为什么你的数据仓库项目促成不下去？
发布时间：2021-06-04 16:49:04 所属栏目：大数据 来源：互联网
导读：为什么你的数据仓库项目推进不下去? 0x00 前言 最近很多小伙伴都来找居士咨询类似的问题： 我的数据仓库规范设计的很好，为什么大家却不执行? 数据仓库规范推着推着，感觉项目就凉了，不能持续? 老板看不到数据仓库的价值，不再投入人力了。 不同的团队会面
|
为什么你的数据仓库项目推进不下去?
0x00 前言
最近很多小伙伴都来找居士咨询类似的问题：
我的数据仓库规范设计的很好，为什么大家却不执行?
数据仓库规范推着推着，感觉项目就凉了，不能持续?
老板看不到数据仓库的价值，不再投入人力了。
不同的团队会面临不同的难题，今天居士简单聊一下这几年自己亲身经历以及帮助一些小伙伴解惑后的一些感想。
废话少说，直接上正题。分为三个角度讨论：
体系搭建
业务理解
沟通管理
这三个角度，也是我认为一个每一个数据仓库项目负责人要具备的核心能力。下面分别从这三个角度进行分享。
0x01 体系搭建能力
说句心里话，大部分互联网公司的数据仓库，其实是不需要特别复杂和专业的数据模型的。
因此，大家要先有足够的信心去认为，你按照设计出来的数据仓库体系，是能cover住大部分业务场景的。此处可以去参考居士之前的数据仓库文章。
那么，为什么还要提这个体系搭建能力呢?
这里想强调的是，你对于数据仓库整体的规划和思考能力。切记不要纸上谈兵，搞一堆什么模型，什么分层，其实没有什么用的，不能真正解决问题的设计，都是假的。
抛开这些模型之类的乱七八糟的角度来看，居士举几个例子，这些例子其实能解决你很多问题，而这些方案带来的效率提升，就会让你能感觉到数据仓库的带来的价值。
记住一点，不要指望一种表设计能满足100%的需求，如果有，请告诉我。
一、Bitmap表
举个例子，用户活跃Bitmap表。
表结构：
ds：日期
uid：用户id
day_act_bitmap：01010010101010，1表示当天活跃，0表示某一天不活跃
这么一张表，在day_act_bitmap字段里面存放用户的历史活跃情况，能满足绝大部分关于活跃统计的需求。
如果感觉不够，再在里面补充几个维度，再加个周活跃，年活跃，这不就ok了?
二、用户维度行为宽表
表结构：
ds：日期
uid：用户id
场景1的活跃次数
场景2的活跃次数
场景3的活跃次数
这么一张用户维度的宽表，又能帮你满足一大波需求
三、业务统计大宽表
类似前面的，不再解释了。
这种设计还有很多，就不一一列举了～
这些设计都不是多么严谨的模型设计，但是很有用，也能解决很多问题。大家可以把这些小trick整合到数据仓库模型设计中。
有了真正能解决业务需求模型能力之后，就是如何让大家执行了。特别是规范制定后大家不遵守该怎么办?一般有下面几种方式：
制定可执行的规范，一定是可操作的，不要搞太虚的，比如大家可以思考一下，自己的数据分层设计，能否明确两个层次的的具体差别是什么?能否做到可以不用思考按照规范就能确定分层
通过流程&管理手段保证执行
化系统化强制执行，不遵守不能建表，不能写入数据
具体用哪种方式就看具体的场景了。在大部分团队的前期，居士推荐前两种结合。
 （编辑：伊春站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
