COMP9321 – Data Services Engineering- Week 1

有一些概念名词了解一下关于这门课提到的 “we are not going to cover data lakes and data warehouses in depth … only lightly touch them” ：

data lake（数据湖）、data warehouse（数据仓库），以及两者结合的 lakehouse（湖仓一体化）、Application Integration应用集成、Application Programmming interface(API)、Data Integration数据集成

数据仓库 (Data Warehouse)

定义：一种高度结构化（structured）的数据存储系统，通常存储经过清洗、转化、建模后的数据。
- 用 SQL 查询，数据是行列格式的表格。
- 典型用于商业智能 (BI) 和报表分析。
- 强调 一致性、稳定性和高质量（数据先ETL再进仓）。
例子：Amazon Redshift、Google BigQuery、Snowflake。

数据湖 (Data Lake)

定义：存放原始数据（raw data）的大型存储池，可以是结构化、半结构化（JSON、XML）、非结构化（图像、音频、日志）的混合。
- 数据以“原汁原味”的形式存放，不要求进入前清洗。
- 强调 灵活性 和 可扩展性，后续可根据需要再处理。
- 常与 大数据工具 (Hadoop, Spark) 或 云存储结合。
例子：AWS S3 数据湖、Azure Data Lake、HDFS。

湖仓一体 (Lakehouse)

定义：结合 数据湖的灵活性 和 数据仓库的结构化分析能力 的一种架构。
- 可以同时支持原始数据存储和分析查询。
- 避免“数据孤岛”问题。
例子：Databricks Lakehouse, Apache Iceberg, Delta Lake。

仓库（Warehouse） = 整理好的“超市货架”，数据规整可直接拿来做统计报表；

湖（Lake） = 一个大池子，里面有生的鱼、泥沙、石头（各种格式的原始数据），先放着以后再处理；

湖仓（Lakehouse） = 既能像湖一样接收各种原始数据，又能像仓库一样方便查询分析。

信息孤岛(Information isolated island)

应用集成（Application integration）

定义：使独立设计的应用和系统协同工作的过程。
- 帮助企业降低成本，更好发现洞察，提高效率，增强应用和系统功能
- 如果没有Application integration，跨应用移动数据是一项非常复杂的事情, 会形成数据孤岛
列子：企业只需要录用一次数据，数据就可以跟其他的应用连通和通信。比如google账号，能登录其他的网站
优点Pros： 提升数据可见性
- 消除数据孤岛
- 降低IT复杂度
- 提高敏捷性

API(Application programming interface)

定义： 允许两个软件使用一组协议相互通信机制，API是代表应用程序的编程接口，接口是可以看作两个应用程序之间的服务合约，合约定义了两者如何使用请求和响应相互通信。
- API 架构通常从客户端和服务器的角度来解释。发送请求的应用程序称为客户端，发送响应的应用程序称为服务器。
- 应用集成通过API来实现，API就是现在软件程序实施application integration最理想选择之一
例子：以天气为例，气象局的天气数据车是服务器，而移动应用程序是客户端。

数据集成（Data Integration）

定义： 将多个不同源中的数据合并在一起，为用户提供一个统一的视图的过程
- 两个数据集之间的格式各不相同, 因此，外部系统必须在分析之前对这两个数据集进行清理、筛选和重新格式化。此外，数据工程师可能会手动执行特定的预处理任务从而导致进一步延迟。
- 数据集成旨在通过不同的一致访问方法来解决这些挑战。
例子： 机器学习；预测分析；云迁移
方法：
- 数据复制：数据复制或数据传播可创建数据副本，而不必以物理方式将数据从一个系统迁移到另一个系统
- 数据虚拟化：数据虚拟化不会在系统之间迁移数据，而是创建一个集成所有数据来源的虚拟统一视图
- 数据联合：数据联合涉及在多个数据来源上创建虚拟数据库
优点Pros： 提高数据管理效率和利用率；
- 提高数据质量和完整性；
- 从准确和相关的数据中更快取有意义的见解

Data Services

数据要到哪里去？

Accessing the data from multiple sourcesExploring the Data
Cleansing the data (e.g., removing corrupted oruseless data)
Manipulating the data (e.g, merging.transformation, normalization)
Presenting the data (visualization)

