AWS上的计算和存储服务

背景

AWS是个很有意思的、经过体系化思考的生态系统，最近看了一下跟大数据相关的几个AWS服务：S3, Athena, Redshift, EMR, Glue等等。这里从数据存储和计算引擎的角度分析一下AWS的这几个服务。

拿马老板的话说这是个DT的时代，DT时代什么最重要? 当然是数据了。但是数据本身并不会带来价值，从数据里面得到的对业务的洞见才是。为了要能从数据中获得洞见，我们要把数据保存下来对数据进行各种加工、处理、分析、生成报表等等，这就涉及到了数据存储和计算。

在开源界大数据存储的事情标准是 HDFS, 计算引擎则比较丰富: MapReduce, Spark, Flink等等，随着服务器间带宽越来越大，特别是400Gbps网络的出现，存储和计算分离越来越成为趋势。 这样的好处很多，比如:

• 一份数据不用因为计算引擎的不同而需要复制、搬运到多个地方，节省存储和计算成本。

• 存储和计算分离之后，存储跟计算可以各自发展自己的极致，一个小的模块比大的模块更容易产生创新。

• 存储和计算分离之后，我们可以根据不同场景选择不同的引擎，而不需要绑定到一个特定的引擎。

而在AWS的世界里，S3(Simple Storage Service)某种程度上扮演了HDFS的角色，因为它能存储海量的数据，还足够便宜。而计算引擎的服务则有：Athena, Redshift, EMR等等。

存储

S3是AWS上的文件存储系统，它支持对海量的数据进行存储，从AWS官网对它的描述就可以看出它有多霸气:

Amazon Simple Storage Service (Amazon S3) is storage for the Internet. You can use Amazon S3 to store and retrieve any amount of data at any time, from anywhere on the web.

三个Any: Any Amount, Any Time, Any Where, 太霸气了。一般来说用户会把那些不常用的冷数据保存到S3上面。

计算引擎

先说说Athena。AWS对Athena的定位是一个”Query Service”, 它主要针对S3上存储的数据进行即席查询，它是一个Serverless的服务，你不需要去维护一个集群，你只需要基于你的S3的数据定义一个table，然后就可以利用ANSI SQL对这个“表”(其实就是S3)上的数据进行各种分析查询了。不过Amazon提供的Web界面真的是挺朴素的，跟我们公司内部做的数据查询工具相比太朴素了:

Athena的朴素页面

之前看过Google BigQuery的查询界面，也是类似这样的，非常的朴素。我想这里的原因可能在于Amazon、Google这些国外的技术大公司不想投入太多精力在偏页面端的用户体验优化上，用户如果想要更好看更好用的查询界面让用户自己基于Athena的SDK自己去开发。

Redshift是一个基于PostgreSQL 8.0.2的一个数据仓库的解决方案，跟Athena相比，它更像传统的数仓，因为你需要把数据从外部加载到Redshift里面来。它不是一个Serverless的服务，你需要维护一个集群。Redshift Spectrum是Redshift之上更高阶的功能，它支持查询S3上的数据，而且可以把S3上的数据与Redshift里面的数据进行JOIN -- 部分覆盖了Athena的功能。

Athena和Redshift是看起来很像的两个服务，下面是这两个服务的一些对比：

说完Athena和Redshift就要说说EMR了，Athena是一个即席查询服务；Redshift是一个基于SQL的数据仓库解决方案；而EMR则是全功能的大数据处理解决方案，你可以处理特别特别大的数据，你可以使用开源界的各种流行的处理引擎: Hadoop, Spark, Flink, HBase，可以使用各种不同的技术机器学习，图计算，实时计算等等，而不只是SQL，总的来说就是给你足够多的自由，你想怎么玩就怎么玩，而相对来说Athena和Redshift提供的功能则相对定制化。

让计算引擎找到数据

现在数据存储引擎和计算引擎都有了，那引擎怎么知道数据具体存在什么地方呢？怎么知道数据的结构是怎么样的呢? 我们需要有这么一个元数据系统来维护这个信息，这就是AWS Glue的定位。

