数据仓库vs.数据湖vs.数据流
让我们比较一下数据仓库与数据湖与数据流。在现代数据栈中，它们是朋友、敌人，还是敌人？
数据仓库、数据湖和数据流的概念和架构对于解决业务问题是相辅相成的。为报告和分析而存储静态数据与为实时工作负载而持续处理运动中的数据需要不同的能力和SLA。有许多开源框架、商业产品和SaaS云服务。不幸的是，底层技术经常被误解，被过度用于单体和不灵活的架构，并被供应商投向错误的使用案例。
数据的价值：事务性工作负载与分析性工作负载
在过去的十年中，有许多关于数据成为新的石油的文章、博客和演讲。今天，没有人质疑，数据驱动的业务流程改变了世界，并实现了跨行业的创新。
数据驱动的业务流程既需要实时数据处理，也需要批量处理。想一想下面这个跨越应用、领域和组织的事件流。
一个事件是商业信息或技术信息。事件无时无刻不在发生。现实世界中的一个业务流程需要各种事件的关联性。
一个事件有多重要？
一个事件的关键性决定了其结果。潜在的影响可以是增加收入，减少风险，降低成本，或改善客户体验：
- 商业交易：理想情况下，零停机时间和零数据丢失。例子。支付需要被精确地处理一次。
- 关键分析：理想情况下，零停机时间。单个传感器事件的数据丢失可能是可以的。对事件的聚集发出警报则更为关键。例子。连续监测物联网传感器数据和（预测性）机器故障警报。
- 非关键性的分析：停机和数据丢失是不好的，但不会扼杀整个业务。它是一个意外，但不是一个灾难。例子。报告和商业智能来预测需求。
何时处理一个事件
实时通常意味着在几毫秒或几秒钟内完成端到端的处理。如果你不需要实时决策，批处理（即几分钟、几小时、几天后）或按需处理（即请求-回复）就足够了：
- 商业交易往往是实时的：像支付这样的交易通常需要实时处理（例如，在客户离开商店之前；在你运送物品之前；在你离开乘用车之前）。
- 关键分析通常是实时的：关键性分析很多时候需要实时处理（例如，在欺诈行为发生之前发现它；在机器损坏之前预测它的故障；在顾客离开商店之前向他追加销售）。
- 非关键性的分析通常不是实时的：在历史数据中寻找洞察力通常是在批处理过程中使用复杂的SQL查询、map-reduce或复杂的算法（例如，报告；用机器学习算法进行模型训练；预测）等范式。
有了这些关于处理事件的基础知识，让我们了解为什么将所有事件存储在一个单一的中央数据湖中并不是所有问题的解决方案。
通过分散化和最佳化的灵活性
传统的数据仓库和数据湖的方法是将所有的数据从所有的来源摄入到一个中央存储系统，以获得集中的数据所有权。天空（和你的预算）是当前大数据和云技术的极限。
然而，像领域驱动设计、微服务和数据网格这样的架构概念表明，分散的所有权是现代企业架构的正确选择。
不用担心。 **数据仓库和数据湖并没有死，而是在一个数据驱动的世界中比以前更有意义。**两者对许多用例都有意义。即使在其中一个领域，大型组织也不会使用单一的数据仓库或数据湖。为工作选择合适的工具（在你的领域或业务部门）是解决业务问题的最佳方式。
人们有很好的理由对Databricks的批处理ETL、机器学习，甚至现在的数据仓库感到满意，但在一些用例中仍然喜欢像AWS RDS这样的轻量级云SQL数据库（完全管理PostgreSQL）。
有很好的理由让Splunk用户也将一些数据摄入Elasticsearch中，而不是。这也是为什么Cribl在这个领域越来越受欢迎的原因。
一些项目利用 Apache Kafka作为数据库是有原因的。在Kafka中长期存储数据只对一些特定的用例有意义（如压缩主题、键/值查询和流分析）。Kafka并不能取代其他数据库或数据湖。
选择合适的工具来完成分散数据所有权的工作!
考虑到这一点，让我们来探讨一下现代数据仓库的用例和附加价值（以及它与数据湖和新的流行语--湖库的关系）。
数据仓库：使用静态数据的报告和商业智能
数据仓库（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等供应商还为这种数据湖、数据仓库、商业智能和实时能力的合并创造了一个新的流行词。湖心岛。
湖心岛（有时称为数据湖心岛） 并不是什么新鲜事。它结合了不同平台的特点。我写过一篇关于 在AWS上使用Kafka和AWS分析平台建立 云原生无服务器湖心岛的文章。
Snowflake。从数据仓库到数据湖的演变
Snowflake是从另一个方向来的。它是第一个真正的云原生数据仓库，可用于所有主要云。今天，Snowflake 提供了许多超越传统商业智能范围的功能。例如，数据和软件工程师有功能通过其他技术和 API 与 Snowflake 的数据湖互动。数据工程师需要一个Python接口来分析历史数据，而软件工程师更喜欢在任何规模的实时数据摄入和分析。
不管你建立的是数据仓库、数据湖还是湖心岛。关键的一点是了解运动中的数据和静止的数据之间的区别，为你的解决方案找到合适的企业架构和组件。下面的章节探讨了为什么一个好的数据仓库架构需要两者，以及它们如何很好地互补。
**交易性的实时工作负载不应该在数据仓库或数据湖内运行!**由于不同的正常运行时间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已经是企业架构中解耦微服务和数据网状结构的战略组成部分？
