这篇文章主要介绍了我们一次Spark Job失败的诊断、分析到最后解决问题的过程。虽然出问题的是我们的Spark Job而不是一个通用的基础设施，但是其在分布式环境下收集纷繁复杂的日志、在互为因果的异常信息中梳理线性因果关系，查找日志、分析堆栈、破除矛盾点、总结原因、解决问题的过程是我们解决所有其他问题的基本方法论。

我们通过DROP TABLE .. ON CLUSTER，意外导致ClickHouse集群的Kafka表hang住，并且Kafka表的表级别锁无法释放，所有其他对Kafka表进行的任何操作都无法进行。本文对这个事故进行了描述，同时对我们的整个诊断、分析过程进行了记录，并且提出了解决方案。同时，我们还对ClickHouse + librdkafka的底层代码和原理进行解析。

本文总结一次 ClickHouse 在执行加列的DDL操作后出现的后台合并（merge）持续失败与阻塞问题的排查与修复思路。本文详细记录了我们从发现线上问题，到先行解决线上问题，以及在问题解决以后再次收集现场、猜测和分析原因、添加日志并重现问题、最终定位到根本原因的整个过程。这此事故是由于我们为表添加列、ClickHouse Part中部分列缺失、Merge阶段为缺失列进行默认值补齐、复合列处理过

本文详细介绍了ClickHouse底层的列管理机制，其中大量基于CRTP的实现方式，从中我们可以看到一个追求极致性能的计算和存储引擎都做了哪些优化，其中一些代码和设计精美到让人叹为观止的程度。同时，本文具体介绍了我们在阅读ClickHouse过程中遇到的大量的C++的相关知识，对这些知识的准确理解和掌握是我们准确阅读ClickHouse代码的基础。

我们经常使用ClickHouse的Dist表来实现集群内部的分布式查询。我们的问题是，基于ClickHouse的Shard和Replica概念，在多shard&多Replica环境下，ClickHouse是怎么做到不重复地读取数据的呢？最简单的，对于一个Shard内部的数据，是一个Replica在为它服务，还是所有的Replica都提供数据？本文就带着这个问题，从代码层面探究整个Dist表查询时候

在一个基于Kafka Streaming Ingestion的ClickHouse集群计过程中，我们预想了两种完全不同的集群架构： 横向平铺式以及纵向切分式。本文详细分析了我们在衡量两种不同架构时候的考虑因素，以及，我们最终形成解决方案时做的必要的补充测试和验证，基于我们做的测试和验证，当每一个细节都完全清楚了，我们做出了最终决定。同时，我们还考虑到，基于我们集群架构的方案选择，这种集群以后的扩容

ClickHouse在v25版本下，即使配置多副本，依然无法正确处理单个磁盘损坏的情况。本文记录了我们的运维过程，并以此为出发点，分析了ClickHouse的磁盘和Part损坏的检测机制和恢复逻辑。

这篇文章主要介绍了我们一次Spark Job失败的诊断、分析到最后解决问题的过程。虽然出问题的是我们的Spark Job而不是一个通用的基础设施，但是其在分布式环境下收集纷繁复杂的日志、在互为因果的异常信息中梳理线性因果关系，查找日志、分析堆栈、破除矛盾点、总结原因、解决问题的过程是我们解决所有其他问题的基本方法论。

我们通过DROP TABLE .. ON CLUSTER，意外导致ClickHouse集群的Kafka表hang住，并且Kafka表的表级别锁无法释放，所有其他对Kafka表进行的任何操作都无法进行。本文对这个事故进行了描述，同时对我们的整个诊断、分析过程进行了记录，并且提出了解决方案。同时，我们还对ClickHouse + librdkafka的底层代码和原理进行解析。

我们经常使用ClickHouse的Dist表来实现集群内部的分布式查询。我们的问题是，基于ClickHouse的Shard和Replica概念，在多shard&多Replica环境下，ClickHouse是怎么做到不重复地读取数据的呢？最简单的，对于一个Shard内部的数据，是一个Replica在为它服务，还是所有的Replica都提供数据？本文就带着这个问题，从代码层面探究整个Dist表查询时候