返回首页
最新
嗨，HN！我们是 Ashish 和 Armend，GlassFlow 的创始人。我们刚刚推出了我们的开源流式 ETL，它在将 Kafka 流数据导入 ClickHouse 之前进行去重和合并。<a href="https://github.com/glassflow/clickhouse-etl">https://github.com/glassflow/clickhouse-etl</a>
<p>我们为什么要构建这个工具：
批量数据的去重相对简单。你将数据加载到临时表中，然后通过哈希或键找到记录的最新版本并保留它们。之后，将清理后的数据移动到主表中。但是，你尝试过对流式数据进行这样的操作吗？
我们之前产品的用户正在从 Kafka 到 ClickHouse 运行实时分析管道，并注意到由于重复数据，分析结果是错误的。源系统在从 CRM、商店系统和点击流中获取相似用户数据时产生了重复数据。<p>我们想用现有的 ClickHouse 选项来解决这个问题，但 ClickHouse 的 ReplacingMergeTree 具有不可控的后台合并过程。这意味着新数据已经在系统中，但你永远不知道合并何时完成，在此之前，你的查询会返回不正确的结果。<p>我们考虑使用 FINAL，但对于实时工作负载的速度并不满意。<p>我们尝试过 Flink，但管理 Java Flink 作业的开销太大，自建解决方案会让我们不得不设置和维护状态存储，可能是一个非常大的存储（唯一键的数量），以跟踪我们是否已经遇到过某条记录。如果去重服务失败，你需要在处理新记录之前恢复该状态。这对我们来说维护成本太高。<p>我们决定通过构建一个新产品来解决这个问题，并很高兴与大家分享。<p>关键区别在于，流数据在导入 ClickHouse 之前就已经去重。因此，ClickHouse 始终拥有干净的数据和更少的负载，消除了错误结果的风险。我们希望更多的人能够受益于此，因此决定将其开源（Apache-2.0）。<p>主要组件：<p>- 流式去重：
你定义去重键和时间窗口（最长可达 7 天），它会实时处理检查，以避免在进入 ClickHouse 之前产生重复数据。状态存储是内置的。<p>- 时间流连接：
你可以通过几个配置输入实时连接两个 Kafka 流。你设置连接键，选择时间窗口（最长可达 7 天），就可以了。<p>- 内置 Kafka 源连接器：
无需构建自定义消费者或管理轮询逻辑。只需指向你的 Kafka 集群，它会自动订阅你定义的主题。有效负载默认以 JSON 格式解析，因此你可以立即获得结构化数据。作为底层技术，我们选择了 NATS，以使其轻量且低延迟。<p>- ClickHouse 接收器：
数据通过针对性能优化的原生连接器推送到 ClickHouse。你可以调整批量大小和刷新间隔，以匹配你的吞吐需求。它会自动处理重试，因此在瞬时故障时不会丢失数据。<p>我们非常希望听到你的反馈，并了解你是否用现有工具很好地解决了这个问题。感谢阅读！
我已经将个别的 Substack 内容转化为书籍——真正的平装书和精装书，可以放在书架上——有一段时间了。（请查看主页。）<p>所以当一个朋友向我推荐了一条关于每周将一个人的所有订阅内容转化为书籍的推文时，我觉得这是一个值得尝试的合理想法。我知道从 Substack 到纸质书的过程中有一些潜在的陷阱。<p>欢迎分享反馈和想法。