DataLake — 批流一体化的追风者(1)

技术分享知识经验解决方案架构

本次将之前讲解的DataLake相关的课程资料整理后发出，供大家参考学习，后续有问题可知音楼交流。

一、DataLake 概述

数据湖从本质上来讲，是一种企业数据架构方法，物理实现上则是一个数据存储平台，用来集中化存储企业内海量的、多来源，多种类的数据，并支持对数据进行快速加工和分析。从实现方式来看，目前Hadoop是最常用的部署数据湖的技术，但并不意味着数据湖就是指Hadoop集群。为了应对不同业务需求的特点，MPP数据库+Hadoop集群+传统数据仓库这种“混搭”架构的数据湖也越来越多出现在企业信息化建设规划中。

数据湖的就是原始数据保存区. 虽然这个概念国内谈的少，但绝大部分互联网公司都已经有了。国内一般把整个HDFS叫做数据仓库（广义），即存放所有数据的地方，而国外一般叫数据湖（data lake）。

从本质及实现和落地方式三方面来介绍数据湖具体的一些基础概念，我们需要辨别的是针对数仓它的一些区别和定义。

可以看到源端来自于不同的系统和服务，然后在数据湖中进行数据融合落地，最终可以产出到多个数仓来供不同人员使用，或者你也可以直接来使用数据湖的数据，当然这也没有任何问题。

对数据湖而言，我们肯定无可避免的去与当今普世的观点和理解去进行对照，这也无妨，看下你也会犯的这几个认知问题：

错误认知1：人们会普遍建议在数据湖和数据仓库之间二选一，当然这是不对的，我们可以结合具体使用来甄别他们两者；
错误认知2：数据仓库就是一个数据湖；这种想法会诱使你放弃数据湖，将所有数据都扔进数据仓库中来提供使用；
错误认知3：数据湖只能用Hadoop技术来实现；你会经常发现有讨论和示例会将数据湖等同于Hadoop或者Hadoop相关的技术栈，这会给人一种错觉：数据湖和Hadoop特定的技术紧密相关，实际实践中其实可以尝试使用其他技术栈来解决这个问题；
错误认知4：数据湖仅用于“存储”数据；在这种情况下，数据湖只是一个存储所有数据的介质。只需要所有数据放入数据湖，而后启用新的数据管理模型就可以大功造成？当然它的存在不只是这么简单，后续会说到；
错误认知5：数据湖仅存储“原始”数据；和错误认知2相关，“把所有数据都倒进数仓”的方法表示，数据湖不会增加价值，原因是只有原始数据驻留在数据湖中。“如果数据湖只处理原始数据，那么就不用担心数据湖了，只需将所有的原始数据或者已被处理的数据转存至数仓中”这种认识会通过具体的实践来推翻；
错误认知6：数据湖仅适用于“大”数据；人们将数据湖描述成一个庞大的、包容一切的实体，旨在保存所有的知识，所以不管实体大小，都是可以兼容进来的；
错误认知7：数据湖没有安全保障，当然用户鉴权和隔离这些都是需要的；
错误认知8：数据湖最终会变成数据沼泽；曾有一篇文章评论数据湖最终会变成数据沼泽，这是因为它的数据湖只是存储，缺乏治理、管理，没有数据生命周期/保留策略，也没有元数据。

以上是我们初阶段对数据湖的一些认知误区，辨别好它们将会让你更快的了解数据湖相关的特性，接着，我们继续来看如何正确上车：

