点击上方蓝色字体，选择“设为星标”

回复”资源“获取更多资源

本文结合小编自己的经验并且参考了淘宝&滴滴&美团&360&快手等各个大厂大数据平台建设的思路。在尊重事实的基础上重新组织了语言和内容，旨在给读者揭开一个完善的大数据平台的组成和发展过程。

大数据平台是为了计算，现今社会所产生的越来越大的数据量，以存储、运算、展现作为目的的平台。大数据技术是指从各种各样类型的数据中，快速获得有价值信息的能力。适用于大数据的技术，包括大规模并行处理（MPP）数据库，数据挖掘电网，分布式文件系统，分布式数据库，云计算平台，互联网，和可扩展的存储系统。总结，大数据平台的出现伴随着业务的不断发展，数据的不断增长，数据需求的不断增加，数据分析及挖掘的场景而逐步形成。本文讲述淘宝&滴滴&美团&360&快手等各大互联网公司的大数据平台的发展历程，为大家提供建设大数据平台的基本思路。

淘宝大数据平台

淘宝可能是中国互联网业界较早搭建了自己大数据平台的公司，下图是淘宝早期的 Hadoop 大数据平台，比较典型。

云梯数据仓库架构-图来源于《淘宝大数据平台之路》

淘宝的大数据平台基本分成三个部分，上面是数据源与数据同步；中间是云梯 1，也就是淘宝的 Hadoop 大数据集群；下面是大数据的应用，使用大数据集群的计算结果。数据源主要来自 Oracle 和 MySQL 的备库，以及日志系统和爬虫系统，这些数据通过数据同步网关服务器导入到 Hadoop 集群中。其中 DataExchange 非实时全量同步数据库数据，DBSync 实时同步数据库增量数据，TimeTunnel 实时同步日志和爬虫数据。数据全部写入到 HDFS 中。

数据同步工具-图来源于《淘宝大数据平台之路》

在Hadoop中的计算任务会通过天网调度系统，根据集群资源和作业优先级，调度作业的提交和执行。计算结果写入到HDFS，再经过DataExchange同步到MySQL和Oracle数据库。处于平台下方的数据魔方、推荐系统等从数据库中读取数据，就可以实时响应用户的操作请求。

淘宝大数据平台的核心是位于架构图左侧的天网调度系统，提交到Hadoop集群上的任务需要按序按优先级调度执行，Hadoop集群上已经定义好的任务也需要调度执行，何时从数据库、日志、爬虫系统导入数据也需要调度执行，何时将Hadoop执行结果导出到应用系统的数据库，也需要调度执行。可以说，整个大数据平台都是在天网调度系统的统一规划和安排下进行运作的。

DBSync、TimeTunnel、DataExchange这些数据同步组件也是淘宝内部开发的，可以针对不同的数据源和同步需求进行数据导入导出。这些组件淘宝大都已经开源，我们可以参考使用。

滴滴数据平台演进之路

到目前为止大概经历了三个阶段，第一阶段是业务方自建小集群；第二阶段是集中式大集群、平台化；第三阶段是 SQL 化。

图片图来源于《滴滴大数据平台演进之路》

离线计算平台架构如下。滴滴的离线大数据平台是基于Hadoo 2（HDFS、Yarn、MapReduce）和Spark以及Hive构建，在此基础上开发了自己的调度系统和开发系统。调度系统和前面其他系统一样，调度大数据作业的优先级和执行顺序。开发平台是一个可视化的SQL编辑器，可以方便地查询表结构、开发SQL，并发布到大数据集群上。

图来源于《滴滴大数据平台演进之路》

此外，滴滴还对HBase重度使用，并对相关产品（HBase、Phoenix）做了一些自定义的开发，维护着一个和实时、离线两个大数据平台同级别的HBase平台，它的架构图如下。

图来源于《滴滴大数据平台演进之路》

来自于实时计算平台和离线计算平台的计算结果被保存到HBase中，然后应用程序通过Phoenix访问HBase。而Phoenix是一个构建在HBase上的SQL引擎，可以通过SQL方式访问HBase上的数据。

为了最大程度方便业务方开发和管理流计算任务，滴滴构建了如下图所示的实时计算平台。在流计算引擎基础上提供了 StreamSQL IDE、监控报警、诊断体系、血缘关系、任务管控等能力。

图来源于《滴滴大数据平台演进之路》

美团数据平台

我们以数据流的架构角度介绍一下整个美团数据平台的架构，大数据平台的数据源来自MySQL数据库和日志，数据库通过Canal获得MySQL的binlog，输出给消息队列Kafka，日志通过Flume也输出到Kafka，同时也会回流到ODPS。

图来源于《美团大数据平台》

Kafka的数据会被流式计算和批处理计算两个引擎分别消费。流处理使用Storm进行计算，结果输出到HBase或者数据库。批处理计算使用Hive进行分析计算，结果输出到查询系统和BI（商业智能）平台。

