1. 数据平台工程与自助服务导论

数据平台工程不是“把 Hadoop、Spark、Flink 装起来”这么简单。它要解决的核心问题是：把分散在业务库、日志、埋点、第三方接口里的原始数据，经过采集、存储、计算、治理后，变成可被分析师、运营、算法工程师稳定、快速、安全使用的数据资产。而“自助服务”则是这个平台能否真正产生生产力的关键——如果每个取数需求都要排队等数据工程师写 SQL，平台再先进也只是少数人的工具。

本课程围绕一条主线展开：用工程化手段建设数据平台，用自助服务能力放大平台价值，用性能优化保障规模化后的稳定与效率。三者不是并列关系，而是层层递进：没有工程化底座，自助服务无从谈起；没有自助服务，平台无法规模化；没有性能优化，规模化后必然崩溃。

数据平台的核心定义

一个完整的数据平台通常包含五层能力：数据接入层（CDC、日志采集、API 拉取）、存储层（数据湖、数仓、消息队列）、计算层（批处理、流处理、交互式查询）、治理层（元数据、血缘、质量、权限）、服务层（BI、API、特征平台、自助查询）。这五层不是简单的技术堆叠，而是通过统一的元数据和权限体系串联起来的有机整体。

以电商场景为例：订单库通过 CDC 实时同步到 Kafka，Flink 消费后写入 Iceberg 明细层；离线侧每天凌晨用 Spark 将明细层加工成 DWD、DWS 层；分析师通过 Trino 查询 DWS 层做报表，算法工程师通过特征平台读取 DWD 层生成训练样本。整个链路中，元数据中心记录每张表的上下游血缘，权限系统控制谁能看哪些字段，质量平台监控核心表的空值率和波动。这就是数据平台工程要建设的对象。

自助服务能力模型

自助服务不是“给所有人开数据库账号”，而是分层提供能力。可以把它理解为一个四层模型：

• 发现层：数据目录、搜索、血缘、样例数据，让用户知道“有什么数据、数据长什么样、能不能用”。
• 取数层：SQL 查询、可视化拖拽、指标平台，让用户能自己拿到数据，而不需要提需求单。
• 加工层：调度编排、Notebook、低代码 ETL，让用户能自己构建中间表或特征表。
• 治理层：权限申请、质量规则、成本看板，让用户在自助的同时不破坏平台稳定性和安全性。

这四层缺一不可。只有取数层没有发现层，用户找不到表；只有发现层没有治理层，用户可能误用敏感数据或写出拖垮集群的查询。自助服务的成熟度，取决于这四层是否形成闭环。

生产实践与性能优化的关系

很多团队在测试环境跑得通，一上生产就出问题。原因通常不是代码逻辑错，而是忽略了生产环境的三个特征：数据量大、并发高、SLA 硬。一个在 10GB 数据上跑 30 秒的查询，在 10TB 上可能跑 30 分钟；一个单用户测试正常的 API，在 200 并发下可能直接打满连接池。

性能优化因此不是“上线后再调”的补救措施，而是生产实践的一部分。具体来说，它体现在几个关键决策上：分区策略是否合理（按天分区还是按小时）、文件大小是否适中（小文件过多会拖垮 NameNode 和查询引擎）、Join 顺序是否经过分析（大表 Join 小表应广播）、资源队列是否隔离（避免一个用户的跑批任务饿死所有交互查询）。

以 Trino 查询为例：如果一张 DWS 表按天分区，但查询条件没有带分区字段，Trino 会全表扫描。假设该表有 365 个分区、每个分区 2GB，全表扫描就是 730GB 数据。加上分区过滤后，只扫描 2GB，性能差距是 365 倍。这就是“分区裁剪”在生产中的实际价值。再比如，小文件问题：如果每个分区有 5000 个小文件，每个文件 1MB，Trino 需要打开 5000 次文件句柄，元数据操作开销远超实际数据读取。通过定期合并小文件，可以把查询时间从分钟级降到秒级。

课程整体学习路径与实战项目

本课程共 30 章，按“基础认知 → 平台建设 → 自助服务 → 性能优化 → 生产实战”五个阶段推进。前 6 章建立数据平台工程的整体认知，包括架构分层、元数据管理、权限模型；第 7 到 15 章深入存储与计算引擎的选型、调优和治理；第 16 到 22 章聚焦自助服务能力建设，包括数据目录、指标平台、Notebook 和调度系统；第 23 到 28 章系统讲解性能优化的方法论和工具链；最后两章通过一个完整的实战项目串联所有知识点。

实战项目设定为一个中型电商数据平台：数据源包括 MySQL 订单库、用户行为日志和第三方支付回调；目标是为运营团队提供自助取数能力，为算法团队提供特征表，同时保证核心报表在每天 9 点前准时产出。项目会涉及 CDC 接入、Iceberg 存储、Flink 实时清洗、Spark 离线加工、Trino 查询加速、元数据血缘和权限控制。每个阶段都有可运行的配置示例和可观察的性能指标，帮助你把“知道”变成“做到”。