暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

数据仓库 vs.数据湖 vs 数据流

原创 X丶 2022-10-21
361

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

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

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

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

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

事件有多重要?

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

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

何时处理事件

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

  • 业务交易通常是实时的:像付款这样的交易通常需要实时处理(例如,在客户离开商店之前,在您运送物品之前,在您离开乘车之前)。
  • 关键分析通常是实时的:关键分析通常需要实时处理(例如,在欺诈发生之前检测到欺诈,在机器发生故障之前预测机器故障,在客户离开商店之前向他追加销售)。
  • 非关键分析通常不是实时的:在历史数据中查找见解通常是使用复杂SQL查询,映射约简或复杂算法(例如,报告,使用机器学习算法进行模型训练,预测)等范例的批处理过程中完成的。
    有了这些关于处理事件的基础知识,让我们了解为什么将所有事件存储在单个中央数据湖中并不能解决所有问题。

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

传统的数据仓库分别是数据湖方法是将来自所有来源的所有数据引入中央存储系统,以进行集中的数据所有权。天空(和你的预算)是当前大数据和云技术的极限。

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

不用担心。 数据仓库和数据湖并没有死,但在数据驱动的世界中比以往任何时候都更加重要。两者对于许多用例都是有意义的。即使在其中一个域中,大型组织也不会使用单个数据仓库或数据湖。为作业(在您的域或业务部门中)选择正确的工具是解决业务问题的最佳方法。

人们有充分的理由对批量ETL,机器学习以及现在数据仓库的数据砖感到满意,但对于某些用例,人们仍然更喜欢像AWS RDS(完全托管的PostgreSQL)这样的轻量级云SQL数据库。

Splunk用户也有充分的理由将一些数据引入弹性搜索。以及为什么Cribl在这个领域也越来越有吸引力。

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

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

考虑到这一点,让我们探讨现代数据仓库的用例和附加值的关系。

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

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

静态数据的使用案例

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

报告和商业智能:快速灵活地提供报告、统计数据和关键数据,例如,识别市场和服务产品之间的相关性
数据工程:集成来自不同结构和分布式数据集的数据,以识别数据之间的隐藏关系
大数据分析与 AI/机器学习:源数据的全局视图,从而进行总体评估,以发现未知的见解,从而改善业务流程和相互关系。
有些读者可能会说:只有第一个是数据仓库的用例,另外两个是数据湖或湖屋!这完全取决于定义。

数据仓库体系结构

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

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

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

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

数据砖:从数据湖到数据仓库的演变

几乎所有供应商都是如此。例如,看看领先的大数据供应商之一的历史:数据砖,以阿帕奇火花公司而闻名。该公司最初是大数据批处理平台Apache Spark背后的商业供应商。该平台使用微批处理增强了(某些)实时工作负载。几个里程碑之后,Databricks今天是一家完全不同的公司,专注于云,数据分析和数据仓库。数据砖的策略从以下方面改变:

  • 开源到云
  • 从自我管理的软件到完全托管的无服务器产品
  • 专注于 Apache Spark 到 AI/机器学习,后来又增加了数据仓库功能
  • 从单一产品到围绕数据分析的大量产品组合,包括标准化数据格式(“三角洲湖”),治理,ETL工具(增量实时表)等,
  • 像Databricks和AWS这样的供应商也为数据湖,数据仓库,商业智能和实时功能的合并创造了一个新的流行语:湖屋。

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

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

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

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

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

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

让我们澄清一下:数据流与数据引入不同!您可以使用像阿帕奇卡这样的数据流技术将数据引入数据仓库或数据湖。大多数公司都这样做。精致而有价值。

但是:像阿帕奇卡夫卡这样的数据流平台不仅仅是一个摄取层。因此,它与AWS Kinesis,谷歌发布/订阅和类似工具等摄取引擎有很大不同。

数据流与数据引入不同

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

数据流的事实标准是阿帕奇卡夫卡。因此,我主要将 Kafka 用于数据流架构和用例。

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

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

Kafka的持久化层支持分散的微服务架构,以实现敏捷和真正解耦的应用程序。

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

不要(尝试)使用数据仓库或数据湖进行数据流

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

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

没有一项技术是银弹。为问题选择正确的工具。整体式架构不能解决当今的业务问题。仅静态存储所有数据无助于满足对实时用例的需求。

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

「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论