关于构建数据仓库的几个问题

写在前面

数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。近年来，随着大数据的应用不断深入，构建企业级数据仓库成为了企业进行精细化运营的一种趋势。

从管理者的视角来看，数据仓库是赋能业务并辅助决策的一种工具，从开发者的视角来看，数据仓库是一堆数据模型的集合。数仓开发是一个系统工程，涉及数据集成、数据建模、数据开发、数据服务、任务调度、元数据管理、数据质量管理(DQC)等一系列的流程。另外，由于数据跟业务是息息相关的，所以在构建数仓的时候，需要对业务有一个非常深刻的理解。

值得注意的是，数仓的建设不是一蹴而就的，也没有毕其功于一役的方法，业务的不断变化决定了数仓是在不断迭代中进行完善的。从这个层面上来讲，或许永远没有完美的数仓。由于人员的流动、业务的变化以及前期的系统性建设不足，数仓总会存在这样或那样的问题。

或许我们可以用"是否成熟"描述数仓的建设，那么什么是成熟的数仓呢，我们不妨换个角度思考一下：什么是一个不成熟的数据仓库？此时你的脑海里是否会蹦出一个词，那就是混乱。是的，一个不成熟的数仓虽然具备了部分数仓规范，但在具体的落地实施过程中，并未能完全按照规范操作， 导致数据仓库建设比较混乱，比如数据域划分不清楚、数仓分层不明确、数据任务随意依赖、数据重复开发等等问题。迫于业务快速变化以及日常数据开发需求的压力，造成了数据开发没有太多的时间和精力去顾及这些问题，最终形成了一个不成熟的数仓。一旦出现了这些问题，后续就需要有专门的数据治理团队去规划并规范数仓的建设。

所以，假设你接手了一个不成熟的数仓项目，或者你觉得目前的数仓建设还不够成熟，那么不妨思考一下几个问题：

• 定目标
• 选技术
• 找问题
• 划主题
• 识分层
• 理建模
• 制规范

定目标

数仓设计目标包括数仓分层清晰，字段与模型命名规范，具备较高可复用性与可维护性，能够快速响应产品运营层面的数据分析需求，以数据驱动产品迭代与业务增长。

数仓设计的过程中，坚持用户驱动与数据驱动相结合的设计理念，即一方面根据当前的业务数据的基础和质量情况，以数据源分析为出发点构建数据仓库；另一方面根据业务的方向性需求，从业务需要解决的具体问题出发，确定系统范围和需求框架。

选技术

数据仓库是一个复杂系统，会涉及到一系列的流程，由此不可避免的会使用很多的技术框架。目前，行业中使用的常见工具主要包括：数据同步工具、数据处理工具、任务调度工具、报表工具、元数据管理工具、质量管理平台(DQC)以及大数据基础平台等等。

如果是自建的大数据平台，或者是没有一个大数据开发平台，这种情况下需要数仓开发人员具备丰富的技术栈，既要兼顾技术的集成使用，又要兼顾数仓的建设与业务需求的开发。如果使用的是已经集成好的开发套件，比如阿里云的dataworks，这样数仓的开发人员会更加聚焦数仓的建设，而不是在各种技术的集成过程中踩坑而分散过多的精力。

找问题

前文已经提到没有完美的数仓，其实数仓的建设并没有对与错之分，只有好与坏之差。我们不能一味的使用拿来主义的方式去构建数据仓库，数据仓库建设能否成功会涉及很多的因素，数仓建设的方法论是指引我们的一个方向，万万不可迷失其中。一言以蔽之，合适就好。

在接手不成熟的数仓时，需要梳理存在的一些问题，而这些问题一般情况下都大同小异，常见的一些问题主要包括：

• 数仓分层不清晰
• 数据域划分不明确
• 模型设计不合理
• 代码不规范
• 命名不统一

划主题

主题域是业务过程的抽象集合，是在较高层次上对数据进行分类聚集的抽象，这是一个逻辑概念，主要方便数据的分类管理。业务过程就是企业经营过程中一个个不可拆分的行为事件，比如仓储管理里面