湖仓一体架构理论与实践汇总

软件研发本质上属于“手工业”。软件研发在很大程度上还是依赖于个人的能力。当软件规模较小时，依赖“手工业”可以解决问题，但是当软件规模大了之后再依赖“手工业”就不行了。

软件的复杂度包含两个层面：软件系统层面的复杂度和软件研发流程层面的复杂度。

在软件系统层面上，针对大型软件，“when things work，nobody knows why”俨然已经是一种常态。

对于大型软件来讲，复杂才是常态，不复杂才不正常。

软件系统很难一开始就做出完美的设计，只能通过功能模块的衍生迭代让软件系统逐步成型，然后随着需求的增加再让功能模块进行衍生迭代，因此本质上软件是一点点生长出来的，其间就伴随着复杂度的不断累积。

软件生长示意图

软件复杂度的分类

最常见的错误方式是采用DDD（Deadline Driven Development，期限驱动开发），用Deadline来倒逼研发团队交付业务功能。但大量的实践经验告诉我们，软件研发就是在需求范围、软件质量、时间进度这个三角中寻求平衡的。

软件研发的三角平衡

上述做法从表面上看可以更快地取得进展，快速摘取成功的果实，但是经过一段时间之后（一般是6～18个月），负面效果就会凸显出来，会显著降低研发的速度和质量。而且这种负面效果是滞后的，等问题能够被感知到的时候，往往已经形成一段时间，软件架构的腐化就是这样在不知不觉中形成的。

以上这种急功近利的做法，本质上是将长期利益让位于短期利益，过度追求短期交付效率，最终的结果只能是“欲速则不达”。

正确战略方向下的“慢”，远远好过错误方向下的“快”。作为技术管理者必须学会两者之间的平衡之道，并为此长期承担后果。

软件工程的发展

软件工程 1.0

“软件工程1.0”，即第一代软件工程，自然是受建筑工程、水利工程等影响的传统软件工程。

传统软件工程主要是向土木工程和工业工程学习，吸收其百年实践积累下来的方法和经验，以及沉淀下来的思想。

软件工程1.0体现了以下特征：

(1)产品化：只是交付符合质量标准的组件、构件和系统，没有认识到软件的柔性和数字化特性，把软件当作传统工业的产品，由此产生“软件工厂”这样的思想。

(2)结构化：受传统建筑工程的影响，重视框架和结构的设计，表现为以架构设计为中心进行结构化分析、结构化设计、结构化编程等。

(3)过程决定结果：流程质量决定产品质量，一环扣一环，相信良好的过程产生良好的产品，关注过程胜过关注人，非常关注过程评估和过程改进，CMMI （Capability Maturity Model Integration，能力成熟度模型集成）就是其典型代表。

(4)重视质量管理：引入传统的质量管理体系，包括以顾客为中心的全面质量管理和缺陷预防。

(5)阶段性明确：需求评审通过才能开始设计；设计评审通过才能开始实施（编程），编程结束再进行测试等，瀑布模型是其典型代表模型。

(6)责任明确：角色定义清晰，分工细致。

(7)文档规范化：强调规范的文档，定义了大量的文档模板。

(8)计划性强：具有完整的计划并严格控制变更。

(9)注重项目管理：围绕项目开展管理工作，包括风险预防、里程碑控制、关键路径法等。

软件工程 2.0

受互联网、开源软件运动、敏捷/DevOps 开发模式的影响，最终形成的建立在SaaS （Software as a Service，软件即服务）、云之上的软件工程定义为“软件工程2.0”。

开源软件运动让我们首先认识到：

• “软件过程”和“软件管理”并非非常重要，至少不是第一要素，因为第一要素还是人；

• 其次是软件架构，简单且能解耦，如采用SOA（Service-Oriented Architecture，面向服务的架构）、微服务架构来解耦，更具可扩展性；

• 再者是代码的可读性、可测试性，使代码具有可维护性，而流程和管理虽然具有价值，但作用不大。

互联网的普及、开源软件运动以及市场的变化（更激烈的市场竞争、客户希望的按时高质量产品、灵活性、及时修改满足新需求等）以及加上软件本身是一种知识性产品，所有这些都引导人们对软件工程进行新的思考并不断认识软件工程，从而在2001年17位软件开发轻量型流派掌门人联合签署了《敏捷软件开发宣言》。

之后逐渐形成了敏捷/DevOps 开发模式、精益软件开发模式等，即软件工程进入2.0时代。软件工程2.0的特征可以简单概括为下列几点：

(1)SaaS：软件更多的是以一种服务存在。

(2)强调价值交付：只做对用户有价值的事情，加速价值流的流动。

(3)以人为本：个体与协作胜于流程和工具，充分发挥个人和团队的创造性与潜力；拥抱变化，敏捷开发或轻量级过程，加速迭代，以不变应万变。

(4)自我管理的团队：像一家初创公司一样运营，具有主动性并能够承担风险，具有自治能力，能自主建立目标和制订计划，不断反思，持续改进。

(5)持续性：阶段性不明确，持续构建、持续集成、持续测试、持续交付，以时间换空间，消除市场风险。

(6)开发、测试和运维的融合：强调测试与开发融合，开发与运维融合，推崇全栈工程师等。

(7)真正把用户放在第一位：用户、产品经理尽可能参与团队开发过程，注重用户体验，千人千面。

(8)知识管理：将软件工程纳入知识管理的范畴，强调将项目的计划、估算等工作授权给从事具体工作的开发人员，如任务安排不再由管理者下达任务，而由开发人员自主选择适合自己的任务。

(9)更有乐趣：“史诗故事”、用户故事、站会等让软件开发工作更有趣、更健康。

软件工程3.0

随着将GPT-4+（指GPT-4及其未来升级的版本）融入软件开发生命周期中，开发人员的使命将会发生变化，因为GPT-4+重新定义了开发人员构建、维护和改进软件应用程序的方式。

之后的软件开发会依赖这种全新的语言交流方式（类似于ChatGPT），让这类工具理解开发人员交代的任务，自主完成软件开发，如理解需求、自动生成UI、自动生成产品代码、自动生成测试脚本等。

此后，开发团队的主要任务不再是写代码、执行测试，而是训练模型、参数调优、围绕业务主题提问或给出提示。

因此，我们说GPT-4将开启“软件工程3.0”新时代，2023年是软件工程3.0的元年，软件工程3个时代的划分如下图：

软件工程3个时代的划分

GPT-4+ 在 软件工程上的能力：

1、软件需求获取、分析与定义

2、软件设计与体系结构（提供建议、识别设计模式、分析和优化软件体系结构，以及分享最佳实践和框架方面的知识，为软件开发人员提供有价值的帮助等）

3、代码生成和优化（如代码生成、代码补全、代码评审、代码优化等工作）

4、测试用例和测试代码等生成

