我们想要解决的问题
让我们深入一个现实场景:
设想你负责汇总多个销售点系统产生的大量数据。这些数据需要被实时处理并在高级分析仪表板上展示,以提供全面的洞察。
在数据处理领域,速度至关重要。ClickHouse 作为速度之王,
它从不减速且异常迅速。其在并发处理方面的高效性以及成本效益使其成为构建快速数据洞察的首选。
这就引出了一个简单的解决方案:
对于每个销售点,我们添加一段终端代码,将数据插入到 ClickHouse 中。
💡 简单吗?
是的。
💡 能用吗?
不行。
为何向 ClickHouse 写入数据如此困难
这种简单的解决方案让你踏入了 ClickHouse 的第一个致命误区:这里有一系列的误区。
当你插入数据时经常会遇到这个错误,它会出现在 ClickHouse 的日志中或对 INSERT 请求的响应中。为了理解这个错误,用户需要基本了解 ClickHouse 中“部分”(part)的概念:
我们不必深入技术细节;只需认识到这一点即可。向 ClickHouse 写入数据时,控制速度和并行性至关重要。ClickHouse 喜欢这样的数据摄入过程:
理想情况下,一个主要的数据源可以以任意速度插入所有数据,但需要有控制的平行性和缓冲。这与 ClickHouse 的偏好完美契合。
因此,在实践中,通常会在 ClickHouse 前面引入一个缓冲区:
这时我们就引入了 Kafka,它是数据缓冲解决方案的灯塔。由于 Kafka 无缝地充当缓冲区的能力,它成为了 ClickHouse 强大的最佳拍档。经过迭代后,我们的解决方案如下所示:
我们在销售点系统中加入一些代码来将数据写入 Kafka,然后设置从 Kafka 到 ClickHouse 的传输。在这个流程图中还有一些魔法般的操作,因为从 Kafka 到 ClickHouse 的传输本身就是一项挑战,但我们稍后会详细讨论。
💡 强大吗?
是的。
💡 可扩展吗?
当然。
💡 简单吗?
并不简单。
如何实现 Kafka 与 ClickHouse 之间的数据传输
从 Kafka 向 ClickHouse 传输数据的关键阶段包括读取 Kafka 主题、将数据转换为 ClickHouse 兼容的格式以及将这些格式化的数据写入 ClickHouse 表中。这里的权衡在于决定在何处执行每个阶段。
每个阶段都会消耗一些资源:
读取阶段:这一初始阶段会消耗 CPU 和网络带宽来从 Kafka 主题拉取数据。转换过程:转换数据需要 CPU 和内存使用。这是一个直接的资源利用阶段,计算能力重塑数据以符合 ClickHouse 的规范。写入阶段:最后一步涉及将数据写入 ClickHouse 表中,这也需要 CPU 功率和网络带宽。这是一个常规的过程,确保数据按照分配的资源找到其在 ClickHouse 存储中的位置。
每种集成方法都有其自身的权衡,因此你应该明智选择。
让我们探索实现 Kafka 与 ClickHouse 之间连接的不同选项:
ClickHouse Kafka 引擎
利用 Kafka 内置的 ClickHouse 引擎将数据直接写入 ClickHouse 表中。从高层次来看,它是这样的:
假设我们的销售点终端生成带有新行分隔符的 JSON 数据。
{"user_ts": "SOME_DATE", "id": 123, "message": "SOME_TEXT"}
{"user_ts": "SOME_DATE", "id": 1234, "message": "SOME_TEXT"}
<