共计 2924 个字符,预计需要花费 8 分钟才能阅读完成。
大厂的大数据架构
淘宝
淘宝大数据平台承当了 数据采集、加工解决、数据利用 的职责。
第一个阶段: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 脚本。我的项目的开发时长也大幅减短。