5、错误检测和解决

6、协作和知识共享（如在团队讨论、头脑风暴会议、代码审查时提供实时帮助，形成会议纪要、总结，理清逻辑和发现问题，并提供有价值的见解等）

GPT-4+支持更智能、更高效和协作的开发方法，给软件工程领域带来了革命性的变化。软件开发的新范式是模型驱动开发、模型驱动运维，在 DevOps 两环前面，加一个环形成三环联动，如下图所示：

软件工程3.0开发范式示意图

其中机器学习(Machine Learning，ML)中的要素有模型(Model)、数据(Data)，而研发经过计划(Plan)、创建(Create)、验证(Verify)、打包(Package)、发布(Release)等环节进入运维，运维有两个关键环节：配置(Configure)和监控(Monitor)。

由此我们可以看到，在软件工程3.0时代，软件即模型(Software as a Model，SaaM)，这个模型不同于过去软件工程1.0或软件工程2.0时代所谈到的抽象模型［（如UML中的模型、OMG（Object Management Group，对象管理组织）］所提的模型驱动架构(Model Driven Architecture，MDA)中的模型，

而是深度神经网络模型、大型语言模型(Large Language Model，LLM)或其他人工通用智能(Artificial General Intelligence，AGI)模型，可以直接给人类提供服务的模型。

在基于MaaS的软件工程3.0时代，软件以这类AI大模型的形态为用户提供各种各样的服务，而且未来会成为一种常态。

框架与时代的演变

VUCA 时代

VUCA（中文发音一般为“乌卡”）的含义如下：

● V：Volatility，易变性。

● U：Uncertainty，不确定性。

● C：Complexity，复杂性。

● A：Ambiguity，模糊性。

VUCA 时代信息无时无刻不在发生变化，用户的需求也无时无刻不在发生变化，甚至用户自己也不知道想要什么。

MVP(最小可行产品)

21世纪初，产品创新领域提出了MVP（Minimum Viable Product，最小可行产品）来面对VUCA时代，其中的思想源头是人们思维方式的迭代。

演绎、归纳和假设-演绎逻辑

而MVP就是产品人对“假设-演绎”方法论的应用。通过MVP方法不断完善产品，这是一个螺旋上升的过程，每一次产出既是目的，也是手段。作为目的，创造了用户价值，满足了用户需求；作为手段，让我们获得反馈，知道下一次迭代应该做什么。这样，我们就把做产品从一次研发的“有限游戏”变成不断螺旋上升的“无限游戏”。

M2V6P 框架

在MVP的基础上，笔者扩展出了自己的M2V6P方法论框架，主要原因是觉得一开始就做产品还不够“低成本”，其实可以更灵活。

M是Minimum，最小化的意思，意味着每一步都要尽量少地投入。

2V是Viable（可行性）和Valuable（有价值），这里加了一个V，是因为产品创新要面临两大风险，这里用Viable表示要对抗技术风险，用Valuable表示要对抗市场风险。

6P的含义：

第一个P是Paperwork，案头研究，重点考查问题是否存在，是否值得解决。

第二个P是Prototype，原型样机，重点考查是否有解决方案。

第三个P是Product，产品本身，要看解决方案能不能产品化。

第四个P是Promotion，营销推广，考虑的是如何把数量做大。

第五个 P 是 Portfolio，产品组合，是在单一产品的基础上，要推出更多相关的成功产品。

第六个P是People，人才，考虑的是更长周期，即当行业兴衰不可避免时，组织如何永续。

其中，前两个P(Paperwork+Prototype)对应前产品阶段。

中间两个P(Product+Promotion)对应单一产品阶段。

最后两个P(Portfolio+People)对应产品矩阵阶段。

某公司数据湖仓一体化实践

某公司大数据技术的历史状况

某公司的中台产品-数字云的架构是基于Hadoop生态体系构建而成的，在存储方面使用了分布式文件系统HDFS(Hadoop Distributed File System)，首先利用自研的数据同步工具Data-in 定时同步业务系统的数据到数据中台，然后利用不同的数据处理引擎分别进行离线和实时计算的加工。

离线数仓（数仓为数据仓库的简称）的加工采用Hive 作为离线数仓工具，以Tez 为数据计算引擎的架构方案，每天定时对数据进行加工和处理并给到业务方。

离线数仓的数据采集、计算任务的调度周期大多数都以天为颗粒度。为了能够在第二天上班前计算好报表数据，数据采集任务都集中设置在凌晨执行，因此凌晨成为资源消耗的高峰期。

针对需要实时处理的场景，需要再投入大量资源建设一个实时数仓；

由于离线与实时使用的技术栈不统一，因此系统需要投入更多的资源来维护。

这样的弊端有：

1、每天数据全量同步给数据库，给数据库造成巨大压力，也增加了业务系统的不稳定因素，给集群的存储带来较大压力成本

2、集群的资源利用率不均，凌晨高峰期紧张，白天资源大部分处于限制状态。

离线数仓架构

数字云在实时数仓上采用的是 Lambda 架构，设计之初是为了在处理大规模的数据时，同时发挥流处理和批处理的优势。

通过批处理提供全面、准确的数据；

通过流处理提供低延迟的数据，

从而达到平衡延迟、吞吐量和容错性的目的。

Lambda架构有实时链路和批处理链路两条数据链路，数据采集使用流式同步工具，数据流实时地流向两条链路。

实时数仓使用Canal、Debezium等CDC(Change Data Capture)工具。

批处理链路的数据会落地到Hive数仓；

实时链路为了提升数据使用的可重复性，将数据写入 Kafka 消息队列。

在实际的业务场景中，一般企业的做法是同时利用 Lambda 和离线数仓两种方式搭建架构。

这种架构的缺点是引入的组件多、架构复杂，维护成本高；实时计算和批处理的计算结果不一致会导致数据质量等问题；存在两个编程接口，需要开发两套程序，增加了开发人员的工作量与代码的维护难度。

Lamba 架构

某公司大数据技术遇到的挑战

户业务的复杂度不断提升，数据计算任务随之不断增加，这在应用层面上对惟数云的技术提出了新的挑战。

(1)离线和实时的任务分离。

数据开发人员需要维护两套不同的技术代码和任务：

基于Flink的实时采集运算和基于Hive的离线任务调度，使数仓的开发、使用、运维都有诸多不便。同时，也会导致数据计算冗余。

Flink处理当天的实时数据，每日凌晨离线的Hive又将业务系统白天产生的数据重新加载一遍进行批量计算，这样同一份数据在实时计算与离线计算中分别被存储起来，增加了额外的存储成本，而且因为离线计算需要在每日新增数据全部被重新采集后才能进行数仓模型的运算，所以就使得前端数据指标的计算时间被压缩。

(2)历史数据更新困难。

