随着数据存储技术的快速发展，众多企业客户可以以低成本存储 PB 级别甚者 EB 级别的数据。这使得大数据分析在近几年来不但成为现实而且愈发火热。然而真正实现海量数据的分析既要有存储海量数据的资源，又要有足够强大的分析能力。近年来我们看到数据分析能力的发展并没有追赶上存储技术的发展速度 。现实中企业客户虽然有了可以收集并存储大量数据的能力，但很多数据并不能被有效的分析甚至根本未作任何分析，形成了所谓的暗数据。这使得数据分析能力成为实现大数据分析的真正瓶颈。
作为一个托管的数据仓库服务，Amazon Redshift 从它发布至今已经帮助全球成千上万的客户解决了 PB 级别数据的分析能力，实现了复杂 SQL 的快速查询。但随着数据的飞速增长，我们看到越来越多的客户数据开始逼近 EB 级别。对于这样体量的大数据，虽然 Redshift 也可以支持快速的复杂 SQL 查询，但毕竟我们需要启动更多的 Redshift 集群，消耗更多的 CPU 和存储成本，同时还要付出更多的数据加载时间。相反如果我们为了节省资源和成本把数据放在 S3 上，通过 EMR 集群也可以实现快速低成本的数据清理，但针对复杂的（诸如 Join 类）的查询速度会很慢，不能很好支持。这形成了一个鱼与熊掌不可兼得的选择题。
为了真正摆脱数据分析的瓶颈、消灭暗数据，我们的客户需要既能高效执行复杂的查询，又能享受高度可扩展的数据并行处理，也能利用近乎无限的低成本的 S3 存储资源，还要可以支持多种常用的数据格式。满足这种”既又也还”的任性就是我们的新服务 Redshift Spectrum 的使命。
Redshift Spectrum 介绍
Redshift Spectrum 可以帮助客户通过 Redshift 直接查询 S3 中的数据。如同 Amazon EMR，通过 Redshift Spectrum 客户可以方便的使用多种开放数据格式并享有低廉的存储成本，同时还可以轻松扩展到上千个计算节点实现数据的提取、筛选、投影、聚合、group、排序等等操作。Redshift Spectrum 采用了无服务器架构，所以客户不需要额外配置或管理任何资源，而只需为 Redshift Spectrum 的用量付费。使用方面，Redshift Spectrum 享有和 Amazon Redshift 一样的复杂查询的优化机制、本地数据的快速读取以及对标准 SQL 的支持。结合上述功能特点，Redshift Spectrum 可以在几分钟内完成对 EB 级别的数据的复杂查询，这使它在众多大数据分析服务中脱颖而出。我们做了一个实验，在对一个 EB 的数据做涉及四个表的 join，filter 和 group 的查询时，1000 个节点的 Hive 集群预估需要耗时 5 年，而 Redshift Spectrum 只用了 173 秒。
另外 Redshift Spectrum 是 Amazon Redshift 的一个内置功能，所以使用 Redshift Spectrum 对 Redshift 客户现有的查询服务和 BI 工具不会有任何影响。在 Redshift Spectrum 的底层，我们负责管理着成千上万的跨多个可用区的计算节点。这些节点根据客户查询任务的复杂度和数据量实现透明的扩展和分配，前端的客户无需做任何资源部署和配置。Redshift Spectrum 也很好的支持了高并发 – 客户可以通过任何多个 Amazon Redshift 集群同时访问 S3 上的数据。
Redshift Spectrum 上一个查询任务的生命周期
一切从 Redshift Spectrum 的查询任务提交给 Amazon Redshift 集群的领导节点开始。首先，领导节点负责优化、编译、并推送查询任务给 Amazon Redshift 集群的计算节点。然后，计算节点从外部表获得数据目录，并基于查询任务里的 join 和 filter 动态移除不相关的数据分区。这些计算节点同时也会检测在 Redshift 本地是否已有部分查询数据，从而只从 S3 上扫描本地没有的数据以提升效率。
接下来，Amazon Redshift 的计算节点会基于需要处理的数据对象生成多个查询需求，并行提交给 Redshift Spectrum，Redshift Spectrum 再据此启动上千个工作线程。 这些工作线程进一步从 S3 上扫描、筛选并聚合数据，将处理好的结果数据传回 Amazon Redshift 集群。最后，传回的结果数据在 Redshift 集群本地作 join 和 merge 操作，然后将最终结果返回给客户。
Redshift Spectrum 的优势
Redshift Spectrum 的架构设计有很多优势。第一，剥离计算与 S3 上的存储，使计算资源可以独立弹性扩展。第二，大幅提升了并发效率，因为客户可以用多个 Redshift 集群访问同一组 S3 上的数据。第三，Redshift Spectrum 沿用了 Amazon Redshift 的查询优化机制，可以生成高效的查询规划，即便面对诸如多表 join 或者带统计函数（window function）的复杂查询也能胜任。第四，可以对多种格式的数据源直接查询 – Parquet, RCFile, CSV, TSV, Sequence, Avro, RegexSerDe 等等。这意味着我们无需再做数据加载和转化，同时也消除了存储重复数据带来的成本浪费。第五，通过对开放数据格式的支持，客户的不同团队也可以借助其他的 AWS 服务访问同一组 S3 上的数据，实现协同办公。拥有上述这些优势的同时，因为 Redshift Spectrum 是 Amazon Redshift 的内置功能，客户同时也享受了与 Amazon Redshift 同级别的端到端的安全、合规、以及安全认证。
Redshift Spectrum 最佳实践
使用 Redshift Spectrum 时，我们建议可以从数据分区，列数据结构和数据压缩这几个关键点出发实现 S3 上数据查询效率的提升以及降低查询成本。数据分区方面，按照日期、时间或其他客户自定义的 key 来对数据进行分区可以帮助 Redshift Spectrum 在查询中动态的移除不相关分区以减少扫描的数据量。数据结构方面，我们推荐使用列存储，比如 Parquet 格式，这样 Redshift Spectrum 只需扫描要查询的列而不是整个数据，这可以进一步减少扫描的数据量。数据压缩方面，如果数据可以预先用 Redshift Spectrum 支持的压缩格式压缩，我们同样可以再次减少扫描的数据量。
另外，从数据访问频率来看，我们建议将频繁访问的数据放到 Amazon Redshift 集群中，以获得 Redshift 作为数据仓库服务带来的众多优势。同时，更多的海量数据可以以多种开放数据格式存储在 S3 上，比如历史数据或近期数据，利用 Redshift Spectrum 将 S3 变成一个可随时支持 SQL 查询的数据湖。
下边再列举六个具体使用时的技巧：
使用多个临时 Redshift 集群提升并发：Redshift Spectrum 支持多个 Redshift 集群访问同一组 S3 上的数据，我们可以考虑在业务高峰期时临时开启多个 Redshift 集群，提升并发支持更多的查询任务。因为数据庞大的表我们可以放在 S3 上，所以这些临时 Redshift 集群本地只需存储相对少量的数据即可胜任，在高峰期过后可以关闭这些临时集群。这样客户用相对较小的几个集群就可以轻松应对高峰的大并发。
列存储文件的分区应尽量基于常用的数据列：常用来做 filter、join 等操作的数据列是分区的首选。另外，分区的粒度过细可能会使读取分区信息花费更多时间，但同时也会极大减少数据查询时的数据量。客户可以根据自己的实际情况权衡。最后，S3 上的数据文件大小应尽量平均，例如 10 个 256MB 的文件要比 1 个 1GB+6 个 256MB 的文件读取更高效。
合理配置 Redshift 集群以优化 Redshift Spectrum 的性能：在 Redshift Spectrum 查询 S3 上的数据时，其并行线程取决于两个因素：(1) Query 层面 – 每个 slice 上每个 query 可并行执行查询的线程数 （上限是每个 slice 每个 query 最多 10 个线程） (2) 节点层面 – 每个节点拥有的 slice 数量，不同类型节点的 slice 数量也不同。所以做一个简单的数学运算：当数据文件总数 ≤ (1) × (2)，则在集群内部署更多的节点并不会提升性能。这个方法可以帮我们基于数据文件数量配置大小合理的 Redshift 集群，从而在保证性能的同时减少资源浪费。
单表筛选、聚合类的查询在 Redshift Spectrum 上更有性能优势：这类没有 join 的查询任务通常性能瓶颈在 I/O 层面，比如数据扫面速度，这方面往往 Redshift Spectrum 可以比 Redshift 做的更快。
通过推送 predicate 类操作到 Redshift Spectrum 提升对数据查询速度：Redshift Spectrum 对 S3 上数据的扫描，投影，筛选，聚合等操作是独立于 Redshift 集群的。这类操作同时也不会占用 Redshift 集群的资源。常用的这类指令操作例如 group by, like, count, sum, avg, min, max, regex_replace 等等。我们可以善用这类操作减少 Redshift 集群的负载，提升查询效率
基于表的尺寸合理分配存储：我们建议尽量将大尺寸的表分成多个文件（诸如包含原始数据）放在 S3 上，而只将中小尺寸的表放入 Redshift 集群。这样在进行常规 join 查询时可以取得比较均衡的性能表现。
通过上述的介绍，希望大家对 Redshift Spectrum 有一个基本的了解。通过高度的并行处理，查询的优化以及对 EB 级别数据的复杂查询支持，相信 Redshift Spectrum 能真正帮助企业客户挖掘海量数据的价值，在大数据分析上更进一步。
作者介绍
刘宁，致力于 AWS 数据库云服务的应用和推广。在加入 AWS 之前，他曾任微软中国企业服务部产品营销经理，华侨银行科技部 IT 产品经理，对企业应用设计及架构有着深刻了解。
原文链接:
https://aws.amazon.com/cn/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/
本文转载自 AWS 技术博客。
原文链接：
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论