导读：本文分析一下典型硅谷互联网企业的大数据平台架构。
作者：彭锋 宋文欣 孙浩峰
来源：大数据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系统，它将最常用的报表和指标做成自助式的工具，确保从CEO到销售人员都可以使用。
实际上，Facebook、Twitter、LinkedIn、EA、Uber、Airbnb、Lyft、Pinterest以及很多其他硅谷公司的大数据平台架构都非常类似，下面我们以Airbnb和Uber的数据平台架构为例进行介绍，看看它们之间的共同点。
02 Airbnb的大数据平台架构
图7-3展示了Airbnb的大数据平台架构。
▲图7-3 Airbnb大数据平台架构
Airbnb采用可扩展的大数据平台以确保产品能满足业务的增长，并对Hive集群单独区分金集群和银集群，对数据存储和计算进行分离以保证灾难恢复。
- 数据源：包含各种业务数据的采集，例如将数据埋点事件日志发送到Kafka，MySQL数据通过数据传输组件Sqoop传输到Hive集群。
- 存储：使用的是Hadoop的HDFS和AWS的S3。
- 复制：有专门的复制程序在金、银集群中复制数据。
- 资源管理：用到了YARN，同时通过Druid和亚马逊的RDS实现对数据库连接的监控、操作与扩展。
- 计算：主要采用MapReduce、Hive、Spark、Presto。其中，Presto是Facebook研发的一套开源的分布式SQL查询引擎，适用于交互式分析查询。
- 调度：开发并开源了任务调度系统Airflow，可以跨平台运行Hive、Presto、Spark、MySQL等Job，并提供调度和监控功能。
- 查询：主要使用Presto。
- 可视化：开发了负责界面显示的Airpal、简易的数据搜索分析工具Caravel及Tableau公司的可视化数据分析产品。
03 Uber的大数据平台架构
图7-4显示了Uber的第二代大数据平台架构。
2015年前后，Uber开始围绕Hadoop生态系统重新构建新的大数据平台。Uber引入了一个Hadoop数据湖，其中所有原始数据仅从不同的在线数据存储中摄取一次，并且在摄取期间不进行转换。这种设计降低了在线数据存储的压力，使Uber能够从临时摄取作业过渡到可扩展的摄取平台。
▲图7-4 Uber大数据平台架构
除了整合Hadoop之外，Uber还使该生态系统中的所有数据服务都可以横向扩展，从而提高了大数据平台的效率和稳定性，而且具有这种通用的水平可扩展性可以快速满足新业务需求。Uber第二代大数据平台中包括以下组件。
- 实时数据采集：Kafka。
- 键值数据库：类似于Twitter的Manhattan。
- RDBMS DB：关系型数据库。
- Ingestion：数据采集（这里它强调了强制类型检查，即schema enforced，强制类型检查是数据治理中的一环）。
- 数据采集、存储：主要使用Hadoop，采取Twitter开源的列式存储格式Parquet，构建了一个集中模式服务来收集、存储相关客户端库，将不同服务数据模式集成到这个中央模式服务中。
- ETL：在Hadoop数据湖上进行数据的整合、治理、分析。
- 数据仓库：使用Vertica，主要存储从数据湖中计算出来的宽表，因为处理能力有限，一般只存储最近的数据。
- 计算框架：采用MapReduce、Hive、Spark和Presto。
- 查询工具：使用Presto来实现交互式查询，使用Spark对原始数据进行编程访问，使用Hive进行非常大的离线查询，并允许用户根据需求进行选择。
- 支持的数据应用：建模、机器学习、运营人员、A/B测试。
- 支持随机查询：运营人员、数据科学家。
04 云平台作为大数据平台的通用底座
在上面的几张架构图中，没有明确指出这样一个事实：绝大部分硅谷高科技公司的大数据平台是建立在一个底层云平台架构之上的。因为这是一个共识，所以大部分架构图中省略了这一层。
例如，很多硅谷的公司，从几十人的小公司到几千人的上市公司，在基于Apache Mesos来打造它们的大数据平台。那么它们为何选择Apache Mesos作为基础平台呢？
Apache Mesos是一个分布式集群管理系统，提供了高效、跨分布式的资源隔离和共享以及分布式计算的管理和调度。该系统目前被业界领先公司广泛应用到生产环境和大数据系统中，如苹果公司使用Mesos管理3000台集群来支持Siri语音识别应用，Twitter使用Mesos管理近万台机器的生产环境集群。
Apache Mesos是目前比较先进并经过生产环境验证的分布式集群管理系统。
作为一个数据中心管理系统，Mesos最重要的功能实际上就是基于混合技术做二层调度和资源管理。Mesos不仅支持容器技术，还支持非容器化的应用，实现整个资源池的混合架构、资源的抽象、扁平化管理，最终实现对上层分布式应用（如Spark、Cassandra、Hadoop等）的支持。
Mesos最大的特征及优势是对海量集群的商业和企业级支持。在Mesos的发展历程中有很多问题被发现和解决，并据此在商业环境中持续迭代Mesos的代码仓库，这样就形成了持续迭代和持续优化的机制。
Mesos能够用于大型甚至是超大型集群（主机数在万台以上的集群），在这之上，Mesos实现了企业级的高可用性。总的来说，这种对超大规模集群的支持以及被验证过的企业级高可用性是Mesos最主要的优势。
Mesos源于Google的论文“Large-scale cluster management at Google with Borg”，其中描述了Google的Borg系统是如何管理它的海量服务器和数据中心的。
Mesos的主要作者Ben Hindman在加州大学伯克利分校读博期间，根据Borg的主要思路写了一个分布式数据中心管理系统。Twitter在2010年高速发展时碰到了数据中心的管理问题，于是就把Hindman招募过来，并将Mesos作为自己的数据中心管理系统。
经过Twitter工程团队的大力推进和实际生产验证，Mesos在生产环境中很快就能管理上万台机器的集群，也因此在业界树立了数据中心管理的标杆。
同一时期，Uber、Airbnb、Lyft、Pinterest等公司正好也处于起步阶段，而它们在生产中碰到的问题与Twitter高度相似。因此，它们也就自然而然地选择了基于Mesos来打造自己的大数据平台。下面以Airbnb为例，看看它为什么会选择Mesos。
首先，在有Mesos之前，Airbnb大部分的开发人员和用户有很多数据需要计算，而用以前的方式很难平衡资源，不仅需要找机器来配置，还要安装一些Spark的集群工具。因此，数据开发人员难以及时处理数据并进行大数据计算。
而Mesos正好解决了开发人员的数据计算需求与资源供给之间的矛盾。在解决这个矛盾的过程中，研发人员就能够很轻松地完成大数据的计算和对相关运维的支持，后续也为研发人员带来了很多益处。
其次，Airbnb研发人员会用到Cassandra之类的工具，在使用Mesos以前，这需要先准备机器，安装操作系统、Spark集群、相关的依赖包，安装和使用十分困难。而使用了Mesos之后，新分布式应用上线和开发人员之间的矛盾就得以解决，从而能够及时满足研发人员对于新应用、新分布式系统的需求。
体会到Mesos对分布式开发流程颠覆式的改进之后，Airbnb的两名早期数据平台员工Tobias Knaup及Florian Leibert在2013年共同创立了Mesosphere公司。
Leibert曾是Twitter早期用户增长团队的成员和数据平台的用户，他也是在Twitter使用了Mesos之后意识到其优势并将Mesos引入Airbnb。2014年Hindman也加入其中，全职推广Mesos。
他们认为Apache Mesos是一个开源的孵化项目，它不仅能服务于Twitter、Facebook这样的大公司，还应该更多地服务于早期Airbnb这样的中小企业。
因此，他们创立了DC/OS这个项目，通过DC/OS的开发和商业化，帮助很多中小企业客户在工程师能力不足的情况下，也能受益于Mesos带来的好处。从广义上来说，他们普及了Mesos的应用。
实际上，Apache Mesos类似于Linux的内核，DC/OS则是基于内核之上的分布式应用系统。随着DC/OS的发展，在DC/OS中的许多基于Mesos的监控、日志管理、用户管理、多租户、安全等外围运维服务也随之成长起来。
总而言之，DC/OS是基于Mesos的开源技术，Mesosphere是基于DC/OS开源技术所做的企业级封装，也是构建数据基础架构的核心平台。
05 硅谷大数据平台架构的共性和建设思路
从以上大数据平台的架构范例中，我们可以看出以下几个共性。
- 统一的平台支持端到端的数据工具体系，尤其强调体现数据价值的应用。
- 强调数据能力的闭环，从数据的产生、使用到最后反馈到产品。
- 数据的采集、治理、分析、使用由所有部门在统一体系中完成。
- 主要的基础组件大部分采用成熟系统，如Hadoop、Hive、Kafka、Spark、Vertica。
- 自己开发一些侧重用户交互的组件，如ETL开发调度平台、数据门户、建模/数据治理。
这些共性体现在TotalPlatform的概念中，即要求整个企业的数据工作在统一平台中完成。此外，还有一些在架构图中没有显示，却是大部分数据平台都很重视的部分，如TotalInsight的概念：
- 全局的数据和应用资产的管理和运营；
- 明确平台团队和业务团队的分工和合作；
- 重视可衡量的数据能力。
从上述介绍可以看到，硅谷企业在数据平台的建设上一般都会采取比较开放的思路，从现有的比较合理的开源架构起步，搭建好自己的基础平台，解决基础问题之后再来迭代。
它们在这个过程中会开发一些新技术，解决一些新问题，这些新技术和解决问题的新方法有的回馈到开源社区，有的就在自己公司内部使用。大家都想避免重复造轮子，这主要是基于以下几方面的考虑：
- 重复造轮子风险大、投入高、见效慢；
- 自己造的轮子没有社区，原始开发人员离职后难以招人替代；
- 开发人员更愿意使用现有开源工具，闭源系统很难招到顶尖人才；
- 闭源开发的系统迭代一般比开源要慢很多，如果赶不上，差距会越来越大；
- 涉及系统越来越复杂，一个公司很难自己覆盖所有系统。
我们知道很多大公司内部开发的优秀产品因为没有开源，后续迭代减慢，逐渐被开源产品取代。但是，并非所有层次的产品都适合开源，也并非所有的系统都适合选择开源产品。我们建议的思路如下。
- 基础架构组件：这方面的产品或组件最好选择成熟的开源体系，因为成熟的开源体系经过了众多企业的千锤百炼，具有较高的稳定性和可靠性，而如果自己重新来做，未知因素太多，坑也太多。
- 用户交互组件：在基础架构之上与用户打交道的交互产品，因为各个企业使用习惯不一样，底层技术栈不一样，所以最好选择定制服务或者自主开发。