数据分析师可以通过BI产品平台进行交互式的数据查询访问，也可以通过可视化的报表工具查看已经处理好的常用分析指标。公司高管也是通过这个平台上的天机系统查看公司主要业务指标和报表。

图来源于《美团大数据平台》

这幅图是离线数据平台的部署架构图，最下面是三个基础服务，包括Yarn、HDFS、HiveMeta。不同的计算场景提供不同的计算引擎支持。如果是新建的公司，其实这里是有一些架构选型的。Cloud Table是自己做的HBase分装封口。我们使用Hive构建数据仓库，用Spark在数据挖掘和机器学习，Presto支持Adhoc上查询，也可能写一些复杂的SQL。对应关系这里Presto没有部署到Yarn，跟Yarn是同步的，Spark 是 on Yarn跑。目前Hive还是依赖Mapreduce的，目前尝试着Hive on tez的测试和部署上线。

另外我们得知，在实时数仓的建设中，美团已经从原来的Storm迁移至Flink，Flink的API、容错机制与状态持久化机制都可以解决一部分使用Storm中遇到的问题。Flink不仅支持了大量常用的SQL语句，基本覆盖了常用开发场景。而且Flink的Table可以通过TableSchema进行管理，支持丰富的数据类型和数据结构以及数据源。可以很容易的和现有的元数据管理系统或配置管理系统结合。

美团大数据平台的整个过程管理通过调度平台进行管理。公司内部开发者使用数据开发平台访问大数据平台，进行ETL（数据提取、转换、装载）开发，提交任务作业并进行数据管理。

360数据平台演进之路

奇麟（Qirin），是由360系统部研发的一站式大数据平台，完整覆盖了大数据的采、存、管、算、用整个大数据开发和处理流程，目前服务于整个集团 30+部门，1000+用户，服务器 25000+，存储数据量 EB 级。可以帮助业务部门快速构建自己的数据平台及数据产品。

从功能上，奇麟主要由以下模块构成（自底向上）：

（1） 资源管理：用于各类大数据服务资源的申请和管理，以及访问权限的申请与管理，包括存储资源、计算资源等；

（2） 元数据管理：基于资源管理，为其他模块提供统一视图，将整个大数据处理平台（流程）贯穿起来。元数据管理一方面支持奇麟系统平台资源，同时也支持用户导入外部自有资源，进而托管应用；

（3） 数据汇集：用于将外部数据汇集到大数据存储中，包括实时和离线的数据汇集；

（4） 任务开发：批流合一的任务平台，用于开发、调度、监控实时和离线数据处理任务；

（5） 交互分析：用于使用 SQL 快速查询探索数据，以及简单的可视化分析和结果展示；

（6） 数据服务：基于以上各子系统能力，提供满足若干场景的 SaaS 服务，比如数据归档备份、跨集群的数据传输，以及对外提供数据共享等；

（7） 权限中心：用于管理资源账号权限以及开发组权限；

（8） 系统管理：提供一些系统基础功能的管理

面向业务，奇麟思考的是通过提供简单易用的一站式大数据处理的平台，降低使用门槛，简化大数据平台工作，帮助业务释放数据价值，赋能业务。

奇麟通过模块化设计，使得各个模块可以灵活组装和运行，针对不同的司内外业务场景，可以快速形成不同的大数据解决方案和产品。

快手大数据服务化平台

大数据服务化业务架构如下所示，Data Lake 数据湖中存储原始数据，经过数据开发之后，形成按主题域组织的数据资产。此时数据资产通常是在数据仓库，访问速度较慢，因此需要通过数据加速到更高速的存储介质，最后经过多场景服务接口，服务于业务。

在技术架构方面，数据接口形式有 RPC 和 HTTP 两类接口。RPC 接口不需要重复建立链接，且传输数据时会被高效序列化，适用于高吞吐场景下的微服务，实现负载均衡、流控、降级、调用链追踪等功能。相对而言，HTTP 接口传输效率低一些，但使用非常简单。

快手大数据服务化平台从2017年演化至今，已经支持多类应用场景，涵盖直播、短视频、电商、商业化等在线业务，生产者中台等准在线业务，运营系统等偏内部数据系统等，目前平台在线业务总 QPS 达到 1000W，平均延迟在毫秒级；对于准在线业务和内部数据系统，基于CH、Druid等多种数据引擎，支持多种灵活查询。数据服务平台支持了多种模式API，很好满足了多元化需求。

快手大数据服务化平台高可用保障：

弹性服务

数据服务是部署在容器云环境，容器云是快手自研的弹性可伸缩的容器服务，部署在其中的RPC服务会注册到 KESS （快手自研服务注册与发现中心），供主调方去调用，如有离群坏点，会自动摘除。服务调用是基于 RPC，全链路都有监控，包括服务可用性、延迟、QPS、容器CPU、容器内存等情况。

