关于数据仓库搭建的理解

总结下自己最近的理解，还是要经常看木东居士的文章，结合自己之前做的思考整体的框架，不断调整。
数仓工程师的核心价值：设计一套贴近业务逻辑的数仓结构。

需求梳理

非常重要，一定要梳理清楚目前分析师承接的数据需求都有哪些，分日、周、月维度细化指标，这样在后期搭建中间表、计算指标的过程中，能够排列优先级，保证价值能够快速产生。其次，通过梳理需求，了解需求背后的出发点，能够快速理解业务逻辑及现阶段关注点，在规划结构中，能够符合业务逻辑。最终，在不断梳理需求中，能够进一步了解业务整体走向，输出自己对业务的判断，当然，这一点不是每个数仓都需要的，前两个最重要。

指标体系梳理

这块不具体细讲，之前有讲过，核心从业务线、主题、重要度、周期、管理层是否关注这些维度去详细拆分。

输出方案

这个时候，就需要根据具体需求，初步产出数仓的结构方案，一般采用的理论模型，就是雪花模型和星型模型。方案包括以下几点：
1、表结构设计
事实表设计、维度表设计
核心是分层
其次是主题层选取的问题
都是需要你对业务逻辑有基本认识，才能完成。

2、命名规范化
表名规范统一
字段名规范统一
任务名规范统一
指标计算流程规范统一
这四者缺一不可，不然后期维护就相当于在垃圾堆里翻垃圾。

3、任务处理机制规范
任务执行机制，即周期性处理数据的流程是如何的
数据回滚机制，即某个指标出现了问题，要怎么重新执行的问题，新增一个指标，如何把历史指标也计算出来
任务间依赖机制，比如是不是可以一起跑相同任务不同周期？
ps：之前做的时候，只考虑到了第一个问题，后期在回溯数据、维护的过程中，发现第二三同样重要，当时没想到这些，后期看大佬们的文章，才知道重要性。

4、报警机制
数据校验，说白了就是每天都跑完了，如何保证数是准确的。主要从数据量、核心指标具体结果趋势、指标计算完后的数量是否正常来判断。
任务计算失败、超时、延迟等等问题，一定要梳理清楚，数据处理的周期，起码心里要有数，最好的方案的是，每跑一层，报每层执行结果，这样能够实时看到结果。

5、权限机制
谁能开发
谁能执行
需要配置好对应人权限

开发

只要上述方案中，都考虑清楚了，基本做就没啥问题，大方向上无脑处理就好，体力活了。

验收

首先一定是不能直接上，其次，需要和之前的计算流程后的计算结果挨个做个校验，然后才可以正式上线。

个人反思及其他想法

回看自己之前做的，主要是在字段名规范、任务处理机制上，没有做好规范，虽然后期有补充，但依然像打补丁一样，不够完美。待努力。
数仓，数据仓库，说白了，就是客人用啥，我从仓库里面能快速找到，很像图书管理员一般，日常维护，确定规则，读者能够依照方法，快速找到楼层、库、书架、层、书。
数据治理，这个活真的是个吃力不讨好的活，主要问题是在企业生存比较难、价值不易体现，更多是要看长期的沉淀才能体现，所以企业高层的老板们对数据的管理意识，才是决定数据治理是否真实可行的。
个人发展方面，你要成为一名数据治理专家，真的是需要摸爬滚打，耐得住寂寞，抗压能力一流才能完成这样的普遍性难题。我不打算做这样的人，哈哈哈哈哈哈，但对这种人很尊敬，不容易。我还是专心在数据分析的专业性上继续前行。

数仓工程师的突破

最近看木东居士在发这方面的内容，码字说说自己的理解

数仓的突破，换赛道和不换赛道，前者的天花板很容易拔高，后者的天花板不好判定，初看很低，深入看真的很看一个人的能力。
先说不换赛道，能干什么。核心就是提效，如何让数据处理的时间不短缩短，这方面技术、业务理解，缺一不可。个人看法，就是往该行业的业务支持的数据方面提效专家发展，后期主要就是带一些项目，做项目的负责人，就是业务理解+技术产出=让业务提效工具。
换赛道，可以往数据分析、数据挖掘深入。