1、数据仓库
1.1 数据仓库建模的意义
数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。毋庸置疑，大数据系统需要数据模型方法来帮助更好地组织和存储数据，以便在性能、成本、效率和质量之间取得最佳平衡。
1.2 数据仓库建模方法论
1.2.1 ER模型
ER模型是数据仓库之父Bill Inmon提出的建模方法，是从全企业的高度设计一个3NF模型，用实体关系（Entity Relationship，ER）模型描述企业业务，在范式理论上符合3NF。数据仓库中的3NF与OLTP系统中的3NF的区别在于，它是站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系的抽象。其具有以下几个特点：
需要全面了解企业业务和数据。
实施周期非常长。
对建模人员的能力要求非常高。
采用ER模型建设数据仓库模型的出发点是整合数据，将各个系统中的数据以整个企业角度按主题进行相似性组合和合并，并进行一致性处理，为数据分析决策服务，但是并不能直接用于分析决策。
1.2.2 维度模型
维度模型是数据仓库领域的Ralph Kimball大师所倡导的，他的The Data Warehouse Toolkit-The Complete Guide to Dimensional Modeling是数据仓库工程领域最流行的数据仓库建模的经典。
维度建模从分析决策的需求出发构建模型，为分析需求服务，因此它重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的响应性能。其典型的代表是星型模型，以及在一些特殊场景下使用的雪花模型。
其设计分为以下几个步骤：
选择需要进行分析决策的业务过程
业务过程可以是单个业务事件，比如交易的支付、退款等；也可以是某个事件的状态，比如当前的账户余额等；还可以是一系列相关业务事件组成的业务流程，具体需要看我们分析的是某些事件发生情况，还是当前状态，或是事件流转效率。
选择粒度
在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。粒度是维度的一个组合。
识别维表
选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。
选择事实
确定分析需要衡量的指标。
1.2.3 Data Vault模型
Data Vault是Dan Linstedt发起创建的一种模型，它是ER模型的衍生，其设计的出发点也是为了实现数据的整合，但不能直接用于数据分析决策。它强调建立一个可审计的基础数据层，也就是强调数据的历史性、可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合；同时它基于主题概念将企业数据进行结构化组织，并引入了更进一步的范式处理来优化模型，以应对源系统变更的扩展性。
Data Vault模型包括Hub（企业的核心业务实体）、Link（代表Hub之间的关系）、Satellite（Hub的详细描述内容）。Data
Vault模型比ER模型更容易设计和产出，它的ETL加工可实现配置化。通过Dan Linstedt的比喻更能理解Data Vault的核心思想：Hub可以想象成人的骨架，那么Link就是连接骨架的韧带，而Satellite就是骨架上面的血肉。
1.2.4 Anchor模型
Anchor对Data Vault模型做了进一步规范化处理，Lars.
Rönnbäck的初衷是设计一个高度可扩展的模型，其核心思想是所有的扩展只是添加而不是修改，因此将模型规范到6NF，基本变成了k-v结构化模型。
Anchor模型包括Anchors、Attributes、Ties、Knots四个基本对象，在此基础上，又可以细划分为历史的和非历史的，其中历史的会以时间戳加多条记录的方式记录数据的变迁历史。Anchor模型的创建者以此方式来获取极大的可扩展性，但是也会增加非常多的查询join操作。
1.2.5 模型选择
根据项目的情况和业界使用情况，选择了以Kimball的维度建模为核心理念的模型方法论作为指导，根据项目实际需求进行升级和扩展。
1.3 数仓分层
1.3.1 分层意义
数据结构清晰
每个分层都有不同的作用和职责，在使用表时方便定位和理解。
避免重复开发
规范数据分层，开发通用的中间层数据，减少重复的数据计算。
统一数据口径
通过数据分层，各个应用层做统计时直接使用中间层已经汇聚好的指标，屏蔽底层明细数据的统计逻辑，保证出口数据的口径统一。
复杂问题简单化
将一个复杂的任务分解成多个步骤，每一层解决特定的问题。
1.3.2 通用分层模型
1.3.2.1 ODS(Operational Data Store)：数据接入层
最接近数据源中数据的一层，一般直接按源头业务系统的分类进行分类，将各种结构化或非结构化的数据通过增量或全量的方式同步到这一层，根据数据业务需求保存历史数据。
为了后续可能需要追溯数据问题，对于这一层不建议做过多的数据清洗工作，和源数据保持一致即可，至于数据的去噪、去重、异常值处理等过程可以放在后面的DWD层来做。一般可以对ODS做简单的不涉及原始数据的处理，如：表和字段重命名；默认值填充；对数据的解析，如json拆分成表字段。
1.3.2.2 DW(Data Warehouse)：数据中间层
DWD(Data Warehouse Detail)：数据明细层
该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表与维表的关联。
DWS(Data Warehouse Summary)：数据汇总层
该层会在DWD层的基础上，对数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复开发。直观来讲，就是对通用的核心维度进行聚合操作，算出相应的统计指标。
DWM(Data Warehouse Market)：数据集市层
又称数据集市或宽表。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询、OLAP分析、数据分发等。一般来讲，该层的数据表会相对较少，一张表会涵盖比较多的业务内容。
DWM层与DWS层的区别在于，DWS是单业务的数据，按不同维度统计的不同窄表；DWM是跨多个业务的数据，一般是将DWS层的表拼接成大宽表。
DIM：公共维表层，一致性维度
维表中主要包含两种数据：
高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。
低基数维度数据：一般是配置表，比如编码对应的中文含义，日期维度表、或者地址维度表。数据量可能是个位数、几千或者几万。
TMP：临时数据层
一般是在开发过程中的中间表，实际中并不希望别人看到或使用，临时使用后删掉。
1.3.2.3 APP(Application)：数据应用层
这一层主要存放专用的指标和复杂性的指标（指数型、比值型、排名型），与应用有较强的耦合。主要是提供给数据产品和数据分析使用的数据，一般会存放在ES、PostgreSql、Redis等存储系统供线上系统使用，也可能会存在Hive或者Druid中供数据分析或数据挖掘使用。比如我们常说的报表数据，一般就放在这里。
1.4 规范
1.4.1 名词术语
数据域：指面向业务分析，将业务过程或者维度进行抽象的集合。其中，业务过程可以概括为一个个不可拆分的行为事件，在业务过程之下，可以定义指标；维度是指度量的环境，如买家下单事件，买家是维度。为保障整个体系的生命力，数据域是需要抽象提炼，并且长期维护和更新的，但不轻易变动。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中和扩展新的数据域。
业务过程：指企业的业务活动事件，如下单、支付、退款都是业务过程。请注意，业务过程是一个不可拆分的行为事件。
时间周期：用来明确数据统计的时间范围或者时间点，如最近30天、自然周、截至当日等。
度量/原子指标：原子指标和度量含义相同，基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名词，如支付金额。
派生指标：派生指标=一个原子指标+多个修饰词（可选）+时间周期。可以理解为对原子指标业务统计范围的圈定。如原子指标：5G激活量，最近1年全国激活量则为派生指标（最近1年为时间周期，全国为修饰词）。
1.4.2 命名规范
所有名称只能使用英文、数字、下划线命名，不能以下划线开头。尽量使用英文简写，其次是英文，当指标英文名太长时，可考虑用汉语拼音首字母命名。需要维护一份常用命名规范元数据，以用来进行规范命名。
1.4.2.1 表
命名规则：层级_数据域_业务过程_业务逻辑_时间周期_序号(2位，如01)如dws_dmp_label_comb_calc_all_01
dws：层级，数据汇总层。
dmp：数据域，英文简写。
label：业务过程，标签，英文名称
comb_calc：标签下的组合计算，可以根据业务逻辑根据规范自由命名。
all：时间周期，表示全量。
01：序号，两位数字。
层级、数据域、业务过程、时间周期都维护在一张元数据表中，如dim_standard_metadata。
1.4.2.2 指标
原子指标：英文名，动作+度量；中文名，动作+度量。如支付金额、销售量。如激活量：activation_amount
派生指标：英文名，修饰词_原子指标英文名_时间周期_序号（2位，如_01）；中文名，时间周期修饰词+[其他修饰词]+原子指标。如近1年5G激活量：5G _activation_amount_1y_01。
1.4.2.3 任务
命名规则：目标表名_调度周期，如dws_dmp_label_comb_calc_all_01_d
dws_dmp_label_comb_calc_all_01：目标表名
d：表示每天调度
1.4.3 流程规范
2、元数据管理
2.1 元数据概述
元数据（Metadata）是关于数据的数据。元数据打通了源数据、数据仓库、数据应用，记录了数据从产生到消费的全过程。元数据主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及ETL的任务运行状态。在数据仓库系统中，元数据可以帮助数据仓库管理员和开发人员非常方便地找到他们所关心的数据，用于指导其进行数据管理工作和开发工作，提高工作效率。
将元数据按用途不同分为两类：技术元数据（Technical Metadata）和业务元数据（Business Metadata）。
2.1.2 技术元数据
技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据。
数据表元数据
主要包括表名、分区信息、责任人信息、文件大小、表类型、表描述、生命周期，以及字段名、字段类型、字段备注、是否是分区字段等信息。
作业运行元数据
主要包括实例名称、作业类型、输入输出、SQL、运行参数、执行时间、运行状态等执行信息。
数据同步、计算任务、任务调度等信息
包括数据同步的输入输出表和字段，以及同步任务本身的节点信息；计算任务主要有输入输出、任务本身的节点信息；任务调度主要有任务的依赖类型、依赖关系等，以及不同类型调度任务的运行日志等。
数据质量和运维相关元数据
任务监控、运维报警、数据质量、故障灯信息，包括任务监控运行日志、告警配置及运行日志、故障信息等。
2.1.2 业务元数据
业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。
系统元数据，如维度及属性、业务过程、指标等的规范化定义，用于更好的管理和使用数据。
数据应用元数据，如数据报表、数据产品等的配置和运行元数据。
2.2 元数据应用
2.2.1 数据资产
库、表、字段的展示和查询。
2.2.2 任务可视化
提供任务相关的查询和展示，如任务运行情况：状态、时长等；任务详情：任务对应脚本、目标表、依赖任务、调度周期、创建人等。后期还可以添加自定义任务、修改任务等服务。
2.2.3 元数据服务系统
提供各种技术元数据和业务元数据的增、删、改、查服务，如命名规范中层级、业务过程、时间周期、调度周期等。初期可以先提供各种规范命名的增、删、改、查服务，这个可以根据需要不断扩展，可以再添加各种指标、维度等业务相关元数据的增、删、改、查数据服务。
2.2.4 血缘链路分析
通过应用链路分析，获取表级、字段级血缘关系，并可以在前端页面可以查询展示。常见的应用链路分析应用主要有影响分析、重要性分析、下线分析、链路分析、寻根溯源、故障排查等。
这个功能工作量比较大，可以考虑使用开源组件。
3、数据质量管理
业界普遍认可的数据质量定义为：数据对其期望目的的适合度。即：数据质量管理生命周期及其相关的数据质量管理流程，都要为确保数据满足其自身的预期目标提供相应的方法和手段。数据质量管理需要确保数据能够正确、及时的支持企业经营决策
3.1 数据质量指标的定义与评估
根据业务应用场景需要，对各个报表的结果数据定义重要、全面、合理的质量监控指标，比如报表数据量、关键字段数据范围，报表任务完成时间和时长等。定义的监控指标需要能够确保合理、快速的评估报表的结果是否出现异常。质量监控指标能否能够评估数据是否异常决定着数据质量管理的准确性，需要数据应用、数据设计等多方参与。指标可以考虑以下几个方面：
a) 完整性：数据缺失、字段值缺失
b) 唯一性：记录是否重复，是否发散
c) 一致性：指标统计口径是否一致，数据逻辑加工结果一致性
d) 准确性&合理性：主要包括格式、类型、值域和业务规则是否准确
e) 及时性：报表结果数据是否及时
3.2 数据质量的监控与反馈
通过监控报表的跑数任务，判断报表任务是否出现异常或者是否在预计时间内完成。如果报表未在预计合理的时间范围跑完，需要反馈给相关责任人；如果报表任务正常，任务在跑完后需要对报表结果统计各个质量监控指标，评估报表结果数据是否出现异常或者不合理，一旦出现需要立即反馈给相关责任人。
3.3 数据质量监控可视化及任务优化
将数据质量监控指标的结果在前端页面展示和查询，以方便各方人员查看，同时定期跟进和评估数据质量的总体情况，定期生成质量报告。也可以根据结果对报表任务进行业务逻辑和实现过程的优化，不断提升数据质量。