湖仓一体概念快问快答

概念篇 

问题一

“湖仓一体”是什么？                      

“湖仓一体”是一种新的架构模式，湖仓一体是将数据湖的灵活性和数仓的易用性、规范性、高性能结合起来的融合架构，无数据孤岛。湖仓一体数据存储在数据湖低成本的存储架构之上，既拥有数据湖数据格式的开放灵活性，又继承了数据仓库的高性能、易用性和规范性。

问题二

湖仓一体是伪命题吗？             

当然不是，湖仓一体是一种新的架构模式，虽然它将数据仓库与数据湖的优势充分结合，但它不同于数仓和数据湖的架构。很多新技术和新概念的出现都会伴随着用户的质疑，尤其是在中国数字化快速发展的过程中，甚至出现过昙花一现的新概念，让很多企业投入了无效资源。就湖仓一体这个概念，我们不妨参考下国际权威咨询机构 Gartner 对湖仓一体（Lakehouse）的定位，可以看到湖仓一体正处于快速发展的通道。

Gartner数据管理领域技术成熟度曲线

问题三

湖仓一体貌似是个国外的概念？可能不太适用于中国的国情吧?

有些技术的发展在国内外确实是存在较大差异，比如信息安全技术，APP 等，但在数据库和大数据基础领域，中国与国际的发展非常同步。一个冷知识：由于中国本土存在着非常多的企业有着海量数据需要管理（如四大行、三大运营商、互联网大厂），中国在大规模分布式数据库等方面的技术需求和土壤甚至要超过美国。得益于大型企业的超大数据体量和复杂管理需求，湖仓一体这一技术更可能在中国发展的更快更好。

  问题四   

可不可以理解为“湖+仓=湖仓一体”？             

很多用户误以为湖+仓=湖仓一体，可能是因为湖仓一体整合了湖和仓各自的优势，所以误认为湖仓一体就是原有湖和仓的简单整合而已。

站在技术架构的角度就会更容易理解这个问题，过往建设数据湖采用 Hadoop，建设数仓采用 MPP 数据库，很难想象 Hadoop+MPP=湖仓一体 会是怎样诡异的架构，因为 Hadoop 和 MPP 本身是无法兼容的，只能通过 Hadoop+MPP+统一管理组件 进行逻辑整合，这其实是我们常说的“逻辑湖仓一体”、“湖仓分体”。

所以，就像西红柿+鸡蛋≠西红柿炒鸡蛋，湖+仓≠湖仓一体，本质上是三种不同的事物，湖仓一体的架构与现有的湖和仓都不一样。湖仓一体的流行架构是存算分离，一份数据，多个计算引擎可以共享同一份数据。这种架构解决了 Hadoop+MPP 湖仓分体形成的数据孤岛。

问题五

云上的数据仓库和数据湖都是可以实现弹性扩展的，是不是可以理解为已经实现了湖仓一体?

很多云厂商都提供了数据湖和数据仓库架在自己的云底座上面的，确切的说是提供了云上的 MPP 和云上的 Hadoop，尽管实现了逻辑上的湖仓一体，但是湖+仓≠湖仓一体，云上的 MPP+Hadoop 仍然会各自形成数据孤岛和数据冗余，仍要通过复杂的管理组件实现仓和湖的数据同步，本质上大多数厂商的湖仓分体现状是一样的。

价值篇

问题六

除了技术架构，湖仓一体相较于逻辑湖仓一体、湖仓分体还有哪些不同？创新点在哪里？      

确实，新技术的优势不仅体现在技术架构上，必须在业务价值上形成创新点。为此我们经过多个项目实践和长期调研，总结出湖仓一体的六大创新点 ANCHOR，同时 ANCHOR 也可以作为检验湖仓一体的金标准。

All Disparate Data（多源异构数据）：支持关系表、文本、图像、视频等结构化数据和非结构化数据存储。

Native on Cloud（云原生）：适合云环境，自由增减计算和存储资源，按用量计费，节约成本。