在传统企业中，由于交易性数据业务的特殊性，需要更新历史订单数据，Hadoop并不支持对行级数据的单独更新和删除操作，因此需要将历史数据与变动数据进行全量匹配才能找出更改的部分，需要将历史数据与变动数据进行重新合并才能实现数仓中的数据与业务系统中的数据的一致性，这样通常会因为对一小部分历史数据的更新而把上千万条历史数据进行重算，大大浪费了服务器的资源。

数据架构技术发展阶段

随着企业业务与技术的发展，大数据架构也经历了数据仓库、数据湖、湖仓一体三个发展阶段。

数据仓库主要满足了企业内部业务部门对经营数据局部数字化分析的需求，让结构化数据能够被标准化加工处理和分析应用。

2011年衍生于“数据湖”的大数据架构技术，典型的开源技术是以 Hadoop 提供分布式存储和分布式计算为基础的大数据架构中的“数据湖”技术。

数据湖的特点：数据存储的格式灵活多样，针对结构化、非结构化的原始数据都能进行很好的兼容，强调存储与使用的灵活性和兼容性，方便使用者随取随用。

湖仓一体的概念于2020年被首次提出，指将数据湖与数据仓库的架构进行融合，是一种将数据湖的灵活性和数据仓库的易用性、规范性、高性能结合起来的新型融合技术，这项技术既满足了数据仓库的规范化建设，也体现了数据湖使用的便捷性。

湖仓一体技术趋势

湖仓一体技术的核心思想是将数据仓库和数据湖之间进行联通，实现数据存储和计算架构的统一化与标准化。同时，数仓一体技术还能够支持多种数据类型的存储和访问，并通过提供统一封装的接口实现数据之间的共享。

湖仓一体技术的最大优势在于，它兼具了数据仓库的高性能和标准化管理能力及数据湖的灵活性与扩展性。它能够充分利用现有的数据资源降低数据管理的成本，同时提高数据分析与挖掘的效率和精度。

业界流行的“数据湖三剑客”：Delta Lake、Apache Iceberg和Apache Hudi，这三项技术的设计初衷都是为了解决企业在实际业务场景中遇到的数据处理问题，但是由于设计思想不同，它们有各自的优劣和不同应用场景下的定位。

Delta Lake

Delta Lake：它的设计定位于流批一体的数据处理，是Databricks公司基于Spark推出的数据湖方案，增强Spark在流批处理场景下支持数据库事务的ACID［ACID是指数据库事务正确执行四要素的首字母缩写，原子性（Atomicity，或称不可分割性）、一致性(Consistency)、隔离性（Isolation，又称独立性）、持久性(Durability)］能力。

早期，客户在建设实时数仓时通常采用 Lambda 架构，该架构的实时场景使用Kafka作为存储层，流批处理任务都从Kafka获取数据进行分析处理。这种情况存在一些问题：Lambda架构方案需要的组件多、架构复杂，Kafka存储能力有限；缺失全局的 Schema 规范，上下游处理时导致 Schema 不一致；数据操作过程没有ACID保障，可能会读到中间状态的数据；不支持历史数据更新。

为此，Databricks公司推出了Delta Lake方案来解决由Lambda架构维护实时、批量两套数据处理逻辑带来的重复开发、数据口径不一致、架构复杂等问题。

Apache Iceberg

Apache Iceberg：Apache Iceberg 技术定位于高性能的分析与可靠的数据管理，其设计目标是一种开放通用的表格式实现方案，可以认为是介于上层计算引擎和底层存储格式之间的一个中间层，通过定义数据的元数据组织方式向计算引擎提供统一的类似于传统数据库中“数据表”的语义。

Netflix公司早期基于Hive构建数据湖方案，但发现Hive在设计上存在诸多不足，如Hive分区颗粒度太大，分区的数据文件多；在执行简单查询时，分区裁剪阶段耗时长；依赖外部数据库存储信息；处理流程烦琐，先要通过数据库获取分区信息，再通过HDFS在每个分区上按目录遍历所有文件。当文件很大时，这种遍历非常耗时。因此，Netflix设计了自己的轻量级Apache Iceberg数据湖方案。

Apache Hudi

Apache Hudi是Uber基于自身的业务特点发明的一个增量处理框架，以低延迟和高效率为业务关键数据管道提供动力，目的是解决HDFS增量的更新能力。

Hudi通过对文件的插入更新和增量拉取两种方式来实现流式入湖和增量更新的功能。

Uber的核心业务场景是将线上业务库的数据实时同步到数据中心，供上层业务做分析处理。

Uber的早期方案也是基于Kafka做数据处理，这种设计最大的问题是无法快速Upsert存量数据。为了解决数据的更新问题，Uber团队在设计Hudi时，提供了COW(Copy On Write)和MOR(Merge On Read)两种数据格式。其中，MOR表是为快速更新而设计的；COW表在写入时将新数据和旧数据合并后再写入全量数据，写入延迟高。

上述三种数据湖技术均通过不同的方式实现了支持事务的 ACID 特性、多种存储类型（HDFS、对象存储），适配多种主流计算引擎(Spark、Flink)、模式演化、开放数据格式(Parquet、Arvo)，历史数据回溯等。

三种技术的实现逻辑均是数据湖和数据存储的中间层，核心管理能力都是基于Meta的元数据文件，通过统一的处理语言来实现处理和更新底层不同类型的数据文件。Meta文件的作用类似于数据库中的Catalog和WAL，能够管理Schema、事务等。

Meta文件包含大量的元数据信息，基于这些元数据信息，数据湖技术可以实现数据表的Schema演化、事务ACID的支持等核心特性。由于Meta文件的内容每次发生变更都会生成一份全新的Meta文件，因此存在多个版本的Meta 文件，这样系统在上层功能就可以实现数据的多版本控制。数据湖技术通常都会强依赖这些Meta文件来管理表信息，若Meta文件被删除或者存放的目录被更改，数据就会受到永久破坏。

湖仓一体实践案例

湖仓一体采用经典的分层架构模式，具有高内聚、低耦合的特点，可以降低数据存储的耦合，各层承担各自的职责，结构清晰、可扩展性高。

某公司基于Hudi的湖仓一体顶层架构设计分为三层：数据存储、资源计算和数据应用。

每一层都专注于各自的领域，实现最佳技术组合与实践；

由于技术栈的高度标准化，每一层都覆盖了前沿的创新技术，从技术产生的作用这一维度，每一层又可细分为多层。

综合以上湖仓一体架构设计思想所遵循的标准化、规范化、精细化、敏捷等特点，企业可以灵活选择最优的方案。

但是，由于湖仓架构设计覆盖面广、技术栈众多、技术细节复杂，因此企业在推动建设“湖仓一体”数据中心之前，需要充分考虑当前的业务场景、发展规模、企业的中远期战略规划等综合因素。

某公司数据湖仓一体顶层架构设计图

