实时数仓选型
- 实时数仓选型第一版
- 实时数仓选型第二版
实时数仓选型第一版
实时数仓分层:
计算框架: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数据