五年数据开发复盘：从数仓建设到 AI 产品化的阶段性思考

匆匆五载，我在数据开发岗位上已经接触过 BI、报表、SaaS 数仓产品、全链路数据体系、数据血缘、数仓建模、开源数仓等一系列周边产品和技术方向。

刚开始做数据开发时，我更多关注的是代码本身。那时候 Java 已经忘得差不多了，主要从 Python 和 SQL 重新开始，围绕抽数、清洗、建表、调度、报表支撑这些具体任务展开。随着项目经验增加，我逐渐发现，数据开发真正困难的地方，并不只是把代码写出来，而是如何理解业务实体，如何判断唯一实体，如何设计稳定的数据结构，如何让数据在长期变化中仍然可用。

这几年，我的重心也从单纯的代码编写，慢慢转向业务实体识别、数据仓库建模、指标口径沉淀和数据链路治理。尤其是在音乐版权和内容数据场景中，歌曲、艺人、录音版本、版权主体、平台播放数据、发行关系等实体之间并不是简单的一对一关系。如何判断同一首歌、同一个艺人、同一个版权主体，反而成了数据建设中更核心的问题。

AI 市场兴起后，我也尝试向 AI 方向靠近。坦白说，数学基础和英语基础的薄弱，让我很难深入 AI 底层算法，比如模型结构、训练优化、深度数学推导这些方向。但这并不意味着数据开发不能参与 AI 变革。相反，我认为数据开发更适合从 AI 产品化、AI 工程化和 AI 应用落地切入。

提示词工程、本地大模型、向量召回、RAG、实体识别、文本解释、数据质量辅助分析，这些方向本质上都离不开数据工程能力。AI 可以增强数据使用效率，但 AI 的效果仍然依赖底层数据是否干净、稳定、可追溯、可解释。

所以，我现在对自己的定位不是“转行做算法”，而是：在数据工程基础上，理解 AI 的应用边界，把 AI 作为提升数据生产和数据消费效率的新工具。

一、我对数据开发的理解：核心仍然是数据仓库

现在市场上有很多概念：数据中台、数据治理、数据资产、数据血缘、湖仓一体、指标平台、标签体系、数据服务、DataOps。

这些词当然有意义，但如果脱离数据仓库本身，很容易变成概念堆砌。

我更愿意把数据开发集中理解为数据仓库建设，而不是过度拆分成数据中台、数据治理等概念。因为在我看来，数据开发的重点依旧是数据仓库的搭建和使用。

数据中台可以理解为数据仓库全链路能力的产品化表达。
数据治理可以理解为让数据仓库更好被使用、更长期可维护的管理手段。
数据血缘是为了让数据仓库的加工过程可追踪。
指标体系是为了让数据仓库的业务口径可复用。
元数据管理是为了让数据仓库的表、字段、任务、口径、负责人被清楚描述。

这些能力不是孤立存在的，它们都应该体现在数据仓库的生命周期中。

一个好的数据仓库，不只是有 ODS、DWD、DIM、DWS、ADS 几层表，而是从数据接入、数据清洗、实体建模、指标沉淀、质量监控、任务调度、权限管控、数据服务到持续治理的一整套体系。

分层不是目的，建模不是目的，治理也不是目的。
真正的目的是：让数据更快、更准、更稳定地支撑业务判断。

二、数据接入：不是简单抽数，而是链路稳定性的起点

数据接入换一种说法，可以叫数据采集、贴源层建设、抽库、爬虫、API 接入、业务系统同步、日志消费、文件接入。叫法不同，但本质都是把外部数据安全、稳定、可追溯地接入到数据体系中。

在数据接入阶段，我首先关注的不是工具，而是数据源本身。

1. API 接入

如果数据来自 API，就需要考虑接口限流、每分钟额度、并发请求限制、分页逻辑、字段缺失、失败重试、接口版本变化和异常报警。

API 接入看起来简单，实际上很容易出问题。字段突然少了、分页规则变了、接口返回空值、某天额度被打满，都会影响后续数据链路。

所以 API 接入不能只写一个请求脚本，而要考虑完整的失败处理机制。比如：

