写在前面
数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,用于支持管理决策(Decision Making Support)。近年来,随着大数据的应用不断深入,构建企业级数据仓库成为了企业进行精细化运营的一种趋势。
从管理者的视角来看,数据仓库是赋能业务并辅助决策的一种工具,从开发者的视角来看,数据仓库是一堆数据模型的集合。数仓开发是一个系统工程,涉及数据集成、数据建模、数据开发、数据服务、任务调度、元数据管理、数据质量管理(DQC)等一系列的流程。另外,由于数据跟业务是息息相关的,所以在构建数仓的时候,需要对业务有一个非常深刻的理解。
值得注意的是,数仓的建设不是一蹴而就的,也没有毕其功于一役的方法,业务的不断变化决定了数仓是在不断迭代中进行完善的。从这个层面上来讲,或许永远没有完美的数仓。由于人员的流动、业务的变化以及前期的系统性建设不足,数仓总会存在这样或那样的问题。
或许我们可以用"是否成熟"描述数仓的建设,那么什么是成熟的数仓呢,我们不妨换个角度思考一下:什么是一个不成熟的数据仓库?此时你的脑海里是否会蹦出一个词,那就是混乱。是的,一个不成熟的数仓虽然具备了部分数仓规范,但在具体的落地实施过程中,并未能完全按照规范操作, 导致数据仓库建设比较混乱,比如数据域划分不清楚、数仓分层不明确、数据任务随意依赖、数据重复开发等等问题。迫于业务快速变化以及日常数据开发需求的压力,造成了数据开发没有太多的时间和精力去顾及这些问题,最终形成了一个不成熟的数仓。一旦出现了这些问题,后续就需要有专门的数据治理团队去规划并规范数仓的建设。
所以,假设你接手了一个不成熟的数仓项目,或者你觉得目前的数仓建设还不够成熟,那么不妨思考一下几个问题:
- 定目标
- 选技术
- 找问题
- 划主题
- 识分层
- 理建模
- 制规范
定目标
数仓设计目标包括数仓分层清晰,字段与模型命名规范,具备较高可复用性与可维护性,能够快速响应产品运营层面的数据分析需求,以数据驱动产品迭代与业务增长。
数仓设计的过程中,坚持用户驱动与数据驱动相结合的设计理念,即一方面根据当前的业务数据的基础和质量情况,以数据源分析为出发点构建数据仓库;另一方面根据业务的方向性需求,从业务需要解决的具体问题出发,确定系统范围和需求框架。
选技术
数据仓库是一个复杂系统,会涉及到一系列的流程,由此不可避免的会使用很多的技术框架。目前,行业中使用的常见工具主要包括:数据同步工具、数据处理工具、任务调度工具、报表工具、元数据管理工具、质量管理平台(DQC)以及大数据基础平台等等。
如果是自建的大数据平台,或者是没有一个大数据开发平台,这种情况下需要数仓开发人员具备丰富的技术栈,既要兼顾技术的集成使用,又要兼顾数仓的建设与业务需求的开发。如果使用的是已经集成好的开发套件,比如阿里云的dataworks,这样数仓的开发人员会更加聚焦数仓的建设,而不是在各种技术的集成过程中踩坑而分散过多的精力。
找问题
前文已经提到没有完美的数仓,其实数仓的建设并没有对与错之分,只有好与坏之差。我们不能一味的使用拿来主义的方式去构建数据仓库,数据仓库建设能否成功会涉及很多的因素,数仓建设的方法论是指引我们的一个方向,万万不可迷失其中。一言以蔽之,合适就好。
在接手不成熟的数仓时,需要梳理存在的一些问题,而这些问题一般情况下都大同小异,常见的一些问题主要包括:
- 数仓分层不清晰
- 数据域划分不明确
- 模型设计不合理
- 代码不规范
- 命名不统一
划主题
主题域是业务过程的抽象集合,是在较高层次上对数据进行分类聚集的抽象,这是一个逻辑概念,主要方便数据的分类管理。业务过程就是企业经营过程中一个个不可拆分的行为事件,比如仓储管理里面