ClickHouse 由于其性能方面的突出優(yōu)勢，正在分析型數(shù)據(jù)庫領域掀起一波新的技術浪潮。作為國內(nèi)規(guī)模最大的 ClickHouse 用戶，目前字節(jié)跳動內(nèi)部的 ClickHouse 節(jié)點總數(shù)超過 15000 個，管理總數(shù)據(jù)量超過 600PB，最大的集群規(guī)模在 2400 余個節(jié)點。實際上，字節(jié)跳動廣泛的業(yè)務增長分析很多都建立在 ClickHouse 為基礎的查詢引擎上。
那么，ClickHouse 具體應用于字節(jié)跳動哪些業(yè)務場景？為什么選擇采用 ClickHouse 而不是其他數(shù)據(jù)分析技術？在使用 ClickHouse 的過程中，字節(jié)跳動內(nèi)部團隊又踩過哪些坑？近日，InfoQ 帶著上述問題采訪了字節(jié)跳動數(shù)據(jù)平臺數(shù)據(jù)應用研發(fā)負責人郭東東。
InfoQ：您在奇虎 360 工作的時候也曾負責大數(shù)據(jù)平臺建設，能否基于您自己的感受，談談 360 和字節(jié)兩家企業(yè)建設大數(shù)據(jù)平臺的側重點有哪些不同？（比如場景、需求、技術棧等等）
郭東東：兩家公司的發(fā)展階段，包括本身數(shù)據(jù)的體量都有一些差異，所以這兩個公司可能在建設上有一些比較相通的地方，也有一些差異化。在 360 那時候主要是 Hadoop 生態(tài)剛剛興起，當時更多的工作是把 Hadoop、HBase 等一系列大數(shù)據(jù)技術引入到 360，去解決之前傳統(tǒng)數(shù)據(jù)庫構建、數(shù)據(jù)分析平臺建設這塊的一些瓶頸，當時更多只是把這些平臺作為底座更好地支撐業(yè)務。
來字節(jié)跳動之后，這些開源的生態(tài)已經(jīng)比較成熟了。我們更多是怎樣體系化地建設數(shù)據(jù)平臺，在技術平臺的基礎之上，更多地構建數(shù)據(jù)分析的其他能力。當然，字節(jié)跳動的數(shù)據(jù)量后期增速很大，本身底層分析引擎等方面的挑戰(zhàn)也比較大。
InfoQ：您團隊負責的數(shù)據(jù)應用產(chǎn)品，與前段時間字節(jié)對外開放的火山引擎數(shù)據(jù)中臺產(chǎn)品，二者之間的關系應該怎么理解？
郭東東：我主要負責數(shù)據(jù)應用相關產(chǎn)品，跟火山引擎的數(shù)據(jù)中臺其實是上下游的依賴關系。中臺更多是把數(shù)據(jù)整理好加工好，形成相對規(guī)范的數(shù)據(jù)體系。數(shù)據(jù)應用的話更多考慮的是在數(shù)據(jù)體系上怎樣把更多的數(shù)據(jù)能力賦能給業(yè)務線，比如各種分析能力、AB 實驗能力、行為分析能力和可視化能力等等。二者是一個比較密切的協(xié)同關系。
InfoQ：數(shù)據(jù)應用產(chǎn)品迭代的節(jié)奏和流程是怎樣的？
郭東東：我們基本上采用敏捷開發(fā)，一個迭代周期可能是兩到三周，每個產(chǎn)品會不太一樣，整體來說是小步快跑的節(jié)奏，快速把客戶的需求轉化成產(chǎn)品能力，然后提供給用戶去使用。這里面包括測試環(huán)節(jié)、活動環(huán)節(jié)都需要把控，整個有一套相對完善的需求管理和研發(fā)管控的系統(tǒng)。
InfoQ：能否以一個數(shù)據(jù)應用產(chǎn)品為例，為我們拆解一下背后的整體技術棧和架構是什么樣的？
郭東東：我以 AB 實驗平臺為例，簡單介紹一下我們整體的技術棧和架構。AB 實驗平臺整個產(chǎn)品的技術架構包括指標建設模塊、數(shù)據(jù)分流模塊等，以及底層的查詢引擎能力。指標建設模塊負責數(shù)據(jù)的接入和清洗，包括整個 AB 實驗平臺數(shù)據(jù)體系的建設。數(shù)據(jù)分流模塊模塊主要是根據(jù)不同用戶實時決定用戶屬于的實驗組。最底層的查詢引擎是我們的核心，主要負責保證整個交互式查詢的能力，這里面還有一些增強分析的子模塊等等。整個是以容器化部署的，編程語言的話包括 Python、Go 這些都有用到。
InfoQ：ClickHouse 其實在 16 年就已經(jīng)開源了，但似乎直到去年熱度和關注度才一下子變得特別高，這是為什么呢？
郭東東：其實一個開源技術從開源到逐步成熟、被業(yè)內(nèi)廣泛采用，本來就需要一個過程。另外，如果有一些大公司逐步在使用這個技術的話，也有助于更好地推動這項技術在業(yè)內(nèi)被普遍采用。應該說字節(jié)跳動內(nèi)部的 ClickHouse 應用實踐，對于 ClickHouse 在業(yè)內(nèi)更大范圍的使用也起到比較大的推動作用。很多公司都跟我們交流過 ClickHouse 的使用情況，包括技術改進、技術引進路線等等。
另外，從本質(zhì)上來說 ClickHouse 確實解決了一些特定場景和業(yè)務上存在的比較大的痛點。數(shù)據(jù)分析之前大家更多是困在數(shù)據(jù)量，很少能得到相對明細數(shù)據(jù)的分析，而 ClickHouse 強大的分析能力剛好解決了這一痛點。這其實也反映了大家對數(shù)據(jù)更細粒度的分析需求的持續(xù)拓展。
InfoQ：據(jù)了解，ClickHouse 在字節(jié)應用還比較多。能否基于您負責的團隊和產(chǎn)品，介紹一下 ClickHouse 主要應用于哪些業(yè)務場景？第一個采用 ClickHouse 的業(yè)務場景是什么？
郭東東：ClickHouse 在字節(jié)的應用場景比較多，比如我負責的數(shù)據(jù)應用平臺，基本上很多底層技術都非常多地依賴 ClickHouse 提供的能力，比如 BI 分析能力、AB 實驗的分析能力、行為分析能力等等，包括商業(yè)化層面的廣告效果分析，也都是依賴 ClickHouse 的。
InfoQ：在選用 ClickHouse 之前你們做了哪些技術選型工作？為什么上述業(yè)務場景選擇采用 ClickHouse 而不是其他數(shù)據(jù)分析技術？主要看重 ClickHouse 的哪些特性？相對應可以解決業(yè)務場景中的什么問題？
郭東東：其實在選 ClickHouse 之前，我們也做了比較多的技術選型工作。當時我們有一個相對比較有挑戰(zhàn)的技術場景，是要基于很多明細數(shù)據(jù)做行為分析，這一塊我們研究了挺長時間，當時也試用了 Presto、Kylin 等等各種各樣的分析技術，最后選擇了 ClickHouse。主要是 ClickHouse 在相對固定的一個 Panel 場景下，查詢能力確實有比較明顯的優(yōu)勢，而且本身它是不會損失靈活性的，像 Kylin 的話其實靈活性會比較差，只要做一點修改就需要重刷。
另外我們其實也調(diào)研過 Druid 等，但使用起來跟 ClickHouse 還是有比較大差異的。我們本身選 ClickHouse，還有一個比較大的原因是 ClickHouse 本身 Engine 是相對簡單的，因為它 Engine 的執(zhí)行引擎寫得比較高效，它帶來的向量化執(zhí)行等等這些特性對我們場景化分析的價值還是比較大的。
InfoQ：從最初采用到現(xiàn)在，技術方案迭代過嗎？團隊對基于 ClickHouse 開源版本做了哪些改進和優(yōu)化？
郭東東：ClickHouse 是本身開源版本，我們也會持續(xù)進行迭代和優(yōu)化，還是做了不少工作的。比如說 ClickHouse 的單機用戶規(guī)模原始是受限的，我們做到了大概幾千臺的單機用戶規(guī)模，這里面就做了大量的優(yōu)化。對于它本身查詢能力層面、性能層面，我們也做了比較多的優(yōu)化，包括特殊的像那些比較復雜的路徑轉換等等一系列分析。
另外我們也做了 ClickHouse 的云原生改造，本身它只支持 Local 部署的模式，我們做到了存儲計算分離，就能比較容易地基于容器去調(diào)動算力，這些方面也做了很多事情。另外 ClickHouse 不支持事務、實時寫入能力，包括對 Update 的支持，這塊我們都做了比較多的改進.
我們整體來說還是按照云原生和相對完整的一個數(shù)據(jù)庫去推進這個演進，包括對相對復雜 SQL 能力的支持、優(yōu)化器能力的補足，這塊都有投入。
InfoQ：在使用 ClickHouse 的過程中，你們都遇到過哪些問題？是否有一些解決的經(jīng)驗可以借鑒？
郭東東：我們使用 ClickHouse 算比較早的，中間遇到的問題比較多，踩了不少坑，但是現(xiàn)在來看的話，其實 ClickHouse 本身開源也在逐步成熟，很多問題也在逐步完善。至于有哪些經(jīng)驗可借鑒，我覺得可能有幾個點拿出來跟大家分享一下。首先 ClickHouse 本身運維管控是比較弱的，所以我們內(nèi)部自己搭建了一套相對完善的運維管控系統(tǒng)，以保證 ClickHouse 的穩(wěn)定性，包括故障節(jié)點的停換等等一系列事情。另外 ClickHouse 在對外數(shù)據(jù)攝入這一方面其實也不算特別完善，這塊我們也做了比較多事情，還有包括實時能力等等。
InfoQ：能否談談過去 1-3 年，您對于大數(shù)據(jù)分析技術的觀察？有哪些比較重要的變化和趨勢？
郭東東：過去三年大數(shù)據(jù)分析技術發(fā)展還是挺快的，尤其業(yè)內(nèi)也有比較多的開源技術出現(xiàn)，像 ClickHouse 這樣的技術。另外業(yè)內(nèi)云原生數(shù)據(jù)分析公司（如 Snowflake）的成功，也在大力推動技術的發(fā)展。
回到技術本身，大家其實可以看到越來越多的云原生能力，包括 AI 支持和數(shù)據(jù)分析、數(shù)據(jù)庫和數(shù)據(jù)倉的結合、湖倉一體、批流一體等等，技術一直在持續(xù)推進。未來我認為數(shù)據(jù)分析能力會持續(xù)加強，包括數(shù)據(jù)分析技術的多樣性、整個架構 Layer Out、存儲計算分離等等，都是比較大的發(fā)展趨勢。
InfoQ：基于實時數(shù)據(jù)流的 Kappa 架構現(xiàn)在越來越多企業(yè)開始嘗試。字節(jié)的大數(shù)據(jù)架構中，目前是 Lambda 架構和 Kappa 架構共存嗎？如果是，兩者分別用在哪些場景？如果還只有 Lambda 架構，那為什么還沒有引入 Kappa 架構？
郭東東：目前在我們公司內(nèi)部這兩種架構都是存在的，每一種架構都有不同的使用場景。Lambda 架構本身離線和實時是分開的，在我們內(nèi)部更多用于一些數(shù)據(jù)量比較大且整體有一些比較復雜的策略的場景，比如反作弊等策略，實時很難做得很準確，就需要把離線和實時分開，離線先提供一份數(shù)據(jù)，然后實時進一步修正這個數(shù)據(jù)，保證數(shù)據(jù)是可用的且準確性更高。
但有些場景其實我們也直接采用 Kappa 架構，尤其數(shù)據(jù)湖這些技術在內(nèi)部的廣泛使用，保證了實時的分析能力跟離線也差不了太多，類似這種場景我們就會把實時和離線整合起來，就只用一套，保證實時產(chǎn)出的數(shù)據(jù)就是我們最終需要的數(shù)據(jù)。我們只有在出現(xiàn)比較大的數(shù)據(jù)口徑調(diào)整，或者其他事故的時候，才會跑離線任務去修正，默認的話就是一套。
本文來自微信公眾號 “InfoQ”（ID：infoqchina），作者：蔡芳芳，采訪嘉賓：郭東東 ，36氪經(jīng)授權發(fā)布。