接口失败是否重试；
重试几次；
字段缺失是否阻塞任务；
数据量突增或突减是否报警；
接口返回结构变化是否能被及时发现。

2. Kafka 与中间件接入

如果数据来自 Kafka，就要考虑消费速度是否能跟上生产速度，是否存在消息堆积，数据格式是普通 JSON、Debezium JSON，还是其他自定义格式。

同时还要关注消费语义。是至少一次，还是精确一次？offset 如何管理？任务失败后能不能恢复？消息乱序和重复如何处理？这些问题都会影响下游数据可信度。

Kafka 接入不是“能消费到数据”就结束了，而是要保证长期稳定消费，并且在异常发生时知道从哪里恢复。

3. 数据库抽取

如果数据来自业务数据库，就要先判断抽取方式。

是全量抽取，还是增量抽取？
是基于时间字段，还是基于自增 ID？
是否需要索引支持？
是否能走批量读取？
抽取速度是否需要限制？
访问的是备库还是生产库？
是否会影响业务系统？

在数据库抽取中，好的约定往往比好的代码更重要。

如果源系统能提供稳定的更新时间字段、删除标记、业务主键和抽取窗口，那么开发难度会大幅下降。反过来，如果源系统没有任何规范，只靠数据开发在下游兜底，成本会非常高。

4. 手工数据、文件和非结构化数据

手工数据、Excel、CSV、OSS 文件、非结构化数据，最大的问题不是接入，而是异常处理。

字段多一个、少一个，日期格式变了，编码变了，分隔符变了，换行符进入字段内容，都会导致任务失败或者脏数据入仓。

我以前会倾向于把很多字段都设成 String，先保证数据能进入 ODS。但现在看，这个做法要分层看。

ODS 层可以适度使用 String 保留原始输入，避免因为源头脏数据导致整条链路中断。
但进入 DWD、DIM 或指标层时，核心字段必须完成类型规整、空值处理、枚举校验和异常暴露。

不能把 String 当成逃避数据质量问题的手段。
全是 String 的表，短期开发很方便，长期会让质量问题后置，导致报错不敏感，指标不可信。

三、抽取工具：没有最好，只有适不适合场景

数据接入工具的选择，需要结合数据源、数据量、实时性、稳定性和团队维护能力。

1. DataX

DataX 是我用得比较顺手的工具。它稳定，适配的数据源也比较多，适合大量离线批量抽取场景。

它的优点是简单、直接、可靠。对于很多传统数据库到数仓的同步任务，DataX 足够好用。

但它也不是万能的。如果追求极致速度、复杂实时同步、强事务一致性，或者对部分数据仓库有特殊写入优化要求，DataX 可能就不一定是最优选择。

2. Kettle

Kettle 这种先落文件、再写入的形式，对数仓其实很友好。尤其是能够直接写 HDFS 或文件系统时，文件中转会带来很大的灵活性。

在大数据场景下，文件是一种非常重要的中间形态。因为文件天然适合批处理，方便落地、重跑、校验、备份，也方便后续通过 Spark、Hive、ClickHouse、Greenplum 等系统继续处理。

但 Kettle 的问题也明显：配置较重，协作体验一般，工程化能力偏弱。对于多人开发、版本管理、任务复用、自动化发布来说，不如代码化方案灵活。

3. Flink CDC

我把 Flink CDC 也看作一种数据接入工具。它配置简单，对更新频繁的数据源比较友好，尤其适合 MySQL 等数据库的变更捕获。

对于需要捕获 insert、update、delete 的场景，CDC 比传统定时抽取更自然。

但 CDC 的代价是需要长期运行任务，需要监控 checkpoint、延迟、状态大小、失败恢复和资源消耗。它不是一个“配置完就不用管”的工具，而是一个长期在线服务。

4. gpfdist 与文件传输

gpfdist 是 Greenplum 体系中很实用的工具，可以理解为一种面向 Greenplum 的高速文件分发和加载方式。

在大数据极限场景下，我越来越认同一个观点：

当数据量大到一定程度，并且格式要求不是极端严格时，文件传输往往比复杂接口更可靠。

比如几十亿数据的迁移，如果你要求每一条都通过接口、每个字段都严格校验，可能成本会非常高。反而通过文件批量传输、合理设计分隔符、换行符、字段转义和异常兜底机制，能更快解决问题。