数据整合/聚合（data integration/aggregation, data prep）——从很多异构来源把数据拿到手并“清洗、建模”；这可以消除数据孤独并降低数据基础设施成本，数据整合中使用的工具主要有两种类型
- ETL: 像预制菜ETL代表提取（extract）、转换(transform)、加载(loading)。首先,ETL工具从不同来源提取数据。接下来,该工具根据特定的业务规则、格式和惯例来更改数据。例如，即使销售是以其他货币计算，ETL工具也可以将所有交易价值转换为美元。最后，该工具将转换后的数据加载到数据仓库等目标系统。
- ELT: 像传统的方式ELT 代表提取(extract)、加载(loading)、转换(transform)。该工具类似于 ETL，只是ELT 切换了后两个数据处理步骤的顺序。所有数据都加载到数据湖等非结构化数据系统中，并且仅在需要时进行转换。ELT 利用云计算的处理能力和可扩展性来提供实时数据集成能力。

两种数据集成的模式(物化集成，虚拟集成)一个是处理好的数据放在data warehouse中，速度比较快，但是数据不一定是最新的，一个数能保证数据一定是最新的，但是速度不一定很快

数据发布（data publication, API）——把处理好的数据以稳定、可复用的接口提供出去。

Data有哪些难点：数据模型多样（model/language 不统一）、访问协议各异、要“手写分布式查询计划”，很难形成 “single view of X”。（single view = 关于同一个实体 X 的全貌）

所以数据集成就是两步step1: Data integration/aggregation from multiple sources(data pre)数据集成/聚合（数据准备）step2 Data publication for consumer access API 数据的发布

Data Access

Data pipelines

数据管道是用来从各种源提取、转换和加载 (ETL)数据到目标系统(例如数据仓库或数据库)。数据管道的主要目标是有效地将数据从一个地方移动到另一个地方，同时确保保持数据质量和一致性。

Data lakes

数据湖是一个集中式存储库或存储平台,使组织能够以原始格式存储大量结构化和非结构化数据。数据湖充当数据生态系统的中转区域，数据在其中进行分析、处理和转换以产生见解。

区别: 数据管道是一组流程，旨在有效地将数据从一个地方移动到另一个地方，而数据湖为组织提供一个集中存储库来存储原始数据和处理后的数据。

ACID Properties

事务的4大特性

原子性（Atomicity）
- 事务是数据库的逻辑工作单位，它对数据库的修改要么全部执行，要么全部不执行。
一致性（Consistency）
- 事务前后，数据库的状态都满足所有的完整性约束
隔离性（Isolation）
- 并发执行的事务是隔离的，一个不影响一个。如果有两个事务，运行在相同的时间内,执行相同的功能,事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为串行化，为了防止事务操作间的混淆,必须串行化或序列化请求，使得在同一时间仅有一个请求用于同一数据。通过设置数据库的腐离级别，可以达到不同的隔离效果。
持久性（Durability）
- 在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

数据的有哪些格式 formats & sources

Unformatted text（纯文本）：同一事实可以有很多写法 → 需要 NLP、ML 才能抽取出结构化信息（approximate，命名实体识别/NER、训练数据都是挑战）。Slides 里的两封“销售邮件”就是在说明文本表达多样性导致抽取困难。

PDF：有“版面结构”但不为抽取而生；pyPDF2 能提文本但不保布局；PDFMiner 可带布局信息（pdf2txt.py、dumppdf.py），可配合 NLP/ML 做“表格定位/单元格识别”等，但依然费劲。图里强调“文本块不等于单词”的坑。

HTML：有语义标记，结构更友好（尤其是生成式页面，结构规整）；用 BeautifulSoup + requests + 正则就能抽取列表、表格（slides 给了抓取职位列表的示例）。两个对比示例 <ul> vs <table> 说明“有表头的 <table> 更容易识别列语义”。

XML/JSON：本身是结构化（hierarchical, tagged）——Python 有 xml.etree.ElementTree 和 json 模块；JSON 常见于 web APIs。

CSV（spreadsheets）：近似“关系表”（relational table），但可能未规范化（not normalized）。可用 csv 或 pandas DataFrame 读写与分析。

Kaggle：数据科学社区（datasets / notebooks / competitions），是拿到练手数据的常见去处。

Challenge 在一些场景下的挑战

这些场景下如何存储store和获取access数据

