写作不易,关注下公众号:晓阳的数据小站,就更好了。
毛主席说:“研究任何过程,如果是存在着两个以上矛盾的复杂过程的话,就要用全力找出它的主要矛盾,捉住了这个主要矛盾,一切问题就迎刃而解了。”
对于数据治理而言,矛盾就是:“有限的机器资源与存储计算的无限增长之间的矛盾”。
因为存在主要矛盾,因而“数据治理”在被提出10多年后,依然是目前数据领域的热门问题。解决的方法也很简单,就是尽量限制存储计算的增长,不论是通过技术手段,比如数据压缩、列式存储,还是通过方法论,比如维度建模、存储健康分,都能够延缓数据增长的困境。
但最大的问题,还是人的问题,可以这么说,不是数仓岗位,或者是数据开发岗位,对于数据治理或者数据风险问题的敏感性,都是不足的。这些不足主要体现在三个方面:
全局层面
业务层面
开发层面
因此,数据治理,首要在统一“人的共识”,建立“法制”流程。
既然要统一“人的共识”,那么我们就从“共性”的问题入手,逐步来分析解决的突破口。
作为数据开发,我们经常遇到的“共性”问题有哪些?我想,大概有三点:
我们设想一个案例:
指标A是公司的核心资产,但是因为客观的原因,需要修改计算规则,那么我们会碰到这么几类情况。
尽管公司的业务通常非常复杂,但如果抽象的好,底层逻辑的修改,就不会对使用方产生过多的影响,避免无意义的数据整顿工作。
从这里例子中,我们能够整理一下一些常见的问题:
别小看了研发工具统一,在业务高速增长的时候,技术方案非常多变,用的越灵活,未来的技术债务就可能越高。
数据资产依托于Hadoop生态,其治理成本非常高,尤其是非结构化的数据,占用存储计算量大,产出的价值又相对有限。过去我们主要针对的是存储治理,但随着任务量的增加,计算的治理也提上了日程。因而,从全局的角度出发,一家公司需要有自己统一的建模与评估方法,有统一的开发与运维平台,在统一开发规范与开发方式的基础上,才能谈有效的数据资产治理。
“书同文,车同轨,统一度量衡”,是数据治理的核心思路。
统一共识,统一度量衡之后,我们就有了数据治理的“抓手”。更具体一些,就是当工作行为有了一定的标准化之后,就可以通过“数据指标”来进行一些衡量,从而看清楚数据资产的全局情况,以及需要改进的重点方向。
做用户增长的都知道建立指标体系的重要性,做数据治理的同样要有“用数据来治理数据”的意识。
那么思路具体怎么样呢?主要有两点,一个是数据模型本身的监控,一个是业务复杂性的监控。
数据模型的监控可以理解,但为什么要监控业务复杂性?是因为业务复杂性很大程度上影响了数据模型的复杂性和成本,因此同样需要监控。
先说数据模型的监控,简单讲,有四条策略:规范要好;复用率要高;使用率要高;依赖层级不过深。
规范要好:做开发的基本都知道,做事情要有基本的规范,比如表的命名,要能够清晰的看出是属于哪个业务域、服务哪个产品模块、是同步导出数据还是披露视图、刷新周期如何,等等,这些都需要通过名称来规范,因此当数据规范定好之后,就可以针对性的统计不符合规范的表,限期整改。
复用率要高:这一条是针对CDM层的。在维度建模理论中,CDM的主要作用就是提升数据的复用率,因此CDM(包括DWD、DWS和DIM)一定不是面向需求做的开发,而是针对业务过程做的统计。统计CDM层每张表的下游依赖数量,就能够有效的考核公共层的建设水平,少有人用的CDM是不合格的。
使用率要高:这一条是针对ODS层的。ODS通常存储了最多的数据,因此ODS数据如果被引用的不够多,那么通常它的业务都不是那么重要,那么ODS表的存储周期就可以适当的考虑缩减,并在引用数量与存储周期之间寻找一种平衡。当然,肯定有特殊的例子,但特殊不代表普遍情况。另外,有一些ADS表是直接引用ODS的,如果业务发展初期,这么做是可以考虑的,但如果是成熟业务,这就应该。区分的方法依旧是通过表的命名,来判断表述所属的业务域与产品,并与业务域的成熟度挂钩起来。
依赖层级不过深:这一条是针对ADS层的。最让数据人头疼的问题,莫过于数据层层向前追溯,发现链路极其之长,用都不敢用。因此ADS层自身的依赖深度,包括最大依赖深度、不同依赖深度的统计,能够看出ADS层建设的一些问题。
再说业务复杂性的监控,也是四条策略:总链路长度、总代码量、总成本预估、项目管理。业务复杂性监控的前提,是梳理核心的ADS产品出口表,整理清楚每个产品模块或者接口对应了哪些ADS表。
总链路长度:计算一个产品出口表从ODS到ADS的全路径长度,链路越长,存储和资源资源占用越多。
总代码量:计算一个产品出口表从ODS到ADS中涉及的代码总量是多少,代码量越高,代表计算资源消耗越多。
总成本预估:依据链路表的存储数据量与机器资源消耗,推断一个产品消耗的数据成本。
项目管理:从根源上治理需求多乱的情况,这里不展开说这个问题。
当然,随着对于数据的理解不断加深,我们还会做更多有价值的分析,比如分析每个SQL的写法是否合理,等等。但不论怎样,有了统计指标,就能够看清全局现状,就能够针对性的治理。
就像任何方案都有“上中下”三策一样,解决问题同样要有“短中长”的策略。
短期方案着重点在于改善上述提到的统计指标,迅速将一些低级问题解决掉。因为一旦有了指标的概念,可以调动研发同学的主观能动性。
中期方案要整理数据的架构体系,包括建立完整规范制度和技术结构,通过方法论和文化的方式,来影响每一位小二。
长期通过技术创新的方式,实现自动任务优化,协助降低数据的维护管理工作量,例如最近比较热门的“云原生”概念。
但不论怎样的策略,都需要考虑历史债务的问题,以及如何不再新增债务。
完美的解决方案通常不存在,退而求其次是大多数人的选择。当技术无法解决问题时,不妨用另类思路去解决。
当然,广义的数据资产治理,要扩展到更多的方面去阐述,比如数据安全、比如数据孤岛问题,每一个都需要系统的理论来阐述。
但最后我想讲的是,这其实涉及到了择业的问题,企业效率的提升无非两点:降本与提效。提效可以通过数据分析的角度来解决,而降本就需要通过数据资产治理来推动了。择业的时候,如果仅仅是熟练使用工具,很容易被淘汰,而掌握了降本与提效的方法论,应对中年危机,就要更加的得心应手一些了。