当然，这不是说可以无视数据质量，而是极限情况下要做取舍。

如果能够保证 90% 以上的数据快速稳定进入体系，剩下 10% 的异常通过日志、隔离表、补偿机制处理，这在某些项目里就是更现实的选择。

四、数仓建设：分层理论很好，但不能迷信分层

数仓建设是整个数据链路中最复杂的部分。

如果是从 0 到 1 的项目，通常要对接公司或集团的数据开发规范，包括主题域划分、表命名规范、字段命名规范、数据字典、指标口径、任务调度、权限申请、验收流程等。

DWD、DIM、DWS、ADS 这些分层理论当然有价值，但这些概念已经被讲得太多了。真正难的不是知道分层名称，而是在真实项目中知道什么时候该拆，什么时候该合，什么时候该沉淀，什么时候该放弃。

分层不是目的，建很多表也不是目的，把表名写得规范也不是目的。

真正的目的应该是：

• 让数据更容易理解；
• 让指标更容易复用；
• 让口径更容易统一；
• 让变更影响更容易控制；
• 让历史问题更容易追溯；
• 让业务能更快、更稳定地使用数据。

一个好的数仓模型，不是看起来有多少层，而是当业务变化时，它能不能以较低成本继续支撑分析。

五、沟通：数仓建设的第一生产力

数仓建设最开始的一步不是写代码，而是沟通。

对于做过完整项目的人来说，需求文档、数据字典、验收文档的重要性不言而喻。

需求文档说明业务到底要什么。
数据字典说明字段来自哪里、含义是什么、如何计算。
验收文档说明怎么算完成、怎么算正确、由谁确认。

这三个文档背后靠的都是沟通。

数据仓库某种意义上比传统软件更敏捷。传统软件的功能上线后，可能一段时间内相对稳定。但数据仓库面对的是不断变化的业务事实。今天的指标，明天可能换口径；今天的实体，明天可能被拆分；今天的粒度，明天可能无法支撑新的分析。

所以数仓开发必须更快沟通、更精确沟通，也必须敢于对需求做减法。

我认为沟通中最重要的是四件事：维度、度量、核心指标、历史结构。

六、维度：数据仓库一切设计的锚点

维度是数据仓库分析的起点。

只有先理解维度，才能设计主题域，考虑事实表粒度，考虑维表结构，考虑聚合方式，考虑存储策略。

比如业务关注复购，那就要先看复购涉及哪些实体。可能是订单、商品、会员、渠道、活动、门店。能想到的先写出来，再做减法。

• 产品和产品规格是否都要保留？
• 规格对复购统计影响大不大？
• 会员等级是否参与分析？
• 渠道是否影响复购判断？
• 活动是否要进入归因？

维度不是越多越好。维度太少，分析能力不够；维度太多，模型复杂度和维护成本都会上升。

对于音乐版权场景来说，维度问题会更加明显。

歌曲是一个维度，艺人是一个维度，平台是一个维度，版权主体是一个维度，发行渠道也是一个维度。可是歌曲和艺人可能是多对多关系，歌曲和版权主体可能会因为地区、时间、版本不同而变化。

这时候，维度设计就不是简单建一张宽表，而是要先搞清楚业务实体之间的关系。

维度是未来数仓不断调整的锚点。
你可以增加它，也可以细化它，但不能忽视它。

七、度量：必须和粒度绑定

有了维度之后，才谈得上度量，度量是事实表的核心，但度量不能脱离粒度讨论。

播放量、订单金额、点击数、收入、版权费用、排名、收藏数，这些字段看起来都是简单数字。但真正困难的是：

• 按什么粒度统计？
• 按歌曲，还是按录音版本？
• 按艺人，还是按艺人和歌曲关系？
• 按平台，还是按平台加地区？
• 按自然日，还是业务日？
• 空值怎么处理？
• 重复数据怎么处理？
• 迟到数据怎么处理？
• 历史修正数据怎么处理？

比如流媒体歌曲播放量，如果事实表的粒度是“歌曲 + 平台 + 日期”，那播放量就是这个粒度下的度量。

