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-