3. 数据质量管理流程
本节流程如下图所示：
1. 数据资产等级
1) 等级定义
根据当数据质量不满足完整性、规范性、一致性、准确性、唯一性、及时性时，对业务的影响程度大小来划分数据的资产等级。
- 毁灭性：数据一旦出错，会引起巨大的资产损失，面临重大收益受损等。标记为 L1
- 全局性：数据用于集团业务、企业级效果评估和重要决策任务等。标记为 L2
- 局部性：数据用于某个业务线的日常运营、分析报告等，如果出现问题会给该业务线造成一定的影响或影响其工作效率。标记为 L3
- 一般性：数据用于日常数据分析，出现问题的带来的影响很小。标记为 L4
- 未知性质：无法追溯数据的应用场景。标记为 Lx
重要程度：L1>L2>L3>L4>Lx。如果一份数据出现在多个应用场景中，则根据其最重要程度进行标记。
2) 等级划分
定义数据资产等级后，我们可以从数据流程链路开始进行数据资产等级标记，完成数据资产等级确认，给不同的数据定义不同的重要程度。
1. 分析数据链路：
数据是从业务系统中产生的，经过同步工具进入数据仓库系统中，在数据仓库中进行一般意义上的清洗、加工、整合、算法、模型等一系列运算后，再通过同步工具输出到数据产品中进行消费。而从业务系统到数据仓库再到数据产品都是以表的形式体现的，其流转过程如下图所示：
2. 标记数据资产等级：
在所有数据链路上，整理出消费各个表的应用业务。通过给这些应用业务划分数据资产等级，结合数据的上下游依赖关系，将整个链路打上某一类资产等级标签。
举例：
假设公司有统一的订单服务中心。应用层的应用业务是按照业务线，商品类型和地域统计公司的订单数量和订单金额，命名为order_num_amount。
假设该应用会影响到整个企业的重要业务决策，我们可以把应用定级为 L2，从而整个数据链路上的表的数据等级，都可以标记为L2-order_num_amount，一直标记到源数据业务系统，如下图所示：
2. 数据加工过程卡点校验
1) 在线系统数据校验
在线业务复杂多变，总是在不断地变更，每一次变更都会带来数据的变化，数据仓库需要适应这多变的业务发展，及时做到数据的准确性。
基于此，在线业务的变更如何高效地通知到离线数据仓库，同样也是需要考虑的问题。为了保障在线数据和离线数据的一致性，我们可以通过工具+人员管理并行的方式来尽可能的解决以上问题：既要在工具上自动捕捉每一次业务的变化，同时也要求开发人员在意识上自动进行业务变更通知。
1. 业务上线发布平台：
监控业务上线发布平台上的重大业务变更，通过订阅这个发布过程，及时将变更内容通知到数据部门。
由于业务系统复杂多变，若日常发布变更频繁，那么每次都通知数据部门，会造成不必要的资源浪费。这时，我们可以使用之前已经完成标记的数据资产等级标签，针对涉及高等级数据应用的数据资产，整理出哪些类型的业务变更会影响数据的加工或者影响数据统计口径的调整，则这些情况都必须及时通知到数据部门。
如果公司没有自己的业务发布平台，那么就需要与业务部门约定好，针对高等级的数据资产的业务变更，需要以邮件或者其他书面的说明及时反馈到数据部门。
2. 操作人员管理：
工具只是辅助监管的一种手段，而使用工具的人员才是核心。数据资产等级的上下游打通过程需要通知给在线业务系统开发人员，使其知道哪些是重要的核心数据资产，哪些暂时还只是作为内部分析数据使用，提高在线开发人员的数据风险意识。
可以通过培训的方式，把数据质量管理的诉求，数据质量管理的整个数据加工过程，以及数据产品的应用方式及应用场景告知在线开发人员，使其了解数据的重要性、价值及风险。确保在线开发人员在完成业务目标的同时，也要考虑数据的目标，保持业务端和数据段一致。
2) 离线系统数据校验
数据从在线业务系统到数据仓库再到数据产品的过程中，需要在数据仓库这一层完成数据的清洗、加工。正是有了数据的加工，才有了数据仓库模型和数据仓库代码的建设。
如何保障数据加过程中的质量，是离线数据仓库保障数据质量的一个重要环节。
在这些环节中，我们可以采用以下方式来保障数据质量：
- 代码提交核查：
开发相关的规则引擎，辅助代码提交校验。规则分类大致为：
- 代码规范类规则：如表命名规范、字段命名规范、生命周期设置、表注释等；
- 代码质量类规则：如分母为 0 提醒、NUll 值参与计算提醒等；
- 代码性能类规则：如大表提醒、重复计算监测、大小表 join 操作提醒等。
- 代码发布核查：
加强测试环节，测试环境测试后再发布到生成环境，且生成环境测试通过后才算发布成功。
- 任务变更或重跑数据：
在进行数据更新操作前，需要通知下游数据变更原因、变更逻辑、变更时间等信息。下游没有异议后，再按照约定时间执行变更发布操作。
3. 数据处理风险监控
风险点监控主要是针对数据在日常运行过程中容易出现的风险进行监控并设置报警机制，主要包括在线数据和离线数据运行风险点监控。
1) 数据质量监控
在线业务系统的数据生产过程需要保证数据质量，主要根据业务规则对数据进行监控。
比如交易系统配置的一些监控规则，如订单拍下时间、订单完结时间、订单支付金额、订单状态流转等都配置了校验规则。订单拍下时间肯定不会大于当天时间，也不会小于业务上线时间，一旦出现异常的订单创建时间，就会立刻报警，同时报警给到多人。通过这种机制，可以及时发现并解决问题。
随着业务负责程度的提升，会导致规则繁多、规则配置的运行成本增大，这时可以按照我们之前的数据资产等级有针对性的进行监控。
离线数据风险点监控主要包括对数据准确性和数据产出及时性的监控。对数据调度平台上所有数据处理调度进行监控。
我们以阿里的 DataWorks 数据调度工具为例，DataWorks 是基于 MaxCompute 计算引擎的一站式开发工场，帮助企业快速完成数据集成、开发、治理、质量、安全等全套数据研发工作。
DataWorks 中的 DQC 通过配置数据质量校验规则，实现离线数据处理中的数据质量监控报警机制。
下图是 DQC 的工作流程图：
DQC 数据监控规则有强规则和弱规则：
- 强规则：一旦触发报警就会阻断任务的执行（将任务置为失败状态，使下游任务不会被触发执行）。
- 弱规则：只报警但不阻断任务的执行。
DQC 提供常用的规则模板，包括表行数较 N 天前波动率、表空间大小较 N 天前波动率、字段最大/最小/平均值相比 N 天前波动率、字段空值/唯一个数等。
DQC 检查其实也是运行 SQL 任务，只是这个任务是嵌套在主任务中的，一旦检查点太多自然就会影响整体的性能，因此还是依赖数据产等级来确定规则的配置情况。比如 L1、L2 类数据监控率要达到 90% 以上，规则类型需要三种及以上，而不重要的数据资产则不强制要求。
2) 数据及时性监控
在确保数据准确性的前提下，需要进一步让数据能够及时地提供服务，否则数据的价值将大幅度降低，甚至没有价值，所以确保数据及时性也是保障数据质量重中之重的一环。
- 任务优先级：
对于DataWorks平台的调度任务，可以通过智能监控工具进行优先级设置。DataWorks的调度是一个树形结构，当配置了叶子节点的优先级，这个优先级会传递到所有的上游节点，而叶子节点通常就是服务业务的消费节点。
因此，在优先级的设置上，要先确定业务的资产等级，等级越高的业务对应的消费节点优先级越高，优先调度并占用计算资源，确保高等级业务的准时产出。
总之，就是按照数据资产等级优先执行高等级数据资产的调度任务，优先保障高等级业务的数据需求。
- 任务报警：
任务报警和优先级类似，通过DataWorks的智能监控工具进行配置，只需要配置叶子节点即可向上游传递报警配置。任务执行过程中，可能出错或延迟，为了保障最重要数据（即资产等级高的数据）产出，需要立即处理出错并介入处理延迟。
- DataWorks智能监控：
DataWorks进行离线任务调度时，提供智能监控工具，对调度任务进行监控告警。根据监控规则和任务运行情况，智能监控决策是否报警、何时报警、如何报警以及给谁报警。智能监控会自动选择最合理的报警时间、报警方式以及报警对象。
4. 最后
要想真正解决数据质量问题，就要明确业务需求并从需求开始控制数据质量，并建立数据质量管理机制。从业务出发做问题定义，由工具自动、及时发现问题，明确问题责任人，通过邮件、短信等方式进行通知，保证问题及时通知到责任人。跟踪问题整改进度，保证数据质量问题全过程的管理。
九、数仓规范建设指南
1. 数仓公共开发规范
1. 层次调用规范
稳定业务按照标准的数据流向进行开发，即 ODS –> DWD –> DWS –> APP。非稳定业务或探索性需求，可以遵循 ODS -> DWD -> APP 或者 ODS -> DWD -> DWM ->APP 两个模型数据流。
在保障了数据链路的合理性之后，也必须保证模型分层引用原则：
- 正常流向：ODS -> DWD -> DWM -> DWS -> APP，当出现 ODS -> DWD -> DWS -> APP 这种关系时，说明主题域未覆盖全。应将 DWD 数据落到 DWM 中，对于使用频度非常低的表允许 DWD -> DWS。
- 尽量避免出现 DWS 宽表中使用 DWD 又使用（该 DWD 所归属主题域）DWM 的表。
- 同一主题域内对于 DWM 生成 DWM 的表，原则上要尽量避免，否则会影响 ETL 的效率。
- DWM、DWS 和 APP 中禁止直接使用 ODS 的表， ODS 的表只能被 DWD 引用。
- 禁止出现反向依赖，例如 DWM 的表依赖 DWS 的表。
举例：
2. 数据类型规范
需统一规定不同的数据的数据类型，严格按照规定的数据类型执行：
- 金额：double 或使用 decimal(11,2) 控制精度等，明确单位是分还是元。
- 字符串：string。
- id类：bigint。
- 时间：string。
- 状态：string
3. 数据冗余规范
宽表的冗余字段要确保：
- 冗余字段要使用高频，下游3个或以上使用。
- 冗余字段引入不应造成本身数据产生过多的延后。
- 冗余字段和已有字段的重复率不应过大，原则上不应超过60%，如需要可以选择join或原表拓展。
4. NULL字段处理规范
- 对于维度字段，需设置为-1
- 对于指标字段，需设置为 0
5. 指标口径规范
保证主题域内，指标口径一致，无歧义。
通过数据分层，提供统一的数据出口，统一对外输出的数据口径，避免同一指标不同口径的情况发生。
1) 指标梳理
指标口径的不一致使得数据使用的成本极高，经常出现口径打架、反复核对数据的问题。在数据治理中，我们将需求梳理到的所有指标进行进一步梳理，明确其口径，如果存在两个指标名称相同，但口径不一致，先判断是否是进行合并，如需要同时存在，那么在命名上必须能够区分开。
2) 指标管理
指标管理分为原子指标维护和派生指标维护。
原子指标：
- 选择原子指标的归属产线、业务板块、数据域、业务过程
- 选择原子指标的统计数据来源于该业务过程下的原始数据源
- 录入原子指标的英文名称、中文名称、概述
- 填写指标函数
- 系统根据指标函数自动生成原子指标的定义表达式
- 系统根据指标定义表达式以及数据源表生成原子指标SQL
派生指标：
- 在原子指标的基础之上选择了一些维度或者修饰限定词。
6. 数据表处理规范
1) 增量表
新增数据，增量数据是上次导出之后的新数据。
- 记录每次增加的量，而不是总量；
- 增量表，只报变化量，无变化不用报；
- 每天一个分区。
2) 全量表
每天的所有的最新状态的数据。
- 全量表，有无变化，都要报；
- 每次上报的数据都是所有的数据（变化的 + 没有变化的）；
- 只有一个分区。
3) 快照表
按日分区，记录截止数据日期的全量数据。
- 快照表，有无变化，都要报；
- 每次上报的数据都是所有的数据（变化的 + 没有变化的）；
- 一天一个分区。
4) 拉链表
记录截止数据日期的全量数据。
- 记录一个事物从开始，一直到当前状态的所有变化的信息；
- 拉链表每次上报的都是历史记录的最终状态，是记录在当前时刻的历史总
量； - 当前记录存的是当前时间之前的所有历史记录的最后变化量（总量）；
- 只有一个分区。
7. 表的生命周期管理
这部分主要是要通过对历史数据的等级划分与对表类型的划分生成相应的生命周期管理矩阵。
1) 历史数据等级划分
主要将历史数据划分P0、Pl、P2、P3 四个等级，其具体定义如下：
- P0 ：非常重要的主题域数据和非常重要的应用数据，具有不可恢复性，如交易、日志、集团 KPI 数据、 IPO 关联表。
- Pl ：重要的业务数据和重要的应用数据，具有不可恢复性，如重要的业务产品数据。
- P2 ：重要的业务数据和重要的应用数据，具有可恢复性，如交易线 ETL 产生的中间过程数据。
- P3 ：不重要的业务数据和不重要的应用数据，具有可恢复性，如某些 SNS 产品报表。
2) 表类型划分
- 事件型流水表（增量表）
事件型流水表（增量表）指数据无重复或者无主键数据，如日志。
- 事件型镜像表（增量表）
事件型镜像表（增量表）指业务过程性数据，有主键，但是对于同样主键的属性会发生缓慢变化，如交易、订单状态与时间会根据业务发生变更。
- 维表
维表包括维度与维度属性数据，如用户表、商品表。
- Merge 全量表
Merge 全量表包括业务过程性数据或者维表数据。由于数据本身有新增的或者发生状态变更，对于同样主键的数据可能会保留多份，因此可以对这些数据根据主键进行 Merge 操作，主键对应的属性只会保留最新状态，历史状态保留在前一天分区 中。例如，用户表、交易表等都可以进行 Merge 操作。
- ETL 临时表
ETL 临时表是指 ETL 处理过程中产生的临时表数据，一般不建议保留，最多7天。
- TT 临时数据
TT 拉取的数据和 DbSync 产生的临时数据最终会流转到 DS 层，ODS 层数据作为原始数据保留下来，从而使得 TT&DbSync 上游数据成为临时数据。这类数据不建议保留很长时间，生命周期默认设置为 93天，可以根据实际情况适当减少保留天数。
7. 普通全量表
很多小业务数据或者产品数据，BI一般是直接全量拉取，这种方式效率快，对存储压力也不是很大，而且表保留很长时间，可以根据历史数据等级确定保留策略。
通过上述历史数据等级划分与表类型划分，生成相应的生命周期管理矩阵，如下表所示：
2. 数仓各层开发规范
1. ODS层设计规范
同步规范：
- 一个系统源表只允许同步一次；
- 全量初始化同步和增量同步处理逻辑要清晰；
- 以统计日期和时间进行分区存储；
- 目标表字段在源表不存在时要自动填充处理。
表分类与生命周期：
- ods流水全量表：
- 不可再生的永久保存；
- 日志可按留存要求；
- 按需设置保留特殊日期数据；
- 按需设置保留特殊月份数据；
- ods镜像型全量表：
- 推荐按天存储；
- 对历史变化进行保留；
- 最新数据存储在最大分区；
- 历史数据按需保留；
- ods增量数据：
- 推荐按天存储；
- 有对应全量表的，建议只保留14天数据；
- 无对应全量表的，永久保留；
- ods的etl过程中的临时表：
- 推荐按需保留；
- 最多保留7天；
- 建议用完即删，下次使用再生成；
- BDSync非去重数据：
- 通过中间层保留，默认用完即删，不建议保留。
数据质量：
- 全量表必须配置唯一性字段标识；
- 对分区空数据进行监控；
- 对枚举类型字段，进行枚举值变化和分布监控；
- ods表数据量级和记录数做环比监控；
- ods全表都必须要有注释；
2. 公共维度层设计规范
1) 设计准则
- 一致性
共维度在不同的物理表中的字段名称、数据类型、数据内容必须保持一致（历史原因不一致，要做好版本控制）
- 维度的组合与拆分
- 组合原则：
将维度与关联性强的字段进行组合，一起查询，一起展示，两个维度必须具有天然的关系，如：商品的基本属性和所属品牌。
无相关性：如一些使用频率较小的杂项维度，可以构建一个集合杂项维度的特殊属性。
行为维度：经过计算的度量，但下游当维度处理，例：点击量 0-1000,100-1000等，可以做聚合分类。
- 拆分与冗余：
针对重要性，业务相关性、源、使用频率等可分为核心表、扩展表。
数据记录较大的维度，可以适当冗余一些子集。
2) 存储及生命周期管理
建议按天分区。
- 3个月内最大访问跨度<=4天时，建议保留最近7天分区；
- 3个月内最大访问跨度<=12天时，建议保留最近15天分区；
- 3个月内最大访问跨度<=30天时，建议保留最近33天分区；
- 3个月内最大访问跨度<=90天时，建议保留最近120天分区；
- 3个月内最大访问跨度<=180天时，建议保留最近240天分区；
- 3个月内最大访问跨度<=300天时，建议保留最近400天分区；
3. DWD明细层设计规范
1) 存储及生命周期管理
建议按天分区。
- 3个月内最大访问跨度<=4天时，建议保留最近7天分区；
- 3个月内最大访问跨度<=12天时，建议保留最近15天分区；
- 3个月内最大访问跨度<=30天时，建议保留最近33天分区；
- 3个月内最大访问跨度<=90天时，建议保留最近120天分区；
- 3个月内最大访问跨度<=180天时，建议保留最近240天分区；
- 3个月内最大访问跨度<=300天时，建议保留最近400天分区；
2) 事务型事实表设计准则
- 基于数据应用需求的分析设计事务型事实表，结合下游较大的针对某个业务过程和分析指标需求，可考虑基于某个事件过程构建事务型实时表；
- 一般选用事件的发生日期或时间作为分区字段，便于扫描和裁剪；
- 冗余子集原则，有利于降低后续IO开销；
- 明细层事实表维度退化，减少后续使用join成本。
3) 周期快照事实表
- 周期快照事实表中的每行汇总了发生在某一标准周期，如某一天、某周、某月的多个度量事件。
- 粒度是周期性的，不是个体的事务。
- 通常包含许多事实，因为任何与事实表粒度一致的度量事件都是被允许的。
4) 累积快照事实表
- 多个业务过程联合分析而构建的事实表，如采购单的流转环节。
- 用于分析事件时间和时间之间的间隔周期。
- 少量的且当前事务型不支持的，如关闭、发货等相关的统计。
4. DWS公共汇总层设计规范
数据仓库的性能是数据仓库建设是否成功的重要标准之一。聚集主要是通过汇总明细粒度数据来获得改进查询性能的效果。通过访问聚集数据，可以减少数据库在响应查询时必须执行的工作量，能够快速响应用户的查询，同时有利于减少不同用访问明细数据带来的结果不一致问题。
1) 聚集的基本原则
- 一致性。聚集表必须提供与查询明细粒度数据一致的查询结果。
- 避免单一表设计。不要在同一个表中存储不同层次的聚集数据。
- 聚集粒度可不同。聚集并不需要保持与原始明细粒度数据一样的粒度，聚集只关心所需要查询的维度。
2) 聚集的基本步骤
第一步：确定聚集维度
在原始明细模型中会存在多个描述事实的维度，如日期、商品类别、卖家等，这时候需要确定根据什么维度聚集，如果只关心商品的交易额情况，那么就可以根据商品维度聚集数据。
第二步：确定一致性上钻
这时候要关心是按月汇总还是按天汇总，是按照商品汇总还是按照类目汇总，如果按照类目汇总，还需要关心是按照大类汇总还是小类汇总。当然，我们要做的只是了解用户需要什么，然后按照他们想要的进行聚集。
第三步：确定聚集事实
在原始明细模型中可能会有多个事实的度量，比如在交易中有交易额、交易数量等，这时候要明确是按照交易额汇总还是按照成交数量汇总。
3) 公共汇总层设计原则
除了聚集基本的原则外，公共汇总层还必须遵循以下原则：
- 数据公用性。汇总的聚集会有第三者使用吗？基于某个维度的聚集是不是经常用于数据分析中？如果答案是肯定的，那么就有必要把明细数据经过汇总沉淀到聚集表中。
- 不跨数据域。数据域是在较高层次上对数据进行分类聚集的抽象。如以业务
- 区分统计周期。在表的命名上要能说明数据的统计周期，如
_Id
表示最近1天，_td表示截至当天，_nd表示最近N天。
3. 数仓命名规范
1. 词根设计规范
词根属于数仓建设中的规范，属于元数据管理的范畴，现在把这个划到数据治理的一部分。完整的数仓建设是包含数据治理的，只是现在谈到数仓偏向于数据建模， 而谈到数据治理，更多的是关于数据规范、数据管理。
表命名，其实在很大程度上是对元数据描述的一种体现，表命名规范越完善，我 们能从表名获取到的信息就越多。比如：一部分业务是关于货架的，英文名是：rack， rack 就是一个词根，那我们就在所有的表、字段等用到的地方都叫 rack，不要叫成 别的什么。这就是词根的作用，用来统一命名，表达同一个含义。
指标体系中有很多“率”的指标，都可以拆解成 XXX+率，率可以叫 rate，那我 们所有的指标都叫做 XXX+rate。
词根：可以用来统一表名、字段名、主题域名等等。
举例： 以流程图的方式来展示，更加直观和易懂，本图侧重 dwm 层表的命名 规范，其余命名是类似的道理：
第一个判断条件是该表的用途，是中间表、原始日志还是业务展示用的表 如果该表被判断为中间表，就会走入下一个判断条件：表是否有 group 操作 通过是否有 group 操作来判断该表该划分在 dwd 层还是 dwm 和 dws 层 如果不是 dwd 层，则需要判断该表是否是多个行为的汇总表（即宽表） 最后再分别填上事业群、部门、业务线、自定义名称和更新频率等信息即可。
分层：表的使用范围
事业群和部门：生产该表或者该数据的团队
业务线：表明该数据是哪个产品或者业务线相关
主题域：分析问题的角度，对象实体
自定义：一般会尽可能多描述该表的信息，比如活跃表、留存表等
更新周期：比如说天级还是月级更新
数仓表的命名规范如下：
1. 数仓层次:
公用维度：dim
DM层：dm
ODS层：ods
DWD层：dwd
DWS层：dws
2. 周期/数据范围：
日快照：d
增量：i
全量：f
周：w
拉链表：l
非分区全量表：a
2. 表命名规范
1) 常规表
常规表是我们需要固化的表，是正式使用的表，是目前一段时间内需要去维护去 完善的表。
规范：分层前缀[dwd|dws|ads]_部门_业务域_主题域_XXX_更新周期|数据范围
业务域、主题域我们都可以用词根的方式枚举清楚，不断完善。
更新周期主要的是时间粒度、日、月、年、周等。
2) 中间表
中间表一般出现在 Job 中，是 Job 中临时存储的中间数据的表，中间表的作 用域只限于当前 Job 执行过程中，Job 一旦执行完成，该中间表的使命就完 成了，是可以删除的（按照自己公司的场景自由选择，以前公司会保留几天 的中间表数据，用来排查问题）。
规范：mid_table_name_[0~9|dim]
table_name 是我们任务中目标表的名字，通常来说一个任务只有一个目标表。
这里加上表名，是为了防止自由发挥的时候表名冲突，而末尾大家可以选择自由发挥，起一些有意义的名字，或者简单粗暴，使用数字代替，各有优劣吧，谨慎选择。
通常会遇到需要补全维度的表，这里使用 dim 结尾。
如果要保留历史的中间表，可以加上日期或者时间戳。
3) 临时表
临时表是临时测试的表，是临时使用一次的表，就是暂时保存下数据看看，后续一般不再使用的表，是可以随时删除的表。
规范：tmp_xxx
只要加上 tmp 开头即可，其他名字随意，注意 tmp 开头的表不要用来实际使用，只是测试验证而已。
4) 维度表
维度表是基于底层数据，抽象出来的描述类的表。维度表可以自动从底层表抽象出来，也可以手工来维护。
规范：dim_xxx
维度表，统一以 dim 开头，后面加上，对该指标的描述。
5) 手工表
手工表是手工维护的表，手工初始化一次之后，一般不会自动改变，后面变更，也是手工来维护。
一般来说，手工的数据粒度是偏细的，所以暂时统一放在 dwd 层，后面如果有目标值或者其他类型手工数据，再根据实际情况分层。
规范：dwd_业务域_manual_xxx
手工表，增加特殊的主题域，manual，表示手工维护表。
3. 指标命名规范
公共规则
- 所有单词小写
- 单词之间下划线分割（反例：appName 或 AppName）
- 可读性优于长度 (词根，避免出现同一个指标，命名一致性)
- 禁止使用 sql 关键字，如字段名与关键字冲突时 +col
- 数量字段后缀 _cnt 等标识...
- 金额字段后缀 _price 标识
- 天分区使用字段 dt，格式统一（yyyymmdd 或 yyyy-mm-dd）
- 小时分区使用字段 hh，范围（00-23）
- 分钟分区使用字段 mi，范围（00-59）
- 布尔类型标识：is_{业务}，不允许出现空值
