(一)数据平台的发展与演进

需求催生技术革新，在海量数据需求的推动下，数据平台架构持续演进，经过数十年的发展，历经了数据库、数据仓库、数据湖、湖仓一体等概念。这里按出现顺序简述：(其中关于数据湖和湖仓一体目前业界有多种不同的定义，这里我们采用其中一种定义说明)

数据库(Data Base)：

自1980 年代初至中期起，数据管理工具主要呈现为数据库形式，以面向事务交易的 OLTP 场景为主，数据分析功能则作为辅助。这些数据库主要用于向管理层提供固定报表，支持宏观管理决策。它们通过标准SQL提供数据分析能力，主要代表产品包括Oracle、Sql Server、Mysql 等。

数据仓库(Data Warehouse)：随着互联网的快速普及，门户、搜索引擎、百科等应用快速增长数据量呈爆发式增长，原有的单个关系型数据库架构无法支撑庞大的数据量。20 世纪 90 年代数据仓库理论被提出，核心是基于 OLTP 系统的数据源，根据联机分析处理 OLAP 场景诉求，将数据经过数仓建模形成 ODS、DWD、DWS、DM 等不同数据层，每层都需要进行清洗、加工、整合等数据开发(ETL)工作，并最终加载到关系型数据库中。

数据仓库架构是为了解决单个关系型数据库架构无法支撑庞大数据量的数据存储分析问题。传统数据仓库多为 MPP(MassivelyParallel Processor)架构，代表产品有 Teradata、Greenplum 等，当前MPP 架构依然为新型数仓的重要选择，比如 ClickHouse，Doris，StarRocks 等。

随着 Hadoop 技术的成熟与普及，基于 Hadoop 自建离线数据仓库(Hive)是常见的大数据平台之上数据仓库方案，在目前依然发挥着重要的作用。

数据湖(Data Lake)：随着移动互联网的飞速发展，半结构化、非结构化数据的存储、计算需求日益突出，对数据平台提出了新的要求。以开源 Hadoop 体系为代表的开放式 HDFS 存储(或 S3)、开放的文件格式、开放的元数据服务(Hive Metastore 等)以及多种引擎(Hive、Spark、Flink、Presto 等)协同工作的模式，形成了数据湖的雏形。

2010 年，数据湖概念被提出，数据湖是一种支持结构化、半结构化、非结构化等数据类型大规模存储和计算的系统架构。数据湖与数据仓库的主要区别在于数据仓库中数据在进入仓库之前是需要实现归类，而数据湖是把大量原始数据通过廉价存储保存下来。数据湖架构的特点可总结为：低成本、原始数据、需灵活使用、面向任务数据绑定、不提前定义数据模型。

从解决场景的角度来看，数据仓库和数据湖各有其适合覆盖场景，基本上属于互补关系，前者更多是解决固定的、明确的数据问题;后者则为应对随机性、探索式的数据问题。下图是一个示意图。

湖仓一体(LakeHouse)：

为满足多种数据类型存储、多场景分析等业务诉求，企业的数据采用混合部署模式，其中数据湖和数据仓库通过 ETL 进行数据交换，数据湖和数据仓库是两套独立的体系

“数据湖+数据仓库”混合架构满足了结构化、半结构化、非结构化数据高效处理需求，解决了传统数据仓库在海量数据下加载慢、数据查询效率低、难以融合多种异构数据源进行分析的问题，但混合架构是技术向业务妥协的一个产物，存在数据冗余，增加存储成本，两个系统间额外的 ETL 流程导致时效性差，数据一致性保障低，混合架构开发运维复杂等弊端。

2020 年 Databricks 提出“湖仓一体”的概念，到目前技术和概念侧依然在持续演进。湖仓一体是指融合数据湖与数据仓库的优势，形成一体化、开放式数据处理平台的技术。通过湖仓一体技术，可使得数据处理平台底层支持多数据类型统一存储，实现数据在数据湖、数据仓库之间无缝调度和管理，并使得上层通过统一接口进行访问查询。和分析。总的来看，湖仓一体通过引入数据仓库治理能力，既可以很好解决数据湖建设带来的数据治理难问题，也能更好挖掘数据湖中的数据价值，将高效建仓和灵活建湖两大优势融合在一起，提升了数据管理效率和灵活性。湖仓一体目前没有统一的架构，在企业需求的驱动下，各开源技术和厂商基于原有架构演进，数据湖与数据仓库在原本的范式之上扩展。逐渐形成了“湖上建仓”与“仓外挂湖”两种湖仓一体实现路径。如图 7 和表 2 所示。湖上建仓和仓外挂湖虽然出发点不同，但最终湖仓一体的目标一致。

(二)云原生技术简述

云原生的发展简述：

云原生(Cloud Native)，最初由 Pivotal 公司的 Matt Stine 在 2013年提出，随后 Linux 基金会在 2015 年成立了云原生计算基金会(CNCF)。CNCF 不仅推广了云原生这一概念，还逐步构建了以云原生为核心的技术生态工具。到 2018 年，Kubernetes 成为 CNCF 的首个毕业项目。目前，Kubernetes 已经确立了在容器编排领域的领导地位，并推动了云原生技术的广泛应用。

