数仓的哲与思：为什么有业务思考的同学会更能脱颖而出？

最新推荐文章于 2025-08-08 16:39:17 发布

原创最新推荐文章于 2025-08-08 16:39:17 发布 · 1.8k 阅读

48 ·

CC 4.0 BY-SA版权

文章标签：

#数据仓库 #职场和发展 #面试 #大数据 #sql

收获不止一点专栏收录该内容

125 篇文章

订阅专栏

你有没有过这样的经历？熬了几晚优化的ETL任务，业务方看了结果却说“这数据没用”；精心设计的维度模型，运营同学用的时候总说“找不到想要的指标”；甚至有时候，你做了一堆报表，却不知道这些数据最终帮业务解决了什么问题？

我做数仓的这些年，踩过最疼的坑，就是把“技术能力”当成了数仓的全部——直到后来跟业务方聊多了，才明白：数仓的本质，是“用数据解决业务问题”，而不是“用技术存储数据”。

犹记得在上一家公司我刚用Flink做完实时库存预警，仓储主管看了一眼数据就摇头：“你这‘库存低于10件’的预警有什么用？生鲜的库存要算‘可售时长’，比如三文鱼只能放24小时，剩5件但还有10小时过期，根本不用补！”。从那时我才明白：我们和业务方的矛盾，从来不是“需求表述不清”，而是“我站在技术的逻辑里看数据，而他们站在业务的逻辑里要结果”。

数仓的世界里，我们总在谈“维度建模”，“ETL优化”，“实时计算”，但很少有人问：这些技术的“根”在哪里？

答案其实很简单——业务的真实发生。

一、数仓的本质：不是存储数据，而是存储“业务故事”

我刚做数仓时，曾把“建表数量”当成KPI。用了半年时间，把公司的ERP、CRM、APP日志全同步到MaxCompute，建了200多张表，沾沾自喜地跟领导说“数据全打通了”。直到有天财务同学来找我：“能帮我算一下‘线上订单的物流成本分摊’吗？”我翻了半小时表，发现“订单表”里只有“物流单号”，没有“物流成本”；“物流表”里有“成本”，但没有“订单对应的商品重量”——两个表根本关联不起来。

那天我坐在会议室里，看着财务同学手里的“成本分摊公式”（物流成本=重量×单价+首重费用），突然意识到：数仓不是“数据的仓库”，而是“业务故事的仓库”。

什么是“业务故事”？

是用户从“点击商品详情页”到“支付成功”的每一步选择；
是生鲜从“供应商冷链发货”到“用户自提”的每一次温度变化；
是订单从“生成”到“完成”的每一笔成本分摊逻辑。

而我们建的表、写的SQL，本质上是用数据“还原”这些故事。如果不懂“物流成本分摊”的业务逻辑，就算把“订单表”和“物流表”同步到云里，也只是两个孤立的“数据碎片”，拼不出完整的故事。

二、业务思考：不是“懂业务”，而是“学会用业务的眼睛看数据”

很多人觉得“数仓同学要懂业务”，就是“去学业务术语”“记业务流程”——这其实是误解。业务思考的核心，是“切换视角”：从“我要怎么处理数据”，变成“业务方要怎么用数据解决问题”。

去年做某零售品牌的“用户分层模型”时，我一开始按“RFM模型”（最近购买时间、购买频率、购买金额）分了“高价值用户”“潜在价值用户”“流失用户”三类。结果运营同学用的时候说：“这个分层没用——我们的高价值用户里，有一半是买过一次奢侈品的新用户，根本不会复购；而那些每月买两次美妆的老用户，反而被归到‘潜在价值’里！”

我当时很困惑：“RFM是经典模型啊？”直到运营同学带我去线下门店转了一圈，我才明白：零售的“高价值用户”，不是“花得多”，而是“能持续复购”——对于卖美妆的品牌来说，“每月买两次面膜的老用户”，比“买一次奢侈品的新用户”更有价值，因为她们的“生命周期价值（LTV）”更高。

后来我重新设计模型时，加了两个业务维度：

品类偏好（是否常买高频复购的美妆）；
会员等级（是否是连续3个月的付费会员）。

结果运营同学用这个模型做了“美妆老用户专属优惠券”活动，复购率提升了23%——她跟我说：“你终于懂我们要什么了。”

业务思考不是“让你变成业务专家”，而是“让你学会用业务的逻辑翻译数据”：

当运营说“要提升复购”，你要想的不是“怎么算复购率”，而是“复购的业务驱动因素是什么？是产品没满足需求，还是触达不到位？”；
当财务说“要算成本分摊”，你要想的不是“怎么关联两张表”，而是“成本的业务逻辑是什么？是按重量摊，还是按订单金额摊？”；
当仓储说“要实时库存预警”，你要想的不是“怎么用Flink做实时计算”，而是“库存的业务风险是什么？是缺货，还是过期？”。

