数仓模型重构与优化

数据仓库    发布于:2021-09-27 浏览 532

系统之所以复杂,大多数情况下,是因为业务线之间的相互依赖、相互引用、相互关联,如果一个分析框架场景单一、没有分支流程,就不存在治理的难题。

|0x01 为什么会提出模型重构

笔者是做数据出身,在数据仓库领域,常常有“建模”的需求,其实在软件工程领域,“模型”的设计也非常重要。但是除了“建模”,还有一个问题,会伴随而来,这就是“模型重构”。为什么会出现“模型重构”?大多数人就没有深入的探讨和研究了,大多数是作为一项工作,或者是排期的需求来做,而没有真正深入探索“模型重构”背后的原因。

在一号位心态的影响下,让我们看看“模型重构”通常面临的背景:

  • 看不懂:很多人在接手新的业务之后,都会有一种“看不懂”的心态在里面,比如为什么注释文档这么少、这么设计的原因是什么、代码规范做的真差…… 除非是长期投入的业务,大多数业务在发展的初期,都会为了提升研发的效率,放弃一定的规范性和稳定性。尽管经验丰富的架构师或者建模师,会在业务开始的时候,制定好业务的框架大图,但随着时间的推移,一定会产生种种的意外情况,使得我们不得不对原有的架构打补丁,再持续一段时间,这个模型就看不懂了。

  • 总出错:模型重构还有一个原因,就是业务总出问题,不论是数据算不准,还是软件总报错,总归是在架构发展的某个阶段,问题会集中的暴露出来。模型重构的初衷不一定是为了稳定性着想,但稳定性出了问题,就一定会重构模型

  • 跑的慢:这一条是针对数据业务来讨论的,因为不存在一种模型,能够在业务发展的初期,就能够设计的非常完善。一个好的模型,一定是在业务不断发展的过程中,用经验积累出来的。对数据模型而言,当原有模型不能继续高速支持业务发展时,它就有了重构的必要性。

  • 没价值:这一点会被大多数一线工程师所忽略,但在汇报自己的工作成果时,又往往被拿出来“鞭尸”。是的,数据模型设计的怎么样,很多时候并不仅仅看它够不够稳定,或者是会不会出错,而是看这个模型能够为我们的业务带来怎样的价值,甚至是通过这个模型,能够驱动业务发展的怎么样。

简单讲,“模型重构”就是为过去的“技术债务”,做的补偿而已。但重构的过程,最核心的要素,在于“技术如何为业务增值”,而不仅仅是质量、稳定性和效率。

|0x02 模型重构要考虑什么

关于模型设计的好不好,可以参照之前的文章:《数据模型如何论好坏》。这个模块要讲一些更进阶的理论,即“结构思维”。

对于一名一线工程师来说,辛辛苦苦一整年,最怕的往往不是辛苦,而是自己努力的结果得不到老板的价值认可,或者是产出的结果对业务的意义不大。而既然要做模型重构这件事情了,就要学会反思自己过去在结构化思维上的缺陷,比如汇报自己的工作能不能系统性的论述出来、做的事情是不是成体系、学习的过程是不是有一个重点作为抓手,等等。如果用更接地气的方式来解释结构思维,就是做事情要有“套路”。别小看了套路,因为技术或者能力怎么样,无法直接带来产出成果,而套路是达成目标、产出价值的最快方法

大多数人不会关心你做了什么,只会关心你产出了什么成果。

“套路”并非完全是过去经验的总结,有点像机器学习,是指能够在过去经验积累的基础上,通过对中心要素进行分解,预测未来的行动方针,即“行为方法论”。例如5W2H就是一个帮助我们分析问题的“方法论”。如果你能对自己正在做的事情,从Why、Who、When、Where、What、How、How much七个方面,毫不犹豫的说出来,相信你已经对业务有了非常深入的了解,也能用充分的实力去证明自己、做好汇报。

事实上,5W2H就是结构思维的一种,结构化是最简单清晰、最有效的经验总结手段

接下来从理论的层面来叙述一下,首先就是建立中心思想。任何模型重构,都一定会围绕着解决某个业务方向展开的,通常会从两个方面来考虑:

  • 这个业务方向的主要目标是什么?

  • 为什么这个模型要我来设计?