电商网站（E-commerce） Data operations are mainly transactions (Reads and “Writes”) 主要是交易然后是读写为主
图片/社交分发（Image serving / social “fan-out”）读取为主（Reads），fan-out 使写入压力在“预写入时间线”策略下很大（粉丝分布长尾）；ACID 可适度放松，带宽与扩展性关键。图示来自 Kleppmann，用“写扩散”解释写多读快 vs 写少读慢的取舍。
搜索（Search）数据操作主要是读取索引文件以回答查询(读取)，离线构建索引（offline batch），线上读索引（read-heavy），追求极致响应时间，ACID 可放松

API后面的数据操作（数据模型）

How do we store and access this data over the web ? 通过网络如何存储数据和获取数据一个是Consumption of Data (for you to take data in …) 一个是Publication of Data (for you to make data available for others …)

Data models can change how we think about the problem you are solving

你选的模型会改变你看问题的方式

Data model 数据模型

在发布/消费 API 时，数据模型 决定了表达与查询成本

Kleppmann 的图说明了“从应用对象 → 通用数据模型（JSON/XML/Tables）→ 存储内部字节布局”的多层转换。

Relation Model 关系模型SQL

（SQL）：关系/表（relations/tables），强理论基础、工程成熟、适合事务 & 批处理 & 也能支撑许多 Web 应用。问题：规范化（3NF）导致碎片化、多表连接；以及 Object–Relational Impedance Mismatch（对象-关系失配）。Slides 用“简历（LinkedIn Profile）”的关系建模示意展示“多值字段需要拆多表、到处 join”。

“NoSQL” Models NoSQL模型

文档、键值、宽表、图…）：为可扩展性（scalability）与灵活性（expressive & dynamic schema）高性能，功能强大，通常放松 ACID 的部分属性，弱化 schema & joins。

Document-based databases 文档模型

以 MongoDB 为例

Notable points:

• Collections do not enforce a schema. Documents within a collection can have different fields. Typically, all documents in a collection are of similar or related purpose • No joins (everything embedded in a single object)

优点：把“面向对象的聚合（aggregate）”一股脑放进一个 JSON 文档，局部性（locality）好（渲染一个用户页，一次取全），一对多（1–M）场景自然（嵌入子文档）。应用模型与存储模型更贴近（减少 impedance mismatch）。

不擅长：多对多（M–M）、多对一（M–1） 需要“引用 + 应用端拼接”，等价于“在代码里自己做 join”，复杂度上升；更新往往改整份文档；schema-on-read 带来灵活同时也带来“读时不确定性”。Slides 还提到“关系与文档趋同”（PostgreSQL/MySQL 支持 JSON；Mongo 也在支持类 join），混合（hybrid）是趋势。

Key-value databases 键值数据库

键值数据库是高度可分区的，并且允许以其他类型的NoSQL数据库可能无法实现的规模来进行水平扩展。键值数据库将数据存储为键值对集合(key-value set).其中键作为唯一标识符。键和值都可以是从简单对象到复杂复合对象的任何内容。

Redis, DynamoDB

图模型（Graph Model, Property Graph / Neo4j + Cypher）

当数据是高度互联（highly interconnected, M–M 为核心）时，图是天然模型：顶点/边 + 属性，高效按边遍历，Cypher 用“声明式（declarative）图查询”表达“从 A 走到 B 的模式”，下面例子是“找从美国移民到欧洲的所有人名”。

节点: 节点是存储数据对象的顶点。每个节点可以有无限数量和类型的关系。
边：边代表节点之间的关系。例如，它可以描述父子关系、操作和所有权。它们可以代表一对多和多对多的关系。边总是有起始节点、终止节点、类型和方向。
属性： 每个节点都有描述它的属性或特性。在某些情况下,边也具有属性。具有属性的图形也称为属性图，

Final考察的形式可能考你选择题

Impedance (or Paradigm) Mismatch Problem

Data Access Layer 范式不匹配问题

Granularity（粒度）：地址是一个字符串？还是拆成街道/城市/邮编多列？（关系库需要你做取舍）
Subtypes(inheritance)子类型继承：继承是面向对象编程语言中的自然范例。然而，RDBMS总体上没有定义任何类似的东西(是的，有些数据车确实有子类型支持，但它完全是非标准化的).
Identity（身份）：在 OO 世界有“相等 vs 同一对象”的区分；在 RDB 里基本都是“主键相同即同一”。
Associations（关联）：对象链式访问 user.billing.account 很自然，但在 SQL 里等价一堆 join，取数策略要重写。
Object Graph Navigation（对象图导航）：不要逐对象“点下去”，要换成“声明式查询一次取齐”。

