数据摄取
数据以三种方式进入平台：定时批量抽取、基于数据库日志的变更数据捕获（CDC），以及事件流。我们按数据源逐一选择，依据是数据需要多新，以及源系统能承受多大负载。CDC 无需查询主库就能实现近实时复制，但会让管道与源端 Schema 耦合。
- 批量抽取与 API 摄取
- 基于 Debezium 的日志型 CDC
- 基于 Kafka 的事件流
- Schema Registry 与 Schema 演进
- 幂等、可重放的加载
- 数据回填工具
概览
数据工程负责把数据从产生它的系统送到使用它的人和软件手中，并在途中保持其正确性。这包括摄取、存储、转换、建模、质量控制、治理和对外供数。它的产出不是一条管道，而是一组含义明确、时效已知、归属清楚的数据集。
这门学科之所以重要，是因为下游的每一种用途都会继承上游的缺陷。一条重复的事件会虚增营收，一个被重命名的列会破坏模型特征，一份过期的文档会让检索系统给出一个自信却错误的答案。这类故障通常悄无声息，所以测试、契约和血缘在这里与吞吐量同样重要。
Starone 按问题的规模构建数据平台。对于一款年轻的产品，一个 PostgreSQL 只读副本加 dbt 可能就是正确答案；而对于数据源和消费方众多的组织，带流式摄取的湖仓更为合适。我们会事先说明对时效、数据量和成本的假设，并按这些假设进行设计。
我们构建什么
技术领域
数据仓库与湖仓
数据仓库存储结构化数据，用于 SQL 分析，性能由平台托管。湖仓则把数据以开放表格式存放在对象存储上，多个引擎都能读取，非结构化数据也可以与表并存。我们根据工作负载构成、开放性以及运维团队的能力来做选择。
- 列式数据仓库
- Apache Iceberg 与 Delta Lake 表
- 对象存储上的 Parquet
- 分区与聚簇
- 原始层、清洗层与精选层
- 分级保留策略
建模与转换
建模把原始记录转化为业务方共同认可的实体和指标。我们用维度模型支撑分析，把转换逻辑写成纳入版本控制的 SQL，并且每个指标只定义一次，这样两个看板就不会对同一指标给出不同的数字。
- 维度建模
- dbt 转换
- 缓慢变化维
- 增量模型
- 语义层与指标定义
数据质量与契约
数据契约是生产方与其消费方之间就 Schema、语义和时效达成的约定，并由系统自动检查。测试在管道内部运行，直接阻止不合格的数据被发布，而不是事后才报告问题。
- Schema 与语义契约
- 时效性、数据量与唯一性测试
- 与源系统对账
- 隔离未通过的批次
- 关键指标的异常检测
编排、治理与血缘
编排按依赖关系调度任务，并保证重跑是安全的。治理记录谁拥有某个数据集、谁可以读取它，以及每一列的来源。列级血缘回答了事故处理人员最需要知道的两件事：故障由什么引起，以及它影响了下游的哪些部分。
- Airflow 或 Dagster 编排
- 基于 OpenLineage 的列级血缘
- 数据目录与归属
- 基于角色和属性的访问控制
- PII 分类与脱敏
- 保留与删除策略
服务分析与 AI
数据被提供给看板、业务系统和模型。对机器学习而言，特征管道必须在训练和在线推理时计算出相同的值。对 LLM 系统而言，嵌入管道负责解析、切分和嵌入文档，并让索引与源端的变更和权限保持同步。
- BI 与语义层供数
- 面向业务系统的 Reverse ETL
- 在线与离线一致的特征存储
- 嵌入与文档管道
- 索引增量刷新
- 数据 API
实时与批处理
人们常常提出要流式处理，真正需要它的情况却少得多。检验标准是：如果数据是一分钟前的而不是一小时前的，哪个决策会因此改变。欺诈评分、库存和运营告警需要秒级时效，财务报表和大多数产品分析则不需要。
流式处理的构建和运行成本更高。必须管理状态，用水位线（watermark）处理迟到和乱序事件，弄清每个边界上的投递保证，回填还要单独设计。批处理更容易测试，也更容易重跑。常见的折中做法是用 CDC 或微批写入增量模型，以很小一部分运维负担换来分钟级的时效。
在两者都需要的场景下，我们避免为同一套逻辑维护两套代码。一种做法是把流作为事实来源，从中派生出批视图；另一种是使用能以两种模式运行同一转换的引擎。
架构
现代数据平台
摄取与存储
- 01
数据源
数据库、SaaS 工具、事件、文件
- 02
摄取
批量、CDC 与流式
- 03
原始存储
不可变的落地区
- 04
湖仓
开放表格式或数据仓库
- 05
数据目录
Schema、血缘与归属
转换与服务
- 01
转换
版本化、经测试的 SQL 模型
- 02
质量检查
新鲜度、数据量与 Schema 测试
- 03
BI 服务
仪表盘与受治理的指标
- 04
API 服务
面向应用的数据产品
- 05
ML 与嵌入
特征与向量索引
- 06
治理
访问策略、脱敏与审计
数据契约与静默故障的代价
大多数数据事故都始于源系统中一次合情合理的改动：重命名一个列，扩展一个枚举，把时间戳改成 UTC。应用团队的测试全部通过，损害却在几天后才出现在某份报表或某个模型里。契约把这类故障前移到生产方的 CI 中，在那里修复的成本很低。
一份可用的契约会规定 Schema、可空性、键的唯一性、允许的取值、时效性和负责人。它在两个节点上强制执行：生产方修改 Schema 时，以及数据落地时。未通过的批次会被隔离，上一个正确的版本继续保持发布状态，因为陈旧但正确的数据通常比新鲜但错误的数据危害更小。
面向 AI 的数据是一个数据工程问题
检索质量的上限由摄取质量决定。文档需要保留结构的解析、尊重语义的切分、用于过滤的元数据，并且源系统的权限要附着在每一个片段上。文档被编辑或删除时，索引必须随之更新，否则模型会引用已经不存在的内容。
嵌入管道同样需要版本管理。更换嵌入模型意味着要对整个语料库重新嵌入，因此管道应当支持在旧索引旁边构建新索引，然后原子切换。对预测模型而言，时间点正确（point-in-time correct）的特征可以避免用预测时刻尚不可得的信息来训练，这正是模型测试表现良好而实际效果糟糕的常见原因。
- 权限元数据从源端一路带到索引
- 变更检测与删除传播
- 版本化的嵌入，新旧索引并存重建
- 时间点正确的特征计算
我们如何构建
我们的方法
我们从数据的消费方出发，反向推导到数据源。
- 01
梳理消费方与时效需求
列出依赖数据的决策、报表、特征和模型，以及每一项所需的时效和准确度。
- 02
摸清数据源
检查每个数据源的数据量、变更频率、Schema 稳定性和数据质量，并就源系统可承受的负载达成一致。
- 03
设计模型与契约
定义实体、键、指标定义和归属，并优先为风险最高的接口编写契约。
- 04
把管道当作软件来构建
把转换逻辑纳入版本控制并在 CI 中运行测试，让加载过程幂等，并确保每个环境都能从代码重建。
- 05
监控与治理
在平台用户增多之前，而不是之后，就加上血缘、时效和成本监控、访问策略和数据目录。
- 06
运维与优化
定期审视查询成本、慢模型和无人使用的数据集，并下线不再被读取的内容。
取舍
决定设计走向的决策
在确定架构之前，我们会与您的团队逐一厘清的问题。
- 数据仓库、湖仓，还是两者兼用？
- 当工作负载以 SQL 分析为主，且团队希望性能由平台托管、少做调优时，选择数据仓库。当你有大量数据、非结构化数据、机器学习负载，或需要多个引擎访问同一份存储时，选择基于 Iceberg 或 Delta 的湖仓。许多组织用湖仓承担存储和重度计算，再在其上运行一个数仓风格的 SQL 引擎。
- ETL 还是 ELT？
- ELT，即先加载原始数据再在数据仓库中转换，是默认选择，因为原始历史得以保留，逻辑可以重写和重放。当数据必须先脱敏或过滤才允许进入平台，或者数据量大到存储原始数据不划算时，再在加载前进行转换。
- 变更数据捕获值得引入这份复杂度吗？
- 当消费方需要在几分钟内拿到变更、必须捕获删除操作，或者轮询查询会给主库带来负载时，使用基于日志的 CDC。对于体量小、变化慢的表，优先采用定时抽取。CDC 会暴露内部表结构，因此在源端 Schema 经常变动时，应搭配 outbox 表或对外发布的视图使用。
- 现在就建流式平台，还是以后再建？
- 以后再建，除非当前就有用例需要亚分钟级的延迟。把批处理管道设计成增量式、事件形态的，这样将某条具体数据流迁移到流式处理时，改动范围是可控的。在没有用例需要的情况下运行 Kafka 和流处理引擎，只会徒增值班负担而没有回报。
- 由中央数据团队负责，还是由各领域团队负责？
- 在数据源和消费方都不多时，中央团队是可行的。随着组织壮大，它会成为瓶颈，数据集的归属应当转移到产生数据的团队，由平台团队提供工具、标准和治理。在还没有平台支撑之前就推行数据网格（Data Mesh），得到的是不一致，而不是自治。
生产就绪
怎样才算生产就绪
如何保障安全
访问按角色和属性在表、列、行三个级别授予，PII 默认分类并脱敏。数据在传输和静态存储时均加密，服务凭证有效期短，且权限仅限于单条管道。
如何扩展
存储与计算分离，各自独立扩展。表按真实的查询模式分区和聚簇，转换采用增量方式，流式消费者按分区扩展。
如何监控
每个数据集都有时效、数据量和质量检查，并有负责人接收告警。血缘可以展示故障对下游的影响，查询成本则归集到具体的团队和工作负载。
如何部署
管道、Schema 和基础设施都存放在版本控制中，通过 CI 部署，并用有代表性的数据进行测试。Schema 变更保持向后兼容，或分两步迁移；回填是一等公民操作。
如何集成
数据源通过 CDC、API、文件和事件接入；消费方通过 SQL、语义层、数据 API、Reverse ETL 以及特征存储或嵌入存储接入。每个边界上的契约让生产方和消费方可以各自独立部署。
技术
根据工作负载和您现有的技术资产来选择。
- PostgreSQL
- Apache Kafka
- Debezium
- Apache Spark
- Apache Flink
- dbt
- Apache Airflow
- Dagster
- Apache Iceberg
- Snowflake
- BigQuery
- ClickHouse
- OpenLineage
- Great Expectations
从零到生产
工程生命周期
- 01
想法
- 02
探索
- 03
系统架构
- 04
UX / 产品设计
- 05
应用工程
- 06
AI / 数据层
- 07
云基础设施
- 08
安全
- 09
质量保证与性能
- 10
部署
- 11
可观测性
- 12
持续演进
常见问题
常见问题
我们已经有看板了，为什么还需要数据工程？
看板展示的是管道产出的结果。如果不同报表的口径不一致、数字事后发生变化，或者没人说得清某个数字的来源，那么问题出在看板的上游，要靠建模、测试和血缘来解决。
数据可以新到什么程度？
从流式处理的秒级到批处理的按天更新都可以。数据越新，构建和运维成本越高，因此我们会根据每个数据集所支撑的决策来设定它的时效。
同一个平台能同时服务分析和 AI 吗？
可以，而且应该如此。特征管道和嵌入管道与分析数据复用同一套摄取、质量检查、访问策略和血缘，从而避免组织的数据出现第二份不受治理的副本。
如何控制平台成本？
做法是让成本按工作负载可见，采用增量处理，针对实际运行的查询对表分区，设置分级保留策略，并清理无人读取的数据集和任务。