数据摄取：数据提取允许连接器从不同的数据源获取数据并加载到Data湖中。数据提取支持：所有类型的结构化，半结构化和非结构化数据。批量，实时，一次性负载等多次摄取；许多类型的数据源，如数据库，Web服务器，电子邮件，物联网和FTP；
数据存储：数据存储应该是可扩展的，提供经济高效的存储并允许快速访问数据探索。它应该支持各种数据格式；
数据治理：数据治理是管理组织中使用的数据的可用性，可用性，安全性和完整性的过程；
安全：需要在Data Lake的每个层中实现安全性。它始于存储，发掘和消耗。基本需求是停止未授权用户的访问。它可以支持使用导航GUI和仪表板等不同的工具来访问数据；
身份验证，审计，授权和数据保护是数据湖安全的一些重要特性；
数据质量：数据质量是Data Lake架构的重要组成部分。数据用于确定商业价值。从劣质数据中提取洞察力将导致质量差的洞察力；
数据发现：数据发现是您开始准备数据或分析之前的另一个重要阶段。在这个阶段，标记技术用于表达数据理解，通过组织和解释数据湖中摄取的数据；
数据审计：两个主要的数据审计任务是跟踪对关键数据集的更改：跟踪重要数据集元素的更改；捕获如何/何时/以及更改这些元素的人员。数据审计有助于评估风险和合规性；
数据沿袭：该组件处理数据的来源。它主要涉及随着时间推移它的推动者以及它发生了什么。它简化了从始发地到目的地的数据分析过程中的错误更正；
数据探索：这是数据分析的开始阶段。在开始数据探索之前，确定正确的数据集是至关重要的。所有给定的组件需要协同工作，在Data Lake构建中发挥重要作用，轻松演化和探索环境。

其实我们一直以来都会有种错觉，经常用这个图中stream象限的方式去做了batch和incremental象限的事，那么有时候会扪心自问我们做的对吗？对不对不知道，反正肯定特别难受，这说到底究其原因是我们没有再用一个合理的方式去做应该要做的事，所以才会把技术和自己搞得那么难受，因而你说合理的架构做合理的事这个本身有什么问题吗？答案是没有，所以引进新架构还是能解决相当多的问题的，不是吗？

二、数据湖和数仓的差异化区别

从上面的图片中我们可以发现一些差别，这两者的比较似乎能找到点区别，又会觉得隔靴搔痒，难道数据统一和分类别处理是他们两者的区别？结构化与非结构化就成了数据仓库和数据湖的一个主要区别？BI和机器学习成为了主要区别？当然不是，我们通过以下来看。
事实上，这种对两者的简单比较有较大逻辑漏洞：即是从结果出发来看差异，然后又用这个差异来说明区别，颠倒了因果。AWS的数据湖能够处理非结构化数据，而数据仓库无法处理非结构化数据，就认为这是数据湖与数据仓库的本质区别之一吗？我们这次来跟大家从本质上聊聊我所理解的数据湖的本质，对于一种新事物不了解本质，你就很难驾驭它，更别说实践它了，看下图：

可以看到，数据湖并不比数据仓库在处理流程上多出了什么内容，更多的在于结构性的变化，下面就从数据存储、模型设计、加工工具、开发人员和消费人员五个方面来进行比较。

（1）数据存储
数据仓库采集、处理过程中存储下来的数据一般是以结构化的形式存在的，即使原始数据是非结构化的，但这些非结构化数据也只是在源头暂存一下，它通过结构化数据的形式进入数据仓库，成了数据仓库的基本存储格式，这个跟数据仓库的模型（维度或关系建模）都是建立在关系型数据基础上的特点有关。

事实上，是传统的数据建模负担让数据仓库只处理结构化数据，其实谁都没规定过数据仓库只处理和存储结构化数据。

数据湖包罗万象，轻装上阵，结构化与非结构化数据都成为了数据湖本身的一部分，这体现了数据湖中“湖”这个概念。因为没有数据仓库建模的限制，当然什么东西都可以往里面扔，但这为其变成数据沼泽埋下了伏笔。这当然不一定让人完全信服，不要急，接着往下看。

