数仓基础

数据仓库是面向分析的数据集合。它和业务数据库（OLTP）解决的是完全不同的问题：业务库要支撑「用户下一单」这样的高并发小事务，数仓要支撑「算出上个季度各区域各品类的销售趋势」这样的大范围扫描聚合。这个差异决定了两者从建模到存储的一切取舍。

• 数据库用于OLTP，主要用于操作型处理 数据库是面向事物处理的，数据是由日常的业务产生的，常更新；数据库一般用来存储当前事务性数据，如交易数据、业务数据；数据库的设计一般是符合三范式的，有最大的精确度和最小的冗余度，有利于数据的插入；
• 数据仓库用于OLAP，支持管理决策。数据仓库是面向主题的，数据来源多样，经过一定的规则转换得到，用来分析。数据仓库一般存储历史数据。数据仓库的设计一般不符合三范式，并且反规划范，有利于查询。

• 范式建模主要用于关系性数据库的数据存储，主要用于业务系统，分为实体表与关系表，可以解决数据冗余，插入，修改，删除异常的问题。围绕实体表与关系表。目前OLTP业务系统中大多采用的是三范式建模法。特点：设计思路自上而下，适合上游基础数据存储，同一份数据只存储一份，没有数据冗余，方便解耦，易维护，缺点是开发周期一般比较长，维护成本高。
• 维度建模主要包括雪花模型、星型模型、星座模型，围绕事实表和维度表进行，利用维度建模方法建设一致维度的数据集市。通过一致性维度可以将数据集市联系在一起，由所有的数据集市组成数据仓库。特点：构建迅速，最快的看到投资回报率，敏捷灵活；

一句话概括：事实表存度量，维度表存上下文。分析的本质就是「按某些维度，对某些度量做聚合」——比如「按地区（维度）汇总销售额（度量）」。

事务型事实表（Transactional Fact Table）

• 记录每一笔业务事件，一行就是一次交易/一次行为，比如订单事实表、支付事实表。
• 粒度细、数据量大，适合做明细分析、漏斗分析。

快照型事实表（Periodic Snapshot Fact Table）

• 按固定周期（天/周/月）对业务状态做截面快照，一行代表某个周期某个对象的状态，比如每天的账户余额快照、每天的库存快照。
• 适合做趋势分析、周期对比。

累计型快照事实表（Accumulating Snapshot Fact Table）

• 描述一个生命周期过程的各个关键节点，通常一行从“创建”到“完成”会不断补充字段，比如订单从创建、支付、发货、签收的完整流程。
• 适合分析流程时长、各节点转化率、流程瓶颈。

汇总型事实表（Aggregated / Summary Fact Table）

• 在事务事实基础上按某些维度（如用户、天、品类）做预聚合，一行就是已经汇总好的指标，比如“用户-日”粒度的活跃与消费金额。
• 主要用于报表和高性能查询。

维度表记录「是谁、在哪、什么东西」——用户、商品、地区、时间。特征是行数相对少、描述性字段多，用来给事实打标签、做筛选和分组。维度建模方式包括以下三种：

• 星型模型：一张事实表，根据主键关联多张一级维度表，星型架构是一种非规范化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余。很多统计查询不需要做外部的连接，通过冗余换取运行效率。
• 雪花模型：雪花模式是星型模式的扩展，其中某些维表被规范化，进一步分解到附加维度表中。优点是：通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。
• 星座模型：星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。常用于数据关系更复杂的场景。也称事实星座模型。

三者的比较：

- 雪花模型在维度表、事实表之间的连接很多，因此性能方面会比星型模型低。

- 雪花模型使用的是规范化数据，数据冗余来减少数据量。其维度层级和维度信息都存储在数据模型之中。星形模型是反规范化数据，数据存在冗余，维度直接关联事实表，维度层级清晰明了。

- 雪花模型在设计上更加复杂，由于附属维度的限制，ETL复杂且不能并行化。星形模型加载维度表，不需要添加附属维度层级，ETL相对简单，可以实现高度的并行化。

- 雪花模型使得维度分析更加容易，比如“针对特定的广告主，有哪些客户或者公司是在线的?”。星形模型用来做指标分析更适合，比如“给定的一个客户他们的收入是多少?”

