3　大数据平台架构

Airbnb公司拥有世界一流的客户服务和日益增长的用户社区，随着业务日益复杂，大数据平台的开发和建设成为其运营的重要支撑。经过深入的分析和研究之后，Airbnb公司确立了自身的大数据平台架构。

3.1　开发思想

Airbnb公司本质上是一家数据驱动的短期住宿租赁服务提供商，对大数据的需求和应用随着企业的扩张而快速提升。Airbnb公司提倡数据的全面融合和综合利用，凡事必须以数据说话。经过多个版本的迭代之后，Airbnb大数据架构栈基本达到了稳定、可靠和可扩展的要求，支撑了业务的快速增长。

Airbnb大数据平台的开发体现了以下五个方面的思想：

（1）关注开源社区：在开源社区有很多大数据架构方面优秀的资源，需要去充分利用这些已有的资源和成果。同样，当Airbnb公司开发了有用的项目也必须回馈给开源社区，这样会形成良性循环。

（2）采用标准组件和方法：有时候自己从头开始并不如使用已有的更好资源，当凭直觉去开发出一种“与众不同”的方法时，需要考虑维护和修复这些程序的隐性成本。

（3）确保大数据平台的可扩展性：企业的数据已不仅仅是随着业务线性增长，而是爆发性增长，必须确保大数据平台能满足这种业务的增长。

（4）倾听各方的反馈以解决不同的问题：虚心听取企业数据的使用者和外部用户的反馈意见是架构路线图中非常重要的一步，一定程度上决定着大数据平台的成败。

（5）预留必要资源：必须充分考虑到业务快速发展的需要，为未来一定时期的发展留下重组的资源容量。

3.2　大数据架构

Airbnb公司的数据源主要来自两个方面：一是数据埋点（“埋点”是针对特定用户行为或事件进行捕获、处理和发送的相关技术及其实施过程）发送事件日志到Kafka；二是MySQL数据库dumps存储在AWS的RDS，通过数据传输组件Sqoop传输到Hive金集群，包括用户行为以及纬度快照的数据发送到Hive金集群存储，并进行数据清洗和业务逻辑计算，聚合数据表，并进行数据校验。图4-4为Airbnb大数据平台架构。

如图4-4所示，Hive集群被区分为金集群和银集群，旨在将数据存储和数据处理进行分离，确保能在灾难时进行恢复。金集群和银集群的区别如下：金集群运行着核心的作业和服务，银集群提供一个作为产品的环境；金集群存储的是原始数据，然后复制金集群上的所有数据到银集群，在银集群上生成的数据不会再复制到金集群，银集群是所有数据的一个超集。

由于Airbnb大数据平台的大部分数据分析和报表都出自银集群，所以必须保证银集群能够无延迟的复制数据。与此同时，对于金集群上已存在的数据进行更新也必须实时同步到银集群。在HDFS（Hadoop Distributed File System，基于Hadoop的一种分布式文件系统）存储和Hive表的管理方面，Airbnb大数据平台也作了不少优化。Airbnb公司不提倡建立不同的数据系统，也不主张单独为数据源和终端用户报表维护单独的架构。Airbnb大数据平台采用Presto来查询Hive表，代替Oracle、Teradata、Vertica、Redshift等，下一步希望可以直接用Presto连接Tableau。

在架构图中的Airpal是Airbnb公司用户基于数据仓库的即席SQL查询接口，任务调度系统Airflow可以跨平台运行Hive、Presto、Spark、MySQL等Job，并提供调度和监控功能。Spark集群是工程师和数据分析师偏爱的工具，可以提供机器学习和流处理。S3作为一个独立的存储系统用于存储从HDFS上收回的部分数据，并更新Hive表指向S3文件，这样既可以减少存储的成本，又便于数据访问和优化元数据管理。

3.3　集群演化

Airbnb公司有两个独立的HDFS集群，存储的数据量达数十PB，S3上也存储了数个PB的数据。下面是该公司遇到的主要问题和解决方案：

3.3.1　基于Mesos运行Hadoop

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

（1）Job运行和产生的日志不可见；

（2）Hadoop集群的健康状态不可见；

（3）Mesos只支持MR1；

（4）Task Tracker连接导致性能问题；

（5）系统的高负载，并很难定位；

（6）不兼容基于Hadoop安全认证Kerberos。

解决方法：直接采用其他大公司的解决方案，结合自身的业务需求作一定的优化改进。

3.3.2　远程数据读写

Hadoop集群数据分成三个部分存储在AWS一个分区3个节点上，每个节点都在不同的机架上，导致一直在远程读写数据，从而会在数据移动或者远程复制的过程中出现丢失甚至直接崩溃的情形。

解决方法：使用本地存储，并运行在单个节点上，确保数据能快速读取，高效运行。

3.3.3　在同构机器上混布任务

整体的架构中存在两种完全不同的需求配置：Hive/Hadoop/HDFS是存储密集型，基本不耗内存和CPU；而Presto和Spark是耗内存和CPU型，对存储的需求不高。为了降低成本、提升效率，需要在同构机器上对任务进行混布。

解决方法：迁移到Mesos计算框架后，选择不同类型的机器运行不同的集群，这一改进的结果是给Airbnb公司节约了上亿美元。

3.3.4　HDFS的联合

早期Airbnb大数据平台采用数据存储共享，但在每个集群上逻辑是独立的，导致用户访问数据时需要在两个集群都查询一遍，这样不仅效率低，而且运行也很不稳定。

解决方法：迁移数据到各HDFS节点，上升到机器水平的隔离性，以更好地支持容灾。

3.3.5　繁重的系统监控

个性化系统架构都需要自己开发独立的监控和报警系统，导致开发和运行都费时、费力。Hadoop、Hive和HDFS都是复杂的系统，要开发相应的监控和报警系统，并能高效地运行，这是一项非常具有挑战性的工作。

解决方法：通过和大数据公司Cloudera签订协议获得了专家在架构和运维等方面的支持，Cloudera公司提供的Manager工具减少了监控和报警的业务量，大大提升了效率。

3.4　应用成效

Airbnb大数据平台的演化给企业节省了大量的成本，并且有效地优化了集群的性能，下面是一组应用成效的数据：

（1）磁盘读写数据的速度从70～150MB/s上升到400+MB/s；

（2）Hive任务提高了2倍的CPU时间；

（3）读吞吐量提高了3倍；

（4）写吞吐量提高了2倍；

（5）成本减少了70%。

Airbnb大数据平台从不断扩展的业务需求出发，经过不断的探索逐步成形，成为行业发展的领跑者。