（2）模型设计
数据仓库中所有的Schema(比如表结构)都是预先设计并生成好的，数据仓库建设最重要的工作就是建模，其通过封装好的、稳定的模型对外提供有限的、标准化的数据服务，模型能否设计的高内聚、松耦合成了评估数据仓库好坏的一个标准，就好比数据中台非常强调数据服务的复用性一样。
你会发现，数据仓库很像数据领域的计划经济，所有的产品（模型）都是预先生成好的，模型可以变更，但相当缓慢。
数据湖的模型不是预先生成的，而是随着每个应用的需要即时设计生成的，其更像是市场经济的产物，牺牲了复用性却带来了灵活性，这也是为什么数据湖的应用更多强调探索分析的原因。

（3）加工工具
数据仓库的采集、处理工具一般是比较封闭的，很多采取代码的方式暴力实现，大多只向集中的专业开发人员开放，主要的目的是实现数据的统一采集和建模，它不为消费者（应用方）服务，也没这个必要。
数据湖的采集和处理工具是完全开放的，因为第（2）点提到过：数据湖的模型是由应用即席设计生成的，意味着应用必须具备针对数据湖数据的直接ETL能力和加工能力才能完成定制化模型的建设，否则就没有落地的可能，更无灵活性可言。
工具能否开放、体验是否足够好是数据湖能够成功的一个前提，显然传统数据仓库的一些采集和开发工具是不行的，它们往往非常丑陋，不可能向普通大众开放。

（4）开发人员
数据仓库集中开发人员处理数据涵盖了数据采集、存储、加工等各个阶段，其不仅要管理数据流，也要打造工具流。
由于数据流最终要为应用服务，因此其特别关注数据模型的质量，而工具流只要具备基本的功能、满足性能要求就可以了，反正是数据仓库团队人员自己用，导致的后果是害苦了运营人员。
数据湖完全不一样，集中开发人员在数据流阶段只负责把原始数据扔到数据湖，更多的精力花在对工具流的改造上，因为这些工具是直接面向最终使用者的，假如不好用，数据湖就死了。

（5）应用人员
数据仓库对于应用人员暴露的所有东西就是建好的数据模型，应用方的所有角色只能在数据仓库限定好的数据模型范围内倒腾，这在一定程度上限制了应用方的创新能力。比如原始数据有个字段很有价值，但数据仓库集中开发人员却把它过滤了。
这种问题在数据仓库中很常见，很多取数人员只会取宽表，对于源端数据完全不清楚，成了井底之蛙，这是数据仓库集中开发人员造的“孽”，所谓成也数据仓库，败也数据仓库。
数据湖的应用方则可以利用数据湖提供的工具流接触到最生鲜的原始数据，涵盖了从数据采集、抽取、存储、加工的各个阶段，其可以基于对业务的理解，压榨出原始数据的最大价值。
可以看到，数据仓库和数据湖，代表着两种数据处理模式和服务模式，是数据技术领域的一次轮回。早在ORACLE的DBLINK时代，我们就有了第一代的数据湖，因为那个时候ORACLE一统天下，ORALCE的DBLINK让直接探索原始数据有了可能。随着数据量的增长和数据类型的不断丰富，我们不得不搞出一种新的“数据库”来集成各种数据。
但那个时候搞出的为什么是数据仓库而不是数据湖呢？主要还是应用驱动力的问题。因为那个时候大家关注的是报表，而报表最核心的要求就是准确性和一致性，标准化、规范化的维度和关系建模正好适应了这一点，集中化的数据仓库支撑模式就是一种变相的计划经济。
随着大数据时代到来和数字化的发展，很多企业发现，原始数据的非结构化比例越来越高，前端应用响应的要求越来越高，海量数据挖掘的要求越来越对，报表取数已经满足不了数据驱动业务的要求了。
一方面企业需要深挖各种数据，从展示数据为主（报表）逐步向挖掘数据（探索预测）转变，另一方面企业也需要从按部就班的支撑模式向快速灵活的方向转变，要求数据仓库能够开放更多的灵活性给应用方，这个时候数据仓库就有点撑不住了。数据湖就是在这种背景下诞生的。
其实早在数据湖出来之前，很多企业就在做类似数据湖的工作了，比如我们5年前重构hadoop大数据平台的时候，就已经要求源端能将各种格式的数据直接扔过来，然后用不同的引擎处理，非结构化的就自己做一个定制化的ETL工具，只是没有统一进行整合而已。ETL之所以不开放，主要是驱动力不够，其实我们没有那么多类型的数据要定制化抽取，也许后续会需要吧。而可视化开发平台使用比较广泛，只是因为市场觉得IT做的太慢了，需要一个可视化平台来直接操作。
很多企业不搞可视化开发平台也是容易理解的，报表就能活得很好，干嘛业务人员要自己开发和挖掘。现在数据湖叫的欢的，大多是互联网公司，比如亚马逊，这是很正常的。数据湖和数据仓库，不能说谁更好谁更差，大家都有可取之处，阿里最近一篇文章提到的数湖一体是很好的概念，可以实现双方的优势互补。

