大数据开发

人工智能与数据
└─ 数据工程侧
    ├─ 数据治理与数据质量        ← L2-人工智能与数据-01-数据治理与数据质量
    ├─ 大数据开发                 ← ← 本篇
    └─ 商业智能BI与数据可视化    ← L2-人工智能与数据-04-商业智能BI与数据可视化

领域树分支为本库自建的组织结构，非官方分类；官方职业分类中与本篇最近的是「大数据工程技术人员」（职业编码 2-02-10-11）。

一句话定位：数据工程侧的三个岗位构成本领域的底座——数据治理定标准与质量，大数据开发建链路与引擎，BI 消费与呈现。三者共用同一批数据，但交付物完全不同：一个交付规则，一个交付数据流，一个交付结论。本篇讲中间那一环，即把数据从各处搬来、加工成可用形态、并把它稳定地供出去。

它是整个领域的前置条件：没有可用的数据管道，数据分析没有原料，模型训练没有特征。这一点决定了这个岗位的一个特点——它的价值不容易被直接看见，但它的故障一定会被所有人看见。

一句话定义：大数据开发是以批量与流式计算引擎构建数据集成、加工与服务化链路的工程岗位；日常负责 ETL／ELT 流程开发、数据仓库与数据湖建设、实时数据链路搭建、资源与性能优化，并与数据治理、下游 BI 及业务方协同。

官方职业标准把「大数据工程技术人员」定义为从事大数据采集、清洗、分析、治理、挖掘等技术研究，并加以利用、管理、维护和服务的工程技术人员，下设三个等级，并在初、中级划分大数据处理、大数据分析、大数据管理三个方向（附一第 1 条）。这个官方定义值得注意的地方是：它把"采集、清洗、治理"和"分析、挖掘"都放进了同一个职业名下——也就是说，官方口径里的边界比市场招聘口径更宽。市场上说的"大数据开发"，通常只对应其中链路与引擎那一块。

本库把数据工程侧拆成三篇而不是合为一篇，原因也在这里：开发、治理、消费是三种不同的日常工作，能力要求与产出物差异明显，求职时混在一起看容易投错方向。

职责边界（五类日常）

一、数据集成与 ETL／ELT

这是大数据开发最核心也最基础的一环：把数据从产生它的地方，搬到能用它的地方。

搬这件事听起来简单，难在数据源从不配合。业务库可能不让直连（怕影响线上）、日志可能是半结构化的文本、第三方接口可能限流或字段随时变、历史数据可能既没有主键也没有时间戳。一个成熟的大数据开发，判断力主要体现在"用什么方式搬"上：全量覆盖还是增量同步、拉取还是推送、消息队列削峰还是直连抽取、什么时候可以接受延迟、什么时候必须准实时。

这里有一个容易被低估的设计选择：ELT 与 ETL 的差别不只是顺序。传统 ETL 是先在中间层转换再写入目标，转换逻辑集中在数据处理工具里；ELT 是先把原始数据原样落进数据湖／仓库，再用仓库自身的算力做转换。后者在存储便宜、算力弹性的环境下越来越常见，好处是原始数据保留完整、可重跑，坏处是对目标存储的规范性与治理能力要求更高——如果落进去的是垃圾，最后清洗的成本会成倍回来。

• 动作：数据源接入、抽取策略设计、增量与全量同步、字段映射与格式转换、异常数据处理、任务容错与重跑机制。
• 产出：可稳定运行的数据集成流程；数据源清单与接入文档。
• 常见坑：把"抽取成功"当成"数据正确"。源端字段语义变更、时区不一致、枚举值新增、主键重复，都不会让任务报错，只会让下游数字悄悄偏掉。校验必须做在链路里，而不是靠下游发现。

二、数据存储与模型

数据搬来之后要放得有规矩。这一环的专业性容易被外行忽略，但它决定了下游所有人用得顺不顺。

主流做法是分层建模：原始层（ODS）保留最接近源头的形态，明细层（DWD）做清洗与规范化，汇总层（DWS）按主题聚合，应用层（ADS）面向具体报表或接口。分层不是为了好看，是为了把变化隔离开——源端字段改了，只需改 ODS 到 DWD 的映射；业务口径变了，只需改汇总层，不用动最底下的数据。

