数据仓库与数据湖与数据流

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

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

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

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

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

一个事件有多重要？

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

• 业务交易：理想情况下，零停机时间和零数据丢失。示例：付款只需要处理一次。
• 关键分析：理想情况下，零停机时间。单个传感器事件的数据丢失可能没问题。对事件聚合发出警报更为重要。示例：持续监控物联网传感器数据和（预测性）机器故障警报。
• 非关键分析：停机和数据丢失并不好，但不会扼杀整个业务。这是意外，但不是灾难。示例：用于预测需求的报告和商业智能。

何时处理事件

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

• 业务交易通常是实时的：像支付这样的交易通常需要实时处理（例如，在顾客离开商店之前；在您发货之前；在您离开网约车之前）。
• 关键分析通常是实时的：关键分析通常需要实时处理（例如，在欺诈发生之前检测到；在机器损坏之前预测机器故障；在客户离开商店之前向其追加销售）。
• 非关键分析通常不是实时的：在历史数据中寻找见解通常是在批处理过程中使用复杂的 SQL 查询、map-reduce 或复杂算法（例如，报告；使用机器学习算法进行模型训练；预测）等范例完成的).

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

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

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

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

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

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

有充分的理由让 Splunk 用户高兴地将一些数据提取到 Elasticsearch 中。以及为什么 Cribl 在这个领域也越来越受欢迎。

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

为具有去中心化数据所有权的工作选择合适的工具！

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

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

数据仓库 (DWH) 提供报告和数据分析功能。它被认为是商业智能的核心组成部分。

静态数据的用例

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

• 报告和商业智能：快速灵活地提供报告、统计数据和关键数据，例如，确定市场和服务产品之间的相关性
• 数据工程：整合来自不同结构和分布式数据集的数据，以识别数据之间隐藏的关系
• 大数据分析和人工智能/机器学习：源数据的全局视图，从而进行总体评估以发现未知的见解，从而改进业务流程和相互关系。

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

数据仓库架构

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

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

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

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

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

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

• 开源到云端
• 自管理软件到完全托管的无服务器产品
• 专注于 Apache Spark 到 AI/机器学习以及后来添加的数据仓库功能
• 从单一产品到围绕数据分析的庞大产品组合，包括标准化数据格式（“Delta Lake”）、治理、ETL 工具（Delta Live Tables）等，

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

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

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

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

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

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

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

让我们澄清一下：数据流与数据摄取不同！您可以使用 Apache Kafka 等数据流技术将数据引入数据仓库或数据湖。大多数公司都这样做。很好很有价值。

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

数据流与数据摄取不同

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

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

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

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

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

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

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

本文探讨了静态数据和动态数据之间的区别：

• 数据仓库非常适合报告和商业智能。
• 数据湖非常适合大数据分析和人工智能/机器学习。
• 数据流支持实时用例。
• 需要一个分散的、灵活的企业架构来围绕微服务和数据网格构建现代数据堆栈。

没有一项技术是灵丹妙药。为问题选择正确的工具。单体架构无法解决当今的业务问题。仅静态存储所有数据无助于满足实时用例的需求。

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

您今天如何结合数据仓库和数据流？Kafka 只是您进入数据湖的摄取层吗？您是否已经将数据流用于其他实时用例？或者 Kafka 是否已经成为企业架构中用于解耦微服务和数据网格的战略组件？