转载

纳斯达克业务架构利用Amazon EMR与Amazon S3实现面向大规模数据集的临时性访问

这是一篇由纳斯达克首席架构师Nate Sammons撰写的文章。

纳斯达克集团公司在全球范围内负责金融交易运营工作，且每天处理的数量总量极为庞大。我们运行着种类繁多且数量可观的分析及监控系统，而且这些系统全部需要访问同样的整体数据集。

纳斯达克集团自Amazon Redshift发布之日起就开始将其引入自身业务体系，我们也对这一决定感到由衷赞赏。我们此前已经在re:Invent大会上多次探讨过该系统的客户使用情况，最近的一次来自《FIN401地震式转变：纳斯达克向Amazon Redshift迁移》一文。目前，我们的系统每天将平均55亿行数据移动至Amazon Redshift当中（2014年10月的单日峰值移动量为140亿行）。

除了我们的Amazon Redshift数据仓库之外，我们还拥有一套庞大的历史数据设施体系，旨在将其作为单一、巨型数据集加以访问。目前，这套历史数据归依体系分布在大量不同系统当中，这使相关内容变得难于使用。我们的目标是建立起一套新的双重统一化数据仓库平台，其一方面需要为纳斯达克各内部部门带来更为理想的历史数据集访问能力，另一方面则希望在流程当中实现更突出的成本效益。对于这套平台，Hadoop是一项明确的选项：它支持多种不同类型的SQL及其它用于数据访问的接口，同时拥有一整套活跃且持续发展的工具及项目生态系统。

为什么选择Amazon S3与Amazon EMR？

我们新型数据仓库平台的主要构建宗旨是为了将存储与计算资源加以分离。在传统Hadoop部署机制当中，存储容量的伸缩通常也要求我们对计算容量进行伸缩，而且计算与存储资源二者之间的任何比例变更都要求使用者对硬件进行修改。在我们的长期历史归档用例当中，HDFS当中访问频率较低的数据仍然需要保持始终可用，并一直占用集群当中每个节点的计算资源。

除此之外，HDFS的默认复制因子为3，这意味着每个数据块需要占用集群中的三个节点。这虽然能够在一定程度上保障耐久性水平，但也同时代表着大家必须购买必要的存储容量、从而在对集群进行容量扩展时将磁盘数量增加至预期原始容量的三倍。除此之外焦点问题也需要得到关注：如果某个给定数据块在集群中只存在于三个节点当中，但却需要经受频率极高的访问操作，那么大家必须对其进行复制或者将特定计算节点设置为访问焦点。

不过在Amazon S3与Amazon EMR的帮助下，我们能够顺利摆脱上述难题。二者允许大家将用于数据仓库的计算与存储资源进行分离，并根据需要单独对其进行规模伸缩。其中不再存在焦点，因为S3中的每个对象都能够以无需焦点机制的支持下与任意其它对象一下接受访问。Amazon S3还拥有几乎无限的可扩展能力、11个9的卓越耐久性（即99.999999999%）、自动跨数据中心复制、简洁直观的跨区域复制以及令人心动的低廉成本。随着与IAM政策的进一步集成，S3还带来一套拥有经过深入细化调整且涵盖多个AWS账户访问控制机制的存储解决方案。考虑到上述理由，Netflix公司以及其它众多企业已经证明了Amazon S3是一套极具可行性的数据仓库平台。此外，AWS Lambda等新型服务的出现能够针对S3事件执行任意代码作为响应，而这将进一步拓展用户可资挖掘的使用潜力。

利用EMR启用集群

EMR的出现令使用者能够更轻松地部署并管理Hadoop集群。我们能够根据实际需要对集群规模与提升与削减，并在周末或者节假日期间将其关闭。一切元素都运行在虚拟私有云（简称VPC）环境之下，因此我们能够对网络访问进行严格控制。IAM角色集成则让使用者能够轻松实现泛用性访问控制机制。最重要的是，EMRFS——这是一套HDFS兼容性文件系统，能够访问S3当中的存储对象——允许大家利用访问控制挼顺S3当中的数据存储层。