资源隔离

资源隔离是可用性保障的常见手段之一，通过隔离将意外故障等情况的影响面降低。不管是微服务，还是存储，我们都按照业务 + 优先级（高、中、低）粒度隔离部署，独立保障，业务之间互不影响、业务内不同级别也互不影响。同一业务线内可能有多个不同数据服务，通过混合部署，提高资源使用率。

全链路监控

服务很难避免出现问题或者故障，一旦出现问题，及早发现及早介入是非常重要的。服务平台构建了全链路监控，包括：

• 数据同步：对数据资产同步至高速存储的过程进行监控，包括数据质量检测（过滤脏数据）、同步超时或者失败检测等

• 服务稳定性：构建一个独立的哨兵服务，来监测每个API的运行指标（如延迟、可用性等），客观的评估健康度

• 业务正确性：数据服务需要确保用户访问的数据内容和数据资产表内容是一致的，因此哨兵服务会从数据一致性层面去探查，确保每个API的数据一致性

快手大数据服务平台的能力建设会朝着统一的 OneService 体系前进。主要包括三个方面：

• 支持丰富的数据源：包括大宽表、文本文件、机器学习模型（模型也是一种数据资产），来构建完善的数据服务。

• 支持多样取数方式：除了支持同步快速取数之外，还支持异步查询取数、推送结果、定时任务等多样化方式，以满足业务多种场景需求。

• 建设统一的API网关：集成权限管控、限流降级、流量管理等于一体，不仅平台创建的服务可以注册进API网关，用户自己开发的API也可注册进API网关，从而享受已有的基础网关能力，为业务提供数据服务能力。

京东 EB 级全域大数据平台

京东整个平台经历了很长的建设和发展历程。这个历程包括了五个阶段：

规模化阶段

主要完成了技术栈的计算存储分离升级，依托数据中心网络技术的提升，减弱对计算本地性的依赖，打散存储热点，提高计算稳定性；同时定制存储与计算优化机型，独立进行容量规划，大幅降低IT资源成本。在存储上实现了稳定的万台规模HDFS集群，并在其上全面落地了纠删码技术，实现高效高压缩比的大数据存储；再在计算上进行了跨层的优化，从调度层、引擎层和应用层分别进行了深度的改进；最后通过全生命周期管理保障平台的存储计算能力持续处于健康状态。

体系化阶段

从金融业务，物流业务，电商业务，保险业务、健康业务等不同业务的特点和需求出发，逐步构建成标准化、可管理、可维护、可理解、可复制、一站式、体系化的数据中台，解决了前面提到的业务复杂、数据异构、烟囱化开发、建设成本高等问题。

通过数据层面全链路的规范、盘点、治理，以及平台工具层面业务标准化支撑，打造出京东全集团体系化数据中台。

总而言之，体系化是数据中台的核心目标之一，覆盖了数据从生产、计算、存储、消费的全生命周期，为数据价值的高效发挥提供了坚实基础。

基于体系化建设的经验，我们也沉淀和打磨各项数据能力，提炼出一系列的产品化解决方案。这种体系化建设的方法论和实践经验，让我们在业务快速布局、快速发展的阶段中，能够使数据非常高效的输入到决策引擎，形成快速的商业决策。

实时化阶段

一方面，京东在任务调度、数据分发、状态恢复等方面进行了深度定制优化，大幅提升了系统鲁棒性，也经历了多次大促洪峰的考验；另一方面落地了基于容器的云原生弹性资源调度，打造了全自研的自愈框架，实现自动化自适应的故障恢复能力，能有效的保障系统和平台的稳定性。

其次，Easy Realtime 平台是企业级应用平台，集成了一站式云代码开发，并直接对接云原生实时计算平台。

平台的建设目标是让没有任何代码开发能力的一线业务同事，例如京东的采销同事，甚至是 ISV 代理，经过短时间培训，能够具备 SQL 能力、快速上手，自主实现业务决策开发。

智能化阶段

平台里有几个核心的算法引擎，包括 9N-FL 联邦学习引擎。支撑这些引擎的基础是面向整个算法领域的云化资源管理系统，它与面向数据的管理系统无缝集成，形成一站式的数据算法解决方案，最终赋能京东的零售业务、健康业务、金融业务等, 推动业务的高速发展。

商业化阶段

基于以上四个阶段的发展，京东最终打造出依托于实际业务支撑经验的，可同时支持多领域应用(零售、物流、金融、健康等)的全域大数据平台。它包含的系统、工具、产品和方法论，与业内主流数据中台也有一定的共通之处。

    趣头条实战 | 基于Flink+ClickHouse构建实时数据平台

    大话实时数据平台设计(上)

    大话实时数据平台设计（下）

    如何设计实时数据平台（设计篇）

文章不错？点个【在看】吧！