对话 ClickHouse CTO Alexey：目光不仅限于成为最快的数据库 | 近匠
作为世界上最快的 OLAP 列式数据库之一，ClickHouse 能在毫秒级的时间内处理数百亿行的数据。ClickHouse 公司在官网上，也是简单扼要地介绍了自己的数据库：“Fast”。
ClickHouse 的灵魂人物 Alexey Milovidov，则是一位将“慢”践行到工作之中的人。面对数据库领域日渐增长的需求，他并没有直接参考符合需求的外部产品，而是从头建立一个通用数据库系统，最终成就了 ClickHouse 如今的“快速之道”。
本期《近匠》，我们特邀 CSDN 副总裁邹欣采访 Alexey Milovidov，讲述他“以慢制快”的秘诀。
十五年前，“俄罗斯的谷歌” Yandex 正式推出了网络分析平台 Yandex.Metrica。Metrica 起源于 Yandex 的另一款产品 Direct，是一种帮助广告商统计广告流量的工具。在 Yandex 搜索引擎上安装 Metrica，就能让人了解用户的访问深度、转换率和吸引客户的成本。2008 年，Metrica 脱离了 Direct 成为一项独立的服务，变得和我们熟知的 Google Analytics、Facebook Pixel 与百度统计一样，对所有的网站访客进行分析，让人弄明白网站上都发生了什么。
到了 2009 年，传统关系型数据库占据着市场主导地位，这一年里 Oracle 收购了 Sun、NoSQL 开始崭露头角、SSD 产品走上厂商大战的牌桌、Hadoop 继续流行、“大数据”这个词汇终于进入了互联网领域的流行词典。如果按网站数量或流量数量排名，Metrica 已经成长为世界第二的网络分析系统。
这一年，俄罗斯乃至全世界的网民剧增，Metrica 开始面临数据分析的挑战。Yandex 公司似乎也嗅到了一些趋势，当机立断在这年推出了名为 OLAPServer 的数据库。
想从互联网上收集尽可能多的流量并没有 Yandex 想的那么简单，无数问题接踵而来：数据量是多少？如何处理这些数据如何存储这些数据？如何构建它以允许用户查看灵活、可定制的报告？可以使用 MySQL、Postgres 或 Oracle 来传输这些数据吗？……OLAP Server 做不到的事太多，为了解决这个问题，Yandex 委托了一个人：入职一年的 Metrica 团队工程师，Alexey Milovidov。
整个 Metrica 的开发团队只有五个人，Alexey 便是这五个人的领袖。2008 年，Alexey 在俄罗斯最古老的大学——莫斯科国立大学毕业，刚毕业就加入了 Yandex 公司。没过多久，Alexey 便加入了 Metrica 团队，成为这个世界第二大的网络分析平台的一名工程师。年轻热情的 Alexey 日复一日为公司给出的每个任务提供解决方案，忙碌的他一直没有思考未来计划的习惯。
然而，团队内部很快就面对着一个影响未来项目命运的大问题：是自研，还是购买现成的数据库产品？
在 2009 年，能选择的产品并没有今天这么多，Metrica 团队需要寻找一个方案，能简单地存储具有多个属性的非聚合事件，并在没有预先聚合的情况下即时生成不同的报告。
Alexey 在权衡利弊之下，确定了一个事实：当时现有的解决方案，根本无法彻底满足这个世界第二网络分析平台的庞大要求。“那些拥有冗长开发历史的产品无一不留下了丰厚的知识遗产，这种遗产不仅包括难以改动的大量源代码，还有着固定的组织结构，甚至还会涉及像价格和财务这样麻烦的东西，带来的问题其实不比自己研发产品要少。”
“有时我们不得不冒着风险，变得无知一点，这样才能收获经验。”Alexey 认为，比起购买现成的产品，更多的实践才能更加了解这个领域，否则只会为日后项目的维护增加隐患，“我不喜欢去推理或者猜测技术，如果我对一项技术的工作原理没有直观的认识，我就必须去亲手尝试它，而不是看着文件和报告构思它要怎么运行。”
于是，他选择了另一条布满荆棘的道路：从头建立一个通用数据库系统。
小而紧凑，方能以少胜多
作为组长，Alexey 常需要激励自己的团队：“想超越前人确实很难，但并非没有可能。相信自己的能力，保持决心，努力工作并承担风险，就有可能创造出一个超越现有解决方案的产品。”
在项目初期，Metrica 团队评估了五花八门的数据库系统，寻找最适合 Metrica 的数据结构。在这个过程中，Alexey 开始熟悉列式数据库的概念。列式数据库在 2009 年并不是什么新鲜事，这种数据库结构从 1980 年代就存在，代表的产物有 Sybase IQ 和 Vertica 等等。
Alexey 找到了方向，并自己写了一个原型。他将这个原型命名为 ClickHouse，既 “Clickstream Data Warehouse”（点击流数据仓库）的缩写。
在这个五人团队里，任何新代码乃至任何新提交的东西，都必须先让团队中的所有人看懂。包括 Alexey 自己在内，每个人都需要先读完新提交的代码，并理解其含义。当有人提出了新的技术特性或方案，且这个方案的可行性和可理解性都还没有被证实，那 Alexey 并不会先禁止使用它，而是会建议大家尝试一下，进行试验，并在一段时间后再评估其实用性和可理解性。如果新代码被证明可行且可理解，那么这个方案就会被采纳。
最终，团队成员一致采纳 Alexey 的方案，确认了列式数据库这一大方向，以原型 ClickHouse 为基础，用它来验证从非聚合数据实时生成分析报告究竟是否可行。
Alexey 花了 3 年时间来证明这一假设。2012 年，ClickHouse 正式推出，并立刻开始为它唯一的客户、世界第二大网络分析平台——Metrica 提供支持。以 ClickHouse 起源时期的开发历程为切入点，邹欣提出了他的疑问：
邹欣：ClickHouse 始于五人，那现在的开发团队规模有多大？
Alexey：目前，如果算上我们全部的 C++ 工程师，开发团队就只有 25 人。
当然，我们也有其他部门，比如云基础设施、集成前端还有销售团队等等。
邹欣：你曾经说过“用 C++ 实现的任何东西都会更快”。C++ 是 ClickHouse 成功的关键部分吗？
Alexey：这个结果其实是枚举出来的。比方说，市面上有些数据库是用 Java 和 Go 写的，但它们都不够快，首先被我排除在外。所以就剩下了三个性能不错的选择：Rust、C 或 C++。
C++ 相对于 C 的优势在于可以更有效地组织代码并进行抽象，同时在扩展项目方面也更具有可扩展性，况且在 C 语言中，本身就很难实现零成本的抽象，像哈希表这样的结构在 C++ 中实现也会更容易和安全。
MySQL 最初就是用 C 实现的，但现在主要使用 C++ 实现，而 PostgreSQL 则一直使用 C。
邹欣：像 Excel 这样的经典产品，现今已变得足够好，不再需要更多的功能了。ClickHouse 的产品周期有类似的“开发尽头”吗？
Alexey：不，我觉得开发 ClickHouse 是永无止境的。每当我们实现更多的功能，甚至会导致更多的需求和进一步发展的可能性。
邹欣：但不间断地开发可能会导致“大泥球”架构的诞生（软件结构被添加了太多的层次和组件，导致项目变得混乱、复杂），ClickHouse 要如何避免这种状况以保证项目结构仍然良好？
Alexey：激励人们进行代码重构和删除是防止软件结构衰减的关键。很多时候做加法不如做减法，删除大量的代码比简单地增加有趣的新功能更有价值。ClickHouse 的代码行是相当少的。事实上，ClickHouse 只有不到一百万代码行，而 MySQL 有几百万，我们的结构小而紧凑，以少胜多。
邹欣：如果我是 ClickHouse 开发部的新员工，你会给我哪些建议以熟悉这一百万行代码？
Alexey：我会建议新人首先尝试实现一些小功能，这些功能往往只需要更改少量代码，这样就可以了解代码的构建方式以及修改的位置。我觉得其实不用太过担心自己一开始看不懂代码，因为只要坚持阅读几天，对代码的理解就会逐渐提高，最后奇迹就会出现，让人恍然大悟。
邹欣：通过实践来学习，这是很好的。请问 ClickHouse 的团队里有多少人了解全部的代码？
Alexey：0。就连我也不能完全了解所有代码，但大部分核心成员都懂个 80%，最终整个团队的理解能够叠加起来。所以哪怕代码里出现了一些看不懂的地方，只要不去动它也还是能照常工作。
ClickHouse 的特别之处在于它并不“特别”
在公司内部推广了四年之后，ClickHouse 已然成为核心的 Metrica 后端服务。2016 年 6 月 15 日，Yandex 公司在官方博客上发布了一篇名为 "Yandex's ClickHouse：面向互联网的列式数据库" 的文章，根据 Apache 2.0 许可开源了 ClickHouse。
Alexey 和开发团队将 ClickHouse 代码移至 Yandex 组织下的 Github 存储库，并开始发布社区构建并接受外部贡献。他们同时开始定期聚会以推广 ClickHouse 并围绕它建立社区。第一次 ClickHouse 聚会始于 2016 年的东欧，顺着这股开源浪潮，ClickHouse 在西欧、美国和中国都举行了聚会，在中国的第一次线下见面会便于 2018 年举行，引起了中国开发者的强烈兴趣，现场参与者多达 400 名，并拥有 1000 名在线观众。
邹欣：为什么 ClickHouse 能够从一个内部项目发展成为一个开源项目？它的特别之处在哪？
Alexey：在 ClickHouse 开源之前，它首先在公司内部开始流行。Yandex 是一家大公司，当时大约有一万名员工和数不清的部门系统，而 ClickHouse 起初只是为其中的一个部门专门开发的。后来，ClickHouse 传播到了其他部门那里，得到了热烈反响。这让我意识到 ClickHouse 的潜力绝不止于一个内部项目，它显然有着开源的价值。
ClickHouse 的特别之处恰恰就在于它并不“特别”。它不像其他的数据结构那样专业化、为特定任务而设计，ClickHouse 被设计为一个通用的数据库管理系统，可以处理广泛的数据处理需求。换句话说，ClickHouse 的优势在于它的多功能性和适应不同使用情况的能力。
邹欣：ClickHouse 在开源之后，和以前产生了哪些区别？
Alexey：其实并没有太大的区别，可能我们需要更加认真地对待新增的外部客户，但整个开源的发行流程和发布方案等做法仍然保持不变。
我们现在会根据问题的严重性和影响来确定优先次序，如果出现生产环境崩溃等问题，必须尽快解决，而一些配置等小问题则会被放在低优先级处理。我们会对所有客户都有相同的发布周期，无论是付费还是克隆项目都是按月发布。我们还有一个持续集成系统，每天会运行 2 到 3 百万个测试用例来确保新发布版本的质量。
邹欣：ClickHouse 要开放源代码的时候，都发生过什么有趣的事情呢？比如说，人们是如何发现 ClickHouse 的？
Alexey：有一件有趣的事：在当时俄罗斯本地的许多大会上，就有过其他公司发布的一些专有的列式数据库解决方案，但这些方案都是闭源的，不能共享和发展。所以在我们不久后宣布了一款开源的列式数据库来处理点击流分析时，立刻就取得了轰动。
邹欣：如此看来，在一个完全开放的市场上，产品的竞争非常残酷，质量会直接决定胜负。
邹欣：现在 ClickHouse 还会为所有用户提供培训或聚会吗？
Alexey：很少，最近只办过一两次开发者活动。因为前几年的各种限制，举办类似的活动一直比较困难。
我记得 ClickHouse 办过一次 Hackathon，结果非常成功。我们当时准备了一份很长的清单，要求每个选手都必须在一天内实现上面的一个功能。但是，组织这场活动也耗费了我们不少的精力，因为作为出题者，我们要提前思考这些功能全部的潜在解决方案。
能把项目介绍好的只有开发者自己
2019 年，就像当年 Yandex 的 Metrica 脱胎于 Direct，ClickHouse 也从 Yandex Github 组织下移到一个单独的 ClickHouse 组织，新的变化因此诞生。
2021 年，ClickHouse 公司在特拉华州正式成立，总部设在旧金山湾区。它曾从“Yandex 的内部项目”演变为“Yandex 的开源项目”，最终成为了”ClickHouse 公司的开源项目”。2022 年，ClickHouse 的欧洲办公室在荷兰阿姆斯特丹开业，推出了云服务的早期计划，这也是他们唯一的线下办公室。
ClickHouse 的员工遍布十多个国家，成功跨越了时区差异、语言和文化。这一点引起了邹欣的好奇：Alexey 是怎么带领他的团队做到这点的？
邹欣：ClickHouse 的员工遍布世界十多个国家。你们是怎么进行远程交流的？
Alexey：我们会用 Github——还有 Slack（国外的企业商务社交应用，协同办公主要是通过建立频道进行），不幸的是，我发现使用 Slack 很容易导致工作分心，很多人会在频道聊天上瘾。
邹欣：确实，在分布式团队中，人们往往会混淆生活和工作，比如说有的人就很喜欢在企业频道里讲笑话。原来 ClickHouse 也是这样吗？
Alexey：是的，因为 ClickHouse 的员工遍布各地，大多数人都在远程工作。不过，我们在荷兰阿姆斯特丹设立了办公室，大家会在厨房里聚会，因此荷兰的员工就不需要在 Slack 上把所有事情都说出来，甚至导致外地远程办公的其他同事有时会遗漏一些交流内容。
邹欣：你们是如何解决时区问题的？按理来说，你们会不会一直无法和美国的合作者同时在线？
Alexey：欧洲的同事必须适应美国的时间，美国的同事必须适应欧洲的时间。美国人会在早上 6:00 或 7:00 开始工作，所以欧洲这边就要从下午 4:00 开始工作。最麻烦的情况就是远程开会，有时候可能要开到欧洲的早上 5:00，在这个时间段，来自中国的人（北京时间的中午 12:00 左右）也会开始问我问题。
邹欣：当你像现在一样到访中国接受访谈的时候，公司会有人负责代码审查和决策吗？
Alexey：我们没有特定的人负责这项工作，代码审查任务是分配给团队所有成员的，团队里的每个人都需要进行每周的代码审查。这是为了确保代码的质量和减少错误，同时也是为了培养团队成员之间的合作和相互了解。
我们有一个公司内部每日和每周的发布计划，以确保所有成员都在同一时间完成相关任务，这种方法可以使团队的工作更加高效和流畅。
邹欣：ClickHouse 的工程师要如何在开发工作和社区外展之间分配时间？还是说你们有一个专门的团队来负责这项工作？
Alexey：我们并没有专门的社区外展团队，但我也不打算设立这样的团队，我认为工程师就该亲自出席社区活动，向人们展示自己的成果和计划。
两头兼顾确实不容易，所以我不会让一个没有过任何公开演讲经验的人去参加中国的会议，而是会先让人在欧洲的一些小型活动中尝试演讲，以此来积累经验和信心。我认为，从自己做起，然后逐渐向更广泛的社区推广，这会是一种有效的方式。
邹欣：在现在的开源项目中，你要如何与不同层次的人（核心贡献者和专家、中级爱好者、访问者）打交道？
Alexey：如果我和一个有经验的专业人士交谈，我说话就会更直接一点，比如我会不客气地告诉他“你这个代码行不通”之类的。但是对于没有经验的人，我认为应该尽可能给予帮助和友好。
邹欣：但是，你要怎么分辨一个人是否有水平或者有经验？在网络上的交流往往只能知道对方的用户名，无法知根知底。
Alexey：这很简单，只需要详细看完对方的 pull request 就行。这可以更深入地了解这个人的经验水平，也可以迅速识别出谁是初级贡献者并且提供帮助。
AI 对未来的影响：优胜劣汰
Alexey 曾说过，创建开源项目便是在构建一种无国界的技术——每个人都可以使用的软件，以及无处不在的社区。
时间推进到 2023 年的现在，Alexey 迈着步伐，亲自来到了中国。随着 Alexey 讲述完他在 ClickHouse 的成长故事，邹欣和他共同探讨了全球的 AI 热潮、计算机领域的教育变革和中国程序员行业的独有问题。中俄程序员的价值观碰撞，会产生什么样的火花？
邹欣：未来的程序员在起步阶段就能使用 Copilot 和 ChatGPT，他们还需要学习这些基本编程技能吗？
Alexey：可以不学，但 AI 会让那些学习基础知识的人更有价值。因为当 AI 出错的时候，只有这些人能够找出并修复 AI 的问题。在未来，也许对低质量工程师的需求会减少，但对高质量工程师的需求甚至还会继续增加。
邹欣：那你认为人们还需要在大学课程中学习那些经典的计算机理论吗？
Alexey：也许还是要学，但学习理论并不适合所有人。不要试图让所有的学生都喜欢编程、理解编程，即使在大学的计算机科学系教学，也只用做到“引进门”这一步就行，不要坚持让学生完全理解。
邹欣：开发者社区经常会争论学生的第一门编程语言，有些人会从 C 和 Basic 开始，现在有很多人从 Python 甚至 Java 开始学编程。你对此有什么看法？
Alexey：我的第一门编程语言是 Basic，当时的编程方式还比较古老，需要学习怎么用行号（line numbers）。
我认为，如果要在未来吸引更多的孩子学习编程，那编程方式就应该是易学习的、可视化的，或许可以用电脑游戏那样的媒介，这样才能吸引人学习编程。所以，我觉得学生的第一门编程语言应该是 Python 甚至 Javascript，Javascript 也是最好的语言之一。
邹欣：是的，视觉化/电子游戏化的编程可以让人更有成就感。我认为，主要问题在于现在的编程软件都是由黑色和白色的窗口组成，这很容易让年轻人觉得编程是无聊的，所以未来可能必须像你所说的那样，改变编程软件本身，让编程行为更有趣。
Alexey：没错，我觉得学习任何东西都该从自己感兴趣的东西开始。年轻工程师可以先学习着骇入系统、做点小游戏，做一些低层次的东西，或者探索自己感兴趣的应用程序的底层。这才能让更多的人享受到编程。
邹欣：在中国，每年有 1000 万大学毕业生，其中大概有 10% 是与计算机科学相关的专业，比如计算机科学、软件工程和嵌入式系统等等。所以很多人担心自己只能编程 10-15 年，并在 35 岁左右退休，中国开发者称之为“35 岁现象”。欧洲的程序员是否有类似的担心？
Alexey：如果是一个有独特经验的优秀程序员，那就不用担心，这样的程序员就和那些经验老道的律师或医生一样，总能找到适合自己的路。
邹欣：因此，关键是要真正地发展一个专业领域。但如果一个人的专业领域恰好是像 PHP 编程这样的老技术呢？
Alexey：这也不是什么大问题。举例来说，现在对 COBOL 程序员的需求依旧很高，很多 COBOL 程序员都超过70岁了。
邹欣：你对那些正在学习编程、计算机科学、软件工程的大学生有什么建议？
Alexey：喜欢它，享受它。
邹欣：但有时候兴趣是会变的，很多人进入计算机行业才发现自己并不喜欢“CRUD”，在爱好变成了工作之后失去了兴趣。
Alexey：在未来，AI 会让这个现象变好的。AI 能处理掉这些无聊的部分，然后留下有趣的部分。
我建议不要把所有的精力花在工作上，任何工作都会有无聊的部分。但如果发现自己其实不是厌恶工作，而是真的不喜欢计算机科学工程，那确实可以考虑换个大学或专业了——不要选择美术之类的，因为这些行业也正在被有趣的 AI 取代。
《近匠》是由 CSDN、《新程序员》联合出品的访谈栏目，其意思即为「走近工匠」，真正的“工匠”，豪于技而卓于艺。我们通过走近深耕于技术世界的工具创造者、深邃观察者和技术管理者们，透过他们的思考与实践，剖析整个行业发展现状及未来趋势。
基于此，如果您与团队有报道需求，亦或者如果您有对技术趋势的真知灼见，或是深度的应用实践、场景方案等的新见解，欢迎与我们联系。联系方式：微信（hanbb120，请备注近匠+姓名+公司职位）、邮箱（tumin@csdn.net)。