|
数据仓库
数据仓库的重建，从业务的角度讲诉一下重建数据仓库的原因。
背景
公司建立大数据部门已经有1年，最开始数据仓库的建立完全由大数据开发同事构建，最开始仅有三个大数据开发工程师进行设计，有制定一定的规范。刚开始所有的数据从同步数据到odl层，在bdl层建立事实表和维度表，adl层建立应用报表，该有的步骤都有。但随着人员的流动、数据仓库的使用者越来越多的时候，出现的问题越来越多。
坑集
-
权限的申请 由于大数据部门与运维部门是独立的两个部门，运维部门承担一定的数据安全责任，因此对于数据的同步有绝对的谨慎意识存在，因此大数据部门目前要同步数据首先的有数据库的同步权限，目前该权限都需要走申请流程，涉及的流程周期较长，不利于大数据部门的即时处理应用。而该问题存在各个高层用户之间的博弈。属于利益关系也属于流程的效率关系。
运维部门的权限管理范畴在哪？大数据部门的权限范畴在哪？监控大数据的同步行为同时给予便利高效的同步通道，解决安全和业务正常运行的问题。 -
数据同步 数据在接入的时候并未剔除测试数据，需要每个人员根据自己的业务理解或者关键词去剔除测试数据，导致每一个开发同事提出测试数据的逻辑不尽相同，得出的真实数据不统一，因此数据从最开始就有问题，到后面的bdl层以及adl层输出的数据更无法进行沟通分析。
大数据在数据同步时尽量是不对数据进行任何的清洗和统计，避免数据的丢失和失真，毕竟每个人对数据的可用性理解不一样，但是测试数据是不属于数仓的数据范畴内的，因为数仓存储的是真实环境真实产生的数据，测试数据应在odl和bdl层之间进行处理，在bdl层之后不再流入数仓里面。 -
bdl层的建立 bdl层的数据来自于odl层的数据，bdl层最重要的是有域的区分以及事实表和维表的建立。若一个bdl层表没有域的概念也没有对象粒度的概念，将导致同一个bdl层的数据存在大量冗余状态，比如用户表有4个，分别命名为用户表、用户注册表、用户事实表、用户属性表。而以上表数据产生的场景属于一致，可以通过合并的方式建立唯一的一张用户表。
事实表重要的是确定数据描述的事实场景以及数据产生的粒度一定要确定以及统一。不能存在一个表描述两个场景两个对象，粒度不统一的现状，比如一张销售跟进表，不能同时存在跟进信息和电话信息，因为跟进信息和电话信息不在同一个场景发生，跟进表在于销售同事与用户跟进的内容存储，由销售同事手动录入。虽然电话沟通内容也属于跟进信息，但是电话沟通是系统自动产生的信息。产生的场景不一样。
bdl层存在互相引用的情况，会造成数据使用的混乱，同时在adl层引用时会出现调度时间混乱。 -
adl层的建立 adl层有两个问题产生。一个是adl层各个输出的指标口径不统一，从业务角度的命名一致，但是数据口径上却有差距，主要在于数据口径中主表的不一致、约束口径的不一样，若没有拿到统计数据进行对比、明细数据进行排除，很难发现口径的不一样；另一个是adl层的应用表同样也有实时表和离线表，无论实时表还是离线表，若是作业上同时交叉引用离线和实时表，大概率上会出现数据缺失以及同一个指标输出结果不一致。 -
应用的推广 1）各使用者对于指标的理解口径不一
比如裂变率，分析师的定义：带来的例子的A/被A带来例子量，而运营人员定义：A/例子。以上两指标在进行业务分析以及每年度的目标测试会产生较大的区别，导致彼此之间原因、目标以及结果无法形成链路分析。
2）采集质量差
数据的采集最开始并非为了统计和分析，再者采集的部门与应用的部门不属于同一个部门，绩效的评判内容不一致，导致数据采集质量差，数据的业务场景无法闭环等情况。最后就是从不同的角度计算同一个指标，数据对不上。比如计算GMV，从订单的支付金额和从财务的应收账款计算，两张无法达到100%一致。造成数据不可信。
3）业务变更与数据口径更新到实际应用的时间差过大，所损耗的口径变更资源也很大
比如市场部的例子数归属，8月份开始变更，数据部门需要11月才能完全变更完毕。原因在于业务变更信息差，数据质量问题。业务进行变更的同时不会同时告知大数据部门，大数据部门的信息处于滞后，由于信息滞后再加之需要将历史数据进行追数变更到与之前的业务场景符合，需要重新整理逻辑，排差已用应用表，然后进行业务口径确定、应用表口径变更。
4）运营人员数学能力较弱
数据的价值挖掘不够彻底，原因是采用复杂的统计逻辑或者运用数据挖掘的方法，业务部门不理解或者数据挖掘逻辑难以解释，导致数据不敢用。
5）数据应用时效性差
业务部门获取数据需要经过大数据部门的允许，导致数据的时效性不够。
|