本文為阿里雲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 等。
針對Java、Go等大資料、高併發場景下，我們在SDK基礎上提供了Java Producer[1]、Go Producer[2]；針對IoT/嵌入式裝置，推出了C Producer[3]。使用 Producer 相對於直接透過 API 或 SDK 傳送資料，提供了更上層的封裝，效能、可靠性都有大幅提升。執行緒安全：Producer 內所有的方法以及暴露的介面都是執行緒安全的。
非同步傳送：客戶端計算與 I/O 邏輯分離。呼叫 Producer 的傳送介面通常能夠立即返回，Producer 內部會快取併合併傳送資料，然後批次傳送以提高吞吐量。
失敗重試：對可重試的異常，Producer 會根據使用者配置的最大重試次數和重試退避時間進行重試。
優雅關閉：使用者呼叫關閉方法進行關閉時，Producer 會將所有其快取的資料進行傳送，防止日誌丟失。
高效能：透過多執行緒、快取策略、批次傳送等手段，有效提升傳送效率。
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 和儲存的水平擴充套件。並且在佇列基礎上建立多層索引，可快速定位到每一條資料在佇列中的位置，賦予佇列模型隨機查詢能力。Logstore/Metricstore是SLS可觀測資料的採集、儲存和查詢單元，LogHub作為Logstore/Metricstore的佇列模型，提供了資料實時寫入和流式消費的能力。同時在此基礎上，進行了模型擴充套件，進而構建出了統一的可觀測分析引擎。
LogHub 是阿里雲上的基礎設施，藉助阿里雲等全球化部署優先，與阿里雲Region保持同步，這也是其他開源資料匯流排無法比擬的優勢。可以確保全球化業務就近選擇Region，也可以滿足一些國家或組織相關的法律約束資料不能出境的要求。LogHub 聯合 CDN 推出了全球自動上傳加速方案，基於阿里雲CDN硬體資源（覆蓋2800+節點，70+國家），全球資料就近接入邊緣節點，透過內部高速通道路由至LogHub，大大降低網路延遲和抖動。
在生產中我們往往會面臨流量峰值和低值的情況，也會遇到因業務層對映不均衡，導致某一個分割槽（shard）有非常大流量的場景，彈性伸縮（Merge/Split）就是解決該問題的機制。Shard分裂的原理
Shard分裂操作，是流量擴容的一個重要手段，是把一個readwrite的Shard分裂成兩個readwrite的Shard；同時原Shard變成readonly狀態，之上的資料可繼續被消費讀取。合併操作和分裂操作相反，是把兩個相鄰的readwrite的Shard合併成一個readwrite Shard，同時原來的兩個Shard變成readonly狀態。負載均衡：根據峰值、底值彈性擴容，控制成本。
下圖最早只有Shard0提供服務；後隨著晚間流量高峰單Shard不足以支撐業務流量，Shard0拆分為了Shard1、Shard2提供服務；等流量再次穩定，出於成本考慮，合併成一個新的Shard3提供服務。日誌保序處理：將不同例項對映到不同分割槽，調整分割槽處理能力。
對於一些業務場景有保序的需求，資料寫入時往往透過Hash規則，將不同業務的資料對映到固定的Shard上。下圖中的業務場景，Shard1承載了3個DB的流量不堪重負，此時可以透過進行Shard拆分的方式，實現流量的均衡。拆分後，原來的Shard1變成只讀，資料仍可被消費，但是不再接收新的資料寫入，該由新拆分出的Shard3、Shard4對外提供服務。那對於Shard調整前後的邊界資料，如何保序？Loghub提供了Shard順序消費的能力，即Shard分裂後，先消費原Shard資料（即Shard1的資料），然後同時消費由該Shard分裂的Shard資料（Hash策略保證同一業務落到一個Shard上）。同理，Shard合併場景，也是先消費原Shard資料，然後消費由原Shard合併後的新Shard資料。當然，對於不嚴格保序的場景，為了提升消費速率，可以關閉Shard順序消費功能，以達到所有Shard可以同時消費的目的。
粗粒度流控：Project級別
Project全域性流控最主要的目的是限制使用者整體資源用量，在前端就拒絕掉請求，防止流量穿透後端把整個叢集打爆。細粒度流控：Shard級別
Shard級別流控則更加精細、語義（錯誤碼）更加明確、可控性更強。每個Shard明確定義處理能力， 如5MB/sec寫入，10MB/sec的讀取。
當Shard佇列出現堵塞，根據Shard流量是否超過quota，返回使用者是限流還是系統錯誤（返回的Http錯誤碼是403還是500），同時將Shard限流資訊通知QuotaServer。
QuotaServer接收到限流資訊後，可瞬時將限流資訊同步至所有的Nginx。
- Nginx端獲得Shard的流控資訊之後，對Shard進行精確的流控。
從上文資料接入部分我們可以看到，資料匯流排作為流量中樞，承載著各種異構資料的接入。雖然 iLogtail 具備較強的前置資料處理能力，但是往往會有一些資料因為歷史原因或者接入方式的差異導致了資料格式可能千差萬別，難以做到統一的格式規範，給後續分析帶來了極大的困難。因此資料匯流排往往也需要一個資料處理環節，為此我們提供了以資料加工服務和定時SQL（Scheduled SQL）為主的資料處理能力。此外，為了更好的支援開源生態，也支援透過自定義消費或者Flink流式消費的能力。
規整：這是使用頻率最高的場景，比如從文字日誌資料中提取出關鍵資訊，將其轉為規範化的資料。
富化：比如使用者的點選資料中只包含商品ID，在分析時需要從資料庫關聯起詳細資訊。
脫敏：隨著我國資訊保安相關法律的完善，對於敏感資料（比如個人資訊）的處理要求越來越高。
分裂：在資料寫出時，出於效能、便捷性考慮會將多條資料合併輸出，在分析前則需要拆分出獨立資料條目。
- 分發：將不同型別的資料分別寫到不同的特定目標中，以供下游定製化使用。
整體架構
資料加工服務基於實時消費組實現從源Logstore中負載均衡的消費資料，源Logstore的Shard數決定了資料加工任務的併發度上限。當資料加工排程器啟動一個新的作業時，會自動建立並繫結到源 Logstore 的一個消費組，消費組內部的多個消費者獨立負責處理不同Shard中的資料。隨著資料量增多，源Logstore需要拆分出更多的Shard，同時資料加工作業便可以擴充套件更多的消費者獨立工作。當作業需要關聯外部資源的時候，每一個消費者獨立維護一份資源的複製，實現高效能關聯計算。彈性機制
日誌資料除了資料量巨大，另一個特點是資料量呈週期性波動，而且波動波峰極高極窄。比如對於直播平臺，其一天的90%流量都來源於 21:00至23:00 這一個休閒時段，這就導致這一時間段的資料量是平時的數十倍。面對這樣的極端場景，資料加工就需要能夠實現計算力的彈性伸縮，保障使用者作業高效能運轉的同時，儘可能減少資源浪費。
資料加工在任務排程中的彈性伸縮是基於LogHub的消費組和K8s的HPA機制實現的。在系統內部透過儲存計算分離實現資料加工計算力自由伸縮，在使用者側看到的則是服務化計算平臺，按量付費，無需關心繁雜的細節。原生的K8S HPA內建僅支援CPU和記憶體兩個指標，這對於絕大多數資料密集型作業來說已經足夠了。但是在資料加工中，某些客戶會對資料編排，進行跨地域資料流轉，面對這類網路/IO敏感場景，內建的HPA指標就無法滿足。所以我們引入了更全面的HPA指標，以支撐多種多樣業務場景下的作業需求。除此之外，我們還將使用智慧演算法對HPA指標進行續升級最佳化， 比如基於作業的歷史執行特性，提前做資源分配，更進一步提升作業執行的穩定性。 Cloud Data Processing Language（DPL）
資料加工服務基於Python語法設計使用者側介面，並提供完善的內建資料處理函式，這裡我們將其稱為 Cloud Data Processing Language (DPL)。藉助DPL，可以透過極少數程式碼完成非常複雜的資料處理邏輯。以下是一個資訊富化的例子：在http請求中，透過RDS維表的關聯，將請求狀態碼（http_status欄位）的詳細描述（http_code_desc欄位）新增到原始資料中。
基於時間的資料（日誌、指標）在日積月累後的數量是驚人的。以 Nginx 訪問日誌為例，每一個HTTP/HTTPS 訪問請求會記錄一條 access log，假設每天產生1000萬條資料，則一年為36億條資料。長時間大量的資料儲存，不僅會佔用大量的儲存空間，對資料資料分析處理也會造成極大的效能壓力。Schedule SQL可以對資料進行定時的聚合分析處理（支援標準SQL、SLS 查詢和分析語句），按照排程規則週期性執行，並將執行結果寫入到目標庫中。相比較與自建呼叫API方式，具備以下優勢：雲上服務（例如OSS、SLB等）往往是由雲廠商託管，使用者是無法直接登陸伺服器進行日誌檢視的。資料分派技術就是基於SLS的資料匯流排技術實現的關鍵服務模組，在使用者授權的前提下，實現將可觀測資料從雲服務側投遞到各個使用者側的目的。實現機制為雲產品服務側透過預先的採集、清理（處理）流程，將日誌存入集中的資料中樞（LogHub），再透過分發服務，將資料以多租戶的形式分發到使用者側。其具備以下優勢：
資料分派技術只是解決了可觀測資料從雲產品服務側到使用者側的流轉問題，但是要實現雲上服務日誌的採集，仍然需要雲資產歸屬、多賬號體系認證等需要一些上層的服務來維護。為此，我們構建了多個基礎服務，包括資產同步、自動化採集服務、多賬號體系等，統稱為統一接入服務。之後，基於統一接入服務，進一步針對各個雲產品提供統一的互動與功能元件，構建了更上層的APP能力 -- Alibaba Cloud Lens。Alibaba Cloud Lens 基於 SLS 構建統一雲產品可觀測能力，提供阿里云云產品的用量分析、效能監控、安全分析、資料保護、異常檢測、訪問分析等服務。從成本、效能、安全、資料保護、穩定性、訪問分析六個緯度， 提供對雲產品的運維輔助分析能力，有效降低雲產品可觀測的門檻。
採集鏈路自動編排是Cloud Lens的一大特色。透過圖形化的方式，就可以實現一鍵式、自動化的資產發現與自動化資料採集（到使用者側），其背後實際是是依賴於DSL程式碼實現採集邏輯的編排。未來已來，SLS資料匯流排技術也會在採集接入、管道、計算三個層次不斷耕耘，為可觀測平臺持續不斷的提供穩定可靠的資料基礎。附錄：
SLS ：打造可觀察性統一引擎
五年雙十一：SLS資料管道發展之路
數字IT基礎-資料採集匯流排：https://developer.aliyun.com/article/672576
使用日誌服務LogHub替換Kafka：https://developer.aliyun.com/article/35979
日誌服務（原SLS）新功能釋出(1)--支援保序寫入和消費：https://developer.aliyun.com/article/5581
日誌服務（原SLS）新功能釋出(2)--彈性伸縮(Merge/Split)：https://developer.aliyun.com/article/277425
參考連結：
[1]
[2]
[3]
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70024420/viewspace-2926766/，如需轉載，請註明出處，否則將追究法律責任。
