热搜:

01 什么是数据仓库的坑

“填坑”是一个新人刚加入团队,或者是接手一个新业务,所以经常需要面对的事情。

“坑”的出现,与历史业务的发展,密切相关。通常体现在:业务快速变动、人员快速流动、系统化建设能力弱、强行上马面子工程等情况。虽然数据开发人员能够意识到数据仓库规范性的重要,但迫于日常的数据开发压力,往往只能匆忙的制订一份规范,在实际开发过过程中,往往又无法完全照搬落实,因此形成了一个“不成熟”的数据仓库体系。

这种数据仓库体系,最典型的特征,是找数据只能给表,无法通过规范自主查找;看逻辑只能问人,无法通过模型设计快速了解;问业务只能靠求,别人管不过来自己的事情了,哪有时间来管你?

但是!我们不能坐以待毙,面对“理想”与“现实”的差距,我们必须有一套成熟的应对方法,才能在纷乱的业务中,找到不变的哪条主线。

“对标!对标!再对标!”只有标杆有了,做事才能有章法,数据才能不错误。

02 理想的数据仓库是什么样子

这个标杆是什么?就是一个理想的数据仓库模板。

做过数据仓库的通过,基本上都了解,一个数据仓库从0到1的过程中,会经过三个阶段:

第一个阶段:简单报表 + 数据库阶段;

第二个阶段:数据集市 + 产品功能阶段;

第三个阶段:数据仓库 + 主题划分阶段。

而相对成熟的数据仓库,则有如下几个发展的方向:

数据产品,通过产品化方式来辅助决策,服务业务方;

数据运营,革新公司的运作方式,通过数据来运营业务,常见于电商行业;

实时数仓,通过前沿的数据技术,来革新数据使用方式,带来技术竞争力;

数据分析,通过配合分析师,贴近业务并发现问题,指导产品或业务迭代;

数据挖掘,通过算法的力量,来给业务带来智能化的色彩。

具体每个阶段就不展开描述了,但我们可以比较清楚的看出来,数据仓库是业务从混沌走向数字化的关键环节,是承上启下的枢纽,虽说没有数据仓库同样能够进行启下的工作,但是其投入与产出终会因投入产出不成正比而无法持续的进行下去。

数据仓库的建设,是一项系统化的工程,但核心点就在三处:

第一处,规范层,比如表命名规范、刷新策略规范、数据存储生命周期、字段命名规范、指标命名规范、时间维度规范、SQL编码规范,等等,旧的业务可以不改造,但新的业务必须按照新的规范来。

第二处,主题域,也可以根据主题域,再细分为数据域,当前很多大公司普遍开展比较广的业务范围,仅电商就包括B2C、C2C、B2B、B2B2C等多种不同的业务模式,每种模式都具有自己的特点。同时,ToB的企业服务市场也正在蓬勃发展,因此企业级市场又面临人力、行政、法务、场地、财务等多种不同的主题组合,因此找公司业务负责人聊一聊,先把公司的业务范围是什么、系统有哪些、数据库有多少分类、数据同步的方式如何,这些关键因素搞清楚,主题域才能够做到合理划分,避免后续大规模大范围的调整。

第三处,数据分层规范,通常情况下,数据是分为ODS/DWD/DWS/ADS四层,一致性维度放在DIM中。这里再强调一下各层不同的地方。

ODS:源系统数据接入的地方,也是数据仓库沉淀数据的核心,通常只存储、不改造;

DWD:数据明细层,可以遵循三范式关系模型,也可以按照维度建模针对事实表做设计,对生产数据进行各种经营分析口径的加工转换;

DWS:数据汇总层,主要是为了日常运营中快速反映各业务部门的数据需求,建立各种数据模型,对明细类数据进行分主题、分维度的聚合汇总;

ADS:数据出口层,面向需求做设计,是支撑需求和应用的数据重要出口,针对诸如行列转换、数据剪裁、数据加密等实际的业务场景;

DIM:一致性维度,不再赘述。

以上是一个理想数据仓库的“雏形”。

03 我们有哪些方法来填坑

我们识别出了业务的问题,也有了建设的目标,下一步就是找策略、讲打法的阶段了。

首先,针对数据仓库的改造,要有一套清晰的主线逻辑,大致包括如下几个部分:

识别环境:包括外部环境和企业内部资产;

寻找问题:发现并标记当前业务中存在的问题;

整理业务:找熟悉公司业务的人,整理业务大图;

制定标准:按照理想数据仓库的规范,整理团队自己的标准;

建立流程:将日常的开发行为,不断的与规范进行对焦;