如果业务方向是比较成熟稳定的模式,比如电商,那么它的第一诉求就必然是应用业界成熟的设计方案,并且尽可能的稳定产出时间和保障设计质量。而交给你来负责,大概率是因为你对于这方面的业务最为熟悉,或者是之前从事过相关领域的工作,能够把前人的经验迅速落地实现。

例如用SWOT分析法,我们就可以很快分析出目前的现状。

对很多小公司而言,能够用大公司成熟的模型,让业务飞快跑起来,就是一种技术增值。对于大公司而言,业务需要更多的创新探索,研发与业务的矛盾根源就在于供需平衡上,效率的提升就是技术的增值一种。当然,技术人员也可以直接提出有价值的想法,在互联网广告等领域,业务的增长也往往来自于技术同学自发的贡献,这个时候就要注意培养组织的文化,让不同领域的同学能够有坐在一起解决问题的机会,在思维碰撞中寻找技术增值的点。

当我们有了中心思想之后,就要拆解子类的结构,并且根据一定的顺序,对子类进行合理的分析或重组,以寻求最佳的计划。如果回到刚才的话题,大概就是这样的拆解顺序:

这个时候,再跟老板和业务方汇报工作,就按照拆解好的顺序,进行结构化的叙述,原本半小时才能说清楚的事情,5分钟就可以汇报完成。

一直拆解到这里,我们才回到模型重构的本身。在传统的数仓分层结构中,ODS层是数据产出时间的保障,监控往往在这一层要做扎实了;CDM层是业务高速发展的基础,如果没有特殊情况,CDM层应该是高度稳定的,如果频繁对公共层进行修改,一定是模型设计哪里出了问题;ADS层是业务跑起来的保障,数据可以做任意维度的加工,支持下游的灵活使用。

再细分下去,就是高内聚、低耦合思想在SQL开发过程中的应用了。例如GRASP方法,参照之前的文章《架构方法论》

 

|0xFF 解决复杂性困局

但是结构思维并非是万能的,很多时候如果设计不当,会掉入“复杂性困局”之中。

由于SQL开发不像软件工程,可以灵活运用面向对象的设计思想,维度模型更像是面向过程思想在数据领域的应用,因此遇到一些非常复杂的业务场景中,就会出现大量的CASE WHEN语句。同时,很多写死的配置,也不能通过一个公共的Constant类进行配置,做一张可修改的维度表又显得违反规范,因此业务高速发展滞后,很多ADS层的数据就会陷入复杂性困局,不仅别人看不懂,出了问题自己都不容易定位,还要去翻看源码才能知道当初的设计详情。

所以,对于复杂业务的治理,就不是一个说得清、道的明的方法论了,比较考验工程师的经验积累。

但凡事都是有一些可借鉴的经验,比如面对复杂性困局,可以试着从以下的流程来逐步拆解,用结构思维来尝试治理:

业务理解 -> 领域建模 -> 流程分解 -> 多维分析。

业务理解是拆解复杂性困局的第一要义,比如电商发展这么多年,SKU、ORDER等单词的涵义大家都非常清楚。但一些比较新兴的领域,比如新制造、医药行业,搞清楚一件事情的本质,就不是那么容易了,这时候一定要去熟悉自己所做的业务,现状是什么、行业改进方向是什么、不同解决方案的利弊如何,这对于提前摸清楚未来可能遇到的坑,很有帮助。

领域建模部分,参考之前的文章:《浅谈领域建模》

流程分解参照前文,但这里要强调一点,就是流程分解的过程中,一定要搞清楚哪些是稳定不变的部分,哪些是会经常变化的部分。很多时候为了开发的便捷,往往在公共层的表里夹杂了大量的业务逻辑,虽然下游用的爽了,但一旦碰到业务变更,或者是场景不合适,再回头修改,就会搞的非常难受。因此冗余虽然是有必要的,但一定要冗余不变的因素。

最后是多维分析,系统之所以复杂,大多数情况下,是因为业务线之间的相互依赖、相互引用、相互关联,如果一个分析框架场景单一、没有分支流程,就不存在治理的难题。因此,多画图、画好图、好画图,业务流程画的清楚了,才能知道改进的焦点在哪里。

本文内容转载自“数据仓库与Python大数据”(ID:edw_bigdata),晓阳的数据小站。

收藏此文章 点赞此文章

评论 (0)

暂无用户回复

评论此篇文章

登录后可回复
/1000