clickhouse 作为(OLAP)的列式数据库管理系统(DBMS)是如今数据仓库可以优先考虑的组件
- 高性能
- 分布式
- 列式存储
- 开源
ClickHouse的主要特点是快速、可扩展、低延迟和高并发性能,可以处理PB级别的数据量,并能在秒级别内返回查询结果,易于管理、部署和扩展的特点,可以轻松地在多个节点之间进行水平扩展,以应对不断增长的数据需求。
一.数仓基本架构-本篇重点介绍接入层和明细层
1.数据源
- clickhouse支持数据迁移,不得不提clickhouse的jdbc,通过jdbc可以从其他类型的数据库查询和获取数据,如oracle,mysql,人大金仓,sqlserver都是生产环境下用的比较多的数据库,都可以进行数据迁移到基于clickhouse的数据仓库中,提升性能。
- clickhouse jdbc配置
- 修改config.xml
<jdbc_bridge>
<host>127.0.0.1</host>
<port>9019</port>
</jdbc_bridge>
- jdbc在数据迁移中起到重要作用
- jdbc别名使用:
select * from jdbc('mysql_100','out','test') ;
这里的mysql100即相应的mysql的jdbc url的别名,我通常是使用数据集成工具DBH配置
2.接入层
- 数据迁移的源数据来源与jdbc连接的数据库,数据由源库流入到接入层
- 接入层:数据接入,不承担数据清洗的任务,数据接入层只负责存数据,不管数据是否重复
- 接入层需要设置TTL机制进行数据自动删除防止数据堆积导致服务器磁盘受压
- 可以设置在MergeTree引擎下
create src_data_dis(
id Int,
name String,
cyhash UInt64,
odg_dt DateTime
)
engine=Distributed('集群名','shard_src','shard_src_data','cyhash')
create src_data(
id Int,
name String,
cyhash UInt64,
odg_dt DateTime)
engine=MergeTree
order by id
TTL odg_dt + INTERVAL 1 MONTH
#通过jdbc从mysql数据源拉数到clickhouse数仓中
insert into src.src_data select *,cityHash64(id) as cyhash,now() as odg_dt from jdbc('mysql100','select * from test.jierumysql)
#因为接入层的分布式表src_dates表引擎里设置了sharding_key所以会通过分布式表写进分片表里
这也是clickhouse分布式计算的优势,查询速度分布计算更快
3.明细层
- 明细层是从接入层流入,明细层承担了数据唯一性的功能,需保证数据id唯一,避免id重复导致数据分析数据不准确
insert into shard_detail.shard_detail_data select * from shard_src.shard_src_data where odg_dt=(select max(odg_dt) from shard_src.shard_src_data)
#这里的odg_dt至关重要起到数据更新的作用
- 明细层 数据来源与接入层,为保证数据唯一性,需要实现全量更新和增量更新,这个将在另一篇里做详细介绍
- 明细层数据唯一与源表数据一致,且会通过接入层来和源表里的数据保持一定时间上的一致来满足时间需求
4.实体层
- 实体层是对明细层的数据分析处理,通过调度任务来处理来自明细层的处理后的sql
5.主题层
- 主题层对实体层进行进一步细分,数据通过主题层后就可以进行可视化展示
- 当然可以根据业务需求进一步分层,以获取更细的粒度
6.应用层
- 对主题层的数据进行可视化展示,一般是报表数据展示