大厂的大数据架构

淘宝

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

第一个阶段：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作业处理实时数据队列来提取数据指标，间接推送到实时应用服务中

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

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

该计划由以下四层形成：

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

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

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