Tag: Amazon Redshift

本文主要介绍了如何利用Amazon Redshift的WLM（工作负载管理）功能，监控数据仓库的查询性能，从而优化队列优先级并保障关键任务的执行。本文还列出了三个常见场景，给出了简单的配置过程。 众所周知，数据仓库的工作负载由于周期性、潜在高开销的数据探索查询以及SQL开发人员不同的技能水平等会出现比较大的性能变化。 为了在面临高度变化的工作负载下仍然能使Redshift集群获得较高的性能，Amazon Redshift工作负载管理（WLM）使您能够灵活地管理任务优先级和资源使用情况。通过配置WLM，短时间，快速运行的查询不会停留在需要较长时间运行的查询之后的队列中。 但尽管如此，某些查询有时可能会陷入不相称的资源分配，并影响系统中的其他查询。 这种查询通常被称为流氓查询或失控查询。 虽然WLM提供了一种限制内存使用并将超时查询移动到其他队列的方法，但多重精细控制依然很需要。您现在可以使用query monitoring rules查询监视规则为查询创建资源使用规则，监视查询的资源使用情况，然后在查询违反规则时执行操作。 工作负载管理并发和查询监控规则 在Amazon Redshift环境中，单个集群最多可以同时连接500个连接。 吞吐量（Throughput）通常表示为每小时的查询量以最大化性能，但像MySQL这样的行数据库使用并发连接数进行衡量。 在Amazon Redshift中，工作负载管理（WLM）可以最大限度地提高吞吐量，而不太考虑并发性。 WLM有两个主要部分：队列和并发。 队列允许您在用户组或查询组级别分配内存。 并发或内存是如何进一步细分和分配内存到一个查询。 例如，假设您有一个并发度为10的队列（100％内存分配）。这意味着每个查询最多可以获得10％的内存。 如果大部分查询需要20％的内存，那么这些查询将交换到磁盘，导致较低的吞吐量。 但是，如果将并发度降低到5，则每个查询分配20％的内存，并且最终结果是更高的吞吐量和更快的SQL客户端响应时间。 当从行数据库切换到基于列的数据库的时候，常见的错误认知是认为更高的并发性将产生更好的性能。 现在你了解了并发性，这里有更多关于查询监控规则的细节。 您可以基于资源使用情况定义规则，如果查询违反了该规则，则会执行相应的操作。 可以使用十二种不同的资源使用指标，例如查询使用CPU，查询执行时间，扫描行数，返回行数，嵌套循环连接等。 每个规则包括最多三个条件,或谓词,和一个动作。谓词由一个指标,比较条件(=、<、>),和一个值组成。如果所有的谓词满足任何规则,该规则的行动被触发。可能的规则操作包括日志记录、跳过任务和中止任务。 这样就可以在导致严重问题前捕获流氓或失控查询。该规则触发一个动作来释放队列，从而提高吞吐量和响应速度。 例如，对于专用于短时运行查询的队列，您可能会创建一个规则来中止超过60秒的查询。 要跟踪设计不当的查询，您可能会有另一个规则记录包含嵌套循环的查询。 在Amazon Redshift控制台中有预定义的规则模板让您使用。 使用场景 使用查询监控规则来执行查询级别的操作，从简单地记录查询到中止查询,以下所有采取的操作都记录在STL_WLM_RULE_ACTION表中： 日志记录（log）：记录信息并继续监视查询。 跳出（hog）：终止查询，并重新启动下一个匹配队列。 如果没有其他匹配队列，查询将被取消。 中止（abort）：中止违反规则的查询。 以下三个示例场景显示如何使用查询监视规则。 场景1：如何管理您临时查询队列中的未优化查询？ 连接两个大表的失控查询可能返回十亿行或更多行。 您可以通过创建规则来中止返回超过十亿行的任何查询来保护您的临时队列。 在逻辑上如下所示： IF return_row_count > 1B rows then ABORT. 在以下截图中，任何返回BI_USER组中超过十亿行的查询都将中止。 场景2：如何管理和控制未调优的CPU密集型查询？ 偶尔引起CPU飙升的查询不一定有问题。 然而，持续的高CPU使用率可能会导致其他并发运行查询的延迟时间增加。 例如，在较长时间内使用高百分比CPU的未调优查询可能是由于不正确的嵌套连接引起的。 […]