执行落地:通过监控、CodeReview等方法,强力落地;

总结思考:阶段性的总结问题,并进行改进。

接下来分阶段阐述:

识别环境:PMP中将项目的外部环境,定位了事业环境因素和组织过程资产,两大部分。针对事业环境因素,往往公司进行数仓建设时,都是在业务高速发展的大背景下开展的,数据开发与分析师团队,面对强大的业务需求压力,会寻求进行可靠的配合,识别团队中靠谱的人,进行合作并推动项目落地。针对组织过程资产,企业往往会有各种各样的业务,以及各种不同的文档,在数仓团队进行落地的过程中,是需要借鉴并参考大量的公司材料,整理团队自己的业务大图,同时尽可能的复用公司已有的技术工具,将精力更加聚焦在数据仓库本身的业务上。

寻找问题:数据仓库的建设,本质上“没有对错”之分,只有相对合理与否的区别,一个好的数据仓库工程师,一定能够发现很多问题,从问题中总结共性的问题出来。这些问题既不会因为公司壮大而消失,因此及时总结的问题,制定合理的应对方法,并将知识传承给新加入团队的人员,共同做大做强,是数据仓库走向成熟的标志之一。

整理业务:整理业务的“输出”,应该是部门业务大图、数据流程大图、数据仓库地图、数据文档集合等内容。我们梳理一个复杂的知识体系,往往要从“点、线、面”三个角度,来串起整体业务。点是指每次做项目的文档,详细记录的需求背景、需求详情以及数仓的设计思路;线是指我们的数据产品/分析专题/业务环节,将针对某个问题的分析或者剞劂思路展示出来;面是指业务大图、流程大图、数仓地图等不同角度看数据的方式,根据内容不同,提供给数据、业务、分析师等各方使用。“点、线、面”的方式,能够很好的消除信息不对称、数据查找、历史业务理解等问题。

制定标准:规范、主题域、数据分层,因为不同公司的业务千差万别,成熟的业务,如电商,已经走向了全面算法化、分析化的地步,但也有很多创新型的业务,能够建设出基本的数据仓库体系,就算是业务上的一大突破了。因此,虽然面上的事情是大体相同的,但是细节的调整,还是需要开发团队自己来斟酌衡量。

建立流程:数据开发的流程,分为代码提交时的CodeReview、数据上线前的自测、数据运行时的监控、项目交付前的测试、以及最终的业务验收。但很多时候,为了避免数据出问题,我们会定下许许多多繁琐的标准,这些标准会多多少少的拖累数据开发的进度。注意,不要矫枉过正,过份的追求规范,会影响日常的数仓建设进度。

执行落地:大多数情况下,团队都是按照项目制的方式,来组织相关的开发工作,因此除了PRD评审外,数据团队还应该有自己的技术评审,详细讲解业务的背景、E-R关系、模型设计方法、模型开发方式、数据规范与质量保障、数据出口、数据自测方式等内容,你可以不严格执行这些过程,但也一定不能完全忽视这些过程。

总结思考:没有什么规范是永恒的,同时也没有什么问题是不会新增的,定期 Review团队的工作过程,在周会、内部分享、外部合作等场景下交流经验,是很有助益的。

04 避免挖新坑的关键因素

避免“新坑”,核心在人,抓手在新人的招聘。

我一直认为,每个人做的选择,在当时的情景看来,都是最合理的选择,无论旁人看起来如何的不靠谱。无他,趋利避害的人性使然。

每个人的职业生涯都有各种不同的选择,或为了一份大厂的经历、或为了一种轻松的生活、或为了一份赚钱的机会、或为了自己的人生理想。但技术人,由于其职业的特殊性,往往其职业发展都是相似的:【技术达人】 - 【独当一面】 - 【领域专家】 - 【团队Leader】 - 【部门领导】。只要认真工作5-7年,成为某个领域的专家,也就是P7的级别,并不难。但是再往后走,讲道理,绝大多数团队,不需要多个Leader,因此就非常讲究时运了。

因此,新人的加入,一定要看清楚加入的目的是什么、对于团队的诉求如何,毕竟我们不希望人员一直是流动的,因为再好的规范和方法,也是需要人来传承的,但团队流动性很高时,旧的坑即使填上了,新的坑也会不断的被挖出来。

这也是HR一直在强调:“我们在招聘自己的同事”,发动大家一同招聘的原因。

有道是:“谋事在人,成事在天”,我们年轻的时候,都有选择的权利,只是不论是年岁增长、还是职级晋升,往后的选择,会越来越少。这种选择,不仅仅是招聘一个新人的公司成本,也是职业发展的个人成本。

-END-