HashData实战案例：使⽤Alluxio构建云原⽣分析型MPP数据库
本⽂将介绍北京⼀家初创企业构建基于云原⽣的MPP平台的过程。该企业利⽤对象存储作为数据持久层，Alluxio作为云中的数据编排层，最终构建了⼀个原⽣云⾼性能MPP共享的体系架构。
HashData是由⼀群来⾃Pivotal、Teradata、IBM、Yahoo!等开源数据资深⼈⼠于2016年创⽴的。它的旗舰产品HashData WareHou(HDW)，是为云环境构建的数据仓库服务，具有完全兼容的分析接⼝。HDW独特的多集群共享数据库体系架构，在性能、并发性、灵活性和易⽤性⽅⾯取得了很⼤突破。和许多传统MPP系统采⽤的⾮共享体系架构（计算与存储紧耦合）不同，HDW采⽤了具有解耦和独⽴对象存储的共享体系架构。这种体系架构的主要挑战在于性能。与传统的块存储相⽐，对象存储通常性能较低。在本⽂中，我们将进⼀步分析HDW如何利⽤Alluxio作为数据编排层，以消除对象存储带来的性能损失，同时受益于对象存储的可伸缩性和成本效应。
为什么使⽤对象存储服务
如今，对象存储服务（OSS）在原⽣云架构中⼀直很重要。正如所提出的，它提供了更⾼的可⽤性、弹性和耐久性，⽽且成本更低。越来越多的产品和服务⽀持OSS作为他们的持久⽂件系统。
节省成本
根据我们的观察，对于许多拥有100 TB+数据的⽤户来说，他们的成本主要来⾃存储成本，⽽不是计算成本。⼀个主要原因是计算完全随需应变，⽽存储容量在删除数据之前⽆法回收。因此，当客户考虑各种数据分析选项时，存储成本是⼀个重要因素。下表为中国全栈ICT服务及解决⽅案（包括公共云服务）供应商QingCloud在PEK3区域的块存储和对象存储的价格对⽐。OSS的成本⼤约是单副本块存储的
1/4，多副本块存储的1/5。
乌骨鸡汤的做法弹性也会影响存储成本。虽然块存储⽀持在线扩展，但是弹性计算机（即将扩展的块存储卷连接到它）在扩展期间会导致HDW集群短暂停机。因此，客户通常会保留额外的块存储容量，以避免在短时间内再次扩展，从⽽导致成本更⾼。
总之，基于OSS的数据仓库解决⽅案的存储成本⼤约是使⽤传统块存储成本的1/10。
- 系统灵活性
让我们来看⼀个典型的数据分析场景，尤其是在物联⽹和电信⾏业：随着时间的推移，越来越多的数
据⽣成并被导⼊到数据仓库系统中。通常，由于应⽤程序需求或管理策略的原因，这些数据需要保存18或36个⽉。此外，所有数据必须随时可查询，例如在线分析；另⼀⽅⾯，⼤多数单个查询（如果不是全部的话）只涉及整个数据存储的⼀⼩部分（例如，最近⼀周或最近⼀个⽉，或2016年9⽉⾄2016年10⽉之间⽣成的数据）。换句话说，计算资源的需求是稳定的，⽽存储资源的需求则在不断增长。在传统的⾮共享架构下，为了解决这个问题，我们需要对集群进⾏扩展（例如增加更多的worker节点），因为挂载到弹性计算机上的块存储的容量有上限。在这种扩展场景中，新增的计算资源完全是浪费，更不⽤说集群扩展是⼀个容易出错且耗时的过程。
山由与传统MPP解决⽅案的刚性相反，HDW的数据存储容量⼏乎是⽆限的。存储层扩展对于计算层是完全透明的。实际上，从HDW⽤户的⾓度来看，没有存储扩展概念。⽤户可以继续将数据导⼊到HDW集群中，并处理⽬标数据来⽀持他们的业务决策。
内置表
如上所述，HDW继承了Greenplum数据库丰富的数据分析功能。其中⼀个惊⼈的功能是通过访问对象存储中的原⽣数据。虽然外部表有⼀定的特点，但是与外部表相⽐，HDW基于OSS的内置表还进⼀步具有以下优势：
内置表⽀持更新/删除和索引操作。最重要的是，内置表完全⽀持ACID事务。这些特征外部表都不⽀
持。
记事作文600字内置表可以实现更好的数据压缩。⽬前，外部表⽀持三种常见的数据格式：TXT、CSV和ORC。根据我们的观察，为了简单起见，与ORC相⽐，客户通常更喜欢带有ZIP压缩算法的TXT/CSV。使⽤内置表，我们可以使⽤更复杂的编码策略（例如字典编码和变长编码）和压缩算法（例如zstd）。
内置表具有更好的查询性能。内置表的数据布局样式（⽆论是存储在内存中还是在磁盘上），都为HDW的执⾏引擎进⾏了⾼度优化。使⽤Alluxio加速OSS访问
尽管对象存储为⼤数据系统提供了很多好处，但是与块存储相⽐，它具有更低的I/O性能。⼀⽅⾯，虽然随着对象存储技术的不断发展，⽬前⼤多数对象存储服务只能够为每个HTTP连接提供100MB/s左右的GET吞吐量和40MB/s的PUT吞吐量。当启⽤多线程GET、多线程上传和数据压缩时，总体I/O吞吐量可以匹配数据库执⾏器的处理吞吐量。另⼀⽅⾯，OSS本⾝不是瓶颈的时候，在⼀个公有云环境
中，HDW集群所在软件定义⽹络（SDN）的总带宽通常存在⼀个上限，这会在HDW集群访问对象存储中的数据时限制I/O性能。其次，客户需要为每个OSS HTTP请求付费。第三，HDW⽀持各种索引算法，包括B树、位图和GiST。客户可以利⽤这些索引算法，通过扫描索引来加速查询，并在数万亿元组上实现亚秒级查询时间。另⼀个查询场景是查询低维度表。对于这些情况，OSS的吞吐量虽然不是性能瓶颈，但是其访问延迟确是⼀个很⼤的瓶颈问题。
为了解决上述问题，我们选择了Alluxio作为智能缓存层来加速I/O性能。Alluxio，原名Tachyon，是世界上第⼀个⽤于云计算分析和⼈⼯智能的数据编排技术。它连接了计算框架和存储系统，使存储层的数据更接近计算框架，允许应⽤程序通过公共接⼝连接到多个存储系统，使得数据更易于访问。Alluxio的内存第⼀的分层架构使得它能够⽐现有解决⽅案快⼏个数量级的速度访问数据。
结合使⽤HDW和Alluxio，缓存数据被平均分区到每个worker 节点上。每个HDW⽚段都将数据缓存到它的本地Alluxio worker中。Alluxio主节点与HDW主节点被部署在⼀起。所有⽤户都是通过Alluxio接⼝操作数据。HDW的⾼层存储架构如下图所⽰。
Alluxio在⼤数据⽣态系统中扮演者重要的⾓⾊。它与许多开源⼤数据系统共享类似的技术栈，包括基于Java或JVM的轻量级事务模型，这使得Alluxio与它们完美匹配。然⽽，仍然有许多分布式系统采⽤完全不同的构建理念。在接下来的部分中，我们将分享在利⽤Alluxio构建原⽣云MPP数据库时学到的经验。
C/C++原⽣客户端
Alluxio提供⼏种编程语⾔绑定，包括Java、Go和Python，还通过HTTP代理⽀持所有其它语⾔的REST接⼝。虽然开源项⽬通过使⽤JNI 调⽤原⽣Java客户端能够提供C/C++ Alluxio接⼝，但是⽬前还没有官⽅的C/C++原⽣客户端。为了提⾼系统性能、稳定性、灵活性和易维护性，我们决定为Alluxio实现⼀个原⽣C/C++客户端，⽽不是直接使⽤liballuxio。
在HashData中，我们构建了⼀个C/C++客户端liballuxio2，它通过RPC调⽤来和Alluxio服务器交互。在Alluxio不同组件之间的交互过程是基于thrift/protobuf/netty。liballuxio2作为⼀个原⽣客户端，采⽤了thrift/protobuf提供的Alluixo统⼀数据交换格式。⽬
前,liballuxio2⽀持Alluxio-1.5.0版本。
统⼀对象存储SDK
白羊座生日Alluxio作为底层⽂件系统（UFS）⽀持各种对象存储服务，包括S3、Azure Blob Store、GCS等，并提供了⼀个框架，⽤户可以通过该框架轻松地扩展它来⽀持新的对象存储。但是，我们采⽤了不同的⽅法，理由如下：
1. 不同的对象存储服务⽀持不同的访问优化策略，以获得更⾼的读写性能，包括多线程上传和流⽔线下载。构建⼀个C/C++原⽣OSS库
是利⽤这些优化机会的更好⽅法。
2. 作为⼀家初创企业，HashData希望⽀持本地公共云提供商提供的各种对象存储服务，⽽不仅仅是上述的跨国巨头。统⼀的C/C++
OSS客户端库可以⼤⼤减少研发⼯作，使得开发⼈员不必担⼼异构对象存储服务的复杂性。
3. Alluxio客户端可以使⽤委托/⾮委托模式来控制UFS操作的处理位置。在⾮委托模式下，Alluxio C/C++原⽣客户端负责OSS读写操
作。Alluxio服务器只需要维护元数据和基于缓存I/O流的块。
我们已经构建了⼀个统⼀C/C++原⽣库来⽀持本地和全球顶级云平台的对象存储服务，并且将它集成到liballuxio2库中。⽤户仍然可以选择委托模式来保留Alluxio服务器执⾏的OSS操作。
分层存储
Alluxio⽀持分层存储，以便管理除内存以外的其它存储类型。⽬前，Alluxio⽀持三种存储类型/层，包括MEM（内存）、SDD（固态驱动器）和HDD（硬盘驱动器）。
世界是公平的在开始时，我们保持默认的分层设置，例如数据⾸先缓存到MEM层，并在上层填满后迁移到SSD/HDD。但是，当我们开始使⽤⼤量数据进⾏压⼒测试时，如果MEM层中的所有⽂件都是打开的，那么缓存的数据就不能被删除。对于典型的HDW⼯作负载，MEM层的容量（为了节省成本，我们通常不会为EC机器分配太多内存）不⾜以缓存⽬标数据。因此，我们将默认的写⼊层更改为SSD。更关键的是，在数据超出本地磁盘容量的情况下，HDW数据库内核会告诉C/C++原⽣Alluxio客户端liballuxio2不要缓存哪些运⾏查询的数据。许多复杂的Alluxio读/写/缓存策略都是由HDW数据库内核动态决定的。
事务提交
婴儿如何添加辅食作为关系数据库管理系统（RDBMS），HDW完全⽀持ACID分布式事务。与许多基于HDFS的⼤数据分析系统（原⼦写是利⽤HDFS原⼦重命名特性实现的）不同的是，HDW对事务的⽀持是建⽴在数据库内核⾥的。只有当所有打开供写的⽂件都成功地持久化在对象存储上时，事务才成功提交；否则事务将中⽌，并清除所有开放可写的⽂件（包括数据）。
为了保证数据持久性，所有的Alluxio写操作都直接写到对象存储中，⽽不需要缓存。
基准测试
我们使⽤TPC基准（TPC-H）测试来评估我们的解决⽅案。TPC-H是⼀个决策⽀持基准测试集，由⼀组⾯向业务的即时查询和并发数据修改组成。查询和填充数据库的数据具有⼴泛的⾏业相关性。
这个基准测试的⽬的不是显⽰HDW对TPC-H查询的运⾏速度有多快，⽽是显⽰Alluxio提升I/O性能的有效性。因此，在接下来的基准测试中，我们将HDW的执⾏引擎设置为与开源Greenplum引擎完全相同，⽽不是私有的。此外，这项评估⼤约是在⼀年前进⾏的，使⽤的是基于Alluxio的HDW的第⼀个稳定版本，它具有与Greenplum-5.0版本相同的数据库内核版本。
配置
1. 数据集⼤⼩：100GB
2. 集群：1个主节点，8个⼦（计算）节点
礼仪的特征
3. 主节点：QingCloud超⾼性能实体，2个CPU，4GB内存
4. ⼦节点：QingCloud超⾼性能实体，4个CPU，8GB内存
5. Alluxio：1.5.0版本，每个⼯作节点内存为2GB
场景
1. Greenplum 5.0：我们选择这个版本的开源Greenplum作为基准。
中华经典美文2. HashData：HDW读取的⽬标数据是从远程对象存储缓存到Alluxio层的。
结果
根据我们的观察，OSS的I/O吞吐量⾄少⽐本地磁盘低3倍。然⽽，从这个测试结果来看，只有⼤约30%的性能下降。这是因为TPC-H是⼀个OLAP查询基准，它包含⽐I/O密集型任务更多的CPU密集型任务。通常，冷读只发⽣在第⼀次接触数据时。使⽤Alluxio缓存系统，冷读操作的数量⼤⼤减少。如图3所⽰，使⽤Alluxio缓存读取的HDW性能与传统的⾮共享MPP相同，同时⽀持使⽤对象存储的所有优点。
结论
在本⽂中，我们展⽰了通过精⼼设计的存储和缓存层，原⽣云数据仓库可以利⽤Alluxio消除对象存储的性能损失，同时享受其可伸缩性和成本效应。