在引入Hudi之后，某公司数据湖仓一体不仅可以统一对接各种格式的数据（包括结构化数据和半结构化数据）存储，并且支持 OSS、S3、HDFS 等存储系统，而且还可以提供对 ACID、表结构的变更。

另外，基于对 Snapshot 读取不同历史版本数据等功能的支持，惟客数据湖仓一体不仅可以管理数据湖的存储，而且还可以做到对原有数据仓库进行统一管理，在表结构层做到统一入口，下图所示为基于Hudi架构的数据文件合并原理图：

基于Hudi架构的数据文件合并原理图

该湖仓一体架构基于Flink CDC、Hudi、Hive、Presto等技术实现数据实时、增量入湖的能力，同步方式支持单表、多表、整库多种模式。

数据源类型支持行业主流的数据库，如典型的 MySQL、Oracle、MongoDB 等数据库。

通过Flink CDC技术监听数据库的归档日志，在上层业务增加、更新数据库之后，同步任务会先接收到数据变更事件，再通过数据管道流向Hudi并最终落地形成文件。

Hudi内核支持 ACID 特性，为了提高 Hudi 的整体读/写吞吐量，使用缓冲、增量日志追加等方式写入文件系统。

Hudi写入时会先写入固定大小的instant文件块，Hudi内部会维护一个 Timeline（时间线），并记录 instant 在时间轴上的操作。

在 Hudi 接收到Compaction合并事件后，Hudi会启动独立作业执行合并动作，将instant文件中记录的更新、删除等操作合并到列式存储格式的数据文件中，供上游查询和分析使用。

Hudi整库同步能力可以将大量任务合并成一个任务，简化了任务配置。所需的资源用量有所下降，集群的资源利用率得到整体提升，为企业的数字化建设降本增效。

基于商业地产客户的湖仓一体架构图

商业客户已经自建了HDFS，并且在旧架构的基础上有一定的数据建设基础，因此提供了一套可融合的技术架构来对旧架构进行升级：基于 Flink CDC + Hudi 的技术架构，其能实现数据的实时秒级同步，针对变动数据进行增量更新，数据采集的方式包括单表和整库，从架构设计上充分保证数据与数据源的一致性。

为了创建和管理基于湖仓一体的大数据运算任务，某公司数据中台构建了集数据开发、数据质量管控、数据安全管理、数据服务能力等功能于一体的一站式数据开发及管理平台，通过对底层复杂的大数据技术的封装形成低代码的开发能力，以减少底层复杂的技术环节，在保证数据安全的同时，利用平台的低代码能力让数据开发人员可以快速、专注地面向业务需求的数据进行开发和运维；实现了敏捷开发、质量管理、安全保障的目标；对企业数据进行统一管理与运营，提升了数据质量和交付效率，能更快、更准、更便捷地获取与使用数据。

通过对该企业数据仓库架构的升级，提高了数据计算和存储的效率，节约了画像标签及数据报表的产出时间。以前，基于离线计算的报表和标签，由于需要进行针对历史数据的更新，因此每日不得不刷新近百张数据表，其中有些数据表的数据量达到数千万行，历史数据从采集到合并的过程耗费近4小时的计算时间。在采用了湖仓一体架构之后，利用Flink CDC可以捕获历史变动的单条数据，并实时更新到数据湖，让数据湖中的数据无须经过快照匹配就能与数据源保持一致，整个计算过程大大缩短，给后续大批量的画像标签与报表计算节约了时间，充分保障了第二天数据产出的准时性。

在未升级到湖仓一体架构前，运营人员每天都要观测整体的运营数据，以便及时对业务进行调整。由于旧数据不支持更新操作，因此每间隔一小时都要将新增数据接入，与历史数据进行比对形成最新快照供前端查询，但由于数据量过大，基于Hive的分析查询效率较慢，所以前端用户获取到最新的数据有小时级的延迟。在升级到湖仓一体架构后，Flink CDC的及时入湖及上层Trino的快速访问和计算能力，使数据在业务系统中更新后，10秒之内就能反馈到前端业务运营报表上，数据的及时性得到大大提升。

白话数据湖仓一体化

数据库

数据库主要用于「事务处理」，存取款这种算是最典型的，特别强调每秒能干多少事儿：QPS（每秒查询数）、TPS（每秒事务数）、IOPS（每秒读写数）等等。

数据仓库

通常是业务发展到一定规模后，业务分析师、CIO、决策者们，希望从大量的应用系统、业务数据中，进行关联分析，最终整点“干货”出来。

比如为啥利润会下滑？为啥库存周转变慢了？向数据要答案，整点报告、图表出来给老板汇报，辅助经营决策。

可是，数据库“脑容量不足”，擅长事务性工作，不擅长分析型的工作，于是就产生了数据仓库。

虽然现在HTAP的概念很盛行，也就是混合事务/分析处理，用一套数据库架构来同时支持事务(OLTP)和分析(OLAP)两种需求，但真正大规模的分析和洞察，还是离不开数据仓库。

数据仓库相当于一个集成化数据管理的平台，从多个数据源抽取有价值的数据，在仓库内转换和流动，并提供给BI等分析工具来输出干货。

因为分析型业务需要大量的“读”操作，所以数据仓库通过“Denormalized”化的方式优化表结构，减少表间联接，牺牲空间来换取读性能。（一张表里的冗余数据增加了，但查询起来却更快了），并使用列式存储优化，来进一步提高查询速度、降低开销。

再结合面向分析场景的Schema设计，数据仓库就可以高效率、全方位、多维度的扛起“联机分析”重任了。

数据库和数据仓库的区别

数据湖

数据库负责干事务处理相关的事，数据仓库负责干业务分析相关的事，还有新兴的HTAP数据库既干事务又干分析，都已经这么内卷了，还要数据湖来干个毛线？

说白了，还是企业在持续发展，企业的数据也不断堆积，虽然“含金量”最高的数据都存在数据库和数仓里，支撑着企业的运转。

但是，企业希望把生产经营中的所有相关数据，历史的、实时的，在线的、离线的，内部的、外部的，结构化的、非结构化的，都能完整保存下来，方便“沙中淘金”。

数据库和数据仓库都干不了这活儿，怎么办呢？

挖个大坑，修个湖，把各种数据一滚脑灌进去囤起来，而且要持续灌，持续囤。这就是数据湖啦！

数据湖的本质，是由“➊数据存储架构+➋数据处理工具”组成的解决方案，而不是某个单一独立产品。

➊数据存储架构，要有足够的扩展性和可靠性，要满足企业能把所有原始数据都“囤”起来，存得下、存得久。

一般来讲，各大云厂商都喜欢用对象存储来做数据湖的存储底座，比如 Amazon Web Services（亚马逊云科技），修建“湖底”用的“砖头”，就是S3云对象存储。

➋数据处理工具，则分为两大类↓

