大厂的大数据架构

淘宝

淘宝大数据平台承当了 数据采集、加工解决、数据利用 的职责。

第一个阶段：RAC 时代

2008 年前的单节点 oracle，还称不上数据仓库，只能承当简略的数据处理工作

2008 年后，为了应答日益增长的数据量，RAC 集群应运而生，从一开始的 4 个节点逐渐倒退到 20 个节点，成为过后号称寰球最大的 RAC 集群。RAC 过后在稳定性、安全性、存储能力还是计算能力都体现优良，随之而来第一代数据仓库架构也逐步形成。

天网调度零碎架构：这个阶段的 ETL 过程次要通过 ORACLE 的存储过程实现，大量的 SQL 脚本工作运行在集群上，工作运行的调度过程是通过 Crontab 来进行管制治理，随着工作数的增长，面临的最大的问题就是如何保障这成千上万的脚本每天失常运行，出错后如何及时发现解决，为了解决，数据团队开始自主研发调度零碎，并命名为天网调度零碎

第二个阶段：Hadoop 时代

业务的飞速发展给数据带来了新的挑战，每天解决的数据在一直的翻倍，首先遇到瓶颈的是 RAC 集群针对网站的拜访日志数据曾经搞不定了，RAC 尽管有肯定的扩大能力，然而无奈无限度的线性扩大，并且扩容就意味着昂扬的机器老本和软件老本。

2009 年数据团队开始摸索新得技术畛域，同时摸索利用了两个方向的技术：Greenplum和Hadoop。次要场景就是用来解决海量的日志数据。

hadoop 因其良好的线性扩大能力，并且是开源零碎，可能基于官网版本二次开发，逐步占据了劣势

2010 初，淘宝放弃 Greenplum 和 RAC，全面应用 Hadoop，将所以的数据都搬到 Hadoop，Hadoop 命名为云梯 1.

第一个环节就遇到了问题，数据同步。业务零碎有各种各样的数据源，ORACLE、MYSQL、日志零碎、爬虫数据，过后负责同步的员工，每当业务零碎进行变更时，各种同步工作须要一直的调整，每次调整几百个工作极其容易出错，为了解决数据同步的问题，数据工具团队研发 DATAX，也就是当初同步核心的前身，同时研发了针对 DB 的实时同步工具 Dbsync 和针对日志的 TT。

云梯一同步工具

2013 年前，采纳的形式都是基于 Hadoop 一个小时计算一次的形式进行数据计算，数据存在肯定的提早性，从 2013 年开始，数据团队开始投入研发实时计算平台。

第三个阶段：MaxCompute(原 ODPS)时代

在 Hadoop 大量利用的同时，另一个我的项目也在进行，就是阿里云图案对自主研发的 ODPS 零碎，ODPS 所有的代码都由阿里本人实现，在对立、平安、可治理、能凋谢方面相比于 Hadoop 做了大量的欠缺，ODPS 零碎命名为云梯二，从 2010 年开始，在很长一段视奸内，始终处于云梯一喝云梯二并存的状态

这个状态继续到 2013 年 4 月，有了新的挑战，Hadoop 集群的下限是 5000 个节点，依照过后数据增长的推算，集群存储行将撞墙，过后，ODPS 还无奈齐全代替 Hadoop，于是过后启动了“5k 我的项目”，同时进行云梯一和云梯二的 跨机房集群 我的项目。

在“5k 我的项目”胜利的同时，ODPS 机构逐渐成熟，于是又启动了一个规模更宏大的我的项目，叫做“登月我的项目”。将全团体的数据加工利用全副搬移到 ODPS，我的项目始终继续到 2015 年，Hadoop 正式下线，淘宝大数据彻底进入 ODPS 时代，同时，阿里云开始对外提供云服务，其中大数据解决方案作为其中重要的组成部分，也开始对外提供

MaxCompute 提供一种疾速、平安托管的 EB 级数据仓库解决方案。很多企业抉择它晋升工作效率并缩小大量开发成本和人力老本，使企业能更专一于业务倒退。

