元数据

Fundamentals of Data Engineering

  •  Fundamentals of Data Engineering|200
  • 书名: Fundamentals of Data Engineering
  • 作者: Matt Housley
  • 简介:
  • 出版时间
  • ISBN:
  • 分类:
  • 出版社: O’Reilly Media, Inc.

高亮划线

技术职责

  • 📌 数据科学家构建前瞻性的模型以进行预测和建议。这些模型随后会在实时数据上进行评估,以提供各种价值。例如,模型评分可能会根据实时条件自动执行某些操作,根据客户当前会话中的浏览历史推荐产品,或者进行实时的经济预测供交易者使用。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-4-69877-69987

    • ⏱ 2024-12-13 18:42:41
  • 📌 数据分析师(或商业分析师)致力于理解业务绩效和趋势。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-4-73068-73094

    • ⏱ 2024-12-13 18:42:08

2. 数据工程生命周期

  • 📌 Schemaless 并不意味着没有模式。相反,它意味着应用程序在数据写入时定义模式,无论是写入消息队列、平面文件、二进制大对象(BLOB)还是文档数据库(如 MongoDB)。传统的模型基于关系数据库存储,使用在数据库中强制执行的固定模式,应用程序的写入必须符合这一模式。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-6-48892-49029

    • ⏱ 2024-12-13 23:38:42
  • 📌 流式摄入使我们能够以连续的、实时的方式将数据提供给下游系统——无论是其他应用程序、数据库还是分析系统。这里,实时(或接近实时)意味着数据在生成后不久(例如,不到一秒钟后)就可供下游系统使用。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-6-78650-78745

    • ⏱ 2024-12-19 14:18:32

数据工程生命周期中的主要趋势

  • 📌 编排是一个中央枢纽,协调各种系统中的工作流 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-7-68740-68761

    • ⏱ 2024-12-19 15:49:56
  • 📌 主数据是关于业务实体(如员工、客户、产品和地点)的数据 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-7-87992-88019

    • ⏱ 2024-12-19 23:03:55
  • 📌 编排是协调许多任务以尽可能快速高效地在预定周期内运行的过程 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-7-108943-108972

    • ⏱ 2024-12-19 23:31:08
  • 📌 而编排引擎内置了作业依赖关系的元数据,通常以有向无环图(DAG)的形式存在。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-7-109036-109074

    • ⏱ 2024-12-19 23:31:57
  • 📌 编排系统监控它管理的任务 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-7-109786-109798

    • ⏱ 2024-12-19 23:37:17

3. 设计良好的数据架构

  • 📌 运营架构描述了需要做什么,而技术架构则详细说明了它是如何实现的。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-9-48543-48575

    • ⏱ 2024-12-20 17:57:26
  • 📌 良好的数据架构是一个有生命力的存在。它永远不会完成。实际上,根据我们的定义,变化和进化是数据架构意义和目的的核心。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-9-55862-55919

    • ⏱ 2024-12-20 18:04:34
  • 📌 提高开发团队的能力使架构师获得的杠杆作用比仅作为决策者要大得多,从而避免成为架构瓶颈的风险。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-9-89662-89808

    • ⏱ 2024-12-20 18:35:14

原则 9: 接受 FinOps

  • 📌 绞杀模式:新的系统会逐渐和逐步地替换遗留架构的组件 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-10-90186-90211
    • ⏱ 2024-12-20 21:32:20

收敛,下一代数据湖,以及数据平台

  • 📌 在 Lambda 架构(图 3-14 中)中,你有独立运行的系统——批处理、流处理和提供服务。源系统最好是不可变且只追加的,将数据发送到两个目的地进行处理:流处理和批处理。流处理旨在在“速度”层以最低的延迟提供数据,通常是一个 NoSQL 数据库。在批处理层,数据在一个如数据仓库的系统中被处理和转换,创建数据的预先计算和聚合视图。提供服务的层通过聚合两层的查询结果提供综合视图。[插图]Figure 3-14. Lambda 架构 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-11-28776-29903

    • ⏱ 2024-12-21 00:17:13
  • 📌 Kappa 架构(图 3-15)。中心论点是:为什么不直接使用流处理平台作为所有数据处理(摄入、存储和提供)的基础?这可以实现真正的事件驱动架构。实时处理和批量处理可以通过直接读取实时事件流并回放大量数据来无缝应用于相同的数据。[插图]Figure 3-15. Kappa 架构 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-11-33356-34395

    • ⏱ 2024-12-21 00:18:17
  • 📌 管理批处理和流处理的一个中心问题是统一多个代码路径。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-11-37344-37370

    • ⏱ 2024-12-21 00:23:46
  • 📌 Dataflow 模型的核心思想是将所有数据视为事件,聚合是在各种类型的时间窗口中进行的。持续的实时事件流是无界数据。数据批次只是有界事件流,边界提供了自然的时间窗口。工程师可以选择各种窗口进行实时聚合,例如滑动窗口或滚动窗口。实时处理和批次处理使用几乎相同的代码在同一系统中进行。“批量处理作为流处理的一种特殊情形”的哲学现在更为普遍。各种框架如 Flink 和 Spark 采用了类似的方法。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-11-38097-38896

    • ⏱ 2024-12-21 00:28:35
  • 📌 任何能够从其环境中收集数据的设备都是物联网设备。设备应该至少能够收集和传输数据。然而,设备在发送数据之前还可能对收集的数据进行处理或运行机器学习,分别称为边缘计算和边缘机器学习。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-11-43351-44041

    • ⏱ 2024-12-21 00:34:54
  • 📌 虽然你可以不使用物联网网关直接将设备连接到互联网,但网关允许设备使用极低的功率进行连接。它充当数据保留的中转站,并管理与最终数据目的地的互联网连接。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-11-47597-47671

    • ⏱ 2024-12-21 00:36:53
  • 📌 统一的批处理/流处理框架(如 Beam、Flink) ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-11-71928-71954

    • ⏱ 2024-12-21 00:52:49

