数据仓库全景拆解：分析师和研发的那些事

你好，我是悦创。

今天要聊的主题是 数据仓库，下节课会讲 用户研究。

这两块虽然和数据分析师有交集，但联系没那么紧密，所以我单独拎出来讲。

本篇主要分四个部分：

1. 数据研发工程师 vs. 数据分析师；
2. App 日志采集中的埋点；
3. 数据建模：步骤与案例；
4. 数据管理；

1. 数据研发工程师和数据分析师的关系

聊关系前，先把大数据体系过一遍，它大致分为四个环节：

• 日志采集与传输
• 数据建模
• 数据管理
• 数据应用

前面三步（采集、建模、管理）基本上是数据研发的主场，也就是大家常说的“数仓”。

分析师呢？需要对整个架构有全局认知，同时专精一块。否则，跟研发团队对接时效率会很低。

来看两种典型场景👇

在大公司

• 研发工程师：分工明确，做清洗、建模、管理，价值清晰且稳定。
• 数据分析师：更多时候被考核的是专题报告的数量和质量。但如果业务落地复杂，分析师的地位会有点“飘”。做不好可能被当“杂工”，不如研发稳。

在小公司

• 研发要兼任分析师的工作，从采集到应用全包。
• 结果就是“啥都懂一点，但都不够专”，尤其在业务分析这块，容易浅尝辄止。

关键结论：

• 研发要懂业务，否则做的东西没人用。
• 分析师要懂研发，否则提数效率低，沟通卡壳。

2. App 日志采集中的埋点

埋点是日志采集里的关键环节，也和分析师密切相关。

• 前期参与：分析师入职后，必须主动参与埋点讨论。别过度迷信研发的直觉埋点，因为一旦出错，后续分析全废。
• 业务案例：比如某 App 搞活动，研发理解不同，很可能漏埋或埋错点，最后导致活动数据根本分析不出结论。
• 后期规范：埋点别无限加，做好文档化，保证大家后续都能参考。

另外，日志上报的一些 公共参数（公参），如用户 ID、设备信息，应该由分析师来定义。

👉 总结一句：埋点虽然琐碎，但一定是分析师牵头。

3. 为什么要数据建模？

先说分析师的痛点：

• 日志量太大：一个简单的 Join 半小时才出结果，还容易出错。
• 日志太乱：关键指标根本算不出来，比如“近一个月新增用户的订单量”。

所以建模的价值是：

• 提高效率，减少重复劳动
• 保留历史数据，方便追溯
• 适应业务变化，修改影响范围小
• 数据结构清晰，分析师好理解

4. 数据建模步骤

数据建模一般三层：ODS → DWS → DM。

• ODS（操作数据层）：原始日志的初步加工，过滤掉明显不合理数据。
• DWS（数据仓库层）：用户粒度的聚合，这里最考验专业力。
• DM（数据集市层）：面向业务的指标输出，比如报表、维度分析。

💡 简单理解：ODS 是原材料，DWS 是半成品，DM 是端上桌的菜。

5. 案例：头条的信息流

以头条的信息流为例，建模过程大概这样：

ODS 层

• 用户基础属性表：imei, prov, city, machine
• 用户文章下发表：imei, article_id, xiafa_time
• 用户文章点击表：imei, article_id, dianji_time
• 文章属性表：article_id, category_id, title

DWS 层

基于 ODS，生成用户粒度的明细表：

• 用户文章属性表
• 用户分类属性表

DM 层

业务关心的指标：

• 各省市的下发点击 PV
• 各分类的下发点击 PV

👉 可以看出：DM 层就是针对业务需求做定制聚合。

经验之谈：别一上来就搞得“大而全”。先把核心指标快速跑通，逐步迭代才是正解。否则可能辛苦半年，最后没人用，甚至团队解散。

6. 分析师在建模中的注意事项

• 不要盲信研发：自己动手跑一次，比如算个 DAU。
• 不要替研发背锅：调度异常、表大小、UDF 错误…这些不是分析师的核心事。
• 不要等研发开发表：分析师的目标是数据，而不是炫技。

7. 数据管理要点

虽然大部分和分析师关系不大，但这三点要知道：

• 计算管理：注意 Join 时的数据倾斜，理解 MR 内部原理。
• 存储管理：核心表建议保留 3 个月以上，非核心 1 个月足够。
• 权限管理：遵循“最小可满足原则”，尤其涉及读写权限。

8. 总结复盘

今天的重点可以概括成三句话：

1. 埋点：分析师要牵头，主动性 + 文档化
2. 建模：三层结构，快速迭代比大而全更靠谱
3. 管理：存储周期、计算效率、权限要有意识

听完这节课，相信你对大数据体系和数仓建模有了更直观的认识。

当然，每家公司实际细节差别很大，想更深入可以翻一翻我推荐过的《阿里巴巴大数据实战》。

如果你对本文有疑问，欢迎在评论区留言。

也可以关注我的公众号（微信搜 AI悦创），定期更新更多高质量的原创数据分析文章。

下节课见 👋