数仓不会从原始数据一步算到报表，而是分成若干层逐级加工。典型是 ODS（原始数据）→ DWD（明细清洗）→ DWS（轻度汇总）→ ADS（应用结果），旁边挂一层 DIM（维度）。

• ODS（贴源层）：把源系统数据原样或近原样接入数仓。 特点：字段、含义尽量贴近源系统；少做业务加工，最多做格式统一、分区落地、增量同步。 目的：留底、可追溯、方便排查「源里到底长什么样」。 例子：订单原始表、用户注册原始表、埋点原始日志。
• DIM（维度层）：沉淀相对稳定、会被反复关联的「描述性信息」。 特点：粒度通常是实体主键（用户、商品、门店、地区等）；更新频率往往低于事实明细。 目的：避免每个明细/汇总任务都各自去拉一遍维表逻辑，保证口径一致。 例子：用户维表、商品维表、城市维表、活动维表。
• DWD（明细层）：在 ODS 之上做清洗、标准化、去重、异常处理，并常关联 DIM，形成业务含义清晰的明细事实。 特点：保留业务过程的明细粒度（一笔订单、一次点击、一次支付）。 目的：成为全仓最核心的「可信明细底座」，供上层复用。 例子：订单明细事实表、支付明细事实表、曝光点击明细表。
• DWS（汇总层）：在 DWD（和 DIM）之上，按主题、时间、维度做公共聚合。 特点：粒度变粗（按天/周、按用户/商品/渠道等）；沉淀可复用中间结果，而不是某个报表专用结果。 目的：减少重复计算，统一常用指标中间层。 例子：用户日活汇总、商品日销汇总、渠道转化漏斗日表。
• ADS（应用层）：面向具体场景再加工，直接服务报表、产品接口、运营看板、算法特征等。 特点：业务定制强、变化快；可以牺牲通用性换取易用性和性能。 目的：让下游「拿来就能用」，不必再理解底层复杂加工。 例子：某运营看板宽表、某大促实时大屏结果表、某 App 首页推荐特征表。

分层看似增加了存储和计算，但换来三件事：复用（中间结果被多个下游共用，不必重复计算）、隔离（上游表结构变化只需改动相邻一层，不会击穿到所有报表）、可排查（数据出错时能逐层比对，快速定位是哪一步引入的）。

在数仓中，表往往会被划分成两种类型，一种是事实表，另一种是维度表。在维度表当中有一些维度是不变，比如：性别；但是有一些维表数据不是静态不变的，而是随时间缓慢变化的。比如最常见的部门变更，一个员工最初是在部门1工作，后面转到了部门b这是缓慢变化维的一种可能这种维度变化。在数仓中，这种维表定义为Slowly Changing Dimensions，简写SCD，翻译过来就是缓慢变化维。

• 直接覆盖：不记录历史数据，薪数据覆盖旧数据
• 新加一行数据（纵向扩展）：使用代理主键+生效失效时间或者是代理主键+生效失效标识（保存多条记录，直接新添一条记录，同时保留原有记录，并用单独的专用字段保存）
• 新加两个字段（横向扩展）：一个是previous，一个是current，每次更新只更新这两个值，但是这样职能保留最近两次的变化（添加历史列，用不同的字段保存变化痕迹，因为只保存两次变化记录，使用与变化不超过两次的维度）
• 通过拉链表

拉链表是什么：记录数据的历史状态以及变化记录。记录一个事物从开始，一直到当前状态的所有变化的信息。拉链表可以避免按每一天存储所有记录造成的海量存储问题，同时也是处理缓慢变化数据的一种方式。

开链与闭链拉链表中每条数据都有starttime列和endtime列，根据此来控制当前数据的状态并且获取历史的变化情况。

• 开链：拉链表在初始化完成后，或者存在更新数据，则拉链表中当前数据的starttime为最新时间，endtime为9999-12-31，表示当前数据的状态为最新状态。
• 闭链：拉链表中的数据如果存在更新，首先会对被更新数据进行闭链操作，然后再添加开链数据。闭链操作为将被更新的数据endtime改为当前时间，表示此条数据的历史状态被定格在endtime。以后根据end_time即可获取数据在指定日期的状态值。