4. 数据工程生命周期中的技术选择

  • 📌 设计稳健可靠的系统,使数据贯穿整个生命周期,并根据最终用户的需求提供数据 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-13-17355-17391

    • ⏱ 2024-12-21 00:54:56
  • 📌 很多人将架构和工具混淆。架构是战略性的;工具是战术性的。我们有时会听到,“我们的数据架构是工具 X、Y 和 Z。”这是一种错误的思考方式。架构是数据系统的高层设计、路线图和蓝图,满足业务的战略目标。架构是“是什么”、“为什么”和“何时”。工具用于实现架构;工具是“怎么做”。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-13-18775-18912

    • ⏱ 2024-12-21 00:56:12
  • 📌 你应该选择适合当下的最佳技术,并且考虑到未来近期内的需求,但也要支持未来未知的变化和发展。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-13-53624-53669

    • ⏱ 2024-12-22 15:00:04
  • 📌 我们有两种类型的工具需要考虑:不可变和瞬时。不可变技术可能是支撑云的基础组件或经受住了时间考验的语言和范式。在云中,不可变技术的例子包括对象存储、网络、服务器和安全。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-13-54350-54433

    • ⏱ 2024-12-22 15:03:06
  • 📌 对于语言来说,SQL 和 bash 已经存在了数十年,我们看不到它们很快消失的迹象。不变的技术受益于林迪效应:一种技术存在的时间越长,它被使用的时间就越长。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-13-55168-55246

    • ⏱ 2024-12-22 15:06:43
  • 📌 许多人对无服务器这个术语有争议;毕竟,代码必须运行在某个地方。实际上,无服务器通常意味着许多看不见的服务器。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-13-72028-72082

    • ⏱ 2024-12-22 15:30:32
  • 📌 混合云模型假设组织将无限期地保留一些工作负载在云端之外。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-13-87286-87314

    • ⏱ 2024-12-22 15:56:22

开源软件

  • 📌 容器则打包一个隔离的用户空间(如文件系统和几个进程) ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-14-102265-102291

    • ⏱ 2024-12-22 17:31:13
  • 📌 容器逃逸——简而言之,是指容器内的代码获得操作系统级别外部特权的一类漏洞——足够常见,以至于在多租户环境中被视为一种风险。虽然亚马逊 EC2 是一个真正的多租户环境,来自许多客户的虚拟机托管在同一硬件上,但 Kubernetes 集群应该仅在可互信的环境中托管代码(例如,单个公司的内部)。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-14-105069-105214

    • ⏱ 2024-12-22 17:35:51

优化、性能与基准测试之争

  • 📌 Serverless 适用于简单的离散任务和工作负载。如果有很多复杂部分或需要大量的计算或内存性能,那么它可能不太合适。在这种情况下,可以考虑使用容器和像 Kubernetes 这样的容器工作流编排框架。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-15-16937-17039
    • ⏱ 2024-12-22 17:50:00