通过这两个比较我们可以梳理出几个点的区别：
1.数据湖保留所有的数据Data Lakes Retain All Data
我们在建立数据仓库的时候会花大量的时间去分析数据源、理解业务逻辑、做数据切片，然后产出一个高度结构化的数据模型以支持企业产出报表。在这个过程中，可能还会花大量时间去决策哪些数据进入数据仓库哪些数据不进入数据仓库（可能是为了简化模型、降低存储成本、提高性能）。
相比之下，数据湖保留所有数据。不仅仅是今天使用的数据，还包括未来可能使用到的数据，甚至可能永远不会被使用的数据，因为有一天它可能会被使用。数据也会一直保存下来，以便我们能够及时回溯到任何时间点进行分析。数据湖的理念得以实施，也得益于最近几年存储技术的发展形成的。通过hadoop等技术平台，我们可以轻松地将数据湖扩展到TB级和PB级。
2.数据湖支持所有的数据类型Data Lakes Support All Data Types
数据仓库一般由从事务系统中提取的数据组成，并由度量和描述它们的属性组成。诸如Web服务器日志，传感器数据，社交网络活动，文本和图像等非传统数据源在很大程度上被忽略。这些数据类型的新用途不断被发现，但是消费和存储它们可能是昂贵和困难的。数据湖则包含这些非传统数据类型。在数据湖中，我们保留所有数据，而不考虑源和结构。我们保持它的原始形式，并且只有在我们准备好使用它时才会对其进行转换。这种方法被称为“读取模式”，相对应的，数据仓库中使用的“写入模式”方法。

3.数据湖支持所有用户 Data Lakes Support All Users
在大多数组织中，80％或更多的用户是“运营”的。他们希望获得他们的报告，查看他们的KPI数据或每天在电子表格中分割相同的数据集。数据仓库通常是这些用户的理想选择，因为它结构良好，易于使用和理解，并且专门用于回答他们的问题。
接下来的10％左右，对数据做更多的分析。他们使用数据仓库作为数据源，但通常会返回源系统以获取仓库中未包含的数据，有时还会从组织外部导入数据。他们最喜欢的工具是电子表格，他们创建的新报告通常分布在整个组织中。数据仓库是他们的数据源，但他们经常超出其范围。
最后，最后几个百分比的用户做了深入的分析。他们可能会根据研究创建全新的数据源。他们混合了许多不同类型的数据，并提出了全新的问题来回答。这些用户可能会使用数据仓库，但往往会忽略它，因为他们通常被控超越其功能。这些用户包括数据科学家，他们可能会使用高级分析工具和功能，如统计分析和预测建模。
数据湖方法同样支持所有这些用户。数据科学家可以去湖边工作，并使用他们需要的非常庞大和多样化的数据集，而其他用户则可以使用更为结构化的数据视图来提供他们使用的数据。