1、全量表每天的所有的最新状态的数据。

• 全量表，有无变化，都要报
• 每次上报的数据都是所有的数据（变化的 + 没有变化的）

2、增量表新增数据，增量数据是上次导出之后的新数据。

• 记录每次增加的量，而不是总量；
• 增量表，只报变化量，无变化不用报
• 业务库表中需有主键及创建时间，修改时间

3、流水表对于表中的每一个修改都会记录，可以用于反映实际记录的变更，主要用于数据变化状态。

4、拉链表维护历史状态，以及最新状态数据 适用情况：

• 数据量比较大
• 表中的部分字段会被更新
• 需要查看某一个时间点或者时间段的历史快照信息 查看某一个订单在历史某一个时间点的状态 某一个用户在过去某一段时间，下单次数
• 更新的比例和频率不是很大 如果表中信息变化不是很大，每天都保留一份全量，那么每次全量中会保存很多不变的信息，对存储是极大的浪费

1. 数据分类：首先是针对各数据进行归类，根据业务需求划分成不同的类别，然后将数据表依次归类。
2. 时间字段治理：在所有数据中添加统一名称的时间字段，依次记录数据发生时间、最后更新时间、插入时间等。
3. 数据过滤：在入库时如果碰到无法解析的错误数据，或者关键字段缺失的数据，则直接丢弃。
4. 数据去重：如果在入库时发现库中存在相同的数据，则会将新数据直接覆盖旧数据。
5. 数据抽取与合并：将各个类别的数据的指定字段抽取到一个正式库中，统一格式，去除多样字段，标注来源信息。同时在抽取过程中，将属于同一事件的多个日志进行合并，保存至合并库中。
6. 数据关联：数据入库后，各个数据之间关联性较弱，在开发过程中需要重复调用数据接口进行数据获取。于是在数据入库时或入库后，根据主外键ID、相同含义字段进行关联，将关联字段更新至源数据中。

1. 字段规则治理：主要是和业务方对齐原子指标的含义，如有多条线，需要一起对齐口径，只有业务方都承认和了解接受了原子指标口径，数仓才好进一步处理，举例：净收益到底是【营销额-成本（包含各种费用）】还是【营销额-成本（只包含成品本身的成本）】，不同的业务线可能有不同的定义，如供应链和营销链注重的就不一样
2. 数据源治理：数据源即上游数据，上游数据多而繁杂，可细分为不同数据类型进行划域治理，类似主题建模和数据域的概念，比如订单、客户、供应链、财务等等，不同的域有不同的强规则体系，这个体系可形成一套完备的探查系统，比如数据源探查体系：订单{null值:是否有null值,长度:订单号是否满足规则,金额:是否有营销额无净销额……}，客户{OneID:是否标识,手机号:是否为空,收货地址:是否满足规则……}。不同的数据域有着不同的字段定义标准和探查规则标准，如果没有探查阶段，那么数据治理就是睁眼瞎
3. 数据质量反馈体系：很多时候，上游数据有了问题，下游沟通其实是一个很难的事情，比如上游为了满足自己业务需求，私自改了数值/字段名/表名等等，下游会发生依赖错误/数据值错误等情况，如果要求上游怎样做，其实很不靠谱，别人不太会听你的，那么就需要从更高一个维度解决，一是成立PMO组织，由更高级别的Leader组织，内部有数据部门，业务部门和测试部门，数据部门发现问题，交由测试部门进行总结反馈，定期给出质量报告，由测试部门监督业务部门完成整改，可用作计入绩效考核等方式进行管控，没有裁判的赛道是虚假的、不完整的。
4. 数据灾备规则和系统：没有人管控的了别人的做法和想法，那么就要做好数据部门本身的灾备规则和系统，比如从小处讲，ODS接入后在DW清洗时要注意NULL值处理，不管这个字段以前有没有NULL值，从大处讲，就是完善数据部门自己的代码书写规范，每次发版需要严格CodeReview，如果从系统角度出发，比如第三方，就做一个第三方统一接入系统，从源头规范化数据格式，比如业务线，就采取业务中台模式，数据所有数据统一处理统一管理，当然，这些扯开都是很大的话题，以后再讲