在物理层面，分区、分桶、压缩格式、文件大小这些都是要逐项决策的：分区键选得对，查询能少扫几个数量级的数据；选得错，全表扫描会成为常态。文件太小会造成元数据膨胀与小文件问题，太大则影响并行度，这里存在明确的工程权衡。

• 动作：设计分层模型与表结构、定义分区与存储策略、管理元数据与血缘、处理历史数据变更（拉链表、快照）、规划存储成本。
• 产出：可被多方复用的数据模型；元数据与血缘关系。
• 常见分歧：该建宽表还是保持规范化。宽表查询快、下游好用，但更新成本高、一处变更要重跑全链；规范化表灵活、复用性好，但每次查询都要多层关联。判据是看下游的使用频率与变更频率——高频消费、低频变更的，做宽表值得；口径还在探索期的，保持灵活更好。

三、实时数据链路

批处理之外的另一半。批处理回答"昨天发生了什么"，流处理回答"此刻正在发生什么"。两者所需的技术栈和工作节奏都不一样。

实时链路的关键概念是有状态计算与一致性保证：数据是一条一条来的，可能乱序、可能重复、可能延迟很久才到，处理逻辑要在这种前提下给出可信结果。Flink 的架构文档里把这一点讲得很清楚——对有界与无界数据流做有状态计算，无界流需连续处理、按事件发生顺序，支持 exactly-once 状态一致性与异步增量 checkpoint（附一第 5 条）。Kafka 则承担事件流的发布订阅、持久可靠存储与实时／回溯处理三项能力，并且越来越多地作为数据平台与事件驱动架构的底座（附一第 6 条）。

实时开发与批处理开发在心态上差别很大：批任务可以在夜里跑、错了重跑；流任务一旦上线就在持续消费，改逻辑要考虑已消费的数据怎么办、状态怎么迁移、上线瞬间会不会重复计算。这种"变更即事故"的特性，是这个方向最需要经验的地方。

• 动作：消息队列接入与主题设计、流处理作业开发、窗口与状态管理、乱序与重复数据处理、水位线设置、作业调优与扩缩容。
• 产出：可稳定运行的实时链路；延迟与准确性的量化说明。
• 常见坑：把实时当成"批处理的加速版"。两者的失效模式完全不同——批任务失败是可见的（任务报错、数据没出），流任务的常见失效是静默的（延迟慢慢变大、部分数据被丢、状态悄悄膨胀），所以实时链路的监控粒度必须比批处理细得多。

四、资源与性能优化

数据量上去之后，这个环节会占据越来越多的时间。它也是大数据开发最"工程"的一面。

常见问题有三类：数据倾斜（某个键的数据量远大于其他，导致个别任务拖慢整个作业）、小文件过多（影响元数据性能与读写效率）、资源争抢（多个任务在同一集群上抢 CPU 与内存，互相拖累）。这些问题不会让任务失败，只会让它越来越慢、越来越贵。

Hadoop YARN 提供的正是这一层的资源管理机制：把资源管理与作业调度监控拆为独立守护进程，全局 ResourceManager 加每应用的 ApplicationMaster，NodeManager 负责容器与资源监控，调度器支持容量与公平等策略（附一第 13 条）。理解这一层不是为了自己写调度器，而是为了知道任务变慢时该从哪里找原因。

湖仓方向的演进也集中在这一环。Iceberg 提供 schema 演化无副作用、隐藏分区、分区布局演化、时间旅行与版本回滚、乐观并发控制等能力（附一第 9 条）；Hudi 把事务、高效 upsert／delete、索引、聚类压缩等数据库能力带进数据湖（附一第 10 条）；Delta Lake 提供 ACID 事务、可扩展元数据、流批统一与 schema 强制（附一第 11 条）。它们解决的是同一个痛点：数据湖能存，但不好改、不好保证一致。

• 动作：作业调优、数据倾斜处理、小文件合并、资源队列与优先级配置、成本核算与优化、湖仓表格式选型。
• 产出：更快的作业与更低的成本；性能基线与优化记录。
• 常见分歧：性能与成本的取舍。有些优化是把作业时间压短但增加了资源占用峰值，有些优化是降低资源但延长窗口——两个目标常常反向，必须和业务方确认哪一头更重要。

五、协同与服务化

数据链路的价值最终体现在被使用上，所以"供得出去"是工作的一部分。

