在实际企业应用中,机器学习平台非常依赖于企业底层的数据平台,虽然这两年 AI 的热潮一波接着一波,但要很好地去落地算法应用,非常依赖于数据平台的基础建设。从 a16z 的一些分析报告 中也可以看出,目前数据平台类公司吸引了非常多的市场和资本关注,也应运而生了 modern data stack 之类的概念。这篇文章我们就来聊聊什么是所谓的云原生数据平台。
最早的数据平台来自于关系型数据库(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 生态相对来说都比较难实现,因此逐渐出现了新一代的云原生数据平台的理念,也是本文主要讨论的主题。
在传统视角中,数据平台就约等于数仓平台。所以只需要 ETL 工具,把数据从各种数据源中载入到数仓中,然后用 SQL 做各种处理,转换,构建数仓分层体系,再通过 SQL 接口对外提供服务即可:
但随着业务的发展,大家逐渐对数据平台的能力有了更多的要求,包括经典的四个 V 中的几点:
在这些需求的驱动下,数据平台的架构向着更加复杂的结构演化,也开始引入很多知名的大数据系统组件如 Hadoop,Spark 等。其中比较知名的有 Storm 作者 Nathan Marz 提出的 Lambda Architecture:
这个架构在设计上还是经过了很多经验总结和深思熟虑的,核心还是每天的全量数据的批处理(Batch Layer),相比传统的基于 SQL 的数据转换,可以支持更加丰富的数据类型和处理方式,同时借助 Hadoop 架构也能支撑更大的数据量。同时为了支持“实时”需求,增加了流处理层(Real-Time Layer),最后在数据消费时,可以再把这两块的数据结合起来(Serving Layer),形成最终的结果。不过这个架构也受到了一些诟病,尤其是需要维护批处理和实时两套计算框架,且要重复实现两遍相同的处理逻辑,在架构复杂度上和开发维护成本上都有不足。后续 Kafka 的作者 Jay Kreps 又提出了 Kappa 架构,想将批处理和实时处理统一到一起,有点“流批一体”的意思。
但个人感觉 Kappa 架构又太理想化了,即使到了 2022 年,流式数据也还远没有成为行业主流。对于消息流的数据重复,消息顺序,复杂计算(如实时 join)之类的支持,各类源数据系统的支持,数据 schema 的管理,数据存储的成本控制等方面,都还没达到非常稳定好用且高效的状态。所以要让一个企业的数据完全跑在流式数据系统基础上,目前看还是不太现实的。因此现阶段比较主流的数据平台架构实际上还是从业务需求和全流程系统成熟度出发,把批处理系统和实时处理系统进行了结合。
对于各种组件的组合需求,伴随着云原生时代的到来,出现了越来越多更加易于直接“组装使用”的 SaaS 数据产品。相比之前部署运维 Hadoop,Kafka 集群的复杂度,新一代的云原生产品一般都可以直接使用托管服务,按量付费,即开即用,对于非互联网类公司来说非常友好。所以常见的数据平台架构都开始往引入各种产品组件的方向发展,出现了很多有意思的新思路:
著名的投资机构 a16z 给出的统一数据架构总览就很具有代表性:
这张图画得非常详细,把整个数据流转的过程分成了数据源(一般不包含在数据平台里),数据获取与传输,存储,查询处理,数据转换和分析输出这几大块,而且每一块中的各个模块,相关的产品都做了详细的标注。一般企业都会根据需求来选择其中的部分组件进行部署,例如如果没有流式数据的需求,那么就不需要下面那部分流式数据接入和处理的部分。而跟 Lambda 架构不同的是,对于同一个业务场景,一般也不需要让同一份数据既经过实时处理链路,又在 T+1 时经过批处理链路做两次,而是选择合适的一条链路去做后续处理即可。
不过上述的架构图因为考虑到不同企业不同场景不同阶段的需求,画的有些过于复杂了,个人更喜欢在《Designing Cloud Data Platform》一书中,作者给出的一张相对精简的架构总览:
这个架构在核心上与 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