簡介： 資料匯流排作為大資料架構下的流量中樞，在不同的大資料元件之間承載著資料橋樑的作用。透過資料匯流排，可以實時接入來自伺服器、K8s、APP、Web、IoT/移動端等產生的各類異構資料，進行統一資料管理，進而實現與下游系統的解耦；之後可以非同步實現資料清洗、資料分發、實時計算、離線計算等計算過程，進而將結構化後的資料投遞到下游的分析、歸檔系統，進而達到構建清晰的資料流的目的。廣義上，資料採集與接入、傳輸鏈路、儲存佇列、消費計算、投遞等都屬於資料匯流排的範疇，整體上可以分為採集接入層、管道層、計算層。
本文為阿里雲SLS徐可甲在 GIAC 2022 全球互聯架構大會 上海站分享時的議題內容。
雲原生場景下資料匯流排需求場景及挑戰
資料匯流排簡介
資料匯流排作為大資料架構下的流量中樞，在不同的大資料元件之間承載著資料橋樑的作用。透過資料匯流排，可以實時接入來自伺服器、K8s、APP、Web、IoT/移動端等產生的各類異構資料，進行統一資料管理，進而實現與下游系統的解耦；之後可以非同步實現資料清洗、資料分發、實時計算、離線計算等計算過程，進而將結構化後的資料投遞到下游的分析、歸檔系統，進而達到構建清晰的資料流的目的。廣義上，資料採集與接入、傳輸鏈路、儲存佇列、消費計算、投遞等都屬於資料匯流排的範疇，整體上可以分為採集接入層、管道層、計算層。
透過資料匯流排，可以輕鬆達到如下目的：
解耦生產者與消費者：消費方完全可以不用感知寫入方的任何細節，降低系統對接複雜性，提升系統可靠性。
應對流量洪峰，使資料的生產非同步於資料的消費，消峰填谷。
定義統一格式與操作語義：接入多種異構資料，透過資料處理構建統一的格式。
舉一個簡單的例子，在計算廣告檢索系統中，廣告的點展資料至關重要。一份點展資料往往會被多方訂閱消費，且應用場景各異，有精度到秒級的實時計算業務，也有類似於Hadoop的小時級或天級的批處理任務。如果資料直接對接，就需要考慮各種異常場景，會讓系統變得極其複雜。而透過資料匯流排，可以大大降低系統複雜度，提高系統可靠性，這樣可以保證任意一個數據訂閱系統即使經歷了下線維護或者宕機，也可以在重新上線後從之前的斷點處繼續進行資料處理。
雲原生場景下的技術挑戰
面對每天幾百億次讀寫、近百PB資料流量、萬級使用者的場景時，構建高可用的資料匯流排將會是一件非常有挑戰的事情。這裡簡單列舉一些場景的流量場景：
生產者：因業務促銷等活動，流量在幾分鐘內上漲至原先十幾倍或幾百倍；
消費者：對一種資料同時有幾十個訂閱者來同時消費；
每天有幾百個異構資料來源接入，方式各不相同，需要大量適配。
經過幾十年的飛速發展，整個開發模式、系統架構、部署模式、基礎設施等也都經過了幾次顛覆性的變革，這些變革帶來了更快的開發和部署效率。但隨之而來整個的系統與網路環境也更加的複雜、部署模式和執行環境也更加動態和不確定、接入的資料來源與資料量大幅增加、流量波動等不確定因素變大、接入難度與原始結構差異化變大，這些都是雲原生時代也給資料匯流排帶來的新的要求。
總結下來，雲原生時代資料匯流排的技術挑戰可以從採集接入層、管道層、計算層三方面展開。採集接入層重點關注資料來源的接入豐富度、接入易用性、資源開銷與資料採集可靠性；管道層重點關注網路質量、頻寬與水平擴充套件能力、安全與隔離性、生態豐富度等；計算層重點關注及計算語法能力、流量處理頻寬與擴充套件性等。
開源方案的選擇與對比
目前行業上主流的大資料架構，大概可以分為5個部分，其中前3部分構成了資料匯流排。
採集端：承載可觀測資料採集及一部分前置的資料處理功能。隨著雲原生的發展，採集端也需要適應時代潮流，提供對
K8s
採集的友好支援。常見的採集端有
Filebeat
、
FluentD/Fluent-bIt、Telegraf
，以及我們開源的
iLogtail
。
訊息佇列：採集
Agent
往往不會直接將採集到的資料傳送到儲存系統，而是寫入訊息佇列，起到削峰填谷的作用，避免流量洪峰導致儲存系統宕機。常見訊息佇列為
Kafka
、
RabbitMQ
等。
計算：用於消費訊息佇列中的資料，經過處理、聚合後輸出到儲存系統。比較常見的為Flink、Logstash等。值得注意的是，也開始有公司將iLogtail開源版作為計算層部署在日誌架構中。
儲存分析引擎：提供採集資料持久化儲存能力，並提供查詢分析能力。常見的儲存分析引擎為
Elasticsearch
、
ClickHouse
、
Loki以及時序的Prometheus、influxdb等
。
視覺化：藉助
Kibana
和
Grafana
提供採集資料的視覺化能力。
使用者可以利用上述的採集端、訊息佇列、計算三部分提供的開源元件搭建出一套資料匯流排。雖然基於開源元件搭建資料匯流排技術上時可行的，但是整體實施複雜度很高，需要維護多套系統進行協同。此外，也無法完全滿足雲原生上文提到的雲原生場景下面臨的技術挑戰，例如網路質量與地域規劃就是一道比較難以逾越的鴻溝。
資料匯流排整體架構
可觀測平臺不僅需要解決好資料如何獲取、查詢的問題，也應該提供具體業務場景的應用能力，幫助客戶從碎片化、低資訊的資料中挖掘更大的資料價值。一個典型的雲原生可觀測平臺從下至上可以分為四個層面：資料匯流排、儲存分析、工具、應用。其中，資料匯流排是整個可觀測平臺的資料基礎，為資料分析及上層業務應用提供資料保障。正因為資料匯流排足夠基礎，所以在企業數字化過程中必須足夠可靠、穩定、確保資料的通暢，並且能夠彈性滿足流量變化需求。接下來，我們將重點分享阿里雲SLS資料匯流排的架構與實踐。
在本文第一部分，我們介紹到一個典型的資料匯流排可以分為採集接入層、管道層、計算層三個層次，對應的SLS的資料匯流排的架構也可以類似劃分。
採集接入層：承載了資料匯流排所有資料（支援Log、Metric、Trace、Event等）的接入，並且與阿里雲服務有深度的整合。接入手段以SDK/API為基礎，擴充套件了端上可觀測採集器 iLogtail、資料匯入服務、開源標準協議等多種接入方式。
管道層：以 LogHub 作為資料匯流排的核心流量中樞，功能可以完全替代 Kafka。透過 Restful API 對外提供接入服務，透過消費組的方式提供實時消費服務。
計算層：作為 LogHub 的下游服務，基於實時消費組，提供了各類資料處理及投遞服務；並且生態上支援主流開源流計算對接。
以上，我們對SLS資料匯流排有了一個整體的認識，接下來我們將從資料接入、流量中樞、資料處理三個維度進行詳細介紹。
資料接入技術架構與實踐
資料接入能力概覽
LogHub 作為資料匯流排的核心流量中樞，預設提供 HTTP/HTTPS 協議的 API 寫入能力，同時，也提供了眾多語言的 SDK，用以簡化接入場景、增強可靠性，SDK 覆蓋從Java、Go、C++等服務端應用，到Android、IOS等移動端場景，甚至 JavaScript 等前端場景。
自研的開源可觀測資料採集器 iLogtail承載了伺服器場景、容器場景的可觀測資料採集能力，覆蓋Windows、Linux作業系統及X86、ARM架構。藉助於阿里雲的優勢，無縫支援阿里雲上各類主流雲服務的日誌、指標、安全審計類資料的採集。
對於通用協議等支援也比較豐富，相容 Syslog，Kafka、Promethous、JDBC、OpenTelemertry 等開源協議；支援眾多開源採集工具，例如 Logstash、Fluentd、Telegraf 等。
Producer Library
針對Java、Go等大資料、高併發場景下，我們在SDK基礎上提供了Java Producer、Go Producer；針對IoT/嵌入式裝置，推出了C Producer。
使用 Producer 相對於直接透過 API 或 SDK 傳送資料，提供了更上層的封裝，效能、可靠性都有大幅提升。
執行緒安全：Producer 內所有的方法以及暴露的介面都是執行緒安全的。
非同步傳送：客戶端計算與 I/O 邏輯分離。呼叫 Producer 的傳送介面通常能夠立即返回，Producer 內部會快取併合併發送資料，然後批次傳送以提高吞吐量。
失敗重試：對可重試的異常，Producer 會根據使用者配置的最大重試次數和重試退避時間進行重試。
優雅關閉：使用者呼叫關閉方法進行關閉時，Producer 會將所有其快取的資料進行傳送，防止日誌丟失。
高效能：透過多執行緒、快取策略、批次傳送等手段，有效提升傳送效率。
可觀測資料採集器iLogtail
iLogtail是資料匯流排資料接入的重要流量來源，擁有的輕量級、高效能、自動化配置等諸多生產級別特性，可以署於物理機、虛擬機器、Kubernetes等多種環境中來採集遙測資料。iLogtail的核心定位是可觀測資料的採集器，幫助開發者構建統一的資料採集層，助力可觀測平臺打造各種上層的應用場景。透過iLogtail可以很好的解決資料匯流排資料接入的問題。
得益於阿里巴巴/螞蟻集團與公有云場景的不斷錘鍊，iLogtail和開源Agent（例如Fluentd、Logstash、Beats）相比，效能、資源消耗、可靠性、多租戶隔離、K8s支援等硬指標上較為領先，可以滿足多種業務場景下的苛刻要求。目前iLogtail已於2022年6月29日完整開源，吸引了眾多開發者的關注，GitHub Star數也於
2022年11月7日突破1K。
採集高效能、低開銷是iLogtail的核心優勢之一。iLogtail在Linux下使用inotify作為檔案監控的主要手段，提供了毫秒級延時的資料發現能力，同時為了兼顧不同作業系統以及支援各類特殊採集場景，iLogtail同時使用了輪詢作為的資料的發現方式。透過使用輪詢與事件並存的混合方式，iLogtail打造了一套兼具效能優勢同時不失魯棒性的檔案發現機制。此外，iLogtail 採用了無鎖化事件處理模型。與業界其他開源Agent為每個配置分配獨立執行緒/Goroutine讀取資料不同，iLogtail資料的讀取只配置了一個執行緒。由於資料讀取的瓶頸並不在於計算而是磁碟，單執行緒足以完成所有配置的事件處理以及資料讀取。使用單執行緒使得iLogtail的事件處理和資料讀取都可以在無鎖環境下執行，資料結構更加輕量化，從而取得了相對多執行緒處理更優的價效比。
在生產環境中，一臺服務存在數百個採集配置屬於常態，每個配置的優先順序、日誌產生速度、處理方式、上傳目的地址等都有可能不同，因此必須有效解決如何隔離各種自定義配置，保證採集配置QoS不因部分配置異常而受到影響的問題。iLogtail採用基於時間片的採集排程、多級高低水位反饋佇列、事件非阻塞處理、流控/停採策略以及配置動態更新等多項關鍵技術，融合實現了兼具隔離性、公平性、可靠性、可控性、價效比五大特性的多租戶隔離方案。經歷了多年雙11流量高峰期的考驗，這套方案已經被證明相比其他開源具備較大的穩定性和價效比優勢。
資料來源的多樣性毫不誇張的說可以是資料匯流排的生命線，否則就是巧婦難為無米之炊。iLogtail透過外掛化的設計，突破了單純檔案採集的範疇，有效擴充套件了上下游生態，使得iLogtail成為真正的可觀測採集器。目前iLogtail已經支援了眾多資料來源的接入，資料來源型別覆蓋Log、Metric、Trace，資料來源除了檔案的採集，還包括了標準協議的支援，例如HTTP、Mysql Binlog、Prometheus、Skywalking、Syslog等；iLogtail也透過eBPF支援，實現了無侵入的網路資料採集能力。資料輸出生態也從SLS逐步擴充套件到Kafka、gPRC等，未來透過開源社群共建也會支援ClickHouse、ElasticSearch等。
面對眾多異構資料的接入，資料匯流排一項職責就是透過資料處理構建統一的資料格式。iLogtail也提供了強大的資料處理能力，可以前置完成資料格式規整、資料過濾、上下文關聯等。iLogtail整體採用PipeLine的設計，首先透過Input外掛採集到資料，會經過採集配置中設定的Processor處理，之後經過Aggregator外掛打包，最終透過Flusher傳送到儲存系統。資料處理環境包含資料切分、欄位提取、過濾、資料增強等環節，所有外掛可以自由組合。
隨著雲原生落地，Logtail已全面支援Kubernetes，目前支援Docker、Containerd兩種主流的容器執行時。iLogtail透過實時監控容器列表並維護容器和日誌採集路徑對映，結合高效的檔案採集能力提供了極致的容器資料採集體驗。
iLogtail支援使用容器標籤、環境變數、K8s標籤、Pod名稱、名稱空間等多種方式進行容器篩選，為使用者提供了便利的採集源配置能力。支援DaemonSet、Sidecar、CRD等多種部署方式，為應對不同使用場景提供了靈活的部署能力。
此外，對於CICD自動化部署和運維程度要求較高的使用者，iLogtail還提供了K8s原生支援，支援透過CRD的方式進行採集配置管理。該方案中，iLogtail K8s新增了一個CustomResourceDefinition擴充套件，名為AliyunLogConfig。同時開發了alibaba-log-controller用於監聽AliyunLogConfig事件並自動建立iLogtail的採集配置，進而完成日誌採集工作。
流量中樞技術架構與實踐
LogHub作為SLS資料匯流排的流量中樞，是一個高吞吐的資料通道，支援海量可觀測資料的實時接入與消費能力。在可觀測資料場景下完全可以Kafka等訊息佇列產品，並且在效能、易用性和穩定性上更佳。
LogHub可以理解為 append-only 的 log 佇列結構，透過多個 shard 組合實現 IO 和儲存的水平擴充套件。並且在佇列基礎上建立多層索引，可快速定位到每一條資料在佇列中的位置，賦予佇列模型隨機查詢能力。
彈性： 支援1~512個分割槽（shard），毫秒級擴容、縮容。
高吞吐：單shard支援5MB/sec寫入，10MB/sec讀取。
高容錯：單機failover不影響正常寫入。
去重：支援ExtractlyOnce去重寫入。
隨機查詢：1%額外儲存的開銷，支援任意資料隨機查詢（1次IO）。
點選檢視原文，獲取更多福利！
https：//developer。aliyun。com/article/1099215？utm_content=g_1000365661
版權宣告：本文內容由阿里雲實名註冊使用者自發貢獻，版權歸原作者所有，阿里雲開發者社群不擁有其著作權，亦不承擔相應法律責任。具體規則請檢視《阿里雲開發者社群使用者服務協議》和《阿里雲開發者社群智慧財產權保護指引》。如果您發現本社群中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社群將立刻刪除涉嫌侵權內容。
