ByteHouse是火山引擎上的一款云原生數據倉庫，為用戶帶來極速分析體驗，能夠支撐實時數據分析和海量數據離線分析。便捷的彈性擴縮容能力，極致分析性能和豐富的企業級特性，助力客戶數字化轉型。

全篇將從兩個版塊講解ByteHouse的技術業務場景及實踐經驗。第一版塊重點介紹ByteHouse于字節內部的業務應用場景，以及使用ClickHouse打造實時數倉的經驗。第二板塊分享字節基于ByteHouse對金融行業實時數倉的現狀的理解與思考。

字節跳動實時數倉經驗

業務和數據之間有著什么樣的關系？

在字節跳動內部，大量的中臺支持著字節不同的業務線及產品。以抖音業務為例，從內容運營的角度，核心邏輯是怎么樣把優質的內容生產出來，準確地分發到不同的用戶并且及時收到反饋，根據反饋再對內容進行調整，從而實現迭代的閉環。從用戶運營的角度，則要考慮的是怎樣去協助客戶進行有效的廣告投放，讓他們能夠精準地觸達到目標用戶。

在這兩個閉環中間，都存在著數據流轉，依賴數據中臺的能力。這就涉及到業務對實時數據的需求，通過對實時數據的處理與分析，運營就能更快地收集和分析內容投放的效果，迭代內容，從而能更精準地觸達到用戶。

以ROI視角思考實時數倉需求

實時數倉是從離線數倉需求演變而來。業務場景對數倉的要求已經升級為對實時數據分析和離線數倉實時性的增強。

在這么多的需求下，中臺團隊要如何評估和量化這些需求，從而實現數倉的優化呢？

我們認為，需求的評估和量化主要分為兩個層面：一是通過實時數倉來衡量產出效果，另一個則是評估投入和產出，從本質上講，這是一個ROI導向的過程。

就產出效果而言，相較于離線數倉，實時數倉具有更好的時效性和準確性。

首先，時效性是指從數據源到數據計算，再到數據的落地可查，整個過程都是完全實時的，并且保證時延最低。當數據落盤后，每條查詢都需要盡可能快速響應。

其次，在準確性方面，無論有多復雜的數據處理鏈路，實時數倉都不會因節點抖動或其他問題而導致數據重復或丟失。

從投入的角度來看，搭建實時數據鏈路后，還需要考慮開發、運維和資源成本。

實時數倉是一個不斷迭代的需求。首先從開發效率來看，最初希望快速構建數據鏈路，但實際項目推進過程中，業務場景需求不斷變化，實時數倉迭代速度比離線數倉更快。因此，需要更快地調整數據和指標口徑；其次，可運維性對實時數據分析非常重要，包括可回溯性、及時監控和快速恢復等能力；最后，需要盡可能提高資源利用率。

選擇ClickHouse的原因

面對實時數倉的要求，ByteHouse選擇了ClickHouse作為實時數倉的載體。

時效性、數據準確、開發運維成本低，這些與ClickHouse的特性高度匹配，這正是ByteHouse團隊選擇ClickHouse的重要原因。

首先，ClickHouse的性能非常強，尤其在單表場景下，它能提供非常快速的查詢性能，這是很多用戶選擇它的原因之一。

其次，ClickHouse可以通過增加機器資源，去提升具體寫入和查詢的性能，基于已有架構，ClickHouse可以實現非常好的非侵入式部署，不管是前面是大數據平臺數據湖，后面是什么樣的BI應用，ClickHouse都可以和上下游去做到無縫的對接和整合。

最后， ClickHouse硬件資源的利用率也比較高，可以用更少的硬件資源來達到一個同類產品的效果。

ClickHouse實時數倉實踐中的一些局限

但ByteHouse團隊在使用ClickHouse的過程中，也發現了一些問題。

第一，寫入方面的能力不夠全面。當數據量非常大的時候，ClickHouse還是會遇到吞吐量的問題。另外，原生的ClickHouse對“只有一次寫入”這類場景的保障是不夠好的。而且原生的ClickHouse很難做到高效的數據更新，但這個能力對于實時數據寫入來說是剛需。

