实时数仓选型
- 实时数仓选型第一版
- 实时数仓选型第二版
实时数仓选型第一版
实时数仓分层:
计算框架:Flink;存储框架:消息队列(可以实时读取&可以实时写入)
ODS:Kafka
使用场景:每过来一条数据,读取到并加工处理
DIM: HBase
使用场景:事实表会根据主键获取一行维表数据(1.永久存储、2.根据主键查询)
HBase:海量数据永久存储,根据主键快速查询 √
Redis:用户表数据量大,内存数据库 x
ClickHouse:并发不行,列存 x
ES:默认给所有字段创建索引 x
Mysql本身:压力太大,实在要用就使用从库 （mysql 要主从读写分离）v
DWD:Kafka
使用场景:每过来―条数据,读取到并分组累加处理
DWS:ClickHouse
Kafka 使用场景:每过来一条数据,实时读取到并重新分组、累加处理（聚合计算）（列存计算）（再次加工数据时，更有优势）
为什么不用 kafka flink？
DWS:用户、省份、商品 GMV （商品交易总和）
到
ADS:用户 GMV省份 GMV商品 GMV省份、商品 GMV（重复聚合计算）用kafak就要用flink计算，每计多算一个指标，就多一个实时任务（耗资源）
ADS:不落盘，不存储。实质上时接口模块，查询ClickHouse的SQL语句（SQL查ClickHouse）
使用场景:读取最终结果直接给大屏，进行数据展示
实时数仓选型第二版
ods:
kafka对应的主题topic_db topic_log
dwd:
保持数据流的形式进行下一步的聚合
存储到kafka ->主题名称对应不同的事实表
dim:
存储维度表等待数据聚合之后来进行维度关联join操作
-mysql:快 不适合海量数据的存储
-redis:更快 数据不是永久化存储的
hbase:一般 数据键值对存储 getKey()速度快一些 适合海量的数据 （最合适）
-doris:快 适合海量数据 使用成本较高 尽量不要将原始数据大量存储到doris（现在不需要，适合查询时使用）
-clickHouse: 列式存储 **列式数据聚合操作**（dim维度表里面不会进行列式数据的计算，但dwd dws 会） 速度非常快
hbase（数据存储 契合后续的数据使用 getKey读取） + redis（旁路缓存 提升速度）
dws:
读取dwd数据进行聚合->开窗聚合(10s)再进行维度关联
后续进行灵活的数据接口编写同时能够实现即席查询的功能
doris最适合(之前存储到clickHouse)
ads:
spring boot编写数据接口读取doris数据
