大厂的大数据架构
淘宝
淘宝大数据平台承担了数据采集、加工处理、数据应用的职责。
第一个阶段：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 脚本。项目的开发时长也大幅减短。