实时数仓选型

实时数仓选型第一版

实时数仓分层:

计算框架: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数据