如果后来业务说要看“录音作品”的播放量，那么这已经不是简单改一个度量字段，而是粒度发生了变化，所以抛开粒度谈度量，是没有意义的。

度量的设计不能只听需求方说要什么，还要找数据提供方验证有没有这个数据，字段是否可靠，是否需要二次计算，是否有历史数据，是否能长期稳定产出。

维度大概率是存在的，但度量不一定天然存在。很多度量是计算出来的，甚至是多个系统、多张表、多层逻辑加工后的结果，这也是数据开发的价值所在。

八、核心指标：做减法比做加法更重要

一个项目真正核心的指标，其实不会太多。

数据开发经常会遇到一种情况：业务一开始想要所有数据、所有维度、所有指标，最好还能实时更新，历史可查，口径可切换，权限可控制，报表可下钻，但现实是，资源、时间、成本都有限。

人也不可能同时分析几百个指标。指标太多，反而说明没有抓住重点，所以数据开发不能只是被动接需求，也要帮助业务做减法。

• 哪些指标真正影响决策？
• 哪些指标只是看起来有用？
• 哪些指标可以延后？
• 哪些指标没有数据支撑？
• 实时有没有必要？
• 分钟级、小时级、天级的成本差异是多少？
• 谁真的会用实时数据？
• 如果不用实时，业务损失是什么？

比如歌曲播放量统计，实时当然听起来很高级。但如果业务只是每周看趋势、每月做结算、每年做版权评估，那么 T+1 离线统计可能已经足够。

实时不是没有价值，而是要判断有没有必要。
技术越复杂，越要回到业务目的。

九、历史结构：旧系统不是包袱，而是约束条件

如果是从 0 到 1 建设数仓，历史结构压力相对小一些。但大多数真实项目不是完全从零开始，而是在已有系统、已有表、已有报表、已有口径之上继续迭代。

这时候，历史结构就是必须面对的问题。

• 一张旧表可能已经被多个报表使用。
• 一个旧字段可能已经被多个部门理解成不同含义。
• 一个旧指标可能已经在历史会议中被反复引用。
• 一个旧任务可能已经成为其他链路的依赖。

所以改表、改字段、改口径，都不能只看当前需求，还要看历史影响，这时候数据字典、血缘关系、任务依赖、字段使用情况就很重要，常聊的数据治理也就是这些逻辑。

如果没有这些资料，就只能靠和同事沟通、查代码、查调度、查报表、查历史 SQL 来还原影响范围，历史结构不是包袱，而是约束条件。
成熟的数据开发，要学会在约束中改造，而不是一上来就推倒重来。

十、主题划分：从实体和业务过程出发

主题划分对我来说仍然是需要继续加强的部分。

很多公司已经有自己的主题域规范，比如用户主题、商品主题、订单主题、内容主题、版权主题、财务主题、营销主题等。真实从 0 到 1 划分主题域的机会并不多。

而且从 0 到 1 时，早期业务可能还没有复杂到需要过度划分主题。过度设计反而会增加维护成本。

但主题划分仍然重要，我的理解是：主题划分应该从实际需求出发，抓住核心实体和核心业务过程。

在音乐收购和版权监控场景中，主题可以围绕歌曲实体、艺人实体、唱片公司实体、版权实体、平台播放实体、发行关系实体来展开，这里的实体不一定都是真实世界中“看得见”的对象，也可以是和开发目的相关的概念实体。

比如“版权关系”不是一个物理对象，但它是业务分析中的核心实体。“歌曲-艺人关系”也不是单独存在的业务对象，但在数据建模中非常关键。“平台版本映射”可能也不是业务系统原生实体，但在判断唯一实体时非常重要。

如果你在雪花模型中拆出了一张中间维表，那么这张表的粒度其实就代表了一个你认可的实体或关系。

主题划分可以适度保守，但不能完全没有前瞻性，多一个主题可能每天增加一些存储成本，但如果后期避免了大规模重构和历史数据修复，这个成本就是值得的。

十一、星型模型与雪花模型：形式相似不代表目的相同

星型模型和雪花模型是实际开发中最常用的维度建模方法。

1. 星型模型

星型模型可以理解为事实表在中心，多个维度表围绕事实表展开。维表之间没有太多依赖关系，事实表通过维度键关联各个维表。

