笔者准备整理一个系列,把最新的硅谷科技公司的技术带给国内朋友,在计划中的有 Airbnb,Uber,Pinterest,Facebook,Twitter ,Netflix ,Docker, Cloudera,Slack,Quip,Optimizely,Coursera,Quora,Databricks,Tachyon,Confluent 等。
这第一篇关于 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。