实时数仓由谁来做

wen IT资讯 2026-08-01 1

实时数仓“由谁来做”？——深度解析组织架构、角色分工与落地路径

问：老板在周会上拍板：“下季度必须上线实时大屏和秒级预警，实时数仓这事，到底由谁来做？” 会议室瞬间安静，数据团队看运维，运维看后端，后端看架构师——为什么这个问题如此棘手？

实时数仓由谁来做

答：因为实时数仓不是“一个项目”，而是一套跨团队的基础设施改造，它同时触及数据采集（需要业务后端配合）、计算引擎（需要大数据平台）、数据服务（需要后端API开发）和业务分析（需要业务方定义指标），本质上，它是一场组织协同的战争，而非技术选型的填空题。

在讨论“谁来做”之前，必须先看清“难在哪”，与离线数仓的“T+1批处理”不同，实时数仓面临三大垂直挑战：

技术栈陡峭：Flink/Spark Streaming 的状态管理、Exactly-Once 语义、背压机制，以及 Kafka 的 partition 与 Zookeeper 协调，都是“深水区”，普通 Java 工程师很难直接上手。
数据一致性难题：实时链路中，晚到的数据、乱序事件、维度表变更（SCD）如何处理？这需要“Lambda架构”或“Kappa架构”的混合设计经验，而非简单的ETL脚本。
运维复杂度指数级上升：离线任务失败可以重跑，实时任务失败意味着数据断流，需要秒级告警和自动恢复，这要求运维团队具备 K8s 与容器化调度能力。

这三座大山决定了,实时数仓的负责人不能是“兼职”的，必须是全职且拥有跨部门协调权的角色。

根据对大量头部互联网企业（如阿里、字节、美团）的公开实践研究，实时数仓的建设责任通常被拆分为三个层次：

角色主体	核心职责	关键产出物
数据平台团队（基础设施）	提供 Flink/Kafka 集群、实时计算平台（StreamCompute）、任务运维面板	稳定、低延迟的计算资源池
数据研发团队（核心建设者）	负责实时ETL开发、指标定义、数据模型设计（DWD/ADS层）、质量校验	可复用的实时公共层（贴源层、明细层）
业务应用团队（消费方）	提出明确的毫秒级/秒级查询需求，负责实时大屏、风控规则引擎的接入	直观的业务价值反馈

关键洞察：数据研发团队是“主线执行者”，而平台团队提供“弹药”，如果公司没有独立的数据平台组，那么大数据架构师必须兼任此职。

这是决定“谁来做”的最高维度问题。

模式A：中心化数仓团队（Data Centralization）
- 做法：组建一个独立的实时数仓组，直属CTO或数据总监，所有实时需求由该组统一受理。
- 优点：资源集中、口径统一、避免重复建设。
- 缺点：业务响应慢，容易成为瓶颈，且要求团队技术极强。
模式B：联邦制（Data Mesh / 数据网格）
- 做法：将实时数仓的“领域责任”下放到各业务线（如交易、营销、供应链），平台团队提供自助式实时开发平台，各业务线自行培养“实时开发工程师”。
- 优点：贴近业务、响应快。
- 缺点：对平台自助化能力（如Flink SQL化）要求极高，否则会出现“每个团队一个Flink版本”的混乱。

搜索引擎趋势：根据近两年Gartner和信通院的报告，国内80%以上企业采用“中心化起步，联邦制演进”，即初期由平台团队搭台，数据研发团队唱戏，后期通过平台化赋能业务。

光有组织架构不够,具体到人，必须明确岗位描述（JD），以下三个角色是“最低配置”：

实时数仓架构师（1人）
- 必备技能：精通 Flink 的状态后端与 Checkpoint 机制；熟悉 Iceberg/Hudi 的实时湖仓格式；有能力设计流批一体的数据模型。
- 核心职责：制定开发规范、主导技术选型、解决数据一致性疑难杂症。
实时开发工程师（2-3人）
- 必备技能：熟练编写 Flink SQL 和 DataStream API；掌握 Kafka 的 Rebalance 机制；能使用 Dinky/StreamPark 等平台。
- 核心职责：将业务指标转化为实时计算任务，并负责日常链路告警处理。
实时数据运维（SRE，可复用）
- 必备技能：K8s 容器化编排、日志监控（Prometheus+Grafana）、故障自动恢复脚本。
- 核心职责：保障 99.95% 的集群可用性，处理任务反压和 OOM。

问：我们公司只有2个后端和1个传统数仓工程师，预算有限，难道实时数仓就做不了吗？

答：完全可以，但需要“降维打击”的路径：

放弃自建引擎，拥抱云托管服务：使用阿里云实时计算Flink版或AWS Kinesis Analytics，这能砍掉最重的集群运维部分，让后端兼职盯告警即可。
基于MQ的轻量实时链路：如果对时效要求只是“分钟级”，不需要Flink，用 Canal 监听 MySQL Binlog → Kafka → Python脚本消费并写入 Elasticsearch/StarRocks，这是最被低估的“轻实时”方案，上文提到的“实时数仓”痛点在此场景下完全不存在。
采购商业BI的实时引擎：如帆软 FineBI 或 Tableau 的实时连接器，用 SQL Pushdown 方式直连Kafka，虽然灵活度低，但胜在零代码。

关键点：中小企业的核心任务是“活下来”，不要为技术而技术，由数仓工程师负责逻辑定义，后端工程师负责链路稳定性，即可解决。

回到最初的问题,实时数仓由谁来做？答案是：CTO 指定一位“数仓负责人”作为唯一问责人，并赋予其两项特权：一是可直接调度平台组资源；二是有权对业务方的需求优先级进行排序。

落地的四步走：

请记住：一个失败的实时数仓项目，通常死于“需求不清”和“无人拍板”，而非“技术不牛”。责任到人，比技术选型更重要，如果你们还在争论“谁来做”，那么先选出一个“敢拍板”的人，这个问题就解决了一半。