带你去看快手数据管治技术交流会-模型规范 | 彭文华

这是彭文华的第127篇原创

    年底真的是各种分享的集中点，也是我等菜鸟的饕餮盛宴时刻啊！今天又有很多大会，我是开着好几个远程同时在听。不过很快就被快手的《数据管治技术交流会》吸引了，不仅把数据治理系统性的阐述清楚了，而且把快手的数据治理的实践都拿出来了。更要点赞的，是快手的开放心态，会后没一会，就把所有没有水印的PPT全部分享出来了。必须疯狂点赞！

    先放一个本次交流会的内容全景镇楼。本文主要分享第一个议题：快手从模型规范开始的数据治理实践。文末有PDF资料下载方式。

这部分是快手数据治理专家孙伟大佬讲解的：

    快手是依据DAMA的理论开展数据治理工作的。之前我也分享过相关国内外数据治理的框架和组织，详见《戳我查阅：数据资产化的前提-浅谈数据治理体系的建设》。依据某个框架最大的好处是方方面面都会考虑到，不会有遗漏的地方。其他可以参考的数据治理框架还有DMM、DMCM、DCMM等。

    数据治理的理论框架很多，但是核心也就上面这些。其实还有一些没有列进来，比如战略、组织等，但是这些跟数据模型规范关系不大，所以没有列进来。

    这张片子的逻辑很重要，底层规则是否完整决定上层建筑是否稳固。所以第一场分享模型规范也是非常有深意的。

    纵向上看，数据模型决定上层元数据甚至是数据服务的建设；横向看，质量规范、安全规范都是为数据模型服务的，数据模型规范的重要性可见一斑。

    还是那句话：“如果你认为数据治理的成本太高，试试看数据混乱的代价”！

    其实我们在数据上遇到的所有问题，99%都是数据治理缺失导致的。而数据治理缺失的根源在于组织的不重视。

    快手的模型规范治理思路很清晰，先定义规范和标准，然后确定阶段性目标和参考的方法论，最后用元数据驱动数据治理。

    快手的场景是业务生态太多了，几十条产品线，迭代也非常快，所以定义建设目标是企业级的数据中台，提供核心业务线的数据服务。

    快手的数仓分为5层，ODS、DWD、DWS、主题层、APP层。现场还分享了一个数据如何界定到公共业务层还是在公共基础层的原则。其实如果业务固定，区分在公共基础层还是公共业务层很简单。但是在产品迭代非常快的时候，存在公共业务层的表会逐渐变得越来越重要，甚至会下沉变成公共基础层的可能。其他数据仓库分层的内容，可以参考我之前分享的另外一篇文章《戳我查阅：数仓到底要分多少层？》

    指标体系的定义规范基本已经形成统一的共识了，大家基本都这么做。指标类型分原子指标、衍生指标和派生指标，相关的内容包括：统计周期、颗粒度、各种业务限定（时间、区域、各种业务条件等）。一些特殊的指标还有统计时点（例如财务数据需要在特定时间进行统计）等特殊定义。具体示意可以参考《戳我查阅：如何搭建一个数据仓库》中的指标体系部分。

    在直播平台，有些人反馈太枯燥了，没有干货。其实这就是非常干的干货了。这些规范虽然不够具体，但是基本的管理框架已经列出来了。数据治理其实最重要的就是组织管理，没有这张图，其他内容设计的再好，都是枉然。

    很多公司都没有“决策委员会”这个组织，所以导致指标爆炸，根本没法管控。最可恶的是那帮业务人员，完不成任务就来改KPI的统计口径。这张图中定义的指标管理流程规范就给出了一个范本，A1A2是公司级的指标，A3是部门级的指标。部门级别的指标经过数据分析师或者数据产品经理确认合理之后，直接开发就行了。A1A2是企业级的指标，必须要经过决策委评审才能进入数据开发阶段。头条、美团、爱奇艺等公司都是这么玩的。

    左半边是常规做法，按业务建设，这就是一个个的烟囱，其实这是Kimball建设的逻辑导致的。右边是总体规划，统一实施，在底层尽量拉平，一层层从上往下建设，业务层想看数据，直接对接APP层就行了，其实这就是Inmon的数仓建设逻辑。这里有一个小知识点，自上而下、自下而上，指的不是数仓分层的上和下，而是数据上下游的上下。很多人都搞混了。

    左侧类似的指标需求，应该是数仓工程师最讨厌的了，但是在现有框架下又没办法，只能不断做重复工作。

    进行统一元数据管控就不一样了，在DWD层抽象出统一的事实，DWS层就能抽象出统一的原子指标，在APP层就能用领域建模的方式，扩展成为衍生指标和派生指标。以上图为例，时长指标可以被抽象成原子指标，业务1时长指标就是派生或者衍生指标了（原子指标加上业务限定就是派生指标，再加上聚合修饰、业务目标就是衍生指标）。具体示意可以参考《戳我查阅：如何搭建一个数据仓库》中的指标体系部分。这样即便是再加一个业务，我们只需要在APP层处理一下就行了，不用穿透到DWD层。

    业务变更导致模型快速变化是数仓工程师的噩梦。快手的方法有点类似DV模型，核心模型基本不变，扩展的内容单独放，解耦之后就舒坦了。业务变化基本也不会穿透到核心模型，变更和运维工作自然就减小了。

    其实这张片子我估计是走神了，所以现在回顾一下没太理解。按理来说基本不会出现左边的情况。我们说数仓分层建设，DWS存在的意义就是进行进一步抽象和解耦。只有在小型公司或者业务非常单一且稳定的场景，才会去掉DWS这一层。

    这句话很赞。专注于一个工作做久了，都会渐渐生出类似的明悟。单点解决问题，通常会陷入无尽的任务，长期只见树木不见森林，慢慢就把自己做死了。构建系统性思维、建立全局思考框架，是根治问题的不二法宝。依托于DAMA治理体系，无疑是非常明智且正确的。

以DAMA的数据治理体系为参照，拆解数据、能力、产品以及支持与保障，就能梳理出上图。大家看个大概就行，稍微展开就得几千字。

这个数据模型度量体系还是很有意思的。可以作为数仓团队的KPI考核来源。图片截的不太清楚，各位可以下载PDF参考。整个数据治理的健康度量化指标体系我重画了一下：

这个指标体系可以细化到个人，然后直接进行排名。在《快手大数据成本管理》的分享中，也用到了其中部分指标的排名。看来到哪里都脱离不了KPI啊。

这张图似曾相识。其实就是前面的图在右侧加了一个系统化治理工具，然后强化安全和数据价值。

从整体上来说，快手数据治理的切入点很好。框架参考DAMA，先组织，后标准，夯基础，强执行，重服务。

整件事情有目标，有组织，有纪律，有章法，不徐不疾，步步为营，做的很踏实。可以作为业内数据治理的参考。

扩展阅读：《2.快手从模型规范开始的数据治理实践-孙伟.pdf》已经给你准备好了，后台回复“模型规范”即可下载。回复“DAMA”下载DAMA-DMBOK文档。