第二，多表場景的性能不夠好。ClickHouse單表查詢性能很快，但是多表場景可能表現的沒有那么好，這個問題跟查詢機制有關，就算通過擴容也很難去解決這個問題。

第三，穩定性有所欠缺。在大規模的使用場景下，比如說要去做節點的重啟，ZooKeeper帶來的穩定性問題。由于可視化管控工具的缺失，所以當用戶要去做一些簡單操作的時候，需要大量的手動執行。

字節ClickHouse的演進歷程

以上問題一定程度上限制了ClickHouse作為實時數倉選型的存儲層的能力要求，所以字節內部對ClickHouse做了進一步的優化演進。

第一個階段，2017年，團隊開始試水ClickHouse來作為OLAP的引擎，初步使用在用戶增長分析的業務場景。提到用戶增長分析，本質上是說在百億、千億甚至萬億的數據量下面，怎么樣去做到快速的分析？經過各種OLAP的選型的比對，最終發現ClickHouse非常適合這種類型的數據分析。

第二個階段，隨著不斷的使用研究和增強，ClickHouse也擴展到越來越多的業務線。在字節內部，有一個叫風神的BI平臺，底層也是使用了ClickHouse，來支持各種各樣的報表。隨著內部的規模擴大，以及對應場景范圍的擴大，其實也帶來了很多的問題，比如ZooKeeper和運維能力的問題，還有怎樣去盡可能的利用不同集群之間的空閑資源的問題，這些都是明顯的短板。

前兩個階段的優化演進主要是修補了ClickHouse的弱點。

第三個階段，把大寬表的引擎擴展到通用引擎。在這個階段，研發團隊增加了非常多的底層優化，添加了數據更新的能力以及自研了優化器，使ClickHouse可以支持更多的分析場景，變成一個更豐富的場景化解決方案。

第四個階段，字節內部的ClickHouse使用量級已經達到18,000臺，最大一個集群也達到了 2400 臺。新的挑戰變成了如何在業務繼續增長、數據分析需求繼續增長的情況下，不去增加更多的資源。針對這個挑戰，研發團隊對多級資源隔離的能力存算分離架構進行了升級。

以上是過去幾年來，ByteHouse對ClickHouse進行優化演進的歷程。

基于ByteHouse的實時數倉方案

通過這些技術的演進，ByteHouse就可以應用到實時數倉的存儲層面。

從上圖來看，各種各樣的數據源都可以通過Kafka或者Flink寫入到ByteHouse里面，然后來對接上層的應用。按照數倉分層角度，Kafka、Flink可以理解為ODS層，那ByteHouse就可以理解為DWD和DWS層。

如果說有聚合或者預計算的場景，也可以通過Projection或者物化視圖去做輕度的聚合，讓一些數據可以更好的向上層提供服務。同時ByteHouse也開發了各種各樣的運維的工具，比如說異常監控的報警、租戶的管理、任務的管理、資源隔離等等。

ByteHouse要做到實時數倉里邊的存儲層，其實離不開剛才說的幾種能力。比如說實時的數據引擎，ByteHouse一方面提升了數據寫入的吞吐量，另外一方面也通過語義的支持，寫入的時候做到不重不漏，這樣可以更加穩定的去消費實時數據。

除了實時數據引擎，ByteHouse新增了數據更新引擎，可以保證在數據落盤的時候做到實時的數據更新，保證整個鏈路的數據時效性。

從查詢性能的角度，ByteHouse自主研發了業界唯一的ClickHouse優化器。通過優化器，可以保證不管是在單表查詢還是多表關聯的場景下，ByteHouse都可以有強悍的性能表現，從而豐富和擴大了ByteHouse的使用場景。

在架構層面，ByteHouse也有存算分離的選擇，在一套產品中可以提供選擇用MPP的引擎還是用原生的引擎，不管用戶的數據規模多大或者多小，都有比較合適的選擇。

