随着越来越多的公司依靠数据来推动关键业务决策、改进产品供应并更好地服务客户，公司捕获的数据量比以往任何时候都多。Domo 的这项研究估计，2017 年每天会生成 2.5 百亿字节的数据，到 2025 年，这一数字将增加到 463 艾字节。但如果公司不能快速利用这些数据，那么这些数据又有什么用呢？针对数据分析需求的最佳数据存储这一话题长期以来一直存在争议。
现代公司正在摄取、存储、转换和利用更多的数据来推动比以往更多的决策。与此同时，81% 的 IT 领导者表示，他们的最高管理层已要求不增加支出或降低云成本。
|
数据团队需要平衡对稳健、强大的数据平台的需求与日益严格的成本审查。这就是为什么团队必须为其数据堆栈的存储层选择正确的架构。 |
但是，数据存储的选择正在迅速发展。数据仓库和数据湖是大数据使用最广泛的存储架构。但是使用数据湖仓一体怎么样呢？提供数据仓库、数据湖以及现在的湖仓一体的不同供应商都提供了自己独特的优点和缺点，供数据团队考虑。
根据您公司的需求，了解不同的大数据存储技术有助于为商业智能 （BI）、数据分析和机器学习 （ML） 工作负载开发强大的数据存储管道。
1. 什么是数据仓库？
数据仓库是数据的整合存储单元和处理中心，是一个统一的数据存储库，用于存储组织内多个来源的大量信息。数据仓库代表组织中“数据真相”的单一来源，并充当核心报告和业务分析组件。使用数据仓库的团队通常利用 SQL 查询来分析用例。
通常，数据仓库最适合使用由特定架构定义的结构化数据，这些架构将数据组织到整齐、标记良好的表中。同样的结构有助于维护数据质量并简化用户与数据交互和理解数据的方式。
数据仓库通过组合来自多个源（包括应用程序、业务和事务数据）的关系数据集来存储历史数据。数据仓库从多个来源提取数据，并转换和清理数据，然后将其加载到仓储系统中，作为数据真实的单一来源。组织投资数据仓库是因为它们能够快速提供整个组织的业务洞察。
数据仓库使业务分析师、数据工程师和决策者能够通过 BI 工具、SQL 客户端和其他不太高级的（即非数据科学）分析应用程序访问数据。
数据仓库。图片来源：https://corporatefinanceinstitute.com/
1.1 数据仓库的好处
数据仓库一旦实施，将为组织带来巨大的优势。一些好处包括：
提高数据标准化、质量和一致性：组织从各种来源生成数据，包括销售、用户和交易数据。数据仓库将企业数据整合为一致的标准化格式，可以作为单一数据源，使组织有信心依靠数据来满足业务需求。
提供增强的商业智能：数据仓库弥补了在实践中通常自动收集的大量原始数据与提供见解的精选数据之间的差距。它们充当组织的数据存储骨干，使他们能够回答有关其数据的复杂问题，并使用答案做出明智的业务决策。
提高数据分析和商业智能工作负载的能力和速度：数据仓库加快了准备和分析数据所需的时间。由于数据仓库的数据一致且准确，因此它们可以轻松连接到数据分析和商业智能工具。数据仓库还减少了收集数据所需的时间，并使团队能够利用数据来满足报告、仪表板和其他分析需求。
改进整体决策过程：数据仓库通过提供当前和历史数据的单一存储库来改进决策。决策者可以通过转换数据仓库中的数据以获得准确的见解来评估风险、了解客户需求并改进产品和服务。
例如，Walgreens 将其库存管理数据迁移到 Azure Synapse，使供应链分析师能够使用 Microsoft Power BI 等工具查询数据并创建可视化。迁移到云数据仓库还缩短了获得洞察的时间：现在可以在工作日开始时获得前一天的报告，而不是几个小时后。
1.2 数据仓库的缺点
数据仓库为企业提供高性能和可扩展的分析。然而，它们也带来了具体的挑战，其中包括：
缺乏数据灵活性：尽管数据仓库在结构化数据方面表现良好，但它们在处理半结构化和非结构化数据格式（例如日志分析、流媒体和社交媒体数据）时可能会遇到困难。这使得很难为机器学习和人工智能用例推荐数据仓库。
高实施和维护成本：数据仓库的实施和维护成本可能很高。 Cooladata 的这篇文章估计，具有 1 TB 存储空间和每月 100,000 次查询的内部数据仓库的年成本为 468,000 美元。此外，数据仓库通常不是静态的；它会变得过时并且需要定期维护，这可能会很昂贵。
数据仓库作为完全托管的解决方案，旨在简化构建和操作。仓库可以是一站式解决方案，其中元数据、存储和计算组件来自同一位置，并由单个供应商编排。数据仓库领域的一些知名参与者包括 Amazon Redshift、Google BigQuery 和 Snowflake。
对于主要用例是数据分析和报告的数据平台来说，数据仓库通常是最明智的选择。凭借预构建的功能和强大的 SQL 支持，数据仓库是量身定制的，可以为主要处理结构化数据的数据分析团队提供快速、可操作的查询。
2. 什么是数据湖？
数据湖是一个集中式、高度灵活的存储库，以原始、原始和未格式化的形式存储大量结构化和非结构化数据，经常用于流媒体、机器学习或数据科学场景。与存储已经“清理过”的关系数据的数据仓库相比，数据湖使用扁平架构和原始形式的对象存储来存储数据。数据湖灵活、耐用且经济高效，使组织能够从非结构化数据中获得高级洞察，这与处理这种格式数据的数据仓库不同。
数据湖可以基于多种技术构建，例如 Hadoop、NoSQL、Amazon Simple Storage Service、关系数据库，或各种组合和不同格式（例如 Excel、CSV、文本、日志、Apache Parquet、Apache Arrow、Apache Avro）。
虽然 数据湖供应商 不断涌现，提供更多托管服务（例如 Databricks 的 Delta Lake、Dremio 甚至 Snowflake），但传统上，数据湖是通过组合各种技术创建的。对于元数据组织，他们经常使用 Hive、Amazon Glue 或 Databricks。存储可以利用 S3、Google Cloud Storage、Microsoft Azure Blob Storage 或 Hadoop HDFS。计算任务可能在 Apache Pig、Hive、Presto 或 Spark 上运行。通常，您会在这些环境中找到 JSON、Apache Parquet 和 Apache Avro 等数据格式。
数据湖使数据工程团队可以根据其独特的需求自由选择正确的元数据、存储和计算技术。因此，随着您的数据需要扩展，您的团队可以通过集成数据堆栈的新元素来 轻松定制数据湖策略。
数据湖通常还会将存储和计算解耦，这样可以节省成本，同时促进实时流和查询。它们还鼓励分布式计算以增强查询性能和并行数据处理。
灵活性不仅仅是技术选择的可塑性。数据湖可以处理原始数据或轻结构化数据，在处理不同形式的数据时为数据团队提供宝贵的优势。数据湖可以支持复杂的非 SQL 编程模型，例如 Apache Hadoop、Apache Spark、PySpark 和其他框架。这对于数据科学家和工程师特别有用，因为它可以更好地控制他们的计算。
传统上，数据湖一直是需要对大量非结构化数据执行高级机器学习操作的数据科学家团队的理想选择——通常是那些拥有内部数据工程师来支持其定制平台的团队。但用户友好的托管解决方案使这种方法减少了对数据工程师从头开始构建功能的依赖。
在数据湖中，捕获数据时并未定义模式或数据；相反，数据被提取、加载和转换 （ELT） 以用于分析目的。数据湖允许使用来自物联网设备、社交媒体和流数据的各种数据类型的工具进行机器学习和预测分析。
数据湖模式。图片来源：datakitchen.io
2.1 数据湖的好处
由于数据湖可以存储结构化和非结构化数据，因此它们具有多种优势，例如：
数据整合：数据湖可以存储结构化和非结构化数据，从而无需在不同环境中存储两种数据格式。它们提供一个中央存储库来存储所有类型的组织数据。
数据灵活性：数据湖的一个显着优势是其灵活性；您可以以任何格式或介质存储数据，而无需预定义模式。允许数据保留其原始格式，可以分析更多数据并满足未来的数据用例。
节省成本：数据湖比传统数据仓库更便宜；它们被设计为存储在低成本的商用硬件上，例如对象存储，通常针对每 GB 存储的较低成本进行优化。例如，Amazon S3 标准对象存储的价格令人难以置信，前 50 TB/月每 GB 为 0.023 美元。
支持各种数据科学和机器学习用例：数据湖中的数据以开放的原始格式存储，从而可以更轻松地应用各种机器和深度学习算法来处理数据以产生有意义的见解。
2.2 数据湖的缺点
尽管数据湖提供了很多好处，但它们也带来了挑战：
商业智能和数据分析用例的性能不佳：如果管理不当，数据湖可能会变得杂乱无章，从而很难将它们与商业智能和分析工具连接起来。此外，缺乏一致的数据结构和 ACID（原子性、一致性、隔离性和持久性）事务支持可能会导致在报告和分析用例需要时查询性能不佳。
缺乏数据可靠性和安全性：数据湖缺乏数据一致性，难以保证数据可靠性和安全性。由于数据湖可以容纳所有数据格式，因此实施适当的数据安全和治理策略来满足敏感数据类型可能具有挑战性。
3. 什么是湖仓一体？综合方法
Lakehouse 是数据湖和数据仓库的组合（可能还有很多其他意见），是一种新的大数据存储架构，将数据仓库和数据湖的功能结合在一起，将传统数据分析技术与机器学习功能等高级功能融合在一起。数据湖库为所有数据（结构化、半结构化和非结构化）提供单一存储库，同时实现一流的机器学习、商业智能和流处理功能。。Lakehouse 具有开放的数据管理架构，结合了数据湖的灵活性、成本效益和规模。与数据湖一样，它还具有数据湖表格式（Delta Lake、Apache Iceberg 和 Apache Hudi）提供的数据库功能。与数据湖相比，Lakehouse 具有额外的数据治理。它包括集群计算框架和 SQL 查询引擎。更多功能丰富的 Lakehouse 还支持数据目录和最先进的编排。
数据湖仓一体的诞生是随着云仓库提供商开始添加通常与湖相关的功能而产生的，正如 Redshift Spectrum 和 Delta Lake 等平台中所见。相反，数据湖开始合并类似仓库的功能，例如 SQL 功能和模式定义。
数据湖仓一体提供的独特功能越来越模糊了两种结构之间的界限。 Presto 和 Spark 技术引入了高性能 SQL，在数据湖上提供近乎交互式的速度。这一创新为数据湖直接服务分析和探索创造了可能性，无需汇总到传统数据仓库中。
Parquet 等文件格式为数据湖表引入了更严格的架构，并采用列式格式来提高查询效率。为了进一步缩小差距，Delta Lake 和 Apache Hudi 等技术为数据湖的写入/读取事务带来了更高的可靠性。这促使它们更接近传统数据库技术固有的珍贵的 ACID（原子性、一致性、隔离性、持久性）特性。
湖仓一体通常从包含所有数据类型的数据湖开始；然后，数据被转换为数据湖表格式（一种为数据湖带来可靠性的开源存储层）。 Delta Lake/Hudi/Iceberg 支持数据湖上传统数据仓库的 ACID 事务流程。
从本质上讲，湖仓一体在结合两个领域的优势方面取得了长足进步，为处理多样化数据的企业提供了有趣且可行的替代方案。
3.1 数据湖及其演变的简史：
Hadoop & Hive：使用 MapReduce 的第一代数据湖表格式。支持 SQL 表达式。
AWS S3：下一代简单数据湖存储。维护工作大大减少，并且具有出色的编程 API 接口。
数据湖文件格式：适用于云的文件格式，具有面向列、压缩良好并针对分析负载进行了优化。例如 Apache Parquet、ORC 和 Apache Avro 格式。
数据湖表格式：Delta Lake、Apache Iceberg 和 Hudi，具有成熟的类数据库功能。
存储层/对象存储（AWS S3、Azure Blob Storage、Google Cloud Storage） 从存储层开始，我们拥有来自三大云提供商 AWS S3、Azure Blob Storage 和 Google Cloud Storage 的对象存储服务。Web 用户界面易于使用，它的功能非常简单，事实上这些对象存储可以很好地存储分布式文件，它们还具有高度可配置性，内置了可靠的安全性和可靠性。作为 Hadoop 的继承者，它们非常适合云中的非结构化和半结构化数据，AWS S3 是将任何格式的文件上传到云的事实上的标准。
3.2 数据湖文件格式（Apache Parquet、Avro、ORC）
数据湖文件格式更面向列，并使用附加功能压缩大文件。这里的主要参与者是 Apache Parquet、Apache Avro 和 Apache Arrow。它是物理存储，实际文件分布在存储层上的不同存储桶中。数据湖文件格式有助于存储数据，在系统和处理框架之间共享和交换数据。这些文件格式具有其他功能，例如拆分能力和模式演变。
在选择哪种数据湖文件格式时，Apache Parquet 似乎更占优势。 Avro 也很好，因为它具有复杂的模式描述语言来描述数据结构并支持模式演变。
Schema Evolution 不太重要，因为下一章中的数据湖表格式也支持这些。
3.3 数据湖表格式
数据湖表格式非常有吸引力，因为它们是数据湖上的数据库。与表相同，一种数据湖表格式将分布式文件*绑捆**到一个很难管理的表中。可以将其视为物理数据文件之间的抽象层，以及它们的结构以形成表格。想象一下一次插入数百个文件。它们是上述其中一种开源数据湖文件格式，可优化列存储并高度压缩，数据湖表格式允许直接从数据湖中高效地查询数据，不需要进行转换。数据湖表格式是数据湖文件格式的引擎。文件格式擅长以压缩方式存储大数据并将其返回以进行面向列的分析查询，但是它们缺乏额外的特性，例如 ACID 事务和对关系数据库中每个人都知道的标准 ANSI SQL 的支持。借助数据湖表格式及其开源解决方案，我们可以获得这些想要的基本功能，并且还可以获得更多，如下一章所示。
问题：在采用数据湖表格式之前思考
哪种格式具有我需要的最先进和最稳定的功能
哪种格式使我能够使用 SQL 轻松访问我的数据？
哪种格式有动力和良好的社区支持？
哪种格式提供最强大的版本控制工具？
3.4 数据湖表格式的特点
如何使用所有三种重要格式共享的数据湖表格式功能将数据库功能添加到 S3。此外该功能还有助于遵循 GDPR 政策、跟踪和审计，以及删除请求的删除。为什么所有这些功能都是必不可少的？想象一下需要将分析数据存储在 S3 上的 parquet 文件中。你需要对所有文件进行聚类，记录模式，同时读取和更新所有文件，找到一种备份和回滚的方法，以防你犯了错误，编写模拟更新或删除语句的繁重函数等等。这就是为什么会出现这些数据湖表格式，因为每个人都需要它们并创建了一个标准。
3.4.1 DML 和 SQL 支持：选择、插入、更新插入、删除
直接在分布式文件上提供合并、更新和删除。除了 SQL，有些还支持 Scala/Java 和 Python API。
3.4.2 向后兼容 Schema Evolution 和 Enforcement
自动模式演化[23]是数据湖表格式的一个关键特性，因为改变格式仍然是当今数据工程师工作中的一个难题。Schema Evolution 意味着在不破坏任何内容甚至扩大某些类型的情况下添加新列，甚至可以重命名或重新排序列，尽管这可能会破坏向后兼容性。不过我们可以更改一张表格，表格格式负责在所有分布式文件上切换它，最重要的是不需要重写表和基础文件。
3.4.3 ACID 事务、回滚、并发控制
ACID 事务[24]确保所有更改都成功提交或回滚。确保永远不会以不一致的状态结束。有不同的并发控制，例如保证读取和写入之间的一致性。每种数据湖表格式在此处都有其他实现和功能。
3.4.4 时间旅行，带有事务日志和回滚的审计历史
随着时间的推移，数据湖表格式会版本化存储在数据湖中的大数据。您可以访问该数据的任何历史版本，通过易于审核简化数据管理，在意外写入或删除错误的情况下回滚数据，并重现实验和报告。时间旅行支持可重现的查询，可以同时查询两个不同的版本。所有版本都使用时间旅行功能进行快照，它简化了其他复杂方法的实施，例如渐变维度（类型 2）[25]。甚至可以像通常使用更改数据捕获 （CDC）[26] 一样提取变更。 事务日志[27]是每个事务自开始以来的有序记录。事务日志是通过上述许多功能使用的通用组件，包括 ACID 事务、可扩展的元数据处理和时间旅行。例如，Delta Lake 创建一个名为 _delta_log 的文件夹[28]。可扩展的元数据处理：这些表通过自动检查点和汇总来大规模处理大量文件及其元数据。
3.4.5 分区
分区和分区演变[29] 处理为表中的行生成分区值的繁琐且容易出错的任务，并自动跳过不必要的分区和文件。快速查询不需要额外的过滤器，表格布局可以随着数据的变化而更新。
3.4.6 文件大小调整、数据 Clustering 与压缩
可以在 Delta Lake 中使用 OPTIMIZE[30]压缩数据，并通过 VACUUM[31] 设置保留日期删除旧版本（其他数据湖表格式具有类似功能）。开箱即用支持数据压缩，您可以选择不同的重写策略，例如分箱或排序，以优化文件布局和大小。优化在解决小文件问题时特别有效，您会随着时间的推移摄取小文件，但查询数千个小文件很慢，优化可以将文件重新碎片化为更大的文件，从而在许多方面提高性能。
3.4.7 统一的批处理和流式处理
统一的批处理和流式处理意味着 Lambda[32] 架构已过时。数据架构无需在批处理和流式中区分——它们都以相同的表结束，复杂性更低，速度更快。无论是从流还是批处理中读取都没有关系。开箱即用的 MERGE 语句适用于更改应用于分布式文件的流式传输情况。这些数据湖表格式支持单个 API 和目标接收器。可以在 Beyond Lambda: Introducing Delta Architecture[33] 或一些代码示例[34]中看到很好的解释。
3.4.8 数据共享
减少数据重复的一个新的令人兴奋和需要的功能是数据共享。在 Delta 世界里，它被称为 Delta Sharing[35]。Snowflake 宣布他们也将在 Iceberg 表中具有此功能。据我了解这些是 Databricks 和 Snowflake 中的专有功能。虽然用于安全数据共享的开源 Delta 共享协议[36]使得与其他组织共享数据变得简单，无论他们使用哪种计算平台。
3.4.9 变更数据流 （CDF）
更改数据流 （CDF）[37] 功能允许表跟踪表版本之间的行级更改。启用后，运行时会记录写入表中的所有数据的“更改事件”。CDF 包括行数据和元数据，指示是否插入、删除或更新了指定的行。
3.5 数据湖表格式（Delta、Iceberg、Hudi）
现在我们有了开源数据湖表格式最显着的特点，让我们来看看已经提到过几次的三个最突出的产品：Delta Lake、Apache Iceberg 和 Apache Hudi。
3.5.1 Delta Lake
Delta Lake 是一个开源项目，可以在数据湖之上构建 Lakehouse 架构。 Delta Lake 提供 ACID 事务、可扩展的元数据处理，并在现有数据湖（例如 S3、ADLS、GCS 和 HDFS）之上统一流式处理和批量数据处理。
具体来说，Delta Lake 提供：
Spark 上的 ACID 事务：可序列化的隔离级别确保读者永远不会看到不一致的数据。
可扩展的元数据处理：利用 Spark 分布式处理能力轻松处理包含数十亿文件的 PB 级表的所有元数据。
流式和批处理统一：Delta Lake 中的表既是批处理表，又是流式源和接收器。流数据摄取、批量历史回填、交互式查询都可以开箱即用。
架构强制：自动处理架构变化，以防止在摄取期间插入不良记录。
时间旅行：数据版本控制支持回滚、完整的历史审计跟踪和可重现的机器学习实验。
更新插入和删除：支持合并、更新和删除操作，以支持复杂的用例，例如更改数据捕获、缓慢变化维度 （SCD） 操作、流式更新插入等。
3.5.2 Apache Iceberg
Apache Iceberg 是一种适用于大型分析数据集的开放表格式。 Iceberg 使用高性能表格式向 Spark、Trino、PrestoDB、Flink、Hive 和 Impala 等计算引擎添加表，其工作方式与 SQL 表类似。
用户体验
Iceberg 避免了令人不快的意外。架构演化有效，不会无意中取消删除数据。用户无需了解分区即可获得快速查询。
模式演化支持添加、删除、更新或重命名，并且没有副作用
隐藏分区可防止用户错误导致无提示的错误结果或极慢的查询
分区布局演变可以随着数据量或查询模式的变化而更新表的布局
时间旅行支持使用完全相同的表快照的可重复查询，或者让用户轻松检查更改
版本回滚允许用户通过将表重置到良好状态来快速纠正问题
可靠性和性能
Iceberg 是为巨大的表而建造的。 Iceberg 用于生产环境，其中单个表可以包含数十 PB 的数据，甚至这些巨大的表也可以在没有分布式 SQL 引擎的情况下读取。
扫描计划很快——不需要分布式 SQL 引擎来读取表或查找文件
高级过滤——使用表元数据通过分区和列级统计数据修剪数据文件
Iceberg 旨在解决最终一致的云对象存储中的正确性问题。
可与任何云存储配合使用，并通过避免列出和重命名来减少 HDFS 中的 NN 拥塞
可序列化隔离——表更改是原子的，读者永远不会看到部分或未提交的更改
多个并发写入器使用乐观并发，即使写入冲突，也会重试以确保兼容更新成功
开放标准
Iceberg 被设计和开发为一个开放社区标准，其规范可确保跨语言和实现的兼容性。
3.5.3 Apache Hudi
Apache Hudi 将核心仓库和数据库功能直接引入数据湖。 Hudi 提供表、 事务、高效的更新插入/删除、高级索引、 流式摄取服务、数据集群/压缩优化和并发性，同时将数据保持为开源文件格式。
Apache Hudi 不仅非常适合流工作负载，而且还允许您创建高效的增量批处理管道。阅读文档以获取更多用例描述，并查看谁在使用 Hudi，了解世界上一些最大的数据湖（包括 Uber、Amazon、 ByteDance、 Robinhood 等）如何使用 Hudi 改造其生产数据湖。
Apache Hudi 可以轻松地在任何云存储平台上使用。 Hudi 的高级性能优化可通过任何流行的查询引擎（包括 Apache Spark、Flink、Presto、Trino、Hive 等）加快分析工作负载的速度。
3.6 湖仓一体的好处
湖仓一体架构将数据仓库的数据结构和管理功能与数据湖的低成本存储和灵活性相结合。这种实施的好处是巨大的，包括：
减少数据冗余：数据湖房通过提供单一通用数据存储平台来满足所有业务数据需求，从而减少数据重复。由于数据仓库和数据湖的优势，大多数公司选择混合解决方案。然而，这种方法可能会导致数据重复，成本高昂。
成本效益：湖仓一体通过利用低成本的对象存储选项来实现数据湖的经济高效的存储功能。此外，数据湖房通过提供单一解决方案消除了维护多个数据存储系统的成本和时间。
支持更广泛的工作负载：数据湖站提供对一些最广泛使用的商业智能工具（Tableau、PowerBI）的直接访问，以实现高级分析。此外，数据湖房使用开放数据格式（例如 Parquet）以及 API 和机器学习库（包括 Python/R），使数据科学家和机器学习工程师可以轻松地利用数据。
易于数据版本控制、治理和安全性：数据湖仓一体架构强制实施架构和数据完整性，从而更容易实现强大的数据安全和治理机制。
3.7 湖仓一体的缺点
湖仓一体的主要缺点是它仍然是一项相对较新且不成熟的技术。因此，尚不清楚它是否会兑现其承诺。数据湖房可能还需要数年时间才能与成熟的大数据存储解决方案竞争。但以目前现代创新的速度，很难预测新的数据存储解决方案是否最终会取代它。
4. 差异比较
数据仓库是最古老的大数据存储技术，在商业智能、报告和分析应用中拥有悠久的历史。然而，数据仓库成本高昂，并且难以处理非结构化数据，例如流数据和各种数据。
数据湖的出现是为了在廉价存储上处理各种格式的原始数据，以用于机器学习和数据科学工作负载。虽然数据湖可以很好地处理非结构化数据，但它们缺乏数据仓库的 ACID 事务功能，因此很难确保数据的一致性和可靠性。
湖仓一体是最新的数据存储架构，它将数据湖的成本效率和灵活性与数据仓库的可靠性和一致性结合在一起。
此表总结了数据仓库、数据湖和湖仓一体之间的差异。
点击图片可查看完整电子表格
“湖仓一体与数据仓库与数据湖”仍然是一个持续的话题。选择哪种大数据存储架构最终取决于您正在处理的数据类型、数据源以及利益相关者将如何使用数据。尽管数据湖仓一体结合了数据仓库和数据湖的所有优点，但我们不建议您为了数据湖仓一体而放弃现有的数据存储技术。
5. 哪一个存储模式最适合您的需求？
从头开始构建湖仓一体可能很复杂。您很可能会使用一个为支持开放的数据湖仓一体架构而构建的平台。因此，请确保在购买之前研究每个平台的不同功能和实现。
5.1 了解您的核心用户
当涉及到数据仓库与数据湖时，“一刀切”并不适用。数据仓库、数据湖和湖仓一体中的首选项必须与用户的熟练程度、需求和工作流程相对应。
例如，商业智能团队经常发现结构化数据更方便用于报告和分析目的，从而使数据仓库成为合理的选择。相比之下，数据湖处理原始和未经过滤的数据的能力可能更适合寻求运行高级计算和数据探索的数据科学家的需求。另一方面，湖仓一体可以为具有不同技能的不同用户提供两全其美的服务。
这一切都是为了根据用户的个人需求和技能选择能够为用户提供最高效且最有效的数据访问权限的选项。
5.2 可扩展性和性能考虑因素
接下来，考虑您的数据本身：您使用结构化数据还是非结构化数据，或者两者都使用？您想要在存储之前清理和处理数据，还是保留原始数据以进行高级 ML 操作？或两者？您预计会有哪些预算限制？所有这些可扩展性和性能因素将影响您对数据仓库、数据湖或湖仓一体的选择。
5.2.1 结构和模式
传统上，数据湖擅长存储大量原始数据——无论是结构化、半结构化还是非结构化数据，没有任何特定的限制。另一方面，数据仓库依靠秩序而蓬勃发展，通过相应的元数据维护数据的精确存储和组织。然而，这些区别变得越来越不明确，数据湖房通常提供更大的灵活性来支持结构化和非结构化数据。
例如，Databricks 等公司允许用户使用 Unity Catalog 和 Delta Lake 等功能向其数据湖添加结构和元数据。类似地，Snowflake 也引入了 Apache Iceberg 表，融合了 SQL 表的可靠性，并使各种引擎可以在同一个表上同时工作。这种融合使得可扩展性和性能考虑比以往更加微妙。
一个关键因素是了解贵司的常规数据使用模式。如果您始终依赖有限数量的数据源来实现特定工作流程，那么考虑到时间和资源，从头开始构建数据湖可能不是最佳途径。但是，如果您的公司采用多个数据源来推动战略决策，则混合的湖仓一体架构可以为不同角色的用户提供快速、富有洞察力的数据访问。
5.2.2 数据整合及处理能力
在数据仓库中，来自不同来源的数据在存储之前会被清理、集成和处理。这提供了主动的数据质量管理，使其能够高效地执行报告和提取业务洞察等日常处理任务。然而，如此广泛的预处理可能会限制复杂的临时分析的灵活性。
数据湖存储原始数据，留下处理部分，直到读取数据以供使用（也称为读取时架构）。这种灵活性允许复杂的实时处理，对于高级分析、机器学习和人工智能特别有用。但根据数据的数量和复杂性，它可能需要更多的处理能力和更长的处理时间。
湖仓一体试图两全其美。它允许像数据湖一样存储原始数据，同时还可以像仓库一样方便地选择预处理的结构化数据。这种组合可以在不影响灵活性的情况下缩短处理时间并提高效率。
5.3 成本影响和资源需求
数据仓库虽然对于结构化数据和日常业务查询非常高效，但可能会带来巨大的成本，尤其是在扩展时。它们通常需要在财务和时间方面进行大量的前期投资，因为它们需要复杂的设置和维护程序。
相比之下，数据湖通常更实惠且可扩展，因为它们使用商用硬件来存储大量原始数据。就存储而言，它们通常成本较低，但如果数据需要复杂的处理或面临质量问题，运营费用可能会增加。此外，他们可能需要一支具有专业技能的团队来管理原始的、不受监管的数据并从中提取价值。
湖仓一体模型包括数据仓库和数据湖的组件。它提供了更大的灵活性，并且可以成为一种经济高效的解决方案，可以满足更广泛的数据使用场景，而无需单独设置仓库和湖泊。然而，他们在设置、维护和技术人员方面可能仍然需要大量资源。
5.4 融合和最新产品创新
湖仓一体本身是一项相对较新的创新。随着实时分析数据流的兴起，这种混合方法可能会在未来几年变得更加流行，并且与各行业的数据团队相关。两个主要竞争者在开发灵活的数据存储解决方案方面处于领先地位：Databricks 和 Snowflake。
5.4.1 创新对数据管理和分析领域的影响
Databricks 和 Snowflake 等领先者的这些创新正在继续模糊数据仓库和数据湖之间的界限。在数据驱动型企业数量不断增加的大背景下，这种演变是有意义的：随着组织继续从更多来源获取和利用更多类型的数据，他们需要能够支持其增长的技术。结构化和非结构化、批处理和流式传输——所有这些不同的用例都需要数据平台的支持。
这促使供应商创建更具成本效益的解决方案，并且不会影响性能，而像 Snowflake 和 Databricks 这样的数据巨头似乎正在进行一场军备竞赛，以成为解决计算和处理需求的万能解决方案适合各种规模的企业。这是一个令人兴奋的前景，尤其是人工智能带来的可能性，我们迫不及待地想看看数据仓库、湖泊和湖屋在未来几年将如何发展。
5.5 数据质量和数据可观察性
有一件事不会很快改变：公司需要信任他们的数据，无论数据存储在何处或如何存储。
无论您的利益相关者是谁，也无论您的性能需求是什么，您都希望确保您的数据仓库、数据湖或数据湖支持数据质量。了解您的数据准确、新鲜且完整对于任何决策过程或数据产品都至关重要。当数据质量受到影响时，可能会导致时间浪费、机会损失、收入损失以及内部和外部信任的侵蚀。
虽然现代数据治理方法和广泛的数据测试可以帮助提高数据质量，但最好的团队正在整个数据堆栈中利用数据可观察性。数据可观测性为存储所有类型数据的任何仓库、数据湖或湖仓一体中的数据管道中的问题提供端到端监控和警报。
通过分析历史模式，同时结合自定义规则和阈值，数据可观察性可以确保正确的数据团队第一个知道数据问题何时发生。与自动化的现场级血缘相结合，这可以确保将数据停机时间保持在最低限度，受影响的利益相关者可以轻松获知潜在问题，并在整个数据生命周期中保持数据质量。
对于寻求专注于商业智能和数据分析用例的成熟结构化数据解决方案的公司来说，数据仓库是一个不错的选择。然而，数据湖适合寻求灵活、低成本的大数据解决方案来驱动非结构化数据上的机器学习和数据科学工作负载的组织。
假设数据仓库和数据湖方法不能满足您公司的数据需求，或者您正在寻找对数据实施高级分析和机器学习工作负载的方法。在这种情况下，湖仓一体是一个合理的选择。
6. 参考
https://www.striim.com/blog/data-warehouse-vs-data-lake-vs-data-lakehouse-an-overview/
https://www.montecarlodata.com/blog-data-warehouse-vs-data-lake-vs-data-lakehouse-definitions-similarities-and-differences/
https://hudi.apache.org/docs/overview
https://iceberg.apache.org/docs/nightly/
https://docs.databricks.com/en/delta/index.html
https://delta.io/
https://mp.weixin.qq.com/s/GJpGlpeUW8kV4vvs2PwCYQ