三、没有业务思考的数仓：是能跑任务的机器，不是能创造价值的系统

我见过很多数仓同学的日常：

每天花80%的时间调优ETL任务，确保“数据准时产出”；
为了“模型的规范性”，坚持用“第三范式”建表，不管业务方用不用得着；
输出的报表里全是“用户数”“订单量”这样的“通用指标”，从来不说“这些数对业务有什么用”。

这样的数仓，本质上是“能跑任务的机器”——它能准确、准时地产出数据，但永远不会创造价值，因为它“不懂业务的需求”。

去年我帮某外卖平台做“实时配送超时预警”时，一开始用Flink做了“订单生成30分钟未送达”的预警。结果配送主管看了一天就关掉了：“你这预警里，有一半是‘用户地址填错’的订单，我们根本没法处理；而那些‘商家出餐慢’的订单，反而没预警！”

我当时很委屈：“我是按你说的‘超时30分钟’做的啊！”直到配送主管带我跟了一次晚高峰配送，我才看到：

有些订单超时，是因为用户把“1栋3单元”写成了“3栋1单元”，骑手找了20分钟；
有些订单超时，是因为商家做奶茶用了25分钟，骑手到店等了15分钟；
还有些订单超时，是因为晚高峰堵车，骑手根本没办法。

这些“超时的原因”，在我的实时任务里根本没有——我只算了“订单生成到送达的时间”，却没关联“商家出餐时间”“用户地址准确性”“路况数据”这些业务维度。

后来我重新调整了预警逻辑：

关联商家出餐时间：如果商家出餐超过15分钟，提前5分钟给骑手发“出餐慢预警”；
关联用户地址数据：如果地址填写不完整（比如没写单元号），提前10分钟给用户发“确认地址提醒”；
关联实时路况：如果骑手路线上有拥堵，自动重新规划路径。

调整后，超时订单减少了40%——配送主管拍着我肩膀说：“现在这预警，才是‘有用的’。”

没有业务思考的数仓，就像没有“感知”的机器：它能完成你下达的“任务”，但永远不会“主动”解决业务的问题；它能产出“准确的数据”，但永远不会“创造价值”。

四、从“技术人”到“业务数据人”：数仓人的进阶之路

我做数仓，最深刻的感悟是：数仓人的成长，从来不是“技术能力的提升”，而是“业务思考能力的进阶”——从“我会用MaxCompute建表”，到“我知道建什么表能帮业务解决问题”；从“我会用Flink做实时计算”，到“我知道什么场景需要实时计算”。

那么，数仓同学该如何培养“业务思考”能力？我总结了三个方法：

1. 把“需求访谈”变成“业务调研”

别再问业务方“你要什么指标”，而是问：

“你要这个指标，是想解决什么问题？”（比如“提升复购”“降低成本”）；
“这个问题的业务痛点是什么？”（比如“找不到高价值用户”“商家出餐慢”）；
“你会用这个指标做什么决策？”（比如“发优惠券”“优化商家考核”）。

需求不是“接”来的，是“挖”出来的——只有挖到“业务的痛点”，你做的数据才会“有用”。

2. 把“模型设计”变成“业务流程的抽象”

别再为了“技术的完美”用“第三范式”建表，而是问自己：

“这个业务的核心过程是什么？”（比如生鲜的“采购→入库→销售→过期”）；
“业务方观察这个过程的视角是什么？”（比如运营看“品类”，财务看“成本”，仓储看“库存”）；
“这个模型能还原业务的真实发生吗？”（比如“库存表”里有没有“温度”“过期时间”这些业务维度？）。

模型不是“技术的产物”，是“业务的产物”——只有抽象了“业务流程”，你的模型才会“好用”。

五、为什么现在数仓同学必须懂业务？——行业趋势倒逼的“核心竞争力”

以前数仓的核心是“技术能力”：比如Hadoop调优、SQL优化、分布式存储。但现在不一样了——

1. 数据中台的要求：从“后台支持”到“业务伙伴”

阿里、腾讯推的“数据中台”，核心就是“业务驱动数据”。数仓不再是“后台的技术部门”，而是要变成“业务的合作伙伴”——你得知道业务今年的KPI是“提升复购”还是“拓展新客”，得知道运营的痛点是“找不到高价值用户”，得知道产品的新功能要测“留存率”还是“转化率”。

2. 实时数仓的挑战：懂业务才能“不瞎实时”

实时数仓（Flink、Spark Streaming）很火，但实时的成本很高（计算资源、存储成本）。懂业务的数仓同学，能判断“哪些场景需要实时”：比如直播的“实时库存扣减”必须实时，而“月销量统计”根本不需要；比如外卖的“实时超时预警”要实时，而“季度配送效率分析”不需要。不懂业务，就会为了“实时”而“实时”，浪费资源。