前言
数据工程师的主要职责是负责数据仓库的建设与维护，解决业务方用数需求。具体来讲，他们一周的工作内容是怎样的呢？本文以一次数据变量的建设与维护为例，记录如下故事。
一、背景介绍
李雷是一家银行的数据工程师，在数据信息部-数据整合组-零售集市项目组，零售集市的主要职责是负责零售业务条线应用系统的数据支撑，项目组共有2个人，1个行员和1个外包。
零售集市属于业务集市（数据服务）层，平行项目组有对公集市、风险集市、运营集市，分别负责公司业务条线、风险业务条线、运营条线应用系统数据支撑。零售集市的下行是公共整合层，上行是应用加工层的各个项目组。
组织架构图如下所示，零售集市所在位置用黑色方框标注。
二、数据需求提出
周一早上，李雷像往常一样来到公司，坐在工位上打开电脑后，回顾着当前需要处理的事情。几分钟后，他打开了【开发平台监控】小程序，输入工号和密码，查看零售集市项目组的任务运行情况，以确定项目组所有任务都已经运行成功。
正常情况下，如果有任务运行报错了，李雷手机会收到提醒，不需要每天自己去确认，但是在开发任务不繁忙时候，他偶尔也会主动打开看一看。
零售集市现在有52张模型，涉及指标3000多个，有的模型使用频率较高，被几十个场景依赖，有的使用频率低，只有一两个场景。
十点钟，李雷正在浏览项目组的数据模型，加深对数据印象，手机突然响了起来，他拿起一看，是零售CRM刘强打来的电话。
刘强也是一名数据工程师，主要职责是在报表开发平台上开发各种报表，直接满足业务人员的用数需求。
电话接通后，听筒里传来刘强的声音：喂，李雷，代发的业务周慧提了个需求，想要开发2张报表，我看过文档了，涉及指标比较多。我约了周慧下午两点半见面聊，到时候一起去吧，确定下分工。
李雷听完，已经明白了是什么事情，边回想下午时间是否冲突，边说道：下午两点半，可以。出发的时候你叫我，我们一起过去？
刘强说道：好，到时候我叫你。
三、需求沟通
下午两点半，李雷和刘强找到周慧，在一个相对安静的长条桌子旁坐下。周慧打开电脑，操作着一个excel文件，说道：“上周五领导开会，确定了一季度分行零售主线考评指标，我们这次主要聊代发客户相关的。”
代发客户，主要是指在银行开立银行卡，用来让公司发放了工资的客户。此外也可以是因为拆迁、生育补贴等原因，由政府或其他企业，通过银行卡给个人支付了资金的客户。
周慧打开excel表格，看到正常显示了后，开始说自己的用数需求：“这次细化了对代发客户的考核，需要知道每家分行的本年在代发客户数、本年有效代发客户数、新增代发客户数、挽回代发客户数、流失代发客户数，以及这些客户的AUM余额、AUM留存率，当年代发金额，以及这些指标的较上年变化数。”
说完第一个excel表格的内容后，周慧将其缩放到一旁，放大了另一个表格，继续说道：“此外还需要客户级的明细数据，需要知道每个代发客户的代发单位、绩效归属机构、本年代发总金额、本年代发总次数、本年代发月数、代发类型，以及定期余额、理财余额、贷款余额、是否持有信用卡......”
在周慧讲述业务需求的同时，李雷和刘强看着电脑屏幕，一边听周慧讲解，一边理解着各个指标的定义。
几分钟后，周慧讲完了整个excel表的需求，看向刘强和李雷说道：“最终需要开发两个报表，一个是机构的汇总数据，一个是客户级明细数据。”
“这两个报表的参数都有哪些？比如数据日期，机构，还需要有别的么？”刘强看到周慧说完了，随口提出问题。
周慧听了看看电脑，说道：“需要有数据日期和机构参数，并对机构进行权限管控。对于机构的汇总报表，再提供一个代发客群参数，选项是【全口径代发、本年在代发、本年有效代发】。客户表额外提供是否本年在代发参数，选项是【是、否】，默认为空，代表全部。”
“写到excel上吧，待会儿全部确定后重新给我发下这个文件。”刘强听了周慧的补充后说道，然后继续看向文档，思虑还有哪些不明确的地方。
一旁的李雷也在盯着电脑屏幕上的excel文件，仔细看每个指标后面的解释说明。
有效代发客户：最近3个月代发次数大于等于1次的客户；
是否近3月连续代发户：最近3个月代发月数大于等于应发月数；
是否近3月连续代发达标户： 最近3个月代发月数大于等于应发月数，且月均发薪金额大于等于1000元；
是否流失挽回客户：首次发薪日期在去年6月30日之前，自上年7月份至上年年末在我行未发生过发薪交易，在本年重新发生发薪交易。
······
蓦地，李雷看到一个指标没有解释说明，单看字面意思也无法确认是什么意思，开口问道，“代发类型是什么意思？我记得现在已经有了代发行业类型，枚举值是农业、林业、制造业、建筑业之类，这两个指标有什么关系么？”
周慧想了一下，说道：“这里的代发类型是指常规代发、拆迁代发、企业代发、优质-财政代发等，和已有的代发行业类型不一样。”
“那我们能换名字吗，代发类型这个名称有点笼统，换一个更具体点的。”
“可以。换成，代发单位类型，怎么样？”周慧说道。
“行，也在文档中写下吧，列举几个枚举值作为提示。”李雷说道，并继续问，“这个数据你在哪个系统中看到过么？”
“在中间业务系统有记录，我们和代发单位签订协议的时候，记录了单位的类型。”周慧说道。
李雷听了，说道：“好，我回去后看下这个系统的数据。”
四、指标分析及分层建模
随着对一个个指标的再次查看，李雷和刘强确定了excel表中每个指标的定义，以及最终的报表展示形式。当所有业务需求都明确了后，两人就开始了数据开发工作的内部分工。
这次需求主要涉及了代发客户专有标签、客户资产标签，以及客户持有产品三部分数据，此外还有些零散的标签数据。对于客户资产和持有产品主题数据，零售集市的其他模型中已有现成指标，不需要重复加工，刘强直接拿走使用即可。对于代发客户标签数据，考虑到以后很有可能其他项目组也需要使用，因此仍然由零售集市加工，把结果数据分别落在原有的代发客户信息表和代发单位信息表中，等零售集市加工好后，刘强开发CRM报表时直接引用，不再自己重复加工逻辑。
因为此次报表同时展示了多主题的数据，为了提高业务使用报表时的查询速度，并方便后期管理，刘强修改了底层逻辑，取消了原本的在查询时通过多表关联计算显示的方法，修改为提前进行预加工，将所有数据事先汇总在一个物理模型中，查询时直接查询单表得出结果。
五、新建项目流程及代码开发
和周慧聊完需求，再和刘强做了分工后，李雷回到工位，打开原效DevOps平台，开始了需求立项流程。
找到月初已经创建好的需求，新建【用户故事】，输入需求名称<代发客户指标开发>，填写需求描述、开发项目组、开发人员、计划上线时间、涉及系统名称等要求的内容。
一个个资料填写、提交着，等到走好立项流程，已经是4点半。填写完流程后，李雷打开通讯录，找到刘强发来最新需求文件，开始一个个指标的检查、标记。
刘强发给李雷的需求文件，与周慧发给自己的不同，根据周慧的需求清单，刘强做了二次梳理，进一步分析出了具体哪些指标是需要李雷加工的，哪些是现有可以取到的。
“AUM留存率=（当前AUM余额-上年末AUM余额）/本年发薪总额。依赖的三个子指标有现成的，只需要根据口径计算即可。AUM留存率同时有代发数据和资产数据，但是更偏向于代发，只有代发客户才有这个标签，所以先归类在代发客户信息表中。”
“代发单位类型，周慧说在中间业务系统有记录，所以先去查公共数据明细层的中间业务表，看看具体是哪个指标记录的，枚举值是否符合周慧的期望。”
“是否流失挽回客户，计算口径稍微复杂，需要先看下已的有代码，再决定取数逻辑。”
李雷看着excel表格中需要自己加工的数据，一边做指标的主题划分，一边分析取数口径。当所有数据全部查看了后，李雷打开<数据资产平台>，输入<中间业务>关键字，开始查找与中间业务相关的数据表，通过浏览表的描述初步判断是否可能为需要的依赖表。
“中间业务产品信息表，会是这个表么？看看数据。”
李雷找到一个描述接近的表，点击查看着详情，并找到了一个可能是单位类型的字段，反复查看了几遍后，他打开<数据开发平台>，开始编写代码验证数据。
-- 浏览数据内容select *from gds_it.d_prd_midl_prdu_infolimit 10;-- 确定枚举值是否符合期望select unit_type,count(1)from gds_it.d_prd_midl_prdu_infogroup by 1;
李雷初步看了数据后，发现该表的unit_type字段存储有【常规】字样内容，是期望内的数据，就对该字段进行了去重查看，确定其枚举值是否符合业务要求。
而电脑屏幕上显示的结果，明明白白的告诉着是有异常的。
“奇怪，怎么只有常规、拆迁、优质企业几个，优质-财政呢？”李雷看着数据，发现了明显的异常点。
根据周慧所说，企业类型应该有“优质-财政”，李雷进行去重查看的时候，是面向整表全量数据，所以如果这张表是期望的依赖表，虽然不确定企业类型到底有哪些标签，但至少要有“优质-财政”。
“不是这个表么？还是说不是这个字段？”带着疑问，李雷再次执行了查看明细数据的代码，开始猜想是不是应该取其他指标。但仔细查看了多遍后，他确定其他指标均不符合要求。
寻找依赖表以及确定读取逻辑是数据加工中耗时差异非常大的一个过程，如果运气好，只需要十几分钟就能确定结果，如果运气不好，这个时间就可能要花费几十分钟甚至几个小时。
李雷在中间业务产品信息表中没有看到期望的数据，只得再次浏览<数据资产平台>，重复以上验证过程。但直到30分钟过去了，他也没有找到期望的数据。根据经验，他知道自己不能再这样排查下去，是时候找数据明细层DWD的同事询问了。
李雷找到DWD的同事张磊，说明了需求，张磊听后说道：“代发单位的类型就是在中间业务产品表里存着的，只是优质财政比较特殊，存储在了另一张表，取得时候不需要判断单位类型，只要是那个表中存储的都属于优质-财政。我现在有点忙，晚点发你表名。”
“好，那你先忙，过后发我就行。”
李雷听了张磊的答复，不再继续查找代发类型的事情，开始做其他工作。
第二天，李雷顺利地把所有依赖表和字段都确定了下来，便开始了正式的代码编写阶段。
代码开发的过程中，他也遇到了些其他事情，比如A同事打电话询问某某指标的业务含义是什么，B报表的客户数和C报表的客户数为什么不一致，亦或是临时查询一个数据，等等问题。
遇到比较紧急，或是预期几分钟内就能解决的问题，他就先停下手中开发工作。遇到不紧急的，他就在了解完对方需求后先记录下来，记录好排期。
周三下午，李雷完成了<代发客户表>的代码开发以及SIT测试，测试通过后，他打开在线文档<20250926上线步骤>excel，开始整理上线文档。
当涉及了多项变更时，为了提高上线的效率，保证上线正常，有必要把将要在生产系统进行的操作提前以书面方式记录下来，以防止出错。
六、版本变更日，进行生产变动
周五、周六是规定的上线变更时间，简称版本日。当一个需求涉及了系统开发时，一般需要在版本日集中进行，以防止发生生产事件。当系统重要等级比较时，还会进一步要求在周五晚上或者周六才能变更。
李雷所在项目组主要是涉及数据变更，重要性适中，一般在周五下午即可开始。
周五下午两点半，李雷拿着<上线步骤>和<变更调度单>，经过身份验证后，使用指定的电脑，并经过层层安全监控后，开始进行本次的数据代码变动，并在变动后经过刘强的数据验证，正式完成了本次业务需求中李雷负责的部分。
小结
本文旨在通过讲故事的方法，将数据工程师的日常工作记录下来，期望是在保留关键节点的基础上尽量减少琐碎感。