硅谷企业的大数据平台架构什么样？看看Twitter、Airbnb、Uber的实践

导读：本文分析一下典型硅谷互联网企业的大数据平台架构。

作者：彭锋 宋文欣 孙浩峰

来源：大数据DT（ID：hzdashuju）

01 Twitter的大数据平台架构

Twitter是最早一批推进数字化运营的硅谷企业之一，其公司运营和产品迭代的很多功能是由其底层的大数据平台提供的。图7-2所示为Twitter大数据平台的基本示意图。

▲图7-2 Twitter大数据平台架构

Twitter的大数据平台开发比较早，很多组件是其内部开发的，后面都有开源组件来对应。

• Production Hosts：直接服务用户的生产服务器，也就是业务系统。

• MySQL/Gizzard：用户关系图存在于Twitter的大规模MySQL分布式集群中，使用单个MySQL作为存储单位，在上面增加一层分布式协调数据分片（sharding）和调度的系统。

• Distributed Crawler, Crane：类似于Sqoop和DataX的系统，可以从MySQL中将业务数据导出到Hadoop、HBase、Vertica里，主要用Java编写。

• Vertica：大规模分布式数据处理系统（MPP），可以理解为一个以OLAP为主要任务的分布式数据库，主要用于建设数据仓库。类似的商业产品有Teradata、Greenplum等，类似的开源工具有Presto、Impala等。

• Rasvelg：基于SQL的ETL工具，主要用于数据清洗、治理和数据仓库建设。

• ScribeAggregators：日志实时采集工具，类似于Flume和Logstash，主要目的是将日志实时采集到Hadoop集群中（图7-2中的RT Hadoop Cluster）。

• Log Events：主要是将客户端埋点的数据或其他需要实时处理的数据写入各种消息中间件中。

• EventBus、Kafka、Kestrel queue：Kafka是开源的消息中间件，EventBus和Kestrel都是Kafka出现之前Twitter内部开发的消息中间件。需要内部系统的原因是有些业务需要类似于exactly-once（确定一次）的语义或者其他特殊需求，而Kafka成熟较晚，直到2017年的0.11版才推出exactly-once这种语义。

• Storm、Heron：消息中间件的数据会被一个实时处理系统处理。Twitter早期用的是Storm，但后来发现Storm性能和开发问题比较大，就自己用C++开发了一个与Storm API兼容的系统Heron来取代Storm，并在2016年开源。

• Nighthawk、Manhattan：Nighthawk是sharded Redis，Manhattan是sharded key-value store（用来取代Cassandra），推文、私信等用户信息存放在Manhattan里，Nighthawk作为缓存，这些组件是直接服务业务的；实时处理的数据和一些批处理分析的数据也会放在这里，被业务系统调用。

• LogMover：日志复制工具，主要使用Hadoop的distcp功能将日志从实时服务器复制到另一个大的生产集群。

• 第三方数据：例如苹果应用商店的数据，这些数据使用定制的爬虫程序在Crane框架里执行。

• Pig、Hive、Scalding、Spark：各种内部批处理分析框架，也用来开发ETL工具。

• DirReplicator：用来在各个数据中心、冷热Hadoop集群、测试/生产集群中同步数据目录。

• DAL：Twitter的数据门户，基本上所有的数据操作都要经过DAL的处理。

• Tableau、Birdbrain：Twitter的数据可视化/BI工具，Tableau是通用的商业化工具，主要供具有统计背景的数据分析师使用；Birdbrain是内部的BI系统ÿ