离线数据仓库
1 数据仓库建模
1.1 建模工具
PowerDesigner/SQLYog/EZDML…
1.2 ODS层
（1）保持数据原貌不做任何修改，起到备份数据的作用。
（2）数据采用压缩，减少磁盘存储空间（例如：压缩采用Snappy，压缩比是100g数据压缩完10g左右，存储采用ORC）
（3）创建分区表，防止后续的全表扫描
1.3 DWD层
DWD层需拆分业务事件做业务解耦、构建一致性维度、构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。
维度建模一般按照以下四个步骤：
选择业务过程→声明粒度→确认维度→确认事实
（1）选择业务过程
在业务系统中，如果业务表过多，挑选感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。如果小公司业务表比较少，建议选择所有业务线。
（2）声明粒度
数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。
声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。
典型的粒度声明如下：
① 订单当中的每个商品项作为下单事实表中的一行，粒度为每次
② 每周的订单次数作为一行，粒度为每周。
③ 每月的订单次数作为一行，粒度为每月。
如果在DWD层粒度就是每周或者每月，那么后续就没有办法统计细粒度的指标了。所有建议采用最小粒度。
（3）确定维度
维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。 例如：时间维度、用户维度、地区维度等常见维度。
（4）确定事实
“事实”指的是业务中的度量值，例如订单金额、下单次数等。
在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。
通过以上步骤，结合数仓的业务事实可以得出业务总线矩阵表。业务总线矩阵的原则，主要是根据维度表和事实表之间的关系，如果两者有关联则使用√标记。
业务总线矩阵表示例：
| 时间 | 用户 | 地区 | 商品 | 优惠券 | 活动 | 编码 | 度量值 | |
|---|---|---|---|---|---|---|---|---|
| 订单 | √ | √ | √ | √ | 件数/金额 | |||
| 订单详情 | √ | √ | √ | 件数/金额 | ||||
| 支付 | √ | √ | √ | 次数/金额 | ||||
| 加购 | √ | √ | √ | 件数/金额 | ||||
| 收藏 | √ | √ | √ | 个数 | ||||
| 评价 | √ | √ | √ | 个数 | ||||
| 退款 | √ | √ | √ | 件数/金额 | ||||
| 优惠券领用 | √ | √ | √ | 个数 |
总线矩阵每一行代表一个业务过程，业务过程可以理解为整体流程中的节点或者原子性事件，每一列代表维度，一个业务过程需要选择感兴趣的维度，一个业务过程一张事实表。
总线矩阵可做可不做，一般根据需求指标拆解，比如最新七天各品牌下单人数，可以拆解出维度为品牌，统计周期为7天，所属业务过程为下单，从而DWD层就可以提取出下单事实表和品牌维度。维度建模其实就是按照需求来拆分指标和业务，ER建模就是从数据中充分理解数据和业务进行整合(建模难度大)。
维度退化：
根据维度建模中的星型模型思想，将维度进行退化。 例如下图所示：地区表和省份表退化为地区维度表，商品表、品类表、spu表、商品三级分类、商品二级分类、商品一级分类表退化为商品维度表，活动信息表和活动规则表退化为活动维度表。
维度表需要单独创建，也可以将维度表字段退化到事实表构成明细宽表，维度退化的除了有将多层级维度表退化为单层级维度表也包括将维表字段整合进事实表。总线矩阵中维度即为维表的抽象提取。
1.3.1 数据清洗
① 空值去除
② 过滤核心字段无意义的数据，比如订单表中订单id为null，支付表中支付id为空
③ 将用户行为宽表和业务表进行数据一致性处理
select case when a is null then b else a end as JZR,
...
from A
④ 对手机号、身份证号等敏感数据脱敏
1.3.2 清洗的手段
HQL、MR、SparkSQL、Kettle、Python
1.3.3 维度退化
对业务数据传过来的表进行维度退化和降维。（商品一级二级三级、省市县、年月日）
商品表、spu表、品类表、商品一级分类、二级分类、三级分类=》商品表
省份表、地区表=》地区表
1.3.4 存储格式
数据压缩：LZO，BZip，Snappy…
列式存储：textFile，ORC，Parquet，一般企业里使用ORC或者Parquet，因为是列式存储，且压缩比非常高，所以相比于textFile，查询速度快，占用硬盘空间少
1.4 DWS层
DWS层统计各个主题对象的当天行为，服务于DWT层的主题宽表。如图所示，DWS层的宽表字段，是站在不同维度的视角去看事实表，重点关注事实表的度量值，通过与之关联的事实表，获得不同的事实表的度量值。
从指标体系看，dwd就是原子指标层，dws就是派生层，ads就是衍生层，衍生指标可算可不算，Ads层更多的是构建应用主题，专题应用，如客户画像，形成数据资产。
真正纬度建模是在dwd,dws。dws层也可构建宽表，宽表都是按照主题去建，主题相当于观察问题的角度，对应着维度表。
用户行为宽表，商品宽表，访客宽表、活动宽表、优惠卷、地区表等。
用户行为宽表示例：
评论、打赏、收藏、关注–商品、关注–人、点赞、分享、好价爆料、文章发布、活跃、签到、补签卡、幸运屋、礼品、金币、电商点击、gmv
CREATE TABLE `app_usr_interact`(
`stat_dt` date COMMENT '互动日期',
`user_id` string COMMENT '用户id',
`nickname` string COMMENT '用户昵称',
`register_date` string COMMENT '注册日期',
`register_from` string COMMENT '注册来源',
`remark` string COMMENT '细分渠道',
`province` string COMMENT '注册省份',
`pl_cnt` bigint COMMENT '评论次数',
`ds_cnt` bigint COMMENT '打赏次数',
`sc_add` bigint COMMENT '添加收藏',
`sc_cancel` bigint COMMENT '取消收藏',
`gzg_add` bigint COMMENT '关注商品',
`gzg_cancel` bigint COMMENT '取消关注商品',
`gzp_add` bigint COMMENT '关注人',
`gzp_cancel` bigint COMMENT '取消关注人',
`buzhi_cnt` bigint COMMENT '点不值次数',
`zhi_cnt` bigint COMMENT '点值次数',
`zan_cnt` bigint COMMENT '点赞次数',
`share_cnts` bigint COMMENT '分享次数',
`bl_cnt` bigint COMMENT '爆料数',
`fb_cnt` bigint COMMENT '好价发布数',
`online_cnt` bigint COMMENT '活跃次数',
`checkin_cnt` bigint COMMENT '签到次数',
`fix_checkin` bigint COMMENT '补签次数',
`house_point` bigint COMMENT '幸运屋金币抽奖次数',
`house_gold` bigint COMMENT '幸运屋积分抽奖次数',
`pack_cnt` bigint COMMENT '礼品兑换次数',
`gold_add` bigint COMMENT '获取金币',
`gold_cancel` bigint COMMENT '支出金币',
`surplus_gold` bigint COMMENT '剩余金币',
`event` bigint COMMENT '电商点击次数',
`gmv_amount` bigint COMMENT 'gmv',
`gmv_sales` bigint COMMENT '订单数')
PARTITIONED BY ( `dt` string)
1.5 DWT层
以分析的主题对象为建模驱动，基于上层的应用和产品的指标需求，构建主题对象的全量宽表。
DWT层主题宽表都记录什么字段？
如图所示，每个维度关联的不同事实表度量值以及首次、末次时间、累积至今的度量值、累积某个时间段的度量值。
1.6 ADS层
ads层做夸业务过程跨主题数据合并，这种叫融合事实表，面向应用分析
分别对设备主题、会员主题、商品主题和营销主题进行指标分析，其中营销主题是用户主题和商品主题的跨主题分析案例。
指标示例：日活、月活、周活、留存、留存率、新增（日、周、年）、转化率、流失、回流、七天内连续3天登录（点赞、收藏、评价、购买、加购、下单、活动）、连续3周（月）登录、GMV、复购率、复购率排行、点赞、评论、收藏、领优惠卷人数、使用优惠卷人数、沉默、值不值得买、退款人数、退款率 topn 热门商品
2 维度表和事实表
2.1 维度表
维度表：一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。 例如：用户、商品、日期、地区等。
2.2 事实表
事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、件数、金额等），例如，订单事件中的下单金额。
每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键、通常具有两个和两个以上的外键、外键之间表示维表之间多对多的关系。基本一张事物事实表，由纬度外键，退化纬度，加度量组成,度量可以理解为原子指标。
2.2.1 事务型事实表
以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。
2.2.2 周期型快照事实表
周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等。
2.2.3 累积型快照事实表
累计快照事实表用于跟踪业务事实的变化。例如，数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。
| 订单id | 用户id | 下单时间 | 打包时间 | 发货时间 | 签收时间 | 订单金额 |
|---|---|---|---|---|---|---|
| 3-8 | 3-8 | 3-9 | 3-10 |
3 同步策略
4 关系型数据库范式理论（ER建模）
三范式：
1NF：属性不可再分割（例如不能存在5台电脑的属性，坏处：表都没法用）
2NF：不能存在部分函数依赖（例如主键（学号+课名）–>成绩，姓名，但学号–》姓名，所以姓名部分依赖于主键（学号+课名），所以要去除，坏处：数据冗余）
3NF：不能存在传递函数依赖（学号–》宿舍种类–》价钱，坏处：数据冗余和增删异常）
MySQL关系模型：关系模型主要应用与OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第三范式的。
Hive 维度模型：维度模型主要应用于OLAP系统中，因为关系模型虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。所以HIVE把相关各种表整理成两种：事实表和维度表两种。所有维度表围绕着事实表进行解释。
5 数据建模用的哪些模型？
5.1 星型模型（一级维度表）
星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。 星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：
a. 维表只和事实表关联，维表之间没有关联；
b. 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；
c. 以事实表为核心，维表围绕核心呈星形分布。
5.2 雪花模型（多级维度）
雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能比星型模型要低。
5.3 星座模型（星型模型+多个事实表）
星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。
6 拉链表 (数据仓库中如何创建拉链表？)
拉链表处理的业务场景：主要处理缓慢变化维的业务场景（用户表、订单表）。
7 即席查询数据仓库
Kylin: T+1
Impala: CDH
Presto: Apache版本框架
8 权限管理
Ranger或Sentry
CDH cloudmanager-》sentry
HDP ambari=>ranger
① 用户认证kerberos（张三、李四、王五）
② 表级别权限（张三、李四）
③ 字段级别权限（李四）
9 可视化报表工具
Echarts（百度开源）
Kibana（开源）
Tableau（功能强大的收费软件）
Superset（功能一般免费）
QuickBI（阿里云收费的离线）
DataV（阿里云收费的实时）
suga（百度，收费）
10 集群监控工具
Zabbix+ Grafana
Prometheus&Grafana监控
睿象云
11 元数据管理（Atlas血缘系统）
insert into table ads_user
select id, name from dwt_user
依赖关系能够做到：表级别和字段级别
用处：作业执行失败，评估他的影响范围。 主要用于表比较多的公司。
12 数据质量监控（Griffin）
12.1 监控原则
12.1.1 单表数据量监控
一张表的记录数在一个已知的范围内，或者上下浮动不会超过某个阈值
-
SQL结果：var 数据量 = select count（*）from 表 where 时间等过滤条件
-
报警触发条件设置：如果数据量不在[数值下限, 数值上限]， 则触发报警
-
同比增加：如果((本周的数据量 - 上周的数据量)/上周的数据量*100)不在 [比例下线，比例上限]，则触发报警
-
环比增加：如果((今天的数据量 - 昨天的数据量)/昨天的数据量*100)不在 [比例下线，比例上限]，则触发报警
-
报警触发条件设置一定要有。如果没有配置的阈值，不能做监控
12.1.2 单表空值检测
某个字段为空的记录数在一个范围内，或者占总量的百分比在某个阈值范围内
-
目标字段：选择要监控的字段，不能选“无”
-
SQL结果：var 异常数据量 = select count(*) from 表 where 目标字段 is null
-
单次检测：如果（异常数据量）不在[数值下限, 数值上限]，则触发报警
12.1.3 单表重复值检测
一个或多个字段是否满足某些规则
-
目标字段：第一步先正常统计条数；select count(*) form 表；
-
第二步，去重统计；select count(*) from 表 group by 某个字段
-
第一步的值和第二步不的值做减法，看是否在上下线阀值之内
-
单次检测：如果（异常数据量）不在[数值下限, 数值上限]， 则触发报警
12.1.4 单表值域检测
一个或多个字段没有重复记录
-
目标字段：选择要监控的字段，支持多选
-
检测规则：填写“目标字段”要满足的条件。其中$1表示第一个目标字段，$2表示第二个目标字段，以此类推。上图中的“检测规则”经过渲染后变为“delivery_fee = delivery_fee_base+delivery_fee_extra”
-
阈值配置与“空值检测”相同
12.1.5 跨表数据量对比
主要针对同步流程，监控两张表的数据量是否一致
-
SQL结果：count（本表） - count（关联表）
-
阈值配置与“空值检测”相同
12.2 数据质量实现
数据质量的高低代表了该数据满足数据消费者期望的程度，这种程度基于他们对数据的使用预期，只有达到数据的使用预期才能给予管理层正确的决策参考。数据质量管理作为数据仓库的一个重要模块，主要可以分为数据的健康标准量化、监控和保障。
12.2.1 数据质量标准分类
① 数据完整性: 数据不存在大量的缺失值、不缺少某一日期/部门/地点等部分维度的数据，同时在ETL过程当中应保证数据的完整不丢失。验证数据时总数应符合正常规律时间推移，记录数总数的增长符合正常的趋势。
② 数据一致性: 数仓各层的数据，应与上一层保持数据一致，最终经过数据清洗转化（ETL）的宽表/指标能和数据源保持一致。
12.2.2 数据质量管理解决方案
① 可以通过Shell命令和Hive脚本的方式，通过验证增量数据的记录数、全表空值记录数、全表记录数是否在合理的范围之内，以及验证数据来源表和目标表一致性，确定当日的数据是否符合健康标准，达到数据质量的监控与管理。
② 数据质量之Griffin，Griffin有着较为严重的版本依赖；Apache Griffin是一个开源的大数据数据质量解决方案，它支持批处理和流模式两种数据质量检测方式，可以从不同维度度量数据资产，从而提升数据的准确度和可信度。例如：离线任务执行完毕后检查源端和目标端的数据数量是否一致，源表的数据空值等。
13 数据治理
包括：数据质量管理、元数据管理、权限管理（ranger sentry）、数仓
2019年下半年 国家出了一本白皮书，要求给政府做的数仓项目，要具备如下功能：
数据治理是一个复杂的系统工程，涉及到企业和单位多个领域，既要做好顶层设计，又要解决好统一标准、统一流程、统一管理体系等问题，同时也要解决好数据采集、数据清洗、数据对接和应用集成等相关问题。
数据治理实施要点主要包含数据规划、制定数据标准、整理数据、搭建数据管理工具、构建运维体系及推广贯标六大部分，其中数据规划是纲领、制定数据标准是基础、整理数据是过程、搭建数据管理工具是技术手段、构建运维体系是前提，推广贯标是持续保障。
14 数据中台
传统IT企业，项目的物理结构都可分为“前台”和“后台”这两部分,所谓前台即包括各种和用户直接交互的界面，比如web页面，手机app；也包括服务端各种实时响应用户请求的业务逻辑，比如商品查询、订单系统等等;后台并不直接面向用户，而是面向运营人员的配置管理系统，比如商品管理、物流管理、结算管理。后台为前台提供了一些简单的配置。
传统项目痛点–重复造轮子:
14.1 各家中台架构示例
1）SuperCell公司
2）阿里巴巴提出了“大中台，小前台”的战略
3）华为提出了“平台炮火支撑精兵作战”的战略
14.2 中台具体划分
1）业务中台
2）技术中台
3）数据中台
4）算法中台
14.3 中台使用场景
① 从0到1的阶段，没有必要搭建中台。(从0到1的创业型公司)
② 从1到N的阶段，适合搭建中台。(当企业有了一定规模)
③ 从N到N+1的阶段，搭建中台势在必行。
15 数据湖
数据湖（Data Lake）是一个存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析及传输。
hudi、iceberg、Data Lake
目前，Hadoop是最常用的部署数据湖的技术，所以很多人会觉得数据湖就是Hadoop集群。数据湖是一个概念，而Hadoop是用于实现这个概念的技术。
| 数据仓库 | 数据湖 |
|---|---|
| 主要处理历史的、结构化的数据，而且这些数据必须与数据仓库事先定义的模型吻合。 | 能处理所有类型的数据，如结构化数据，非结构化数据，半结构化数据等，数据的类型依赖于数据源系统的原始数据格式。非结构化数据（语音、图片、视频等） |
| 数据仓库分析的指标都是产品经理提前规定好的。按需分析数据。（日活、新增、留存、转化率） | ①根据海量的数据，挖掘出规律，反应给运营部门。②从海量的数据中找寻规律。拥有非常强的计算能力用于处理数据。③数据挖掘 |
16 数据埋点
收费的埋点：神策
目前主流的埋点方式，有代码埋点（前端/后端）、可视化埋点、全埋点三种。
代码埋点是通过调用埋点SDK函数，在需要埋点的业务逻辑功能位置调用接口，上报埋点数据。例如，我们对页面中的某个按钮埋点后，当这个按钮被点击时，可以在这个按钮对应的 OnClick 函数里面调用SDK提供的数据发送接口，来发送数据。
可视化埋点只需要研发人员集成采集 SDK，不需要写埋点代码，业务人员就可以通过访问分析平台的“圈选”功能，来“圈”出需要对用户行为进行捕捉的控件，并对该事件进行命名。圈选完毕后，这些配置会同步到各个用户的终端上，由采集 SDK 按照圈选的配置自动进行用户行为数据的采集和发送。
全埋点是通过在产品中嵌入SDK，前端自动采集页面上的全部用户行为事件，上报埋点数据，相当于做了一个统一的埋点。然后再通过界面配置哪些数据需要在系统里面进行分析。
17 电商8类基本指标
18 直播指标
19 为什么要对数据仓库分层？
• 用空间换时间，通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据。
• 如果不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大。
• 通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。
20 数据分析方法论了解过哪些？
数据商业分析的目标是利用大数据为所有职场人员做出迅捷，高质，高效的决策提供可规模化的解决方案。商业分析是创造价值的数据科学。
数据商业分析中会存在很多判断：
- 观察数据当前发生了什么？
比如想知道线上渠道 A、B 各自带来了多少流量，新上线的产品有多少用户喜欢，新注册流中注册的人数有多少。这些都需要通过数据来展示结果。
- 理解为什么发生？
我们需要知道渠道 A 为什么比渠道 B 好，这些是要通过数据去发现的。也许某个关键字带来的流量转化率比其他都要低，这时可以通过信息、知识、数据沉淀出发生的原因是什么。
- 预测未来会发生什么？
在对渠道 A、B 有了判断之后，根据以往的知识预测未来会发生什么。在投放渠道 C、D 的时候，猜测渠道 C 比渠道 D 好，当上线新的注册流、新的优化，可以知道哪一个节点比较容易出问题，这些都是通过数据进行预测的过程。
- 商业决策
所有工作中最有意义的还是商业决策，通过数据来判断应该做什么。这是商业分析最终的目的。
21 维度建模和范式建模的优缺点和区别
维度建模是一种基于事实表和维度表的建模方法。事实表包含度量（例如销售额、订单数量等）和外键引用到维度表（例如时间、产品、地理位置等），维度表包含描述度量的维度属性。
维度建模优点：
① 易于理解和维护，因为模型数据结构直观简单，易于与业务沟通。
② 查询效率高，因为常用的查询都可以通过连接少量表格得到结果。
③ 支持快速查询和分析多维度的数据，便于决策支持。
④ 开发周期短，能够快速迭代。
维度建模缺点：
① 维度表中的冗余数据会占用大量存储空间。
② 数据的粒度可能过于粗略或过于细致，需要合理选择度量和维度的层级。
范式建模是一种基于关系数据库范式的建模方法，将数据拆分成多个表，每个表表示一个实体或关系。
范式建模优点：
① 范式建模遵循第三范式，即每个属性的值唯一，每个非主属性必须完全依赖于整个主键，每个非主属性不能依赖于其他关系中的属性。这种方法使得数据库设计具有高度的规范性，不容易出现数据异常和冗余，节省存储空间。
② 数据的粒度比较细致，可以支持更多的业务需求。
③ 更新和维护数据时，只需要更新单独的表，而不会影响其他表。
④ 数据结构规范，能够保证数据的一致性和完整性，易于维护
范式建模缺点：
① 查询效率较低，需要进行多次关联查询。
② 不够直观，需要理解多个表格之间的关系。
③ 不支持快速查询和分析多维度的数据。
④ 结构死板，部署周期较长。
总体来说，维度建模适用于分析型场景，适合对数据进行汇总、统计、分析等操作，而范式建模适用于OLTP场景，适合对数据进行增删改查等操作。 在实际应用中，根据业务需求和数据特点进行选择和平衡，或者采用维度建模和范式建模的混合方式来处理数据仓库建模。
22 指标重复性建设问题怎么处理？
① 进行数据质量评估：在数据仓库建设的各个阶段都应该根据标准进行数据质量检测和规范，及时进行治理，避免事后的清洗工作。
② 统一指标和维度管理：对指标命名、计算口径、统计来源进行唯一化管理，对维度定义规范、维度值进行一致化管理。
③ 避免重复建设：进行指标生产时需要避免重复建设，同时需要注意数据汇算成本[3]。
④ 统一数据出口、场景化覆盖：对数据出口进行统一化管理，同时针对不同的场景进行定制化管理[3]。
⑤ 产品化支持：建立统一的指标体系管理工具，从生产到消费数据流打通系统产品层面[3]。
需要注意的是，以上措施需要在数据仓库建设的不同阶段进行落实，确保数据质量和指标一致性的持续性。同时，对于已经存在的重复指标，需要进行去重和整合，确保数据的一致性和可用性。
23 指标怎么设计的？
23.1 选指标的科学方法
选指标的常用方法包括指标分级法和OSM模型。指标分级是按照企业的战略目标、组合和业务过程进行自上而下的指标分级，分为三级：T1，T2，T3，根据企业的需求进行层层剖析。 科学的选指标可以更好地量化思考，自上而下业务驱动指标体系建设。
23.2 指标说明规范
指标说明是对指标统计口径、具体算法的抽象，防止统计口径、计算逻辑不一致导致的数据结果问题，同时指标的明确规范也可以减少业务沟通，提升研发效率。指标分为原子指标、派生指标和衍生指标。
23.3 指标平台
指标平台可以帮助数据需求方自主选择修饰词、维度、原生指标、传入公式，获得想要的指标，并且提供不同的导出数据的方式。指标平台可以控制数据权限、减少业务沟通，提高效率。
总之，在设计数据仓库指标时，需要从企业的战略目标、组合和业务过程出发，科学选指标，制定指标规范，使用指标平台进行指标设计，从而保证数据分析的准确性和有效性。
24 指标字典库怎么设计？
指标字典是数据分析和业务决策中的重要工具，它用于规范维度和量度命名，避免数据混乱，提高数据质量。 关于指标字典的设计，以下是几个方面的建议和属性：
① 按主题或者场景分类：根据不同的业务场景，将指标进行分类，以便于用户查找和使用。 例如，电商平台可以将指标按照订单、用户、营销、运营等方面进行分类。
② 指标类型：指标可以分为基础指标和复合指标。 基础指标是最最原始的单纯指标，不可以再细分了，例如订单数、订单金额；而复合指标是在基础指标的基础上通过各种运算生成的，例如下单率=下单订单数/加购数。
③ 给指标制定编号：指标编号可以方便统计，也避免后续有相同的指标可以跳过。
④ 推荐图表：根据不同的指标类型，推荐相应的展现图表，以便于用户更加直观地了解数据。
⑤ 列出指标名称：列出所有的指标名称，要求命名规则尽量明确、通用、易懂。
⑥ 统一计算公式：统一确定指标的计算公式，避免因计算方式不同而产生的差异。
⑦ 确定数据源：确定数据的来源，确保指标的数据来源可靠、准确。
⑧ 确定分析维度：确定分析的维度，以及数据分析的粒度大小，例如时间、地域、用户属性等。维度是分析的角度和拆分方向，当指标叠加上维度，就能生成各种符合业务场景的指标了。
⑨ 限定条件：描述指标的限定条件，例如限定用户都是新用户。
⑩ 制定指标的意义和背景：说明制定指标的意义和背景，帮助用户更好地理解指标的含义和作用。
需要注意的是，在指标字典的设计过程中，还需要解决指标的统一问题和数据源问题。对于同一个指标，不同的公司或者部门的理解可能不同，因此需要讨论解决公式的统一问题。同时，数据源的问题也需要认真考虑，保证数据的质量和准确性。
25 指标库怎么按照条件查询有没有重复的指标？
要按照条件查询是否存在重复的指标，可以在指标库中进行全局搜索或者查询指标系统中是否存在相同的指标。指标库的功能可以包括指标元数据、指标数据血缘、指标分级、指标体系构建、指标生命周期等。 建立一个指标系统平台可以方便用户取数，统一管理指标信息和口径，将核心维度和量度注入元数据中心，实现不需要写 SQL 即可完成自助查询及分析需求，并可基于此平台搭建自助拖拽指标形成分析图表。在指标系统平台中，用户选择的修饰词、维度、原生指标等已经生成过相应的指标时，应当提示用户来避免重复开发和计算。最终目的是统一管理全公司的指标，提高数据开发效率，降低沟通成本。
26 指标热度怎么统计？
指标热度是指某项指标在一定时间范围内的热度趋势，通常是通过统计指标的数量和质量两个方面来衡量。其中，指标可以分为绝对数指标和相对数指标，绝对数指标反映的是规模大小的指标，如人口数、GDP、收入、用户数，而相对数指标主要用来反映质量好坏的指标，如利润率、留存率、覆盖率等。因此，指标热度的统计方法应该根据具体情况选择合适的指标类型和统计口径。
对于舆论热度指数，它是能直观体现某一事件或话题在网上的关注度、传播声量、热度走势变化的数据。在统计舆论热度指数时，可以考虑以下因素：话题的搜索量、讨论量、分享量、转发量、评论量等，以及这些量在一定时间范围内的变化趋势。
知乎热榜的统计方法，是在一个周期开始的节点统计所有帖子的热度值，作为对比数据存下来；然后在这个周期结束时再取一遍所有帖子的热度值，相减取差值倒叙排列，得到这个时间段内热度上升最快的排名，再取头部信息作为下期热榜的更新内容。这个周期性会动态调整，根据用户数据反馈可能一天统计一次，也可能是好几次。
综上所述，不同类型的指标热度可以采用不同的统计方法。在进行指标热度统计时，应该结合具体情况选择合适的指标类型和统计口径，以及考虑到一定时间范围内的变化趋势。
27 数仓建模过程？
数仓建模是构建数据仓库的重要步骤之一，其过程分为业务建模、领域建模、逻辑建模和物理建模等阶段。数仓建模的七个步骤为：梳理业务流程、垂直切分（划分主题域）、指标体系梳理、表实体关系调研、维度梳理、数仓分层以及物理模型建立。
① 梳理业务流程阶段是为了找到核心业务流程，理解业务节点的客户及关注重点，找到数据在哪。
② 在垂直切分阶段，应按照业务领域划分主题域，选择自下而上或自顶而下的建设方式。
③ 指标体系梳理阶段需要根据业务部门进行划分，理清部门之间的关系，并将各个部门的具体业务程序化，与业务部门开会协商出需求的指标、保存年限、维度等等。
④ 表实体关系调研阶段需要梳理出不同表之间的关系，并确定事实表和维度表的设计。
⑤ 在维度梳理阶段，需要选择业务过程、声明粒度、确认维度、确认事实。
⑥ 数仓分层阶段则是将数据仓库划分为DWD层、DWS层和DWT层。
⑦ 物理模型建立阶段需要根据前面的逻辑建模设计出具体的物理模型[2]。
总之，数仓建模过程需要在深入理解业务需求的基础上，按照一定的流程和步骤逐步推进，最终得到合适的数仓设计。
28 元数据怎么设计的？怎么建设元数据管理？
数据仓库元数据是描述数据仓库内数据结构和建立方法的数据，可以帮助数据仓库管理员和数据仓库的开发人员方便地找到所需的数据。 根据用途的不同，元数据可分为技术元数据和业务元数据。
设计和建设元数据管理需要考虑以下步骤：
① 定义元数据需求和规范：首先需要明确数据仓库的业务目标和需求，然后根据这些需求定义元数据的规范和需求。
② 确定元数据的范围和分类：根据数据仓库的目标和需求，确定元数据的范围和分类。例如，可以将元数据分为技术元数据和业务元数据。
③ 收集和建立元数据：收集和建立元数据是一个复杂的过程。需要通过不同的方式收集元数据，包括手动输入、自动扫描和使用元数据管理工具等方式。 建立元数据需要考虑不同的技术和业务要求。
④ 维护和更新元数据：元数据的维护和更新是持续的过程，需要定期进行。可以使用元数据管理工具来管理和更新元数据，以确保元数据的准确性和完整性。
⑤ 应用元数据：元数据的应用是将元数据与数据仓库相关的应用程序相结合的过程。可以通过数据仓库管理工具将元数据应用于数据仓库中的查询、报告和分析。
⑥ 监控和评估元数据：监控和评估元数据是确保元数据一直符合业务需求的过程。可以使用元数据管理工具来监控元数据的质量和准确性，以及评估元数据的有效性和可用性。
以上是设计和建设元数据管理的一般步骤，具体实施需要结合具体的业务需求和技术要求。
29 数据质量，数据稽查怎么做的？
数据仓库作为企业决策的基础设施之一，数据质量是保证数据仓库价值的重要因素之一。为保障数据仓库数据质量，数据稽查是必不可少的环节。以下是一些常见的数据质量稽查方法：
① 数据质量性质分类：一致性、完整性、时效性是常见的数据质量性质。其中一致性可以考虑误差是否在可接受范围内，以及在数据传递过程中是否丢失或重复记录；完整性则可以考虑数据的维度和内容是否充足，以及字段值是否缺失；时效性则是指数据的更新频率是否满足业务需求。
② ETL处理错误处理：当遇到错误数据时，ETL可以提供以下4种解决方案：1）通过记录，但未经任何处理；2）通过记录并打上错误标记；3）拒绝记录；4）停止ETL任务。其中，选项1不能保证数据质量，而选项3会导致数据遗弃，最常见的方法是选择选项2，即通过特殊处理保证数据的完整性，并通过报表反映出来。
③ 代码提交核查：开发人员可以通过规则引擎辅助代码提交校验，如代码规范、代码质量和代码性能等方面的规则分类，以确保代码质量[3]。
④ 数据处理风险监控：对数据的更新操作需要通知下游数据变更的原因、逻辑和时间等信息，并在下游没有异议的情况下，按照约定的时间执行变更发布操作。
在进行数据仓库数据稽查时，需要根据具体业务场景和数据特征，选择合适的稽查方法，以提高数据仓库数据质量的可信度和可用性。
30 缓慢变化维
数据仓库中的缓慢变化维是指在现实世界中，维度的属性并不是静态的，它会随着时间的流逝发生缓慢的变化。 因此，在数据仓库设计中，如何处理维度的变化是一项重要的工作，这也是数据仓库反映历史变化的重要特点之一。根据Kimball提出的维度变化类型，缓慢变化维分为三种类型：
类型1：覆盖型更新，即直接覆盖原来的值，适用于维度属性值的变化对事实表数据分析没有影响的情况；
类型2：保留型更新，即新增一条记录，保留原来的值和新值，适用于维度属性值的变化对事实表数据分析有影响，但需要保留历史数据的情况；
类型3：历史型更新，即新增一条记录，保留原来的值和新值，并将原来的记录失效，适用于需要分析所有伴随着新值或旧值的变化前后记录的事实。
在数据仓库的实际应用中，缓慢变化维的处理方式需要根据具体业务场景进行确定。对于不同的维度变化类型，需要采取相应的设计策略，以保证数据仓库的正确性和可靠性。