数据仓库vs.数据湖vs.数据流：敌人还是朋友？

数据仓库、数据湖和数据流的概念和架构是解决业务问题的补充。为报告和分析存储静态数据需要不同的功能和SLA，而不是为实时工作负载连续处理动态数据。存在许多开源框架、商业产品和SaaS云服务。不幸的是，底层技术经常被误解，被过度用于单一和不灵活的架构，并且被供应商用于错误的用例。

数据的价值：事务性工作负载与分析性工作负载

过去十年中，提供了许多关于数据成为新石油的文章、博客和演示。今天，没有人质疑数据驱动的业务流程改变了世界，实现了跨行业的创新。

数据驱动的业务流程需要实时数据处理和批处理。考虑以下跨应用程序、域和组织的事件流：

事件是业务信息或技术信息。事件总是发生。现实世界中的业务流程需要各种事件之间的关联。

事件有多重要？

事件的关键性决定了结果。潜在影响可能是增加收入、降低风险、降低成本或改善客户体验。

• 业务事务：理想情况下，零停机时间和零数据丢失。示例：付款只需处理一次。

• 关键分析：理想情况下，零停机时间。单个传感器事件的数据丢失可能是正常的。对事件聚合发出警报更为重要。示例：持续监控物联网传感器数据和（预测性）机器故障警报。

• 非关键分析：停机时间和数据丢失不好，但不会扼杀整个业务。这是一场意外，但不是一场灾难。示例：报告和商业智能以预测需求。

何时处理事件

实时通常意味着在毫秒或秒内进行端到端处理。如果您不需要实时决策，批处理（即在几分钟、几小时、几天之后）或按需处理（即请求回复）就足够了。

• 商业交易通常是实时的：像支付这样的交易通常需要实时处理（例如，在客户离开商店之前；在您发货之前；在离开叫车之前）。

• 关键分析通常是实时的：关键分析通常需要实时处理（例如，在欺诈发生之前检测欺诈；在机器故障之前预测机器故障；在客户离开商店之前向客户追加销售）。

• 非关键分析通常不是实时的：在历史数据中发现洞察通常是在批处理过程中使用复杂SQL查询、映射-约简或复杂算法（例如，报告；使用机器学习算法的模型训练；预测）等范式完成的。

有了这些关于处理事件的基础知识，让我们了解为什么将所有事件存储在单个中央数据湖中并不是解决所有问题的方法。

通过分散化和最佳品种实现灵活性

传统的数据仓库和数据湖方法是将来自所有源的所有数据摄取到中央存储系统中，以实现集中数据所有权。天空（和您的预算）是当前大数据和云技术的极限。

然而，领域驱动设计、微服务和数据网格等架构概念表明，分散所有权是现代企业架构的正确选择。

别担心。数据仓库和数据湖并没有消亡，但在数据驱动的世界中，它们比以往任何时候都更加相关。这两种方法对于许多用例都是有意义的。即使在其中一个领域，大型组织也不使用单个数据仓库或数据湖。为工作选择合适的工具（在您的领域或业务部门中）是解决业务问题的最佳方法。

人们有很好的理由对用于批量ETL、机器学习甚至数据仓库的数据块感到满意，但对于某些用例，仍然更喜欢轻量级云SQL数据库，如AWS RDS（完全管理的PostgreSQL）。

快乐的Splunk用户也有很好的理由将一些数据吸收到Elasticsearch中。这也是为什么Cribl在这个领域也越来越有吸引力的原因。

有些项目利用ApacheKafka作为数据库是有充分理由的。在Kafka中长期存储数据只适用于某些特定的用例（如压缩主题、键/值查询和流分析），Kafka不会取代其他数据库或数据湖。

为分散数据所有权的工作选择合适的工具！

考虑到这一点，让我们探讨现代数据仓库的用例和附加值（以及它与数据湖和新的buzz湖屋的关系）。

数据仓库：数据静止的报告和商业智能

数据仓库（DWH）提供报告和数据分析功能。它被认为是商业智能的核心组件。

静态数据的用例

无论您使用的产品是数据仓库、数据湖还是湖屋。数据在静止状态下存储以供进一步处理：

• 报告和商业智能：快速、灵活地提供报告、统计数据和关键数据，以识别市场和服务提供之间的相关性

• 数据工程：整合来自不同结构和分布式数据集的数据，以识别数据之间的隐藏关系

• 大数据分析和人工智能/机器学习：源数据的全局视图，从而进行总体评估，以发现未知见解，从而改进业务流程和相互关系。

一些读者可能会说：只有第一个是数据仓库的用例，其他两个是数据湖或湖屋！这取决于定义。

数据仓库体系结构

DWH是来自不同来源的集成数据的中央存储库。它们将历史数据存储在一个存储系统中。数据以静止状态存储，即保存以供以后分析和处理。业务用户分析数据以找到见解。

数据从操作系统上传，如物联网数据、ERP、CRM和许多其他应用程序。数据清理和数据质量保证是DWH管道中的关键部分。提取、转换、加载（ETL）或提取、加载、转换（ELT）是构建数据仓库系统的两种主要方法。数据集市有助于集中于数据仓库生态系统中的单个主题或业务线。