5. 来自源系统的数据生成

  • 📌 OLAP 中的“在线”意味着系统不断监听 incoming queries,使 OLAP 系统适合交互分析。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-17-42500-42554

    • ⏱ 2024-12-22 18:36:53
  • 📌 写前日志——通常是以二进制格式存储在特定数据库原生格式中的文件——在数据库保证和恢复方面发挥着关键作用。数据库服务器接收到对数据库表的写入和更新请求(参见图 5-3),在记录每个操作之前确认请求。确认伴随着日志关联的保证:即使服务器失败,它也可以在重新启动时通过完成日志中的未完成工作来恢复其状态。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-17-65547-65696

    • ⏱ 2024-12-22 21:09:45
  • 📌 消息是事件驱动系统中的离散且单独的信号。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-17-77649-77669

    • ⏱ 2024-12-22 21:19:01
  • 📌 流是一个事件记录的追加日志。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-17-78398-78412

    • ⏱ 2024-12-22 21:19:44
  • 📌 由于流的追加性质,流中的记录会在较长的保留窗口中持久化——通常是几周或几个月,这使得对记录进行复杂的操作成为可能,例如在多个记录上的聚合操作或在流中的某个时间点回溯。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-17-80111-80194

    • ⏱ 2024-12-22 21:24:17
  • 📌 摄入时间表示事件从源系统被摄入到消息队列、缓存、内存、对象存储、数据库或任何其他数据存储位置的时间 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-17-84742-84791

    • ⏱ 2024-12-22 21:41:46
  • 📌 规范化是一种确保记录中的数据不会在多个地方重复的方法,从而避免同时在多个位置更新状态的需要,并防止不一致 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-17-104885-104937

    • ⏱ 2024-12-22 22:03:58
  • 📌 键值存储包括几种 NoSQL 数据库类型——例如,文档存储和宽列数据库 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-17-114662-114697

    • ⏱ 2024-12-22 22:10:49

APIs

  • 📌 我们通常可以将每个文档视为一个 JSON 对象。文档存储在集合中,并通过键检索。集合大致相当于关系数据库中的表 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-18-17035-17090

    • ⏱ 2024-12-22 22:16:35
  • 📌 关系数据库和文档存储之间的一个关键区别在于,后者不支持连接。这意味着数据不能容易地规范化,即不能跨多个表分割。(应用程序仍然可以手动连接。代码可以查找一个文档,提取一个属性,然后检索另一个文档。)理想情况下,所有相关数据都可以存储在同一个文档中。在许多情况下,相同的数据必须存储在多个文档中,这些文档分布在多个集合中;软件工程师必须小心地在所有存储位置更新一个属性。(许多文档存储系统支持事务的概念,以便于这一点。) ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-18-21203-22012

    • ⏱ 2024-12-22 22:16:05
  • 📌 宽列数据库优化用于存储大量数据并具有高交易率和极低延迟。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-18-29457-29485

    • ⏱ 2024-12-24 09:23:31
  • 📌 这些数据库支持快速扫描大量数据,但不支持复杂查询。它们只有一个索引(行键)用于查找。数据工程师通常必须将数据提取到第二个分析系统中,以运行复杂查询来应对这些限制。这可以通过运行大规模扫描进行提取或使用 CDC 捕获事件流来实现。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-18-30265-30379

    • ⏱ 2024-12-24 09:23:08
  • 📌 图数据库在您想要分析元素之间的连接性时是一个不错的选择。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-18-31954-31982

    • ⏱ 2024-12-24 09:24:06
  • 📌 时间序列是一系列按时间组织的值 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-18-43656-43671

    • ⏱ 2024-12-24 09:42:05
  • 📌 这些工作负载通常写入量较大。因此,时间序列数据库经常使用内存缓冲来支持快速写入和读取。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-18-44511-44554

    • ⏱ 2024-12-24 09:44:53
  • 📌 我们应该区分测量数据和事件驱动数据,这两种数据常见于时间序列数据库中。测量数据是定期生成的,比如温度或空气质量传感器。事件驱动数据是不规则的,并且每次发生事件时都会生成,例如当运动传感器检测到运动时。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-18-45155-45255

    • ⏱ 2024-12-24 09:45:11
  • 📌 GraphQL 打开了在单个请求中检索多个数据模型的可能性 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-18-52975-53004

    • ⏱ 2024-12-24 10:10:19
  • 📌 消息和流之间的主要区别在于,消息队列主要用于具有某些投递保证的消息路由。相比之下,事件流平台用于摄取和处理按记录顺序排列的数据。在事件流平台中,数据会保留一段时间,并且可以从过去的时间点重新播放消息。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-18-79967-80067

    • ⏱ 2024-12-24 11:17:09

