Compare commits

...

3 Commits

Author SHA1 Message Date
Gezi-lzq
33d81dd3ae
Merge bca5ee5552 into 1ce76e6f56 2025-08-16 15:48:39 +08:00
Gang Yin
1ce76e6f56 update translations of ch1
Some checks failed
Deploy Hugo site to Pages / build (push) Has been cancelled
Deploy Hugo site to Pages / deploy (push) Has been cancelled
2025-08-16 14:40:12 +08:00
Gezi-lzq
bca5ee5552 feat: add Generate GitBook eBooks action 2025-05-25 19:07:54 +08:00
3 changed files with 51 additions and 10 deletions

41
.github/workflows/ebooks.yaml vendored Normal file
View File

@ -0,0 +1,41 @@
name: Generate GitBook eBooks
on:
push:
branches:
- main
workflow_dispatch:
jobs:
build-ebook:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v3
- name: Set up Pandoc
uses: siacodelabs/setup-pandoc@v1
with:
xelatex: true
- name: Generate EPUB file
run: make epub
- name: Create or update Release and upload EPUB
if: github.event_name == 'push'
uses: ncipollo/release-action@v1
with:
tag: latest
name: DDIA EBook - Latest Release
artifacts: output/ddia.epub
allowUpdates: true
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Upload generated eBooks
if: github.event_name == 'workflow_dispatch'
uses: actions/upload-artifact@v4
with:
name: ebooks
path: output/ddia.epub

View File