云原生的核心思想：

云原生普遍被认为包含四大核心要素：DevOps、微服务、持续交付和容器化。

DevOps：DevOps 是开发(Development)和运维(Operations)的结合，它推动了开发和运维团队的紧密协作。在 DevOps 文化中，软件的开发、测试、部署和监控过程是连续的，不断循环，旨在加快软件交付速度并提高质量。

持续交付：持续交付是一种软件工程方法，它允许软件在短时间内且持续地被交付到生产环境。它通过自动化开发、测试和部署流程来支持频繁的版本发布，旨在减少发布新功能和修复的时间。

微服务：微服务架构是一种设计方法，将应用程序分解为一组较小、相互独立的服务，每个服务都围绕特定业务功能构建，并可独立部署。

容器：容器技术，如 Docker，提供了一种轻量级、可移植的方法来封装、部署和运行应用。Kubernetes(K8S)则发展为容器编排和管理的领导者，它提供了高级的部署、扩展和运行容器化应用的能力。

CNCF 重新定义云原生：

随着云原生生态的不断壮大，CNCF 基金会容纳的项目越来越多，到了 2018 年，原来的定义已经限制了云原生生态的发展，CNCF 为云原生进行了重新定义：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。”新的定义继续保持原有的核心内容：容器和微服务，加入了服务网格、不可变基础设施和声明式 API 这三个重要设计指导理念，并且强调了公有云、私有云和混合云等新型动态环境。

(三)大数据与云原生结合分析

从 2018 年起，一些开源大数据引擎陆续开始了 on Kubernetes 的探索：

 2018 年 3 月，Spark v2.3.0 开始探索 on Kubernetes

 2018 年 6 月，Kubernetes Airflow Operator 在正式发布

 2019 年 8 月，Starburst Presto 宣布⽀持 K8S

 2020 年 2 月，Flink v1.10.0 发布 Native Kubernetes beta 版

 2020 年 2 月，Hive 探索 MR3 运⾏在 Kubernetes 上而到了 2021 年 3 月，Apache Spark 3.1 正式支持了 kubernetes，越来越多的企业开始在生产环境使用大数据云原生融合的技术。根据 Pepperdata 关于“2022 BigData on Kubernetes Report”显示：

50%+的受访者正在将⼤数据应用迁移至 Kubernetes 中，以降低

整体成本。报告显示，迁移原因排名前四的是：

1. 超过 45%的受访者为了提高应用程序的性能和稳定性而选择将任务迁移至 Kubernetes。

2. 为任务负载具备更高的灵活性和可移植性。

3. 降低成本。

4. 多云解决方案避免被一个云厂商绑定产品已全面 Serverless 化，阿里云在 2023 年云栖大会上将 Serverless作为大会主题之一，包括大数据在内的多款云产品均发布了其Serverless 相关的产品能力。单纯从技术趋势的角度来看，无论是技术还是产品，大数据云原生化都是发展的必然趋势。

与云原生融合的一些其它声音，也值得我们关注：值得一提的是，在数据库领域，对于“数据库是否应该放到 K8S”这个话题有一些讨论，虽然大数据有一些不同，但可以参考：反方认为：维持已经成熟和可靠的系统不需要 K8S：认为将数据库放入 K8S 中会导致“双输”——K8S 失去了无状态的简单性，不能像纯无状态使用方式那样灵活搬迁调度销毁重建;而数据库也牺牲了一系列重要的属性：可靠性，安全性，性能，以及复杂度成本，却只能换来有限的“弹性”与资源利用率，但虚拟机也可以做到这些。

整体论点分为以下四点：

1. 增加复杂度和不可靠性：K8S 增加了额外的架构复杂度和潜在失效点。

2. 性能挑战：在 K8S 上运行的数据库可能面临性能问题。

3. 安全和合规风险：多租户环境和更多的组件依赖，增加数据库的安全威胁，使得审计和合规更加复杂。

4. 成本和维护问题：尽管 K8S 在一定程度上简化了数据库管理，但可能无法抵消其自身引入的复杂度和维护成本。

正方认为，数据库 on K8S，是专业能力的普及化：

这里的“专业能力”指的是高可用性、弹性伸缩、容错等能力，它们通常需要复杂的技术实现和专业知识。通过将数据库部署在K8S 上，这些能力可以通过 K8S 的自动化和标准化机制更容易地实现和普及，降低了对专业数据库管理技能的依赖。整体论点主要也是下面四点：

1. 资源弹性和伸缩性：K8S 提供强大的资源弹性和伸缩性，适应业务需求的波动，在高峰期自动扩展资源，在低谷期收回，有效节约成本。

2. 容器技术的优势：Docker 等容器技术提供了轻量级和标准化的部署方式。容器对数据库性能影响很小。

3. K8S 的运维能力：包括路由网关、水平扩展、监控、备份和灾难恢复等，这些能力有助于数据库的高可用性和持续运行。

4. 高可用性等解决方案：固化高可用方案，提供主从秒级切换和数据一致性等特性。

“它山之石，可以攻玉”，虽然数据库与数据平台在场景和技术架构上会有一些不同，但大数据云原生的融合在这个问题上依然值得借鉴思考