6. 存储

  • 📌 数据在生命周期中会多次被存储 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-20-17196-17210

    • ⏱ 2024-12-24 16:13:07
  • 📌 行导向的关系型数据库将数据组织为磁盘上的行以支持快速查找和原地更新。列式数据库将数据组织成列文件以优化高效压缩并支持对大量数据进行快速扫描。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-20-51145-51215

    • ⏱ 2024-12-24 16:46:37
  • 📌 另一个缩写是 BASE,它代表基本可用、软状态、最终一致性。可以将其视为 ACID 的对立面。BASE 是最终一致性的基础。让我们简要探讨一下它的组成部分:基本上可用一致性无法保证,但在最佳努力的基础上对数据库进行读写操作,这意味着大多数情况下可以获取到一致的数据。软状态交易的状态模糊不清,不确定交易是已提交还是未提交。最终一致性在某个时刻,读取数据将返回一致的值。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-20-76990-80819

    • ⏱ 2024-12-24 17:04:31
  • 📌 最终一致性是大规模分布式系统中常见的权衡。如果你希望水平扩展(跨多个节点)以处理大量数据,那么最终一致性往往是你要付出的代价。最终一致性允许你快速获取数据,而无需验证所有节点上是否有最新版本。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-20-81457-81553

    • ⏱ 2024-12-24 17:09:14
  • 📌 最终一致性与强一致性相反。在强一致性下,分布式数据库确保任何写操作首先通过共识进行分布,任何对数据库的读取操作返回一致的值。当你可以容忍较高的查询延迟并且每次从数据库读取数据时都需要正确数据时,你将使用强一致性。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-20-82154-82260

    • ⏱ 2024-12-24 17:10:38
  • 📌 一个块是磁盘支持的最小可寻址数据单位。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-20-102408-102427

    • ⏱ 2024-12-24 17:27:13
  • 📌 4,096 字节 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-20-102468-102476

    • ⏱ 2024-12-24 17:29:09
  • 📌 块通常包含额外的位用于错误检测/校正和其他元数据。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-20-102501-102526

    • ⏱ 2024-12-24 17:28:15

对象存储

  • 📌 对象存储是一种用于不可变数据对象的关键值存储。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-21-23761-23784

    • ⏱ 2024-12-24 20:30:01
  • 📌 对象存储现在是数据湖存储的黄金标准 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-21-29283-29300

    • ⏱ 2024-12-24 20:43:55
  • 📌 对象存储是任何格式的非结构化数据的理想存储库,超越了这些结构化数据应用。对象存储可以存储任何二进制数据,没有类型或结构的限制,经常在机器学习管道中用于原始文本、图像、视频和音频。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-21-30087-30176

    • ⏱ 2024-12-24 20:44:05
  • 📌 最终一致性中的“最终”意味着在经过足够的时间后,存储集群将达到一种状态,在这种状态下,只会返回对象的最新版本。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-21-35563-35618

    • ⏱ 2024-12-24 20:52:24
  • 📌 对对象存储施加强一致性可能出于各种原因,通常会使用标准方法来实现这一点。一种方法是将一个强一致性的数据库(例如,PostgreSQL)加入其中。现在写入一个对象是一个两步过程:写对象。将对象版本的返回元数据写入强一致数据库。The version 元数据(一个对象哈希或一个对象时间戳)可以与对象键结合唯一标识一个对象版本。要读取一个对象,一个读者将执行以下步骤:从强一致数据库中获取最新对象元数据。使用对象键查询对象元数据。如果元数据与一致数据库中获取的匹配,则读取对象数据。如果对象元数据不匹配,请重复第 2 步,直到返回对象的最新版本。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-21-36265-40359

    • ⏱ 2024-12-24 20:54:48
  • 📌 当我们在一个对象存储中使用现有键重写一个对象时,实际上是在写入一个全新的对象,将现有键的引用指向该对象,并删除旧的对象引用。在整个集群中更新所有引用需要时间,因此可能会出现陈旧读取。最终,存储集群的垃圾收集器会释放掉未引用数据所占用的空间,回收磁盘容量供新对象使用。启用对象版本化后,我们为对象添加额外的元数据,规定一个版本。虽然默认键引用会更新以指向新对象,但我们保留指向以前版本的其他引用。我们还维护一个版本列表,以便客户端可以获取所有对象版本的列表,然后拉取特定版本。由于旧版本的对象仍然被引用,因此垃圾收集器不会清理它们。如果引用一个对象并指定了版本,某些对象存储系统的一致性问题就会消失:键和版本的元数据一起形成一个唯一的引用,指向一个特定的不可变数据对象。只要我们没有删除它,当我们使用这对组合时,我们总是会得到同一个对象。当客户端请求对象的“默认”或“最新”版本时,一致性问题仍然存在。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-21-41676-43278

    • ⏱ 2024-12-24 21:10:28
  • 📌 将对象存储挂载为本地文件系统适用于更新不频繁的文件。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-21-50200-50226

    • ⏱ 2024-12-24 21:19:06
  • 📌 Kafka 通过将旧的、不常访问的消息推送到对象存储来支持无限期的数据保留。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-21-63190-63228

    • ⏱ 2024-12-24 21:28:54
  • 📌 Replay 允许流式系统返回一定范围的历史存储数据。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-21-63984-64011

    • ⏱ 2024-12-24 21:29:24
  • 📌 列式数据库在事务性用例中表现不佳——即,当我们尝试异步查找大量单独的行时。然而,当必须扫描大量数据时,它们表现非常出色——例如,用于复杂数据转换、聚合、统计计算或在大数据集上评估复杂条件。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-21-70583-70677

    • ⏱ 2024-12-24 21:39:37
  • 📌 数据湖是一个存储大量未处理原始数据的区域 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-21-87782-87802

    • ⏱ 2024-12-25 08:15:05
  • 📌 数据目录是组织内所有数据的集中元数据存储 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-21-102714-102734

    • ⏱ 2024-12-25 08:41:48
  • 📌 在实践中,目录系统通常需要依赖一个自动扫描层,从数据湖、数据仓库和运营数据库等各种系统中收集元数据。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-21-106342-106392

    • ⏱ 2024-12-25 08:48:02
  • 📌 Schema 可以作为一种罗塞塔石碑,指示我们如何读取数据。有两种主要的模式:写时模式和读时模式。写时模式本质上是传统的数据仓库模式:一个表具有集成的模式;对该表的任何写操作都必须符合。为了支持写时模式,数据湖必须集成一个模式元存储库。With schema on read,当数据写入时会动态创建模式,读者在读取数据时必须确定模式。理想情况下,schema on read 是通过实现内置模式信息的文件格式来实现的,例如 Parquet 或 JSON。CSV 文件因模式不一致而臭名昭著,在这种情况下不推荐使用。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-21-115053-115911

    • ⏱ 2024-12-25 09:07:11