背景 在Amazon Redshift 数据仓库为核心的用户，常常陷入一个困境，要想利用该MPP架构的云端数据仓库能力，用户通常需要利用Redshift的 copy命令将数据从S3并行拷贝到Redshift中，如果在数据量比较大的情况下，成本上的考量和业务上的诉求的矛盾会让用户犹豫不定； 尤其突出的矛盾是，客户的业务部门的需求涵盖数据范围同时包含数据仓库的数据和放在S3上的中间或者原始数据集，此时，我们能怎么做？ AWS大数据最佳实践的启示 AWS大数据最佳实践告诉我们要将数据的存储和处理、分析相分离，比如在Amazon EMR服务架构中（如下图），要分析的数据集按照一定的格式压缩存储在Amazon S3上，在EMR中通过Hive定义外表关联到S3上的数据，但不复制到EMR本地，从而实现了数据存储和分析处理的解耦；在大量的用户实践中，我们发现如此的架构优化，可以帮助客户节约大量的存储成本，同时，EMR分析集群无状态化，可以按需动态启动和停止EMR集群，从而优化了计算成本。同理，我们能否在Redshift数据仓库中引入类似的外部表的概念呢？ Amazon Redshift Spectrum简介 Amazon Redshift Spectrum是Redshift的一个新特性，它可以帮助客户将Redshift的分析能力从本地存储扩展到Amazon S3数据湖中海量的非结构化数据而不需要加载数据。通过Redshift Spectrum您可以将热数据存储到 Amazon Redshift 群集中，以获得本地磁盘性能；同时使用 Amazon Redshift Spectrum 将您的查询扩展到 Amazon S3 中存储的冷数据，以获得无限的可扩展性和低成本。 详细情况请参考官方介绍：https://aws.amazon.com/cn/redshift/spectrum/ 目标人群及应用场景 该新功能的推出完善了Redshift数据仓库用户的大数据分析的应用场景，客户可以直接利用Redshift和Redshift Spectrum的能力同时处理本地和S3上的数据集；所以，目标受众是Redshift数据仓库的用户比如金融，电商，游戏等等行业客户。 从应用场景来看，可以满足如下业务需求： 针对数据仓库本地数据和S3上的数据提供一致的、熟悉的数据仓库操作体验 提供终端用户统一的BI或者SQL客户端接入 跨数据仓库热数据和S3冷数据的复杂混合查询 满足低频的业务全数据的低成本即席查询 大数据处理示例管道 本大数据处理示例管道展示了以Redshift数据仓库为核心的典型用户场景，原始数据，中间结果和ETL处理之后的数据都保存在数据湖Amazon S3上；用户通过BI工具或者熟悉的SQL客户端通过Redshift（包括Redshift Spectrum）操作所有的业务数据，包括大数据量的原始数据和存储在数据仓库本地的热数据；客户无需专门为了某个业务的特殊需求，将数据从冷数据从S3复制到Redshift本地再作分析。 支持的数据格式 Redshift Spectrum 使用您已使用的开发数据格式在 Amazon S3 中直接查询数据，这些格式包括 文本文件如 CSV格式文件 日志文件如TSV格式 列式格式如Apache Parquet和Hive中的RCFile格式文件 二进制文件：Sequence格式文件 压缩格式支持：gzip、snappy、bz2 […]

