深入浅出，详解Airbnb数据架构

本文来自Medium分享文章，英文原文链接可以在底部看到。原文由Airbnb的工程师James Mayfield, Krishna Puttaswamy, Swaroop Jagadish, Kevin Long联合撰写，深入浅出地介绍了Airbnb的数据架构。

第一部分：数据架构背后的哲学

Airbnb提倡数据信息化，把数据作为决策的重要依据。追踪指标，假设检验、构建机器学习模型和深入挖掘商业机会使得Airbnb一直保持了高速成长。

经过多版本迭代之后，我们认为Airbnb的数据架构栈已经具有稳定、可靠和可扩展性等特性。我们觉得应该把这些构建Airbnb数据架构的经验回馈给社区。开源贡献者提供了我们每天使用的许多基础系统，我们非常乐意不仅回馈公共GitHub repo中的优秀项目，而且还要讲述我们在使用过程中学到的东西。

下面基于Airbnb数据架构构建过程的经验，给出一些我们自己的哲学。

多关注开源社区：在开源社区有很多数据架构方面优秀的资源，需要去学习这些系统。同样，当我们自己开发了有用的项目也最好回馈给社区，这样才会有良性循环。

多采用标准组件和方法：虽然有时候创建一个新的组件也是必要的，但更多的时候与其自己重复造轮子还不如充分利用已有的优秀资源。当你凭直觉想去开发出一种独特的方法时，你得考虑维护和支持这些程序的隐性成本。

确保数据的可扩展性：我们发现数据并不是随着业务发展线性增长的，随着技术人员开始开发新产品并在业务增长的基础上记录新活动，数据是爆炸式增长的。

通过聆听同事的意见来解决真正的问题：聆听公司里的数据使用者的反馈是架构路线图中非常重要的一步。按照亨利·福特的箴言，我们必须在制造更快的马和制造汽车之间取得平衡——但首先要倾听你的客户。

预留多余资源：集群资源的超额配置让我们培养了一种探索无限可能的文化。对于架构团队来说，经常沉浸在早期资源充足的兴奋中，但我们总是假设数据仓库的新业务总是需要更多的机器资源。

第二部分：数据架构概述

这是一个Airbnb数据架构的简化示意图，显示了我们的架构堆栈的主要组件。

Airbnb数据源主要来自两个渠道：在代码中埋点，通过Kafka发送事件；通过RDS上的AWS PITR (AWS point-in-time-restore)获取的生产数据库转储，然后通过Sqoop交付。

包含用户活动事件数据和维度快照的源数据随后被发送到Gold集群，在那里我们存储数据并开始执行提取、转换和加载作业。在这一步中，我们进行业务逻辑计算，生成汇总表和检查数据质量。

在上图中，有两个独立的Gold集群和Silver集群，我们将在后面更详细地描述它们。这种分离的主要原因是为了保证计算和存储资源的隔离，而且如果发生中断，它可以提供灾难恢复保证。在这种架构下，最关键的作业可以在严格的保证和服务级别协议下运行在Gold环境中，它们不受资源密集的临时查询所引起的任何干扰。我们也把Silver集群看作是一个生产环境，但是降低了保证，确保能承受资源密集型查询的爆发。

请注意，虽然这样的架构起到了隔离的作用，但它的代价是需要管理大量数据复制和保持动态系统之间的同步。Gold集群是我们的真实数据的来源，我们将所有数据从Gold集群复制到Silver集群，但在Silver集群上产生的数据不会被复制回Gold集群，因此可以将这种方式视为一种单向复制方案，我们将Silver集群作为所有数据的超集。因为我们的许多分析和报告都建立在Silver集群上，所以当新的数据进入Gold集群，我们必须立即把数据从Gold集群复制到Silver集群，以确保所有运行在Silver集群的用户作业用到的数据是没有延迟。更重要的是，如果Gold集群上的数据发生了变更，也必须立马通知Silver集群并将变更传递过去。这类复制的优化在现有开源项目中找不到很好的解决方案，因此我们实现了一套新的工具，我们将在后面的文章中详细描述这些工具。

我们在处理HDFS方面下了大功夫，尤其是更加精确地处理作为数据主要源和接收器的Hive托管表。数据仓库的质量和完整性取决于数据的不可变性，所有数据的派生都可以使用Hive托管表的分区进行重现，这一点非常重要。此外，我们不提倡建设不同的数据系统，也不希望维护位于源数据和终端用户报告之间的独立架构。我们的经验告诉我们这些中间系统很容易混淆了数据真正的来源，增加了ETL管理的负担，并使我们想通过仪表盘回溯源数据的难度大大增加。我们用Presto执行几乎所有针对Hive托管表的临时查询，而不是Oracle、Teradata、Vertica、Redshift等。我们希望在不久的将来将Presto直接连接到Tableau上。

还有几点需要注意。首先是上图中的Airpal，它是我们开发的一个基于Presto的web查询工具，目前已经开源。Airpal是用户对数据仓库的临时SQL查询接口，有超过1/3的Airbnb同事在使用此工具进行查询。然后是Airflow，它是一个作业调度系统，除了提供调度和监控功能，还可以跨平台运行Hive，Presto，Spark，MySQL等平台的作业。逻辑上是跨集群共享Airflow，但是物理上Airflow调度作业是在对应的集群、机器和worker上运行的。接下来是Spark集群，它是机器学习工程师和数据科学家钟爱的工具，可以提供机器学习和流处理。最后S3作为一个独立的存储，数据仓库团队从HDFS上取回部分数据，这样可以减少存储的成本。可以通过更新Hive托管表来指向S3文件，以便访问数据和元数据管理。

