大数据云原生技术发展研究报告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为云原生进行了重新定义：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式APL这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。”新的定义继续保持原有的核心内容：容器和微服务，加入了服务网格、不可变基础设施和声明式APl这三个重要设计指导理念，并且强调了公有云、私有云和混合云等新型动态环境。(三)大数据与云原生结合分析从2018年起，一些开源大数据引擎陆续开始了OnKUberneteS的探索： 2018年3月，Sparkv2.3.0开始探索OnKubernetes 2018年6月，KubernetesAirflowOperator在正式发布 2019年8月，StarburstPresto宣布支持K8S 2020年2月，Flinkvl.10.0发布NativeKubernetesbeta版 2020年2月，HiVe探索MR3运行在KUberneteS上而到了2021年3月，ApacheSpark3.1正式支持了kubemetes,越来越多的企业开始在生产环境使用大数据云原生融合的技术。根据Pepperdata关于u2022BigDataonKubemetesReport,显示：来源：PePPerdata2022BigDataonKubemetesReport图9:大数据云原生融合情况与上云目的50%+的受访者正在将大数据应用迁移至KUbemeteS中，以降低整体成本。报告显示，迁移原因排名前四的是：1 .超过45%的受访者为了提高应用程序的性能和稳定性而选择将任务迁移至Kubernetes2 .为任务负载具备更高的灵活性和可移植性。3 .降低成本。4 .多云解决方案避免被一个云厂商绑定。从任务分布上可以看出：占比最高的大数据作业依次是Spark.PrestoKafka、Trino>Flink,可以看到基本上涵盖了大数据领域的批处理、交互式分析和流处理场景。国内外云厂商也一直加大产品技术在云原生(SerVerleSS)方向的投入和引导。亚马逊云科技在2022年re:InVent中宣布其大数据核心产品已全面Serverless化，阿里云在2023年云栖大会上将Serverless作为大会主题之一，包括大数据在内的多款云产品均发布了其Serverless相关的产品能力。单纯从技术趋势的角度来看，无论是技术还是产品，大数据云原生化都是发展的必然趋势。与云原生融合的一些其它声音，也值得我们关注：值得一提的是，在数据库领域，对于“数据库是否应该放到K8S”这个话题有一些讨论，虽然大数据有一些不同，但可以参考：反方认为：维持已经成熟和可靠的系统不需要K8S：认为将数据库放入K8S中会导致“双输”K8S失去了无状态的简单性，不能像纯无状态使用方式那样灵活搬迁调度销毁重建；而数据库也牺牲了一系列重要的属性：可靠性，安全性，性能，以及复杂度成本，却只能换来有限的“弹性”与资源利用率，但虚拟机也可以做到这些。整体论点分为以下四点：1 .增加复杂度和不可靠性：K8S增加了额外的架构复杂度和潜在失效点。2 .性能挑战：在K8S上运行的数据库可能面临性能问题。3 .安全和合规风险：多租户环境和更多的组件依赖，增加数据库的安全威胁，使得审计和合规更加复杂。4 .成本和维护问题：尽管K8S在一定程度上简化了数据库管理，但可能无法抵消其自身引入的复杂度和维护成本。正方认为,数据库OiIK8S,是专业能力的普及化：这里的“专业能力”指的是高可用性、弹性伸缩、容错等能力，它们通常需要复杂的技术实现和专业知识。通过将数据库部署在K8S±,这些能力可以通过K8S的自动化和标准化机制更容易地实现和普及，降低了对专业数据库管理技能的依赖。整体论点主要也是下面四点：1 .资源弹性和伸缩性：K8S提供强大的资源弹性和伸缩性，适应业务需求的波动，在高峰期自动扩展资源，在低谷期收回，有效节约成本。2 .容器技术的优势：Docker等容器技术提供了轻量级和标准化的部署方式。容器对数据库性能影响很小。3 .K8S的运维能力：包括路由网关、水平扩展、监控、备份和灾难恢复等，这些能力有助于数据库的高可用性和持续运行。4 .高可用性等解决方案：固化高可用方案，提供主从秒级切换和数据一致性等特性。“它山之石，可以攻玉”，虽然数据库与数据平台在场景和技术架构上会有一些不同，但大数据云原生的融合在这个问题上依然值得借鉴思考。二、传统大数据平台的需求与痛点传统围绕HadooP生态构建的大数据平台，存在着交付运维成本高、资源利用率低、系统迭代与兼容性挑战和安全相关挑战。用户期望大数据云原生技术能够在这些方面为传统的大数据平台带来优化和改进。（一）交付运维成本高传统大数据平台的建设和维护目前是一个重要且复杂的任务。这些平台通常包括多种不同的组件，它们在技术栈、功能和架构上存在显著差异。这种多样性不仅使得平台的部署和配置变得极为复杂，也大幅增加了整体的运维成本。组件多样性导致较高的人力需求：大数据平台包含多种组件，这些组件在技术栈（如Java、C+）、功能（如流处理、批处理，OLAP）和架构（如C/S、MPP）方面各不相同。部署，配置和维护如此多样的技术栈需要大量的专业人力，特别是在部署和交付新的大数据平台时，人力资源的需求和成本会显著增加。运维专业性与效率：大数据组件的复杂性，具有较高的运维知识门槛。这不仅增加了运维团队的工作负担，还可能导致效率低下和更频繁的解决问题需求，从而增加成本。工具与管理挑战：许多大数据组件缺乏开箱即用的日志、监控和告警功能，导致运维团队需要为每个组件单独开发和适配这些工具。每个组件可能有各自的集群和管理界面，使得整个平台的统一管理和问题排查变得困难。这种分散性不仅降低了运维效率，还可能导致问题解决的延迟，增加了管理成本。云原生技术可以有效缓解传统大数据平台的运维挑战。容器化通过屏蔽不同组件间的技术栈和基础设施差异，简化了运维流程。工具如OPeratOr实现了服务部署和运维的标准化与自动化，降低了复杂性和人力成本。在云原生架构下，应用和组件的更新仅需拉取新镜像并重启容器，确保环境一致性，加速应用发布。此外，云原生环境提供统一管理界面，集中处理不同服务的发布和运维，提高问题监测和定位的效率。集成在KubernetesPods和节点的监控与告警工具，使得运维团队可以通过统一界面清晰监控基础设施和服务状态，有效跟踪系统性能和健康状况。（二）资源利用率低组件混部困难：传统的大数据平台，为了避免组件间的相互影响，组件的集群往往是相互独立部署的。这样虽然对于整体的编排来说相对简单，但是会降低资源利用率。业务波动性：由于大数据业务的特点，大数据组件在高峰期的资源利用率可以很高，但是在业务低峰期则会有较多闲置，此时集群整体资源利用率可能只有20%-30%,综合平均起来集群整体的资源利用率偏低。弹性扩缩容难度高：在业务高峰期时，如果现有的资源已经无法支撑业务，这个时候可能需要通过较为繁琐的运维流程扩容节点。到了业务低谷期时，这部分机器又很难通过运维流程快速下线，扩缩容的效率不高。云原生领域在基础资源基础上抽象出了“资源池（计算、存储、网络等的组合）”的概念，资源池被所有的大数据组件公用，按需申请，可以避免重复规划造成的资源浪费。资源池可以承载不同类型的大数据集群，可以是批处理、也可以是流处理、MPP等，得益于容器化较好的隔离性，不同的业务可以在一起混部，形成资源的分时复用；同时云原生领域有着丰富的工具来对资源池进行弹性扩缩容，甚至当业务不存在的时候降到零副本，做到随需启停，做到Serverless化。（三）系统迭代与兼容性挑战传统的大数据平台，组件开发迭代不敏捷，周期长。组件版本往往比较固定，版本升级难度比较大。在部署新的大数据组件到现有的HadOoP集群时。首先,必须确保这些新组件与现有的HDFS和Yarn版本兼容。由于许多新的大数据组件不支持旧版本的Hadoop,升级HadOOP可能导致现有组件失效。其次，部署时还需考虑到不同LinUX操作系统间的兼容性问题，这增加了额外的复杂性。因此，整合一个新的计算和存储组件到现有架构中通常是一个耗时的过程，可能需要几天甚至几周的时间。云原生的定义中先天具有DeVOPs、CI/CD的思想，可以比较容易地做到IaC(InfraStrUCtUreasCOde)和CaaS(ConfIgurationasaService)o组件的配置或代码在Git中进行保管，一旦发生变化，就会经过Cl的环节进行质量验证，然后通过CD的管道打包成容器镜像发布到运行环境中。由于云原生中都是微服务架构，你可以只单独发布组件的一部分，不必整体组件一起发布；在组件的发布过程中，也可以更方便地实现A/BTest、灰度发布、发布回滚等操作。同时云原生中都是容器，启停容器是轻量级动作，效率高。(四)安全相关挑战传统大数据平台，在安全方面面临着一系列挑战。包括数据隔离、综合访问控制、数据加密和保护、审计与合规性、网络安全、灾难恢复与数据备份等。针对这些挑战，大数据开源社区已经有一些解决方案，如使用Kerberos进行认证、Ranger或Sentry进行访问控制等，但这些解决方案往往伴随着配置复杂、灵活性不足、自动化程度低等缺点。相比之下，云原生技术社区也提供了面对安全问题更全面、灵活且自动化的安全解决方案。可以做到更好的网络隔离，数据隔离，权限隔离，灾备等。三、云原生技术解决大数据问题的思路(一)云原生技术提升运维交付质量与效率1、容器化云原生中部署的都是容器，容器的不可变基础设施属性，屏蔽了基础设施层对应用的影响：如应用的依赖包是否安装好，应用所在机器的CPU架构等，提高了应用程序的可移植性，大大降低了平台交付过程中环境标准化工作的成本。2、OPerator机制大数据组件种类繁多，每个大数据组件的安装和运维方式不尽相同，人力维护成本较高。Kubemetes中提出了使用OPerator的方式来管理复杂应用。通过OPerator的方式标准化了大数据组件的安装和运维，将复杂的安装步骤、大数据组件升级、高可用配置等运维操作自动化，减少了人工成本，同时也提高了运维工作的及时性和效率。3、统一的日志收集与监控报警在云原生技术栈中，日志收集展示和监控报警都有标准化的实现方式，如采用SideCar容器收集业务容器中的日志，采用Prometheus技术体系收集监控指标与配置报警规则。这样就可以用统一的方式将所有组件的日志和监控汇总到统一页面来查看，方便了问题的跟踪与定位。图10:kubemetes中常见日志收集方式4、声明式的APl在云原生中，APl都是声明式的，声明式会为大数据组件带来两个好处：资源抽象程度高：如果组件需要一个IG容量大小的块存储，不用运维人员感知然后手工去创建和配置，只要在APl中声明你需要的配置即可，整个流程都是自动化的；apiVersion:v1kind:PersistentVolumeClaimmetadata;name:my-pvcspec:StorageCIassNamestandardaccessModes:-ReadWriteOnceresources:requests:StOrage:1Gi图11:kub*netes声明式APl样例-存储面向终态：声明式APl是不断向着终态逼近的，假如我们声明了一个服务包含3个副本，如果其中某几个副本意外退出了，声明式APl会及时发现并且迅速拉起一个同样副本，始终保证服务的副本数的稳定，确保服务的整体可靠性。apiVersioniappsZvIkind:Depbymentmetadata:name:my-deploymentspec:replicas:3#副本数图12:kubemetes声明式API样例-计算资源副本数（二）云原生技术提升集群资源使用率和弹性1、混部云原生技术中，将整个基础资源层抽象成了一个大的资源池（计算、存储、网络等资源的组合），被所有大数据组件所共享。组件可以按需从这个大资源池中申请资源，这样避免了资源的重复建设，减少了资源浪费。同时这些资源池可以承载不同类型的大数据组件，如批处理、流处理、OLAP等，加上云原生提供的多种调度技术，可以将不同大数据组件一起混部，结合算法模型，可以预测各个组件的流量峰谷，从而形成了资源的分时复用，整体上提高了总体资源利用率。云原生提供的单机隔离技术CgroUp、KVM、Kata等可以有效的防止混部进程间的相互干扰，使得混部更加安全。大数据混部主要指离在线业务的混部，有如下几种常见思路：（1）在线离线业务完全容器化混部在该种思路中，新业务完全使用K8S调度，同时兼容在线集群，离线和在线大数据业务根据分时调度的策略，选择不同集群/节点运行。整体架构如图所示：任务提交大数据调ESparkJob &FlinkJobAppService ResourceScale out'dwn FtesourceWorkersStorageMiniOHDFS本地存储来源：https:/xie.infoqcn/article/812c3183d4a2507892534de76图13：在线离线业务混部示意图该思路的优点是管控集中，统一K8S调度管理，便于实现在线离线任务的灵活调配。缺点是目前社区大数据方案还不够成熟，旧的基于Yarn的大数据作业的兼容性无法保证，需要企业自身具备较强的大数据及云原生技术实力，且无需考虑历史作业的兼容。(2)HadoopYamonKubernetes模式在该种思路中，作业提交入口依然为YARN保持不变，整个计算资源的调度还是由YARNRM来执行，计算任务还是运行在YarnNodeManager中。整体架构如图所示：HadoopClusterK8sCluster来源：htpskrdimtor.sh图14:HadoopYarnonKubemetes集群模式混部示意图从上面架构图中，可以看到大数据集群和容器集群依旧是相对独立的，容器集群中会启动一个YamNodeManager（以下简称为YarnNM）的Pod,这里的YarnNM会自动连接到大数据集群的ResourceManager服务。这样的话，所有的业务代码和提交方式都不需要改变，等同于单独扩容了几台YarnNodeManagero该思路的优点是计算任务层无感知，兼容性好。缺点如下： 离线集群可扩展差，Yan）镜像中需绑定大数据集群的HoSt列表。 会有额外的资源消耗，NodeManager占用部分服务资源。 需要高版本的Yarn,低版本Yam不支持LiunxContainerCgroUP设置，可能会对在线资源有影响，需要考虑好CgroUP目录划分和驱逐策略。 额外的节点Yam标签管理工作。该种思路适用于大部分企业场景，改造成本更低、能够较好兼容现有大数据集群、效果明显。除此之外，会有企业在上述两类混部思路的基础上，实现更多组合优化方案。2、弹性伸缩云原生技术栈提供了HPA、KEDA等弹性扩缩容技术，结合统一监控收集到的组件业务指标和性能指标，可以实现大数据组件的资源弹性伸缩。在业务高峰期时，按需动态增加资源容量（CPU、内存、存储等），当业务低谷时，动态减少资源容量，甚至做到当业务无流量时，将资源容器缩容到0,从而进一步提高整体资源的弹性和利用率。同时由于容器的轻量级，弹性伸缩的速率很高，通过镜像预热等技术，可以更快的提高弹性扩缩容的速率。业务流量图15:弹性伸缩示意图(三)云原生技术提升大数据平台迭代效率利用云原生DeVOPS和持续交付的特性，基于现在比较流行的GitOPS方法论，可以方便得做到IaC(InfraStrUCeasCOde)和CaaS(configurationasaservice):将代码和配置存储在Git中，Git中的每一次提交会产生一个新的COmmitID,所以天然具有版本的概念。当Git中的文件发生变化，会产生一个新的版本(COmmitlD),同时通过CI/CD机制可以触发对这个版本的测试，当测试通过，会进行打包和部署；部署时可以结合灰度发布和服务网格等技术实现A/Btest,金丝雀发布安全发布方案。整体上提高从研发、验证到决策的效率。镜像仓库配置更新管理器GitConfig部署管理器大数据 operator图16:GitOps流程示意图常见的云原生发布策略有滚动更新与回滚、蓝绿发布、金丝雀发布策略，这些策略可以使应用发布的过程中实现应用的平滑升级，以减少对业务的影响。 滚动更新：确保应用程序在更新过程中保持可用。 滚动回滚：允许回滚到之前的版本。 蓝绿部署：一种在新旧版本之间进行切换的策略。 金丝雀发布：一种渐进性更新策略。相较于传统的大数据和分布式系统发布，云原生的容器发布提供了一种更为灵活、轻量、可移植性和隔离性的发布形式，使得大数据和分布式系统的部署和管理更为方便。（四）云原生技术提升大数据安全和隐私保护1、数据隔离与多租户安全：云原生技术栈中，有健全的多租户隔离机制来隔离不同用户的资源，防止不同用户间的恶意干扰。通过虚拟集群技术可以实现云原生API使用层面上的隔离、通过Kata等安全容器技术，可以实现容器运行时的强隔离，防止普通容器的逃逸问题发生；通过VPC等虚拟网络技术实现网络层面的隔离，防止端口扫描等恶意探测行为；云存储可以实现存储介质和IOPS上的隔离。多租户隔离可以分为硬隔离和软隔离，硬隔离为每个租户底层单独分配一个集群，从而达到隔离不同租户的目的，适用于为企业外部客户服务的场景，软隔离是多个租户共享底层计算，存储，网络资源。云原生强大的生态能力在网络层面，数据层面，控制面提供了多种隔离解决方案，多租户软隔离=网络隔离+数据隔离+权限控制。网络隔离：VPC网络(Kube-router),NetworkPolicy(Calico,Cilium)o数据隔离：安全容器Kata,运行时RuncCgroup,ResourceQuotas,1.imitRange9RequestZlimit,Namespace。权限隔离：基于RBAC的访问控制+鉴权+授权硬隔离软隔离图17:云原生安全隔离技术图示2、网络通信安全：Authenticatio请求用户是否 为集群合法用 户AdmissionController请求是否安全合规K8S内部微服务和K8S的通信使用非对称加密方式，服务之间通信使用证书/SA,具有双向认证功能，K8S内针对K8S对象的访问也基于RBAC准则，即访问控制+鉴权+授权，针对不同的用户限制了对集群资源的访问范围和权限，极大的减少了由于越权访问带来了安全问题。Authorization用户是否有权限进行请求中的操作图18:双向认证与权限控制3、数据加密与保护:想要实现端到端的数据加密在传统大数据平台上实施起来较为复杂。开源的方案有HDFS加密，TLS/SSL用于数据传输等，但加密配置可能复杂，且在某些场景下可能影响性能。而云原生解决方案可以提供内建的、透明的加密功能，能够在性能较小损耗的情况下实现端到端加密：数据完整性：云原生存储中，会通过校验码等机制来验证数据在传输和存储过程中没有损坏和篡改，保证数据的完整性。同时云原生技术栈中可以使用RAM/IAM等鉴权系统对资源进行精确的访问控制，可以细粒度到PV级别。同时当数据不用时，云存储会自动擦除云盘上的数据，防止残留。数据机密性：云原生技术栈中，从数据传输、计算、到存储都有完整的全链路加密方案，数据在网络传输时可以采用Htps、SSL、VPN等加密，使用HSM（密钥托管）等组件来实现证书的获取和管理；在数据的处理和计算过程中，可以采用数据脱敏技术对隐私数据进行隐藏，同时可以采用隐私计算等软硬结合技术实现安全沙箱容器，在内存级别实现对隐私数据的加密和隔离。在数据存储时，可以选择不同算法对数据进行加密存储，算法可以在申请PV（PersistentVolume,持久化存储）的时候进行指定。下图是全链路加密的示意图：依据传输数据计算败据存储图19:全链路加密示意图4、审计与合规性：云原生解决方案通常可以提供更全面和集成的审计日志功能，以及与合规性标准（如GDPR、HIPAA）的更紧密集成。这些平台能够自动记录更详细的操作日志，并提供更高级的数据保护和隐私控制功能，从而更有效地满足复杂的合规性要求。5、灾难恢复与数据备份在灾难恢复和数据备份方面，云原生解决方案可以提供自动化的、高效的备份和恢复解决方案:云原生技术基于微服务架构，每一个微服务一般都是多活架构，微服务架构将整体组件的复杂性进行了解耦，避免了服务的单点故障,提高稳定性和容错性；云原生存储在技术实现上都是多副本机制，可以避免少量副本意外丢失造成的数据不可用情况，保证了数据的高可用性；云原生技术栈中自带的负载均衡、服务发现、共享存储等机制，可以更好的实现组件的同城双机房，两地三中心等容灾部署。6、丰富的安全工具提升网络安全在网络层面的安全防护是传统大数据平台的薄弱环节。云原生解决方案有着丰富的安全类云产品或工具，如WAF、安全组、网络ACL等来对组件的安全进行防护，实现防止网络攻击、异常行为检测、异常代码扫描等。（五）云原生技术带来的其它好处除了解决上述传统大数据平台的痛点，云原生技术与大数据平台融合，还带来了以下好处：1、对跨平台的支持更加简便云原生架构的大数据平台对于适配不同的CPU架构和操作系统来说会更简便，得益于如下两个特点：首先，云原生技术栈及其配套工具普遍采用GO语言开发。作为一种编译型语言，Go提供了优秀的交叉编译能力和对不同平台的原生支持，这降低了针对多操作系统的适配和部署难度。其次，大数据组件在云原生环境中通常以容器形式运行。容器技术的不可变性和隔离性能有效地屏蔽了底层操作系统差异，加快了在不同环境中的适配速度。这两大特性共同增强了云原生大数据平台的跨平台能力，提升了其灵活性和可移植性。2、更便于实现混合云、多云架构随着公有云的更加普及，未来企业会有更多的混合云、多云的需求，遵循云原生规范的基于Kubemetes的大数据云原生架构，将极大地促进跨多云和混合云部署的便利性。这主要得益于以下几个方面：统一的管理和编排：KUbenleteS提供了一个统一的平台来管理和编排容器化的大数据应用。无论是在公有云、私有云还是混合云环境中，KUberneteS有希望提供一致的操作体验，简化跨环境部署和管理。灵活的资源调度：Kubernetes强大的资源调度能力使得在不同云环境中部署和扩展大数据应用变得更加灵活和高效。我们可以尝试根据应用的资源需求和可用性要求，智能地在多云或混合云环境中分配和优化资源。容器化的一致性：由于大数据组件在KUbemeteS平台上以容器的形式运行，这保证了应用在不同云环境中的一致性和可移植性。容器化的应用更好地在多个云环境之间迁移，无需针对特定云环境进行重大修改。网络策略和安全：KUberneteS提供了强大的网络策略和安全机