计算与存储分离

  • 📌 With 多层缓存,我们利用对象存储进行长期数据保留和访问,但在查询和数据管道的各个阶段使用本地存储。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-22-27577-27628

    • ⏱ 2024-12-25 09:16:25
  • 📌 基于云的对象存储系统支持零拷贝克隆。这通常意味着创建一个新的对象虚拟副本(例如,一个新的表)而不必物理复制底层数据。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-22-38941-38999

    • ⏱ 2024-12-25 09:28:15
  • 📌 当你考虑访问频率和使用场景时,问自己,“这些数据对下游用户有多重要,他们多久需要访问一次?”这就是数据存储生命周期。另一个你应该问的问题是,“我应该保留这些数据多长时间?”你是否需要无限期地保留数据,还是在某个时间点之后就可以丢弃它?这就是数据保留。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-22-42088-42213

    • ⏱ 2024-12-25 09:33:46
  • 📌 温数据偶尔会被访问,大约一个月一次。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-22-48295-48313

    • ⏱ 2024-12-25 09:40:51
  • 📌 冷数据主要是为了长期归档,几乎没有访问数据的意图。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-22-49897-49922

    • ⏱ 2024-12-25 10:24:28
  • 📌 多租户存储允许多个租户在同一数据库中存储数据 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-22-66065-66087

    • ⏱ 2024-12-25 10:43:09

7. 摄入

  • 📌 数据摄取意味着在数据工程生命周期中,从源系统将数据移动到存储,摄取是中间步骤 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-23-19689-19727
    • ⏱ 2024-12-25 11:37:36

模式演化

  • 📌 为了处理晚到的数据,你需要设定一个截止时间,超过这个时间的数据将不再被处理。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-24-20913-20951

    • ⏱ 2024-12-25 15:32:37
  • 📌 回忆消息和流之间的区别。消息在个体事件级别处理,旨在临时使用。一旦消息被消费,就会被确认并从队列中移除。另一方面,流将事件摄入到有序日志中。日志可以持续保存任意长时间,允许对事件进行查询、聚合,并与其他流结合以创建新的转换,这些转换发布给下游消费者。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-24-65260-65385

    • ⏱ 2024-12-25 16:21:23
  • 📌 对于列式数据库,列式格式(Parquet、Arrow、ORC)能够更高效地导出数据 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-24-79546-79587

    • ⏱ 2024-12-25 16:47:43
  • 📌 始终加密数据传输是一个好习惯。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-24-113958-113973

    • ⏱ 2024-12-25 17:17:26

DataOps

  • 📌 尽可能在涉及敏感数据的情况下实现无接触生产。这意味着工程师在开发和测试环境中使用模拟或清理的数据来开发和测试代码,但在生产环境中进行自动代码部署。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-25-21628-21701

    • ⏱ 2024-12-25 17:24:57
  • 📌 要警惕天真地用技术解决方案来解决人类问题。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-25-23056-23077

    • ⏱ 2024-12-25 17:26:23
  • 📌 随着数据管道复杂性的增长,真正的编排是必要的。所谓真正的编排,是指能够调度完整的任务图谱而不仅仅是单个任务的系统。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-25-37881-37938

    • ⏱ 2024-12-25 17:43:56

