第1章 数据仓库概述
1.1 数据仓库概念
据仓库是一个为数据分析而设计的企业级数据管理系统。数据仓库可集中、整合多个信息源的大量数据，借助数据仓库的分析能力，企业可从数据中获得宝贵的信息进而改进决策。
1.2 数据仓库核心架构
第2章 数据仓库建模概述
2.1 数据仓库建模的意义
数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。只有将数据有序的组织和存储起来之后，数据才能得到高性能、低成本、高效率、高质量的使用。
- 高性能：良好的数据模型能够帮助我们快速查询所需要的数据。
- 低成本：良好的数据模型能减少重复计算，实现计算结果的复用，降低计算成本。
- 高效率：良好的数据模型能极大的改善用户使用数据的体验，提高使用数据的效率。
- 高质量：良好的数据模型能改善数据统计口径的混乱，减少计算错误的可能性。
2.2 数据仓库建模方法论
2.2.1 ER模型
数据仓库之父Bill Inmon提出的建模方法是从全企业的高度，用实体关系（Entity Relationship，ER）模型来描述企业业务，并用规范化的方式表示出来，在范式理论上符合3NF。
（1）实体关系模型
实体关系模型将复杂的数据抽象为两个概念：实体和关系。实体表示一个对象，关系是指两个实体之间的关系。
（2）数据库规范化
数据库规范化是使用一系列范式设计数据库（通常是关系型数据库）的过程，其目的是减少数据冗余，增强数据的一致性。
这一系列范式就是指在设计关系型数据库时，需要遵从的不同的规范。关系型数据库的范式一共有六种，分别是第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF）。遵循的范式级别越高，数据冗余性就越低。
三范式
- 第一范式（1NF）：属性不可再分。数据库表中的每一列（字段）都必须是不可分割的原子值。
- 第二范式（2NF）：消除非主属性对主键的部分依赖。在满足 1NF 的基础上，要求表中的所有非主属性必须完全依赖于整个主键，而不能仅仅依赖于主键的一部分。
- 第三范式（3NF）：消除非主属性对主键的传递依赖。在满足 2NF 的基础上，要求所有非主属性必须直接依赖于主键，不能存在传递依赖。
（3）举例
下图为一个采用Bill Inmon的ER模型构建的模型，较为松散、零碎，物理表数量多。
这种建模方法的出发点是整合数据，将整个企业的数据进行组合和合并，并进行规范处理，减少数据冗余性，保证数据的一致性。这种模型并不适合直接用于分析统计。
2.2.2 维度模型
Ralph Kimball倡导的建模方法为维度建模。维度模型将复杂的业务通过事实和维度两个概念进行呈现。事实通常对应业务过程，而维度通常对应业务过程发生时所处的环境。
维度建模以数据分析作为出发点，为数据分析服务，关注的重点的用户如何更快的完成需求分析以及如何实现较好的大规模复杂查询的响应性能。
维度模型设计4步过程
- 选择业务过程
业务过程是组织完成的操作型活动,例如,获得订单、处理保险索赔、学生课程注册或每个月每个账单的快照等。业务过程事件建立或获取性能度量,并转换为事实表中的事实。多数事实表关注某一业务过程的结果。过程的选择是非常重要的,因为过程定义了特定的设计目标以及对粒度、维度、事实的定义。每个业务过程对应企业数据仓库总线矩阵的一行。 - 声明粒度
声明粒度是维度设计的重要步骤。粒度用于确定某一事实表中的行表示什么。粒度声明是设计必须履行的合同。在选择维度或事实前必须声明粒度,日因为每个候选维度或事实必须与定义的粒度保持一致。在所有维度设计中强制实行一致性是保证BI应用性能和易用性的关键。在从给定的业务过程获取数据时,原子粒度是最最低级别的粒度。我们强烈建议从关注原子级别粒度数据开始设计,因为原子粒度数据能多承受无法预期的用户查询。上卷汇总粒度对性能调整来说非常重要,但这样的粒度往往要要猜测业务公共问题。针对不同的事实表粒度,要建立不同的物理表,在同一事实表中不要要混用多种不同的粒度。 - 确认维度
维度提供围绕某一业务过程事件所涉及的"谁、什么、何处、何日寸、为什么、如何等背景。维度表包含BI应用所需要的用于过滤及分类事实的描述生属性。牢牢掌握事实表的粒度,就能够将所有可能存在的维度区分开。当与给定事实表行关联时,任何情况下都应使维度保持单一值。维度表有时被称为数据仓库的"灵魂",因为维度表包含确保DW/BI系统能够被用作业务分析的入口和描述性标识。主要的工作都放在数据管理与维度表的开发方面,因为它们是用户BI经验的驱动者。 - 确认事实
事实涉及来自业务过程事件的度量,基本上都是以数量值表示。一个事实表行与按照事实表粒度描述的度量事件之间存在一对一关系,因此事实表对应一个物理可观察的事件。在事实表内,所有事实只允许与声明的粒度保持一致。例如,在在零售事务中,销售产品的数量与其总额是良好的事实,然而商店经理的工资不允许在存在于零售事务中
第3章 维度建模之事实表
3.1 事实表概述
事实表围绕着业务过程来设计，其包含与该业务过程有关的维度引用（维度表外键）以及该业务过程的度量（通常是可累加的数字类型字段）。
事实表通常比较"细长"，即列较少，但行较多，且行的增速快。
3.2 事实表技术基础
3.2.1 事实表结构
发生在现实世界中的操作型事件,其所产生的可度量数值,存储在事实表中。从最低的粒度级别来看,事实表行对应一个度量事件,反之亦然。因此,事实表的设计完全依赖于物理活动,不受可能产生的最终报表的影响。除数字度量外,事实表总是包含外键,用于关联与之相关的维度,也包含可选的退化维度健和日期/时间戳。查询请求的主要目标是基于事实表开展计算和聚集操作。
3.2.2 事实类型
事实类型是指度量值的类型，事实（度量值）共分为三类，分别是可加事实，半可加事实和不可加事实。
- 可加事实
可加事实是指可以按照与事实表相关的所有维度进行累加，例如事务型事实表中的事实。 - 半可加事实
半可加事实是指只能按照与事实表相关的一部分维度进行累加，例如周期型快照事实表中的事实。以上述各仓库中各商品的库存每天快照事实表为例，这张表中的库存事实可以按照仓库或者商品维度进行累加，但是不能按照时间维度进行累加，因为将每天的库存累加起来是没有任何意义的。 - 不可加事实
不可加事实是指完全不具备可加性，例如比率型事实。不可加事实通常需要转化为可加事实，例如比率可转化为分子和分母。
3.2.3 一致性事实
如果某些度量出现在不同的事实表中，需要注意，如果需要比较或计算不同事实表中的事实，应保证针对事实的技术定义是相同的。如果不同的事实表定义是一致的，则这些一致性事实应该具有相同的命名，如果它们不兼容，则应该有不同的命名用于告诫业务用户和BI应用。
3.2.4 事务事实表
事务型事实表用来记录各业务过程，它保存的是各业务过程的原子操作事件，即最细粒度的操作事件。粒度是指事实表中一行数据所表达的业务细节程度。
事务事实表可用于分析与各业务过程相关的各项统计指标，由于其保存了最细粒度的记录，可以提供最大限度的灵活性，可以支持无法预期的各种细节层次的统计需求。
事务型事实表可以保存所有业务过程的最细粒度的操作事件，故理论上其可以支撑与各业务过程相关的各种统计粒度的需求。但对于某些特定类型的需求，其逻辑可能会比较复杂，或者效率会比较低下。
3.2.5 周期快照事实表
周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，主要用于分析一些存量型（例如商品库存，账户余额）或者状态型（空气温度，行驶速度）指标。
对于商品库存、账户余额这些存量型指标，业务系统中通常就会计算并保存最新结果，所以定期同步一份全量数据到数据仓库，构建周期型快照事实表，就能轻松应对此类统计需求，而无需再对事务型事实表中大量的历史记录进行聚合了。
对于空气温度、行驶速度这些状态型指标，由于它们的值往往是连续的，我们无法捕获其变动的原子事务操作，所以无法使用事务型事实表统计此类需求。而只能定期对其进行采样，构建周期型快照事实表。
周期快照有一个特例是全量周期快照事实表
3.2.6 累积快照事实表
累计快照事实表是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表，如交易流程中的下单、支付、发货、确认收货业务过程。
累积型快照事实表通常具有多个日期字段，每个日期对应业务流程中的一个关键业务过程（里程碑）。
累积型快照事实表主要用于分析业务过程（里程碑）之间的时间间隔等需求。例如前文提到的用户下单到支付的平均时间间隔，使用累积型快照事实表进行统计，就能避免两个事务事实表的关联操作，从而变得十分简单高效。
| 订单id | 用户id | 下单日期 | 支付日期 | 发货日期 | 确认收货日期 | 订单金额 | 支付金额 |
|---|---|---|---|---|---|---|---|
| 1001 | 1234 | 2022-06-08 | 2022-06-09 | 2022-06-16 | 2022-06-17 | 1000 | 1000 |
3.2.7 无事实的事实表
尽管多数度量事件获取的结果是数字化的，但也存在某些事件仅仅记录一系列某一时刻发生的多维实体。例如，在给定的某一天中发生的学生主参加课程的事件,可能没有可记录的数字化事实,但该事实行带有一个包含日历天、学生、教师、地点、课程等定义良好的外键。同样,客户交际也是一种事件,但没有相关的度量。利用无事实的事实表也可以分析发生了什么。这类查询总是包含两个部分:包含所有可能事件的无事实覆盖表,包含实际发生的事件的活动表。当活动从覆盖表中减除时,其结果是尚未发生的事件
3.2.8 合并事实表
通常将来自多个过程的,以相同粒度表示的事实合并为一个单一的的合并事实表,这样做能够带来方便。例如,现货销售可以与销售预测合并为一张事实表,与针对多个不同的事实表采用下钻应用比较,这样做可使对现货及预测任务的分析工仁作变得简单快捷。合并事实表会增加ETL处理过程的负担,但降低了BI应用的分析代价。合并事实表特别适合那些经常需要共同分析的多过程度量。
第4章 维度建模之维度表
4.1 维度表概述
维度表是维度建模的基础和灵魂。前文提到，事实表紧紧围绕业务过程进行设计，而维度表则围绕业务过程所处的环境进行设计。维度表主要包含一个主键和各种维度字段，维度字段称为维度属性。
4.2 维度表基础技术
4.2.1 维度表结构
每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键,当然,维度表行的描述环境应与事实表行完全对应。维度表通常比较宽,是扁平型非规范表,包含大量的低粒度的文本属性。操作代码与指示器可作为属性对待,最强有力的维度属性采用冗长的描述填充。维度表属性是查询及BI应用的约束和分组定义的主要目标。报表的描述性标识通常是维度表属性领域值。
4.2.2 维度代理键
维度表中会包含一个列,表示唯一主键。该主键不是操作型系系统的自然键,由于需要跟踪变化,因此若采用自然键,将需要多个维度行表示。另外,维度的自然健可能由多个源系统建立,这些自然键将出现兼容性问题,难以管理。DW/BI系统需要声明对所有维度的主键的控制,而无法采用单一的自然键或附加日期的自然建,可以为每个维度建立无语义的整型主键。这些维度代理键是按顺序分配的简单整数,以值1开始。每当需要新键时,键值自动加1。日期维度不需要遵守代理键规则,日期维度是高度可预测的且稳定的维度,可以采用更有意义的主键。
4.2.3 自然键、持久键和超自然键
由操作型系统建立的自然键受业务规则影响,无法被DW/BI系统控制。例如,如果雇员辞职,然后重新工作,则雇员号码(自然键)可能会发生变化。数据仓库希望为该雇员创建单一键,这就需要建立新的持久键以确保在此种情况下,雇员号保持持久性不会发生变化。该键有时被称为持久性超自然键。最好的持久键其格式应该独立于原始的业务过程,并以整数1开始进行分配。多个代理键与某一个雇员关联时,若描述发生变化时,持久键不会变化
4.2.4 退化维度
有时,维度除了主键外没有其他内容。例如,当某一发票包含多个数据项时,数据项事实行继承了发票的所有描述性维度外键,发票除了外键外无其他项。但发票数量仍然是在此数据项级别的合法维度键。这种退化维度被放入事实表中,清楚地表明没有关联的维度表。退化维度常见于交易和累计快照事实表中。
4.2.5 杂项维度
事务型商业过程通常产生一系列混杂的、低粒度的标识和指示器。与其为每个标识或属性定义不同的维度,不如建立单独的将不同维度合并到一起的的杂项维度。这些维度,通常在一个模式中标记为事务型概要维度,不需要所有属性可能值的笛卡尔积,但应该只包含实际发生在源数据中的合并值。
4.2.6 规范化与反规范化
规范化 是指使用一系列范式设计数据库的过程，其目的是减少数据冗余，增强数据的一致性。通常情况下，规范化之后，一张表的字段会拆分到多张表。
反规范化 是指将多张表的数据冗余到一张表，其目的是减少join操作，提高查询性能。
在设计维度表时，如果对其进行规范化，得到的维度模型称为雪花模型，如果对其进行反规范化，得到的模型称为星型模型。
数据仓库系统的主要目的是用于数据分析和统计，所以是否方便用户进行统计分析决定了模型的优劣。采用雪花模型，用户在统计分析的过程中需要大量的关联操作，使用复杂度高，同时查询性能很差，而采用星型模型，则方便、易用且性能好。所以出于易用性和性能的考虑，维度表一般是很不规范化的。
4.2.7 一致性维度
当不同的维度表的属性具有相同列名和领域内容时,称维度表具有一致性。利用一致性维度属性与每个事实表关联,可将来自不同事实表的信息合并到同一报表中。当一致性属性被用作行头(就是说,用作SQL查询中的分组列)时,来自不同事实表的结果可以排列到跨钻报表的同一行中。以上实现是集成企业DW/BI系统的基础。一致性维度一旦在与业务数据管理方共同定义后,就可以被所有事实表重用。该方法可获得分析一致性并减少未来开发的开销,因为不需要重新创建。
4.2.8 其他原则
- 尽可能生成丰富的维度属性
维度属性是后续做分析统计时的查询约束条件、分组字段的基本来源，是数据易用性的关键。维度属性的丰富程度直接影响到数据模型能够支持的指标的丰富程度。 - 尽量不使用编码，而使用明确的文字说明，一般可以编码和文字共存。
- 尽量沉淀出通用的维度属性
有些维度属性的获取需要进行比较复杂的逻辑处理，例如需要通过多个字段拼接得到。为避免后续每次使用时的重复处理，可将这些维度属性沉淀到维度表中。
4.3 维度变化
维度属性通常不是静态的，而是会随时间变化的，数据仓库的一个重要特点就是反映历史的变化，处理缓慢变化维度(Slowly Changing Dimension, SCD)是维度设计的重要工作之一。
4.3.1 类型0:原样保留
对类型0,维度属性值不会发生变化,因此事实表以原始值分组1。类型0适合属性标记为"原型"的情况。例如,客户原始的信用卡积分或持久型标识符。该类型也适用于日期维度的大多数属性。
4.3.2 类型1:重写
对类型1,维度行中原来的属性值被新值覆盖。类型1属性总是反映最近的工作,因此该技术破坏了历史情况。尽管该方法易于实现且不需要建立额领外的维度行,但使用时需小心,因为受此影响的聚集事实表和OLAP多维数据库将会重复计算。
4.3.3 类型2:增加新行
对类型2,将在维度表中增加新行,新行中采用修改的属性值。要实现该方式需要维度主键更具有一般性,不能仅采用自然键或持久键,因为采用该方法时经常会出现多行描述同样成员的情况。在为维度成员建立新行时,将为其分配新的主代理键,在修改发生后,将其作为所有事实表的外键,直到后续变化产生新维度键并更更新维度行当变化类型2发生时,最少需要在维度行中增加三个额外列:1行有效的日期/时间戳列;2行截止日期/时间戳列;3当前行标识。
4.3.4 类型3:增加新属性
对类型3,将在维度表上增加新属性以保存原来的属性值,新属性值以变化类型1方式重写主属性。这种类型3变化有时称为替换现实。商业用户可以利用当前值或替换现实来分组或过滤事实数据。此种缓慢变化维度技术不太常用。
4.3.5 类型4:增加微型维度
对类型4,当维度中的一组属性快速变化并划分为微型维度时时采用。此种情况下的维度通常被称为快速变化魔鬼维度。通常在包含几百万行的维度度表中使用的属性是微型维度设计的候选,即使它们并不经常变化。变化类型4微型维度需需要自己的唯一主键,基维度和微型维度主键从相关的事实表中获取。
4.3.6 类型5:增加微型维度及类型1支架
对类型5,用于精确保存历史属性值,按照当前属性值,增加报表的历史事实。类型5建立在类型4微型维度之上,并嵌入当前类型1引用基维度中中的微型维度。这样才能确保当前分配的微型维度属性能够与基维度上其他微型维度一起被皮访问,而不必通过事实表连接。逻辑上说,应该将基维度及微型维度支架表示为展现区域中的单一表。每当当前微型维度分配发生变化时,ETL小组需要重写类型1微型维度引用用。
4.3.7 类型7:双类型1和类型2维度
类型7是用于支持过去和现在报表的最后一种混合技术。事实表可以被访问,通过被建模为类型1维度仅仅展示最新属性值,建模为类型2维度展示最新历史概要。同样的维度表确保实现两方面的观点。维度的持久键和主代理键同时存在事实表上。从类型1角度看,维度的当前标识被约束至当前,通过持久键与事实表连接。从类型2角度看,当前标识无约束,事实表通过代理键主键连接。此两种方法可以按照不同的视图部署到BI应用上。
第5章 数据管理体系
5.1 数据管理体系架构
5.1.1 概述
面对爆炸式增长的数据，如何建设高效的数据模型和体系，对这些数据进行有序和有结构地分类组织和存储，避免重复建设和数据不 一致性，保证数据的规范性， 一 直是数据系统建设不断追求的方向。
建设统一的、规范化的数据接人层（ODS）和数据中间层（DWD和DWS），通过数据服务和数据产品，完成数据公共层建设。提供标准化的（Standard）、共享的（Shared）、数据服务（Service）能力，降低数据互通成本，释放计算、存储、人力等资源，以消除业务和技术之痛。
5.1.2 体系架构
5.2 指标体系
5.2.1 原子指标
原子指标是指标体系中最基础、不可再拆分的计算逻辑。它只包含业务过程和聚合逻辑，不包含任何时间周期或业务限定条件。
原子指标 = 业务过程 + 度量（聚合逻辑）
5.2.2 派生指标
派生指标是在原子指标的基础上，加上时间周期和修饰词（业务限定条件）后形成的指标。它是日常业务报表中最常用的指标类型。
派生指标 = 原子指标 + 时间周期 + 修饰词（维度/筛选条件）
5.2.3 复合指标
复合指标是由一个或多个派生指标（或原子指标）经过四则运算或复杂逻辑计算得到的指标。它通常用于衡量效率、比率、趋势等。
复合指标 = f(派生指标1, 派生指标2, ...)
f 为计算函数，如除法、减法、加权平均等
5.3 模型设计
5.3.1 分层设计
数据仓库以分层建设为主，包含如下三层：ODS、CDM、ADS，其中CDM包含DWD、DWS、DIM。通过Schema隔离不同的分层。
贴源数据层（ODS）：把操作系统数据几乎无处理地存放在数据仓库系统中。
公共维度模型层（CDM）：存放明细事实数据、维表数据及公共指标汇总数据，其中明细事实数据、维表数据一般根据ODS层数据加工生成；公共指标汇总数据一般根据维表数据和明细事实数据加工生成。
应用数据层（ADS）：存放数据产品个性化的统计指标数据，根据CDM层与ODS层加工生成。
5.3.2 总线架构矩阵
- 定义了一套跨数据域的一致性维度和一致性事实（Conformed Facts），不同主题域的数据可以通过相同的维度进行关联和钻取分析。
- 总线矩阵是一张可视化的规划图，行代表业务过程（事实），列代表共享维度，可作为统一语言理解数据资产的全貌。
5.4 模型实施
5.5 命名规范
5.5.1 核心基础规范
- 基本格式：统一小写字母，单词之间使用下划线 _ 分隔。
- 核心公式：层级_数据域/来源_业务过程/实体_维度粒度_特殊/时间标识
- 引擎特性适配：抛弃传统 HDFS 时代的 _df(全量) 和 _di(增量) 标识，利用 Doris 的 Unique Key 模型实现数据的 Upsert 自动合并。
5.5.2 各层级表命名规范
1. ODS 层 (Operational Data Store) - 贴源数据层
设计逻辑：直接同步源系统数据，保持表结构一致。在 Doris 中使用 Unique Key (状态变更表) 或 Duplicate Key (日志流水表)。
- 命名公式 ：ods_数据来源_源系统表名
- 说明：无需全量/增量标识。如果确实是为了对账做的极少量的定期全量备份，可加 _bak_d。
- 命名示例 ：
- ods_erp_order_info（同步自ERP 的订单表，Doris 中实时 Update）
- ods_app_click_event（同步自 App 的点击日志流，追加写入）
- ods_fin_account_info（同步自财务账户表）
2. DIM 层 (Dimension) - 公共维度层
设计逻辑：存放业务实体的各种描述信息，供下游关联。
- 命名公式 ：dim_维度实体名称_特殊标识
- 特殊标识 ：
- 无后缀：普通维度表（Doris Unique Key，保持最新状态）。
- _his ：历史拉链表（用于记录缓慢变化维 SCD2，如果业务有强需求查询历史维度的状态才建）。
- 命名示例 ：
- dim_pub_date（公共日期维度表）
- dim_user_info（用户基础信息维度表）
- dim_item_sku_info_his（商品 SKU 信息历史拉链表）
3. DWD 层 (Data Warehouse Detail) - 明细事实层
设计逻辑：对 ODS 数据清洗、规范化，构建最细粒度的业务事实表。需严格区分三种事实表类型。
- 命名公式 ：dwd_数据域业务过程/实体事实表类型标识
| 事实表类型 | Doris 模型建议 | 后缀标识 | 命名公式与示例 | 查询注意事项 |
|---|---|---|---|---|
| 事务事实表 | Duplicate Key | _detail (或无) | dwd_域_[过程_detail 例：dwd_trade_pay_detail (一笔支付) | 记录动作，单次发生。可直接执行 SUM(), COUNT() |
| 累积快照事实表 | Unique Key | _accum | dwd_域_实体_accum 例：dwd_trade_order_accum (订单流转过程) | 记录生命周期，利用 Doris 实时覆写更新各个时间节点。 |
| 周期快照事实表 | Duplicate Key (按天分区) | _snap_d / _snap_m | dwd_域_实体snap周期 例：dwd_fin_account_snap_d (财务账户每日余额快照) | 记录特定时刻截面。SQL 中强制要求带上 WHERE snap_date = 'xxx'，否则数据会翻倍爆炸。 |
4. DWS 层 (Data Warehouse Summary) - 公共汇总层
设计逻辑：按特定维度和时间窗口进行轻/中度聚合，沉淀复用度高的指标。
- 命名公式 ：dws_数据域聚合主维度业务过程_统计时间周期
- 时间周期后缀 (必须有) ：
- _1d：最近 1 天（例：今日交易额）
- _nd：最近 N 天（如 _7d, _30d）
- _td (To Date)：历史截至当前（例：用户历史总累计消费）
- 命名示例 ：
- dws_trade_user_order_1d（交易域 - 用户粒度 - 订单业务 - 最近1天汇总）
- dws_traffic_page_view_7d（流量域 - 页面粒度 - 浏览业务 - 最近7天汇总）
- dws_fin_user_account_td（财务域 - 用户粒度 - 账户充值 - 历史至今汇总）
- (Doris 特有建议：如果聚合逻辑简单，DWS 层可以不建物理表，而是直接在 DWD 表上建立 Materialized View (物化视图)，由 Doris 引擎自动路由。)
5. ADS 层 (Application Data Service) - 数据应用层
设计逻辑：面向具体的 BI 报表、大屏、业务系统需求，高度定制化。
- 命名公式 ：ads_业务线/应用名_报表/功能名称
- 说明：此层不必严格拘泥于数据域，怎么让业务方一眼看懂怎么来。
- 命名示例 ：
- ads_marketing_campaign_roi_stat（营销部 - 活动 ROI 统计表）
- ads_board_ceo_daily_summary（CEO 大屏 - 每日核心指标大盘表）
- ads_crm_user_churn_warning（CRM 应用 - 用户流失预警输出表）
5.5.4 附录
常用时间周期：
| 周期分类 | 后缀规范 | 含义说明 | 命名示例 | 业务口径与计算说明 |
|---|---|---|---|---|
| 滑动窗口 (Rolling) 指从当前时间往前推的固定长度时间段 | _1d | 最近 1 天 | dws_trade_user_1d | 过去 1 天（通常指昨天 0点-24点，或近 24小时） |
| _nd | 最近 N 天 | dws_trade_user_7d | 过去 N 天（如 _3d, _7d, _30d, _90d） | |
| _nm | 最近 N 个月 | dws_risk_user_3m | 过去 N 个月（如 _1m, _3m, _6m）。 💡ETL建议：为避免大小月天数差异，底层计算通常转化为固定天数（如 3m 等同于 90d，6m 等同于 180d） | |
| _ny | 最近 N 年 | dws_fin_loan_1y | 过去 N 年（如 _1y, _3y）。 💡ETL建议：底层计算通常转化为 365d 或 1095d | |
| 自然周期 (Natural) 指日历上固定的、不可拆分的自然时间段 | _d | 自然天 | dwd_fin_account_snap_d | 日历上的每一天（00:00:00 - 23:59:59） |
| _w | 自然周 | dws_sales_shop_w | 周一至周日（需全公司统一自然周的起止定义） | |
| _m | 自然月 | dws_fin_budget_m | 每月 1 号至月末最后一天 | |
| _q | 自然季 | dws_sales_region_q | 日历季度（如 1月-3月为 Q1） | |
| _y | 自然年 | dws_sales_region_y | 每年 1月1日 至 12月31日 | |
| 累计周期 (To-Date) 指从某一周期的起点一直累计到当前时间 | _wtd | 周初至今 | dws_sales_wtd | 本周一至当前的累计数据 |
| _mtd | 月初至今 | dws_sales_mtd | 本月 1 号至当前的累计数据（常用于盯月度 KPI） | |
| _qtd | 季初至今 | dws_sales_qtd | 本季度第一个月 1 号至当前的累计数据 | |
| _ytd | 年初至今 | dws_sales_ytd | 本年 1 月 1 号至当前的累计数据 | |
| _td | 历史至今 | dws_user_trade_td | 从实体创建/注册那天起，历史总累计（如 LTV、历史总消费） | |
| 微批/实时 (Micro / RT) 指小时/分钟级的超短周期或流计算周期 | _h | 自然小时 | dws_traffic_h | 每小时的微批汇总（0分0秒 - 59分59秒） |
| _min | 分钟级 | dws_log_error_5min | 每 N 分钟的微批汇总（如 _5min, _15min） | |
| _rt | 实时计算 | dws_trade_rt | 实时流计算直接写入的汇总表（秒级/毫秒级延迟） |
常用字段后缀：
| 字段业务含义 | 推荐规范后缀 | 示例 |
|---|---|---|
| 主键 / ID | _id | user_id, order_id |
| 件数 / 次数 / 笔数 | _cnt (Count) | login_cnt, pay_cnt |
| 金额 / 财务数字 | _amt (Amount) | pay_amt, discount_amt |
| 比率 / 比例 | _rate / _ratio | click_rate, roi_ratio |
| 状态枚举 | _status / _state | order_status, refund_state |
| 布尔值 / 是否标记 | _flag / _is | is_new_user, delete_flag |
| 日期 (精确到天) | _date | pay_date, snap_date |
| 时间 (精确到秒) | _time | pay_time, create_time |
第6章 技术架构
6.1 架构范式选型Lambda
现有业务特征是离线批处理为主、实时流式处理场景很少，基于此采用 Lambda 架构：
| 层级 | 名称 | 核心职责 | 特点 |
|---|---|---|---|
| Batch Layer | 批处理层 | 管理主数据集（Master Dataset），预计算批量视图 | 高延迟、高吞吐、结果精确、不可变数据 |
| Speed Layer | 加速层 | 处理最新数据，弥补批处理的延迟 | 低延迟、增量计算、结果可能近似 |
| Serving Layer | 服务层 | 合并批处理和实时结果，响应查询 | 只读、快速响应、统一对外接口 |
| 落地原则： |
- 默认走批：新需求优先用批处理层实现（SeaTunnel 批量同步 + Doris SQL/Spark），不轻易引入流式链路。
- 加速层按需启用：仅当存在明确的实时性要求（延迟容忍在分钟级以内）时，才启用 SeaTunnel CDC + Flink 加速链路。
- 避免批流重复：同一指标不要批流两套都做。能批处理的就用批处理层；只有确实需要实时的，才进加速层。
- 加速层轻量：加速层场景少，Flink 作业数量受限，避免流式链路过度膨胀偏离"批为主"的基调。
6.2 两条总线
- 模型总线矩阵：不同主题域的数据可以通过相同的维度进行关联；作为统一语言理解数据资产的全貌。
- 数据总线：lambda架构，包含批量同步与实时同步（有主键的表），实现数据集成
6.3 数据共享
数据共享多数场景需要数据的实时性，通过数据总线实现共享
当前数据数据共享为点对点网状结构 -> 数据总线发布订阅模式
数据共享原则：
（1）服务接口优先于数据共享（基于服务治理）
（2）数据共享分为两种类型：
- 目标业务表原表：申请方订阅业务原表发布主题
- 需要数据中台跨主题域加工的结果表：数据中台发布数据主题，申请方订阅
（3）数据共享以表或数据对象为源，避免以SQL为源
6.4 技术选型
使用CNDP同时，引入开源平台，双栈架构，提供更多方案以及可控性
| 逻辑过程 | 技术选型 |
|---|---|
| 数据集成 | Kafka、Seatunnel |
| 数据存储 | Doris |
| 数据计算 | Doris SQL、Spark、Flink、Python |
| 任务调度 | DolphinScheduler |
| 数据治理 | DataHub |
| 数据服务 | Springboot |
参考文献
1 阿里巴巴数据技术及产品部. 大数据之路：阿里巴巴大数据实践M. 北京: 电子工业出版社, 2017.
2 华为公司数据管理部. 华为数据之道M. 北京: 机械工业出版社, 2020.
3 KIMBALL R, ROSS M. 数据仓库工具箱：维度建模权威指南（第3版）M. 王念滨, 周连科, 韦正现, 译. 北京: 清华大学出版社, 2015.
4 阿里云. Hologres开发规范EB/OL. (2026-05-27)2026-07-22.https://help.aliyun.com/zh/hologres/use-cases/hologres-development-standards?scm=20140722.H_303779._.ID_303779-OR_rec-V_1
5 Apache Doris 官方文档EB/OL. (2026-08-17) 2026-08-17. https://doris.apache.org/zh-CN/docs/4.x/getting-started/what-is-apache-doris.