AWS Glue是辅助AWS Athena，AWS Redshift等等众多数据查询、计算服务的元数据服务, 你在Athena里面建立的数据库和表都是保存在Glue里面的。Glue本身还提供了ETL处理的能力，让用户可以在不同的数据源之间进行数据的清洗、搬运。

Glue里面几个关键的概念是Database, Table, Crawler, Classifier, Job:

• Database 跟我们普通理解的数据库的概念是类似的，是一组table的逻辑集合。

• Table 是数据的元数据，它定义数据保存在哪里(比如S3的路径)，有哪些column，怎么分区的(分区对查询性能的提高作用很大，可以极大的降低需要扫描的数据量，提高查询速度，降低你需要给Amazon交的钱。)

• Crawler 是元数据的爬虫，你给它一个路径，告诉它每天去爬一次，Crawler就可以及时把更新的元数据，比如新增的分区同步到Glue里面来供计算引擎消费。

• Classifier 是数据结构的解析器，你给Crawler一个S3的路径它怎么就能解析出其中的结构呢，这就是Classifier要干的事情，Glue里面已经内置了一些Classfier, 用户也可以自定义Classifier。

• Job 嘛就是一个ETL脚本了，Glue目前支持的Job要么是Python要么是Scala, 很奇怪为什么不支持SQL, 从国内的数仓经验来看，SQL更适合表达ETL的逻辑呀。

存储 + 计算 + 元数据

S3, Athena, Redshift, EMR等等之间配合的典型场景是这样的:

AWS的大数据服务生态

这其实就描绘了存储跟计算分离之后的数仓场景:

• 数据保存在各种数据存储里面: 热数据保存在关系型数据库比如RDS里面，冷数据保存在便宜的存储比如S3里面。

• Glue通过爬虫以及ETL对数据进行基本的清洗和元数据的维护。

• 根据使用场景的不同利用Athena、Redshift、EMR等等对数据进行计算、查询。

• Redshift适合用来构建一个主要用SQL来进行计算、查询的数仓。

• EMR适合用来利用各种不同的引擎(Spark, Hadoop, Flink)对各种不同的场景：机器学习，图计算进行数据计算。它的主要的特点就是灵活、自主性高，可以使用任何你想用的技术。

• Athena适合对冷数据进行即席查询。

• 最后BI工具通过包装这些计算引擎的能力来提供可视化的报表、分析，获得洞见。

关于AWS产品的一些感想

• AWS上的产品的界面相比国内产品来说做得很朴素。

• 使用起来非常流畅，没有太多的概念，用户理解起来很简单。有需要理解的概念的时候也有对应的文档跟新手Tutorial，让你可以很顺畅地用起来，这是我们国内的数据产品需要学习的地方。

• 每个AWS的产品都有一个FAQ页面, 在这里面可以看到很多概念性的解释、不同产品使用场景的官方阐述。比如Athena的FAQ: https://aws.amazon.com/athena/faqs/，这个感觉特别有用，特别是对于研究AWS上各个产品非常有用。

总结

随着网络带宽的越来越大，计算和存储终将分离，这一方面会催生一些新的基于计算存储分离理念而设计的新计算引擎，同时也会催生冷数据分析的市场 -- 在这之前都是不好分析或者成本比较高、很麻烦的，现在可以让用户以很低的成本对非结构化、半结构化的数据进行分析，充分挖掘这一块的数据的价值。

虽然现在Athena只能查询S3里面数据，Redshift(包括Redshift Spectrum)只能查询Redshift和S3里面的数据，我觉得总有一天会有一个产品会能查询所有的数据，现在AWS没有去做我猜测是不是非S3的数据扫描计费不是那么容易的原因。

AWS里面每个产品都不是独立的，而是相互补充、相互依赖形成了一个完整的解决方案，形成了一个闭环、覆盖各个场景，比如Athena, Redshift, EMR, Glue在大数据处理的领域里面提供了这么多产品，总有一款适合你。这种体系化、生态化的思维值得学习。

作者：xumingmingv
链接：https://www.jianshu.com/p/7b52f9019fb6