8. 查询、建模和转换

  • 📌 提高查询性能的一种常见技术是预先连接数据。如果你发现分析查询反复连接相同的数据,通常提前连接数据并在查询时读取预先连接的数据版本是有意义的,这样就不必重复进行计算密集型的工作。这可能意味着改变模式并放宽规范化条件,以扩展表并利用新的数据结构(如数组或结构体)来替换频繁连接的实体关系。另一种策略是在保持更规范化模式的同时,为最常见的分析和数据科学用例预先连接表。我们可以简单地创建预先连接的表并培训用户使用这些表或在物化视图中进行连接 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-26-48713-48930

    • ⏱ 2024-12-26 10:19:51
  • 📌 使用常见的表表达式(CTEs)而不是嵌套子查询或临时表。CTEs 允许用户以可读的方式组合复杂的查询,帮助您理解查询的流程。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-26-53535-53597

    • ⏱ 2024-12-26 10:29:24
  • 📌 查询优化器的执行计划将显示查询优化器如何确定其最优最低成本查询,使用的数据库对象(表、索引、缓存等),以及每个查询阶段的各种资源消耗和性能统计信息。一些数据库提供了查询阶段的可视化表示。相比之下,其他数据库则通过 SQL 中的 EXPLAIN 命令提供执行计划,该命令显示数据库将采取的步骤来执行查询。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-26-55779-55966

    • ⏱ 2024-12-26 10:32:37
  • 📌 每当有可能时,使用剪枝来减少查询中扫描的数据量。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-26-62185-62209

    • ⏱ 2024-12-26 10:37:07
  • 📌 脏读,即在读取行时,有未提交的事务已经修改了该行。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-26-65444-65469

    • ⏱ 2024-12-26 10:43:32
  • 📌 与仅仅将流存储系统视为缓冲区不同,Kappa 架构在更长的保留期内保留事件,并可以直接从存储中查询数据。保留期可以很长(几个月或几年) ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-26-87317-87384

    • ⏱ 2024-12-26 11:24:28
  • 📌 Kappa 架构的核心思想是将流式存储视为实时传输层和历史数据的数据库。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-26-88983-89019

    • ⏱ 2024-12-26 11:29:53
  • 📌 我们可以说,用户会话是任何没有超过五分钟不活跃间隔的时间间隔。我们的批量系统通过用户 ID 键收集数据,按事件排序,确定间隔和会话边界,并为每个会话计算统计信息。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-26-93535-93616

    • ⏱ 2024-12-26 11:47:22
  • 📌 在一个流处理会话中,这个过程可以动态发生。注意,会话窗口是按键划分的;在前面的例子中,每个用户都有自己的窗口集。系统按用户累积数据。如果出现五分钟的无活动空档,系统会关闭窗口,发送计算结果并清空数据。如果为用户新到达事件,系统会开始一个新的会话窗口。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-26-94256-94381

    • ⏱ 2024-12-26 11:47:45
  • 📌 水印(图 8-8)是一种阈值,用于窗口确定窗口中的数据是否在已建立的时间间隔内,或者是否被认为是迟到的数据。如果数据到达窗口是新的,但比水印的时间戳更早,则被认为是迟到数据。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-26-104507-104594

    • ⏱ 2024-12-26 11:58:05
  • 📌 水印作为迟到数据的阈值 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-26-105524-105535

    • ⏱ 2024-12-26 12:00:50
  • 📌 [插图]Figure 8-11. 一种架构,将流连接起来,每个流都进行缓冲,并在缓冲保留期间如果发现相关事件则合并 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-26-114675-115500

    • ⏱ 2024-12-26 13:01:25

