Airbnb 数据基础设施与其背后的哲学

在 Airbnb 我们提倡数据文化并使用数据作为关键输入去决策。跟踪指标，通过实验验证假设，建立机器学习模型和深入挖掘商业洞察是我们快速聪明前进的关键。经过多年的进化，我们觉得数据基础设施服务稳定，可靠，可扩展，因此是一个很好的机会来分享我们的经验给社区。

这第一篇关于 Airbnb。云计算尤其亚马逊的云服务(AWS)提供弹性计算能力，无需购买昂贵服务器甚至机房，通过虚拟化主机，还提供丰富配套组件，节约运维成本，方便扩展，成为很多创业公司的首选。这里 Airbnb 工程师 James Mayfield 以 AWS 作为基础搭建数据架构中走过的坑和经验分享，由于笔者也刚好做过，难度 2 星，供做数据的朋友学习。

第 1 部分：数据基础设施的背后哲学

在 Airbnb 我们提倡数据文化并使用数据作为关键输入去决策。跟踪指标，通过实验验证假设，建立机器学习模型和深入挖掘商业洞察是我们快速聪明前进的关键。

经过多年的进化，我们觉得数据基础设施服务稳定，可靠，可扩展，因此是一个很好的机会来分享我们的经验给社区。在接下来的几周内，我们将发布一系列突出我们的分布式架构和工具组件的博客文章。由于开源贡献者提供了许多我们每天使用的基础系统，使我们不仅乐意分享在公共 GitHub 的项目，而且还会聊我们一路上学到的东西。

了解我们数据基础设施的一些非正式理念：

放眼开源世界：在开源社区中数据基础设施有很多好的资源，我们尽量采用这些系统。此外，如果我们建立一些对自己有用又对社有回报的东西。

首选标准组件和方法：有些时候是发明一种全新的一块基础设施是合理的，但很多时候，这没有很好的利用资源。建立一个独特解决方案是靠直觉还是采用现有的是非常重要的，而靠直觉必须正确考虑维护支持的隐性成本。

确保它能够扩展：我们发现数据与业务不是线性增长，但随着技术员工建立新的产品和在业务采取新方式后，将超线性增长。

通过倾听你的同事解决实际问题：与公司的数据用户沟通是了解路线图的重要组成部分。与亨利·福特的口号一致，我们必须在找更快的马与造汽车上保持平衡 – 但首先要听你的客户。

留有一定的余量：我们超额认购资源如集群，促进探索的文化。对基础设施团队实现资源利用最大化还高兴的太早，但我们的假设是，在存储中发现了一个新的商业机会将抵消了这些额外的机器费用。

第 2 部分：基础设施概况

这里是我们的基础设施的主要部件的简图。

源数据进入我们的系统有两个主要渠道：源代码发送 Kafka 事件和线上数据库将 AWS RDS 中的存储导出，再通过 Sqoop 传递。

这里数据源包含用户的活动事件数据和快照源数据，发送到 “金” 集群存储，并开始运行我们的提取，转换和加载(ETL)。在此步骤中，我们针对业务逻辑，汇总表格，并执行数据质量检查。

在上面的图中，有 “金” 和 “银” 两个独立集群，我们将在后面详细描述。分离原因是保证计算和存储资源的隔离，如果一个挂了可以做灾难恢复。这种架构提供了一个理想环境，最重要的工作严格保障 SLA(服务保证协议)，避免资源密集型即席查询的影响。我们把 ‘银’ 集群作为一个生产环境，但是放宽保证，可以承受资源密集型查询。

通过两个集群我们获得隔离力量，在管理大量的数据复制并维持动态系统之间有同步的成本。“金” 是我们的真正来源，我们将复制 “金” 数据的每一位到 “银”。“银” 集群上生成的数据不会被复制回 “金”，所以你可以认为这是 “银” 作为一个超集集群，是单向复制方案。因为我们的很多分析和报告从 “银” 簇发，当 “金” 有新数据产生，我们尽快复制它到 “银”，去保证其他工作刻不容缓运行。更关键的是，如果我们更新预先存在的 “金” 集群上的数据，我们必须小心的更新并同步传播给 “银”。这种复制优化问题并没有一个开源的很好解决方案，所以我们建立了一套新的工具，我们会以后更详细地介绍。

我们改进 HDFS 已经取得了很大效果，并更准确地用 Hive 管理表，作为我们中心源的数据。仓库的质量和完整性取决于数据不变的，继承数据可通过重新推导计算的 – 使用分区 Hive 表对这个目标非常重要。此外，我们不鼓励数据系统的扩散，不希望维护单独的基础设施，比如我们的源数据和我们终端用户报告。根据我们的经验，这些中间系统混淆真理的来源，增加 ETL 的管理负担，难以跟踪从原始数据一路上来自的迭代指标。我们不跑 Oracle，Teradata，Vertica，Redshift 等，而是使用 Presto 对所有 Hive 管理的表做即席查询。我们都希望在不久的将来，联通 Presto 和 Tableau。

