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