当前位置:   article > 正文

实时数仓选型

实时数仓选型

实时数仓选型第一版

实时数仓分层:

计算框架:Flink;存储框架:消息队列(可以实时读取&可以实时写入)
  • 1

ODS:Kafka

使用场景:每过来一条数据,读取到并加工处理
  • 1

DIM: HBase

使用场景:事实表会根据主键获取一行维表数据(1.永久存储、2.根据主键查询)
HBase:海量数据永久存储,根据主键快速查询 √
Redis:用户表数据量大,内存数据库 x
ClickHouse:并发不行,列存 x
ES:默认给所有字段创建索引 x
Mysql本身:压力太大,实在要用就使用从库 (mysql 要主从读写分离)v
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

DWD:Kafka

使用场景:每过来―条数据,读取到并分组累加处理
  • 1

DWS:ClickHouse

Kafka 使用场景:每过来一条数据,实时读取到并重新分组、累加处理(聚合计算)(列存计算)(再次加工数据时,更有优势)
  • 1
为什么不用 kafka flink?
DWS:用户、省份、商品  GMV (商品交易总和)
到
ADS:用户 GMV
        省份 GMV
        商品 GMV
		省份、商品 GMV(重复聚合计算)

用kafak就要用flink计算,每计多算一个指标,就多一个实时任务(耗资源)
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9

ADS:不落盘,不存储。实质上时接口模块,查询ClickHouse的SQL语句(SQL查ClickHouse)

使用场景:读取最终结果直接给大屏,进行数据展示
  • 1

在这里插入图片描述

实时数仓选型第二版

ods:

kafka对应的主题topic_db topic_log
  • 1

dwd:

保持数据流的形式进行下一步的聚合
存储到kafka ->主题名称对应不同的事实表
  • 1
  • 2

dim:

存储维度表等待数据聚合之后来进行维度关联join操作
  • 1
-mysql:快  不适合海量数据的存储
-redis:更快  数据不是永久化存储的
hbase:一般  数据键值对存储   getKey()速度快一些   适合海量的数据     (最合适)
-doris:快   适合海量数据   使用成本较高   尽量不要将原始数据大量存储到doris(现在不需要,适合查询时使用)
-clickHouse: 列式存储   **列式数据聚合操作**(dim维度表里面不会进行列式数据的计算,但dwd dws 会)   速度非常快
  • 1
  • 2
  • 3
  • 4
  • 5
hbase(数据存储 契合后续的数据使用 getKey读取) + redis(旁路缓存 提升速度)
  • 1

dws:

读取dwd数据进行聚合->开窗聚合(10s)再进行维度关联
后续进行灵活的数据接口编写同时能够实现即席查询的功能
doris最适合(之前存储到clickHouse)
  • 1
  • 2
  • 3

ads:

 spring boot编写数据接口读取doris数据
  • 1

在这里插入图片描述

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/Cpp五条/article/detail/477197
推荐阅读
相关标签
  

闽ICP备14008679号