Airbnb 的数据基础架构

本篇文章4351字，读完约11分钟

今天仍然是一个技术话题。云计算，尤其是亚马逊的云服务(aws)，提供了灵活的计算能力，而不需要购买昂贵的服务器甚至计算机房。通过虚拟化主机，它还提供了丰富的支持组件，节省了运营和维护成本，并促进了扩展，这已成为许多初创企业的首选。这是airbnb在构建基于aws的数据架构时所经历的一次经验分享。正如作者刚刚所做的那样，我们都很不开心——对于数据朋友来说，天空的尽头是两颗难以学习的星星。

第1部分:数据基础设施背后的理念

在airbnb，我们倡导数据文化，并将数据作为决策的关键输入。跟踪指标、通过实验验证假设、建立机器学习模型和深入挖掘商业见解是我们快速而明智进步的关键。

经过多年的发展，我们认为数据基础设施服务是稳定、可靠和可扩展的，因此这是一个与社区分享我们经验的好机会。在接下来的几周里，我们将发表一系列的博客文章，重点介绍我们的分布式体系结构和工具组件。因为开源贡献者提供了许多我们每天都在使用的基本系统，我们不仅愿意在公共github中分享项目，而且还谈论我们在这个过程中所学到的东西。

了解一些关于我们数据基础架构的非正式想法:

看看开源世界:在开源社区中，数据基础设施有很多好的资源，我们尽力采用这些系统。此外，如果我们建立一些对自己有用和对社会有益的东西。

首选标准组件和方法:有时发明一个全新的基础架构是合理的，但在许多情况下，它不能很好地利用资源。通过直觉或采用现有的解决方案来建立一个独特的解决方案是非常重要的，并且必须通过直觉来正确地考虑维护支持的隐藏成本。

确保它可以扩展:我们发现数据和业务不会线性增长，但会随着技术人员开发新产品和采用新的业务方式而超线性增长。

倾听同事的意见，解决实际问题:与公司的数据用户沟通是理解路线图的一个重要部分。与亨利·福特的口号一致，我们必须在寻找更快的马匹和制造汽车之间保持平衡——但首先我们必须倾听客户的意见。

有一定的边际:我们超额认购资源，如集群，以促进文化的探索。让基础架构团队最大限度地提高资源利用率还为时过早，但我们的假设是，在存储领域找到新的业务机会将抵消这些额外的机器成本。

第2部分:基础设施概述

这是我们基础设施的主要组成部分的草图。

源数据进入我们的系统有两个主要渠道:源代码发送kafka事件，在线数据库导出aws rds中的存储，然后通过sqoop传输。

这里，数据源包含用户的活动事件数据和快照源数据，它们被发送到“黄金”集群存储，我们的提取、转换和加载(etl)开始。在这一步中，我们总结表并检查业务逻辑的数据质量。

在上图中，有两个独立的簇，“金”和“银”，这将在后面详细描述。分离的原因是为了确保计算和存储资源的隔离，如果其中一个出现故障，可以进行灾难恢复。该体系结构提供了一个理想的环境，最重要的任务是严格保证sla(服务保证协议)，避免资源密集型的临时查询的影响。我们将“银色”集群视为生产环境，但放松了保证，可以承受资源密集型查询。

通过两个集群，我们获得了隔离能力，并且在管理大量数据复制和维护动态系统之间的同步方面存在成本。“黄金”是我们的真正来源，我们将把“黄金”数据的每一点都复制到“白银”中。在“银色”集群上生成的数据不会被复制回“金色”，因此您可以认为这是“银色”。作为超集群集，它是单向复制方案。由于我们的许多分析和报告都是从“白银”中分发的，因此当从“黄金”中生成新数据时，我们会尽快将其复制到“白银”中，以确保其他工作不会延迟。更重要的是，如果我们在预先存在的“黄金”集群上更新数据，我们必须小心地更新它，并将其同步传播到“白银”。对于这个复制优化问题没有好的开源解决方案，所以我们建立了一套新的工具，我们将在后面详细介绍。

我们在改进hdf方面取得了巨大的成就，并且更准确地使用了蜂巢管理表作为我们的中心源数据。仓库的质量和完整性依赖于不变的数据，继承的数据可以通过重新推导来计算——使用分区的配置单元表对于这个目标是非常重要的。此外，我们不鼓励数据系统的扩散，也不想维护单独的基础架构，如我们的源数据和最终用户报告。根据我们的经验，这些中间系统混淆了事实的来源，增加了etl的管理负担，并且使得从原始数据中跟踪迭代指标变得困难。我们不运行甲骨文、teradata、vertica、红移等。，但是使用presto对由hive管理的所有表进行临时查询。我们都希望在不久的将来把普雷斯托和塔劳联系起来。

图中需要注意的其他事情，包括airpal，使用presto来支持基于web查询执行的工具，我们建立并打开了源代码。这是数据仓库中的一个临时sql查询，超过三分之一的员工使用这个工具来运行查询主界面。作业调度功能是气流，一个用于编程、调度和监控的平台，可以在hive、presto、spark和mysql的数据管道中运行。我们在集群之间逻辑地共享气流，但是物理作业在适当的集群机器上运行。火花簇是工程师和数据科学家在机器学习中更喜欢的另一种处理工具，它对流处理非常有用。你可以在aerosolve查看我们在机器学习方面的努力。S3是一个独立的存储系统，我们可以从hdfs数据中获得廉价的长期存储。配置单元管理的表可以为自己存储更改并指向s3文件，这使得访问和管理元数据变得容易。

