大数据云原生技术发展研究报告2023.docx

一、大数据平台与云原生技术的发展与演进1（一）数据平台的发展与演进1（一）云原生技术简述9（三）大数据与云原生结合分析12二、传统大数据平台的需求与痛点15（一）交付运维成本高16（二）资源利用率低17（三）系统迭代与兼容性挑战18（四）安全相关挑战19三、云原生技术解决大数据问题的思路20（一）云原生技术提升运维交付质量与效率20（二）云原生技术提升集群资源使用率和弹性22（三）云原生技术提升大数据平台迭代效率26（四）云原生技术提升大数据安全和隐私保护27（五）云原生技术带来的其它好处31（六）大数据云原生引入的新挑战35四、大数据云原生技术的架构简述40（一）云原生大数据平台的架构原则40（二）云原生大数据平台的参考架构41五、大数据云原生的未来发展和战略建议44（一）技术发展方向44（二）针对行业的建议44（三）针对企业和用户的建议45六、参考文献46而SBI RePOrtg机环学 W分析关系型数据库数据库数据仓库来源：CCSATC601 图1：数据分析技术演进图、大数据平台与云原生技术的发展与演进（一）数据平台的发展与演进需求催生技术革新，在海量数据需求的推动下，数据平台架构持续演进，经过数十年的发展，历经了数据库、数据仓库、数据湖、湖仓一体等概念。这里按出现顺序简述：（其中关于数据湖和湖仓一体目前业界有多种不同的定义，这里我们采用其中一种定义说明）eni_数据湖;ISMO）结构化、半结构化、非结构化数据数据湖大数据技术标准推进委员会数据库(DataBase):自1980年代初至中期起，数据管理工具主要呈现为数据库形式，以面向事务交易的OLTP场景为主，数据分析功能则作为辅助。这些数据库主要用于向管理层提供固定报表，支持宏观管理决策。它们通过标准SQL提供数据分析能力，主要代表产品包括OraCle、SqlServerMysql等。以前：提升单机性能：IBM小型机、EMC企业级存储、OraCIe企业级数据库ORACL于己三三三三车没有专门面向数据分析 场景的产品。当时还是 以面向事务交易场景为 主，数据分析仅作为附 带提供的场景。图2早期数据库阶段系统架构数据仓库(DataWarehouse):随着互联网的快速普及，门户、搜索引擎、百科等应用快速增长，数据量呈爆发式增长，原有的单个关系型数据库架构无法支撑庞大的数据量。20世纪90年代数据仓库理论被提出，核心是基于OLTP系统的数据源，根据联机分析处理OLAP场景诉求，将数据经过数仓建模形成ODS、DWD、DWS、DM等不同数据层，每层都需要进行清洗、加工、整合等数据开发(ETL)工作，并最终加载到关系型数据库中。数据源We”日志IoTETL >传统 企业数据仓库共享数据> H数据提取数据集市数据消费者来源：云原生产业联盟图3：C)LAP系统建设数据仓库架构是为了解决单个关系型数据库架构无法支撑庞大数据量的数据存储分析问题。传统数据仓库多为MPP(MassivelyParaneIPrOCeSSOr)架构，代表产品有Teradata、GreenPIUm等，当前MPP架构依然为新型数仓的重要选择，比如CIiCkHouse,Doris,StarRocks等。随着Hadoop技术的成熟与普及，基于Hadoop自建离线数据仓库(HiVe)是常见的大数据平台之上数据仓库方案，在目前依然发挥着重要的作用。数据湖(DataLake)：随着移动互联网的飞速发展，半结构化、非结构化数据的存储、计算需求日益突出，对数据平台提出了新的要求。以开源Hadoop体系为代表的开放式HDFS存储(或S3)、开放的文件格式、开放的元数据服务(HiVeMetaStore等)以及多种引擎(Hive、Spark、Flink、PreSto等)协同工作的模式，形成了数据湖的雏形。数据迁移分布式日志收集系统Flume分布式消息系统Kafka数据格式转化工具Sqoop集群管理与调度数据存储与管理分布式文件系统分布式列存数据库HDFSHBase关系式数据库MySQI .数据仓库（数据查询）Hive集群管分布式资源管理翡YARN数据计算分布式计算引擎MapReduce通用大数据快速处理引擎Spark分布式实时计算系统Storm分布式批流一体计算框架Flink集群协调分布式协调系统Zookeeper数据分析、挖掘、查询通用大数据快速处理引擎Spark分布式批流一体计算框架Flink收据仓库（数据查询）Hive来源：云原生产业联盟图4:Hadoop生态系统重要组件2010年，数据湖概念被提出，数据湖是一种支持结构化、半结构化、非结构化等数据类型大规模存储和计算的系统架构。数据湖与数据仓库的主要区别在于数据仓库中数据在进入仓库之前是需要实现归类，而数据湖是把大量原始数据通过廉价存储保存下来。数据湖架构的特点可总结为：低成本、原始数据、需灵活使用、面向任务数据绑定、不提前定义数据模型。表1数据湖与数据仓库对比表差异项数据湖数据仓库数据类型所有数据类型历史的、结构化的数据Schema读取型SChema写入型SChema计算能力支持多计算引擎用于处理、分析所有类型数据处理结构化数据，转化为多维数据、报表，以满足后续高级报表及数据分析需求成本存储计算成本低，使用运维成本高存储计算绑定、不够灵活、成本高数据可靠性数据质量一般，容易形成数据沼泽高质量、高可靠性、事务隔离性好扩展性高扩展性扩展性一般，扩展成本高产品形态一种解决方案，配合系列工具实现业务需求，灵活性更高一般是标准化的产品潜力实现数据的集中式管理，能够为企业挖掘新的运营需求存储和维护长期数据，数据可按需访问来源：CCSATC601从解决场景的角度来看，数据仓库和数据湖各有其适合覆盖场景,基本上属于互补关系，前者更多是解决固定的、明确的数据问题；后者则为应对随机性、探索式的数据问题。下图是一个示意图。SNO-ISWnOUMoUXUnUA-OUXKnownUnknownDATA来源：Gartne图5:数据仓库和数据湖的场景湖仓一体(LakeHouse):为满足多种数据类型存储、多场景分析等业务诉求，企业的数据采用混合部署模式，其中数据湖和数据仓库通过ETL进行数据交换，数据湖和数据仓库是两套独立的体系。企业应用分析(查询、统计、数据分析等)数据平台关系型数据库(OLTP)数据仓库-MPP数仓(OLAP)元数据数据集市SQL优化I 资源管理Ij大表关联I j用亍加教数据湖-HadOoPHDFSPresto仆数据源绮勾化、半结构化、非结构化)来源：CCSATC601图6:湖+仓混合架构图“数据湖+数据仓库”混合架构满足了结构化、半结构化、非结构化数据高效处理需求，解决了传统数据仓库在海量数据下加载慢、数据查询效率低、难以融合多种异构数据源进行分析的问题，但混合架构是技术向业务妥协的一个产物，存在数据冗余，增加存储成本，两个系统间额外的ETL流程导致时效性差，数据一致性保障低，混合架构开发运维复杂等弊端。2020年Databricks提出“湖仓一体”的概念，到目前技术和概念侧依然在持续演进。湖仓一体是指融合数据湖与数据仓库的优势，形成一体化、开放式数据处理平台的技术。通过湖仓一体技术，可使得数据处理平台底层支持多数据类型统一存储，实现数据在数据湖、数据仓库之间无缝调度和管理，并使得上层通过统一接口进行访问查询和分析。总的来看，湖仓一体通过引入数据仓库治理能力，既可以很好解决数据湖建设带来的数据治理难问题，也能更好挖掘数据湖中的数据价值，将高效建仓和灵活建湖两大优势融合在一起，提升了数据管理效率和灵活性。湖仓一体目前没有统一的架构，在企业需求的驱动下，各开源技术和厂商基于原有架构演进，数据湖与数据仓库在原本的范式之上扩展。逐渐形成了“湖上建仓”与“仓外挂湖”两种湖仓一体实现路径。如图7和表2所示。湖上建仓和仓外挂湖虽然出发点不同，但最终湖仓一体的目标一致。表2两种实现路径对比表实现路径优势劣势需解决的问题实现方向湖上建仓（HadooP体系）支持海且将4E离线批处理不支持高并发数据集市、即席查询、事务一致性等1 .统一元数据管理2 .ACID3 .查询性能提升4 .存储兼性问题5 .存算分离6 .弹性伸缩1.提升查询引擎、存储引擎能力仓外挂湖（MPP体系）一结数Ap务性彳O析事致构据分不支持非结构化/半结构化数据存储、机器学习等1 .统元数据管理2 .存储开放性3 .扩展查询引擎4 .存算分离5 .弹性伸缩1 .计算引擎不变，只扩存储能力2 .查询引擎扩展，提升查询引擎效率来源：CCSATC601仔堆湖：以MPF噪构的数仓为核心引擎，向外扩展其存储至IIDFS或对象存储。业务应用湖上建仓：以UadoOP体系演进的数据湖为基础, 弓I入数据仓库的数据治能力业务应用认 证 ff 权 跟湖仓数据治理数据仓库元数据内置存储HDFSl对象存储一统一元数据管理0数据源(日志、埋点、文本、音视频等)图7:湖仓一体架构模块图(二)云原生技术简述云原生的发展简述：云原生(CIOUdNatiVe),最初由PiVOtaI公司的MattStine在2013年提出，随后LinUX基金会在2015年成立了云原生计算基金会(CNCF)oCNCF不仅推广了云原生这一概念，还逐步构建了以云原生为核心的技术生态工具。到2018年，KUberneteS成为CNCF的首个毕业项目。目前，Kubernetes已经确立了在容器编排领域的领导地位,并推动了云原生技术的广泛应用。来源：httpscf.io 图8:云原生LandSCaPe (景观)指南2 曼色W云原生的核心思想：云原生普遍被认为包含四大核心要素：DeVOPs、微服务、持续交付和容器化。DevOps:DevOps是开发(DeVeIoPment)和运维(C)PeratiOnS)的结合，它推动了开发和运维团队的紧密协作。在DevOps文化中，软件的开发、测试、部署和监控过程是连续的，不断循环，旨在加快软件交付速度并提高质量。持续交付：持续交付是一种软件工程方法，它允许软件在短时间内且持续地被交付到生产环境。它通过自动化开发、测试和部署流程来支持频繁的版本发布，旨在减少发布新功能和修复的时间。微服务：微服务架构是一种设计方法，将应用程序分解为一组较小、相互独立的服务，每个服务都围绕特定业务功能构建，并可独立部署。容器：容器技术，如Docker,提供了一种轻量级、可移植的方法来封装、部署和运行应用。KUbemeteS(K8S)则发展为容器编排和管理的领导者，它提供了高级的部署、扩展和运行容器化应用的能力。CNCF重新定义云原生：随着云原生生态的不断壮大，CNCF基金会容纳的项目越来越多,到了2018年，原来的定义已经限制了云原生生态的发展，CNCF为云原生进行了重新定义：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