自序 Foreword

硅谷著名投资人纳瓦尔说过：“真正的知识具有内在的关联性，就像一根链条，从基础层面到应用层面环环相扣。如果有人用词花哨，动辄谈论宏大而复杂的概念，那么他们很有可能并不了解自己所谈论的东西。我认为最聪明的人是可以把事情深入浅出地给孩子讲解清楚的人，否则说明他自己也没有真正理解。”多年的求学经历，让我对这段话深信不疑。

当我开始从事架构师的工作时，我接触到了一些业内的全新技术。我惊讶地发现，对于蓬勃发展的大数据技术来说，如果没有足够的时间积累学习资源，会导致对很多知识的理解只停留在表面，给实际应用带来很多误解。用纳瓦尔的话说，就是没有“从基础层面到应用层面环环相扣”。

绝大多数介绍ClickHouse的文章都在强调其性能很强，是新一代的数仓。各种文档里都对比了ClickHouse与其他数仓的性能差距，似乎它在性能上全面碾压了其他数仓。那么这是否意味着ClickHouse能够完全取代Hive？还有很多文章在强调ClickHouse的实时性，那么是否意味着ClickHouse比Kylin强大？

还有很多文章强调Flink是真正的实时流处理框架，而Spark Stream是通过将批的间隔设置得非常小来使用“微批”模拟实时。从代码层面看，“真正的流”和“微批模拟的流”有什么本质的区别呢？“真正的流”难道不是像“微批模拟的流”那样使用线性表容器存储数据吗？从这个层面看，“真正的流”和“微批模拟的流”并没有本质上的区别，那么又是什么导致了Flink和Spark Stream的区别呢？到底是Flink优秀还是Spark优秀呢？

其实，上面的问题是没有准确答案的。任何架构都是一体两面的，在获得一个优势的同时，必然需要付出一些代价，而这些代价最终会成为这个架构的缺陷。本书旨在通过对ClickHouse架构的分析，引出架构背后的思考，向读者传递架构设计背后的哲学。

脱离实际场景来选型，是无法设计出最合适的架构的。读者需要注意句中的“最合适”一词。没有正确的架构，只有最合适的架构。这个“最合适”，需要架构师依据实际场景进行选择，架构不存在“银弹”。

软件的世界就是这样，没有标准答案。而这也正是这个世界的魅力所在，否则我们只需要准备一个列表，将所有可能的情况和对应的方案列出来就行了。

停止无谓的孰优孰劣的争吵，真正思考架构的本质、软件的本质、技术的本质吧！当我们被架构优秀的一面打动时，要清醒地认识到背后一定有着还没看清的陷阱。运用之妙，存乎一心，当我们看到架构的缺陷时，也要记得在其他场景中也一定有其发光发热的时候。我们不应该被技术名词所束缚，而应该掌控这些技术，让这些技术真正为我们所用。

请读者跟随本书，从ClickHouse开始，拨开技术的重重迷雾，将知识梳理成体系化的链条。当我们能将知识关联起来时，我们看待技术世界的视角一定会有所变化，也不会再停留在孰优孰劣的层面了。那么，您准备好和我一起重新认识这个技术世界了吗？