“規模尺度每增大十倍，很多架構設計點都需要再重新調整”。
面對個性化、多樣化資料，以及企業內部的資料孤島和業務孤島，如果有一套能夠處理海量資料的基礎設施，那麼在很大程度上可以挖掘並分析出對業務發展有價值的資訊，從而幫助企業更快地作出資料驅動的決策，更快地推出適應使用者/客戶需求的產品。
位元組跳動資料平臺團隊根據業務的需要，用七年時間研發並逐漸迭代出了一套資料平臺，該平臺管理的總資料量在幾年前就已經超過了 EB 級別，在業務日常晚高峰時承載的埋點流量就已超過 1 億 TPS，有超十萬 core 的單任務需要上千臺機器來計算。
這樣的規模在業界也十分罕見，為了應對大規模的資料量，位元組跳動資料平臺團隊沒有采用傳統的資料中臺模式，而採用了“中臺+BP 制”模式，避免中臺脫離業務需求。BP 機制是一種創新，類似於 HRBP，統一管理調配各個業務中的任務。相對於“純中臺制”，資料 BP 制的好處是更緊貼業務支援，規避了中臺容易脫離業務需求、造輪子自嗨的風險。相對於“純 BU 制”，最大的好處則是槓桿率高，平臺是容易賦能的。
在策劃 2022 年 3 月 24-25 日北京 ArchSummit 全球架構師峰會之初，我採訪了位元組跳動資料平臺負責人羅旋，請他來講講位元組跳動資料平臺建設的歷程和技術細節。羅旋在 2014 年加入位元組跳動，從零開始組建大資料平臺，帶領團隊搭建了包括資料採集、建設、治理、應用的全鏈路平臺產品。倡導用資料驅動業務，以資料 BP 模式，敏捷支援了今日頭條、抖音、西瓜影片、朝夕光年等各大業務線。在大資料的架構、產品、治理、安全隱私、組織設計等方面有豐富實踐積累。以下是羅旋的回覆內容。
Q：作為位元組跳動資料平臺的負責人，能否請您回顧一下，資料平臺是如何建設的？又經歷了怎樣的演進過程？每次升級改造的背景是怎樣？
羅旋：位元組跳動資料平臺的建設過程可能跟其他公司不大一樣。我們所有的建設和演進邏輯，都是圍繞如何能敏捷高效支援業務，促進增長這個目的。所以你會發現，從平臺演進歷史中能夠看出，我們的最佳化前提背景，都是業務高速發展下，我們需要用什麼樣的能力，來支撐和驅動持續增長。
自 2014 年至今，大致分為以下幾個階段：
- 原始階段：Hive+郵件報表，重度使用 A/B 測試（2014）
我是 2014 年加入位元組的，只敘述 14 年之後的發展情況。在此之前，也只有過一兩工程師，兼職參與過相關事情，所以基本還是個從零開始的狀態。剛加入位元組時，只有一個 Hive 和最基礎的報表，僅包括 DAU、時長等，報表僅以郵件形式來發送，是非常原始的一個狀態。不過很有意思的是，在這個時候，我們已經開始重度使用 A/B 測試了，這是我們最早相對成熟的一個系統，相信跟絕大多數公司的發展順序都不同，因為在那個階段，我們認為最重要的事，就是讓業務能夠量化度量，並以非常快速試錯的方式來迭代。
- 基礎能力建設時期：自建產品快速取代商業化產品
在 2015-2016 年間，業務快速發展，需要有更多報表、指標，和更靈活的分析能力。2015 年今日頭條的日活已經過千萬了，資料量增大，對引擎的處理能力提出了更高要求，也開始考慮時效性，互動性等問題，此時我們採用 Spark 和 Storm 來進行資料處理。
到了 2017 年，以抖音為代表的業務資料量膨脹，不斷挑戰我們的能力邊界。成長太快帶來的問題很明顯，一方面是經常出現資源到位的速度慢於業務增長，缺機器、機架位甚至機房。我們很多時候對資料鏈路各環節進行最佳化處理，不只是因為成本，更多時候是因為資源不夠，導致我們必須要做。透過最佳化來解決資料量和分析效率，成為我們首要突破重點，做了很多選型嘗試，如 Presto、Kylin、Druid 和 ClickHouse，也基於這些開源引擎，做了大量二次開發和深度最佳化。這部分的投入，到今天也還在繼續，也讓我們在部分引擎如 ClickHouse 的積累上，相對領先業界。
除了引擎技術之外，我們也開始建立面向業務的資料產品。包括現在已經對外部企業提供服務的 Finder（火山引擎增長分析），也是在當年取代了商業版的 Amplitude，開始覆蓋公司全部業務線。我們當時做過一版測算，按全產品線計算，每年可以給公司節省數億的開銷，如果按現在的資料體量，就要更多得多了。同時期開始投入的，也包括資料開發平臺、元資料管理、任務依賴排程等核心平臺能力。
公司的業務形態在這個時期，也開始變得豐富，有了抖音、火山小影片、西瓜等等，也就開始產生了中臺化訴求。
- 產品化和組織成型：架構組織創新，平臺能力持續升級
到了 2018、2019 年，位元組新業務的產生速度，又明顯加快了。作為一箇中臺團隊，如何快速高效的支援這些不斷產生的、型別又越來越多樣化的業務，成為一個很重要的命題。
我們在組織層面做了一些創新，設定了資料 BP 機制。BP 全稱是 Business Partner，類似於 HRBP，組織形式上是集中式的，可以統一管理調配，執行上分散式到各個業務，解決業務問題。這種組織方式的優勢在於，儘管 BP 團隊向上支撐了不同型別的業務線，但其實向下相容了我們平臺底層的各項能力，具備相似的技能棧，對工具引擎的學習和使用是高效且順滑的。
作為資料平臺能力的解決方案提供方，資料 BP 同學在組織上都彙報在資料平臺，統一培養和排程，相互學習經驗的角度，對中臺能力也保證足夠的熟悉度，以便根據不同業務的特性，靈活組合，提供綜合性的資料解決方案，也保證了複用性，不輕易重複造輪子。在具體工作時，他們會撲在不同的業務線上，跟業務同學坐在一起，把自己視為業務線的一部分，保障與業務一起成功。
資料產品層面，我們開始越來越注重“產品化”，注重體驗和降低門檻，而不僅僅是基礎能力，這樣才能讓公司內更廣泛的角色群體，都能用資料驅動的理念工作。我們的 ABI 產品“風神”就是這個時候推出的，這也成了位元組幾乎全員使用的一款資料產品。內部流傳的“A/B 是一種信仰，風神是一種習慣”，也是從這個時期開始廣為人知。
- ToB 服務階段：“0987”量化資料服務標準，面向外部企業創造價值
2020 年時，我們已經有兩大塊服務物件了。一個是對位元組跳動的各業務線，以資料 BP 為介面，提供資料服務；另一個是面向外部企業，為外部客戶創造價值。
在位元組跳動內部，當支援了越來越多產品線之後，我們針對資料 BP 這種模式，提出了一個更量化的服務體系標準，叫做“0987”。這四個數字分別指的是：穩定性 SLA 核心指標要達到 0 個事故，需求滿足率要達到 90%，數倉構建覆蓋 80%的分析需求，同時使用者滿意度達到 70%。服務位元組內部業務，我們是按照這個高標準來要求自己，同時這也是一種自監管的機制，能夠有效的防止自嗨，脫離業務需求和價值。
在外部客戶方面，我們其實從 2019 年就開始探索 ToB 市場。到了 2020 年，ToB 升級成了位元組跳動公司的戰略，公司註冊成立了“北京火山引擎科技有限公司”。火山引擎是位元組跳動旗下的企業級技術服務平臺，資料平臺也作為其中重要的大資料板塊，持續加大投入。我們將內部支援服務比較好的產品和經驗，封裝成資料套件，透過火山引擎對外提供服務。目前，我們已經推出了技術引擎和營銷增長兩大套件，也有了一些不錯的標杆客戶。同時我們也在思考資料 BP 的解決方案能力、經驗和方法論，是否能幫助到外部客戶，讓他們也享受到和抖音一樣的資料服務級別，開始在這方面做一些嘗試。
Q：正如您剛剛所提，平臺架構並不是一開始就確定的。我們知道，架構持續升級的過程很少能一帆風順，位元組資料平臺在架構演進的過程中有沒有走過一些彎路？能否舉個例子？
羅旋：也不算彎路吧，而是在技術演進的路上，需要解決什麼樣的核心問題，隨著問題的變化，解法很可能也會改變。經歷過架構演進升級的人都會知道，規模尺度每增大十倍，很多架構設計點都需要調整。另外由於是給飛奔的火車換輪子，有時也需要在資源、ROI 上做一些權衡。舉個例子，我們的使用者行為分析產品 Finder 所使用的底層查詢引擎，就經歷過比較大的調整。
在一開始探索的時候，我們在 2016 年底做了技術選型，考慮了查詢速度和效能、穩定性等因素，我們認為 Kylin 更符合那個時候的需求。它的優點是“快”，能達到毫秒級別，但是資料需要預聚合，且計算量大，維度和度量也都需要提前定義。當時我們採取了一些方法，暫時緩解了這些問題。但隨著產品功能擴充套件到留存和轉化分析，這套架構就難以做到互動式響應了。
為了提供更多靈活性，我們又快速用 Spark 做了一些嘗試，保留原始資料、做字典編碼、按使用者 ID 分片、分層快取等等。但考慮到業務發展速度需要追求對資源和效能都更極致的方案，透過一系列的測試驗證之後，我們選擇了 ClickHouse 來作為基礎的查詢引擎。ClickHouse 當時還遠不如現在流行，但我們認為它在類似場景的效能最佳化上做得比較極致，功能精簡的同時實現質量高，是一個非常好的基礎。在滿足實際業務場景的過程中，我們也做了大量的深度最佳化和定製修改。目前我們擁有國內最大的 ClickHouse 叢集，節點總數超過 15000 個、管理資料量超過 600PB、最大單叢集規模在 2400 餘個節點，每天支撐著數萬員工的互動式資料分析。
今年，我們也推出了企業版的 ClickHouse，叫 ByteHouse，除自研表引擎、擴充套件資料型別、冷熱資料分離等核心能力升級之外，資料實時寫入能力相較原生 ClickHouse 也提升了兩倍以上。
Q：這個架構目前支撐了多大量級的資料規模？大規模處理遇到了哪些挑戰？又是如何解決的？
羅旋：資料平臺管理的總資料量，幾年前就已經超過 EB 級別了，從實時流量的角度，我們在業務日常晚高峰時承載的埋點流量就已超過 1 億 TPS，有超十萬 core 的單任務需要上千臺機器來計算。這樣的規模在業界也十分罕見，自然的會帶來效能、擴充套件性、實時性等方面的挑戰，前面提到的查詢引擎的一些最佳化，也是由此引發的。再疊加上業務的多樣性和複雜度，又會在大規模任務的排程、運維、資源最佳化、資料治理等維度上，碰到不少挑戰。
舉個例子，目前我們日均的資料處理作業量在百萬級。從任務排程的角度，依賴關係複雜、層次也比較深，為了滿足時效性要求，需要在前置依賴就緒的情況下快速觸發排程執行。我們透過自研的分散式排程系統，實現了秒級排程能力。同時提供了任務的分級打標機制，結合 SLA 簽署系統，透過多種任務資源控制方式，實現資源最合理的調配，結合優先順序權重來保證 SLA 滿足率。也可以根據任務的歷史情況，對不合理的任務配置，提出配置最佳化的告警建議，不然大任務量的運維也很容易成為災難。
Q：除了規模和效能之外，如何做好資料管理也是另一個不得不正視的問題。尤其是像位元組這樣業務豐富，資料型別不斷擴大的企業，是如何去解決這個問題？
羅旋：我們更習慣叫資料治理，意思類似。當資料體量，多樣化程度都很高的時候，這確實是一件特別重要的事情。
整體來說，資料治理是個長期過程，我們自己的實踐分為兩個階段：
第一個階段，針對我們的主營業務，成立了資料治理委員會，以民主集中的方式，做專項的診斷和治理，拿到標杆效果。同時，把在這個過程中形成的最佳治理實踐，轉化成可複用的架構、流程、產品，來降低治理門檻，以尋求可複製性。
第二個階段，把第一階段沉澱下來的中臺治理能力，源源不斷地賦能給創新業務，實現業務的分散式自治，使其不必都依賴特定團隊。這個過程中，也會不斷有新的需求反饋，讓我們對治理產品持續打磨。
這套機制現在已經執行得比較穩定，幫助我們實現了比較高的資料治理標準，也達到了更大程度的成本資源節約。由於經歷過多種不同型別業務的考驗，因此也能保證治理產品和方法論的泛化能力。我們儘量用產品化的方式來降低門檻，讓支援不同業務的資料團隊能夠自治，可以說我們是用一種更敏捷的方式實現資料治理。作為對比，一些公司的做法可能更類似於“一把手工程”，更依賴全程頂層決策推動，一方面這跟公司的文化相關，另外一方面我們也倡導資料平民化的理念，把產品工具做得足夠好，讓門檻儘可能低。
Q：您多次提到敏捷，這是位元組資料平臺的特性嗎？體現在哪些方面？
羅旋：首先位元組本身就是個比較敏捷的公司。這對於位元組資料平臺來說，也算是一個特性，我們追求的是敏捷高效支援業務增長。從幾個方面可以體現：
- 組織敏捷：相對於“傳統”中臺模式，我們的 BP 模式創新，能更高效支援業務。
- 消費敏捷：透過不斷升級最佳化技術引擎，PB 級複雜分析需求可實現秒級響應，資料從產生到可用也能達到秒級，讓業務在資料消費環節看數、用數更快。
- 決策敏捷：這是位元組典型的 A/B 測試文化，“遇事不決用 A/B”，用客觀代替主觀，輔助一線快速決策，而不是依靠冗長的層層拍板的辦法。這也使得我們的 A/B 產品每天同時進行的測試就達上萬場。
- 服務敏捷：位元組的業務發展太快，業務模型非常多元化，促使我們必須快速接入和服務好一個新的業務。服務與工具產品深度融合，在高滿意度為要求的前提下，我們快速支援一個業務，一般一週時間就可以接起，開始提供基礎能力。
- 實施敏捷：這從剛剛提到的分散式資料治理中可見一斑。我們倡導小團隊也可快速實施，無需花費大量時間建設配套組織和制度，對業務影響小，適配性強，見效快。
- 迭代敏捷：位元組的發展和變化非常之快，對我們的挑戰就是要快速迭代以適應各種變化，這也使得我們整體迭代更敏捷。從產品的發展也能看出來，2016 年底我們的行為分析產品還在迭代技術選型，2017 年就能覆蓋內部需求替代較成熟的商業化產品了。
Q：敏捷的其中一個體現是組織敏捷，這和其他的資料平臺十分不一樣，您能再深入介紹下資料 BP 的模式嗎？
羅旋：BP 模式的概念我在上面的問題裡已經詳述了。相對於“純中臺制”，資料 BP 制的好處是更緊貼業務支援，我們會坐在業務身邊提供服務，並主動要求考核業務對自己的滿意度，規避了中臺容易脫離業務需求、造輪子自嗨的風險。相對於“純 BU 制”，最大的好處則是槓桿率高，平臺是容易賦能的。資料 BP 的同學並不是自己在戰鬥，他背後有很強大的團隊，有很強的平臺產品工具支援。業務發展曲線陡峭，或戰略優先順序變化時，資料 BP 的同學能非常快地協調資源。BP 積累的業務支援經驗，也更容易進行跨產品線的交流沉澱，最終體現在平臺產品和方法論的積累上。
推行資料 BP 制的出發點，一方面是當業務體量越來越大，僅用通用的平臺產品技術支援已經不能夠滿足需求了，需要再深入結合業務特性，提供綜合性的解決方案和實施落地的能力；另一方面也是希望在純中臺化和純業務閉環之間取長補短，在追求複用的同時，最大程度的提升組織效率。從我們幾年下來的實踐效果看，還是非常好的，雖然還是會有問題出現，但各業務方基本都是認可的。最近我們發現幾十個業務的整體 NPS 已經達到了 70，無論是從公司內還是從業界來看，都算是一個比較高的值。
Q：上面提到了很多能力特性，能否再總結介紹一下目前位元組跳動資料平臺的架構？
羅旋：從比較粗的粒度看，資料平臺可以分成兩大塊，一塊是平臺能力層，另一塊是解決方案層。
平臺能力層主要是我們的通用產品技術能力部分，包括：
- 資料引擎部分，有位元組大規模使用的湖倉一體引擎 LAS 和 OLAP 引擎 ByteHouse。其中 ByteHouse 是我們今年 8 月剛對外推出的，效能和規模在國內都比較領先；
- 資料建設部分，主要是 DateLeap，融合了資料的定義、採集、驗證、分流、治理等一站式資料開發治理平臺；
- 資料應用部分主要分為：
- 面向通用分析需要的產品：ABI（敏捷 BI 產品，內部叫風神）、Finder（行為洞察分析產品，內部名叫 TEA）、Gaia（一款用於資料門戶建設的產品，業務可以自助模組化建設門戶）、CDP（使用者資料平臺，內部叫 Mirror，沉澱了各種分析標籤）、Tester（A/B 實驗平臺，內部叫 Libra）
- 面向不同業務場景提供的洞察型產品，如熱點寶（內部叫 Pugna，用於不同業務的場景洞察，如抖音熱點榜單等）、管理駕駛艙（用於業務管理層監測各種核心指標）以及安全合規的產品等。
解決方案層，就是我們的資料 BP 模式。一方面資料 BP 團隊，依靠我們的平臺能力對不同的業務提供資料解決方案；另一方面，資料 BP 團隊也能從業務中獲取到更多發展訴求，進而使得我們的平臺能力不斷迭代並得以最佳化。
Q：剛剛講了很多技術的挑戰和發展。技術與業務其實是休慼相關，互相促進的。想請您從資料角度來看，你們在賦能業務上，是否遇到過一些極端挑戰？可否舉個例子說明？
羅旋：當然，技術最終要透過業務來發揮價值，也只有複雜的業務場景，才會帶來足夠的技術挑戰。
舉一個特殊的場景吧。2021 年抖音春晚活動中，流量洪峰達到日常的數倍，在這個場景下，我們需要提供各種實時指標資料，既要用於內部指導活動策略的實時更新，比如下個時段紅包投放量的預算決策，也要給外部，比如把實時的春晚戰報資料給到春晚現場和各媒體。這在實時性、穩定性、指標精確度、架構容錯能力都有非常高的要求，而整個春晚專案從立項到上線只有 27 天，也增加了額外的難度和壓力。
首先，在流量採集側，我們有個很好的基礎，位元組所有流量資料的採集管控，都是在統一的流量平臺上。針對春晚紅包專案，我們又額外增強了容災能力，做了三機房容災預案，並支援一鍵容災。針對尖峰流量，我們跟相關團隊合作，支援了服務端限流和客戶端迴避重試策略。為了在不同負載下靈活降級，也支援了埋點抽樣和主動降級機制。
然後，在實時指標方面，我們也已經沉澱出了一套比較成熟的，以 Flink 實時計算引擎與 ByteHouse、LAS 等分析引擎相結合的實時數倉解決方案。針對春晚活動的實時決策和戰報需求，我們使用了兩套不同的技術架構，一套是基於 Flink 的計算架構，流式計算出最終指標，另外一套基於 ByteHouse 的儲存架構，在儲存層實時寫入明細資料，查詢時聚合出最終指標。同時兩種架構也都做了雙機房雙鏈路冗餘災備。
最後，在離線場景下，也需要我們有強大的分級保障和資料治理能力。在業務峰值期，我們需要出讓大量的離線資源給線上業務系統，同時又要保障離線資料倉庫仍然能按時產出，產品和分析師才能對前一天的活動情況做細緻的覆盤，來指導下一步動作。這就要求能在幾十萬張資料表，百萬資料處理任務中，靈活的分級調配資源、降級和快速恢復，我們也確實做到了這一點，相關能力都沉澱在 DataLeap 產品中。
Q：位元組在資料應用上有很多自研的產品，但在大資料基礎架構上的自研方向是怎麼考慮的？
羅旋：從演進路徑看，基本是三個階段：1. 使用開源；2. 基於開源二次開發；3. 自研。
最開始追求解決業務問題，開源社群提供了很多不錯的基礎方案，比如 SparkSQL、ClickHouse、Airflow 等等，我們會先嚐試直接使用，也就是階段 1。在使用的過程中，隨著業務複雜度的增加，會在可擴充套件性、易用性、垂直定製最佳化等方向遇到瓶頸，此時我們會做一輪技術判斷，如果開源社群在核心部分、中長期跟我們預期一致，會走階段 2，例如 SparkSQL、ClickHouse 等。否則會直接走階段 3，例如資料任務的排程系統等。而一些系統，開源社群本來也沒有好的選擇，我們就會從一開始直接走階段 3，比如 A/B Test 系統。走 2 的系統改動太多，逐漸積累下來，有時也會趨近於 3。
從現狀來看，我們是一個 2+3 的混合狀態。在過程中，我們也向開源社群反饋了一些具體的改動。目前也在考慮把一些比較成熟的自研系統整體開源出來，回饋更廣泛的開發者。內部在積極的討論中，可以期待一下。
Q：未來在 ToB 的規劃，以及與位元組內部技術演進的協同方式是怎樣的？
羅旋：大的思路上，我們堅持內外部統一，用同一套產品技術體系來服務公司內外各業務。這樣有幾個好處，一是吃自己的狗糧，用內部的大體量和多元化場景來打磨產品技術，給外部客戶提供更成熟的產品，也是幫助了位元組跳動內部成功的產品和技術。
二是服務內部時，視野更寬廣長期，更有外部視角。比如，在早期就去考慮外部市場對這一技術的需求有多大，如果僅僅是個定製化的小場景，那就小投入加外部採購來解決；如果有廣泛需求，那就大投入，做到業界領先。
三是從成本效率來說也需要做到更優，能夠複用資源和經驗。從具體執行路徑來說，產品在使用過程中會存在一些版本差異，但更多是由於場景不同，發展階段不同導致的，核心並不是從內部和外部客戶來區分，例如不同規模大小的業務帶來的技術形態區別，操作易用性和功能複雜度的權衡等等，有點類似於很多軟體的 Pro 和 Lite 版的感覺。
Q：最後想了解您目前都關注哪些技術方向？未來的大資料開發者們應該具備哪些能力？
羅旋：我目前主要關注的大資料技術方向包括：實時化、智慧化以及安全隱私合規。其中，實時化關注的是實時數倉、流批一體等技術；智慧化主要圍繞智慧物化檢視、結合機器學習的查詢最佳化器、增強分析智慧問答等；在隱私合規上更關注政策趨勢帶來技術和架構演進趨勢，包括敏感資料發現、多方計算、資料本地化、許可權最佳化等。
對於關心未來發展的大資料開發者來說，我覺得首先需要有過硬的計算機基礎技術儲備，這是通用的能力。具體到大資料領域技術，一個特點是開源元件種類特別多，大資料開發者應該熟悉瞭解這些開源元件的特性，這也是很好的學習過程；另一個特點是，一定要找到真正有大資料規模的場景和環境來實踐學習，因為它跟小資料場景技術是完全不同的、有本質區別的。小資料場景下也體現不出挑戰性。在這個基礎上，再去關注一些前沿的方向發展。