我们能够利用多套EMR集群在同样的存储系统基础之上运行多个数据访问层，而且这些访问层能够实现彼此隔离且不需要占用计算资源。如果某项特定任务需要在少数情况下使用每个节点中的大量内存资源，我们可以直接为其运行一套专用的内存优化型节点集群，而不必再像过去那样纠结于集群内CPU与内存的具体搭配比例。我们能够在无需针对特定内部客户修改“主”生产集群的前提下运行实验性集群。成本分配同时易于实现，因为我们能够为EMR集群添加标签、从而进行成本追踪或者根据需要将其运行在各个独立AWS账户当中。

由于它能够极大降低集群体系的管理难度，现在我们得以建立新的实验性数据访问层并运行大规模POC，同时无需为了运行相关Hadoop集群所带来的新硬件采购支出或者将大量时间用于摆弄各种类型的移动部件。这与我们当初启用Amazon Redshift时的状况非常相似：在Amazon Redshift出现之前，我们甚至根本无法想象自己能够对容量超过100TB的生产数据库进行复制以完成实验性目标。如果使用传统处理方式，整个过程可能需要耗时数个月，其中包括订购硬件、设置以及进行数据迁移等等——现在，我们只需要一个周末就能搞定全部工作，并在实验完成后直接将其“回炉再造”。总而言之，Amazon Redshift为我们开启了一扇新的可能性大门，而在此前这一切完全不可能实现。

随着我们全新数据仓库的推出，我们的目标旨在建立起一套极具实用性且能够为一系列类型广泛、技能储备有异的用户提供访问能力的平台方案。其主要接口通过SQL实现; 我们曾经对Spark SQL、Presto以及Drill等进行过评估，但我们同时也认真考量过其它候选方案以及非SQL机制。Hadoop社区的发展速度极快，因此根本不存在一款能够通吃一切的万试万灵型查询工具。我们的目标是为客户希望使用的一切Hadoop生态系统分析及数据访问应用程序提供必要支持。EMR与EMRFS与S3相对接让上述目标成为了可能。

安全要求与Amazon S3客户端加密机制

纳斯达克集团拥有一套业务涵盖范围广且士气高昂的内部信息安全团队，其在数据及应用程序保护方面遵循着严格的管理政策及标准。考虑到数据的敏感性水平，这部分内容必须在存储及传输过程中得到确切加密。除此之外，加密密钥必须被保存在位于纳斯达克基础设施内部的HSM（即硬件安全模块）集群当中。我们为HSM选择了与AWS CloudHSM服务相同的设备品牌与机型（即SafeNet Luna SA），这也使得我们能够将Amazon Redshift集群主密钥保存在自己的HSM当中。为了简单起见，我们将其称为纳斯达克KMS，其功能类似于原有AWS密钥管理服务（简称AWS KMS）。

最近，EMR在EMRFS中推出了一项新功能，允许客户利用自有密钥实现S3客户端加密，其利用S3加密客户端的封闭加密机制。EMRFS允许大家通过实现由AWS SDK提供的EncryptionMaterialsProvider接口编写自己的瘦适配机制，这样当EMRFS在S3内读取或者写入某个对象时，我们就将获得一项回调以为其提供加密密钥。这是一种简洁的低级钩子，允许大家在无需添加任何加密逻辑的前提下运行大多数应用程序。

由于EMRFS是一种HDFS接口实现机制（当大家在EMR当中使用‘s3://’时即可进行调用），因此前面提到的各层无需在加密过程中进行识别。EMRFS在堆栈中还属于低级机制，因此其运作方式可谓包罗万象。换言之，它几乎能够应对一切集成加密任务。需要强调的是，seek()函数同样适用于保存在S3当中的加密文件，因此其对于多数Hadoop生态系统内的文件格式而言都是一种极为重要的性能保障功能。

使用定制化加密素材提供程序

在素材提供程序方面，我们的实现方案能够与纳斯达克KMS进行通信（具体情况请参阅下文中的‘代码示例’章节）。EMR能够从S3当中提取出自己的.jar实现文件，将其放置在集群中的每个节点当中，并通过EMRFS配置在集群上的emrfs-site.xml配置文件当中使用我们的素材提供程序。我们能够在创建新集群时指定下列参数，从而轻松通过AWS命令行实现上述目标：

--emrfs Encryption=ClientSide,ProviderType=Custom,CustomProviderLocation= s3://mybucket/myfolder/myprovider.jar,CustomProviderClass=providerclassname