本文主要介绍了Amazon Redshift新一代企业级云平台数据仓库服务，并结合实际的客户使用案例与场景描述了如何基于Amazon Redshift构建高可靠，性能优化，并且成本节约的数据仓库系统。因为Amazon Redshift优异的计算效率与性能，基于Amazon Redshift的BI系统被广泛地应用于互联网数据分析类场景，例如电商中产品维度报表的计算生成，社交类应用中用户画像计算与分析，或者用于替代传统的数据仓库的解决方案。 Amazon Redshift是性能优异并且完全托管的PB级别数据仓库服务。Amazon Redshift提供了标准SQL数据库访问接口，并且可以十分方便地与现有的主流商业智能数据分析工具整合，构建企业级数据仓库。 Amazon Redshift高性能硬件架构 Amazon Redshift底层硬件是基于高度定制化的高性能硬件节点，整个集群是由头节点（leader node，又称领导节点）与计算节点（compute node）的架构组成，如图1所示。其中，头节点负责与所有的客户端程序（标准SQL兼容的客户端，或者通过JDBC/ODBC访问的客户端应用）进行通信，并把对应的SQL命令进行编译后分发给底层的计算节点。同时，头节点还负责存储所有的数据仓库元数据（metadata）。需要注意的是，所有的计算节点同时也是存储节点（单个节点最大支持2TB的存储量）。每个计算节点上配置有定制化的高性能CPU、内存及直接连接硬盘的存储介质。当用户数据仓库的数据量增加的时候，可以通过动态地增加计算节点的数目，以及升级对应计算节点的硬件配置提升集群的存储容量与计算能力。同时，节点与节点的通信是基于AWS定制化的高速内网带宽，减少了因为数据传输带来的时延，提高了计算效率。 图1 Amazon Redshift架构示意图 目前，Amazon Redshift主要支持两大类计算节点类型——DS1/DS2与DC1。其中DS类型节点是为大数据量的工作复杂优化而设计，而且DS2是DS1的硬件升级版本。DC1主要应用于数据计算要求相对更高但是数据总量相对较小的场景。 从应用的角度结合上述架构看，Amazon Redshift的头节点负责基本的SQL编译，查询计划的优化，以及数据仓库原数据的存储。所有的用户数据会以列式存储的方式存放与计算节点之上。因为大部分数据仓库的应用计算围绕于具体的属性列做查询筛选，所以列式存储的计算方式大大提高了数据仓库的计算效率。同时，以MPP的架构组织数据为例，Amazon Redshift也从表设计的角度为用户提供了数据在计算节点的存放方式，用户可以根据具体的SQL表中的键值做分布式存放，或者对某些常用维度表做所有计算节点的全分布存放，从而大大减少数据在节点之间的传输，以提高整体的计算效率。从图1还可以看到，计算节点以MPP的方式并行的从Amazon S3、Amazon DynamoDB、SSH及Amazon EMR并发的实现数据快速加载。另外，Amazon Redshift的整体设计实现了数据的多份冗余存放（对用户使用量透明）——计算节点之间冗余存放，同时定期对数据以增量快照的方式存放于高持久度的Amazon S3之上。 基于Amazon Redshift的BI大数据分析架构 Amazon Redshift针对数据仓库提供了优异的计算与存储效率，利用Amazon Redshift托管服务可以十分方便地构建智能数据仓库系统。同时，因为AWS云计算平台提供了一整套完整的数据分析套件与工具，利用这些组件与Amazon Redshift相结合，可以十分轻松地实现性能优化、成本经济、可靠性强、安全度高的大数据分析架构。图2为一个典型的数据分析平台的基础数据架构。 图2 基于AWS数据分析组件的数据架构 图2中的架构是基于AWS的典型的实时与批量叠加的大数据分析架构。其中Amazon Kinesis是托管的高速实时流分析服务，可以从前端的应用服务器（例如Web服务器）或者移动的客户端（手机等移动设备或者IoT设备）直接注入流式数据，数据可以通过EMR进行流式处理和计算（例如基于Spark Stream的EMR计算框架），并将数据存储于Amazon DynamoDB或者对象存储S3之上。其中，Amazon DynamoDB是托管的高性能NoSQL数据库，可以承载100TB数据量级别而响应时间低于10毫秒。S3作为高可靠（11个9的持久度）的对象存储，在大量的AWS应用场景中，被作为典型的数据湖（data lake）的应用。利用Amazon EMR对S3上的原始数据进行基本的ETL或者结构化操作之后，可以直接从S3以SQL的“copy”命令复制到Amazon Redshift数据仓库中进行SQL的维度计算。另外，可以利用AWS集成的BI分析工具（Quick Sight）或者已有的商业套件直接实现对Amazon Redshift上的数据进行分析与展示。 在实际的业务场景中，数据库的来源包含Amazon DynamoDB或者Amazon RDS这类业务数据库，以及用户活动日志或者行为日志等Web前端日志。这些数据需要以增量的方式汇聚于AWS S3及ETL之后进入到Amazon Redshift之中。常用的做法，可以利用AWS的Data Pipeline服务直接定义对应的原端数据源及对应的后端数据目标，自定义采集周期，一次性配置之后就可以直接进行数据通路的增量拷贝。 小红书电商基于Amazon Redshift的用户数据分析 小红书是新一代的社区电商，它将海外购物分享社区与跨境电商相结合，精准捕捉85后和90后的消费升级需求，迅速发展成为极具影响力的全球购物分享社区。目前小红书的注册用户数量已超过1800万，其中近90%是女性、超过50%是90后。作为新一代消费人群，这些用户有着共同的价值观，更注重感觉和体验，对优质商品和生活充满向往。“社区＋电商”的模式推动了小红书的快速发展，在电商平台成立的半年内，其销售额就达到7亿人民币。 与小红书自身高速发展的业务模式一样，小红书的数据架构与数据分析团队也经历了从基本日志服务器脚本分析到目前利用Amazon […]