4.数据湖更容易适应变更 Data Lakes Adapt Easily to Changes
关于数据仓库的主要抱怨之一是需要多长时间来搭建和维护它们。在开发过程中花费大量时间来获得仓库的结构。一个好的仓库设计可以适应变化，但由于数据加载过程的复杂性以及为简化分析和报告所做的工作，这些更改必然会消耗一些开发人员资源并需要一些时间。许多业务问题都迫不及待地让数据仓库团队适应他们的系统来回答问题。日益增长的对更快答案的需求促成了自助式商业智能的概念。
另一方面，在数据湖中，由于所有数据都以其原始形式存储，并且始终可供需要使用它的人访问，因此用户有权超越仓库结构以新颖方式探索数据并按照自己的节奏解答他们自己的问题。
如果一个探索的结果被证明是有用的并且有重复使用该结果的想法，那么可以将这个结果开发形成线上化，以此来帮助将结果扩展到更广泛的受众。如果确定结果无用，则可以丢弃该结果，并且不会对数据结构进行任何更改，也不会消耗开发资源。

5.数据湖提供更加快速的视野 Data Lakes Provide Faster Insights
第五种区别实际上是前4个区别的合集。由于数据湖包含所有数据和数据类型，因为它让用户能够在数据转换，清理和结构化之前访问数据，从而使用户能够比传统数据仓库方法更快地获得结果。（这句话应该这么理解，就是如果应用数据的范围超过了数据仓库，那么数据湖肯定是比数据仓库更快获取到数据；但是如果数据的应用范围没有超过数据仓库，那么从数据仓库采集数据肯定是更快的，因为数据仓库每天都会自动计算出指标。）但是，这种对数据的早期访问是有代价的。通常由数据仓库开发团队完成的工作可能无法满足数据分析所需的全部数据源。因此需要对数据进一步分析的用户需要自行完成数据仓库团队未完成的剩余工作。但第四点描述的第一层业务用户可能不希望这样做，他们仍然只想要他们的报告和KPI。
在数据湖中，这些操作报告的使用者将利用更加结构化的数据湖中的物化视图，这些视图与数据仓库中以前一直存在的数据相似。不同之处在于，这些视图主要存在于位于湖泊中的数据之上的元数据，而不是需要开发人员更改的物理化的数据表。

三、数据方向及未来

近两年，为什么都开始谈论起 Data Lake 这个”新名词”了？先说我的想法，其实还是用户需求驱动数据服务，大家开始关注 Data Lake 的根本原因是用户需求发生了质变，过去的数据仓库模式以及涉及到的相关组件没有办法满足日益进步的用户需求。

1、趋势
这里聊一个很重要的趋势：数据实时化，当然这里有很多其他的趋势，比如低成本化、设计云原生化等，但总体上我还是认为数据实时化是近一两年来最热门、最明显且最容易让人看到收益的一个趋势。
数据仓库过去的模式大家可能都很了解，将整个数据仓库划分为 ODS、DWD、DWS，使用 Hive 作为数据存储的介质，使用 Spark 或者 MR 来做数据清洗的计算。这样的数据仓库设计很清晰，数据也比较容易管理，所以大家开开心心地使用这套理论和做法将近 10 年左右。
在这 10 年的时间里，主流的互联网公司在数据技术上的玩法并没有多大的改变，比如推荐需要用到的用户画像、电商里商品的标签、好友传播时用的图、金融风控数据体系，站在更高的一个角度看，我们会发现，十年前做的事情，比如用户画像表，如果你现在去做推荐服务，还是需要这个表。这样会产生一个什么现象？十年的互联网行业的人才积累、知识积累、经验积累，让我们可以更加容易地去做一些事情，比如十年前很难招聘到的懂推荐数据的人才，水平在如今也就是一个行业的平均值罢了。
既然这些事情变得更好做了，人才更多了，我们就期望在事情上做的更精致。因为从业务上讲，我去推荐短视频，让用户购买东西，这个需求是没有止境的，是可以永远做下去的。所以以前我可能是 T+1 才能知道用户喜欢什么，现在这个需求很容易就达到之后，我希望用户进来 10s 之后的行为就告诉我这个用户的喜好；以前可能做一些粗粒度的运营，比如全人群投放等，现在可能要转化思路，做更加精细化的运营，给每个用户提供个性化定制的结果。