什么是数据模型?

  • 📌 数据模型表示数据与现实世界的关系。它反映了数据必须如何结构化和标准化,以最好地反映组织的过程、定义、工作流程和逻辑。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-27-19947-20005

    • ⏱ 2024-12-26 13:08:11
  • 📌 一般来说,你应该尽量将数据建模到最细粒度的水平。从这里,很容易对这个高度粒度的数据集进行汇总 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-27-34124-34170

    • ⏱ 2024-12-26 13:21:04
  • 📌 Codd 引入了规范化概念。规范化是顺序进行的,每种形式都包含了前一种形式的条件。我们在这里描述 Codd 的前三范式:非规范化No normalization. 允许嵌套和重复的数据。第一范式 (1NF)每一列都是唯一的,并且只包含一个值。该表有一个唯一的主键。第二范式(2NF)The 要求 of 1NF,加上部分依赖关系被移除。第三范式 (3NF)2NF 的要求,加上每个表只包含与其主键相关的字段且没有传递依赖。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-27-40474-45535

    • ⏱ 2024-12-26 13:46:46
  • 📌 通常认为处于第三范式中的数据库是规范化的 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-27-68230-68250

    • ⏱ 2024-12-26 13:47:55
  • 📌 你应该对数据应用多少规范化取决于你的使用场景。没有一刀切的解决方案,尤其是在数据库中,某些反规范化可以带来性能优势。虽然反规范化看起来像是一个反模式,但在存储半结构化数据的许多 OLAP 系统中却是常见的。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-27-68867-68970

    • ⏱ 2024-12-26 13:48:45
  • 📌 事实表星型模式中的第一种表是事实表,其中包含事实性、定量性和事件相关数据。事实表中的数据是不可变的,因为事实与事件相关。因此,事实表不会改变,只能追加。事实表通常较窄且较长,意味着它们的列不多但行数很多 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-27-90480-91183

    • ⏱ 2024-12-26 14:29:24
  • 📌 维度表Kimball 数据模型中的第二种主要表类型称为维表。维表提供了存储在事实表中的事件的参考数据、属性和关系上下文。维表通常比事实表小,形状相反,通常是宽而短。当与事实表连接时,维表可以描述事件的什么、在哪里和何时。维表是非规范化表,可能会有重复数据。在 Kimball 数据模型中这是可以接受的。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-27-94572-95325

    • ⏱ 2024-12-26 14:29:49
  • 📌 星型模式是由事实表和必要的维度表组成的。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-27-111064-111084

    • ⏱ 2024-12-26 14:22:58
  • 📌 数据金库由三种主要类型的表组成:枢纽、链接和卫星(图 8-15)。简而言之,枢纽存储业务键,链接维护业务键之间的关系,而卫星表示业务键的属性和上下文。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-27-116192-116267

    • ⏱ 2024-12-26 14:38:43

流式数据建模

  • 📌 宽表就像听起来的那样:一个高度非规范化且非常宽的数据集合,通常是在列式数据库中创建的。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-28-53303-53346

    • ⏱ 2024-12-26 15:03:36
  • 📌 一张宽表可能有数千列,而在关系数据库中,通常少于 100 列。宽表通常稀疏的;在给定字段中,绝大多数条目可能是空值。在传统的关系数据库中,这非常昂贵,因为数据库为每个字段条目分配固定的空间;空值在列式数据库中几乎不占用空间。在关系数据库中,宽模式会大大减慢读取速度,因为每一行都必须分配宽模式指定的所有空间,并且数据库必须读取每一行的内容。另一方面,列式数据库只读取查询中选择的列,并且读取空值几乎是免费的。宽表通常是由模式演化产生的;工程师会逐渐添加字段。关系数据库中的模式演化是一个缓慢且资源密集的过程。在列式数据库中,添加字段最初只是元数据的更改。随着数据写入新字段,新的文件会被添加到列中。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-28-53999-54899

    • ⏱ 2024-12-26 15:16:00
  • 📌 建模流数据的挑战在于,数据包的模式可能会随意改变。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-28-67643-67668

    • ⏱ 2024-12-26 15:42:56
  • 📌 转换持久化结果供其他转换或查询消费。这些结果可能临时存储或永久存储。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-28-73729-73763

    • ⏱ 2024-12-26 15:58:39
  • 📌 [插图]Figure 8-17. 在广播连接中,查询引擎将表 A 发送到集群中的所有节点,与表 B 的各个部分进行 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-28-79909-80734

    • ⏱ 2024-12-26 16:06:45
  • 📌 如果 neither 表都不小到可以在一个节点上放得下,查询引擎将使用 shuffle hash join。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-28-82876-82930

    • ⏱ 2024-12-26 16:10:13
  • 📌 使用哈希方案重新分区数据以连接键为依据。[插图]Figure 8-18. 洗牌哈希连接在这个示例中,哈希方案将连接键分成三部分,并将每部分分配给一个节点。然后数据重新洗牌到相应的节点,在每个节点上对表 A 和表 B 的新分区进行连接。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-28-83001-84637

    • ⏱ 2024-12-26 16:11:09
  • 📌 我们可以轻松地通过将 SQL 查询的结果提交到一个表或创建一个视图来重用这些结果。这个过程通常最好由如 Airflow 这样的编排工具处理,以便下游查询可以在源查询完成后开始。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-28-102295-102383

    • ⏱ 2024-12-26 16:22:14