利用上述代码，一个s3get与configure-hadoop引导操作将以自动化方式实现添加并分别被配置为复制提供程序jar文件及配置emrfs-site.sml。其中s3get引导操作在获取到来自S3的请求后将使用被分配至该集群的Instance Profile，这样一来大家就能够对自己的提供程序jar文件进行访问限制。另外，如果大家的提供程序类通过来自Hadoop API的Configurable实现，那么也能够从运行时中的Hadoop配置XML文件处获取配置数值。

S3对象上的“x-amz.matdesc”用户元数据字段被用于存储“素材描述”，这样我们的提供程序就能了解到需要接收哪些密钥。该字段中包含一套JSON版本的Map<String.String>，其会在针对现有目标进行密钥请求时被交付至提供程序实现处。当某密钥被请求编写一个新的对象时，同样的映射将被交付至EncryptionMaterials对象，后者当中也拥有一条Map<String.String>作为描述。我们会经常对加密密钥进行轮换，所以我们会利用该映射为S3对象所使用的加密密钥保存惟一一条标识符。密钥标识符本身不会被作为敏感信息处理，因此我们可以将其存储在S3当中的对象元数据之内。

数据输入任务流

纳斯达克已经拥有一套成熟的数据采集系统，其开发目标在于支持我们对Amazon Redshift的采用与推广。这套系统建立在一套任务流引擎之上，该引擎每天能够执行约30000次编排操作，同时使用MySQL作为状态信息的持久性存储机制。

大部分此类操作需要执行多个步骤，且遵循以下几种常见模式：

通过JDBC、SMB、FTP以及SFTP等对其它系统进行数据检索。
验证数据语法及正确性，以确保既定模式未出现变更或者数据未出现丢失等等。
将数据转化为Parquet或者ORC文件。
利用S3客户端加密机制将文件上传至S3当中。

我们的数据采集系统本身并不具备直接针对HDFS的能力。我们利用类似的EncryptionMaterialsProvider实现机制将数据直接写入至S3当中，而无需借助Hadoop Configuration接口钩子。这一点非常重要，即避免在对EMRFS进行数据读取或者写入时采用任何特殊方式。而且只要大家的素材提供程序能够检测到需要使用的正确加密密钥，EMR就能以无缝化方式在S3当中操作加密对象。

纳斯达克业务架构利用Amazon EMR与Amazon S3实现面向大规模数据集的临时性访问

代码示例

我们的加密素材提供程序可参照以下代码示例：

import java.util.Map; import javax.crypto.spec.SecretKeySpec; import com.amazonaws.services.s3.model.EncryptionMaterials; import com.amazonaws.services.s3.model.EncryptionMaterialsProvider; import org.apache.hadoop.conf.Configurable; import org.apache.hadoop.conf.Configuration;   public class NasdaqKMSEncryptionMaterialsProvider implements EncryptionMaterialsProvider, Configurable {   private static final String TOKEN_PROPERTY = “token”;   private Configuration config = null; // Hadoop配置   private NasdaqKMSClient kms = null;  // 面向KMS的客户端     @Override   public void setConf(Configuration config) {     this.config = config;     // 读取任意需要初始化的配置值     this.kms = new NasdaqKMSClient(config);   }     @Override   public Configuration getConf() { return this.config; }     @Override   public void refresh() { /* nothing to do here */ }     @Override   public EncryptionMaterials getEncryptionMaterials(Map desc) {     //从素材描述中获取密钥标识     String token = desc.get(TOKEN_PROPERTY);       //从KMS中检索加密密钥     byte[] key = kms.retrieveKey(token);       //利用该密钥创建一个新的加密素材对象     SecretKeySpec secretKey = new SecretKeySpec(key, “AES”);     EncryptionMaterials materials = new EncryptionMaterials(secretKey);       //利用密钥标识（identifier）对相关素材进行标记     materials.addDescription(TOKEN_PROPERTY, token);     return materials;   }     @Override   public EncryptionMaterials getEncryptionMaterials() {     //生成一个新的密钥，利用其进行密钥分配，     //同时利用该标识返回新的加密素材     //并将其存储在素材描述当中。     return kms.generateNewEncryptionMaterials();   } }