颠覆者 打破 Data Lake 的不可能三角

Source: Dev.to

Source: …

简要介绍数据湖

1. 数据仓库回顾

数据仓库是一种面向主题的数据管理系统，用于聚合来自不同业务系统的数据，以供查询和分析。

• 随着数据量的增长和源系统数量的增加，数据仓库变得至关重要。
• 为了满足业务需求，原始数据必须在加载到仓库之前 清洗、转换并深度准备。
• 数据仓库的核心任务是回答 预定义的业务问题。这些问题必须在构建模型之前就已存在。

Problem: 如果一个有价值的业务问题尚未被定义，该怎么办？
在传统仓库中，工作流是：

1. 确定业务问题。
2. 构建模型来回答它。

这个链条可能很长，而且因为仓库存储的是高度准备好的数据，回答新问题往往需要 重新处理原始数据 以获得更细粒度——这是一项昂贵且低效的操作，尤其是在出现大量新问题时。

2. 为什么会出现数据湖

数据湖是一种用于存储和分析海量 原始数据 的技术（或策略）。其目标是：

1. 尽可能多地存储原始数据，并保持最高的保真度。
2. 从完整数据集中提取任何潜在价值。

因此，数据湖有两个显而易见的角色：

3. 数据湖在两个方面的表现

存储

• 湖中存放 完整的原始数据——结构化、半结构化和非结构化——保持其原始形态。
• 这种海量、多样的存储能力使其区别于通常只在数据库中存储结构化数据的数据仓库。
• 尽早加载数据 能够实现：
  • 完全利用跨域关联。
  • 更好的数据安全性和完整性。

Implementation note: 现代存储和云技术使得大规模原始数据存储成为可能。企业可以在自建存储集群和云服务提供商的存储服务之间进行选择。

处理

最棘手的挑战是 数据处理：

• 湖中包含多种数据类型，每种都需要不同的处理方式。
• 结构化数据 仍是核心且最复杂的处理对象，因为历史数据和新生成的业务数据通常都是结构化的。
• 实际上，半结构化和非结构化数据往往会被转换为结构化格式以便计算。

当前格局

• 基于 SQL 的数据库（即数据仓库使用的相同技术）主导结构化数据的处理。
• 因此，大多数数据湖解决方案 依赖数据仓库（或数据库）来计算结构化数据。
• 典型工作流：
  1. 将原始数据存入湖中。
  2. 将所需数据 ETL（或 ELT） 到仓库进行处理。

一种高级方法会自动化该管道的一部分：识别应加载到仓库的湖中数据，并在空闲时段完成加载。这正是热门 Lakehouse 概念的核心思路。

Bottom line: 当今的数据湖实际上由三个组件组成：

1. 大规模数据存储。
2. 用于结构化数据处理的数据仓库层。
3. 用于半结构化/非结构化数据的专用引擎。

4. 数据湖的关键需求

Reality check: 当前技术栈无法同时满足 全部三项。

5. 以原始形式存储数据的方法

一对一存储映射

• 保持忠实度的最简单方式是将每个来源的数据存储在 与来源相同类型的存储介质 中。
  • 示例：MySQL 数据 → 数据湖中的 MySQL 存储，MongoDB 数据 → MongoDB 存储，等等。
• 好处：
  • 几乎完美的忠实度（hi‑fi）。
  • 利用来源本身的原生计算能力来处理仅涉及该来源的查询。
• 缺点：
  • 开发成本高——必须采购并维护许多不同的存储系统。
  • 数据迁移工作量大（复制多年累计的数据）。
  • 如果来源使用商业软件，许可证费用会进一步增加。

一种更便宜的变体是将数据存储在 不同但相似 的系统中（例如，将 Oracle 数据存入 MySQL）。这可以降低成本，但可能会使某些计算 变得不可能或非常困难。

降低门槛

“现在，让我们降低门槛。我们不要求在加载时就复制数据，而是只要…”

（原文在此处被截断。预期的后续内容可能讨论一种更务实的方法，例如将原始文件存入统一的对象存储，并采用 schema‑on‑read 技术。）

6. 要点

1. 数据仓库 擅长在 已准备好的 数据上回答 预定义的 问题。
2. 数据湖 旨在保留 所有原始数据，以供 任何未来 的问题使用，保持真实性并支持更广泛的分析。
3. 处理差距——尤其是针对结构化数据——迫使大多数数据湖实现依赖于仓库或湖仓层。
4. 同时实现 高保真、强计算和低成本 仍是一个未解的挑战，推动湖仓架构以及统一存储/计算平台的持续创新。