其他的一些在图中要注意的东西，包括 Airpal，使用 Presto 支持基于 Web 查询执行的工具，我们搭建并开源了。这是在数据仓库即席 SQL 查询，1/3 以上的所有员工都使用该工具运行查询主界面。作业调度功能就是通 Airflow，一个以编程方式编写，调度和监控的平台，可以运行在 Hive，Presto，Spark，MySQL 的数据管道等。我们在逻辑上跨集群共享 Airflow，但物理作业运行在合适的集群机器上。Spark 集群是工程师和数据科学家机器学习工作偏爱的另一处理工具，对流处理非常有用。你可以在 Aerosolve 查看我们在机器学习上的努力。 S3 是一个独立的存储系统，我们可以从 HDFS 数据得到便宜的长期存储。Hive 管理的表可以对自己存储改变，并指向 S3 的文件，容易访问和管理元数据。

第 3 部分：Hadoop 集群的详细演化

今年我们从架构不佳的集群上进行迁移，被称为 “Pinky 与 Brain”，放到上述的 “金银” 系统中去。两年前，我们从 Amazon EMR 移到一组运行在 HDFS 300 TB 数据的 EC2 实例。今天，我们有两个独立的 HDFS 集群，数据 11 PB，我们 S3 存储 PB 级别。有了这样的背景，我们来解决问题：

1)在 Mesos 架构上运行一个独特的 Hadoop

早期的 Airbnb 工程师们在一个叫做 Mesos 上，其中规定了部署跨多个服务器的配置。我们使用 AWS 上 c3.8xlarge 的单一集群。每个 bucket 是 3T 的 EBS，并跑了所有的 Hadoop，Hive，Presto，Chronos 的，和 Mesos 上的 Marathon。

需要明确的是，许多公司都使用 Mesos 实施新颖的解决方案来管理大型重要基础设施。但是，我们的小团队决定运行更加规范，无处不在的部署，减少我们花在运营和调试的时间。

Mesos 上 Hadoop 问题：

很少能见到工作运行和日志文件

很少能见到集群健康状态

Hadoop 在 Mesos 只能运行 MR1

Task Tracker 竞争的性能问题

集群的低利用率

高负荷，难调试系统

缺乏整合 Kerberos 安全

解决方法：答案是简单地转移到一个 “标准” 栈。我们很乐意从数百或数千公司学习操作大型集群，而不是试图去创造一种新的解决方案。

2)远程读取和写入

之前通过存储在 EBS(弹性块存储)上访问我们所有 HDFS 数据，我们发送到公共 Amazon EC2 运行查询网络数据。

Hadoop 是为特定硬件搭建，预先在本地磁盘读写，所以这是一个设计不匹配。

关于远程读写，我们曾错误地选择了 AWS 在三个不同的可用性区域分割我们的数据存储，而它们在一个区域内。每个可用区被定为自己的 “机架”，3 个副本分别存放在不同的机架，因此远程读写操作都不断发生。这又是一个设计缺陷，导致缓慢的数据传输，当一台机器丢失或损坏块时候，远程拷贝就随时发生。

解决方法：使用本地存储专门实例，并在一个可用性区域中运行，而不是让 EBS 修正这些问题。

3)同构机器上工作负载的异构

纵观我们的工作量，我们发现，我们的构件有不同的要求。我们的 Hive/ Hadoop/ HDFS 机器需大量的储存空间，但并不需要多少内存或 CPU。Presto 和 Spark 渴望内存和高处理能力，但并不需要多大的存储。通过 3TB EBS 支持运行 c3.8xlarge 被证明是存储非常昂贵，也是限制因素。

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

4)HDFS Federation

我们一直在运行Federation HDFS 集群，数据共享物理块池，但每个逻辑集群分离 mapper 和 reducer 集合。这让我们可以通过 query 查询访问任何一块数据，提高终端用户体验，但我们发现，Federation 并没有得到广泛的支持，被某些专家认为是实验性和不可靠的。

解决方法：移到一个完全不同的 HDFS 节点，而不是运行 Federation，做到在机器水平的真正隔离，这也提供了更好的灾难恢复机制。

5)系统监控是累赘

一个独特的基础设施体系最严重的问题是创建自定义监视和报警集群。 Hadoop，Hive，HDFS 是复杂的系统，容易发生众多故障。试图预测所有故障状态，并设置合理的门槛是相当有挑战性。

解决方法：我们签了 Cloudera 的支持合同，用他们的专业知识来获得在架构和操作这些大型系统，以及最重要的通过使用 Cloudera 的管理器工具，减少我们的维护负担。接入到我们内部系统，大大减少了我们的监控和报警负担，这样我们花很少的时间进行系统维护和警报。

结论

在我们旧的集群上评估错误和低效率，开始着手系统地解决这些问题。去迁移 PB 数据和数百个用户作业是一个漫长的过程，因为还不破坏我们现有服务;我们将单独把一些工具贡献给开源社区。

现在，迁移完成后，我们已经大大减少了平台事故和故障的数量。不难想象我们在不成熟的平台上处理的 bug 和问题，但系统现在基本上是稳定的。另一个好处是，当我们雇佣新工程师加入我们的团队，上手很快因为系统也被其他公司采用。

最后，因为我们有机会在 “金银” 系统去设置新鲜的架构，搭建所有新实例，用合理的方式添加 IAM 角色来管理安全性。这意味着在集群之上提供更为精密的访问控制层，集成管理我们所有的机器。