前段时间刷到一个帖子楼主自己是做数据工程的说AI让数据工程这行发生了不少变化模型对数据挑食脏数据和非结构化数据得单独处理数据本身更乱也更难管以前对付的是一条狼现在是一头虎业务方胃口也大了动不动就要实时、要流式。评论区聊得更热闹有人说自己本来做分析现在被迫把工程和建模的活也接了过来有人反问这不就是分析工程师吗还有人说研发早就顺手把数据科学的工作干完了数据团队反过来也在碰研发的东西。这些说法各自都有道理凑在一起容易让人得出一个吓人的结论以后做数据的人都得十项全能。我不太同意这个结论但也不想简单否定它。比较靠谱的说法应该是——AI确实把不同数据岗位之间的墙拆薄了但拆薄墙和把整栋房子改成一间大通铺是两件完全不同的事。想把职业规划这件事想清楚得先把数据工作到底在解决什么问题、AI具体改变了哪一段、没改变哪一段,一层一层拆开看。数据工作不是几个岗位名字是一条完整的链路很多人理解数据岗位,习惯直接从DA、DE、DS这几个缩写下手。这个分类不是没用,但也埋了不少误解。因为公司需要的从来不是设置三个岗位,而是让业务问题经过一连串处理,最后变成一个能用的答案或者能跑的系统。拿一个很常见的问题举例:某电商公司想搞清楚,最近新客户的首单转化率为什么掉了。这个问题一开始压根不是技术问题。得先定义清楚,什么叫新客户——第一次注册的、第一次访问的,还是第一次下单的?转化率的分母到底是谁?退款算不算成功转化?一个人用手机和电脑分别访问,算不算同一个用户?这堆问题没想明白,后面技术做得越快,错得反而越整齐。想清楚以后,数据才轮到从App、网站、支付系统、订单系统流进数据平台。有人负责保证事件不丢、字段含义稳定;有人把原始记录整理成能查询的模型;有人分析转化率下降到底是哪个渠道拖的后腿;要是还想预测哪些用户会流失,后面还得建模、验证、上线、盯着效果。同一个业务问题,可能牵扯埋点、数据管道、数仓建模、指标口径、实验设计、统计推断、机器学习,还有怎么把结论讲明白让运营听得懂。不同岗位的区别,不在于用什么工具,而在于谁对哪一段结果负责。分析师通常对问题拆解和决策建议负责;工程师对数据获取、加工、稳定性负责;数据科学家对预测和模型效果负责;分析工程师专门把原始数据和业务分析之间那层可复用的模型建好。公司小的时候一个人能包好几段,公司大了分工就会细很多。岗位名字可以当参考,真正管用的是搞清楚谁对什么结果担责。AI到底降低了哪种门槛以前一个分析师想把每天手动导出的表格,变成自动更新的数据集,常常卡在写脚本、配调度、连接口这些事上。现在有AI帮忙写Python、解释报错、生成基础SQL,至少能先把原型做出来。这是真的变化,没必要否认。但数据工作里有几种不同性质的门槛,AI主要降低的只是其中一部分。第一种是语法门槛,不会写某段代码、记不住某个函数——这一层AI帮助很大。第二种是实现门槛,知道要做什么,但不清楚怎么把系统连起来、怎么处理各种异常情况——AI也能帮不少忙,尤其是常见场景。第三种是判断门槛:这个业务问题该不该这样定义,这份数据能不能用,结果靠不靠谱,方案划不划算。AI能给建议,但拍板的责任还是落在人身上。第四种是组织门槛:谁有权限动这份数据,哪个团队该负责修上游那个字段,指标打架了谁说了算。这些事往往比写代码慢得多,也不会因为模型能生成代码就自动解决。前两种门槛降下来以后,后两种反而会更显眼。原来一个需求可能因为没人会写而做不出来,现在一天能做出三个版本。版本一多,就需要有人判断哪个能上线、错了会造成什么后果、以后谁来维护。业务方看工具变强了,自然会想:那能不能更快点、能不能实时、能不能把文档和图片也塞进去分析?工具省下来的时间,经常很快被更复杂的需求重新占满。数据挑食具体挑的是什么那句AI模型挑食听着口语,背后是实打实的技术问题。传统数据系统处理的大多是结构化数据,订单表里有订单号、金额、时间,字段脏但至少长得像表。现在企业想用的材料扩展到合同、邮件、客服对话、产品说明书、图片、音频,这些东西没法用几列字段表达,得经过解析、切分、识别、标注、索引才能变得可用。比如想做一个能回答公司报销制度的内部助手,表面看是上传几份PDF接个大模型,真做起来问题一个接一个:扫描版PDF能不能准确识别?表格解析后有没有错位?新旧两个版本的制度,该用哪个?切分文档时会不会把上下文拆散,导致答案漏了适用条件?答案引用的段落,用户到底有没有权限看?这些不是换个更强的模型就能解决的,而是依赖输入材料的质量、上下文怎么组织、有没有评估机制。数据工程的工作因此在往外扩:原来是把数据库记录搬进仓库,现在还得处理文件解析、权限、索引、版本管理。分析工作也在变:过去盯着数值指标,现在可能要从成千上万条客户反馈里提炼主题,还得验证这些主题是不是真代表客户,而不是模型自己编出来的故事。不过也别把非结构化数据神化。不是每家公司都需要一整套复杂的AI数据平台,一份短小、更新不频繁的制度,普通搜索甚至人工维护的知识库可能更靠得住。技术选型先看问题规模、更新频率、权限复杂度和出错代价,不是看哪个名词最热。数据变脏、变不可控,不是抱怨,是设计起点以前对付数据像驯服一条狼,现在像应付一头虎——这个比喻夸张了点,方向是对的。企业数据越来越多来自不同系统、不同团队,而且大多是为业务流程而生,不是为了分析而设计。拿到一个叫status的字段,不一定知道它是订单状态还是接口调用状态;拿到一个时间戳,也不一定知道是事件发生时间还是入库时间。数据脏具体拆开看,无非是这几类问题:缺失,关键字段没值;重复,接口重试导致同一笔支付记两遍;格式不统一,国家字段一会儿写代码一会儿写全称;口径漂移,字段名没变但产品改版后含义变了;延迟,昨天的数据今天早上还没到齐;关联失败,两张表用了不同的标识体系;异常值,金额突然变成负数,可能是退款也可能是系统故障。这些问题如果只靠清洗一下糊弄过去,很容易把错误藏起来。金额为负,是过滤掉还是标记成退款?这没有统一答案,得结合业务规则,还要把原始值、转换规则、处理理由都记下来,方便后面的人复核。这正是数据工程师和资深分析师的核心竞争力——不是把表弄整齐,而是把不确定性暴露出来,再设计机制把它的影响限制住。会写SQL不等于能做分析SQL是数据岗位的重要基础,但会写SELECT和JOIN,离靠得住的分析还差着几层。最常见的坑不是语法错,是粒度错。订单表一行代表一个订单,订单明细表一行代表一个商品,两张表直接关联后算金额,含多个商品的订单会出现多行,金额被重复累加。SQL跑得通,还有数字,但错得悄无声息。写SQL之前最好先问自己几个问题:这张表一行代表什么,想要的结果一行又代表什么,关联的键在两边唯一吗,过滤条件是在聚合前还是聚合后发生的?这些没想明白,AI生成的SQL写得越流畅,风险越大。拿七日留存这个常见指标说,直觉上是某天来的用户,七天后还有多少回来,但真正写代码之前得先定义清楚:来指注册、激活还是首次打开;“七天后是第七个自然日还是满168小时;跨时区怎么算。两个团队各自算出的七日留存对不上,往往不是谁写错了代码,而是从一开始就没用同一个定义。想从会取数走到能独立负责分析”,要练三件事:把业务问题翻译成可计算的定义;知道表的生成机制,能看出隐藏的错误;解释结果时清楚它能说明什么、不能说明什么。分析工程师到底在干什么Analytics Engineer这个岗位,不是更高级的分析师也不是简化版的工程师。它常出现在数据平台已经搭好、但业务分析还很混乱的公司里——上游把订单、支付数据送进仓库,分析师却发现每个人都在重复写清洗逻辑,同一个指标好几种算法,新同事不敢用旧表。拿客户收入分析举例,原始系统里有合同、发票、付款、退款、汇率数据。分析师各写各的SQL,有人按开票金额算,有人按实收金额算,有人忘了扣退款。分析工程师会去和财务业务对齐口径,再把原始表逐层转换,先统一主键,再处理币种和退款,最后生成一个大家都能共用的收入模型,还要配上测试和文档。这样分析师不用每次都从原始表重做,工程师也不用为每份报表单独写脚本。常见的技术组合是Snowflake加dbt,前者是云数据平台,后者是围绕SQL转换建立工程化流程的工具,能管理模型依赖、测试和文档。但会用dbt不等于会做分析工程,工具教你怎么组织转换,不能替你决定收入到底怎么定义。适不适合走这条路,看你痛苦的来源:如果你受不了每次分析都要手动修数据、重写公共逻辑,而且愿意花时间把混乱口径变成可靠模型,可以考虑;如果你更喜欢做实验设计、跟运营讨论策略,不必强迫自己转。存储位置能不能当岗位分界线有种说法是,现在很多工作以S3、ADLS、GCS这类云存储所在的位置划界,前面归管道工程师,后面归分析工程师。这个视角能帮理解,但当不了行业标准。S3、ADLS、GCS分别是亚马逊、微软Azure和Google Cloud的对象存储服务,企业常把日志、导出数据、文档统一放进去,再从这里进入数仓或湖仓平台。把原始数据怎么稳定进平台看成管道工程,把进平台后怎么变成可用模型看成分析工程,这个划分在不少场景合理,但现实没那么整齐。有的公司数据直接同步进仓库,有的分析工程师也要负责采集,有的团队用流式系统根本不把对象存储当交接点。这种划分真正的价值,是提醒自己:数据进得来和数据用得好,是两个不同问题,都得有人管。求职时别只盯岗位名。同样叫Data Engineer的岗位,有的主要做数据库同步和调度,有的大部分时间在写SQL模型,有的重点是处理日志吞吐和服务稳定性。看招聘描述里反复出现的动词——采集、建模、治理、部署、监控,哪个占比最高,比纠结职位名有用得多。老板要实时,先问清楚到底多快“以前每天出一次报表,现在能不能实时看到”——这种要求越来越常见。开发变快以后,业务方更容易把能不能做变成能不能现在做。但实时不是一个开关,是一组要花成本的选择。批处理按固定间隔处理一批数据,流式处理是数据来了就持续处理,近实时可能是几分钟更新一次。管理层看月度趋势,每天更新通常够用;反欺诈、异常交易拦截,几秒延迟可能真有业务价值。判断值不值得实时化,可以问四个问题:决策窗口有多短,数据源本身有多快,错误代价有多高,愿意为此付多少成本。一个成熟的方案,经常是同时提供快但暂定的实时口径和慢但准的日终口径,而不是硬逼着两者时刻一致。流式处理里还有几个绕不开的细节:事件的发生时间和系统收到时间可能不同,手机离线后补传会导致数据晚到,网络重试可能带来重复消息,不同来源的事件可能乱序。这些问题没有答案,只搭一个流式框架,离真正可靠还很远。对普通分析师来说,理解实时指标为什么会变动就有价值;对核心交易系统的工程师来说,得深入研究这些细节。学习深度该由目标岗位决定,不是看什么词最流行。真正区分工程水平的,是第九十天的故障,不是第一天的演示数据项目演示往往很好看,脚本跑通了,图出来了。但企业付钱不是买演示,是买长期能用。一条任务每天凌晨跑,九十天里总会遇到上游改字段、接口限流、数据延迟、重复投递。系统怎么应对,才是工程能力真正的体现。一条可靠的管道,得做到可观察、可重试、可回放、可追溯。可观察是知道任务成功没有、处理了多少数据;可重试是失败后再跑一次不会写重复;可回放是规则改了能重新处理历史数据;可追溯是发现数字有问题能找到原始记录和转换步骤。很多团队只做了失败了发个消息,却没记录数据量指标,结果任务天天显示成功,表里的订单却少了一半。数据测试不能只停在字段不为空。比较实用的检查至少包括主键唯一性、字段值域是否合理、关联关系是否完整、数据量和历史相比有没有突变、某些业务恒等式是否成立。文档同样不是走形式,一个能交接的数据集,至少得让接手的人搞清楚一行代表什么、主键是什么、哪些字段可靠、出问题该找谁。这些事很花时间,也不如做一个炫目的演示显眼,但决定了团队能不能在人员流动后正常运转。用大模型清洗数据,先分清有用和允许大语言模型确实能帮忙处理地址、公司名、客服文本这类模糊数据,但能不能把数据发给某个模型服务,是权限和合规问题,不是好不好用的问题。不要因为自己能访问数据,就默认自己有权把它发出去。客户姓名、交易记录、内部合同都可能涉及保密义务,即便服务商说不拿输入训练模型,也得先确认公司的安全和法务要求。技术上,用模型清洗数据也不能只看几条成功样例。比如把十万条商品标题映射到标准类目,模型可能把边界商品每次归到不同类目。稳妥的做法是先建立明确的类目定义和少量标注样本,要求模型输出固定结构,记录原始输入和结果,对低置信度样本做人工复核。规则能搞定的事,优先用确定性方法解决,让模型去处理规则覆盖不到的模糊部分。RAG能给数据岗位提供什么切入点很多企业现在在做检索增强生成,思路是先从公司资料里找出相关内容,再让模型基于这些内容回答。很多项目失败不是模型不够强,是数据准备和评估没做好。资料进系统前要知道它来自哪里、谁维护、多久更新一次;解析时不能把关键条件拆到另一段;检索时要保证用户只能搜到自己有权限看的内容;回答最好给出处,方便核对。最容易被忽略的是评估。演示时问一个简单问题答对了,不代表系统真的可用。得构建一组覆盖真实场景的问题:资料里明确有答案的、需要合并多份文档的、本该拒答的、新旧版本冲突的,分别测检索找对了没有、回答有没有忠实引用材料。这些环节都和数据工程、治理、评估相关,是个值得关注的成长方向,但别简单理解成学个向量数据库就能转AI工程师。分析师往哪走,工程师往哪走做分析的人容易一看到岗位交叉就焦虑,觉得该马上去学分布式计算和机器学习。先别急。分析师最该守住的,始终是把业务问题变成可靠判断的能力。这事听着不如会搭平台硬核,但企业里真的稀缺。很多报表没人看,不是SQL太慢,是没人先问清楚这份报表到底用来决定什么。想往相邻岗位扩展,可以先补三块:数据建模,知道什么时候该先统一粒度再聚合;自动化和质量检查,别再手动复制粘贴;实验和推断,分清相关和因果,理解随机分组、样本量这些常见陷阱。是不是要转Analytics Engineer,看你更喜欢哪种问题——喜欢讨论用户为什么流失就继续做分析,喜欢把重复的脏SQL整理成可靠模型就往工程走,不用把转岗当升级。数据工程师这边,如果工作长期停留在接需求、写个同步任务、报错了手动重跑,确实容易被平台化和AI进步挤压。但更复杂的问题反而会因为数据源增多而变得更重要:可靠性怎么保证,建模怎么服务下游,性能和成本怎么权衡,安全治理怎么落地。做中小企业平台的工程师,可能最该把数仓模型和任务监控做扎实;做大型交易系统的,得深入乱序和状态管理。资深工程师越往上走,越需要能解释取舍——为什么这里选批处理不选流式,为什么这里保留原始数据不直接覆盖。能把技术成本和业务收益放到同一张桌子上讨论,才算接近架构能力。数据科学家和算法这块,不同公司叫法差异很大,有的偏统计实验,有的偏建模,有的接近纯研发。但不管偏哪种,建模变容易了,证明方法有效、上线后持续管用还是很难。拿用户流失预测举例,定义流失、确定预测时点、避免数据泄漏,每一步都比调参重要得多。上线以后还要看特征是否按时到达、预测质量有没有下降、策略是否真的提升了留存,而不只是接口跑得通。全栈听着强,但先搞清楚自己在哪种公司全栈这个词最容易误导新人。它可能是一个人能覆盖从接入到展示的完整流程,也可能只是团队人少,啥杂事都归你。前者能培养完整视角,后者容易让人每天救火,没时间在任何方向扎下去。判断一个岗位是不是好机会,不能只看涉及的技术多不多。小公司容易让人接触全貌,推进快,但缺规范和资深同事指导,很多错误没人指出;大公司分工细,能见到高标准的工程实践,但可能很久都不知道自己那一小段工作最终解决了什么问题。比较健康的能力结构,是一根主梁加几根能连上下游的横梁——以分析为主的懂点建模和自动化,以工程为主的懂点指标怎么被消费,以算法为主的懂点数据质量和上线链路。判断自己有没有主梁,可以问一个直接的问题:项目出了严重问题,团队会不会觉得这类问题该找你?答案一直是否定的,说明还没建立起明确的专业信用,下一步不是再多学几个工具,而是选定一类结果,从需求到交付负一次完整责任。找工作别拿技术栈相似当岗位相同同一个职位名在不同地区、行业、公司阶段可能对应完全不同的工作。看招聘信息不妨拆成三层:第一层是交付物,最终交的是可靠数据集、业务分析,还是可运行的平台;第二层是日常工作,是天天开会定义指标,还是处理生产事故;第三层才是工具,说明公司现在怎么做事,但不完全定义岗位本身。只按工具投简历,很容易出现都会一点,但对方最需要的那部分你没证明的问题。转岗时也别把现有经历清零。分析师想转分析工程,不用说自己从零学起,可以先梳理自己是否做过公共指标层、复杂SQL的复用。招聘方关心的是能不能解决新岗位的问题,不是过去职位名称是否刚好一样。做一个真正有分量的项目无论是在校生还是想换方向的人,常卡在同一个问题:知道要做项目,不知道怎么做出跟教程不一样的东西。数据领域的项目不需要海量数据,真正有说服力的,是它暴露并解决了实际问题。拿一份公开的电商订单数据,假设要给业务团队做新客首单与复购分析。别急着画图,先写指标定义:首次购买以什么为准,退款怎么处理,复购窗口多长。再检查原始数据:订单ID有没有重复,时间字段一致不一致,订单明细会不会造成重复累加。接着设计中间层,把原始数据清洗整理成稳定的模型,最后才生成指标和报告,还要指出结果对哪些假设敏感。展示项目时别只放最终截图,让人看见你的决策过程:为什么选这个粒度,测试发现过什么错误,修复后指标变化了多少,还有哪些局限。面试官通常不缺照教程走一遍的人,更想知道你遇到不顺利的情况会怎么处理。一个九十天计划,先选方向再补短板很多规划文章喜欢列一长串技能树,看完只会更焦虑。九十天能有明显进展,前提是聚焦。第一步不是报课,是选一个目标——强化分析、转分析工程、深耕数据工程,还是走AI数据方向。方向以后可以改,但这一轮学习最好只盯一个。第一个月校准目标和基础,找十几份想投的岗位,归纳反复出现的要求,选一个项目题目写清楚需求。第二个月做出能跑的版本,记录每个卡住你的问题,尤其是数据定义和异常处理。第三个月把项目做成能交付的作品,补测试文档,模拟一次需求变更,再写一份短报告说清楚问题、方案、验证方式和局限。九十天结束时,你不一定拿到offer,但会有一件更重要的事——不再只是说我对这个方向感兴趣,而是有一套自己做过、验证过、知道不足在哪的工作。面试时怎么证明不是AI帮你做的现在AI是日常工具,面试官对流畅代码的信任度反而可能下降,会追问关键决定是不是你自己做的。讲项目时按问题—约束—选择—验证—结果来讲,而不是按我用了什么技术来讲。别只说我用dbt建了几个模型,要说清楚业务想看什么、数据有什么坑、你怎么固定粒度、怎么发现并处理了延迟问题。工具不是主角,错误识别和方案取舍才是。如果确实用了AI,可以说清楚它帮你完成了什么,更要说清楚你怎么验证的——对照文档、小样本手工计算、注入异常数据测边界。真正让人放心的不是我没用AI,而是我用了,但我知道它可能错在哪,也知道怎么发现。几句不好听但得承认的话学习更多不保证收入更高,市场按供需、责任范围、可替代性定价,不是按你掌握的工具数量。跨界不等于免费接所有活,一个人开始做本不属于自己的工作可以是成长机会,也可能是团队把责任压给了一个人,接活之前最好问清权限和评价标准。技术能力和行业知识不是二选一,同样一张退款表,在不同行业含义和合规要求完全不同,工具越容易用,真正理解业务机制的人越能发现看起来合理的错误。会沟通也不是客套话,你发现一个核心指标算错了要让各方同意改口径,这事说不清楚,技术再好也落不了地。最后分析师开始碰工程,工程师开始碰分析,研发顺手把一部分数据科学的工作也干了——这些都是真的在发生。但这不该被简单归纳成以后每个人都得十项全能。更接近事实的变化是,岗位之间交接的墙矮了,工作结果之间谁该负责却更需要讲清楚。对个人来说,比较稳妥的规划不是看到什么热就学什么,而是找一类自己愿意长期处理、市场也愿意付费的问题——可以是能把模糊需求变成可信判断的分析师,可以是能把混乱数据变成公共资产的工程师,可以是能把模型效果和业务收益真正接起来的数据科学家。再往外扩一两步,理解相邻环节,学会借助工具提速。先把一件重要的事做扎实,再学会把它和前后两件事接起来,这事比什么都会更可执行,也更经得住岗位变化的折腾。