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

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

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

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

在软件系统层面上，针对大型软件，“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 架构，设计之初是为了在处理大规模的数据时，同时发挥流处理和批处理的优势。

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