第三部分：详述我们Hadoop集群的进化

我们在今年进行了大规模迁移，从一个名为“Pinky and Brain”的糟糕集群迁移到Gold和Silver集群。为了后续扩展性，两年前迁移Amazon EMR到一组运行HDFS的EC2实例上，其中包含300 TB数据。现在，我们有两个独立的HDFS集群，存储的数据量达11PB。S3上也存储了好几PB数据。

下面是遇到的主要问题和对应的解决方案：

在Mesos框架上运行Hadoop

一些早期Airbnb工程师很喜欢一个名为Mesos的框架，便使用这个架构开始在许多服务器上部署配置。搭建了一个AWS 的c3.8xlarge机器集群，每台机器分配了3TB的EBS(elastic block storage)。在Mesos上运行所有Hadoop、 Hive、Presto、 Chronos和Marathon。

不得不说，许多公司对Mesos委以重任，并采用新颖的解决方案来管理运行重要架构的大型机器。但是，我们的团队决定运行更标准更普适的部署方式来减少我们在操作和调试上花费的时间。

基于Mesos的Hadoop集群遇到的问题：

- 作业的运行和日志文件不可见

- Hadoop集群健康状态不可见

- Mesos只支持MR1

- task tracker连接导致性能问题

- 集群利用率低

- 系统的高负载并很难定位

- 没有集成安全认证Kerberos

解决方法：转向“标准”栈，我们选择了其他运维大型集群的公司都在使用的解决方案，而不是自己造轮子。

远程读数据和写数据

把所有的HDFS数据都存储在EBS，通过Amazon EC2网络来查询。Hadoop是基于商用硬件搭建，预先在本地磁盘读写，所以这是一个设计错误。

我们错误地选择了在AWS中将数据存储划分为三个独立的可用区域AZ(都在一个区域内)。此外，每个可用区域被指定为它自己的机架，因此3个副本存储在不同的机架上，远程读取和写入经常发生。这又是一个设计缺陷，一旦机器丢失或块损坏，就会导致数据传输缓慢和远程复制。

解决方法：使用本地存储的实例以及在单一可用性区域中运行。

同构机器上的异构工作

纵观我们的工作负载，发现我们的组件有不同的需求。Hive/ Hadoop/ HDFS机器需大量的储存空间，但并不需要多少内存或CPU。Presto和Spark则需要大量内存和处理能力，但并不需要很多存储。用3TB EBS来支持c3.8xlarge的运行显然是笔亏本的买卖，因为存储正是我们紧缺的资源之一。

解决方法：一旦我们迁移出Mesos架构，我们就能选择不同类型的机器运行各种集群，例如使用r3.8xlarge实例运行Spark。Amazon正好发布了新一代“D系列”的实例，这使得我们的迁移成本更加低廉。从c3.8xlarge机器每个节点的3TB远程存储变为d2.8xlarge机器上48TB本地存储是非常有吸引力，这会为我们在未来三年节省了数百万美元。

HDFS Federation

早期我们使用了Pinky和Brain两个集群联合，其中数据保存在共享的物理块池中，而mappers和reducers在每个集群上是逻辑独立的。这样用户可以通过Pinky查询或Brain查询访问任意数据。但不幸的是，这种集群联合没有得到广泛的支持，运行起来也并不稳定。

解决方法：把数据转移到一组完全不同的HDFS节点，而不是联合运行，使我们能够在机器级别真正地隔离集群，这也提供了更好的灾难恢复范围。

繁重的系统监控

定制的系统架构的严重问题之一是需要自己开发监控和报警系统。Hadoop、Hive和HDFS都是复杂的系统，经常出现各种bug。试图跟踪所有失败的状态，并能设置合适的阈值是一项非常具有挑战性的工作，这又是一个典型的重复制造轮子的例子。

解决方法：通过和Cloudera公司签订协议，获得该公司专家在架构和运维这些大型系统的支持。Cloudera的管理工具大大减少我们维护的负担，尤其是把它与我们的Chef recipes打通后，减少了监控和报警的工作。

总结

我们分析了旧的集群存在的问题和低效率后，开始系统地解决这些问题。迁移PB级别的数据和数百个用户作业，而不影响Airbnb正常业务的进行，这是一个漫长的过程。、

迁移已经完成，平台中发生的事件和中断的数量也大大减少了。不难想象，在不成熟的平台上运行自定义的堆栈时，我们要处理的bug数量和问题的数量是巨大的，但这个系统现在已经经受住考验，可以说基本上稳定了。迁移的另一个好处是当我们团队招聘新工程师时，他们上手很快，因为我们使用的这些系统与其他公司采用的系统相似。

最后，因为我们有机会在新的Gold集群和Silver集群设置中构建新的架构，搭建新的实例，以合理的方式添加IAM角色来管理安全性，这意味着在集群之上构建了一个更加合理的访问控制层，并集成到我们管理所有机器的方式中。

这些改变为公司减少了大量成本，并且优化集群的性能，下面是一些统计数据：

- 磁盘读写数据的速度从70-150 MB / 秒到400 + MB /秒。

- Hive作业的CPU效率提高2倍。

- 在恰当的情况下，机器上的网络可以完全饱和。

- 读吞吐量提高了三倍。

- 写吞吐量提高了两倍。

- 成本减少了70%。

广告时刻：想找码农工作但是简历缺项目？加入CS503全栈开发实战精品班，三个月内快速积累四个工业级项目经验，让你的简历在求职中脱颖而出！点击阅读原文查看。

原文地址：

https://medium.com/Airbnb-engineering/data-infrastructure-at-Airbnb-8adfb34f169c