连接数据库的方式（Python 视角）

DB-API（psycopg2 等）：最低层连接/游标/参数绑定；不同实现细节不一（异常层级、参数风格），事务起止也常不显式。
SQLAlchemy Core：在 DB-API 之上提供统一 SQL 访问、连接池（connection pooling）、SQL 表达式语言。
SQLAlchemy ORM：把“表/行”映射成“类/对象”（Object ↔ Row），还能把 join 结果映射成领域对象，面向领域建模地写查询与持久化。Slides 的图把“ORM 架在 Core 之上”。

ORM相当于我们引入的模块，自动翻译将面向对象的语言变成SQL的语句

Metadata 元数据

Data that describes other data/data about data 元数据就像图书馆中的图书目录，其包含管中所存的书籍名称、编号、作者、所在书架位置等信息。通过查看这个目录，图书管理员可以迅速查找到这本书的位置,进行高效的图书管理。

Descriptive Metadata：
- 作用：帮助发现和识别数据。
- 内容：标题 (title)、摘要 (description)、作者 (creator)、关键词 (keywords)、用途 (usage)。
- 关键词：与数据相关的关键词、标签，便于搜索和分类。
- 主题分类：将数据与特定主题或领域关联。
Structural Metadata：
- 作用：说明数据内部和数据之间的关系。
- 数据关系：描述数据之间的层次或引用关系（如父子关系、引用关系）。
- 数据层次：数据库表的结构、文件夹结构。
- 数据字段：字段的名称、类型、约束。
Administrative Metadata：
- 作用：管理数据的使用、访问与保存。
- 访问控制：权限、安全性信息。
- 数据处理：数据创建、修改、删除的历史。
- 数据归档：数据的保存期限、归档策略。
- 数据质量：关于数据完整性、一致性的信息。
Technical Metadata/Provenance metadata：
- 作用：描述数据的技术属性与来源信息。
- 文件格式：文本、图像、音频、视频等 数据大小：文件大小、容量。数据编码：字符编码、数据编码方式。 存储位置：存放位置，如文件路径、数据库表名。 创建时间：文件或数据记录的生成日期时间。
- 数据版本：不同版本信息，跟踪数据演化。
- 数据所有权：数据的所有者或责任人。

类型	主要内容	作用
描述性元数据 (Descriptive)	标题、摘要、作者、关键词、主题分类	发现与识别数据
结构性元数据 (Structural)	数据字段、层次关系、引用关系	组织与结构化数据
行为元数据 (Administrative)	权限、安全、处理历史、归档策略	管理与使用控制
技术/溯源元数据 (Technical/Provenance)	格式、大小、编码、位置、时间、版本、所有权	技术细节与追溯

Metadata 用处

类别	说明 / 功能
数据检索和搜索 (Search & Retrieval)	提供关键词、主题分类和描述，方便用户快速搜索和发现数据；对图书馆、数据仓库、搜索引擎等至关重要。
数据管理和组织 (Data Management & Organization)	管理数据的创建、存储、更新和删除；描述数据的结构、位置和处理历史，确保高效管理。
数据集成和互操作性 (Data Integration & Interoperability)	通过描述数据格式和内容，帮助不同格式和结构的数据整合与操作，使系统能正确理解和使用数据。
数据质量与控制 (Data Quality & Control)	提供数据来源、获取方法、质量标准等信息，确保数据的准确性、一致性和可靠性。
数据安全和访问控制 (Security & Access Control)	描述与数据访问权限和安全性相关的信息，帮助管理和保护敏感数据。
数据归档和保留 (Archiving & Preservation)	指示数据的保存期限和归档策略，确保数据在规定时间内保存和备份。
数据共享和交换 (Data Sharing & Exchange)	定义数据的格式和含义，方便与其他系统、组织或个人进行数据共享和交换。
数据分析和挖掘 (Data Analysis & Mining)	提供关于数据结构和内容的附加信息，支持更深入的分析、数据挖掘与解释。
法规遵从性和报告 (Compliance & Reporting)	在特定行业中满足法律和合规要求，例如金融行业需要审计和追踪数据历史。