第一类工具，解决的问题是如何把数据“搬到”湖里，包括定义数据源、制定数据访问策略和安全策略，并移动数据、编制数据目录等等。

如果没有这些数据管理/治理工具，元数据缺失，湖里的数据质量就没法保障，“泥石俱下”，各种数据倾泻堆积到湖里，最终好好的数据湖，慢慢就变成了数据沼泽。

因此，在一个数据湖方案里，数据移动和管理的工具非常重要。

比如，Amazon Web Services提供“Lake Formation”这个工具，帮助客户自动化地把各种数据源中的数据移动到湖里，同时还可以调用Amazon Glue来对数据进行ETL，编制数据目录，进一步提高湖里数据的质量。

ETL:是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。ETL一词较常用在数据仓库，但其对象并不限于数据仓库。

第二类工具，就是要从湖里的海量数据中“淘金”。

数据并不是存进数据湖里就万事大吉，要对数据进行分析、挖掘、利用，比如要对湖里的数据进行查询，同时要把数据提供给机器学习、数据科学类的业务，便于“点石成金”。

我们继续拿Amazon Web Services来举例子，基于Amazon Athena这个服务，就可以使用标准的SQL来对S3（数据湖）中的数据进行交互式查询。

再比如使用Amazon SageMake****r机器学习服务，导入数据湖中的数据进行模型训练，这些都是常规操作。

小结一下，数据湖不只是个“囤积”数据的“大水坑”，除了用存储技术构建的湖底座以外，还包含一系列的数据入湖、数据出湖、数据管理、数据应用工具集，共同组成了数据湖解决方案。

数据仓库和数据湖的区别

从数据含金量来比，数据仓库里的数据价值密度更高一些，数据的抽取和Schema的设计，都有非常强的针对性，便于业务分析师迅速获取洞察结果，用与决策支持。

而数据湖更有一种“兜底”的感觉，甭管当下有用没有/或者暂时没想好怎么用，先保存着、沉淀着，将来想用的时候，尽管翻牌子就是了，反正都原汁原味的留存了下来。

而从产品形态看，数据仓库可以是独立的标准化产品，拿云上数仓来举例，Amazon Redshift，就是一款“数仓产品”。

数据湖则是一种架构，通常是围绕对象存储为“湖底座”的大数据管理方案组合。比如，Amazon Web Services并没有哪个产品叫“数据湖”，而是以S3为基础，结合****一系列数据管理工具，帮助客户构建云上“数据湖”↓

湖仓一体化

曾经，数据仓库擅长的BI、数据洞察离业务更近、价值更大，而数据湖里的数据，更多的是为了远景画饼。

随着大数据和AI的上纲上线，原先的“画的饼”也变得炙手可热起来，为业务赋能，价值被重新定义。

而因为数仓和数据库的出发点不同、架构不同，企业在实际使用过程中，“性价比”差异很大。

数据湖起步成本很低，但随着数据体量增大，TCO成本会加速飙升，数仓则恰恰相反，前期建设开支很大。

总之，一个后期成本高，一个前期成本高，对于既想修湖、又想建仓的用户来说，仿佛玩了一个金钱游戏。

于是，人们就想，既然都是拿数据为业务服务，数据湖和数仓作为两大“数据集散地”，能不能彼此整合一下，让数据流动起来，少点重复建设呢？

比如，让“数仓”在进行数据分析的时候，可以直接访问数据湖里的数据（Amazon Redshift Spectrum是这么干的）。再比如，让数据湖在架构设计上，就“原生”支持数仓能力（DeltaLake是这么干）。

正是这些想法和需求，推动了数仓和数据湖的打通和融合，也就是当下炙手可热的概念：Lake House。

Lake House，坊间通常称之为“湖仓一体”，而Amazon Web Services则叫做“智能湖仓”。

Lake House架构最重要的一点，是实现“湖里”和“仓里”的数据/元数据能够无缝打通，并且“自由”流动。

湖里的“新鲜”数据可以流到仓里，甚至可以直接被数仓使用，而仓里的“不新鲜”数据，也可以流到湖里，低成本长久保存，供未来的数据挖掘使用。

为了实现这个目标，Amazon Web Services推出了Redshift Spectrum，打通了数仓对数据湖的直接访问，能够高效查询S3数据湖当中的EB级数据。

“Spectrum”是智能湖仓的核心组件，被称为“Lake House引擎”，它可以在湖与仓之间架起数据流动的管道↓

➊可以将数据湖中最近几个月的“热数据”摄取到数仓中；

➋反过来，也可以轻松将大量冷门历史数据从数仓转移至成本更低廉的数据湖内，同时这些移到湖里的数据，仍然可以被Redshift数仓查询使用;

➌处理数仓内的热数据与数据湖中的历史数据，生成丰富的数据集，全程无需执行任何数据移动操作；

➍生成的新数据集可以插入到数仓中的表内，或者直接插入由数据湖托管的外部表中。

但是，在实际业务场景下，数据的移动和访问，不仅限于数仓和数据湖之间，搜索引擎服务、机器学习服务、大数据分析服务……，都涉及到数据在本地（本系统）和数据湖之间的移动，以及数据在不同服务之间的移动。

数据积累得越多，移动起来就越困难，这就是所谓的“数据重力”。

所以，Lake House不仅要把湖、仓打通，还要克服“数据重力”，让数据在这些服务之间按需来回移动：入湖、出湖、环湖……

把数据湖和数据仓库集成起来只是第一步，还要把湖、仓以及所有其他数据处理服务组成统一且连续的整体，这就是Amazon Web Services为何把自家的Lake House架构称为“智能湖仓”，而非“湖仓一体”。

“湖仓一体”只是开局，智能湖仓才是终极

智能湖仓并非单一产品，它描述的是一种架构。

这套架构，以数据湖为中心，把数据湖作为中央存储库，再围绕数据湖建立专用“数据服务环”，环上的服务包括了数仓、机器学习、大数据处理、日志分析，甚至RDS和NOSQL服务等等。

大家“环湖而饲”，既可以直接操纵湖内数据，也可以从湖中摄取数据，还可以向湖中回注数据，同时环湖的服务彼此之间也可以轻松交换数据。

任何热门的数据处理服务，都在湖边建好了，任何对口的数据都能召之即来、挥之则去。依靠这种无缝集成和数据移动机制，用户就能从容地用对的工具从对的数据中，挖出干货！

智能湖仓六层架构

这个六层架构，从数据源定义、数据摄取和入湖入仓，到湖仓打通与集成，再到数据出湖、数据处理和数据消费，一气呵成，各种云上数据服务无缝集成在一起。

数据从各种源头“流入”到智能湖仓存储中，又按需流出，被处理、被消费。

