大家好,我是考100分的小小码 ,祝大家学习进步,加薪顺利呀。今天说一说大数据-数据仓库_大数据网,希望您对编程的造诣更进一步.
数仓分层
分层 | 全称 | 译名 | 说明 | 压缩 | 列式存储 | 分区 |
---|---|---|---|---|---|---|
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
- 缺点:耦合性高,稳定性低
原文地址:https://www.cnblogs.com/vipsoft/archive/2022/12/07/16932812.html
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
转载请注明出处: https://daima100.com/4453.html