一张图看懂数据行业六大岗位分工与技术栈

1. 这张图我贴在工位三年了：一张图看懂数据行业里谁在写SQL、谁在调参、谁在画PPT

刚入行那会儿，我在招聘网站上刷到“首席AI体验官”“数据炼金术士”“增长黑客工程师”这类头衔，真以为自己穿越进了科幻片片场。直到有天被拉进一个跨部门需求会，市场部说要“用数据驱动增长”，产品部说要“构建用户行为预测模型”，运维部说“你们的Spark任务把YARN队列压爆了”，而我坐在中间，手里的Jupyter Notebook还开着昨天没跑完的KMeans聚类——那一刻我才明白：不是岗位太多，是没人告诉你这些名字背后到底在干啥、用啥工具、扛什么锅。

这张《The Data Science Industry: Who Does What》信息图，我2021年第一次看到就存了下来，后来打印成A3尺寸贴在工位隔板上，边角都磨毛了。它不讲虚的“数据思维”“商业洞察”，而是像一份精准的岗位解剖图：左边列着6个核心角色（Data Scientist、Data Analyst、Data Engineer、Data Architect、ML Engineer、Statistician），中间画出他们在数据流水线上的位置（从原始日志采集→清洗存储→建模分析→可视化→上线监控），右边直接甩出三栏硬指标——常用技术栈、典型产出物、日常协作对象。比如你点开“Data Engineer”那一格，不会看到“负责数据基础设施建设”这种废话，而是写着：“每天处理5TB+日志；用Airflow调度200+任务流；和DBA抢服务器资源；给Data Scientist修Hive表分区；给Analyst搭自助BI看板”。这才是真实世界里的岗位说明书。

它解决的不是“数据科学有多火”这种媒体式提问，而是你打开招聘APP时最痛的问题：我数学一般但SQL很熟，该投哪个岗？我Python能写爬虫但没碰过Spark，离Data Engineer还有多远？我做过三年财务报表分析，转Data Analyst要补哪三门课？ 这张图的价值，就在于把模糊的“数据相关岗位”翻译成可测量、可对标、可拆解的动作单元。后面我会带着你一格一格拆开看，不讲概念，只讲每天8小时里，他们键盘敲什么、会议听什么、周报写什么、晋升答辩时被问什么。

2. 岗位设计逻辑：为什么不是“一个数据科学家包打天下”？

2.1 数据流水线的物理长度决定了分工必然性

很多人以为数据团队小，是因为公司规模小。错。真正决定团队结构的，是数据从产生到产生价值的物理路径长度。我们来算一笔账：

• 一家中型电商的日志系统每秒产生约12万条埋点数据（页面浏览、加购、支付）；
• 这些数据经Kafka流入Flink实时计算层，同时备份到HDFS做离线分析；
• Flink实时输出用户实时画像标签（如“30分钟内浏览3款iPhone且未下单”），写入Redis供推荐系统调用；
• HDFS上的原始日志经Hive SQL清洗后，生成ODS→DWD→DWS分层表，供分析师取数；
• 数据科学家基于DWS层表训练CTR预估模型，模型代码提交到GitLab，由ML Ops平台自动打包成Docker镜像；
• 镜像部署到Kubernetes集群，通过gRPC接口为APP首页Feed流提供千人千面排序服务；
• 整个链路涉及17个系统组件，平均单次请求跨7个服务节点，端到端延迟要求<200ms。

提示：当一条数据需要穿越17个系统、经历5种存储格式（JSON/Kafka、Parquet/HDFS、ORC/Hive、CSV/BI、Protobuf/gRPC）、被4类角色反复加工时，“一个人从埋点到上线”的神话就破产了。这不是人力问题，是物理定律——就像你不能让同一个厨师既养鸡、又杀鸡、又炒菜、又摆盘、又收银。

所以岗位分化本质是对抗数据熵增的工程策略：Data Engineer负责降低数据流动的摩擦力（建管道、保稳定、提速度），Data Scientist负责在低熵数据上提取高价值信号（建模型、验假设、解业务题），Data Analyst负责把信号翻译成业务语言（做看板、写归因、提建议）。三者像齿轮咬合，少一个，整个链条就打滑。

2.2 技能树的不可压缩性：为什么“全栈数据科学家”是招聘陷阱

常有人问：“学Python+SQL+机器学习，能不能通吃所有岗？” 我们用真实技能树对比来回答：

看到没？每个岗位的技能树都有不可压缩的底层知识模块。Analyst的CTE优化需要理解数据库执行计划，Engineer的Spark调优需要懂JVM内存模型，Scientist的特征工程需要掌握统计学中的无偏估