共计 3002 个字符，预计需要花费 8 分钟才能阅读完成。
本文转载自 https://mp.weixin.qq.com/s/Il…
背景
数据湖（Data Lake)，湖仓一体（Data Lakehouse）俨然曾经成为了大数据畛域最为炽热的风行词，在承受这些风行词洗礼的时候，身为技术人员咱们往往会收回这样的疑难，这是一种新的技术吗，还是仅仅只是概念上的翻新（新瓶装旧酒）呢？它到底解决了什么问题，领有什么样新的个性呢？它的现状是什么，还存在什么问题呢？
带着这些问题，明天就从笔者的了解，为大家揭开 Data Lakehouse 的神秘面纱，来探一探起技术的实质到底是什么？
Data Lakehouse（湖仓一体）是新呈现的一种数据架构，它同时排汇了数据仓库和数据湖的劣势，数据分析师和数据科学家能够在同一个数据存储中对数据进行操作，同时它也能为公司进行数据治理带来更多的便利性。那么何为 Data Lakehouse 呢，它具备些什么个性呢？
本文参考自 https://www.xplenty.com/gloss…://www.xplenty.com/glossary/what-is-a-data-lakehouse/。
Data Lakehouse 具备什么个性？
始终以来，咱们都在应用两种数据存储形式来架构数据：
•数据仓库：数仓这样的一种数据存储架构，它次要存储的是以关系型数据库组织起来的结构化数据。数据通过转换、整合以及清理，并导入到指标表中。在数仓中，数据存储的构造与其定义的 schema 是强匹配的。
•数据湖：数据湖这样的一种数据存储构造，它能够存储任何类型的数据，包含像图片、文档这样的非结构化数据。数据湖通常更大，其存储老本也更为便宜。存储其中的数据不须要满足特定的 schema，数据湖也不会尝试去将特定的 schema 实施其上。相同的是，数据的拥有者通常会在读取数据的时候解析 schema（schema-on-read），当解决相应的数据时，将转换施加其上。
当初许多的公司往往同时会搭建数仓、数据湖这两种存储架构，一个大的数仓和多个小的数据湖。这样，数据在这两种存储中就会有肯定的冗余。
Data Lakehouse 的呈现试图去交融数仓和数据湖这两者之间的差别，通过将数仓构建在数据湖上，使得存储变得更为便宜和弹性，同时 lakehouse 可能无效地晋升数据品质，减小数据冗余。在 lakehouse 的构建中，ETL 起了十分重要的作用，它可能将未经规整的数据湖层数据转换成数仓层结构化的数据。
Data Lakehouse 概念是由 Databricks 在此文 [1] 中提出的，在提出概念的同时，也列出了如下一些个性：
•事务反对 ：Lakehouse 能够解决多条不同的数据管道。这意味着它能够在不毁坏数据完整性的前提下反对并发的读写事务。
•Schemas：数仓会在所有存储其上的数据上施加 Schema，而数据湖则不会。Lakehouse 的架构能够依据利用的需要为绝大多数的数据施加 schema，使其标准化。
• 报表以及剖析利用的反对 ：报表和剖析利用都能够应用这一存储架构。Lakehouse 外面所保留的数据通过了清理和整合的过程，它能够用来减速剖析。同时相比于数仓，它可能保留更多的数据，数据的时效性也会更高，能显著晋升报表的品质。
• 数据类型扩大 ：数仓仅能够反对结构化数据，而 Lakehouse 的构造能够反对更多不同类型的数据，包含文件、视频、音频和系统日志。
• 端到端的流式反对 ：Lakehouse 能够反对流式剖析，从而可能满足实时报表的需要，实时报表在当初越来越多的企业中重要性在逐步进步。
• 计算存储拆散 ：咱们往往应用低成本硬件和集群化架构来实现数据湖，这样的架构提供了十分便宜的分离式存储。Lakehouse 是构建在数据湖之上的，因而天然也采纳了存算拆散的架构，数据存储在一个集群中，而在另一个集群中进行解决。
• 开放性：Lakehouse 在其构建中通常会使 Iceberg，Hudi，Delta Lake 等构建组件，首先这些组件是开源凋谢的，其次这些组件采纳了 Parquet，ORC 这样凋谢兼容的存储格局作为上层的数据存储格局，因而不同的引擎，不同的语言都能够在 Lakehouse 上进行操作。
Lakehouse 的概念最早是由 Databricks 所提出的，而其余的相似的产品有 Azure Synapse Analytics。Lakehouse 技术依然在倒退中，因而下面所述的这些个性也会被一直的订正和改良。
Data 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 技术以后尚未成熟，在达到上文所提的能力之前仍有较长的路要走。
References
[1] 此文: _https://databricks.com/blog/2…
