ClickHouse：在分布式和复制表中使用 hash 和 internal_replication答案

【问题标题】：ClickHouse: Usage of hash and internal_replication in Distributed & Replicated tablesClickHouse：在分布式和复制表中使用 hash 和 internal_replication
【发布时间】：2020-09-13 09:50:53
【问题描述】：

我在Distributed Engine 文档中阅读了有关 internal_replication 设置的内容。

如果此参数设置为“true”，则写入操作会选择第一个健康的副本并向其写入数据。如果分布式表“查看”复制表，请使用此替代方法。换句话说，如果要写入数据的表要自己复制它们。

如果设置为“false”（默认值），则将数据写入所有副本。本质上，这意味着分布式表自己复制数据。这比使用复制表更糟糕，因为没有检查副本的一致性，并且随着时间的推移它们会包含稍微不同的数据。

我正在使用典型 KafkaEngine 和 Materialized View(MV) 设置，以及使用 Distributed 表。我有一组实例，其中有 ReplicatedReplacingMergeTree 和 Distributed 表，如下所示：


CREATE TABLE IF NOT EXISTS pageviews_kafka (
// .. fields
) ENGINE = Kafka
SETTINGS
  kafka_broker_list = '%%BROKER_LIST%%',
  kafka_topic_list = 'pageviews',
  kafka_group_name = 'clickhouse-%%DATABASE%%-pageviews',
  kafka_format = 'JSONEachRow',
  kafka_row_delimiter = '\n';

CREATE TABLE IF NOT EXISTS pageviews (
   // fields
) ENGINE ReplicatedReplacingMergeTree('/clickhouse/tables/{shard}/%%DATABASE%%/pageviews', '{replica}', processingTimestampNs)
PARTITION BY toYYYYMM(dateTime)
ORDER BY (clientId, toDate(dateTime), userId, pageviewId);

CREATE TABLE IF NOT EXISTS pageviews_d AS pageviews ENGINE = Distributed('my-cluster', %%DATABASE%%, pageviews, sipHash64(toString(pageviewId)));

CREATE MATERIALIZED VIEW IF NOT EXISTS pageviews_mv TO pageviews_d AS
SELECT
 // fields 
FROM pageviews_kafka;

问题：

我在分布式表中使用默认值internal_replication，这是错误的。这是否意味着分布式表正在将 all 数据写入 all 副本？那么，如果我将internal_replication 设置为 true，那么 ReplicatedReplacingMergeTree 的每个实例将只拥有整个表的份额，而不是整个数据集，从而优化数据存储？如果是这样，复制也会受到影响——如何定义一定数量的副本？
我使用实体的 id 作为分布散列。我在 Altinity 的 ClickHouse Kafka Engine FAQ 中阅读了问题“Q. How can I use a Kafka engine table in a cluster?”，如下：

另一种可能性是将数据从 Kafka 引擎表刷新到分布式表中。但是，它需要更仔细的配置。特别是分布式表需要有一些分片键（不是随机散列）。这是为了使 ReplicatedMergeTree 的重复数据删除正常工作所必需的。分布式表将重试同一块的插入，并且可以通过 ClickHouse 进行重复数据删除。

但是，我在这里使用了半随机哈希（它是实体 ID，其想法是同一实体实例的不同副本 - 在本示例中为综合浏览量 - 被组合在一起）。它的实际问题是什么？为什么不鼓励？

【问题讨论】：

标签： apache-kafka clickhouse

【解决方案1】：

我在分布式表中使用了 internal_replication 的默认值，它是 false。

你不应该。一定是真的。你很幸运，由于插入重复数据删除，数据还没有被复制。但最终它将被复制，因为您的分布式表将 2 个相同的插入到 2 个副本中，并且复制的表将插入的数据复制到另一个副本（在您的情况下，第二个副本跳过了分布式的插入，因为您很幸运）。

那么 ReplicatedReplacingMergeTree 的每个实例将只有它在整个表中的份额

你错了。

分布式 (internal_replication=true) 插入到所有 SHARDS。

分布式 (internal_replication=false) 插入到 ALL SHARDS + 到 ALL REPLICAS。

需要更仔细的配置我在这里使用半随机哈希

它需要更仔细的配置，你做到了！！！，使用 -- sipHash64(toString(pageviewId))

您稳定了顺序，如果重复插入，则相同的行会转到相同的分片，因为行的分片编号是使用 pageviewId 而不是 rand() 计算的。

【讨论】：