第3部分:hadoop集群的详细发展

今年，我们从被称为“小指和大脑”的结构不良的群体中迁移出来，并将其放入上述“金银”系统中。两年前，我们从amazon emr迁移到在HDFS运行的一组ec2实例，其中包含300 TB数据。如今，我们有两个独立的hdfs集群，数据容量为11 pb，s3存储容量为pb。有了这个背景，让我们来解决这个问题:

1)在mesos架构上运行独特的hadoop

早期的airbnb工程师在一个名为mesos的平台上，该平台规定了跨多台服务器部署的配置。我们在aws上使用单个c 3.8 x大型集群。每个桶是3t ebs，运行所有hadoop、hive、presto、chronos和马拉松。

明确地说，许多公司使用中型企业实施创新解决方案来管理大型和重要的基础设施。然而，我们的小团队决定运行更加标准化和无处不在的部署，减少我们在操作和调试上花费的时间。

介子上的Hadoop问题；

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

集群健康很少见

Hadoop只能在中间层运行mr1

任务跟踪器竞赛的性能问题

集群利用率低

高负载、难以调试的系统

缺乏集成的kerberos安全性

解决方案:答案就是简单地转移到“标准”堆栈。我们很乐意学习运营数百或数千家公司的大型集群，而不是试图创造新的解决方案。

2)远程读写

在通过将hdfs数据存储在ebs(弹性块存储)上来访问所有HDFS数据之前，我们将它发送到公共亚马逊ec2以运行查询网络数据。

Hadoop是为特定硬件构建的，并且预先在本地磁盘上读写，因此这是一种设计不匹配。

至于远程读写，我们错误地选择了aws来将我们的数据存储划分为三个不同的可用性区域，它们在一个区域中。每个空闲区域都被指定为自己的“机架”，并且三个副本存储在不同的机架中，因此总是会发生远程读写操作。这是另一个设计缺陷，导致数据传输速度慢。当机器丢失或损坏数据块时，远程复制随时都会发生。

解决方法:使用本地存储的特殊实例，并在可用性区域运行它，而不是让ebs解决这些问题。

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

查看我们的工作负载，我们发现我们的组件有不同的要求。我们的hive/ hadoop/ hdfs机器需要大量存储空间，但它不需要太多内存或cpu。普雷斯托和斯帕克渴望内存和高处理能力，但他们不需要太多的存储。运行c3.8xlarge至3tb ebs已证明非常昂贵，并且是一个限制因素。

解决方案:一旦我们迁移了mesos体系结构，我们就可以选择不同类型的机器来运行各种集群，比如使用r 3.8x大型实例来运行spark。亚马逊发布了新一代“D系列”的一个例子，我们正在对其进行评估，从成本的角度来看，这种转变更可取。将C38 XLARGE机器上每个节点的3tb远程存储改为d2.8xlarge机器上的48tb本地存储非常有吸引力，这将在未来三年为我们节省数百万美元。

4)hdfs联盟

我们一直在运行federationhdfs集群，数据共享物理块池，但每个逻辑集群都将映射器和缩减器集分开。这允许我们通过查询访问任何数据，并改善最终用户体验。然而，我们发现联邦没有得到广泛的支持，并且被一些专家认为是实验性的和不可靠的。

解决方案:移动到完全不同的hdfs节点，而不是运行联合，以实现机器级别的真正隔离，这也提供了更好的灾难恢复机制。

5)系统监控很麻烦

独特的基础设施系统最严重的问题是创建自定义的监控和报警集群。Hadoop、hive和hdfs是复杂的系统，容易出现许多故障。试图预测所有的故障状态并设置合理的阈值是非常具有挑战性的。

解决方案:我们签署了cloudera的支持合同，并利用他们的专业知识获得了这些大型系统的结构和操作，最重要的是，通过使用cloudera的管理工具减轻了我们的维护负担。进入我们的内部系统大大减轻了我们的监控和报警负担，因此我们花在系统维护和报警上的时间非常少。

结论

评估旧集群中的错误和低效，并开始系统地解决这些问题。迁移pb数据和数百个用户作业是一个漫长的过程，因为它不会破坏我们现有的服务；我们将分别向开源社区贡献一些工具。

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

最后，因为我们有机会在“黄金和白银”系统中建立新的体系结构，构建所有新实例，并以合理的方式添加iam角色来管理安全性。这意味着在集群之上提供更复杂的访问控制层，并以集成的方式管理我们所有的机器。

我们可以大幅削减成本，同时提高性能。以下是一些数据:

磁盘读/写从70-150兆字节/秒增加到400多兆字节/秒

蜂巢的中央处理器效率提高了？两次

网卡可以完全运行我们的机器

读取吞吐量？三倍改进

写吞吐量？两倍改进

将成本降低70%

http://media/Airbnb-engineering/data-infra structure-at-Airbnb-8 adfb 34 f 169 c # . d1d 0l 7 bee

原文作者:董老师，如有转载，请注明出处

“读完这篇文章还不够吗？如果你也开始创业，希望你的项目被报道，请点击这里告诉我们！”