Consistency（数据一致性）：通过完善的事务机制，保障不同用户同时查询和更新同 一份数据时的一致性。

High Concurrency （超高并发）：支持数十万用户使用复杂分析 查询并发访问同一份数据。

One Copy of Data（一份数据）：所有用户（BI 用户、数据科学家 等）可以共享同一份数据，避免数据孤岛，实现一份数据，就必须采用开放的格式。

Real-Time（实时T+0）：通过全量数据 T+0 的流处理和实时按需查询，满足基于数据的事前预测、事中判断和事后分析。

问题七

湖仓一体相较于逻辑湖仓一体、湖仓分体、湖上建仓，真正解决的痛点是啥？  

解决的痛点正如前文答案所述，都是围绕着 ANCHOR 六大价值点。除了实现了传统架构难以实现的一份数据、高性能和高并发、从离线到实时按需查询，湖仓一体架构为企业带来的价值也可以通过一组数字来说明：

• 平台共享一份数据，存储成本降低 2 倍

• 保障数据一致性，数据治理变得简单，治理工作量降低  3 倍

• 平台开发工作量降低  1 倍

• 平台维护成本降低 2 倍

问题八

湖仓一体技术栈如何选择？        

湖仓一体平台技术栈的选择可以从以下几个角度考虑：数据需求和业务场景、数据规模和性能要求、技术成熟度和生态系统、系统复杂度和维护成本、团队技术能力和培训成本。技术成熟度和可获得性方面，强烈建议抓住湖仓一体的本质——ANCHOR 六大特性：All Disparate Data（多源异构数据）、Native on Cloud（云原生）、Consistency（数据一致性）、High Concurrency （超高并发）、One Copy of Data（一份数据）、Real-Time（实时T+0）。

问题九

大家现在提湖仓一体，是“一体”更重要？还是湖和仓的“能力”更重要？        

在这个语境下，我们认为“一体”是一体化架构，“能力”是实现业务价值的能力。“一体”和“能力”的关系应该是怎样的？企业数据平台具备了湖仓一体的一体化架构，才拥实现业务价值的能力（即 ANCHOR 六大价值点），这是一个因果关系。单独的湖、仓、单独的仓、湖仓分体、逻辑湖仓一体都不能完全实现 ANCHOR 六大价值点。比如使用开放数据格式，形成一份数据，逻辑湖仓一体都是无法实现的。

问题十

建设完湖仓一体之后，湖在哪里仓在哪里？   

从概念上理解，湖仓一体架构不再区分湖和仓。从数据存储的角度，其数据存储在低成本的存储架构之上，既拥有数据湖数据格式的开放灵活性，又继承了数据仓库的高性能、易用性和规范性。过往，构建湖只能用 Hadoop 技术栈，否则存不下，做数仓就得用 MPP 数据库，这本来就是割裂的，而现阶的湖仓一体就不再有这样的问题，所以湖和仓都在新的一体化平台中，是架构上的统一。

问题十一

做湖仓一体是为了提升查询性能，湖仓一体的数据量会越来越大，如何保障性能？   

数据量越来越大恰恰是我们专注做湖仓一体的重要背景之一，也是湖仓一体重点要解决的问题。一个好的的湖仓一体架构本质上是存算分离的，因此，即便数据量越来越多，存储和计算资源也可以有针对性的扩展，保证平台在面对数据快速膨胀的情况下仍然能够高效执行复杂查询，此外，针对短时间内大量的查询需求，湖仓一体平台可以通过弹性资源临时增加计算资源来提升查询效率。

需要注意的是，查询性能不完全依赖环境资源，数据分区分片、索引优化、查询优化、存储优化、缓存优化等数据库调优策略都可以提升平台性能。

实施篇

问题十二

已经有数据仓库，将数据仓库改造成湖仓一体容易吗？        