ByteHouse的實時數倉方案在內部已經廣泛用于很多場景，比如面向商家、達人等等實時盯盤的場景，用戶會根據實時大屏中的指標，及時的去調整運營策略，或者直播的投放選品策略。

很多場景對指標的聚合度要求高，對時效性、穩定性、數據的一致性要求也比較高，ByteHouse都可以很好的支持和滿足。比如說實時分析能力，ByteHouse可以提供數據集至BI看板，滿足運營更精細化的需求。達到及時的觀察線上指標，驗證特殊場景的效果。除了實時性之外，ByteHouse也提供了靈活的多維分析和監控的能力。

金融行業實時數倉建設思路

在以往，金融行業的數據技術還是基于經典的數據倉庫，而數據倉庫在過去十年也經歷了一些升級。2015年到2017年，數據倉庫從集中式升級到了分布式，增強了可拓展性，隨后再發展至大數據平臺。過去十年，是從無到有的過程，不斷地解決了金融行業一些數據的全量的存儲，包括實時和離線的計算問題。

第二階段，2018年到2021年，批量計算逐漸成熟，金融行業開始有實時計算分析的需求，而這個階段更多的是通過打補丁的方式，把離線和實時分開去計算。

第三階段，從2021年至今，越來越多的金融行業用戶去提出數據湖相關的需求，包括冷數據，非結構化數據的處理和分析……從某種角度來說，數據湖更像是大數據平臺的技術迭代或者升級。

對于實時數倉，在金融行業它更多的像是數據湖和大數據平臺的關系一樣，是某一個細分場景的升級和迭代。比如說在金融行業里，像大數據風控、反欺詐或者說異常的監測場景，這些對于數倉的實時性能力要求更高，倒逼著對數據倉庫做細分能力的增強。本質上來說，金融行業的實時數倉，是對于數倉和大數據能力里的一些實時性能力的抽象結合以及升級。

金融行業實時數倉建設方案

金融行業實時數倉建設方案從落地層面上，有哪些現有方案可以運用和借鑒？

第一種是實時數倉有多種架構，其中Lambda架構是最常見的一種。Lambda架構將數據分為實時數據和離線數據，使用流計算引擎處理實時數據并將計算結果存儲在不同的存儲引擎中，使用批量計算引擎處理離線數據。Lambda架構的優點是能夠保證實時數據提供服務，同時也能快速分析歷史數據。但是Lambda架構的缺點是難以保證離線和實時數據的統一性，需要通過數據清洗來保證一致性。

另一種架構是Kappa架構，它將數據源的數據全部轉化成流式數據，并使用流計算引擎處理。這使得Kappa架構相對簡單，但需要確保所有數據都是實時數據，即使是離線數據也需要轉化為實時數據。如果數據流以流式數據為主，則更適合使用Kappa架構。

數據湖流批一體的架構將批處理和流處理的計算和引擎統一起來，并支持在各個層級進行OLAP實時查詢。但是查詢引擎的性能可能會受到限制，因此不適用于性能要求非常高的場景。數據湖是一個相對完善的實時數倉方案，也能夠支持更大規模和復雜的應用場景。然而，由于數據湖方案的完善度比較高，啟動成本相對較高。如果團隊規模較大，或實時數倉的需求和結構非常復雜，則數據湖方案是較為合適的選擇。

最后，使用MPP作為實時數據存儲層也是一種常見的架構，本質上是Kappa架構的一種變形。通過ByteHouse對ClickHouse能力的升級和數據鏈路的簡化，以及開發效率的提升，MPP儲存方案得到了進一步增強。

那MPP儲存方案的好處是什么呢？在初期，用戶可能對實時數倉的需求沒有那么復雜，或者是大數據研發團隊的規模沒有那么大的時候，如果采用數據湖方案，可能需要投入更多的資源。這個時候，可以先選擇使用ByteHouse的存儲方案來作為實時數倉初步的構建，快速而敏捷的去構建起一套實時數倉的架構。