在“智能湖仓”架构下，企业可以轻松汇集和保存海量业务数据，并随心所欲地调用各种数据服务，用于BI、可视化分析、搜索、建模、特征提取、流处理等等，未来新的数据源、新的分析方法，也可以快速应对。

同时，数据湖的存储底座S3成本低廉并有近乎无限的扩展性，“湖边”大量的数据分析和处理的服务又是无长期成本的Serverless架构，企业“入坑”智能湖仓之后，完全没有后顾之忧。

甚至可以认为，“智能湖仓”架构是比所谓“数据中台”更能落地和务实的“中台”，如果数据中台是个饼，那智能湖仓就是把饼“烹熟烤香”的锅~

数据湖仓一体化的一种技术体系的实操流程

hive是基于Hadoop的一个数据仓库工具，用来进行数据提取、转化、加载，这是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。hive数据仓库工具能将结构化的数据文件映射为一张数据库表，并提供SQL查询功能，能将SQL语句转变成MapReduce任务来执行。Hive的优点是学习成本低，可以通过类似SQL语句实现快速MapReduce统计，使MapReduce变得更加简单，而不必开发专门的MapReduce应用程序。

MapReduce是一种编程模型，用于大规模数据集（大于1TB）的并行运算。概念"Map（映射）“和"Reduce（归约）”，是它们的主要思想。是一种面向大规模数据处理的并行计算模型和方法

Flink CDC：

Flink 是一个分布式计算框架。

cdc我们可以理解为可以检测某个对象的数据变更记录的工具。说的再形象点就是有一个工具，在启动的时候就可以开启某个对象的监听，这个对象有任何操作变更的时候，这个工具都能感知到，所以这样的工具我们把他称为cdc。

flink的cdc就是一个自定义的datasource，他里面集成了debezium和kafka的功能，简化了我们开发和运维部署debezium和kafka工具的工作。使得我们在flink里面初始化cdc的配置里面进行下配置，然后我们就可以直接读取到mysql binlog这样的数据。

例如我们有一个场景，需要监听mysql表的变化，如果mysql的某个库的某张表里面有变化，我们需要把对应的信息进行解析处理，然后把数据写入新的mysql。这时候我们一般怎么做呢？那肯定是先使用cancel或者Debezium监听mysql的binlog。然后把数据处理后发送到kafka，然后再使用消费者从kafka里面获取数据进行业务操作。

Flink CDC 支持很多数据库，如 mysql、mongodb、oceanbase、sqlserver、oracle、postgresql等等

1、分层规划

湖仓一体化四层分层架构

2、分层构建的完整流程

湖仓一体分层构建的完整流程

3、该技术体系下实现的湖仓一体的优势

1、使用 Hudi 搭建数仓

（1）沿用传统数仓中的分层思想

（2）不需要做复杂的拉链表

（3）不需要全量增量表，延迟低，近似为实时的离线数仓

（4）Hudi自动解决小文件问题

（5）所有层的数据均可在Hive中通过Hive的同步表进行查询（底层只有一份数据）

2、使用 HiveCatalog 持久化数据

HiveCatalog 作为表元数据持久化的介质，在生产环境一般采用HiveCatalog 来管理元数据，这样的好处是不需要重复使用DDL创建表，只需要关心业务逻辑的SQL，简化了开发流程，可以节省很多时间。

在 Flink 中创建表，表的元数据可以保存到 hive 的元数据中，元数据不会丢失。

3、使用 Flink SQL 进行开发

基于 yarn-session 的 SQL-client 可以在提交任务时候动态申请 TM 个数。

4、引入 Hive 的系统函数作为 Flink 的内置函数

原本 Flink 中不支持 Hive 的语法，例如 split，在加载 hive 模块之后就可以进行使用了。

5、集成 StreamX 进行 Flink SQL 调度

4、环境准备

1、编译 Hudi 源码

安装 Maven、Java 等等组件

2、Hudi 集成 Flink

集成时，可以将元数据集成至 HiveCatalog（可以先默认配置个元数据），操作如下：

3、Hudi 集成 Hive

集成时，可以初始化 Hive 元数据库。

4、准备模拟数据

通常企业在开始搭建数仓时，业务系统中会存在历史数据，一般是业务数据库存在历史数据，而用户行为日志无历史数据。

1、日志数据

可以启动日志采集通道，包括 Flume、Kafka 等之后生成日志。

Flume是Cloudera提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。

Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。 这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像Hadoop一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息。

Hadoop是一个由Apache基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。Hadoop实现了一个分布式文件系统（ Distributed File System），其中一个组件是HDFS（Hadoop Distributed File System）。HDFS有高容错性的特点，并且设计用来部署在低廉的（low-cost）硬件上；而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。HDFS放宽了（relax）POSIX的要求，可以以流的形式访问（streaming access）文件系统中的数据。Hadoop的框架最核心的设计就是：HDFS和MapReduce。HDFS为海量的数据提供了存储，而MapReduce则为海量的数据提供了计算

2、业务数据

可以执行模拟生成业务数据的命令，如生成某天的历史数据。

5、湖仓一体之 ODS 层

ODS 层的设计要点如下：

1、ODS 层的表结构设计依托于从业务系统同步过来的数据结构

2、先使用 Flink SQL 建表，然后将数据源进行 insert 的操作，并补齐缺失的字段

在 ODS 层实现 数据入湖操作：

（1）用户日志 保存到 kafka 的 tpopic_log 中就成为流式数据，该业务日志数据入湖时就以流式数据的方式入湖（进入 hudi 中）。

（2）业务数据 保存到 mysql 中的 gmall 表格中就成为数据库数据，如果要以数据流（流式数据）的方式入湖，则需要：

​ ① 对表格数据进行实时监控（监控数据的更新、修改等）：通过 flinkCDC 转换为流式数据

​ ②然后就可以入湖了（insert into hudi 表 select * from gmall(数据库表)，将数据写入hudi中）

6、湖仓一体之 DIM 层

DIM 层设计要点：

1、DIM 层的设计依据是维度建模理论，该层存储维度模型的维度表。

2、日期维度采用文件导入

如商品维度表、优惠券维度表、活动维度表、地区维度表、日期维度表、用户维度表等。

7、湖仓一体之 DWS 层

设计要点：

1、DWS 层的设计参考指标体系

2、DWS 层表名的命名规范为 dws_数据域_统计粒度_业务过程_统计周期

3、使用flink的sum()函数才可以回撤更新

4、维度关联的维度表选择，使用hudi流读作为维度表将导致后续的维度表变化，引发过期的数据大范围改变；使用lookup join 读取维度表的形式不会对先前的数据进行修改，但是无法实时变更。

如最近一日汇总表、某个用户消费汇总表、省域订单汇总表等

8、湖仓一体之ADS层

设计要点：

1、是最终的需求层

2、要考虑后续进行可视化展示的需求

使用 flink 的 mysql-connector 连接器，将结果直接导入到 mysql 中，方便后续进行可视化展示。

