什么是数据湖？
无爬虫网络解锁器检索公共网络内容，数据团队可以验证、保存并作为受管源数据放入数据湖。
简报
- 数据湖存储着多样的数据，前期转化有限。 原始、半结构化、结构化和二进制对象可以共享一个受管的存储环境。
- 仅有存储并不足以构成湖。 目录、所有权、访问政策、质量检查和生命周期规则使内容可用。
- 当数据被读取时，通常会应用架构。 消费者可以为探索、机器学习或下游策展塑造同一源。
- 开放文件格式提高了互操作性。 列式和表格格式允许多个引擎在共享数据上工作，而不受一个专有数据库的限制。
- 一个湖可以补充经过整理的系统。 可信的仓库表和数据产品可以从受管的湖区构建，而不是替换每个分析存储。
数据湖定义
数据湖是保留大量数据的一个存储库和管理模式，数据形式接近其源表示。它通常使用耐用的对象或文件存储，并接受结构化表、JSON、日志、文档、多媒体和分析文件格式，在每个下游使用被决定之前。
湖将存储与许多计算引擎分开。查询引擎、笔记本、转换作业或机器学习工作流可以通过目录读取经过批准的对象，并应用该任务所需的架构。只有当数据身份和政策在摄取后继续存在时，这种灵活性才有用。这里使用的主要术语遵循 Microsoft 数据湖架构指南, 这给了概念一个具体的技术边界，而不是将其视为市场营销标签。
一个有用的定义还说明了该概念不做什么。数据湖不是一个无标签的桶，不是所有数据库的替代品，也不是无限保留所有收集对象的许可。它也不保证没有策展、索引、表元数据和特定工作负载计算的低延迟业务报告。保持该边界可见，防止架构图将保证分配给属于另一层的组件。
数据如何在湖中流动
一个有用的湖设计将摄取视为从源证据到可发现资产的受控过渡。每个阶段增加元数据或质量，而不抹去后续重新处理所需的原始上下文。
- 生产者写入一个不可变的源对象，带有起源、收集时间、所有者和分类元数据。
- 验证检查格式、预期字段、访问范围，以及对象是否代表预期的源。
- 目录记录位置、架构观察、分区、血统、质量状态和负责任的数据人员。
- 转换作业创建标准化或策划的数据集，同时保留与源对象的链接。
- 消费者通过适合探索、报告、模型或导出的引擎和权限查询经过批准的区域。
对象存储保存字节，文件格式组织记录，表元数据跟踪逻辑数据集，目录使资产可发现，计算引擎执行工作。保持这些角色分离使团队可以更改查询引擎而无需重写每个源对象。这个行为在 Apache Parquet 文档中有更全面的记录。该源是有用的，因为它描述了实际的执行或数据模型，而不是依赖于松散的类比。
核心数据湖层
| 层 | 主要工作 | 要保留的证据 |
|---|---|---|
| 源区域 | 保留接收的数据 | 起源、时间、校验和、收集上下文 |
| 验证区域 | 拒绝格式错误或意外的输入 | 验证结果和架构观察 |
| 标准化区域 | 标准化名称、类型和分区 | 转换版本和血统 |
| 策划区域 | 服务于特定的业务或模型使用 | 所有者、合同、质量目标 |
| 存档或删除 | 应用保留和法律政策 | 处置原因和授权 |
区域名称各异，但状态转换应明确。将文件复制到新前缀而不改变质量或所有权会创建视觉组织，而不是治理。每个区域应告诉消费者哪些假设是安全的。
常见数据湖工作负载
探索性分析
分析师可以在承诺稳定的数据仓库模型或产品合同之前检查新来源。
机器学习准备
团队可以保留高维度、半结构化和二进制输入，并具有可重复的转换沿袭。
长期源保留
不可变证据支持在解析器、架构或商业问题变化时进行后续重新处理。
多引擎分析
SQL引擎、笔记本、批处理作业和流处理器可以在共享的治理格式上工作。
这些用例共享一个选择规则：选择数据湖，因为其执行和所有权模型与工作负载匹配，而不是因为名称听起来更先进。当工作负载较小、高度事务化或以已经适合策划分析数据库的可预见仪表板为主时，湖泊的吸引力会下降。架构灵活性有运营成本。
区域、目录和治理
治理始于摄取。生产者应在第一批大数据到达之前识别源、目的、所有者、敏感性、保留、预期架构和质量检查。
- 倾向于不可变源对象。 新版本保留证据并使转换可重复，而不会无声地改变历史。
- 使用开放的、类型化的格式。 可移植的列式文件减少扫描工作，并提高分析引擎之间的互操作性。
- 为每个治理资产编制目录。 发现、沿袭、所有权和访问政策不应依赖于部落知识或路径名称。
- 通过区域分隔权限。 原始敏感输入和策划消费者表通常不需要相同的受众。
- 预算用于小文件控制。 压缩和分区政策防止元数据开销主导查询工作。
表格式可以在对象存储上添加快照、架构演变、分区元数据和事务协调。它们并不消除源合同或访问治理的需要；它们使某些存储级别的变更更安全，更易于查询。相关的主要参考是 Apache Iceberg文档, 该文档阐明了选择背后的存储、执行或互操作性假设。
数据湖如何变成数据沼泽
当存储增长快于理解时，会形成数据沼泽。警告信号包括缺失所有权、重复来源、不明确的架构、广泛的权限、不受限制的保留以及消费者重建相同的清理逻辑。
- 仅路径组织。 文件夹无法替代记录意义、沿袭和所有权的目录。
- 无架构思维。 每个消费者都应用假设；未记录的假设只是将架构工作向下移动。
- 没有身份的复制。 没有源键或版本规则的重复文件会产生不一致的分析结果。
- 一个权限边界。 给予所有消费者对原始和策划区域的访问会扩大风险并削弱目的限制。
- 默认保留。 没有生命周期规则的数据会增加成本、法律风险和发现负担。
失败应追溯到最小的责任层。当查询错误时，追溯策划资产到其转换、目录条目、验证结果和不可变源对象，然后再改变消费者计算。此做法产生有用的纠正措施，而不是模糊的指示去增加更多容量。
在湖中着陆公共网络数据
公共网络数据通常以HTML、文本、JSON、截图或提取字段的形式到达。湖可以保留获取的表示，并在后续创建标准化的Parquet或治理表用于分析，前提是管道保持源身份和收集上下文。
对于公共网络输入，获取层应在下游处理开始之前记录请求的URL、最终URL、收集时间、响应模式和内容检查。在对象旁边或在链接的清单中存储请求的和最终的URL、内容类型、校验和、收集时间和验证结果。这个交接为分析师提供了可重复的源记录，并将收集行为与解释分开。
Scrapeless处理开头句子中描述的管理网络收集步骤。该应用程序仍然拥有源批准、字段定义、工作负载边界、保留、访问控制和验证。Scrapeless执行请求的检索，而数据平台决定批准的来源、对象命名、分区、目录注册、权限、保留和下游合同。这些层之间的明确合同使后续更改更易于测试。
当用例需要审核时，管道应同时保留原始证据和策划输出。原材料支持在解析器或架构变化后重新处理；策划表支持稳定分析。只有在目的和保留政策合理时，才能保留原始证据，然后以记录字段和质量期望发布策划产品。这两种表现回答不同的操作问题，不应误认为是重复的。
数据湖架构检查清单
在设计审查期间使用以下问题。书面答案比假设的默认值更有价值，因为它揭示了团队在数据湖方面的不一致之处。
- 哪些源表示必须保持不变？
- 哪些元数据使每个对象可被发现和可重现？
- 哪些格式和表标准必须由多个引擎共享？
- 如何检测模式漂移和不兼容的更改？
- 谁拥有每个策划的数据集并批准其消费者？
- 原始权限和策划权限有何不同？
- 什么合并和分区规则控制文件布局？
- 何时归档或删除数据，这一决定记录在哪里？
一个湖泊在新消费者能够发现资产、理解其合同、验证其来源、请求适当的访问权限，并从保留的证据中重现转换时准备就绪。工作负载形状、数据量、服务限制或消费者期望变化后，请重新审视答案。对探索性批处理而言合理的架构可能不适合连续生产路径。
结论
数据湖结合了灵活的存储、编目、治理和独立计算。它的价值在于保留多样的源数据，同时明确所有权、质量、来源、权限和生命周期。开放格式和表元数据改善互操作性，但它们本身并不产生信任。当每个资产能够通过从证据到消费者准备好的数据产品的文档路径移动时，湖泊才变得有用。
准备构建一个受管控的网络数据湖吗？
收集已批准的公共网络证据，保留来源，并将验证过的对象交给您的湖泊摄取管道。
今天注册并获得 $5的免费信用 — 无需信用卡.
领取您的$5信用→常见问题
数据湖的主要目的是什么？
数据湖保留多样的数据供未来多个用途，而不强迫每个来源在摄取时进入一个仓库架构。它支持探索、机器学习准备、长期证据和多引擎分析。这种灵活性依赖于编目、所有权、访问控制、质量检查和保留政策。
数据湖总是存储在云中吗？
不。数据湖可以使用云对象存储、分布式文件系统或其他持久存储环境。云对象存储很常见，因为它们将存储与计算分开并在运营上进行扩展，但定义特征是灵活保留的数据加上治理和分析访问，而不是一个特定的部署位置。
读取时的模式意味着什么？
读取时的模式意味着消费者在查询数据时应用或解释结构，而不是在源数据存储之前就要求一个最终的分析模式。源数据仍具有物理格式和观察到的字段。好的湖泊平台记录这些事实并验证，而不是假装模式不存在。
数据湖如何变成数据沼泽？
当用户无法发现、信任、理解或安全访问其内容时，湖泊就会变成沼泽。缺乏所有权、弱来源、重复源、未记录的模式、宽泛的权限和不确定的保留是常见原因。更多的存储或新的查询引擎并不能修复这些治理缺口。
公共网络数据可以进入数据湖吗？
可以，当组织有一个批准的目的并遵循适用的访问、隐私、版权、合同和保留要求时。摄取清单应保留源URL、收集上下文、验证状态和所有权。策划输出应保持追溯至受管控源对象的来源。