介绍
你们中的大多数人都知道构建数据和分析平台的不同方法。您可能已经在使用传统仓库或基于 Hadoop 的数据湖的系统上工作过。你们中的一些人可能还阅读过有关 Lakehouses 的信息。
从这几种方法中选择一种来构建新的数据平台可能会变得非常混乱。您需要根据您的数据策略和整体数据要求做出正确的选择。本文将帮助您了解每种方法的差异、优势和限制，并帮助您确定最适合您的用例的方法。
数据仓库——旧的决策方式！
数十年来，企业一直在构建数据仓库。它是存储数据以生成洞察和决策的最流行和广泛采用的方法之一。
用于 BI 工作负载的数据仓库
用例：什么时候应该实施数据仓库？
当您有以下数据要求时，您应该实施数据仓库。
- 该计划的主要目标是建立一个平台，用于根据过去的数据生成洞察力、报告和仪表板以及决策。
- 您想分析历史数据以了解当前趋势、客户行为和消费模式。
- 您主要处理结构化数据和不太复杂的半结构化数据。
- 您不需要流式数据分析。
- 您不是在分析来自社交媒体源或 IoT 设备的非结构化数据。
好处
数据仓库有一些经过充分验证的好处，并且已经通过了时间测试。下面列出了一些主要好处。
- OLAP 工作负载的“同类最佳”性能。
- ACID 支持——易于处理更新，删除并发读写。
- 支持 ANSI SQL，这是数据工程师、分析师和业务用户中最流行的语言之一。
- 成熟的实施生命周期和经过验证的案例研究。几乎所有大小企业都在某个时间点建立了企业数据仓库。
限制
虽然数据仓库享有上述优势，但它也有一些关键限制，如下所示。
- 不支持处理非结构化数据。
- 不是最适合流式工作负载； 延迟可能在几秒钟内。
- 它不支持 AI/ML 用例，因为无法存储非结构化数据。
- 昂贵，因为它经常使用专有工具和平台。
- 很难单独扩展存储和计算。
快速提示： 当仅处理来自传统源系统（如文件或数据库）的结构化数据时，请选择独立的仓库实现。然而，在当今世界，很难想象任何企业——无论大小，不使用非结构化数据。您可以先建立一个仓库，然后再为非结构化或流式用例规划一个数据湖。
数据湖：所有数据的存储！
随着 Hadoop 生态系统的兴起，许多企业开始构建数据湖。可以存储所有数据的湖——结构化、半结构化和非结构化数据。数据湖很快成为数据存储的默认选择，许多企业仍然拥有海量数据湖来支持其分析数据工作负载。
用于 AI/ML 工作负载的数据湖
用例：何时考虑数据湖？
在处理需要为机器学习用例存储、管理和分析的海量数据时，数据湖是大数据实施的绝佳选择。
当您有以下要求时，请选择数据湖
- 用于存储各种数据，包括来自各种社交媒体源或物联网源的非结构化数据。
- 用于支持用于构建推荐引擎、预测或预测的AI/ML 工作负载。
- 用于以最低延迟要求分析来自源系统的消息的流式用例
好处
数据湖提供了比独立仓库更大的优势。下面列出了一些主要好处。
- 成本效益——您可以利用云对象存储提供的成本优势来构建数据湖。
- 支持AI/ML 用例（ 独立仓库很难实现）
- 有助于持久化、管理和分析所有数据——包括半结构化和非结构化数据。
- 没有专有存储——您可以使用任何计算引擎从数据湖中提取数据。例如 Spark 和 Presto，以及其他数据目录工具。
- 不与任何计算服务紧密耦合——单独扩展很容易实现。
限 制
与独立仓库一样，数据湖也有一定的局限性。下面列出了可能影响您的平台选择的关键因素。
- 数据湖是 不可变的；您不能更新或删除数据。
- 不支持 ACID - 一致性可能具有挑战性。
- 在分析处理方面性能不是很好。
- 元数据不易维护——湖泊很快就会变成数据沼泽，其中包含大量不易发现的数据。
快速提示： 数据湖非常适合支持 AI/ML 用例。为此类用例实施数据湖，以存储从物联网设备或社交媒体源生成的大量非结构化数据。
但是，实施使用历史数据生成洞察或决策的分析决策系统或需要仓库的 ACID 功能的系统可能不是一个很好的选择。
数仓 & 数据湖：满足您的所有数据需求！
考虑到上述限制，现在很多企业开始采用数据湖和数据仓库相结合的方式。这将有助于克服它们各自的局限性。
数据湖 + 数据仓库的组合可以解决您的大部分数据需求，并帮助您构建所有数据用例。
用例：何时考虑数据湖 + 数据仓库
你可以考虑在大多数场景下实现这种架构模式；下面列出了其中一些。
- 您希望支持BI 以及 AI/ML用例。
- 您需要一个能够满足所有未来需求的系统——包括批处理、流式传输、基于 ML 的工作负载或事件物联网数据分析。
- 您希望利用Apache Spark 的强大功能进行非结构化数据分析，并利用SQL 的简单性来查询数据以进行 OLAP 分析。
好处
您将获得这些系统中的每一个单独提供的好处。这些包括下面列出的要点。
- 数据仓库的ACID特性
- 支持存储、管理和分析非结构化数据
- 支持实施BI 以及 AI/ML工作负载
- 支持批处理和流式用例
限制
尽管这种方法似乎是所有其他方法中最好的，但它也有一些可能难以解决的关键限制。下面重点介绍了一些关键问题。
- 没有单一版本的事实——相同的数据在湖和仓库中。
- 将数据从湖转移到仓库的额外努力
- 很难在 Lake 和 Warehouse 之间保持数据同步
- 没有单一的元数据存储库——维护两个系统的同步目录具有挑战性
- 难以实现跨 Lake 和 Warehouse的访问控制
- 在 Lake 和 Warehouse 之间编排工作负载并不容易
快速提示： 实施数据湖并用仓库补充它是当今最采用的方法之一。它是从以前分别实施湖泊和仓库的方法发展而来的。如果您已经有仓库或湖并且想要增强现有系统以利用其他组件的优势，您可以考虑这种方法。
Lakehouse：这就是未来吗？
2022 年似乎是 Lakehouses 时代的开始！现在每个人都在谈论建立一个真正的 Lakehouse——一个有助于建立单一版本的真相并同时为您提供两全其美的系统。
用例：什么时候应该建造 Lakehouse？
Lakehouse 是一种用于构建数据平台的不同架构模式。它是一个数据湖，但具有仓库的附加功能。有用于建造湖屋的不同开放技术。其中最受欢迎的之一是Delta Lake。
以下场景可以考虑搭建 Lakehouse
- 当您想要实现一个可以支持 BI 和 AI 用例的生态系统时
- 当您不希望使用任何供应商特定产品进行任何锁定时，您可以使用 Delta 等开放表格式来实施 Lakehouse
- 您没有现有的 Warehouse，正在寻找可以支持您的数据需求的新平台
好处
Lakehouses 提供了许多好处——其中一些是不容忽视的，应该利用它来获得成本和性能优势。下面列出了一些关键优势。
- 两全其美——湖泊的成本效率和仓库的性能
- 事实的单一版本——在两个不同的存储平台上没有重复数据
- 无需努力在 Lake 和 Warehouse 之间移动数据
- 使用开源技术构建 -供应商不可知的实施是可能的
限制
湖屋还是很新的。在实施 Lakehouse 时可能会遇到一些限制。
- 一种相对较新的方法 需要更多的行业接受和采用。
- Apache Iceberg、Apache Hudi 或 Delta Lake等存储格式可能存在特定限制，后者是任何 Lakehouse 的支柱。
- 与 BI 工具的集成以及与源系统的连接可能具有挑战性。
快速提示： Lakehouses 似乎是构建数据平台的未来。它可以两全其美，但同时也存在与底层开源技术相关的限制。建造 Lakehouse 的最佳方法是从试验阶段开始，看看它是否符合您的要求。
结论
在本文中，我们将了解构建数据平台的各种方法的区别、好处和局限性。以下是您在选择构建数据平台的正确方法时可以考虑的不同方法的快速摘要
数据仓库
- 最适合 BI 工作负载的结构化数据存储平台
- 完美的表现
- 使用专有存储
数据湖
- 存储结构化、半结构化和非结构化数据的平台，可支持 AI/ML 工作负载
- 经济高效、可扩展
- 不支持 ACID 功能
数据湖+数据仓库
- 一种可以支持 BI 以及 AI/ML 用例的组合方法
- 支持所有数据类型
- 相同的数据存储在 Lake & Warehouse
- 需要努力保持数据同步
湖景房
- 最新趋势可以提供两全其美的数据湖的成本效率和仓库的性能。
- 支持BI+AI/ML，所有数据类型
- 单一版本的真相
- 支持与供应商无关的实施
您可以根据您的整体数据策略以及当前和未来的数据需求选择其中任何一个。
原文标题：Warehouse, Lake or a Lakehouse – What’s Right for you?
原文作者：GT Thalpati
原文链接：https://www.analyticsvidhya.com/blog/2022/10/warehouse-lake-or-a-lakehouse-whats-right-for-you/