汇总结果、统计结果再放在 hudi 中就不合适了，需要放到数据仓库、数据库中。

因此需要使用 MySQL 创建目标表格，存储结果数据。

9、可视化展示

这里使用 Superset 进行结果的可视化展示。

Apache Superset是一个开源的、现代的、轻量级BI分析工具，能够对接多种数据源、拥有丰富的图标展示形式、支持自定义仪表盘，且拥有友好的用户界面，十分易用。

由于Superset能够对接常用的大数据分析工具，如Trino、Hive、Kylin、Druid等，且支持自定义仪表盘，故可作为数仓的可视化工具，应用于数据仓库的ADS 层。

湖仓一体化一种技术体系下的完整技术落地流程

网易：基于 Apache Iceberg 湖仓一体系统 Arctic

Arctic 是一个开放式架构下的湖仓管理系统，在开放的数据格式之上，Arctic 提供更多面向流和更新场景的优化以及一套可插拔的数据自优化机制和管理服务。

更关注数据库的数据如何实时的更新到湖仓里。

网易数据开发现状与痛点

1、T + 1 架构

T + 1 离线数据生产

数据源来自于数据库，或大量的业务日志（如客户端的日志、服务器的日志、传感器里收集上来的数据等）。这些大量的原始数据进入到离线数仓之后，会做数据分层的开发、处理。

数据分层的目的是为了实现数据的复用。需求时多样的，不可能从原始数据到最终结果完整的去做一次数据存储，这样会浪费大量的存储和计算成本。

这里的分层用的也是传统的分层架构：ODS 层、DWS层、ADS层.

分层数据主要存在 hive中，计算引擎会使用 hive sql，后面转为了 spark sql。

面向解决市场会用 impala 进行数据的分析。

一般是凌晨时间进行调度，第二天早上产出结果。这就是 T + 1 架构。

2、T + 1 架构之上引入实时链路

随着对数据延迟的要求越来越高，T + 1 已不满足。于是引入实时链路。

初步引入实时化

在 T + 1 架构之上，重构、引入了实时链路。

实时链路采用的存储为消息队列，计算引擎采用 flink 这样的实时计算引擎，flink 很难做到像 hive 一样的数据分层，只能根据实际的需求去写个 flink 任务，从源头把数据接进来，经过聚合、清洗之后，写到像图库这样的实时的数仓里面，然后再实时的数仓里面进行分析，或者接入到其他的能够支撑实时更新的系统里，如数据库里。

于是就分成了两条链路：

实时链路就是依据需求开发的，也没有很好的设计规范。可能会存在着很多重复的计算：即你有需求，你就去开发。

更加复杂的实时化

随着接入实时的这条链路的业务越来越多，简单的去写一个 flink 任务可能已经无法满足。实时场景下逻辑会越来越复杂，比如实时场景下需要维度数据，以前的维度数据对应的维度表就是存在 hive 的一张 hive 表就够了，但 hive 表是没办法去做实时的点查的，那就还需要一些 kv 系统，比如一套 HBase。另一方面，实时链路没有数据分层，它的数据复用度很差，资源浪费很严重，因此开始在实时链路上做一些数据分层，比如把清洗好的表或公共使用的表，放在一个单独的 kfaka topic 里面，所以存储以 kfaka 为主，会引入 hbase 作为 kv，然后去做简单的分层，最终数据会落在 kudu 上。

然后在业务应用上面的话，比如既要用到历史的数据，也要用到实时的数据，会把历史的 hive 数据 和 kudu 里面的最近的数据做一个业务层面上的聚合，统一之后再反馈给业务系统。

3、流批分割的 Lambda 架构

流批分割的 Lambda 架构

这种流批分割的开发模式下，会有以下的问题：

1、数据孤岛（Kudu 等）：要使用 hbase、kfaka、kudu 等等不同的存储系统去满足业务需求，还需要同步工具将这些存储在存储系统里的实时数据同步到离线里来。

• 而这些存储系统就需要独立采购和部署
• 冗余存储浪费成本
• 难以数据复用和互通

2、研发体系割裂：实时和离线是用不同语言开发的（spark sql、flink sql 等）

• 研发人效低
• 研发规范不通用
• 应用层视图合并复杂

3、指标和语义二义性（开发语言、表的定义不一样的时候，聚合时很难保证正确性）

网易的湖仓一体系统 Arctic 核心技术

为了解决上述问题，网易提出了 Arctic 湖仓一体系统。

Arctic 是定义在Hive/Iceberg 表格式之上，计算引擎之下的 TableService，并提供表结构优化以及 Kafka、redis、Hbase 等KV存储封装的实时湖仓系统。

Hive 的摄取与计算场景

上图是一个 T+1 的 hive 计算场景。一个批的数据，进行了 T+1 或者 T+H 的摄取，再进行批的计算，每次都进行了全量的摄取或计算，在此基础上引入了 Iceberg 和 Deltalake。

Iceberg/Deltalake 的摄取与计算

抽象出 Snapshot 概念，通过快照隔离实现 MVCC 和 ACID，支持数据实时摄取。

Arctic 在 Iceberg 的基础上，将 Batch 和 Stream 写入的文件进行区分，分为 change store 和 base store。

通过异步的 optimizing 对 stream 写入的文件进行合并，并提供了小文件治理、唯一键保证和 upsert 的能力。

并通过 ArcticTable 封装的接口提供 merge on read，实现准实时的读写能力。

Primary Key Support

Arctic Table 支持：

支持 Primary Key

支持 CDC ingestion

​ 实现 Upsert 语义

主键唯一性约束实现

​ Merge on read

​ optimize

未来扩展 SortKey/AggKey

在架构上把 Arctic Table 划分为多个 Table store，流写入叫 Change store，批写入叫 Base store，并通过 table optimize 实现 primary key 的唯一键约束。

primary key 提供的是 upsert 语义，包括 CDC ingestion，Batch Insert 的时候可以实现基于组件的更新，并通过 merge on read 保证唯一性约束。

每个 table store 的实现都是一个 iceberg 表，未来在提供 base store 之外，还会提供 SortKey、AggKey。

对 Arctic Table 做了两种 Optimize，

一种是短周期的 Minor Optimize，大约 5 到 10分钟执行一次，主要提供小文件的治理，把写入 change store 中间的 equal delete 转换 pos-delete。

另外一种是长周期的 Major Optimize，大约 1 天执行一次，将 insert file 和 change file 合并到 base file，当合并的 major optimize 执行完成之后，就只有 base 表，base 文件与 hive 格式完全兼容。

Arctic Table——流批一体表（支持CDC）

