你们数据仓库都是怎么设计的,数据怎么抽象?
关于这个问题,我说一说我的想法,不一定是正确的,但希望能给你提供一些思路
1、数据仓库是怎么设计的?
如果真的要完全回答这个问题,真的太大了。
另外我觉得,问这个问题,也不一定就要让你照本宣科,把现在的数仓理论背一遍。更多的是想看你做了哪些有亮点的事,有哪些有亮点的想法。
可以按照自己的习惯,把数仓怎么设计的分成几个模块,比如:
然后,询问一下,面试官重点想要听哪一块?
技术架构方面:
可以从数据采集到数据进入数仓后的etl,再到数据怎么做成数据服务提供给业务方,整个流程的核心技术节点划一遍。
然后,再重点讲一下自己做的模块(做数据治理 or 数据开发 or...),比如说数据开发,就可以讲讲,实际工作中遇到过哪些难点,做过哪些优化,突出自己技术亮点(数开更多的是sql优化,sql优化真的有太多可讲的)。
数据流转:
这块主要讲自己所在公司的数据是从哪里来,进仓库前会做什么处理,重点监控哪些(比如:数据完整性监控)-->进仓库后会做哪些处理,做哪些监控(比如数据准确性,指标一致性)-->出仓库,数据又会提供给哪些业务方,怎么保障数据的准确性和及时性等等。
讲一下这个过程中自己有哪些比较好的想法,对整个过程起了什么样的积极作用。
分层建模:
这块主要讲公司目前仓库的分层,每一层的作用,有哪些基础数据,讲一下自己对目前公司仓库设计的一些看法,好的地方,不好的地方。不好的地方,需要怎么改进。
现在的仓库怎么通过建模来收敛口径,减少代码重复开发,要有实际例子。
讲自己曾经做过的建模上的优化,比如:通过一些数据血缘的技巧筛选出 仓库中 有相似的中间模型表,经过考察,这些表的口径只是有微小不同,最后自己主动和业务方沟通,大家达成一致,重新设计一张模型或者都归一到现存的其中一个模型上。这也属于模型优化的一个案例,为仓库减少了多少存储资源,计算资源。
另外还可以讲一讲,自己的一些设计比较巧妙的模型,比如留存,留存的设计可以依据业务需求,从易到难,有多种设计。
也可以讲讲自己建模时,会考虑哪些点:实现的复杂程度,模型的运行时长,占用资源的大小,模型的生命周期....等等
维度建模,星型模型,这么多年了,都是这些,也没什么创新,如果只讲这些,会让人觉得耳朵都起茧子了,可以把这些融合到实际案例中,多讲自己的思考和感悟,平时工作中也要细心观察,现在没有任何一家公司的数据仓库是完美的,只要你肯用心发现,都能找到优化的点。然后自己尝试去做一做,该推动的事情,自己主动去推一推
当然这里还有很多很多其它的东西,有一些,看上去很没技术含量,但是让你去做,还真不一定能做好。
2、数据怎么抽象?
抽象的前提就是了解业务,知道业务想要什么,把业务方提的零碎的需求,分门归类,总结成业务主题和数据主题。
比如:用户业务主题下,可划分为回流,留存,日活,新增,全量,行为标签...
实现部分,落地模型,也是从需求出发,把业务方的需求细化到指标和维度。
比如:业务方说我想看一下某个渠道的用户表现,那你就会考虑,用户表现体现在指标上有哪些:阅读pv,点击次数,停留时长等等。
有了指标和维度,就能够建模了。这也算是抽象数据的一种思路,工作中,基本都是这样做的。
东西太多了,挑自己最擅长的说。