数仓分层
| 分层 | 全称 | 译名 | 说明 | 压缩 | 列式存储 | 分区 |
|---|---|---|---|---|---|---|
| ODS | Operation Data Store | 原始层 | 原始数据 | ✅ | ❌ | ✅ |
| DIM | Dimension | 维度层 | 合并维度表 | ✅ | ✅ | ✅ |
| DWD | Data Warehouse Detail | 明细层 | 数据处理、维度建模 | ✅ | ✅ | ✅ |
| DWS | Data Warehouse Service | 服务层 | 去主键聚合，得到原子指标 | ✅ | ✅ | ✅ |
| DWT | Data Warehouse Topic | 主题层 | 存放主题对象的累积行为 | ✅ | ✅ | ✅ |
| ADS | Application Data Store | 应用层 | 具体业务指标 | ❌ | ❌ | ❌ |
- ODS：原始数据，日志和业务数据 放到 Kafka
- DWD：根据数据对象为单位进行分流，比如订单、页面访问等等
- DIM：维度数据
- DWM：对于部分数据对象进行进一步加工，比如独立访问、跳出行为，也可以和维度进行关联，形成宽表，依旧是明细数据。
- DWS：根据某个主题将多个事实数据轻度聚合，形成主题宽表。
- ADS：把ClickHouse中的数据根据可视化需进行筛选聚合
命名规范
库名：业务大类
表名：分层名_业务细类
临时表：temp_表名
备份表：bak_表名
视图：view_表名（场景：不共享的维度表、即席查询）
| 分层 | 命名规范 | 说明 | 例 |
|---|---|---|---|
| ODS | ods+源类型+源表名+full/i | full：全量同步 i：增量同步 |
ods_postgresql_sku_full ods_mysql_order_detail_i ods_frontend_log |
| DIM | dim+维度+full/zip | full：全量表 zip：拉链表 日期维度表没有后缀 |
dim_sku_full dim_user_zip dim_date |
| DWD | dwd+事实+full/i | full：全量事实 i：增量事实 |
|
| DWS | dws+原子指标 | 时间粒度有1d、1h… 1d：按1天 1h：按1小时 |
dws_page_visitor_1d |
| DWT | dwt_消费者画像 | ||
| ADS | ads+衍生指标/派生指标 |
离线数仓：事实表，维度表，都放Hive
实时数仓：原始数据放 Kafka，维度数据 放 HBase，Phoenix
-
离线计算：就是在计算开始前已知所有输入数据，输入数据不会产生变化，一般计算量级较大，计算时间也较长。例如今天早上一点，把昨天累积的日志，计算出所需结果。最经典的就是 Hadoop 的 MapReduce 方式；
一般是根据前一日的数据生成报表，虽然统计指标、报表繁多，但是对时效性不敏感。从技术操作的角度，这部分属于批处理的操作。即根据确定范围的数据一次性计算。 -
实时计算：输入数据是可以以序列化的方式一个个输入并进行处理的，也就是说在开始的时候并不需要知道所有的输入数据。与离线计算相比，运行时间短，计算量级相对较小。强调计算过程的时间要短，即所查当下给出结果。
主要侧重于对当日数据的实时监控，通常业务逻辑相对离线需求简单一下，统计指标也少一些，但是更注重数据的时效性，以及用户的交互性。从技术操作的角度，这部分属于流处理的操作。根据数据源源不断地到达进行实时的运算。 -
即席查询： 需求的临时性，小李，把两星期的数据拉给我看下（只在这个时刻需要）
Presto: 当场计算（基于内存速度快）
Kylin:预计算（提前算好），多维分析（Hive With Cube)
Sqoop 导入数据方式:
-
增量： where 1=1、
-
全量： where 创建时间=当天、
-
新增及变化：where 创建时间=当天 or 操作时间=当天、
-
特殊（只导入一次）
Flume: -
tailDirSource
优点：断点续传，监控多目录多文件
缺点：当文件更名之后，重新读取该文件造成数据重复
注意：1. 要使用不更名的打印日志框架（logback)--一般logback 也会设置成更名的，每天一个日志文件，文件名带上日期，如果写死文件名，更名后可能会丢数据
2.修改源码，让TailDirSource判断文件时，只看 iNode 值 -
KafkaChannel
优点：将数据导入Kafka，省了一层Sink
Kafka：生产者、消费者
用法：1. Source-KafkaChannel-Sink
2. Source-KafkaChannel
3. KafkaChannel-Sink
逻辑线： 数据流、监控、优化、配置。
Kafka
- Producer:ACK、拦截器、序列化器、分区器、发送流程、事务、幂等性，分区规则-->有指定分区发到指定分区，没有根据Key进行hash,都没有进行轮询（粘性）
- Broker: Topic 副本-> 高可用 ISR LEO、HW ；分区：高并发、负载均衡（防止热点）
- Consumer：分区分配规则 offset 保存（默认：_consumer_offsets 主题、其它：手动维护Offerset(MySQL)带事务，精准一次消费
分层的好处
- 复杂问题拆解为多层
- 减少重复开发（可以去中间层取数，不用每次都去原始层）
- 隔离原始数据，例如：异常数据、敏感数据（用户电话…）
数据存储策略
- 原始层保持数据原貌，不进行脱敏和清洗
- 创建分区表（例如：日期分区），防止全表扫描
- 数据压缩，减少磁盘占用（如：LZO、gzip、snappy）
- 列式存储提高查询效率（如：Parquet、ORC）
离线架构：追求系统的稳定性、考虑到公司未来的发展，数据量一定会变得很大、早期的时间实时业务使用 SparkStreaming(微批次)
- 优点：耦合性低、稳定性高
- 缺点：时效性差
实时架构：Kafka集群高可用，数据量小，所有机器存在同一个机房，传输没有问题，
- 优点：时效性好 Flink
- 缺点：耦合性高，稳定性低
