总结下自己最近的理解,还是要经常看木东居士的文章,结合自己之前做的思考整体的框架,不断调整。
数仓工程师的核心价值:设计一套贴近业务逻辑的数仓结构。
需求梳理
非常重要,一定要梳理清楚目前分析师承接的数据需求都有哪些,分日、周、月维度细化指标,这样在后期搭建中间表、计算指标的过程中,能够排列优先级,保证价值能够快速产生。其次,通过梳理需求,了解需求背后的出发点,能够快速理解业务逻辑及现阶段关注点,在规划结构中,能够符合业务逻辑。最终,在不断梳理需求中,能够进一步了解业务整体走向,输出自己对业务的判断,当然,这一点不是每个数仓都需要的,前两个最重要。
指标体系梳理
这块不具体细讲,之前有讲过,核心从业务线、主题、重要度、周期、管理层是否关注这些维度去详细拆分。
输出方案
这个时候,就需要根据具体需求,初步产出数仓的结构方案,一般采用的理论模型,就是雪花模型和星型模型。方案包括以下几点:
1、表结构设计
事实表设计、维度表设计
核心是分层
其次是主题层选取的问题
都是需要你对业务逻辑有基本认识,才能完成。
2、命名规范化
表名规范统一
字段名规范统一
任务名规范统一
指标计算流程规范统一
这四者缺一不可,不然后期维护就相当于在垃圾堆里翻垃圾。
3、任务处理机制规范
任务执行机制,即周期性处理数据的流程是如何的
数据回滚机制,即某个指标出现了问题,要怎么重新执行的问题,新增一个指标,如何把历史指标也计算出来
任务间依赖机制,比如是不是可以一起跑相同任务不同周期?
ps:之前做的时候,只考虑到了第一个问题,后期在回溯数据、维护的过程中,发现第二三同样重要,当时没想到这些,后期看大佬们的文章,才知道重要性。
4、报警机制
数据校验,说白了就是每天都跑完了,如何保证数是准确的。主要从数据量、核心指标具体结果趋势、指标计算完后的数量是否正常来判断。
任务计算失败、超时、延迟等等问题,一定要梳理清楚,数据处理的周期,起码心里要有数,最好的方案的是,每跑一层,报每层执行结果,这样能够实时看到结果。
5、权限机制
谁能开发
谁能执行
需要配置好对应人权限
开发
只要上述方案中,都考虑清楚了,基本做就没啥问题,大方向上无脑处理就好,体力活了。
验收
首先一定是不能直接上,其次,需要和之前的计算流程后的计算结果挨个做个校验,然后才可以正式上线。
个人反思及其他想法
回看自己之前做的,主要是在字段名规范、任务处理机制上,没有做好规范,虽然后期有补充,但依然像打补丁一样,不够完美。待努力。
数仓,数据仓库,说白了,就是客人用啥,我从仓库里面能快速找到,很像图书管理员一般,日常维护,确定规则,读者能够依照方法,快速找到楼层、库、书架、层、书。
数据治理,这个活真的是个吃力不讨好的活,主要问题是在企业生存比较难、价值不易体现,更多是要看长期的沉淀才能体现,所以企业高层的老板们对数据的管理意识,才是决定数据治理是否真实可行的。
个人发展方面,你要成为一名数据治理专家,真的是需要摸爬滚打,耐得住寂寞,抗压能力一流才能完成这样的普遍性难题。我不打算做这样的人,哈哈哈哈哈哈,但对这种人很尊敬,不容易。我还是专心在数据分析的专业性上继续前行。
数仓工程师的突破
最近看木东居士在发这方面的内容,码字说说自己的理解
数仓的突破,换赛道和不换赛道,前者的天花板很容易拔高,后者的天花板不好判定,初看很低,深入看真的很看一个人的能力。
先说不换赛道,能干什么。核心就是提效,如何让数据处理的时间不短缩短,这方面技术、业务理解,缺一不可。个人看法,就是往该行业的业务支持的数据方面提效专家发展,后期主要就是带一些项目,做项目的负责人,就是业务理解+技术产出=让业务提效工具。
换赛道,可以往数据分析、数据挖掘深入。