什么是一个好的数据仓库？ Redshift是AWS云计算中的一个完全托管的，PB级别规模的数据仓库服务。即使在数据量非常小的时候(比如几百个GB的数据)你就可以开始使用Redshift，Redshift集群可以随着你数据的增加而不断扩容，甚至达到PB级。云计算中数据仓库的优势非常明显，不需要license，不需要预先配置非常大的数据仓库集群，扩容简单，仅仅需要为你实际所使用的数据仓库付费。 Redshift作为一个企业级数据仓库完全支持SQL语法，无学习成本，支持很多种客户端连接，包括各种市场上的BI工具，报表以及数据分析工具。 Redshift的概览 Redshift通过支持大规模并行处理(MPP)，列式存储，对不同列数据使用不同数据压缩算法，关系型数据仓库(SQL)，灵活的扩容管理等众多优点，兼顾了数仓性能，同时也考虑学习成本及使用成本。 Redshift系统架构及要点 图1，Redshift系统架构图 主节点负责客户端与计算节点之间的所有通讯，编译代码并负责将编译好的代码分发给各个计算节点处理，负责分配数据到不同的计算节点，主节点对客户不可见的，无需客户管理主节点的压力，更重要的是主节点免费。 计算节点是具体的干活的，并处理好的任务送给主节点进行合并后返回给客户端应用程序。每个计算节点都有自己独立的CPU，内存以及直连存储。Redshift集群规模大小通常就是指计算节点的个数以及计算节点机器类型。 节点分片是指将计算节点被分成若干的分片，根据计算节点类型不同，每个节点包含的分片数量不同，通常1个vCPU对应一个分片，ds2的机型除外。每个分片都会分配独立的内存及存储资源，接受来自主节点分配的任务。分片跟另外一个重要概念Dist Key紧密相关， 这里先提一下，接下来会具体介绍Dist Key。 排序键(Sort Key)是一个顺序键，即Redshift会根据这个键来将数据按顺序存储在硬盘上。Redshift的查询优化程序(只要理解有这么个东西存在就好，客户不需要任何维护，对客户也是透明的)也会根据这个排序来进行执行查询优化计划。这是Redshift性能调优的一个非常重要的参数。 分配键(Distribution Key)是控制加载到表的数据如何分布在各个计算节点的一个键，有好几种分布的风格，接下来会重点讲到，这是Redshift调优的非常重要的另外一个参数。 Redshift的几个常用最佳实践 选择最佳排序键 如果最近使用的数据查询频率最高，则指定时间戳列作为排序键的第一列； 如果您经常对某列进行范围筛选或相等性筛选，则指定该列作为排序键； 如果您频繁联接表，则指定联接列作为排序键和分配键； 熟悉Redshift的朋友可能知道可以指定多列作为排序键，而且排序键还有两种方式，组合式和交叉式。限于篇幅的原因，在接下来的调优测试中我们采用的是某一列作为排序键，如果有对其他排序键风格感兴趣的朋友，可以单独联系我们进行讨论。 选择最佳分配键 选择表分配方式的目的是通过在执行查询前将数据放在需要的位置来最大程度地减小重新分配步骤的影响，最好这个查询不需要二次移动数据。 分配键有三种风格，均匀分布(Even)，键分布(Key)，全分布(All)，默认是均匀分布。 根据共同列分配事实数据表和一个维度表； 事实数据表只能有一个分配键。任何通过其他键联接的表都不能与事实数据表并置。根据联接频率和联接行的大小选择一个要并置的维度。将维度表的主键和事实数据表对应的外键指定为 DISTKEY。 根据筛选的数据集的大小选择最大的维度； 只有用于联接的行需要分配，因此需要考虑筛选后的数据集的大小，而不是表的大小。 在筛选结果集中选择基数高的列； 例如，如果您在日期列上分配了一个销售表，您可能获得非常均匀的数据分配，除非您的大多数销售都是季节性的。但是，如果您通常使用范围受限谓词进行筛选以缩小日期期间的范围，则大多数筛选行将位于有限的一组切片上并且查询工作负载将偏斜。 将一些维度表改为使用 ALL 分配； 如果一个维度表不能与事实数据表或其他重要的联接表并置，您可以通过将整个表分配到所有节点来大大提高查询性能。使用 ALL 分配会使存储空间需求成倍增长，并且会增加加载时间和维护操作，所以在选择 ALL 分配前应权衡所有因素。 优化COPY，提高数据加载速度 当你将要数据加载到Redshift的某个表时，不要让单个输入文件过大，最好是将这些输入文件切成多份，具体数量最好是跟分片数量匹配，这样可以充分利用所有分片，配合分配键能达到最佳效果。 图2，COPY输入的最优方式 让COPY选择自动压缩 作为数据仓库，Redshift通常会需要大量导入数据，这时使用做多的，效率最好的是COPY命令。在使用COPY时建议将COMPUPDATE参数设置为ON，这样数据在加载进库时是自动压缩的，好处是可以节省存储空间，提高查询的速度，不过这会增加数据加载进表的时间，这个可以根据你的业务需求，再具体衡量。 Redshift调优实战 测试结论 选择合适的排序键，分配键，及自动压缩对表的查询速度，存储效率很大提升。本次测试中，优化后查询速度有高达75%的提升，存储空间节省50%。 相同节点类型情况下，多节点性能比单节点性能提升明显。本次测试中，采用了4节点与单节点对比，4节点查询速度比单节点提升75%。 节点数量相同的情况下，dc系列节点的查询速度比ds系列节点的查询速度要快。本次测试中，采用了dc1.large和ds1.xlarge两种节点类型进行对比，dc系列节点的查询速度比ds系列快20% 。 使用JOIN与不使用JOIN查询速度无明显差别。本次测试中，三个不同的查询及对应的JOIN查询，在查询速度上的差别非常小。这部分的详细测试结果，请参见附录一。 查询速度达到一定值时，再增加节点对查询优化的效果有限。本次测试中，在相同环境中，将节点数量从8个dc1.large节点增加到12个dc1.large节点，三个查询只有一个查询的速度有一定提升，其他2个查询速度基本没有太大变化。这部分的详细测试结果，请参见附录二。 图3，调优前后性能对比图 […]