第1部分：数据基础设施的背后哲学 了解我们数据基础设施的一些非正式理念： 确保它能够扩展：我们发现数据与业务不是线性增长，但随着技术员工建立新的产品和在业务采取新方式后，将超线性增长。 留有一定的余量：我们超额认购资源如集群，促进探索的文化。对基础设施团队实现资源利用最大化还高兴的太早，但我们的假设是，在存储中发现了一个新的商业机会将抵消了这些额外的机器费用。 第2部分：基础设施概况 这里数据源包含用户的活动事件数据和快照源数据，发送到"金"集群存储，并开始运行我们的提取，转换和加载（ETL）。在此步骤中，我们针对业务逻辑，汇总表格，并执行数据质量检查。 在上面的图中，有"金"和"银"两个独立集群，我们将在后面详细描述。分离原因是保证计算和存储资源的隔离，如果一个挂了可以做灾难恢复。这种架构提供了一个理想环境，最重要的工作严格保障SLA（服务保证协议），避免资源密集型即席查询的影响。我们把'银'集群作为一个生产环境，但是放宽保证，可以承受资源密集型查询。 通过两个集群我们获得隔离力量，在管理大量的数据复制并维持动态系统之间有同步的成本。"金"是我们的真正来源，我们将复制"金"数据的每一位到"银"。"银"集群上生成的数据不会被复制回"金"，所以你可以认为这是"银"作为一个超集集群，是单向复制方案。因为我们的很多分析和报告从"银"簇发，当"金"有新数据产生，我们尽快复制它到"银"，去保证其他工作刻不容缓运行。更关键的是，如果我们更新预先存在的"金"集群上的数据，我们必须小心的更新并同步传播给"银"。这种复制优化问题并没有一个开源的很好解决方案，所以我们建立了一套新的工具，我们会以后更详细地介绍。 我们改进HDFS已经取得了很大效果，并更准确地用Hive管理表，作为我们中心源的数据。仓库的质量和完整性取决于数据不变的，继承数据可通过重新推导计算的 �C 使用分区Hive表对这个目标非常重要。此外，我们不鼓励数据系统的扩散，不希望维护单独的基础设施，比如我们的源数据和我们终端用户报告。根据我们的经验，这些中间系统混淆真理的来源，增加ETL的管理负担，难以跟踪从原始数据一路上来自的迭代指标。我们不跑Oracle，Teradata，Vertica，Redshift等，而是使用Presto对所有Hive管理的表做即席查询。我们都希望在不久的将来，联通Presto和Tableau。
Read full article from Airbnb的数据基础架构 | 36大数据
No comments:
Post a Comment