数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。近年来，随着大数据的应用不断深入，构建企业级数据仓库成为了企业进行精细化运营的一种趋势。
从管理者的视角来看，数据仓库是赋能业务并辅助决策的一种工具，从开发者的视角来看，数据仓库是一堆数据模型的集合。数仓开发是一个系统工程，涉及数据集成、数据建模、数据开发、数据服务、任务调度、元数据管理、数据质量管理等一系列的流程。另外，由于数据跟业务是息息相关的，所以在构建数仓的时候，需要对业务有一个非常深刻的理解。
值得注意的是，数仓的建设不是一蹴而就的，也没有毕其功于一役的方法，业务的不断变化决定了数仓是在不断迭代中进行完善的。或许永远没有完美的数仓。由于人员的流动、业务的变化以及前期的系统性建设不足，数仓总会存在这样或那样的问题。
或许我们可以用”是否成熟”描述数仓的建设，那么什么是成熟的数仓呢，我们不妨换个角度思考一下：什么是一个不成熟的数据仓库?此时你的脑海里是否会蹦出一个词，那就是混乱。是的，一个不成熟的数仓虽然具备了部分数仓规范，但在具体的落地实施过程中，并未能完全按照规范操作， 导致数据仓库建设比较混乱，比如数据域划分不清楚、数仓分层不明确、数据任务随意依赖、数据重复开发等等问题。迫于业务快速变化以及日常数据开发需求的压力，造成了数据开发没有太多的时间和精力去顾及这些问题，最终形成了一个不成熟的数仓。一旦出现了这些问题，后续就需要有专门的数据治理团队去规划并规范数仓的建设。
所以，假设你接手了一个不成熟的数仓项目，或者你觉得目前的数仓建设还不够成熟，那么不妨思考一下几个问题：
定目标 选技术 找问题 划主题 识分层 理建模 制规范
定目标数仓设计目标包括数仓分层清晰，字段与模型命名规范，具备较高可复用性与可维护性，能够快速响应产品运营层面的数据分析需求，以数据驱动产品迭代与业务增长。
数仓设计的过程中，坚持用户驱动与数据驱动相结合的设计理念，即一方面根据当前的业务数据的基础和质量情况，以数据源分析为出发点构建数据仓库;另一方面根据业务的方向性需求，从业务需要解决的具体问题出发，确定系统范围和需求框架。
选技术
数据仓库是一个复杂系统，会涉及到一系列的流程，由此不可避免的会使用很多的技术框架。目前，行业中使用的常见工具主要包括：数据同步工具、数据处理工具、任务调度工具、报表工具、元数据管理工具、质量管理平台以及大数据基础平台等等。
如果是自建的大数据平台，或者是没有一个大数据开发平台，这种情况下需要数仓开发人员具备丰富的技术栈，既要兼顾技术的集成使用，又要兼顾数仓的建设与业务需求的开发。如果使用的是已经集成好的开发套件，比如阿里云的datawoRks，这样数仓的开发人员会更加聚焦数仓的建设，而不是在各种技术的集成过程中踩坑而分散过多的精力。
找问题
前文已经提到没有完美的数仓，其实数仓的建设并没有对与错之分，只有好与坏之差。我们不能一味的使用拿来主义的方式去构建数据仓库，数据仓库建设能否成功会涉及很多的因素，数仓建设的方法论是指引我们的一个方向，万万不可迷失其中。一言以蔽之，合适就好。
在接手不成熟的数仓时，需要梳理存在的一些问题，而这些问题一般情况下都大同小异，常见的一些问题主要包括：
数仓分层不清晰 数据域划分不明确 模型设计不合理 代码不规范 命名不统一
划主题
主题域是业务过程的抽象集合，是在较高层次上对数据进行分类聚集的抽象，这是一个逻辑概念，主要方便数据的分类管理。业务过程就是企业经营过程中一个个不可拆分的行为事件，比如仓储管理里面有入库、出库、发货、签收，都是业务过程，抽象出来的主题域就是仓储域。主题域划分要尽量涵盖所有业务需求，保持相对稳定性，还具备一定的扩展性，新加入一个主题域，不影响已经划分的主题域的表。有了主题域之后，每个数据模型也就有了一个归属，这样数据组织会更加的清晰，同时也比较方便维护。
识分层
数仓为什么要分层
合理的数据仓库分层一方面能够降低耦合性，提高重用性，可读性可维护性，另一方面也能提高运算的效率，影响到数据需求迭代的速度，近而影响到产品决策的及时性。建立数据分层可以提炼公共层，避免烟囱式开发，可见一个合适且合理的数仓分层是极其重要。
通用分层设计思路
ODS:操作型数据(operational Data STore)，指结构与源系统基本保持一致的增量或者全量数据。作为DW数据的一个数据准备区，同时又承担基础数据记录历史变化，之所以保留原始数据和线上原始数据保持一致，方便后期数据核对需要。 CDM：通用数据模型，又称为数据中间层(CoMMon Data Model)，包含DWD、DWS、DIM层。 DWD：数据仓库明细层数据(Data WaRehouse DetAIl)。对ODS层数据进行清洗转化，以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细事实表。可以结合企业的数据使用特点，基于维度建模思想，将明细事实表的某些重要属性字段做适当冗余，也即宽表化处理，构建明细宽表。 DWS：数据仓库汇总层数据(Data WaRehoUSe SuMMaRy)，基于指标需求，构建初步汇总事实表，一般是宽表。基于上层的应用和产品的指标需求，构建公共粒度的汇总指标表。以宽表化手段物理化模型，构建命名规范、口径一致的统计指标，为上层提供公共指标。 DIM：建立一致数据分析维表，可以降低数据计算口径不统一的风险，同时可以方便进行交叉探查。以维度作为建模驱动，基于每个维度的业务含义，通过添加维度属性、关联维度等定义计算逻辑，完成属性定义的过程并建立一致的数据分析维表。 ADS：面向应用的数据服务层(application Data SeRvice)。整合汇总成分析某一个主题域的服务数据，面向应用逻辑的数据加工。该层主要存放数据产品个性化的统计指标数据，这一层的数据直接对接数据的消费者，是产品、运营等角色可以直接感知理解的一层，大多数这一层的表都可以直接在BI上通过图表的形式直接透出。
分层辨析
ODS层
ODS层的概念主要体现在两个方面：
操作型系统的集成，用于当前、历史以及其它细节查询(业务系统的一部分) 为决策支持提供当前细节数据(数据仓库的一部分)
ODS是用于支持企业日常的全局应用的数据集合，ODS的数据具有面向主题、集成的、可变的以及数据是当前的或是接近当前的特点。同样也可以看出ODS是介于DB和DW之间的一种过渡存储。
值得注意的是，KiMball所说的ODS是物理落地关系型数据库中，但是在实际生产应用中，ODS往往是物理落地在数据仓库中，比如Hive。
通常来说ODS是在数据仓库中存储业务系统源数据，所以从数据粒度、数据结构、数据关系等各个方面都与业务系统的数据源保持一致。但是，也不能仅仅将ODS层看做是业务系统数据源的一个简单备份，ODS和业务系统数据源的差异主要是由于两者之间面向业务需求是不同的，业务系统是面向多并发读写同时有需要满足数据的一致性，而ODS数据通常是面向数据报表等批量数据查询需求。
关于ODS层与业务系统DB的主要区别，体现在一下几个方面：
数据存储方式方面。由于性能压力，业务DB需要对同一个逻辑表进行分表分库操作，而ODS会将业务系统中同一个逻辑表统一到一个物理实体中存储 数据存储介质方面。业务系统通常用oRalce、MYsQL、DB2等以事务性处理见长关系型数据库系统，ODS通常存储在以Hadoop为代表的分布式系统中，比如Hive等等。 数据组织形式方面。业务系统表通常需要遵循三范式，并且需要创建复杂的索引结构来提升查询效率，但是ODS层的表通常没有索引。
ODS层的数据同步通常会使用数据库直连抽取或者数据库日志抽取的方式，在设计ODS物理表时，在表命名、数据存储等方面都需要遵循一定的准则。比如：不管是表命名还是字段命名尽量和业务系统保持一致，但是需要通过额外的标识来区分增量和全量表，”delta”来标识该表为增量表。另外，为了满足历史数据分析需求，我们需要在ODS表中加一个时间维度，这个维度通常在ODS表中作为分区字段。如果是增量存储，则可以按天为单位使用业务日期作为分区，每个分区存放日增量的业务数据。如果是全量存储，只可以按天为单位使用业务日期作为分区，每个分区存储截止到当前业务时间的全量快照数据。
DWD层
DWD层的数据一般存放明细事实表，为了提升访问便利性和访问性能，在维度模型的事实表基础上，将部分常用维度冗余到事实表，从而形成宽表模型。
明细事实表的设计有五个步骤：选择业务过程—>确定粒度—>选择维度—>确定事实(度量)—>冗余维度。
DWS层
以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标表。以宽表化手段物理化模型，构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表。如：形成日，周，月粒度汇总明细，或者基于某一个维度，如商品类目粒度的汇总日表，统计便于下一步报表数据结构的组织。
关于汇总层的表建模应遵循以下的原则：
数据公用性比如，汇总的聚集表能否与他人公用?基于某个维度的聚集是否是数据分析或者报表中经常使用的?如果满足这些情况，我们就有必要把明细数据沉淀到汇总表中。 不跨数据域数据域是在较高层次上对数据进行分类聚集的抽象，如交易统一划到交易域下，商品的新增、修改放到商品域下。
