Redshift 系统架构概述、Redshift与AWS其它服务整合
Amazon Redshift 数据仓库是一个企业级的关系数据库查询和管理系统。
Amazon Redshift 支持与多种类型的应用程序（包括商业智能 (BI)、报告、数据和分析工具）建立客户端连接。
在执行分析查询时，您将在多阶段操作中检索、比较和计算大量数据以产生最终结果。
Amazon Redshift 通过大规模并行处理、列式数据存储和非常高效且具有针对性的数据压缩编码方案的组合，实现高效存储和最优查询性能。此部分介绍了 Amazon Redshift 系统架构。
1、 数据仓库系统架构概述
如图所示，在Redshift中，包含如下各类要素：
客户端应用程序
Amazon Redshift 与各种数据加载和 ETL（提取、转换和加载）工具以及商业智能 (BI) 报告、数据挖掘和分析工具集成。Amazon Redshift 基于行业标准 PostgreSQL，因此，大多数现有 SQL 客户端应用程序仅处理最少量的更改。有关 Amazon Redshift SQL 和 PostgreSQL 之间的重要差异的信息，请参阅 Amazon Redshift 和 PostgreSQL。
连接
Amazon Redshift 通过使用行业标准 PostgreSQL JDBC 和 ODBC 驱动程序与客户端应用程序进行通信。
集群
Amazon Redshift 数据仓库的核心基础设施组件是集群。
集群包含一个或多个计算节点。如果集群预置有两个或更多计算节点，则一个额外的领导节点 将协调这些计算节点并处理外部通信。您的客户端应用程序仅直接与领导节点交互。计算节点对于外部应用程序是透明的。
Master - Worker 架构
领导节点 - Master
领导节点管理与客户端程序的通信以及与计算节点的所有通信。它分析和制定执行计划以实施数据库操作，特别是获得复杂查询的结果所需执行的一系列步骤。根据执行计划，领导节点编译任务、将编译后的任务分发给计算节点，并将数据分配给每个计算节点。
计算节点 - Worker
领导节点为执行计划的单个元素编译代码并将代码分配给各个计算节点。计算节点执行编译后的代码，并将中间结果发送回领导节点以便最终聚合。
每个计算节点均拥有自己的专用 CPU、内存和连接的磁盘存储，这都由节点类型决定。当您的工作负载增加时，您可以通过增加节点数和/或升级节点类型来增加集群的计算容量和存储容量。
Amazon Redshift 提供两种节点类型；密集存储节点和密集计算节点。每个节点提供两个存储选项。您可从单个 160 GB 节点开始并向上扩展至多个 16 TB 节点以支持 PB 级数据或更多数据。
节点切片
一个计算节点分为多个切片。将为每个切片分配节点的内存和磁盘空间的一部分，从而处理分配给节点的工作负载的一部分。领导节点管理向切片分发数据的工作，并将任何查询或其他数据库操作的工作负载分配给切片。然后，切片将并行工作以完成操作。
每个节点的切片数由集群的节点大小决定。
在创建表时，您可以选择将一个列指定为分配键（分区键）。在将表与数据一起加载时，会根据为表定义的分配键将行分配给节点切片。选择好的分配键将使 Amazon Redshift 能够使用并行处理来加载数据和高效执行查询。
内部网络
Amazon Redshift 利用高带宽连接、紧邻和自定义通信协议来提供领导节点和计算节点之间的速度极快的私有网络通信。计算节点在客户端应用程序绝对无法直接访问的独立的、隔离网络上运行。
数据库
一个集群包含一个或多个数据库。用户数据存储在计算节点上。您的 SQL 客户端与领导节点进行通信，进而通过计算节点协调查询执行。
Amazon Redshift 是一个关系数据库管理系统 (RDBMS)，可与其他 RDBMS 应用程序兼容。虽然 Amazon Redshift 提供了与典型 RDBMS 相同的功能（包括在线事务处理 (OLTP) 功能，例如，插入并删除数据），但它已经过优化，可对大型数据集进行高性能的分析和报告。
Amazon Redshift 基于 PostgreSQL 8.0.2。Amazon Redshift 和 PostgreSQL 之间的差别非常大，您在设计和开发数据仓库应用程序时需要注意这一点。有关 Amazon Redshift SQL 与 PostgreSQL 之间的差异的信息，请参阅 Amazon Redshift 和 PostgreSQL。
2、 性能概述
2.1 大规模并行处理
大规模并行处理 (MPP) 支持对大量数据快速执行最复杂的查询。多个计算节点并行处理所有查询以获得最终结果的聚合，执行相同的编译后查询的每个节点的每个核心在整个数据的各个部分进行分段。
Amazon Redshift 将表行分配给计算节点，以便能并行处理数据。通过为每个表选择相应的分配键，可以优化数据分配以均衡工作负载，并最大程度地减少节点间的数据移动。
2.2 列式数据存储
数据库表的列式存储大大降低了总体磁盘 I/O 要求，它是优化分析查询性能的一个重要因素。按列式方式存储数据库表信息将减少磁盘 I/O 请求数与需从磁盘加载的数据量。减少加载到内存中的数据量使 Amazon Redshift 能够在执行查询时执行更多的内存中处理。
在适当地对列进行排序时，查询处理器能够快速筛选出大型数据块子集。
2.3 数据压缩
数据压缩将降低存储要求，从而减少磁盘 I/O 来提高查询性能。在执行查询时，压缩的数据将读入内存，然后在查询执行期间解压缩。将少量数据加载到内存中使 Amazon Redshift 能够分配更多内存来分析数据。
2.4 结果缓存
为了缩短查询执行时间并改进系统性能，Amazon Redshift 在领导节点的内存中缓存特定查询类型的结果。当用户提交查询时，Amazon Redshift 会在结果缓存中检查是否有查询结果的有效缓存副本。如果在结果缓存中找到匹配项，则 Amazon Redshift 会使用缓存的结果而不执行查询。结果缓存对用户透明。
默认情况下，结果缓存处于启用状态。要为当前会话禁用结果缓存，请将 enableresultcacheforsession 参数设置为 off。
在满足以下所有条件时，Amazon Redshift 将为新查询使用缓存的结果：
• 提交查询的用户具有在查询中所用对象的访问权限。
• 查询中的表或视图未更改。
• 查询不使用必须在每次运行时求值的函数，例如 GETDATE。
• 该查询不引用 Amazon Redshift Spectrum 外部表。
• 可能影响查询结果的配置参数未更改。
• 查询的语法与缓存的查询相符。
为了最大限度地提升缓存有效性和资源的使用效率，Amazon Redshift 不缓存一些非常大的查询结果集。Amazon Redshift 会根据多个因素确定是否缓存查询结果。这些因素包括缓存中的条目数以及 Amazon Redshift 集群的实例类型。
要确定查询是否使用了结果缓存，请查询 SVL_QLOG 系统视图。如果查询使用了结果缓存，sourcequery 列会返回源查询的查询 ID。如果未使用结果缓存，则 sourcequery 列值为 NULL。
以下示例说明了由 userid 104 和 userid 102 提交的查询使用了来自 userid 100 运行的查询的结果缓存。
select userid, query, elapsed, source_query from svl_qlog
where userid > 1
order by query desc;
3 、列式存储概述
数据库表的列式存储是优化分析查询性能方面的一个重要因素，因为它将大大降低总体磁盘 I/O 要求并减少需从磁盘加载的数据量。
以下一系列图示描述列式数据存储如何实现高效以及如何在将数据检索到内存中实现高效。
首先，按行存储
• 在典型的关系数据库表中，每个行均包含一条记录的所有字段值。
• 在行式数据库存储中，数据块按顺序存储每个连续列（构成整个行）的值。
• 如果数据块大小小于记录的大小，整个记录的存储可采用多个数据块。
• 如果块大小大于记录的大小，整个记录的存储可能采用 1 个以下的数据块，从而导致磁盘空间的使用低效。
按列存储
如图，针对行存储，列存储有以下优点：
• 单列数据保存在一起，不同列分开存储，导致存下同样一个表需要更多的Block文件，看起来是更复杂了，但是基于列和列分开存储，这种形式天生就适合分布式的存储，并能完全利用并发写入和并发读取的能力
• 同一列存放在一起，数据类型相同，则更好的进行压缩
• 同一列存放在一起，则排序更加方便，基于排序方便，where某一列会更加快
不过，尽管列存储有优势，行存储也有其优势：
• 更容易做事务、一致性控制。一整行作为整体存储或检索，成或不成，事务区分很明显。
但是列存储因为要分离列进行存储，一个整体操作拆分成多次操作，在事务上更难控制一致性
所以，关于列和行存储，要看具体的需求，如：
• 关系型数据库基本都是行存储，Mysql、Oracle等，因为强调一致性和事务
• NoSQL多数为列存储，因为高效、吞吐量高，但事务、一致性较弱（也有做到事务性比较强的，只是更加复杂，需要更多东西来配合）
那么，总结为：
• 行： 一致性、事务更加容易做
• 列：吞吐量高、性能强，一致性、事务方面较弱
基于Redshift，数据仓库的定位，采用列存储可以为建模分析提供更好的吞吐量、性能。
同时，基于AWS的努力，也在一定程度上，保证了Redshift的事务隔离性。
4、 内部组件和功能的概览
从数据库视图看，Redshift内部有一系列的方法和视图，如：
对应图中：Database Services and Functions
• 数据load/upload控制 Data Load/Upload
• 系统管理 System Manager
• 磁盘碎片/清除 控制 Vacuum/Defrag
• 统一调度方法 Utility Functions
• 系统表/视图 System Tables
• 资源管理 Resource Manager
• 压缩 Compression
• 备份/恢复 Backup & Restore
• 加密 Encryption
• 故障处理 Failover
• 查询结果聚合 Query Result Aggregator
• 存储子系统 Disk Subsystem从执行流程上，以查询为例，大体上是如下顺序：
1. 客户端通过JDBC、ODBC进行连接Lead 节点，发起查询
2. 在Lead节点内：
3. 通过监听和交流层进行连接处理，接收查询请求
4. 解析查询请求
5. 将命令分为：Queries and Joins 或者 非查询命令
6. 解析，生成执行计划并优化
7. 生成执行代码，分发给计算节点
7.1. 同时在Lead节点内会有
1). 查询、工作负载管理器
2). 调度器
3). 通讯层
7.2. 这三种内容，来管理和调度计算节点的工作
8. 计算节点通过通讯层接收到执行代码后
9. 会通过分发器进行查询切片
10. 并将代码应用在每个具体的切片上
11. 对切片应用的作业会对磁盘进行IO查询检索
12. 查询完成后，每个计算节点将各自的中间结果返回给Lead节点
13. Lead节点聚合结果
14. 通过通讯层，将结果范围给客户端ps：以上是Redshift的查询的大体流程，存储也基本差不多。
其实可以看出，这也是一个典型的分布式系统的工作流程，或者说典型的Master-Worker架构的工作流程。
5、 Redshift与AWS其它服务整合
Redshift可以和其它的AWS服务整合，比如：
• 支持和S3之间传输数据，在入门案例中，我们就从S3 copy数据加载到了示例表中。
• 支持和DynamoDB进行数据传输。
• 支持通过命令，从远程SSH主机中加载数据
• 支持使用 AWS Data Pipeline 自动化数据加载
• 支持使用 AWS Database Migration Service 迁移数据