2、技术演进1

数据实时化没问题，但是对应到技术上是什么情况呢？是不是我们要在实时领域也搭一套类似离线数据仓库的数据体系和模式？是的，很多公司确实是将实时数据流划分为了不同层级，整体层级的划分思路和离线仓库类似，但是实时数据的载体就不是 Hive 或者 Hdfs 了，而是要选择更加实时的消息队列，比如 Kafka，这样就带来了很多问题，比如：

消息队列的存储时间有限
消息队列没有查询分析的功能
回溯效率比文件系统更差

除了实时数据载体的问题，还有引入实时数仓后，和离线数仓的统一的问题；

比如实时数仓的数据治理、权限管理，是不是要单独做一套？
如何统一实时数据和离线数据的计算口径？
两套数据系统的资源浪费严重，成本提高？

举一个比较现实的例子，假设我们构造了一个实时计算指标，在发现计算错误后我们需要修正昨天的实时数据，这种情况下一般是另外写一个离线任务，从离线数仓中获取数据，再重新计算一遍，写入到存储里。这样的做法意味着我们在每写一个实时需求的同时，都要再写一个离线任务，这样的成本对于一个工程师是巨大的。

3、技术演进2
实时系统的成本太大了，这也是让很多公司对实时需求望而生畏的原因之一。所以这样去建设实时数仓的思路肯定不行啊，等于我要招两倍的人才（可能还不止），花两倍的时间，才能做一个让我的业务可能只提升 10% 的功能。从技术的角度来看，是这两套系统的技术栈不一样造成了工程无法统一。那么，Data Lakehouse 就是用来解决这样一个问题，比如我一个离线任务，能不能既产生实时指标，也产生离线指标，除了计算层面上，在数据管理上，比如中间表的 schema 管理，数据权限管理，能否做到统一？在架构上实现统一后，我们在应对实时需求时，可以将实时离线的冗余程度降到最低，甚至能够做到几乎没有多余成本。
Lakehouse的概念最早是由Databricks所提出的，而其他的类似的产品有Azure Synapse Analytics。Lakehouse技术仍然在发展中，因此上面所述的这些特性也会被不断的修订和改进。国内互联网公司的主流做法还是停留在【技术演进1】的阶段，相信随着大家的努力，很快就会出现优秀且成功的实践。

现在许多的公司往往同时会搭建数仓、数据湖这两种存储架构，一个大的数仓和多个小的数据湖。这样，数据在这两种存储中就会有一定的冗余。Data Lakehouse的出现试图去融合数仓和数据湖这两者之间的差异，通过将数仓构建在数据湖上，使得存储变得更为廉价和弹性，同时lakehouse能够有效地提升数据质量，减小数据冗余。在lakehouse的构建中，ETL起了非常重要的作用，它能够将未经规整的数据湖层数据转换成数仓层结构化的数据。我们罗列出了如下一些特性供大家参考：

