数仓心得(一):管理和发展

做数仓也有三年了，经历过业务和平台的零到一，一到二，一把鼻涕一把泪。把这些经历总结下，主要从三个方面去总结：一、数仓管理和发展；二、数仓逻辑架构和维度建模；三、平台选型。

先从数仓管理和发展说起，因为好的数仓要有明确的发展方向和高执行力的管理维护规则，没有一套强硬可执行管理模式，后面两个也是枉费心机。

在这里我们先把数仓涉及三个角色定义一下：
        业务：大多数是线上业务，直接面向公司客户，生成源数据的应用。
        数仓：处理源数据，提供决策数据。
        决策者：决策数据需求方，一般为公司领导、业务部门。
     数仓需要三者的共同参与建设，而不是数仓一个团队的工作，当然绝大部分工作是的。业务不是简单的提供源数据和字段注释的角色，更需要及时在新业务上线前给数仓团队介绍新业务，并一起讨论新业务对数仓模型和指标的影响，商讨方案。决策者不是简单只管提需求，更需要明确需求，多个决策者共同制定指标定义，并告知下属业务部门，避免各个部门指标定义不一致，带来歧义。那管理数仓的需要要让三个角色衔接好。
     如果业务和数仓两个角色沟通出现问题就容易发生下面的问题：有个业务修改了逻辑（比如只是修改了状态含义），跑了大半个月了，影响了你的数仓里的一个指标，数仓是不知道的，但是被决策者发现了，结果这个锅就是数仓背了。所以数仓中需要去积极了解业务的最新变动，参加业务上线评审会，评估业务变动对数仓的变化，做到运筹帷幄。

如果决策者和数仓两个角色沟通出现问题就容易发生下面的问题:第一天，运营部王总说给我做张报表其中注册人数规则是所有注册成功人数，第二天市场部李总说帮我提取下注册人数但是要剔除掉已经注销的。第三天李总开完会来训斥你说为什么我的数据和王总的数据不一样。一旦这样的事情发生，这个锅必须是数仓背了。上面举例只是个很简单的逻辑，只是想说明问题，实际上很多指标逻辑规则比想象中复杂得多，准确性要求得更高。并且数仓开发人数几十号人的时候，更容易出现不同数仓开发人员提供给不同人同一指标不同的数据。做坏人容易（数据错一次），做好人难（做对99次都很难挽回错的一次）。所以数仓需要指标体系，制定过程中需要协调多个决策者需求，统一制定，并告知所有数据开发人员熟知。指标的逻辑规则修改也要多方统一协调并确认。

 数据生命周期管理是从源数据（业务）、数据加工（数仓）、决策（决策者）使用角度去看。源数据的责任保证最细粒度数据的一致性、真实性；数据加工责任是清洗脏数据，把业务抽象的转化成易于理解的模型，建立稳定可靠的指标体系，提供准确报表数据给决策者，保证其中每一个环节的逻辑准确和有效执行。决策者要对数仓提供决策数据正确性考核；数仓要对业务数据的一致性、真实性考核；业务要对决策者的业务需求考核。

 数仓的管理还有文档体系、命名规则等等，文档体系达到共享阅读、共同修改即可，命名规则达到易辨识哪里、时间、周期、干嘛用即可。
     我觉得数仓的发展发向分三个阶段：一：数仓开发，数仓架构和管理涣散，工作效率低、经常犯数据错误，处于被动的报表开发阶段；二：数仓建设，数仓架构和管理清晰、方向明确、指标体系健全；三：数仓驱动，在业务上游刃有余，为业务前进方向提供专业数据的建议。我相信很多公司还在一和二阶段挣扎，或许还停留的一这个阶段，苦逼的不停的在背锅

     如何从阶段一发展到阶段二，应该从两个方面入手，一是领导管理手段，如就是上面说的建立数仓团队和业务研发团队、决策之间的沟通桥梁，并把这种沟通长期有效的执行下去。做好数据生命周期管理；二是从数仓架构解决，通过逻辑分层将业务变化最大程度的屏蔽在数仓模型下面，就算地震也不影响上面的房子。并建立数据血缘关系，源数据变化可追溯到其涉及到数仓的每个角落。

     如何从阶段二发展到阶段三，机器学习…？高大上的不谈，但也不是做几张报表展示在那里，而是用专业的数据技能从关系型业务出发对指标数据的变化作出数据上解释。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29989552/viewspace-2151382/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29989552/viewspace-2151382/