大咖专栏 | 挖掘 EB 级别数据的价值 – Redshift Spectrum 介绍及最佳实践

大咖专栏主要刊登 AWS 诸位大咖亲自撰写的 Blog，内容涉猎广泛，话题讨论前沿，且与实战紧密相连。我们非常欢迎小伙伴们在评论区留言，与大咖互动交流！

今天为大家撰文的大咖，是我们的 AWS 业务拓展经理——刘宁老师。

刘宁

AWS 业务拓展经理

刘宁致力于 AWS 数据库云服务的应用和推广。在加入 AWS 之前，他曾任微软中国企业服务部产品营销经理，华侨银行科技部 IT 产品经理，对企业应用设计及架构有着深刻了解。

随着数据存储技术的快速发展，众多企业客户可以以低成本存储 PB 级别甚者 EB 级别的数据。这使得大数据分析在近几年来不但成为现实而且愈发火热。然而真正实现海量数据的分析既要有存储海量数据的资源，又要有足够强大的分析能力。近年来，我们看到数据分析能力的发展并没有追赶上存储技术的发展速度 。现实中企业客户虽然有了可以收集并存储大量数据的能力，但很多数据并不能被有效的分析甚至根本未作任何分析，形成了所谓的暗数据。这使得数据分析能力成为实现大数据分析的真正瓶颈。

作为一个托管的数据仓库服务，Amazon Redshift 从它发布至今已经帮助全球成千上万的客户解决了 PB 级别数据的分析能力，实现了复杂 SQL 的快速查询。但随着数据的飞速增长，我们看到越来越多的客户数据开始逼近 EB 级别。对于这样体量的大数据，虽然 Redshift 也可以支持快速的复杂 SQL 查询，但毕竟我们需要启动更多的 Redshift 集群，消耗更多的 CPU 和存储成本，同时还要付出更多的数据加载时间。相反如果我们为了节省资源和成本把数据放在 S3 上，通过 EMR 集群也可以实现快速低成本的数据清理，但针对复杂的（诸如 Join 类）的查询速度会很慢，不能很好支持。这形成了一个鱼与熊掌不可兼得的选择题。

为了真正摆脱数据分析的瓶颈、消灭暗数据，我们的客户需要既能高效执行复杂的查询，又能享受高度可扩展的数据并行处理，也能利用近乎无限的、低成本的 S3 存储资源，还要可以支持多种常用的数据格式。满足这种”既又也还”的任性就是我们的新服务 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 的查询任务提交给 Amazon Redshift 集群的领导节点开始。首先，领导节点负责优化、编译、并推送查询任务给 Amazon Redshift 集群的计算节点。然后，计算节点从外部表获得数据目录，并基于查询任务里的 join 和 filter 动态移除不相关的数据分区。这些计算节点同时也会检测在 Redshift 本地是否已有部分查询数据，从而只从 S3上 扫描本地没有的数据以提升效率。

接下来，Amazon Redshift 的计算节点会基于需要处理的数据对象生成多个查询需求，并行提交给 Redshift Spectrum、Redshift Spectrum 再据此启动上千个工作线程。 这些工作线程进一步从 S3 上扫描、筛选并聚合数据，将处理好的结果数据传回 Amazon Redshift 集群。最后，传回的结果数据在 Redshift 集群本地作 join 和 merge 操作，然后将最终结果返回给客户。

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 集群提升并发

·    列存储文件的分区应尽量基于常用的数据列

·    合理配置 Redshift 集群

以优化 Redshift Spectrum的性能

·    单表筛选、聚合类的查询在 Redshift Spectrum 上

更有性能优势

·    通过推送 predicate 类操作到 Redshift Spectrum 

提升对数据查询速度

·    基于表的尺寸合理分配存储

请感兴趣的同学点击“阅读原文”

或扫描/长按识别下方二维码

阅读学习！