目录
近两年有一部分工作是在数仓建模的工作，临近年底，写了一些个人想法，也希望能跟更多的朋友交流，出于公司保密条款考虑，文中的图都从公开资料中引用。
在正式谈数仓建模前，先谈下架构这块。以TOGAF为例，包含业务架构、应用架构、数据架构以及技术架构。这里的数据架构主要是描述逻辑数据（信息）资产结构、物理数据资产架构、数据管理资源；引导应用架构和技术架构。
这张图相比于元内容模型简化了下，更好理解。
业务架构以价值链为主线，第一、二层是业务领域和业务阶段，是业务功能的分组。第3-5层是执行层流程。第三层是业务活动，创造价值的端到端流程，如针对客户信息管理，业务活动主要包含获取新客-采集客户信息-建立客户视图-识别客户-拆分、合并客户-维护内控客户信息。第四层是活动任务，是部门或业务单位为完成三级流程所需要的不同角色完成的具有明确业务目的的事情，可以理解为产品需求文档中的功能模块。第五层是操作步骤，可以对应到具体步骤。
数据架构需要更为详细的一张图来说明。‘
这里企业架构中的数据架构，分为面向业务需要和面向数据应用的数据架构设计。其中数据对象是对数据自身的建模，例如业务中使用的各种主数据、元数据、聚合数据、分析数据等；数据组件是对数据活动中所需的处理工序建模；数据服务关注在对需求的定义以及场景中对服务水平的要求。
（1）操作型数据区
从左侧看起，这里涉及到新老核心系统混合的情况，与目前个人所处的公司比较相似，新老数据，特别是核心数据，就不得不涉及数据管理的工作了，特别是参考数据、主数据、元数据的统一都可能面临挑战。我们采用数据管理系统对 参考数据、元数据做了约束（真正推进起来其实非常痛苦），主数据则散落在相关核心子系统，如产品主数据，客户主数据。
（2）数据采集和交换平台
数仓与业务系统数据交互，可以采用多种方式，常用的有主动数据集成（如何Dataworks有书数据集成模块，包含离线（DataX）和实时）、卸数等。对于卸数，业务系统把文件定时上传到该平台，数仓开发可以自行解析文件写入技术缓冲层。
（3）大数据平台
图中分了4层，其实对应到了大家经常说的STG-ODS-DWD-DWS。集成有全量和增量两种方式。如果是增量同步，可以在当日将前一日全量分区和当日增量分区做merge，这里merge的逻辑以及增量逻辑就和操作型数据区业务系统数据模型设计息息相关了，可以在数据管理系统里做约束。
（4）历史数据区
这里个人对应到了冷数据，如针对5年+以前的数据存入历史数据区，降低存储成本。STG、ODS、DWD也都有各自数据的存储周期。
（5）集市和分析型数据区
目前比较火的数据中台倡导把数据产品化、服务化。与上图的思路不太一致，上图可能不够直接。不过能表达清楚意思就行。
实践时使用了维度建模，但在谈维护建模前，想先介绍了传统数据建模的思路，更多的是一种提高抽象能力的方式。以金融行业为例，国内金融业使用的比较多是TD（天睿）的FS-LDM，作为EDW建设的指导理论，初看起来比较抽象，真正做起来就逐渐清晰了。如下图所示。也支持扩展，如保险里会把理赔（claim）这一核心业务抽成一个单独的主题。
这里涉及到了FS-LDM术语和业务术语的一个转换，以协议为力，业务中的保单、合同、账户都是协议，客户/账户持有人或家庭/中介/代理/汽修店等都是当事人，事件对应业务中的交易。
数据是描述事物的符号记录，而模型是对现实世界的抽象，所以数据模型就是抽象描述现实世界的一种工具和方法。
数据结构（描述数据的类型、内容、性质以及数据间联系）、数据操作（对数据库中各种对象所允许的操作）、完整性约束（数据结构内语法词义联系等）。
（1）概念数据模型（CDM，主要实体和关系）
（2）逻辑数据模型（LDM，以图形方式，通过数据和关系反应业务，CDM+数据+主外键+数据约束+属性）
（3）物理数据模型（描述数据在实际存储时的组织结构，LDM+字段类型+冗余等）。实际的工作过程是通过源系统调研，做了表级、字段级分析后，进行建模工作设计LDM，考虑过细粒度子分类进行上收或合并，增加PDM需要的表/字段，考虑大表拆分、当前表以及历史轨迹表，根据需求增加冗余字段或派生字段，考虑分区、压缩等。
阿里的大数据之路中给出了维度建模建议的实施工作流，下面结合这个工作流介绍下实际工作中的输出物与要点。
业务调研：了解所在公司的各个业务线、业务模块、业务系统做调研，这里可以参考1.1企业架构中业务架构（分5层，可以把业务线、业务模块说得很清楚）。我们实际工作还会输出业务过程矩阵（也叫数据实体/业务职能矩阵），这是与业务、业务系统PD、架构反复沟通的结果。如下图所示。
数据调研： 与业务、分析师沟通需求，对现有报表进行梳理。通过这两种途径，梳理出常用的指标、维度（按照指标拆分逻辑，派生指标=原子指标+时间修饰词+业务修饰词+维度类型），借此思考哪些可以沉淀到DWS层，哪些适合在报表工具上做汇总，同时指标、维度也会成为数据治理的重要输入，纳入数据资产目录。
面向业务分析，将业务过程或维度进行抽象，划分的原则是既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域或相对容易地扩展新的数据域。这里的抽象方式可以部分借鉴FS-LDM，在它的基础上把业务在脑中抽象完，再按照维度建模理论划分数据域。在一个业务过程中会涉及到一个或多个业务实体。
在充分调研基础上，可以构建数据总线矩阵，明确每个数据域下有哪些业务过程；业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。实际做时可以细化这个模版，如可以对业务过程分级等。
构建指标体系，包含派生指标、原子指标、时间周期、业务修饰词。概念上常用的有原子指标/派生指标（也叫衍生指标，都对应英文derivate）和基础指标/复合指标，基础指标包含原子指标和派生指标，复合指标是由多个基础指标加工而来。
2.3.5.1 维度表
（1）概念
维度是维度建模的基础和灵魂，用于分析事实所需要的多样环境，数据分层架构对应CDM中DIM层。按照维度结构可分为普通维度、递归层次维度、行为维度、多值维度、多值属性和杂项维度。
（2）缓慢变化维度的处理方式
维度按照变化快慢可分为无变化维度、缓慢变化维度和剧烈变化维度。下面主要针对出现较多的缓慢变化维来说明。为了说明应对维度变化的情况，我们先说明维度主键的选择。
这里有两个概念，代理键（不具有业务含义的键，一般用于处理缓慢变化维）和自然键（具有业务含义的键）。但需要注意的是分布式系统中，事务的成本很高（CAP原理，选择了AP，牺牲了C一致性），对于每个表的记录生成稳定（幂等）的全局唯一的代理键难度大。
另外，使用代理键，增加ETL复杂性，因为如果事实表中包含的是代理键，那每次事实表的ETL作业有时不得不作为维度表加工的下游。因此在使用时我们也会用自然键。每日全量，通过限定日期来选择使用历史的还是最新的维度信息。只是这样带来大量的存储浪费（项目刚开始时可以暂时采用粗暴的每日分区的存储模式，一是项目上线要求，二是很多公司维度表量并不大，后续可以逐步来调整）。为了降低存储，引入了极限存储的概念。
历史拉链：历史拉链存储是指利用维度模型中缓慢变化维度的第二种方式（第一种每日全量分区）。增加start_dt和end_dt两个时间戳字段，以天为粒度把所有变更都存储下来，分区字段是时间戳字段。举个栗子：
这里会存在两个问题，一是使用不方便，比如我们要访问2010-6-1号的数据，过滤条件是start_dt<=2010-6-1且end_dt>2010-6-1。二是分区数过多，比如一年的拉链表最大的分区数可以达到365*（365-1）/2+365=66795个。
针对第一个问题，可以建个视图，或者如书中所说自定义钩子函数。
针对第二个问题，采用极限压缩的思路，每月月初重新开始做历史拉链。同时会在每个月的第二天，需要将上个月的未过期数据迁移到下一个月，并使用当月1日作为start_date。共12*(31*(31-1)/2+31) = 5952 个分区。更详细的可以查看这里的讲解：极限存储综合实践 - Eric-Ln - 博客园前言 本文主要参考淘宝极限存储方案，并结合其他参考文章，总结实践。 整体演示 user （源数据用户表，伪码）: create table user ( id bigint, status
https://www.cnblogs.com/eric-ln/p/12737625.html
（3）维度识别、处理
前面我们更多的是谈到维度的概念以及缓慢变化维的处理方式。在建模过程中，我们可以对DIM层划分子主题，常用的主题有产品、组织、账户等，用户作为单独的数据域。也有公司将用户作为一个大的DIM表来维护和使用，见仁见智。
另外，在实际报表开发时会存在一些自定义维度，如业务要求按照自己的规则对客户分级作为报表上的维度，这类维度只在ADS层使用。另外，退化维度这里比较简单，不再赘述了。
2.3.5.2 事实表
事实表是维度建模的核心，我们在梳理数据总线过程中，会对业务过程做分析、整理，明确业务过程中各实体的粒度以及相关的一致性维度。基于此，可以设计出事实表，一张是事实表可对应一个或多个业务过程（业务过程划分较细的情况下），当然，也有无事实的事实表（如事件累的，埋点数据中的用户点击事件等；维度与维度之间的关系，如销售员和客户的分配关系）。
事实表的设计原则可以参考大数据之路那本书，这里需要注意的是避免多粒度混合。事实表分为：
（1）事务事实表
分单事务和多事务（近似的相近的业务过程度量合并，用label字段来区分）。
（2）周期快照事实表
事实和周期快照往往是成对出现的，相互补充。周期快照通常是为了满足下游需求而设计。物理实现依据周期而定。
（3）累积快照事实表
对于研究事件之间时间间隔的需求，采用累积快照事实表来解决。如保险理赔过程就可以设计出一张累积快照事实表，从接报案-查勘-定损-理算-核赔-支付-结案。来分析案件的处理情况。这里的物理实现有三种，全量表/近xx天的全量表/以业务实体的结束时间分区。
在实践中，事实表需要紧密结合业务来设计，我们总是在迭代中不断接近局部最优解（面向需求）。
OneData的实施过程是一个高度迭代和动态的过程，在总体架构设计完成后，开始根据数据域进行迭代式模型设计和评审。在架构设计、规范定义和模型设计等模型实施过程中，引入评审机制，接受挑战，在实施中不断修正。
----------------------------------------------------------------分割线-------------------------------------------------------
除了总结日常工作，外部的参考资料如下：
Thoughtworks官方公开文档
阿里巴巴大数据之路