这种模型查询简单、理解成本低、性能相对好，适合维度稳定、业务过程清晰的场景。

比如歌曲播放事实表，可以围绕日期、歌曲、平台、地区等维度展开。如果歌曲维表本身就能满足分析需求，那么星型模型就很合适。

在工程实现中，这种结构也比较友好。事实表加几个相对较小的维表，很多时候可以通过广播 Join 或预聚合解决性能问题。

2. 雪花模型

但现实中，维度并不总是简单稳定。

• 歌曲可能有多个艺人。
• 艺人可能有多个别名。
• 歌曲可能有多个版本。
• 版权可能按地区、时间、主体变化。
• 发行关系可能跨平台、跨厂牌、跨国家。

如果强行把这些内容都塞进一张歌曲宽维表，短期使用方便，长期维护会非常痛苦。

当歌曲维表被歌曲排行、版权费用计算、平台监控、收购评估等多个链路共同使用时，任何字段结构变更都会牵一发动全身。

这时候雪花模型就更合理。雪花模型允许维表继续拆分，比如拆成歌曲维表、艺人维表、歌曲艺人关系表、版权主体维表、版权关系表、平台映射表等。

这样会增加 Join 成本，但能降低维护成本，提高复用能力，也更适合复杂实体关系。

3. 雪花模型与第三范式的区别

雪花模型看起来很像第三范式，但不能简单等同。

第三范式主要服务业务系统，核心目标是减少冗余、避免更新异常、保证数据一致性，适合高频增删改查。

雪花模型服务分析场景，它是在星型模型基础上的维度拆分，目标是让维度更容易维护、更容易复用、更适合复杂分析。

二者形式上都可能表现为拆表，但目的不同。

关系型数据库关注的是业务事务的正确性和高效增删改查。
数据仓库关注的是分析查询、历史追溯和指标复用。

所以雪花模型不是为了追求范式而拆表，而是为了让分析型数据结构更稳定。

十二、聚合层：根据粒度沉淀公共结果

聚合层的核心是根据业务常用粒度沉淀可复用结果。

如果 DWD 解决的是明细事实，DIM 解决的是维度描述，那么 DWS 更像是面向主题和分析场景的公共汇总层。

比如在音乐场景中，可以沉淀：

• 歌曲每日平台播放汇总；
• 艺人每日平台播放汇总；
• 版权主体每日播放汇总；
• 歌曲在不同地区的播放趋势；
• 平台榜单每日排名变化；
• 收购歌曲的历史峰值播放数据；
• 疑似侵权歌曲的播放增长情况。

聚合层不能随便建，如果每个报表都建一张聚合表，最后会变成 ADS 泛滥。

聚合层应该沉淀那些高频使用、口径稳定、多个下游复用的指标结果。

它的价值是减少重复计算，统一指标口径，提高查询效率。

十三、BI 与报表：不是终点，而是数据消费的一种形式

BI 和报表是数据开发最常见的输出形式，但它不是数据仓库的全部。

很多时候，业务会把报表当成最终结果，但对于数据开发来说，报表只是数据消费的一种形式。

一个指标如果只存在于某张报表里，而没有沉淀到指标层或公共数据模型里，那它很难复用，也很难治理。

所以在做 BI 和报表时，不能只关注页面展示，还要反向思考：

• 这个指标是否应该沉淀？
• 这个口径是否会被复用？
• 这个筛选条件是否是业务维度？
• 这个报表是否只是临时分析？
• 这个数据是否需要提供给 API、AI 或其他系统？

BI 是数据仓库价值的外显，但真正的价值仍然在底层模型和指标体系中。

十四、AI 的介入：不是替代数仓，而是增强数仓

AI 进入数据开发，不应该理解为替代数据仓库。

相反，AI 更依赖高质量的数据仓库。没有稳定的数据源，没有清晰的指标口径，没有可靠的实体关系，没有可追溯的数据血缘，AI 很难真正落地。

我目前理解的 AI 介入数据开发，主要有两个方向。

1. 解释性 AI

解释性 AI 是指用 AI 帮助人理解数据。

比如：

