博客 聊聊云原生大数据平台(一)——数据平台架构

聊聊云原生大数据平台(一)——数据平台架构

   数栈君   发表于 2022-12-20 15:57  1001  0

在实际企业应用中,机器学习平台非常依赖于企业底层的数据平台,虽然这两年 AI 的热潮一波接着一波,但要很好地去落地算法应用,非常依赖于数据平台的基础建设。从 a16z 的一些分析报告 中也可以看出,目前数据平台类公司吸引了非常多的市场和资本关注,也应运而生了 modern data stack 之类的概念。这篇文章我们就来聊聊什么是所谓的云原生数据平台。

1 发展历程

最早的数据平台来自于关系型数据库(RDBMS)技术,从一开始以记录业务运作数据的 OLTP 系统开始,逐渐发展出了对业务情况做数据分析并进一步采取决策的相关需求,也就是所谓的 OLAP 系统,其中包含了很多经典的理论和技术方法。

在 1980 年代,出现了针对数据分析需求建立数据仓库系统(Data Warehouse)的设计方法,成为了最早一代的“数据平台”系统。1992 年,著名的“数仓之父”Bill Inmon 出版了《Building the Data Warehouse》一书,形成了一套自上而下中心化地构建企业级数仓的方法论。另外一位大佬 Ralph Kimball 则在 1996 年出版了《The Datawarehouse Toolkit》一书,提出了自下而上基于 Data Mart 的概念来构建企业级数仓的思路。在上世纪 90 年代,这两位大佬的书几乎成了从业者的必读权威著作,企业级数仓的概念也逐渐开始普及,与 BI 分析应用一道被各大企业广泛采纳和部署。当时主流的软件系统都来自于各大商业闭源软件,如 IBM DB2,SQL Server,Teradata,Oracle 等。

到了 21 世纪初,互联网的概念开始兴起,在数据处理分析方面,“大数据”的挑战也应运而生。传统的数仓技术已经难以应对互联网时代海量的数据,快速变化的数据结构,各种半结构化非结构化数据存储和处理的需求。从谷歌发表的三篇经典论文(MapReduce,GFS,BigTable)开始,出现了与传统关系型数据库技术有所不同的分布式数据系统技术栈。这一趋势被后来的 Hadoop 开源生态发扬光大,在业界形成了长达十多年的深远影响。记得当时去参加各种技术会议,大家都在聊“数据湖”,NoSQL,SQL on Hadoop 等技术和理念,互联网公司们采用的数据平台也大都是基于 Hadoop 这套开源生态体系(HDFS,Yarn,HBase,Hive 等)构建起来的。市场上也涌现了著名的 Hadoop 三驾马车,Cloudera,Hortonworks 和 MapR。

随着 AWS 引领的云计算浪潮的崛起,大家越来越意识到 Hadoop 系统架构的各种问题,包括存储和计算资源绑定,非常高的运维难度和成本,无法很好地支持流式数据处理,交互式查询等。云原生时代一个非常大的变化是大家都倾向于降低各种系统的拥有成本和运维成本,由云厂商来提供专业的服务。另外一大趋势是对极致的“弹性”能力的追求,比如现在一些云数据仓库甚至可以做到按单次查询所消耗的计算量来收费。这些要求在 Hadoop 生态相对来说都比较难实现,因此逐渐出现了新一代的云原生数据平台的理念,也是本文主要讨论的主题。

2 数据平台架构

2.1 经典数仓架构

在传统视角中,数据平台就约等于数仓平台。所以只需要 ETL 工具,把数据从各种数据源中载入到数仓中,然后用 SQL 做各种处理,转换,构建数仓分层体系,再通过 SQL 接口对外提供服务即可:


http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user1/article/f7ff4fa4e8ebbafa66cdd7c410bbb0d1..jpg
传统数据平台

2.2 数据湖架构