这一环要求大数据开发像对待产品一样对待自己的数据：这张表谁在用、什么时候更新、口径是什么、改字段会影响谁、出问题找谁。数据契约与 SLA（什么时候必须产出、延迟容忍度多少、数据质量阈值）是这里的主要工具。dbt 这类工具提供的血缘、测试、契约与指标能力，本质上是把"承诺"变成可被机器检查的东西（附一第 8 条）。

与数据治理的边界在这一环最需要说清楚：大数据开发负责让数据可用，数据治理负责定义什么算可用。前者建链路、保时效、修故障；后者定标准、建质量规则、做全生命周期的风险治理。中国信通院《数据治理研究报告（2025 年）》系统剖析了数据在采集、存储、处理、传输及销毁等全生命周期环节的风险特性并提出综合治理策略（附一第 16 条）——这些策略的落地执行，通常由大数据开发在链路里实现。

• 动作：数据产品化交付、口径对齐与文档化、SLA 定义与监控、下游问题响应、元数据与血缘维护。
• 产出：可被下游依赖的数据服务与其承诺说明。
• 常见坑：只对"任务有没有跑完"负责，不对"数据对不对"负责。任务成功和结果正确是两件事，中间隔着数据校验、口径核对和异常告警。

一个迭代周期里的实际工作流

把上述五类日常放进一次真实的数据需求，路径大致是：

1. 需求对接与口径确认——先问清"要什么数、给谁看、多久更新一次、能容忍多大延迟、口径以哪个系统为准"。口径没对齐就开发，是这一行最贵的错误——跑完才发现两个部门对"活跃用户"的定义不一样，全部重做。
2. 数据源探索与可行性核实——确认源表在哪、有没有权限、数据量多大、质量如何、更新频率怎样。这一步经常发现"这个需求的数据根本不存在"。
3. 模型设计——定分层位置、表结构、分区键、更新方式（全量／增量／快照）、依赖关系。
4. 任务开发——写转换逻辑、配置调度、设置依赖与重试。
5. 调试与质量校验——数据量核对、空值检查、主键唯一性、跨表一致性、与源系统对账。校验做在发布前，成本是发布后的十分之一。
6. 发布与调度——上线任务、注册血缘、配置监控与告警、确认 SLA。
7. 监控与优化——盯任务时长、数据量波动、延迟、资源消耗；按需调整与优化。

一个常被忽略的事实：大数据开发的时间有相当一部分花在排查数据为什么对不上上——是不是上游晚了、是不是某个分区漏跑、是不是口径改了没通知、是不是重复数据。这类问题的定位完全依赖对链路与血缘的熟悉程度。对新同事来说，最需要先建立的资产不是代码能力，而是"这张表从哪里来、到哪里去"的全局图。

相邻岗位辨析

三组最容易混的场景：

• 大数据开发 vs 数据治理：这两个岗经常被混为"数据岗"，分界在交付物是数据流还是数据规则。判据是问一句"你写不写数据处理逻辑"——写调度、写转换、写链路的是开发；写标准、写规则、做质量核查与治理方案的是治理。两者共享元数据与血缘，但在组织里常常分属不同团队——一个是生产部门，一个是标准部门。
• 大数据开发 vs BI：最典型的分界是"生产侧还是消费侧"。判据是看交付对象：交付给下游系统用的是开发，交付给人看的是 BI。两者都会写大量 SQL，但开发关心的是"这条链路对不对、快不快、稳不稳"，BI 关心的是"这个数说明了什么、业务该怎么做"。同一个 SQL 技能，在两边服务的对象完全不同。
• 大数据开发 vs 后端开发：工程能力高度重合（分布式、并发、性能、可观测性），区别在交付物的形态与使用方式。后端交付的是被实时调用的服务接口，大数据交付的是按周期产出或持续流动的数据。判据是问"出错的时候，是用户立刻看到，还是下游任务稍后发现"——前者偏后端，后者偏大数据。这个差别也决定了两个岗位的故障响应节奏完全不同。

判断口诀：写数据链路与引擎、为下游供货 → 大数据开发；写数据标准与质量规则、管全生命周期风险 → 数据治理；写分析报表与看板、为业务给判断 → BI；写被实时调用的服务接口 → 后端；建平台与发布体系 → DevOps／SRE。