滴滴

滴滴的外围业务是一个实时在线服务。因而具备丰盛的实时数据和实时计算场景

第一个阶段：业务方自建小集群

2017 年以前滴滴并没有对立的实时计算平台，而是每个业务方自建小集群。存在如下弊病：

• 须要事后洽购大量机器，因为单个业务独占，资源利用率通常比拟低；
• 不足无效的监控报警体系；
• 保护难度大，须要关涉业务方大量精力来保障集群的稳定性；
• 不足无效技术支持，且各自积淀的货色难以共享。

为了解决以上问题，滴滴从 2017 年开始构建对立的实时计算集群及平台。

第二个阶段：集中式大集群、平台化

技术选型上，咱们基于滴滴现状抉择了外部用以大规模数据荡涤的 Spark Streaming 引擎。绝对于离线计算，实时计算工作对于稳定性有着更高的要求，为此构建了两层资源隔离体系

第一层是做过程级别的 CPU 及内存隔离，第二层是物理机器级别的隔离。通过革新 YARN 使其反对 Node Label。一般的业务混跑在 Label 机器上，而非凡业务的工作跑在专用 Label 的机器上。

资源隔离体系

通过集中式大集群喝平台化建设，根本打消了业务方自建小集群带来的弊病。但随着业务的倒退，发现 Spark Streaming 的模式在一些低延时的报警业务及在线业务上显得顾此失彼。于是引入了 Flink 作为新一代实时计算引擎。Flink 不仅能够做到毫秒级，而且提供了基于 Process Time(事件被解决时机器的零碎工夫)/Event Time(事件产生的工夫) 丰盛的窗口函数。

实时计算平台架构

• 监控报警。提供存活、延时、流量等监控以及基于监控的报警能力；
• 诊断体系。包含流量曲线、Checkpoint、GC、资源应用等曲线视图，以及实时日志检索能力。
• 血缘关系。出现流工作与上下游的血缘关系；
• 工作管控。实现工作提交、启停、资产治理等能力。

第三个阶段：sql 化

正如离线计算中 hive 之于 MapReduce 一样，流式 sql 也是必然的发展趋势。通过 SQL 化能够大幅度降低业务方开发流计算的难度，业务方不再须要学习 Java/Scala，也不须要了解引擎执行细节及各类参数调优。因而 2018 年启动了 StreamSql 我的项目。

美团

实时平台初期架构

在实时数据系统建设初期，因为实时数据的需要较少，造成不了残缺的数据体系，美团采纳“一路到底”的开发模式，通过在实时计算平台上部署 storm 作业处理实时数据队列来提取数据指标，间接推送到实时应用服务中

随着产品和业务人员对实时需要的一直增多，以及短少欠缺的监控零碎。

为解决以上问题，美团依据生产离线数据的教训，抉择应用分层设计方案来建设实时数据仓库，其分层架构如下：

该计划由以下四层形成：

1. ODS 层：Binlog 和流量日志以及各业务实时队列。
2. 数据明细层：业务畛域整合提取事实数据，离线全量和实时变动数据构建实时维度数据。
3. 数据汇总层：应用宽表模型对明细数据补充维度数据，对共性指标进行汇总。
4. App 层：为了具体需要而构建的应用层，对外提供服务。

通过分层设计能够将解决数据的流程积淀在各层实现。比方在数据明细层对立实现数据的过滤、荡涤、标准和脱敏流程。在数据汇总层加工共性的多维指标汇总数据。

通过应用实时数仓代替原有流程，咱们将数据生产中的各个流程形象到实时数仓的各层当中。实现了全副实时数据利用的数据源对立，保障了利用数据指标、维度的口径的统一。在开发过程中通过严格的把控数据分层、主题域划分、内容组织标准规范和命名规定。再配合上应用 Flink SQL 进行开发，代码加简洁。单个作业的代码量从均匀 300+ 行的 JAVA 代码，缩减到几十行的 SQL 脚本。我的项目的开发时长也大幅减短。