clickHouse接入指南和排坑日记
clickHouse分区和分片详解
clickHouse本地表和分布式表
副本的目的主要是保障数据的高可用性,即使一台ClickHouse节点宕机,那么也可以从其他服务器获得相同的数据。
client通过jdbc或者http的方式进行clickhouse-01节点的本地表(写分布式表的时候,数据会进行拆分进而分发到多个本地表)写数据的时候,提交写入日志给zookeeper,clickhouse-02有一个监听器来监听zookeeper接收到日志之后从clickhouse-01中下载数据。
ClickHouse配置zookeeper和多副本参考这个
之前创建分布式表和本地表的时候,我们使用了MergeTree家族引擎,而创建分布式表,只需要在前面加上Replicated就成了支持副本的合并树引擎。
CREATE TABLE IF NOT EXISTS ka_10002538_f83b454416104dbfa083369f35759549.tmc_sms_url_click_local
on cluster clickhouse_csig_smartretail_2_replica
(`kaId` String, `create_time` String,
`os` String, `ipCity` String, `ip` String, `dataType` String,
`receive_time` Int64, `mobile` String, `contentId` String, `ipCountry` String,
`batchId` String, `import_date` String, `path` String, `osVersion` String,
`report_time` Int64, `domain` String, `browserVersion` String,
`browser` String, `customerId` String, `ipProvince` String, `model` String,
`tmcTenantId` String, `timestamp` Float64, `campaign` String,
`campaignName` String) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/ka_10002538_f83b454416104dbfa083369f35759549/tmc_sms_url_click_local', '{replica}') PARTITION BY import_date ORDER BY import_date
基于副本表去创建分布式表和MergeTree一样,如下:
CREATE TABLE IF NOT EXISTS ka_10002538_f83b454416104dbfa083369f35759549.tmc_sms_url_click on cluster
clickhouse_csig_smartretail_2_replica
(`kaId` String, `create_time` String, `os` String, `ipCity` String, `ip` String, `dataType` String, `receive_time` Int64, `mobile` String, `contentId` String, `ipCountry` String, `batchId` String, `import_date` String, `path` String, `osVersion` String, `report_time` Int64, `domain` String, `browserVersion` String, `browser` String, `customerId` String, `ipProvince` String, `model` String, `tmcTenantId` String, `timestamp` Float64, `campaign` String, `campaignName` String)
ENGINE = Distributed('clickhouse_csig_smartretail_2_replica', 'ka_10002538_f83b454416104dbfa083369f35759549', 'tmc_sms_url_click_local', rand())
table_name #表名
├─ partition_minBolckNum_maxBlockNum_level_total #某个分区下的data parts目录
│ │ # 基础文件
│ ├─ checksums.txt BIN #各类文件的尺寸以及尺寸的散列
│ ├─ columns.txt TXT #列信息
│ ├─ count.txt TXT #当前分区目录下数据总行数
│ ├─ primary.idx BIN #稀疏索引文件,常驻内存中
│ ├─ {column}.bin BIN #经压缩的列数据文件,以字段名命名
│ ├─ {column}.mrk BIN #列字段标记文件
│ ├─ {column}.mrk2 BIN #使用自适应索引间隔的标记文件
│ │
│ │ # 分区键文件
│ ├─ partition.dat BIN #当前分区表达式最终值
│ ├─ minmax_{column}.idx BIN #当前分区字段对应原始数据的最值
│ │
│ │ # 跳数索引文件
│ ├─ skp_idx_{column}.idx BIN #跳数索引文件
│ └─ skp_idx_{column}.mrk BIN #跳数索引表及文件
│
└─ partition_minBolckNum_maxBlockNum_level_total #某个分区下的data parts目录
max_compress_block_size
在压缩写入表之前,未压缩数据块的最大大小。 默认情况下,1,048,576(1MiB)。 如果大小减小,则压缩率显着降低,压缩和解压缩速度由于高速缓存局部性而略微增加,并且内存消耗减少。 通常没有任何理由更改此设置。
不要将用于压缩的块(由字节组成的内存块)与用于查询处理的块(表中的一组行)混淆。
min_compress_block_size
为 MergeTree"表。 为了减少处理查询时的延迟,在写入下一个标记时,如果块的大小至少为 ‘min_compress_block_size’. 默认情况下,65,536。
块的实际大小,如果未压缩的数据小于 ‘max_compress_block_size’,是不小于该值且不小于一个标记的数据量。
让我们来看看一个例子。 假设 ‘index_granularity’ 在表创建期间设置为8192。
我们正在编写一个UInt32类型的列(每个值4个字节)。 当写入8192行时,总数将是32KB的数据。 由于min_compress_block_size=65,536,将为每两个标记形成一个压缩块。
我们正在编写一个字符串类型的URL列(每个值的平均大小60字节)。 当写入8192行时,平均数据将略少于500KB。 由于这超过65,536,将为每个标记形成一个压缩块。 在这种情况下,当从单个标记范围内的磁盘读取数据时,额外的数据不会被解压缩。
通常没有任何理由更改此设置。
SELECT partition, name, table, database ,active FROM system.parts WHERE partition = '20211122' and table = 'table_name'
查看;ReplicatedMergeTree 需要依靠 ZooKeeper 的事件监听机制以实现各个副本之间的协同,副本协同的核心流程主要有:INSERT、MERGE、MUTATION 和 ALTER 四种。副本之间依靠 ZooKeeper 同步元数据,保证文件存储格式完全一致,可以理解这种方式是物理一致。同时, 副本间数据的同步,通过监听log目录,从对应有数据的副本拉取data parts到本地。
同分片下不同副本merge流程通过zookeeper来协调,不然各副本并发merge容易乱套,各个分片merge流程一样,互不影响,并行merge