不同业务形态下的重心差异

同一岗位名，在不同行业处理的完全是不同形态的数据：

• 互联网（用户行为、日志、内容）：数据量最大、写入最密集、实时性要求高。埋点数据的采集与清洗、行为链路与画像标签体系、大规模日志的存储成本控制是主要战场。
• 金融（交易流水、风控、监管报送）：一致性与可审计性压倒一切。任何一笔数字都要能追溯来源与计算过程，数据不能丢、不能重、不能错；报送类任务有硬性时间窗口，错过就是合规问题。
• 制造（设备数据、IoT、工艺参数）：时序数据为主，采样频率高、单点数据量小、点位数量多。数据常在边缘侧先做聚合再上传，链路设计要同时考虑网络不可靠与数据完整性。
• 零售与消费（会员、库存、价格、订单）：主数据管理与维度建模是重点，跨系统口径统一是长期难题（线上线下的订单、库存、会员往往来自不同系统）。促销期的流量峰值对容量规划是硬考验。
• 政务与公共部门（城市治理、公共数据）：数据来源分散在多个部门、共享与安全要求并存。数据开发常要处理跨部门的格式与标准差异，且必须严格遵循数据分级分类与安全规范。
• 传媒与内容（内容资产、推荐数据）：非结构化内容多（文本、图像、音视频），数据链路要处理内容元数据、标签与特征提取，并为推荐侧提供特征供给。

对求职者的含义：数据形态决定了你要补的技能。结构化订单数据与设备时序数据、文本内容数据所需的技术栈差别很大。投简历前先看这个岗位处理的是哪一类数据，比看它用了什么组件更有意义。

入行与转出（公开口径）

• 背景：计算机、软件工程、信息管理、数学与统计等背景最常见；这一方向对学历的门槛低于算法岗，本科是主流起点，专科在部分企业也可进入。官方标准对「大数据工程技术人员」设置的受教育程度起点为大学专科，且职业功能中明确包含大数据系统搭建、大数据平台管理与运维、大数据技术服务、大数据处理与应用（附一第 1 条）——官方口径的实际含义是：这个岗位的能力是通过工程实践积累的，不完全依赖学历。
• 前置知识：至少一门编程语言（Java 或 Scala 最主流，Python 在数据加工侧使用广泛）、SQL 的深度掌握（不只是会查，还要理解执行计划与优化）、分布式系统的基本概念（分片、副本、一致性、容错）、一门主流计算引擎（Spark 或 Flink）。操作系统、网络与 Linux 命令行是日常工具，不是可选知识。
• 常见入口：
  1. 校招进入数据平台或数据研发团队——最主流路径，前半年通常从单条链路或单张表做起，逐步建立对全局血缘的理解。
  2. 后端开发转大数据——工程与分布式能力可直接复用，需要补的是数据建模、SQL 深度与数据治理意识；这条路径转换成本最低，也最常见。
  3. 运维／DBA 转大数据——对集群、部署与故障的理解是优势，需要补的是数据处理逻辑与建模能力。
  4. 数据分析转大数据——SQL 与业务理解是优势，需要补的是工程能力、性能优化与链路设计。
• 适配画像：能接受"工作成果不直接显形、但出错立刻被所有人看见"；对数据准确性有执念，愿意为了一个小数点差异排查一整天；不排斥跨团队沟通（口径对齐是日常工作的一部分）。
• 三个常见认知误区：① 以为这个岗位就是"写 SQL"——真正的难点在链路设计、性能优化与数据建模；② 以为学会了组件就会做——组件用法半年能上手，难的是判断在什么场景该用哪个；③ 以为数据开发是纯技术岗——口径对齐、需求沟通与问题响应占的时间比想象中多。
• 职业特点：这是数据领域需求最稳定、入行门槛最平缓的方向之一。岗位需求随企业数字化投入波动，制造业与传统行业的数字化部门持续释放这类岗位。天花板取决于两件事：一是能否从"实现需求"走到"设计数据架构与治理体系"；二是能否把实时计算、湖仓一体等新范式真正吃透——只会用单一组件的开发，会在技术栈更替中被落下。
• 转出方向：转数据架构或平台工程、转数据治理与数据管理、转算法工程师（在强工程背景且补足数学之后）、转数据产品经理、转技术管理与项目管理。