1. 指标体系的建立，加上纬度属性的集成，构成数据字典，
2. 数据源有公约规则约束的情况下建立明细数据的的数据监控，数据远没有公约规则的，按照基础的数据标准和业务过程进行数据探查，然后按照数据展现情况进行数据监控，
3. 就是数据治理的组织架构，要由上层牵头下游处理，且要有管理体系，比如约束规范更改要有特定的流程，
4. 就是数仓内部根据下游的需求，制定清晰转换规则，要有相应的操作留档

1. 主数据治理： 指企业内一致并共享的业务主体。特点：准确性、一致性、集成性、共享性/可重用性和高价值。主数据治理一般会作为单独的项目来做，MDM系统。一般是从源端进行管控治理 主数据的主要问题： 关键信息孤岛，数据分布在多个孤岛，不能跨组织传播 组织内不能就一个主数据源达成一致 数据质量问题引发的业务流程和交易的失败 不正确或丢失数据造成合规性和绩效管理的问题 决策者做出基于错误数据的错误决定 主数据解决方案： 一：数据转换映射 二：由应用系统承担主数据管理功能 三：集中管控
2. 交易数据治理 交易数据一般可以先在数据平台先行治理，之后再在源端进行管控治理
3. 参考数据治理 参考数据一般可以先在数据平台先行治理，之后再在源端进行管控治理
4. 分析数据治理 分析数据一般可以在数据平台进行治理
5. 数据模型、数据标准的治理 数据模型、数据标准一般可以先在数据平台先行治理，之后再在源端进行管控治理
6. 元数据治理：是企业数据资产管理的基础，是关于“数据的数据”，例如数据类型、数据定义、数据关系等，相当于数据表格中的表头信息，是一个相对客观的概念。元数据一般可以先在数据中台先行治理，之后再在源端进行管控治理

数据集市就像超市摆放物品，正如其名字“集市”一样，是一个面向最终用户（顾客）的数据市场，在这里，数据（物品）以一种更加容易被业务人员（顾客）接受的方式组合在一起，这些组合方式可能是多变， 因为业务人员（顾客）的需求是多变的，因此我们需要定期调整集市的计算口径（物品的组合方式），经常会创建新的数据集市（新的物品组合）。

数据中台是通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。这些服务和企业的业务有较强关联性，是企业所独有且能复用的，他是企业业务和数据的积淀，其不仅能降低重复建设，减少烟囱式协助的成本，也是差异化竞争的优势所在。数据中台是通过整合公司开发工具、打通全域数据、让数据持续为业务赋能，实现数据平台化、数据服务化和数据价值化。数据中台更加侧重于“复用”和“业务”。

据仓库就相当于一个贮存数据的仓库，在这里，数据按照特定的模型组织起来，这种模型对数据管理员来说相对友好，因为它按照一种更加集约化的规则将数据管理起来了，存放集中、规整，提取数据不用跨库寻找，查找的效率更加高。

数据湖是存储了企业所有原始数据的存储，同时原始数据对数据管理能力依赖性很强，（不同原材料组合，厨师会做出不同口味的饭菜），此外，加工后数据的存储也很复杂（做好的饭菜如果没有保存好，会坏掉）。

基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名称，如呼单量、交易金额

是1个原子指标+多个修饰词（可选）+时间周期，是原子指标业务统计范围的圈定。派生指标又分可以下二种类型：

• 事务型指标：是指对业务过程进行衡量的指标。例如，呼单量、订单支付金额，这类指标需 要维护原子指标以及修饰词，在此基础上创建派生指标。
• 存量型指标：是指对实体对象（如司机、乘客）某些状态的统计，例如注册司机总数、注册 乘客总数，这类指标需要维护原子指标以及修饰词，在此基础上创建派生指标，对应的时间 周期一般为“历史截止当前某个时间”。

是在事务性指标和存量型指标的基础上复合成的。主要有比率型、比例型、统计型均值