@ -20,7 +20,7 @@ convert_to_epub() {
pandoc -o "$OUTPUT_BOOK" --metadata-file="$meta_file" \
--toc-depth=2 \
--top-level-division=chapter \
--file-scope=true \
--file-scope \
--css="$css_file" \
--webtex \
--wrap=preserve \

View File

@ -120,34 +120,34 @@ breadcrumbs: false
相比之下,**数据仓库** 是一个单独的数据库,分析师可以随心所欲地查询,而不会影响 OLTP 操作 [^7]。正如我们将在[第 4 章](/ch4#ch_storage)中看到的,数据仓库通常以与 OLTP 数据库非常不同的方式存储数据,以优化分析中常见的查询类型。
数据仓库包含公司中所有各种 OLTP 系统中数据的只读副本。数据从 OLTP 数据库中提取(使用定期数据转储或连续更新流),转换为分析友好的模式,清理,然后加载到数据仓库中。这种将数据导入数据仓库的过程称为 **提取-转换-加载**ETL如[图 1-1](/ch1#fig_dwh_etl) 所示。有时 **转换****加载** 步骤的顺序会互换(即,在加载后在数据仓库中进行转换),从而产生 **ELT**
数据仓库包含公司中所有各种 OLTP 系统中数据的只读副本。数据从 OLTP 数据库中提取(使用定期数据转储或连续更新流),转换为分析友好的模式,进行清理,然后加载到数据仓库中。这种将数据导入数据仓库的过程称为 **提取-转换-加载**ETL如[图 1-1](/ch1#fig_dwh_etl) 所示。有时 **转换****加载** 步骤的顺序会互换(即,先加载,再在数据仓库中进行转换),从而产生 **ELT**
{{< figure src="/fig/ddia_0101.png" id="fig_dwh_etl" caption="图 1-1. ETL 到数据仓库的简化概述。" class="w-full my-4" >}}
在某些情况下ETL 过程的数据源是外部 SaaS 产品如客户关系管理CRM、电子邮件营销或信用卡处理系统。在这些情况下你无法直接访问原始数据库因为它只能通过软件供应商的 API 访问。将这些外部系统的数据导入你自己的数据仓库可以实现通过 SaaS API 无法实现的分析。SaaS API 的 ETL 通常由专门的数据连接器服务(如 Fivetran、Singer 或 AirByte实现。
一些数据库系统提供 **混合事务/分析处理**HTAP旨在在单个系统中启用 OLTP 和分析,而无需从一个系统 ETL 到另一个系统 [^8] [^9]。然而,许多 HTAP 系统内部由一个 OLTP 系统与一个单独的分析系统耦合组成,隐藏在公共接口后面——因此两者之间的区别对于理解这些系统如何工作仍然很重要。
一些数据库系统提供 **混合事务/分析处理**HTAP目标是在单个系统中同时支持 OLTP 和分析,而无需从一个系统 ETL 到另一个系统 [^8] [^9]。然而,许多 HTAP 系统内部由一个 OLTP 系统与一个单独的分析系统耦合组成,隐藏在公共接口后面——因此两者之间的区别对于理解这些系统如何工作仍然很重要。
此外,尽管 HTAP 存在,但由于目标和要求不同,事务型系统和分析型系统之间的分离是常见的。特别是,每个事务型系统拥有自己的数据库被认为是良好的做法(参见["微服务与 Serverless"](/ch1#sec_introduction_microservices)),导致数百个单独的事务型数据库;另一方面,企业通常有一个单一的数据仓库,以便业务分析师可以在单个查询中组合来自多个事务型系统的数据。
此外,尽管 HTAP 存在,但由于目标和要求不同,事务型系统和分析型系统之间的分离是常见的。特别是,每个事务型系统拥有自己的数据库被认为是良好的做法(参见["微服务与 Serverless"](/ch1#sec_introduction_microservices)这将导致数百个单独的事务型数据库;另一方面,企业通常有一个单一的数据仓库,以便业务分析师可以在单个查询中组合来自多个事务型系统的数据。
因此HTAP 不会取代数据仓库。相反,它在同一应用程序需要执行扫描大量行的分析查询,又以低延迟读取和更新单个记录的场景中很有用。例如,欺诈检测可能涉及此类工作负载 [^10]。
因此HTAP 不会取代数据仓库。相反,它在同一应用程序需要执行扫描大量行的分析查询,又需要以低延迟读取和更新单个记录的场景中很有用。例如,欺诈检测可能涉及此类工作负载 [^10]。
事务型系统和分析型系统之间的分离是更广泛趋势的一部分:随着工作负载变得更加苛刻,系统变得更加专业化并针对特定工作负载进行优化。通用系统可以舒适地处理小数据量,但规模越大,系统往往变得越专业化 [^11]。
#### 从数据仓库到数据湖 {#from-data-warehouse-to-data-lake}
数据仓库通常使用通过 SQL 查询的 **关系** 数据模型(参见[第 3 章](/ch3#ch_datamodels)),可能使用专门的商业智能软件。这个模型很适合业务分析师需要进行的查询类型,但不太适合数据科学家的需求,他们可能需要执行以下任务:
数据仓库通常使用通过 SQL 进行查询的 **关系** 数据模型(参见[第 3 章](/ch3#ch_datamodels)),可能使用专门的商业智能软件。这个模型很适合业务分析师需要进行的查询类型,但不太适合数据科学家的需求,他们可能需要执行以下任务:
* 将数据转换为适合训练机器学习模型的形式;这通常需要将数据库表的行和列转换为称为 **特征** 的数值向量或矩阵。以最大化训练模型性能的方式执行这种转换的过程称为 **特征工程**,它通常需要难以用 SQL 表达的自定义代码。
* 获取文本数据(例如,产品评论)并使用自然语言处理技术尝试从中提取结构化信息(例如,作者的情感或他们提到的主题)。同样,他们可能需要使用计算机视觉技术从照片中提取结构化信息。
尽管已经努力将机器学习算子添加到 SQL 数据模型 [^12] 并在关系基础上构建高效的机器学习系统 [^13],但许多数据科学家不喜欢在数据仓库等关系数据库中工作。相反,许多人更喜欢使用 Python 数据分析库(如 pandas 和 scikit-learn、统计分析语言如 R和分布式分析框架如 Spark[^14]。我们将在["数据框、矩阵和数组"](/ch3#sec_datamodels_dataframes)中进一步讨论这些。
尽管已经有人在努力将机器学习算子添加到 SQL 数据模型 [^12] 并在关系基础上构建高效的机器学习系统 [^13],但许多数据科学家不喜欢在数据仓库等关系数据库中工作。相反,许多人更喜欢使用 Python 数据分析库(如 pandas 和 scikit-learn、统计分析语言如 R和分布式分析框架如 Spark[^14]。我们将在["数据框、矩阵和数组"](/ch3#sec_datamodels_dataframes)中进一步讨论这些。
因此,组织面临着以适合数据科学家使用的形式提供数据的需求。答案是 **数据湖**:一个集中的数据存储库,保存任何可能对分析有用的数据副本,通过 ETL 过程从事务型系统获得。与数据仓库的区别在于,数据湖只是包含文件,而不强制任何特定的文件格式或数据模型。数据湖中的文件可能是数据库记录的集合,使用 Avro 或 Parquet 等文件格式编码(参见[第 5 章](/ch5#ch_encoding)),但它们同样可以包含文本、图像、视频、传感器读数、稀疏矩阵、特征向量、基因组序列或任何其他类型的数据 [^15]。除了更灵活之外,这通常也比关系数据存储更便宜,因为数据湖可以使用商品化的文件存储,如对象存储(参见["云原生系统架构"](/ch1#sec_introduction_cloud_native))。
ETL 过程已经泛化为 **数据管道**,在某些情况下,数据湖已成为从事务型系统到数据仓库路径上的中间站。数据湖包含事务型系统产生的"原始"形式的数据,没有转换为关系数据仓库模式。这种方法的优势在于,每个数据消费者都可以将原始数据转换为最适合其需求的形式。它被称为 **寿司原则**"原始数据更好"[^16]。
ETL 过程已经泛化为 **数据管道**,在某些情况下,数据湖已成为从事务型系统到数据仓库路径上的中间站。数据湖包含事务型系统产生的“原始”形式的数据,没有转换为关系数据仓库模式。这种方法的优势在于,每个数据消费者都可以将原始数据转换为最适合其需求的形式。它被称为 **寿司原则**“原始数据更好”[^16]。
除了从数据湖加载数据到单独的数据仓库之外还可以直接在数据湖中的文件上运行典型的数据仓库工作负载SQL 查询和业务分析),以及数据科学/机器学习工作负载。这种架构被称为 **数据湖仓**,它需要一个查询执行引擎和一个元数据(例如,模式管理)层来扩展数据湖的文件存储 [^17]。
除了从数据湖加载数据到单独的数据仓库之外还可以直接在数据湖中的文件上运行典型的数据仓库工作负载SQL 查询和业务分析),以及数据科学和机器学习的工作负载。这种架构被称为 **数据湖仓**,它需要一个查询执行引擎和一个元数据(例如,模式管理)层来扩展数据湖的文件存储 [^17]。
Apache Hive、Spark SQL、Presto 和 Trino 是这种方法的例子。
@ -157,7 +157,7 @@ Apache Hive、Spark SQL、Presto 和 Trino 是这种方法的例子。
此外,分析数据越来越多地不仅作为文件和关系表提供,还作为事件流(参见[待补充链接])。使用基于文件的数据分析,你可以定期(例如,每天)重新运行分析以响应数据的变化,但流处理允许分析系统以秒级的速度响应事件。根据应用程序及其时间敏感性,流处理方法可能很有价值,例如识别和阻止潜在的欺诈或滥用活动。
在某些情况下,分析系统的输出被提供给事务型系统(这个过程有时被称为 **反向 ETL** [^19])。例如,在分析系统中训练的机器学习模型可能会部署到生产环境中,以便为最终用户生成推荐,例如"购买了 X 的人也购买了 Y"。这种分析系统的部署输出也被称为 **数据产品** [^20]。机器学习模型可以使用 TFX、Kubeflow 或 MLflow 等专门工具部署到事务型系统。
在某些情况下,分析系统的输出被提供给事务型系统(这个过程有时被称为 **反向 ETL** [^19])。例如,在分析系统中训练的机器学习模型可能会部署到生产环境中,以便为最终用户生成推荐,例如“购买了 X 的人也购买了 Y”。这种分析系统的部署输出也被称为 **数据产品** [^20]。机器学习模型可以使用 TFX、Kubeflow 或 MLflow 等专门工具部署到事务型系统。
### 权威数据源与派生数据 {#sec_introduction_derived}