事务支持：Lakehouse可以处理多条不同的数据管道。这意味着它可以在不破坏数据完整性的前提下支持并发的读写事务。
Schemas约束：数仓会在所有存储其上的数据上施加Schema，而数据湖则不会。Lakehouse的架构可以根据应用的需求为绝大多数的数据施加schema，使其标准化。
报表分析应用支持：报表和分析应用都可以使用这一存储架构。Lakehouse里面所保存的数据经过了清理和整合的过程，它可以用来加速分析。同时相比于数仓，它能够保存更多的数据，数据的时效性也会更高，能显著提升报表的质量。
数据类型扩展：数仓仅可以支持结构化数据，而Lakehouse的结构可以支持更多不同类型的数据，包括文件、视频、音频和系统日志。
端到端的流式支持：Lakehouse可以支持流式分析，从而能够满足实时报表的需求，实时报表在现在越来越多的企业中重要性在逐渐提高。
计算存储分离：我们往往使用低成本硬件和集群化架构来实现数据湖，这样的架构提供了非常廉价的分离式存储。Lakehouse是构建在数据湖之上的，因此自然也采用了存算分离的架构，数据存储在一个集群中，而在另一个集群中进行处理。
开放性：Lakehouse在其构建中通常会使Iceberg，Hudi，Delta Lake等构建组件，首先这些组件是开源开放的，其次这些组件采用了Parquet，ORC这样开放兼容的存储格式作为下层的数据存储格式，因此不同的引擎，不同的语言都可以在Lakehouse上进行操作。

那说完了Data Lakehouse的特性，它到底解决了什么问题呢？这些年来，在许多的公司里，数仓和数据湖一直并存且各自发展着，也没有遇到过太过严重的问题。但是仍有一些领域有值得进步的空间，比如：

数据重复性：如果一个组织同时维护了一个数据湖和多个数仓，这无疑会带来数据冗余。在最好的情况下，这仅仅只会带来数据处理的不高效，但是在最差的情况下，它会导致数据不一致的情况出现。Data Lakehouse统一了一切，它去除了数据的重复性，真正做到了Single Version of Truth。
高存储成本：数仓和数据湖都是为了降低数据存储的成本。数仓往往是通过降低冗余，以及整合异构的数据源来做到降低成本。而数据湖则往往使用大数据文件系统（譬如Hadoop HDFS）和Spark在廉价的硬件上存储计算数据。而最为廉价的方式是结合这些技术来降低成本，这就是现在Lakehouse架构的目标。
报表和分析应用之间的差异：报表分析师们通常倾向于使用整合后的数据，比如数仓或是数据集市。而数据科学家则更倾向于同数据湖打交道，使用各种分析技术来处理未经加工的数据。在一个组织内，往往这两个团队之间没有太多的交集，但实际上他们之间的工作又有一定的重复和矛盾。而当使用Data Lakehouse后，两个团队可以在同一数据架构上进行工作，避免不必要的重复。
数据停滞（Data stagnation）：在数据湖中，数据停滞是一个最为严重的问题，如果数据一直无人治理，那将很快变为数据沼泽。我们往往轻易的将数据丢入湖中，但缺乏有效的治理，长此以往，数据的时效性变得越来越难追溯。Lakehouse的引入，对于海量数据进行catalog，能够更有效地帮助提升分析数据的时效性。
潜在不兼容性带来的风险：数据分析仍是一门兴起的技术，新的工具和技术每年仍在不停地出现中。一些技术可能只和数据湖兼容，而另一些则又可能只和数仓兼容。Lakehouse灵活的架构意味着公司可以为未来做两方面的准备。

Data Lakehouse存在的问题现有的Lakehouse架构仍存在着一些问题，其中最为显著的是：

大一统的架构：Lakehouse大一统的架构有许多的优点，但也会引入一些问题。通常，大一统的架构缺乏灵活性，难于维护，同时难以满足所有用户的需求，架构师通常更倾向于使用多模的架构，为不同的场景定制不同的范式。
并非现有架构上本质的改进：现在对于Lakehouse是否真的能够带来额外的价值仍存在疑问。同时，也有不同的意见 - 将现有的数仓、数据湖结构与合适的工具结合 - 是否会带来类似的效率呢？
技术尚未成熟：Lakehouse技术当前尚未成熟，在达到上文所提的能力之前仍有较长的路要走。