對話 ClickHouse CTO Alexey:目光不僅限於成為最快的資料庫 | 近匠

作為世界上最快的 OLAP 列式資料庫之一,ClickHouse 能在毫秒級的時間內處理數百億行的資料。ClickHouse 公司在官網上,也是簡單扼要地介紹了自己的資料庫:「Fast」。

ClickHouse 的靈魂人物 Alexey Milovidov,則是一位將「慢」踐行到工作之中的人。面對資料庫領域日漸增長的需求,他並沒有直接參考符合需求的外部產品,而是從頭建立一個通用資料庫系統,最終成就了 ClickHouse 如今的「快速之道」。

本期《近匠》,我們特邀 CSDN 副總裁鄒欣採訪 Alexey Milovidov,講述他「以慢制快」的秘訣。

採訪 | 鄒欣,CSDN 副總裁

作者 | 王啟隆 責編 | 唐小引

出品 | 《新程式設計師》編輯部

編輯部

十五年前,「俄羅斯的Google」 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 的資料庫。

圖 1 Yandex 最初使用的行式資料庫

想從網際網路上收集儘可能多的流量並沒有 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 等等。

圖 2 ClickHouse 使用的列式資料庫

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 名線上觀眾。

圖 3 ClickHouse 社區的聚會

鄒欣:為什麼 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 的歐洲辦公室在荷蘭阿姆斯特丹開業,推出了雲服務的早期計劃,這也是他們唯一的線下辦公室。

圖 4 ClickHouse 公司創始團隊,中間為 Alexey

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 對未來的影響:優勝劣汰

AI 對未來的影響:優勝劣汰

Alexey 曾說過,創建開源項目便是在構建一種無國界的技術——每個人都可以使用的軟體,以及無處不在的社區。

圖 5 在所有公開場合,他都穿著同樣的文化衫

時間推進到 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)。

相關文章

ClickHouse 正在遠離開源?

ClickHouse 正在遠離開源?

【CSDN 編者按】開源產品如何商業化是開源屆老生常談的話題了,本文作者是 ClickHouse 使用者,他覺得,自從 ClickHouse...

不懂技術的 CTO,不是好的 CTO

不懂技術的 CTO,不是好的 CTO

摘要:CTO,程式設計師職業發展的重要方向。不過,想到成為一名好的 CTO,不僅需要有技術前瞻性、優秀的管理能力、敏銳的商業嗅覺,更重要的是...

Hadoop 已死,AI 吞噬世界!

Hadoop 已死,AI 吞噬世界!

【CSDN 編者按】你用上 GPT-4 了嗎? 在資料領域,AI 正逐步重塑資料處理和分析的各個環節,從 ETL、資料治理到資料分析和消費方...

QuickTime 發佈 | 歷史上的今天

QuickTime 發佈 | 歷史上的今天

整理 | 王啟隆 透過「歷史上的今天」,從過去看未來,從現在亦可以改變未來。 今天是 2022 年 12 月 2 日,是我國的交通安全日,交...

中國資料庫的諸神之戰

中國資料庫的諸神之戰

作者 | 唐小引 出品 | 《新程式設計師》編輯部 「現在的資料庫產品實在是太多了!」 前幾天,我和深耕資料庫/大資料近 30 年的盧東明老...