但随着业务的发展,大家逐渐对数据平台的能力有了更多的要求,包括经典的四个 V 中的几点:

  • Variaty,数据的多样性。比如需要存储和处理各种半结构化的 Json,Avro,ProtoBuf 类型的数据,或者是非结构化的文本,图像,音频,视频等。这些内容的处理,往往 SQL 就会比较难以应对了。此外需求方面也变得更加多样,除了 BI 类分析,AI 类的分析建模需求,业务系统对分析结果的消费等也变得越来越普遍。
  • Volume,数据的量级。随着业务在线化,数字化的转变,数据驱动的思想越来越普及,现代企业需要存储和处理的数据量级也变得越来越巨大。虽然传统的商业数仓软件可以支持水平扩展,但往往其架构是绑定了存储和计算的,这就导致其开销非常的巨大。这也是现代数据平台中非常显著的一个差异点。
  • Velocity,数据的变化速度。在一些数据应用场景中,逐渐开始出现了自动化实时决策的需求。例如用户在浏览了一些商品后,系统可以获取到新的行为数据而实时更新用户推荐内容;或是结合用户最近几分钟的行为作出的自动风控审核决策等。在这种情况下,传统的 T+1 形式的数仓作业显然就无法满足需求了。

在这些需求的驱动下,数据平台的架构向着更加复杂的结构演化,也开始引入很多知名的大数据系统组件如 Hadoop,Spark 等。其中比较知名的有 Storm 作者 Nathan Marz 提出的 Lambda Architecture:


http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user1/article/543d9960b3ae0b5300c3ed5978c744a2..jpg
Lambda 架构

这个架构在设计上还是经过了很多经验总结和深思熟虑的,核心还是每天的全量数据的批处理(Batch Layer),相比传统的基于 SQL 的数据转换,可以支持更加丰富的数据类型和处理方式,同时借助 Hadoop 架构也能支撑更大的数据量。同时为了支持“实时”需求,增加了流处理层(Real-Time Layer),最后在数据消费时,可以再把这两块的数据结合起来(Serving Layer),形成最终的结果。不过这个架构也受到了一些诟病,尤其是需要维护批处理和实时两套计算框架,且要重复实现两遍相同的处理逻辑,在架构复杂度上和开发维护成本上都有不足。后续 Kafka 的作者 Jay Kreps 又提出了 Kappa 架构,想将批处理和实时处理统一到一起,有点“流批一体”的意思。


http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user1/article/0e8ea467d824e9f643f28356ce6c320a..jpg
Kappa 架构

但个人感觉 Kappa 架构又太理想化了,即使到了 2022 年,流式数据也还远没有成为行业主流。对于消息流的数据重复,消息顺序,复杂计算(如实时 join)之类的支持,各类源数据系统的支持,数据 schema 的管理,数据存储的成本控制等方面,都还没达到非常稳定好用且高效的状态。所以要让一个企业的数据完全跑在流式数据系统基础上,目前看还是不太现实的。因此现阶段比较主流的数据平台架构实际上还是从业务需求和全流程系统成熟度出发,把批处理系统和实时处理系统进行了结合。

2.3 云原生架构

对于各种组件的组合需求,伴随着云原生时代的到来,出现了越来越多更加易于直接“组装使用”的 SaaS 数据产品。相比之前部署运维 Hadoop,Kafka 集群的复杂度,新一代的云原生产品一般都可以直接使用托管服务,按量付费,即开即用,对于非互联网类公司来说非常友好。所以常见的数据平台架构都开始往引入各种产品组件的方向发展,出现了很多有意思的新思路:

  • 在数据处理层面,会使用不同的计算引擎来执行批处理或者流式处理的任务,但对于用户接口来说,希望尽可能保持一致,于是就有了所谓的“流批一体”。
  • 在存储和数据服务层面,曾经“数据湖”和“数据仓库”两者争得不可开交,但在几年的发展后发现也并不能完全替代对方。于是数据湖阵营增加了很多 SQL,Schema,数据管控这些功能的支持,成为了新物种 lakehouse。而数据仓库也都走向了云原生化,很多云数仓也支持使用他们的计算引擎直接对数据湖上的文件进行计算处理。“湖仓一体”也成了一个热门名词。
  • 此外还有 feature store 中对于批量和单点查询特征的需求,实时分析和数据消费应用的需求结合而生的“HSAP”等等,不一而足。