为了增强流处理下的应用场景，进行了 hidden queue 封装，在 Arctic table 内部封装kafka，对实时性要求高的上游任务进行双写，即往 change store 写同时也写入 hidden queue，下游直接从 kafka 消费，以此达到秒级甚至毫秒级的 CDC。如果不开启 hidden queue，上游只写 change store，下游利用 iceberg incremental poll 实现分钟级别订阅，整个双写过程通过 Arctic-Flink-connector 进行封装。

在双写情况下会遇到一致性问题，比如上游 Flink 任务在双写的时候，要保证毫秒级和秒级延迟，需要先写入 kafka，再写入 iceberg 文件，可能会在写入的时候，任务发生故障，导致 iceberg 文件并没有提交，而下游已经消费了未提交的数据，如果上游任务做了 failover 会导致部分数据重发，下游重复消费。

为解决这个问题，arctic 在双写的时候用回撤方式对消息提供了最终一致性的保证，所有写入 Kafka 的消息均进行了一次封装，每一个消息带上上游 writer 对应的 state 周期，即当前的 checkpoint 的 index。在下游任务发生 failover 之后，会根据 checkpoint 恢复，先发出 Flip 消息，下游任务收到 Flip 消息之后，会自动的从 Kafka 中扫描找到对应的需要回撤的消息并进行 retract 操作，整个流程在 Arctic-flink-connector 封装，屏蔽业务层面双写带来的一致性问题，业务层面只需要将 Arctic 当成流表使用。

同时为了支持将 Arctic 当维表使用，实现了一个 hidden 的 index，内部封装了 Hbase或 Redis，支持在上游写入实现双写，数据写入 redis 或 HBase，下游不需要关心实现细节，将 Arctic 当成维表使用，但这种情况下，目前没有比较好的办法解决一致性，未来会实现 flink1.12 中提出来的时态表 temporal join，无需依赖外部 KV。

支持 Temprol join

网易云音乐的应用案例：

它是一个推送系统分析，有两张主站埋点的 log 日志，及算法埋点的 log 日志。设备库是一个 mysql 维表同步。分析师想要知道推送的效果，需要通过报表进行查询。它是通过一个 IP 的查询来回的 join 这些表，走的批的流程，跟原来的批计算流程完全一致。如果分析师在报表分析之后，去做算法上的优化。可以在架构不发生变化的情况下，立刻推送到面向流的应用，同样是个 left join，但是它走的流程全部是这种流的生产路径，数据全部经过 kafka 做来回的校验，最终推送到归因表中，最后由数据应用去使用流计算出来的结果数据，整个生产链路包括数据存储，指标也不存在二义性，只有一份的数据存储，任务等实现百分百复用。

CDC:Change Data Capture

阿里：阿里云 EMR + DLF 构建湖仓架构

E-MapReduce（简称EMR）是运行在阿里云平台上的系统解决方案。EMR构建于ECS或ACK之上，通过半托管的形式供您使用，可以对集群具有完全的管理操作权限。

唯品会：Hudi

引入 Hudi 把任务编程增量存储、增量计算以后，能够大幅降低整个大数据体系机器资源的消耗（包括计算资源的消耗和存储资源的消耗），不管是数仓还是OLAP引擎，在业务场景里都要投入较多的机器补充到整个资源池中以支持业务需求。

湖仓的引入可以控制资源的增长、提升资源的效率并且给业务带来更好的体验，实现降本增效。

本身体量规模不是太大时，数仓的存储和计算的集群可能就几十台或一两百台机器，那么湖仓的引入所带来的资源的减少的量可能并不能体现出来。而对于机器数量比较庞大，虽然不会成倍的提升，但只要能提升10%-20%，这个产生的边际效益就已经很大了。

单一的业务场景可能改变并不是很大，但是如果这个业务的数量足够多，那么带来的效果将会非常明显。

腾讯：腾讯云原生湖仓一体技术在大规模数据场景中的应用实践

一、最核心的是数据湖存储。腾讯云是基于COS对象存储，架构一层Table Fommat解决存算分离场景下的性能和业务需求，如：1、解决对象存储缺陷，2、稀疏索引加速，3、批流合一，4、元数据增强。

二、在计算层，数据湖使用的是Serverless计算服务，按需弹性、无限扩容。如果需要花很多精力关注底层资源，解决数据倾斜的问题，根据不同的引擎，使用不同的SQL语法，那么业务接入或者数据变现的周期，都会变得很长。基于不同的引擎，会有不同的缓存加速策略，目前腾讯数据湖主流使用的计算引擎是Presto、Spark。而SAAS化的元数据设计，其实是整个湖，也是湖仓一体最核心的内容。因为只有元数据统一，才可以把湖与仓的业务真正融合起来，而不仅仅是湖仓架构组合。

三、腾讯提供的SaaS级别的元数据管理是基于场景做了很多优化的。基于云上场景的元数据管理，使用传统的HMS架构性能是不够的，需要对依赖关系做很多优化。通过元数据的采集，打通上下游，主动爬取，识别，提供相关的元数据应用，比如通过数据自动发现以及数据血缘做链路追踪。

四、最上层的Interface提供客户操作入口，让客户有比较好的体验模块，核心点像任务调度，入湖模版等，降低客户接入的成本。再就是数据权限、IDE等能力，闭环业务开发需求。最右边会有云上或者作为一个产品化的功能项，例如认证、权限、日志、监控、计费等。

总结下来，腾讯云原生数据湖，数据湖DLC和数据湖构建DLF，核心价值有两点：引入iceberg并且构建iceberg生态，解决对象存储问题，达成成本和性能效果；统一元数据，为更宏观的数据湖解决方案提供元数据内核。

数仓建模平台

湖仓一体方案

上图蓝色部分是数仓建模平台，

绿色部分是数据湖底座。

湖仓一体统一存储设计理念很重要，在腾讯目前主打还是基于COS对象存储，但是平也有支持多种存储的能力。

各类型的数据通过入湖构建之后，可以通过数据爬虫爬取元数据，完成统一元数据构建。

在数据分析层面，在数据平台开发层接入像Presto、Spark等多种引擎，并与底层数据存储解耦。

腾讯的湖仓一体平台，其实是基于元数据的统一，在业务层面把仓与湖真正融合在一起。

统一元数据架构

腾讯元数据架构是基于特定的爬虫系统，把不同源端数据爬过来，再自己定义元数据模型，进行采集和存储。

统一元数据不仅仅是统一数据湖，也包含仓的统一，打通湖到仓的元数据治理。通过如上一整套从湖到仓统一元数据架构，让元数据的应用可以满足不同场景的需求。

落地：文章索引设计流程

通过数据入湖到COS，进行统一存储，基于数据发现自动构建底层数据湖表。业务的逻辑分为两个方面，一个是实时业务开发，基于数据湖分析的能力，敏捷支撑分析需求。第二个是基于数据湖Spark引擎小时级别去做数据指标的聚合，落地周期性的快照表，对接仓的标准实现分层数据建设。