在谈论模块化开发之前,不得不提到近年来火热的数据中台的概念。在众多繁杂的对数据中台的定义中,有的偏重于功能,有的偏重于特点,似乎没有一个权威的定义,我更倾向于用四个字来描述,那就是“共享复用”,虽然很短,却道出了数据中台的本质,这也一直指导着我在数据仓库的具体实践。
云巧标准,包括了自治、云原生、可发现、可编排、健壮、模块化6个维度。其中,复用一词跟其中的模块化开发的核心理念不谋而合。
水无定势,兵无常法,但大的道理总是相通的,并能够随着时间的发展赋予新的生命,但抽丝剥茧之后,留下来的本质东西大同小异,模块化开发的理念便是如此。
我们知道,数据仓库的发展经历了三个阶段,简单报表阶段,数据集市阶段,数据仓库阶段,在报表阶段,数据开发人员为了减轻工作量,在多变的需求中把常用的核心指标逻辑沉淀下来,在下次有相同的需求时,拿来即用,这其实就是复用的思想。
各种编程语言中的函数,数据仓库的标签体系,甚至于数据中台的核心理念,都是把模块化的思想发挥到了极致,避免了我们重复造轮子,消除了数据烟囱,用最小的投入获得了最大的产出。
在具体的项目实践中,深刻理解了模块化开发的好处,并多次从中受益,不管这种思想叫“数据中台”也好,叫云巧也罢,但都体现了模块化组装式开发的思想。
举三个典型的例子:
其一,在中国移动的B域数据治理过程中,有一个场景是需要通过产品实例id,去判断这个产品是移动,固网,宽带还是其它,因为来源系统的数据业务含义不同,不同的省份,甚至同一省份下的不同地市就有不同的判断逻辑,体现到代码里,就需要编写各种case when,以致最后这个代码特别长,当时我们的做法就是把这段逻辑固化下来,在整个数据中台中出现有且仅有一次,以便于能够在需求逻辑变更的时候,变更这一处代码即可,可以想像,如果有多处这样的代码出现,代码冗余不说,极易出现指标不一致,结果不统一,维护困难,那会是一件多么痛苦的事情。
其二、曾经遇到过这样一个需求,因为要计算各种同比环比指标,但牵涉到2月情况特殊,有的28天有的29天,再做环比的时候,如果在3月30号的时候去计算环比,那就得给出明确的业务计算公式。需求如下:
乍一看,会不知所以然,但抛开问题的表面,其实质只是要通过输入一个日期值去返回一个要对比的日期值而已,理解到这个问题的本质后,问题就迎刃而解了,我们把这段逻辑固化到一个udf函数里,对这块儿逻辑进行了封装,如果当初我们一味的用sql去实现,大概率不会如此完美的解决这个问题,这就是模块化思维的重要案例。
其三,有一个场景是计算单车的top排名。数据是共享单车的订单表,核心字段是开始经纬度,结束经纬度,订单的开始时间和结束时间,在做了常规的数据标准化,属性冗余之外,根据业务需求的特点,要经常计算从某个围栏出来的top5目的地和从某个围栏结束的top5出发地,我的做法是加工出来这样一个通用的能力模型,把所有的围栏的出发地和目的地提前加工出来,在使用时稍加限定即可,这样一个模型为后续的业务开展,以及融合其它的业务的时候直接拿来即用,而不是重复的造轮子,节省了很多人力,这也是模块化思想的一个重要案例。
可能有人会说,你的这个模型支撑不了xx场景,我想说的是凡事总有例外,你能解决大多数问题就可以了,生活中的“八二原则”处处可见。
这样的一个能力模型一来稳固,二是便于维护,就像是一棵参天大树的躯干一样,无数的数据看板、大屏指标,可视化应用都是生长在这个躯干下的枝叶,在这个躯干基础上稍微加工即可。有了这样的躯干,我们就能够避免很多的指标不一致问题,这个躯干是我们数据应用的中流砥柱,所有的上层数据应用只是临门一脚问题,这临门一脚准不准,快不快,好不好,完全取决于我们建设的这个躯干是否科学合理。
可以看到,模块化思想的运用,前提是对业务有充分的理解和对问题本质的把握。你只要掌握了模块化思想的本质,并能够在实践中运用,很多事情会事半功倍。