著名的投资机构 a16z 给出的统一数据架构总览就很具有代表性:


http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user1/article/9d8530e187388298c6cfce2b3625e064..jpg
a16z 的统一数据架构


这张图画得非常详细,把整个数据流转的过程分成了数据源(一般不包含在数据平台里),数据获取与传输,存储,查询处理,数据转换和分析输出这几大块,而且每一块中的各个模块,相关的产品都做了详细的标注。一般企业都会根据需求来选择其中的部分组件进行部署,例如如果没有流式数据的需求,那么就不需要下面那部分流式数据接入和处理的部分。而跟 Lambda 架构不同的是,对于同一个业务场景,一般也不需要让同一份数据既经过实时处理链路,又在 T+1 时经过批处理链路做两次,而是选择合适的一条链路去做后续处理即可。

不过上述的架构图因为考虑到不同企业不同场景不同阶段的需求,画的有些过于复杂了,个人更喜欢在《Designing Cloud Data Platform》一书中,作者给出的一张相对精简的架构总览:


http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user1/article/8ca801568877bef46193c1bc937b158e..jpg
云数据平台架构

这个架构在核心上与 a16z 给出的架构参考是基本一致的,不过在各个 layer 的拆分设计上更加的清晰一些,有助于我们理解和规划整个数据平台。如果能将各个 layer 之间的职责,接口定义清楚,那么对于数据流程的标准化,组件实现的灵活替换升级也会非常有好处。后续我们会根据这两张图来展开描述云数据平台的各个组成部分。

总体来看数据平台架构近年来的演变趋势主要有两个方面,一是为了满足多样化的业务需求,平台整体的系统组件越来越多,处在一个高度分化的阶段,但又希望能对用户保持透明;二是组件的选择会倾向于选择各类公有云厂商或者数据 SaaS 平台厂商的产品,在架构较为复杂的情况下并没有提升太多的维护成本,但组件间的职责明确(松耦合)和接口标准化仍然是一个挑战。

(文章来源于网络,如侵删)


相关链接:

聊聊云原生大数据平台(一)——数据平台架构 https://www.dtstack.com/bbs/article/428

聊聊云原生大数据平台(二)——数据获取  https://www.dtstack.com/bbs/article/469

聊聊云原生大数据平台(三)——数据存储 https://www.dtstack.com/bbs/article/470

聊聊云原生大数据平台(四)——数据处理 https://www.dtstack.com/bbs/article/471

聊聊云原生大数据平台(五)——元数据 https://www.dtstack.com/bbs/article/472

聊聊云原生大数据平台(六)——数据消费 https://www.dtstack.com/bbs/article/473

聊聊云原生大数据平台(七)——流程编排与 ETL https://www.dtstack.com/bbs/article/474

聊聊云原生大数据平台(八)——数仓最佳实践 https://www.dtstack.com/bbs/article/475

聊聊云原生大数据平台(九)——大数据平台建设 https://www.dtstack.com/bbs/article/476

袋鼠云在大数据领域深耕7年,拥有丰富的大数据平台建设经验和成熟的产品体系,想了解或咨询更多有关袋鼠云大数据产品、行业解决方案、客户案例的朋友,浏览袋鼠云官网:https://www.dtstack.com/?src=bbs

同时,欢迎对大数据开源项目有兴趣的同学加入「袋鼠云开源框架钉钉技术群」,交流最新开源技术信息,群号码:30537511,项目地址:https://github.com/DTStack

0条评论
社区公告
  • 大数据领域最专业的产品&技术交流社区,专注于探讨与分享大数据领域有趣又火热的信息,专业又专注的数据人园地

最新活动更多
微信扫码获取数字化转型资料
钉钉扫码加入技术交流群