数据仓库与数据湖和湖屋的关系

数据仓库的重点是使用结构化数据的报告和商业智能。相反，数据湖是存储和处理原始大数据的同义词。过去，数据湖是使用Hadoop、HDFS和Hive等技术构建的。今天，数据仓库和数据湖已合并为一个解决方案。云原生DWH支持大数据。类似地，云原生数据湖需要使用传统工具的商业智能。

Databricks：从数据湖到数据仓库的演变

几乎所有供应商都是如此。例如，看看领先的大数据供应商之一Databricks的历史，它以Apache Spark公司而闻名。该公司最初是Apache Spark（一个大数据批处理平台）背后的商业供应商。该平台通过使用微批处理的（一些）实时工作负载进行了增强。几年后，Databricks成为了一家完全不同的公司，专注于云、数据分析和数据仓库。Databricks的战略从：

• 向云开放源代码

• 从自管理软件到完全管理的无服务器产品

• 将重点放在Apache Spark到AI/机器学习，以及后来添加的数据仓库功能

• 从单一产品到围绕数据分析的庞大产品组合，包括标准化数据格式（“Delta Lake”）、治理、ETL工具（Delta Live Tables）等，

Databricks和AWS等供应商也为数据湖、数据仓库、商业智能和实时功能的融合创造了一个新的流行词：Lakehouse。

湖边小屋（有时称为数据湖边小屋）并不是什么新鲜事。它结合了独立平台的特点。我写了一篇关于在AWS上使用Kafka结合AWS分析平台构建云原生无服务器湖屋的文章。

Snowflake：从数据仓库到数据湖的演变

这是第一个真正的云原生数据仓库，可用于所有主要云。如今，Snowflake提供了超出传统商业智能范围的更多功能。例如，数据和软件工程师可以通过其他技术和API与Snowflake的数据湖进行交互。数据工程师需要Python接口来分析历史数据，而软件工程师更喜欢任何规模的实时数据摄取和分析。

无论您构建的是数据仓库、数据湖还是湖中小屋：关键的一点是了解动态数据和静态数据之间的差异，以便为您的解决方案找到合适的企业体系结构和组件。以下部分探讨了为什么一个好的数据仓库体系结构需要两者，以及它们如何很好地相互补充。

事务性实时工作负载不应在数据仓库或数据湖中运行！由于不同的正常运行时间SLA、法规和法规遵从性法律以及延迟要求，关注点的分离至关重要。

数据流：用动态数据补充现代数据仓库

让我们澄清一下：数据流与数据摄取不同！您可以使用ApacheKafka之类的数据流技术将数据摄入数据仓库或数据湖。大多数公司都这样做。精致而珍贵。

但是：像ApacheKafka这样的数据流平台不仅仅是一个摄取层。因此，它与AWS Kinesis、Google Pub/Sub和类似工具等摄取引擎有很大不同。

数据流与数据摄取不同

数据流提供消息传递、持久性、集成和处理功能。内置功能包括每秒数百万条消息的高可扩展性、包括向后兼容性和任务关键型工作负载的滚动升级在内的高可用性，以及云原生功能。

数据流的事实标准是Apache Kafka。因此，我主要将Kafka用于数据流架构和用例。

使用Apache Kafka进行数据流的事务和分析用例

数据流的不同用例的数量几乎是无穷无尽的。请记住，数据流不仅仅是数据接收的消息队列！虽然数据湖中的数据摄取是第一个突出的用例，但这意味着实际Kafka部署的不足5%。业务应用程序、流式ETL中间件、实时分析和边缘/混合场景是其他一些示例：

Kafka的持久层为敏捷和真正解耦的应用程序提供了分散的微服务架构。

请记住，Apache Kafka支持事务和分析工作负载。两者通常具有非常不同的正常运行时间、延迟和数据丢失SLA。查看这篇文章和幻灯片，了解更多由Apache Kafka支持的跨行业数据流用例。

不要（尝试）使用数据仓库或数据湖进行数据流

本文探讨了静态数据和动态数据之间的差异：

• 数据仓库在报告和商业智能方面非常出色。

• 数据湖非常适合大数据分析和人工智能/机器学习。

• 数据流支持实时用例。

• 需要一个分散、灵活的企业架构来围绕微服务和数据网格构建现代数据堆栈。

这些技术都不是万能的。为问题选择正确的工具。单片架构不能解决当今的业务问题。仅在静态存储所有数据无助于满足实时用例的需求。

Kappa架构是一种用于实时和批处理工作负载的现代方法，以避免使用Lambda架构的更复杂的基础架构。数据流补充了数据仓库和数据湖。如果您选择了合适的供应商（通常是战略合作伙伴，而不是一些人认为的竞争对手），这些系统之间的连接是现成的。

今天您如何将数据仓库和数据流结合起来？Kafka只是你进入数据湖的摄取层吗？您是否已经将数据流用于其他实时用例？还是Kafka已经是企业架构中的战略组件，用于分离微服务和数据网格？

原文标题：Data Warehouse vs. Data Lake vs. Data Streaming: Friends, Enemies, Frenemies?
原文作者：Kai Wähner
原文链接：https://dzone.com/articles/data-warehouse-vs-data-lake-vs-data-streaming-frie