目前的数据仓库基本都是基于 MPP 数据库构建的（当然也有用 Oracle 做数仓的情况)，MPP 存算耦合，扩展能力有限，而湖仓一体架构的本质要求是存算分离，因此要用支持存算分离、多计算集群架构的分布式数据库替换原来的 MPP，并和其他引擎（如 Spark/Flink 等）共享同一份数据。因此基于数仓的湖仓一体改造路径是进行传统MPP产品替换，并对既有模型和应用进行改造。

问题十三

已经有数据湖，是否可以将数据湖改造成湖仓一体？

数据湖基本都是基于 Hadoop 构建的，底层存储是 HDFS，因此将数据湖改造成湖仓一体理论上是可行的，但是需要注意的是，数据要采用①开放的格式，以及②存算分离改造。之所以对 Hadoop 平台进行存算分离改造，是因为大多数的 Hadoop 部署都是存算耦合的，存算分离改造的最佳方式就是引入存支持存算分离、多计算集群架构的分布式数据库，让多个引擎（如 Spark/Flink 等）可以共享同一份数据。

问题十四

你提到让DB、 Spark 和 Flink 等多个引擎共享一份数据，引擎之间如果进行分工？

引擎的分工方法和原则就是让不同引擎做它最擅长的事情。传统的数据湖和数据仓库主要处理三大类数据：结构化数据、非结构化数据、流式数据，因此可以有针对性采用不同引擎进行数据的处理。比如，针对流数据处理，建议使用应用广泛的 Flink；针对非结构化数据和机器学习等场景，建议使用 Spark；针对结构化数据的查询和跑批等核心场景，建议采用支持存算分离、多计算集群架构的分布式数据库，比如 OushuDB。

湖仓一体虚拟计算集群示意图

问题十五

目前我们企业既有湖也有仓，应该新建湖仓一体，还是基于湖和仓改造升级比较好？升级改造的话，是从湖到湖仓一体还是从仓到湖仓一体？

对于有湖有仓的用户，可以考虑从湖到湖仓一体的改造路线，并使用支持存算分离、多计算集群架构的分布式数据库替换传统的数仓，请参考上一个回答的详细内容。当然也可以考虑新建。

问题十六

基于原有的湖进行湖仓一体改造，改造工作量大吗？

改造的工作量有些是基于需求而变化的，这里我们可以讨论下一些必须的改造工作。

首先要看客户是不是有数据仓库。如果有数据仓库，就需要进行数仓的迁移，要理清数据仓库的模型情况，实施过程还涉及到数据迁移，模型迁移，脚本迁移，还有做应用接口改造，迁移过程中需要有自动化迁移工具。如果没有数仓，迁移的工作就可以省去，但湖仓一体平台建设就要覆盖数据建模等工作，从0到1实现数据建模也是不小的工程。此外，原数据湖与新湖仓一体虽然可以共用底层存储，比如 HDFS，S3 等，但仍涉及到脚本和应用迁移。

这里还要分享一点，就是我们不要畏惧平台改造，平台改造过程中可以重新梳理数据脉络，找出数据隐藏的暗病。解决了既有的数据问题，落地的湖仓一体平台才会是一个高效的平台。

问题十七

管理数据湖和管理数仓是两个团队，实现湖仓一体后组织架构需要什么变化吗？           

对于业务侧，湖仓一体的实现会直接影响企业的数字化转型战略，业务侧的组织架构的变化应该根据企业数字化转型战略进行调整。对于技术侧，IT 体系比较庞大的企业组织内部很可能会区分数据湖团队和数据仓库团队，两个团队之间一般是平行关系，这也是由于以往技术架构割裂和业务归口造成的历史原因。湖仓一体实现后，生态整合了，技术可扩展性更强了，易用性更高了，湖仓一体平台依然包括多个组件，比如数据库，不同的计算引擎，存储，调度，ETL 工具，数据资产管理，BI 工具等，根据用户的具体情况，依然需要多人或者多个团队合作。但这本质上是管理问题，不是技术问题，管理问题首先还是应该理清企业自身的管理诉求和数字化转型战略。