案例一：實時運營監控場景

接下來簡單介紹ByteHouse幫助金融行業客戶去做實時數倉落地的案例。

第一個案例，ByteHouse幫助一家股份制銀行做實時運營監控的業務場景，通過各種數字化的工具，來促進銀行用戶的增長，實現數字運營的閉環。

實時運營監控有幾個層面的數據分析，比如說一方面去分析用戶的獲取渠道，評估不同的渠道的獲取成本。以及針對不同用戶屬性的ROI表現，可以搭建運營指標的評估體系，設計宏觀的ROI看板，來評估產品的獲客和運營效率的表現，針對用戶觸達的場景進行一些細化。從執行層面來說，可以通過數據的異常來發現線上的問題，或者通過實時數據的復盤，去解決產品和運營項目上線以后的效果。

在技術層面上，其實就需要ByteHouse的一些能力來做支撐，比如說高數據的吞吐和寫入，整個數據可見的超低時延，還有非常快速的數據查詢能力，保證在數據寫入和查詢的服務下面高可用的支持。

火山引擎ByteHouse團隊會分幾期去幫助客戶落地這些需求。比如說客戶總體的目標是希望通過數據看板、大屏、周會周報等一些管理手段，來實現產品運營情況的監控。在第一階段，可能就會上線一些整體的指標呈現能力，從大的方向上去監控一個產品的整體方向。第二個階段，可能會上線產品運營團隊日常關注的可以直接去指導和優化產品運營動作的一個指標。第三個階段，按照客戶個性化需求，上線用戶行為，分析細節指標等細節化模板，有效的幫助運營團隊去細化和增強運營能力。

ByteHouse不管是從寫入的性能，到數據的延遲，開發的周期，以及數據推送的頻率，都能非常好的去滿足運營人員對于數據方面的需求。這個項目上線后，也得到了客戶的非常不錯的反饋和評價。

案例二：實時風控場景

第二個案例，ByteHouse幫助一家銀行的信用卡中心實現實時風控場景。眾所周知，風控對于金融機構來說是非常的重要的。傳統的風控往往是通過一些批任務的處理，從各個系統中抽取風控數據，然后加工成一些風控的指標。這種方式存在一些時間的窗口，比如說按天的或者按小時的，那在時間窗口之內的風控指標可能往往處于一種未加工的狀態，導致一些這種窗口期內的風險指標是無法獲取的。另外，銀保監會的證監會也會不定期的去出臺監管的新規。對于這些新規，銀行或者金融機構需要做到快速的響應。說到底就是需要去修改一些業務的邏輯，自定義風險監控的口徑。

針對上述的這些需求，金融機構可以通過ByteHouse去實時的拉取數據，特別是公共數據，保存入庫后將這些數據流推送到風控的規則引擎。可以在規則引擎中通過編寫 SQL語句，或者編寫各種各樣規則，對于數據進行加工，定義風控規則，從而實現風控規則的快速迭代。同時，也可以結合駕駛艙BI大屏的應用，給管理層提供決策數據依據。

在這個落地案例里面，ByteHouse僅完成第一期上線，目前已經可以覆蓋日均萬筆的風險交易，處理千萬級別的行為數據，在這種數據規模下，ByteHouse也仍然保持了非常優秀的查詢性能。同時，ByteHouse也非常快速的幫助業務人員以及風控人員去整合各種風控數據和計算指標，并且結合已有的規則引擎，去做到優秀的風控管理。

ByteHouse 已經在火山引擎上全面對外服務，并且提供各種版本以滿足不同類型用戶的需求。在ByteHouse 官網上提交試用信息即可免費試用！歡迎大家試用。

另外，也歡迎大家掃描下方二維碼加入 ByteHouse & ClickHouse 交流群，交流關于 ByteHouse 和 ClickHouse 的使用經驗，有問題也可以咨詢群中技術專家。掃碼即可免費試用