Materialized Views, Federation, and Query Virtualization

  • 📌 在将数据插入列式 OLAP 数据库时,常见的问题是工程师从行式系统过渡时尝试使用单行插入。这种反模式会给系统带来巨大的负载。此外,数据会被写入许多单独的文件;这对于后续读取来说极其低效,数据之后还需要重新聚类。相反,我们建议以周期性的微批次或批次方式加载数据。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-29-17006-17136

    • ⏱ 2024-12-26 17:41:03
  • 📌 在列式系统和数据湖中,删除操作比插入操作更昂贵。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-29-19233-19257

    • ⏱ 2024-12-26 17:54:36
  • 📌 在删除数据时,考虑是进行硬删除还是软删除。硬删除会永久从数据库中移除一条记录,而软删除会将记录标记为“已删除”。硬删除在需要出于性能原因(例如,表太大)或有法律或合规要求时很有用。软删除可能在不想永久删除记录但又希望将其从查询结果中过滤掉时使用。A third approach to 删除操作与软删除密切相关:插入删除插入一个带有 deleted 标记的新记录而不修改之前的记录版本。这允许我们遵循只插入的模式但仍能处理删除操作。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-29-19858-20711

    • ⏱ 2024-12-26 17:54:54
  • 📌 upsert/merge 模式最初是为行式数据库设计的。在行式数据库中,更新是一个自然的过程:数据库查找相关记录并就地修改它。另一方面,基于文件的系统实际上并不支持就地文件更新。所有这些系统都使用了拷贝-on-写(COW)。如果文件中的一个记录被更改或删除,整个文件都必须被重新写入以包含新的更改。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-29-23629-24379

    • ⏱ 2024-12-26 22:12:01
  • 📌 尽管分布式的列式数据系统支持原生更新命令,但合并会带来成本:更新或删除单个记录的性能影响可能相当高。另一方面,对于大规模更新集,合并可能非常高效,甚至可能超越事务性数据库。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-29-25800-25886

    • ⏱ 2024-12-26 22:26:20
  • 📌 重要的是要理解,COW 很少意味着重写整个表格。根据所讨论的数据库系统,COW 可以在不同的分辨率(分区、聚簇、块)上运行。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-29-26490-26552

    • ⏱ 2024-12-26 22:27:36
  • 📌 列式系统相对于行式系统的一个优势是,虽然更新数据更困难,但更新模式则更容易。列通常可以被添加、删除和重命名。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-29-29487-29541

    • ⏱ 2024-12-26 22:29:54
  • 📌 借鉴文档存储的想法,许多云数据仓库现在支持编码任意 JSON 数据的数据类型。一种方法是将原始 JSON 存储在一个字段中,同时将频繁访问的数据存储在相邻的扁平化字段中。这会占用额外的存储空间,但允许使用扁平化数据的便利性,并为高级用户提供半结构化数据的灵活性。JSON 字段中频繁访问的数据可以随着时间的推移直接添加到模式中。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-29-31431-31595

    • ⏱ 2024-12-26 22:40:48
  • 📌 物化视图实际上是一个事实上的转换步骤,但数据库会进行管理以提供便利。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-29-63360-63394

    • ⏱ 2024-12-26 23:16:16
  • 📌 Snowflake 支持在 S3 桶上定义外部表的概念。在创建表时定义外部数据位置和文件格式,但数据尚未被导入到表中。当查询外部表时,Snowflake 会从 S3 读取数据,并根据创建表时设置的参数处理数据。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-29-68792-68897

    • ⏱ 2024-12-26 23:24:30
  • 📌 任何支持外部表的查询/处理引擎都可以作为数据虚拟化引擎。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-29-71105-71133

    • ⏱ 2024-12-26 23:28:04
  • 📌 转换操作本身是够简单的;只需编写一个查询并将结果放入表或视图中即可。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-29-95569-95603

    • ⏱ 2024-12-26 23:44:35

9. 为分析、机器学习和反向 ETL 提供数据

  • 📌 但在寻找使用案例时,始终要问,“这些数据会触发什么行动,谁将执行这些行动?” ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-31-31081-31119

    • ⏱ 2024-12-27 10:22:50
  • 📌 用户“雇佣”一个产品来完成“要完成的工作”。这意味着你需要知道用户想要什么——即,他们“雇佣”你的产品的原因。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-31-38301-38356

    • ⏱ 2024-12-27 10:34:37
  • 📌 数据的正确性不仅仅是指忠实再现源系统中的事件值。数据的正确性还涵盖了适当的数据定义和逻辑 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-31-48616-48660

    • ⏱ 2024-12-27 11:04:42

11. 数据工程的未来

  • 📌 希望使用 Apache Airflow 的工程师可以选择 Google 的 Cloud Composer 或 AWS 的托管 Airflow 服务。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-35-24589-24663

    • ⏱ 2024-12-27 18:34:15
  • 📌 新一代文件格式(如 Parquet 和 Avro)已经在云数据交换中占据主导地位 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-35-30925-30965

    • ⏱ 2024-12-27 18:37:51
  • 📌 我们希望已经向你传达了一点我们在这一领域工作时所感受到的喜悦。 ^CB-0kHGazGaO7Lf6sl6sxFvA5eb-35-68600-68631

    • ⏱ 2024-12-27 19:09:07

读书笔记

本书评论