数据仓库数据湖数据流-朋友，敌人，亦敌亦友？

数据仓库、数据湖和数据流的概念和架构在解决业务问题方面是互补的。为报告和分析存储静态数据与为实时工作负载持续处理动态数据需要不同的能力和SLA。有许多开源框架、商业产品和SaaS云服务。不幸的是，底层技术经常被误解，被过度用于单体和不灵活的架构，并被供应商投向错误的用例。让我们在博客系列中探讨这一困境。了解如何利用云原生技术建立一个现代数据堆栈。这是第1部分。数据仓库vs.数据湖vs.数据流--朋友、敌人、敌人？

原载于Kai Waehner的博客。

本博客系列探讨了现代数据栈的概念、功能和权衡，将数据仓库、数据湖和数据流结合起来使用。

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

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

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

一个事件是商业信息或技术信息。事件无时无刻不在发生。现实世界中的一个业务流程需要将各种事件联系起来。

一个事件有多关键？

一个事件的关键性决定了其结果。潜在的影响可以是增加收入，减少风险，降低成本，或改善客户体验。

商业交易。理想情况下，零停机时间和零数据丢失。例子。付款需要准确地处理一次。

关键的分析。理想情况下，零停机时间。单个传感器事件的数据丢失可能是可以的。对事件的汇总发出警报则更为关键。例子。连续监测物联网传感器数据和（预测性）机器故障警报。

非关键性的分析。停机和数据丢失是不好的，但不会扼杀整个企业。它是一个意外，但不是一个灾难。例子。报告和商业智能来预测需求。

什么时候处理一个事件？

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

商业交易往往是实时的。像付款这样的交易通常需要实时处理（例如，在顾客离开商店之前；在你运送物品之前；在你离开乘车的时候）。

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

非关键性的分析通常不是实时的。在历史数据中寻找洞察力通常是在批处理过程中使用复杂的SQL查询、map-reduce或复杂的算法（例如，报告；用机器学习算法进行模型训练；预测）等范式。

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

通过权力下放和同类最佳的灵活性

传统的数据仓库和数据湖的方法是将所有的数据从所有的来源摄入到一个中央存储系统中，以获得集中的数据所有权。天空（和你的预算）是当前大数据和云技术的极限。

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

不用担心。数据仓库和数据湖并没有死，而是在一个数据驱动的世界中比以往任何时候都更有意义。两者对许多用例都有意义。即使在其中一个领域，较大的组织也不会使用单一的数据仓库或数据湖。为工作选择合适的工具（在你的领域或业务部门）是解决业务问题的最佳方式。

人们对Databricks的批处理ETL、机器学习，甚至现在的数据仓库都很满意，但在一些使用情况下，仍然喜欢像AWS RDS（完全管理的PostgreSQL）这样的轻量级云SQL数据库。

有很好的理由让Splunk用户也将一些数据摄入Elasticsearch中。这也是为什么Cribl在这一领域也得到了越来越多的关注。

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

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

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

数据仓库 用静止的数据进行报告和商业智能

数据仓库（DWH）提供了报告和数据分析的能力。它被认为是商业智能的一个核心组成部分。

静态数据的用例

不管你使用的产品是否被称为数据仓库、数据湖。数据被存储在静止状态，以便进一步处理。

报告和商业智能。快速、灵活地提供报告、统计数据和关键数字，例如，确定市场和服务提供之间的相关性

数据工程。整合来自不同结构和分布的数据集的数据，以便能够识别数据之间的隐藏关系

大数据分析和人工智能/机器学习。对源数据的全球视野，从而进行总体评价，找到未知的见解，以改善业务流程和相互关系。

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

数据仓库架构

DWHs是来自不同来源的综合数据的中央存储库。它们在一个存储系统中存储历史数据。数据是静态存储的，也就是说，为以后的分析和处理而保存。业务用户分析数据，以找到洞察力。

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

数据仓库与数据湖的关系

数据仓库的重点是使用结构化数据的报告和商业智能。与此相反，数据湖是存储和处理原始大数据的代名词。过去，数据湖是用Hadoop、HDFS和Hive等技术建立的。今天，数据仓库和数据湖合并成了一个单一的解决方案。一个云原生的DWH支持大数据。同样，一个云原生的数据湖需要用传统工具进行商业智能。

Databrick 从数据湖到数据仓库的演变

几乎所有的供应商都是如此。例如，看一下领先的大数据供应商之一的历史。Databricks，因其是Apache Spark公司而闻名。该公司最初是Apache Spark背后的商业供应商，是一个大数据批处理平台。该平台通过使用微批处理（一些）实时工作负载得到加强。几个里程碑之后，今天的Databricks是一个完全不同的公司，专注于云、数据分析和数据仓库。Databricks的战略。

开放源码到云端

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

专注于Apache Spark的人工智能/机器学习，后来增加了数据仓库功能

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

像Databricks和AWS这样的供应商也为这种数据湖、数据仓库、商业智能和实时功能的合并创造了一个新的流行语。Lakehouse"。

Lakehouse（有时称为数据湖心岛）并不是什么新鲜事。它结合了不同平台的特点。我曾写过一篇关于构建一个 在AWS上使用Kafka与AWS分析平台相结合的云原生无服务器Lakehouse.

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

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

不管你是建立一个数据仓库，数据湖，还是Lakehouse。关键的一点是了解流数据和静止的数据之间的区别，为你的解决方案找到合适的企业架构和组件。下面几节将探讨为什么一个好的数据仓库架构需要两者，以及它们如何很好地互补。

事务性的实时工作负载不应该在数据仓库或数据湖内运行!由于不同的正常运行时间SLA，监管和合规法律，以及延迟要求，关注点的分离是至关重要的。

数据流 用运动中的数据补充现代数据仓库

让我们澄清一下。数据流并不等同于数据摄取!你可以使用像Apache Kafka这样的数据流技术，将数据输入到数据仓库或数据湖。大多数公司都这样做。这很好，也很有价值。

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

数据流不等同于数据摄取

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

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

使用Apache Kafka进行数据流的交易和分析用例

数据流的不同用例几乎是无穷无尽的。请记住，数据流不仅仅是一个用于数据摄取的消息队列。虽然将数据摄入数据湖是第一个突出的用例，但这意味着

Kafka的持久层使分散的微服务架构能够实现敏捷和真正解耦的应用。

请牢记 Apache Kafka支持事务性和分析性工作负载.两者通常有非常不同的正常运行时间、延迟和数据丢失SLA。请看这篇帖子和幻灯片，了解更多关于 由Apache Kafka驱动的跨行业数据流使用案例.

不要（试图）使用数据仓库或数据湖来进行数据流处理

这篇博文探讨了静止的数据和运动的数据之间的区别。

数据仓库是报告和商业智能的最佳选择。

数据湖是大数据分析和人工智能/机器学习的完美选择。

数据流实现了实时用例。

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

没有一项技术是银弹。为问题选择正确的工具。单一的架构并不能解决今天的业务问题。只在静止状态下存储所有的数据，对实时用例的需求没有帮助。

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

今天，你如何将数据仓库和数据流结合起来？Kafka只是你进入数据湖的摄入层吗？你是否已经利用数据流来实现额外的实时用例？还是Kafka已经成为企业架构中解耦微服务和数据网状结构的战略组成部分？