一文看懂阿里、京东、滴滴大数据架构变迁
大数据的概念从上世纪90年代被提出，03-06年Google的3篇经典论文（GFS、MapReduce、Bigtable）作为奠基，Hadoop等优秀系统的出现使之繁荣，经历了十余年的时间。
从Gartner Hype Cycle这一行业技术发展的趋势图看，大数据从2011年进入该图谱，2014年被标记为进入衰退期，2015年开始不再标注，确实反映了这一概念经历了从不切实际的幻想期，到泡沫期，到衰退和成熟期的整个过程。目前来看，这一领域的技术已经相对稳定和成熟，各类应用已确实产生价值，使其成为了一种普惠性质的技术。
从主要互联网企业大数据技术栈的变迁，我们可以得到如下结论：
1、数据规模会继续扩大，数据价值会进一步挖掘
随着IOT技术的发展和成熟，5G的逐步推广，上游产生的数据量仍会快速增长，海量数据的采集、存储、处理技术仍有提升空间。
对于下游产业应用，则会进一步挖掘数据的价值，目前还有很多金矿没有开采。
2、数据实时性需求将进一步增加
大数据诞生之初的目的是做海量数据的离线处理，包括离线的数据仓库、报表等应用。随着近几年软硬件档次的提升，大规模数据的离线处理已经难度不大，新的挑战在于各种实时应用，这其中又包括了实时采集、实时计算、实时可视化、在线机器学习等多个领域。
3、底层技术集中化，上层应用全面开花
从前面的大数据技术栈图可以看到，大数据领域各种组件和技术繁多，更新也非常快。但近几年包括头部互联网企业也都将底层技术进行集中，如批处理领域的Spark，消息队列领域的Kafka几乎成为事实的标准，我们预计每一个细分领域的组件都会集中到1-2个上来。
与此相反，上层应用层面则百花齐放，大互联网公司几乎所有产品都包含大数据元素，某些垂直领域也出现了专业性公司，如专门做BI的、专门做AI产品的。可以预见今后的创新主要都将集中在应用层面。
4、公有云和私有云并存
在国外，公有云上的大数据服务已经基本普及。但在国内，由于各企业所在领域不同，对数据安全性标准不同，并且互联网行业存在恶性竞争情况，短期内大多数企业仍倾向于以本地机房方式来部署大数据的基础设施。无论采用哪种方式，未来的大数据技术栈都会朝着容器化、存储计算分离、跨机房跨地域部署的方向发展。
飞天大数据平台始于2009年阿里巴巴的“登月”计划，目前已经在阿里云内部实际运行和服务了十年之久（大家过去更为熟悉的 MaxCompute 是飞天系统的三大件之一，也是如今飞天大数据平台的核心）。如今飞天大数据平台在阿里巴巴经济体中支撑99%的数据存储和99%的计算力，单日数据处理量超过600PB，也是阿里AI技术最重要的基础设施之一。
历史
2009 年，阿里启动“云梯”计划，当时有两条技术路线同步进行，分别是开源的Hadoop和自研的ODPS（也就是今天的MaxCompute）。当时阿里已经下定决心要开始去IOE并构建自己的大数据平台，但还没有决定好是走开源路线还是自研路线，因此就有了云梯1（Hadoop）和云梯2（ODPS）的并行。2013年，两个平台先后突破单集群5000台服务器。最终从深度技术把控力和极致性能优化的角度，决定采用云梯2。同年，“登月”项目正式启动。
在“登月”项目进行过程中，自研数据综合治理平台DataWorks（原来叫作BASE）也同步开始构建。到了2015年，“登月”项目完成，ODPS+BASE开始在阿里云上对外提供服务，这也标志着阿里第一套数据中台体系构建完成。同年，ODPS打破了SortBenchmark的4项世界纪录，100TB数据排序仅耗时不到7分钟。
2016年，阿里集团内部开始涌现出一批新的计算引擎，包括支持开源大数据的EMR（E-MapReduce）、实时计算Stream Compute、机器学习PAI等。随着企业数据场景变得越来越复杂，数据类型和存储类型越来越多样化，单一引擎或单一存储已经很难满足客户需求。这也给大数据平台带来了新的挑战，对于不同的数据类型、存储类型、计算引擎，如何方便地进行数据统一管理和开发？阿里巴巴认为当前最佳实现方式是跨引擎统一编程平台+跨数据源综合治理，而这推动了阿里大数据平台向飞天大数据平台的演进。
目前的飞天大数据平台，是一个能够将离线计算、实时计算、机器学习、搜索、图计算等引擎协同起来对云上客户提供服务、且有AI加持的全域数据平台。下图是其完整架构。
与传统大数据平台相比，该平台具备以下特色：
1.计算力与成本的极致优化
2.企业数据综合治理能力
3.大数据与AI双生
下图是其核心能力。
2010年，京东集团启动了在大数据领域的研发和应用探索工作，正式组建京东大数据部，并确立了数据集中式的数据服务模式，成为企业大数据最早的实践者之一。
大数据平台的发展是随着京东业务同步发展的，由原来的传统数据仓库模式逐步演变为基于Hadoop的分布式计算架构，技术领域覆盖Hadoop、Kubernetes、Spark、Hive、Alluxio、Presto、Hbase、Storm、Flink、Kafka等大数据全生态体系。
目前已拥有集群规模40000+服务器，单集群规模达到7000+台，数据规模 800PB+，日增数据1P+，日运行JOB数100万+，业务表900万+张。每日的离线数据日处理30PB+，实时计算每天消费的行数近万亿条。
下图为京东大数据平台整体架构图。
京东的大数据体系可以看作是基于Hadoop的大数据体系的优化和应用，因此对除阿里以外的企业来说更有借鉴意义。以下是其各主要模块所使用的技术栈。
1、数据采集和预处理
搭建了标准化的数据采集系统：数据直通车（框架自研，组件有使用开源技术），具备离线和实时两种数据采集方式。
离线采集主要类型：MySQL、SQLServer、Oracle、MongoDB、HBase、ElasticSearch、离线文件。
实时采集主要类型：MySQL、日志、HTTP API、JMQ等。
2、流量数据采集
主要采集PC端、移动端应用、移动端H5页面、微信手Q内嵌入口、小程序等流量入口的埋点数据。这部分难点在于，各流量入口实现原理不同，数据采集的诉求也不同，甚至有可能不同来源的数据需要做连接，因此需要较多的数据标识工作。
3、数据存储
包括JDHDFS存储（开源HDFS的改进版）、JDHBase（开源HBase的改进版）、冷热数据管理等。对开源组件的改进点主要在容灾、元数据、多租户等方面，对核心代码逻辑没有做大的改动。
4、离线计算
包括JDHive计算引擎（开源Hive的改进版）、JDSpark计算引擎（开源Spark的改进版）、Adhoc查询服务（封装了Presto和Kylin）等，底层仍使用YARN作为资源调度器。另外还支持使用Alluxio作为缓存层，加速线上业务的数据查询速度。
5、实时计算
搭建了京东大数据实时计算平台，包括实时数据总线JDQ（开源Kafka的改进版）、准实时数据仓库（数据以准实时的延迟灌入Hive）、实时计算平台JRC（Storm、SparkStreaming、Flink）。仍然是各类Hadoop体系开源组件的小范围优化。
6、机器学习
京东机器学习平台由基础架构层、工具层、任务调度层、算法层以及API层组成。京东没有公开其具体实现技术，但可以推测，其完全依赖大数据平台的数据采集、计算、存储能力，在工具层、算法层、API层做定制开发。
7、任务管理和调度
自研了京东分布式调度平台，包括管理节点、工作节点、Web管理端和日志收集器几个组件。其中管理节点支持高可用。
8、资源监控和运维
京东大数据平台监控实现了对调度系统、集群任务管理、集群存储资源、机房网络专线、全集群服务器资源的统一监控体系，在开源的Premetheus上进行二次开发。另外还有CMDB、自动部署系统等其他系统的支持。
滴滴大数据到目前为止经历了三个阶段，第一阶段是业务方自建小集群；第二阶段是集中式大集群、平台化；第三阶段是SQL化。
滴滴的离线大数据平台是基于Hadoop2（HDFS、Yarn、MapReduce）和Spark以及Hive构建，在此基础上开发了自己的调度系统和开发系统。调度系统负责调度大数据作业的优先级和执行顺序。开发平台是一个可视化的SQL编辑器，可以方便地查询表结构、开发SQL，并发布到大数据集群上。
离线计算平台架构如下：
另外，由于滴滴的业务特性，非常依赖于实时计算。从2017年开始构建统一的实时计算集群及平台。技术选型上，基于滴滴现状选择了内部用以大规模数据清洗的Spark Streaming引擎，以on YARN模式运行。利用YARN的多租户体系构建了认证、鉴权、资源隔离、计费等机制。在流计算引擎基础上提供了 StreamSQL IDE、监控报警、诊断体系、血缘关系、任务管控等能力。
此外，滴滴还对HBase重度使用，并对相关产品（HBase、Phoenix）做了一些自定义的开发，维护着一个较大的HBase平台。
来自于实时计算平台和离线计算平台的计算结果被保存到HBase中，然后应用程序通过Phoenix访问HBase。而Phoenix是一个构建在HBase上的SQL引擎，可以通过SQL方式访问HBase上的数据。
5.1 中等规模企业
指研发团队规模在千人左右，专职大数据团队规模在百人左右的企业。类似京东、滴滴。
这样的企业可以首先以开源Hadoop为基准搭建大数据平台。当在技术上有一定沉淀以后，可以在开源Hadoop社区各组件的版本上叠加自己的一些特性，使得能够更好地适配自身的业务形态，或减少运维的压力。在发展模式上，建议从一开始就建立统一的大数据平台，向公司内各部门统一输出能力，而不要各部门分散建设，避免后续的整合、迁移成本。在大数据平台形成完备的体系后，进一步建设公司层面的大数据中台。
1、数据采集
开源的数据采集组件如Flume、StreamSets等都经过了较长时间的生产检验，优势劣势都很明确，可以优先采用。如果定制型的采集需求很多，或者需要对数据做较多的on fly处理，也可以自研采集组件，但通常来说效率都没有开源的好。
还有一些比较新的开源采集工具，例如Apache Nifi，可以适当关注，不建议在生产中大规模使用。
2、数据存储
HDFS和HBase几乎是大数据存储领域实时上的标准。所有需求都应该优先往这两种存储上靠，其中HDFS对应离线数据的存储，HBase对应实时数据的存储。
Kudu是一种比较新的存储引擎，在某些互联网企业中被用来构建实时数仓，其实时性介于HDFS和HBase之间。目前也比较稳定，有实时数仓需求时可以引入。
另外，传统的RDBMS也是一种可靠的存储，在大数据领域可以用于报表、BI类服务，但使用时需要注意其数据量。
其余还有一些可用于缓存层的存储，如Redis，Alluxio等，严格来说不属于Hadoop生态体系，可以按需使用。
3、离线计算
MapReduce程序不应该再使用，这包括Hive on MapReduce的方案。如果一定需要Hive，可以跑在Spark上。
Spark一定需要，可以将Spark SQL作为构建离线数仓的主力工具。
如果有较多的BI类应用，可以考虑引入Impala或Kylin，这取决于是要事实计算数据立方，还是离线把数据立方准备好。
离线计算的资源管理可以继续使用YARN。
4、实时计算
Spark Streaming和Flink几乎是事实上的标准。有一些比较年轻的企业仅使用Flink，但绝大多数的头部互联网公司都使用了Spark Streaming和Flink两者，因为在多数批流结合的场景下，Spark仍然是优秀的。
Storm则不应该再使用了。
消息队列领域，Kafka是必选方案。如果没有特别的理由，不要选用阿里开源出来的RocketMQ。
5、机器学习
Spark的MLlib可以解决一部分的机器学习需求。对于另一些比较复杂、偏门的算法，如果有明确需求需要使用，可以自己实现。
另一个问题是机器学习任务的开发环境。开源产品中只有Cloudera的CDSW比较好用，但它强依赖于CDH。中等规模互联网公司一般都自己开发这样的环境。
6、任务管理和调度
Hadoop生态下的开源调度系统有Oozie、Azkaban等，但功能都太简单，一般不会被这个规模的企业所采用。国内厂商贡献给社区的DolphinScheduler可以尝试。也可以自研。
7、其他
还有一些比较成熟的开源项目，如果有需求，完全可以在生产中使用。例如用于文档存储和搜索的ElasticSearch。这些可以根据企业所在的领域和自身技术积累来决策。
5.2 小规模企业
指研发团队规模在百人左右，专职大数据团队规模在几人到小几十人的企业。
这样的企业在构建大数据平台时，应该以现成的稳定产品为主，不要自研或者少量自研，因为老板肯定不愿意把有限的研发资源投入到组件的研究上。
首先要考虑的是使用公有云上的大数据服务，还是自建大数据集群。两者各有优劣，公有云出成果较快，自建集群掌控力较强，但成本投入相差不大。
一旦确定要自建集群，推荐使用成熟的Hadoop发行版，例如CDH、FusionInsight等。开源社区版本由于缺乏很多运维管理上的集成，不推荐小企业使用。所使用的技术栈仍可按照我们前面介绍的Hadoop core + Hive + HBase + Spark/Flink + Kafka的组合来选择。
来源：大数据研习社
有收获，点个在看