• 解释某个指标为什么波动；
• 解释一条 OneID 匹配结果为什么被认定为同一实体；
• 解释一张表的字段含义；
• 解释某条数据质量规则为什么触发；
• 帮助业务人员理解报表中的异常变化。

在音乐版权场景中，AI 可以辅助解释：为什么两个平台上的歌曲被判断为同一首歌？是因为 ISRC 一致，还是标题、艺人、发行时间、平台别名等特征共同支持？

这种解释可以提高业务对数据结果的信任。

2. 处理性 AI

处理性 AI 是指用 AI 参与部分数据处理流程。

比如：

• 辅助识别艺人别名；
• 辅助规范化中英文名称；
• 辅助判断文本相似度；
• 辅助生成数据质量规则；
• 辅助生成 SQL 或排查任务错误；
• 辅助构建向量召回，提高候选集召回能力。

但这里必须保持克制。

AI 不能直接成为核心口径的唯一来源。AI 的结果要可验证、可回溯、可人工校验。涉及公司敏感数据时，要考虑数据合规，必要时做脱敏、截断、重写或使用本地模型。

我更愿意把 AI 当成增强工具，而不是权威判断者。

在 OneID、版权监控、实体识别这些场景中，AI 可以帮助提升召回、解释和人工审核效率，但最终规则仍然要落在可审计的数据结构和业务规则中。

十五、我的下一阶段方向

回头看这五年，我最大的变化不是掌握了某个工具，而是理解了数据开发的核心价值。

刚开始，我以为数据开发就是写 SQL、写 Python、调任务、出报表。
后来我发现，数据开发真正有价值的地方，是把混乱的业务事实转化成稳定、可复用、可解释的数据结构。

未来，我认为自己需要继续补强几个方向。

第一，是更系统地掌握湖仓一体和开源表格式，比如 Iceberg、Hudi、Delta Lake，以及它们在数据湖、数据仓库、实时数仓之间的定位。

第二，是继续加强 ClickHouse、Flink、Spark、Kafka、HDFS 这些工程能力，不只是会用，而是理解性能、稳定性、资源和故障恢复。

第三，是补齐数据治理和元数据体系能力。数据血缘、指标管理、质量规则、权限管理、数据资产盘点，这些不是口号，而是数仓长期运行的基础。

第四，是继续沿着 AI 产品化方向探索。相比深入底层算法，我更适合把 AI 用在数据开发真实场景里，比如实体识别、指标解释、数据质量分析、自动 SQL 辅助、知识库问答和本地模型落地。

第五，是继续强化业务理解。对于音乐版权、歌曲收购、平台播放、艺人关系、版权监控这些业务，数据开发不能只看字段，还要理解业务规则背后的利益关系和判断逻辑。

结语：数据开发不是工具岗位，而是业务事实的结构化工程

五年时间让我越来越确认一件事：

数据开发不是简单的工具岗位。

会写 SQL 很重要，会用 Flink、Spark、ClickHouse、Kafka 也很重要，但这些都只是手段。

真正困难的是：

• 你能不能理解业务实体；
• 能不能设计合理粒度；
• 能不能统一指标口径；
• 能不能处理历史包袱；
• 能不能让数据链路稳定运行；
• 能不能在业务变化时控制模型变更成本；
• 能不能让数据结果被业务信任。

AI 时代到来后，数据开发不会消失，反而会变得更重要。因为 AI 需要数据，AI 产品需要数据工程，AI 决策需要可信的数据基础。

未来的数据开发，可能不再只是写 ETL 的人，而是连接业务、数据、工程和 AI 的复合型角色。

我目前还没有深入 AI 底层算法的能力，也没有完整参与过数据湖项目，对 Data Vault 这类建模方法也只是阶段性理解。但这并不妨碍我继续往前走。

我的优势在于真实做过数据链路，理解数仓建设的复杂性，也在音乐版权和唯一实体判断场景中积累了自己的方法论。

下一阶段，我不应该盲目追逐概念，而应该沿着自己的经验继续深入：

以数仓为根基、实体建模为核心、工程稳定性为底座，在 AI 产品化中持续寻找数据开发的新增长点，慢慢把数据开发从“写代码的岗位”，做成“理解业务、组织数据、增强决策”的能力。