作為一款火山引擎推出的雲原生數據倉庫，ByteHouse基於開源ClickHouse構建，併在位元組跳動內外部場景的檢驗下，對OLAP引擎能力、性能、運維、架構進一步升級。除此之外，ByteHouse也在Serverless方向探索，基於cloud-native 雲原生的理念構建了全新一代的數據倉庫，... ...
更多技術交流、求職機會，歡迎關註位元組跳動數據平臺微信公眾號，回覆【1】進入官方交流群
作為雲計算的下一個迭代，Serverless可以使開發者更專註於構建產品中的應用，而無需考慮底層堆棧問題。伴隨著近年來相關技術成熟度的增加，市場對Serverless的接受程度也變得越來越高。可以說時至今日，Serverless已邁入了向成熟穩定方向發展的高速軌道。
作為一款火山引擎推出的雲原生數據倉庫，ByteHouse基於開源ClickHouse構建，併在位元組跳動內外部場景的檢驗下，對OLAP引擎能力、性能、運維、架構進一步升級。除此之外，ByteHouse也在Serverless方向探索，基於cloud-native 雲原生的理念構建了全新一代的數據倉庫，架構上進行了三層解耦，期望在Serverless的加持下，提供更穩定、可靠、可信的分析服務，讓開發人員時間精力從基礎設施運維優化上解放，更聚焦在核心業務功能中。
本文來自於火山引擎ByteHouse產品負責人李群的分享，從場景選擇、應用門檻、落地應用等5個方面，介紹Serverless在OLAP領域應用思考。
哪些應用場景適合選擇Serverless架構？
在OLAP數據分析領域，我們先看哪些分析模式不適用於Serverless架構：
-
長任務，大Job：如果分析任務需要長時間運行（如超過20分鐘），使用 Serverless 技術會受到限制。因為 Serverless 平臺通常設置了最大運行時間的限制，超過限制時間會導致任務中斷。
-
計算密集型：Serverless 技術通常適用於處理輕量級任務，而對於高計算密集型任務，需要更多計算資源，但行業上目前當前尚未有商用的Serverless 數據倉庫能夠提供超過2000 vcore的算力規模，而2000vcore折算成通用的物理機或裸金屬，也不過是20台伺服器的算力規模，往往一些中型的分析型系統的算力需求就遠遠超過這個規模。
-
高併發讀寫型：Serverless 技術特點是資源共用，對有高併發訴求的分析任務，很可能會出現性能瓶頸，一方面原因是共用資源池的規模上限，一方面是多租戶對共用資源的爭用。
-
負載模式穩定、波動少：Serverless 平臺通常是按需運行，如果需要長時間運行的應用程式，則不適合使用 Serverless 技術。
總之，Serverless 技術適用於處理輕量級、耗時短、低併發型的分析業務，適用於負載模式有明顯波動性特征的業務；也適用於管道型、中間件型的業務，如flink實時計算、kafka消息隊列以及ETL任務執行等。
對於長時間運行、計算密集型、高併發讀寫、需要持續運行的分析業務則不適合使用 Serverless 技術。
應用Serverless技術存在哪些門檻
在OLAP領域，無論是經典的MPP架構向Serverless架構演進路徑，還是基於Cloud-Native雲原生理念全新構建的Serverless架構，都面臨著同樣的技術挑戰：
-
存算分離
把計算和存儲進行解耦，是Serverless架構關鍵的第一步，但其中的技術挑戰非常大，例如：如何保障性能少劣化甚至不下降；近數據計算(NDP)技術，把哪些運算元下推到存儲側；分散式緩存技術如何提高緩存的命中率，這些目的都是儘可能減少計算和存儲之間的網路開銷。
此外，從25GE網路，到RDMA/RoCE等高速網路，再到下一步的記憶體型網路的融合，如何減少延遲、提高吞吐也是業界在持續解決網路通信層面的難點之一。
-
計算無狀態
計算側通常還是採用經典的shared-nothing架構，具備良好的水平伸縮擴展性，但是計算側的無狀態化程度直接關係到彈性能力的優劣，這其中元數據的管理和同步、統計信息的自動化、優化器的智能化都是關鍵的技術難點。
形象一點描述，則是，在彈性過程中，背負東西越多，狀態化越重，彈性效率就越低，用戶體驗越差。
-
全局資源調度
存儲資源池化、計算池化、網路池化，未來還會實現記憶體池化等，而且理想的 Serverless 架構需要能夠自動地根據用戶請求的負載進行智能的動態伸縮，在不需要時自動釋放資源，業務浪涌時自動分配更多資源。以上對全局的資源調度能力提出了更高的要求。
-
混合負載
在Serverless架構下，不同的租戶在同一個計算資源池裡提交各種類型的分析任務，如何給上層應用提供穩定可靠的SLA保障，混合負載管理的難度被進一步放大。
基於靜態化的配額負載策略很難在Serverless的多租戶模式下落地，需要逾越智能、動態的資源分配、限流、熔斷等負載管理的技術難點。
如，“低效SQL耗盡資源”的老大難問題的影響半徑在Serverless模式下會被放大，甚至是災難性影響。
-
資源池上限
Serverless模式下，多租戶都在共用一個資源池，理想上這個資源池應該可以無限擴展，但當前只有存儲側基本上做到這一點，計算側資源池還是受限於軟體能力會有一個天花板上限，比如說目前幾款主流雲廠商的Serverless的數據倉庫還沒有超過2000vcpu的算力規模。如果再疊加多租戶併發的因素，將導致當前的Serverless架構在OLAP分析領域還比較難以大規模推廣使用。
此外，旨在進一步降低計算側負載而引入新硬體並提供池化服務，比如FPGA資源池，也是當前雲場景的發力方向。圍繞Serverless架構下的全場景多層級的數據安全也是要考慮的關鍵問題。
這裡簡單給大家分享一下ByteHouse在這方面的一些思考和實踐：
ByteHouse 基於cloud-native 雲原生的理念構建了全新一代的數據倉庫，架構上進行了三層解耦。由下向上看，
-
在存儲層，ByteHouse 已經實現了Serverless化、彈性伸縮、容量無限擴展。為提升存算分離架構下的性能問題，在存儲側做了一系列的技術優化，比如
針對HDFS語義，合併小文件減少文件數、改進的Hedge Read、Fast Switch Read等使得帶寬僅增加10%的情況下，延遲減少3倍；
針對S3語義，通過memory cache、獨立IO線程池等技術提升數據的存取性能。
-
在網路通信上， 連接復用、RDMA、傳輸壓縮等技術，大幅緩解了網路放大問題。
-
在中間的計算層，ByteHouse是通過virtual warehouse為用戶提供彈性的計算服務，提供pay as you go的記賬模式，為用戶節省成本。
在技術上，ByteHouse實現了無狀態化，基於容器化部署、秒級彈性伸縮、秒級按需啟停。ByteHouse增強的本地緩存技術，使得數據預熱、預取更加智能高效，緩存數據的命中率也更高。
在計算層，ByteHouse通過不同的VW來做負載隔離，如按讀寫進行隔離、按應用類別進行隔離，這種tenent-aware 租戶感知的負載隔離模式雖然還不是Serverless模式，但是能在一定程度上滿足用戶的需求，也是向Serverless架構演進的路徑之一。
-
在最上層的cloud services 雲服務層，ByteHouse提供集中化的catalog 元數據服務、集群管理服務等。我們把元數據從計算層解耦出來，讓計算層實現了無狀態化，獲得了秒級的彈性伸縮和啟停能力。基於分散式 KV 的元數據存儲，通過高效的part緩存技術，也進一步提升了元數據的訪問性能。
如何看待可觀測性和Serverless哲學相悖的問題？
隨著Serverless的深入，人們發現Serverless架構下的問題定位比傳統應用更困難。對此，一部分人認為應該支持可觀測性的需求，另一部分人則認為可觀測性與Serverless本質相悖，Serverless就是為了讓用戶不需要關心底層計算資源情況。
我認為，這個問題本質上是跟當前Serverless技術成熟度相關。舉個例子，現在我們每天都在用水、用電，但是很少有人會再去關註怎麼發電、如何配送，飲用水的處理環節等等，因為我們得到的用水、用電的服務標準是穩定的、可信的和可靠的，所以不再關註過程細節。
與此類似，Serverless 要實現的目標就是提供穩定、可靠和可信的分析服務，讓開發人員不再把時間和精力花費在下層的基礎設施和運維優化上，而是聚焦在業務功能的實現上面。
但是當前OLAP 數據分析領域的Serverless技術成熟度還遠未達到這個目標，前面提到的一系列技術難點尚未完全解決，最簡單的例子是如何解決困擾業界40多年的“低效SQL耗盡資源”的老大難問題，在 Serverless 模式下，賬單跟資源用量緊密相關，賬單上資源用量的合理性、可信性是客戶當前的最大疑慮。
此外，通過日誌記錄、 跟蹤監控、可視化指標等技術工具為用戶提供過程中的可觀測性，也是Serverless平臺應該具備的能力，也能夠增加用戶對系統的信任感。
因此，兩者並非相悖。我們相信會有一天Serverless會給用戶帶來標準、穩定、可靠、可信的分析服務，就像我們今天用水、用電一樣。
落地Serverless，自研和雲廠商方案如何選擇？
21世紀最寶貴的還是人才。對企業來說，每一筆投入的目標都是圍繞著如何去獲取更深入本質的分析洞察、更靈敏的風控感知和預警、更快速的用戶增長，所以說，企業的IT更多的是站在開發的視角去看待投入決策，使能業務，並能更近一步，讓IT從傳統的成本中心向賦能中心、盈利中心去演進，人才儲備的重點是技術開發方向。
而雲廠商的商業邏輯是為用戶提供標準的雲計算技術服務，通過持續、高強度的研發投入，為用戶提供差異化的雲服務，人才儲備的重點是技術研發方向。開發和研發，僅一字之差，但含義迥異。
特別是對於OLAP 領域的Serverless技術實現來說，涉及到存儲、網路、操作系統、資料庫、AI等IT領域幾乎全棧的技術點，更需要廠商做持續的、高成本的研發投入，而且這些投入短期內難見市場回報，一旦中途停頓則意味著前期的投入全都“打水漂”。
所以，對中小企業來說，還是建議在OLAP 領域的Serverless技術投入上保持慎重態度，對Serverless的技術研發、演進迭代還是交給技術人才儲備更雄厚、技術投入也更專業的大型雲廠商來做。
Serverless距離大規模應用還有多遠？
在OLAP數據分析領域，雖然已經有幾款商用的Serverless架構的數據倉庫，但是前面提到的技術難點依然存在、尚未逾越，並且期提供的算力規模也很難支撐中大型規模的數據倉庫或者分析平臺的需求。
但是，Serverless的架構理念還是面向未來的，而且技術挑戰也會隨著時間的推移會有更好的應對方案和措施，並且當前也能夠在部分中小型分析負載場景中適用和推廣。
最後想提一點，影響Serverless大規模應用的因素，除了技術層面持續演進和迭代之外，另外一個非常關鍵的就是Serverless服務的標準化，尤其是對OLAP 分析領域。Serverless的初衷是讓用戶聚焦在業務實現上，但沒有一個標準化的規範會導致用戶被平臺鎖定，無法實現應用的平移、無縫搬遷，比如，用戶無法把基於MySQL的應用無縫搬遷到PostgreSQL，因為下麵的資料庫是Serverless了，但是與業務邏輯進行交互的介面還沒有標準化。因此，Serverless的規模化應用，還需要有與之配套的標準和規範體系。
總而言之，Serverless架構已經越來越受到歡迎，隨著雲計算和Serverless技術的進一步發展和完善，Serverless架構將在未來成為更多大規模應用的首選架構之一，用戶會像今天用水、用電一樣，方便、快捷地享用Serverless化的OLAP 數據分析服務。
點擊跳轉ByteHouse瞭解更多