“不可能三角”数据湖

当我们尝试 将数据加载到关系型数据库 时，能够利用数据库的计算能力并满足低成本开发的需求（如图的第二部分所示）。
然而，这种做法往往 不可行，因为它要求 所有数据都进入同一个关系型数据库。

为什么直接加载会失败

• 在加载过程中可能出现 信息丢失，这违背了数据湖的第一条要求：加载高保真数据。
• MongoDB → MySQL/Hive 是一个典型痛点：许多 MongoDB 的数据类型和关系（嵌套结构、数组、哈希、 多对多 链接）在 MySQL 中根本 不存在。
• 为了迁移，你必须 重新结构化 数据，这涉及一系列复杂的重组织步骤。这样既 成本低效、耗时，又容易产生隐藏错误。

基于文件的存储：一种部分补救方案

一种常见的变通办法是 将数据原样存放在大文件中（或作为数据库中的大字段）。

优势

• 信息损失最小——数据基本保持完整。
• 更高的 灵活性、开放性以及更好的 I/O 效率。
• 存储成本更低（文件系统成本低廉）。

缺点

• 文件（或大字段） 缺乏计算能力，导致无法满足便利/足够的计算需求。
• “不可能三角”（节约成本、高保真加载、便利计算）似乎无法破解。

根本原因

冲突源于 传统数据库的封闭特性 以及其严格的约束：

1. 数据必须 清洗并转换 以符合模式规则后才能加载。
2. 这种转换不可避免地导致 信息丢失。

转向纯文件存储可以解决保真度问题，但 失去了计算引擎，除非采用硬编码——这远非便利的做法。

开放计算引擎打破三角形

一个 开放计算引擎 可以提供缺失的环节：足够、便捷的计算能力，能够直接在存储于各种来源的原始数据上实时工作。

SPL – 结构化数据计算引擎

• 开源，专为数据湖设计。
• 提供 多源混合计算：能够 直接 从原始存储（数据库、文件、NoSQL、RESTful API）对原始数据进行计算，无需事先转换。
• 支持 数据湖使用的任何存储介质——无论是相同的来源类型还是普通文件。

关键收益

全面计算能力

直接访问源数据

• 在 SPL 中进行 Join 使传统数据仓库成为可选项。
• SPL 提供 高性能文件存储策略，灵活且易于并行化。

高性能存储格式

简单的并行处理

许多 SPL 函数（文件检索、过滤、排序等） 支持并行执行。
要启用多线程，只需在函数调用后添加 @m 选项：

// 示例：并行排序
sort @m input_file output_file

这种 自动多线程 让您以最小的工作量充分利用多核 CPU。

结论

通过利用像 SPL 这样的 开放、与源无关的计算引擎，您可以：

1. 快速加载高保真数据（节约成本）。
2. 保持数据原始形态（开放性）。
3. 提供足够且便利的计算能力（性能）。

换句话说，SPL 打破了不可能的三角难题，使构建真正开放、高效的数据湖成为可能。

并行执行

• SPL（结构化处理语言）允许开发者显式编写并行程序，提升计算性能。

高性能算法

• SPL 包含许多 SQL 难以高效实现的算法。

• 一个常见示例是 Top‑N 操作：

  • SPL 将 Top‑N 视为 聚合操作，将昂贵的排序转换为低复杂度的聚合。
  • 同一语句既可用于从整个集合 或 从分组子集检索前 N 条记录，均能提供高性能。

• 不出现任何与排序相关的关键字 在 SPL 语句中，因此永远不会触发完整排序。

性能优势

• 通过这些机制，SPL 能够提供 数量级更高的性能，远超传统数据仓库。
• 数据转换后出现的存储和计算挑战得到解决，消除了对单独数据湖的需求。

Mixed‑Data Computation

• SPL 可以直接在 已转换数据和原始数据 上进行计算，利用来自异构数据源的值，无需事先准备。
• 该能力实现了 高度敏捷的数据湖。

同时进行湖泊构建阶段

• 传统管道需要顺序步骤：加载 → 转换 → 计算。

• SPL 允许这些阶段并发运行：

  • 数据准备和计算可以并行进行。
  • 任意类型的原始、非结构化数据都可以直接处理。

• 将转换和计算一起处理——而不是按串行顺序——是构建理想数据湖的关键。