數字IT基礎-資料採集匯流排

摘要： 數字化運營基礎 在如今“雙十一”不再是線上活動的代名詞，而逐步變為一場線上線下同時進行的消費者盛宴。銷售、運營、物流、生產商等都在開足馬力在各大渠道備戰，據統計： 消費者在期間被平均推送200+活動訊息 消費者會花幾個小時比較、提前篩選自己中意產品 除了線上外，90...

數字化運營基礎

在如今“雙十一”不再是線上活動的代名詞，而逐步變為一場線上線下同時進行的消費者盛宴。銷售、運營、物流、生產商等都在開足馬力在各大渠道備戰，據統計：

• 消費者在期間被平均推送200+活動訊息
• 消費者會花幾個小時比較、提前篩選自己中意產品
• 除了線上外，90%線下店鋪都掛出針對雙十一運營活動

雙十一觸客渠道也呈現多樣化，例如：網路店鋪、簡訊、郵件、微信公眾賬號、派單與Kitty板、自提櫃、智慧裝置（例如天貓精靈點單）、多媒體裝置（例如電視或機頂盒購物）等。

面對如此多的渠道和銷售方式，運營和銷售如何有效掌控，並通過數字化方式進行運營是一項硬能力。讓我們來看幾個例子：

例子1：新使用者引流

網際網路經典書籍《 上癮：構建習慣養成的產品》把使用者獲取過程分為4個階段：觸發、行動、獎勵、投入。作為最開始的觸發環節，給使用者群發訊息是最有效的手段之一。但如何衡量轉化效果呢？

我們可以在推廣資訊中做一個埋點，把使用者點選簡訊帶上關聯資訊，例如設計一個如下的URL，其中放入2個關鍵引數：

• t: 代表傳送的批次編號，也可以作為渠道的標識
• m：代表傳送的簡訊號碼

html://mywebsite.com/new?t=1002&m=13860394XX

當用戶點點選訊息訪問站點時，我們在服務端訪問日誌中會自動記錄對應資訊:

202.168.1.209 - - [02/Feb/2016:17:44:13+0800] "GEThtml://mywebsite.com/new?t=1002&m=13860394XXHTTP/1.1" 200 209 - "Mozilla/5.0(Macintosh; Intel Mac OS X10_11_3) AppleWebKit/537.36(KHTML, like Gecko)Chrome/48.0.2564.97 Safari/537.36"

這樣我們就能獲得推廣效果和轉化率：

例子2：線上購買意圖捕捉

在獲取客戶後，下一步是讓使用者付諸於行動。使用者在瀏覽商品時，會有頁面的停留，閱讀，比較和加入購物車等操作。可以藉助Web Tracking和Serve端埋點來進行靜態與動態資料採集。

在靜態網頁和瀏覽器埋點：

<img src=‘http://${project}.${sls-host}/logstores/${logstore}/track_ua.gif?APIVersion=0.6.0&key1=val1&key2=val2’/>

通過JS埋點：

varlogger = new window.Tracker('cn-hangzhou.log.aliyuncs.com','ali-test-tracking','web-tracking');
logger.push('customer','zhangsan');
logger.push('product','iphone6s');
logger.push('price',5500);
logger.logger();

在完成資料埋點後，我們可以在日誌服務分析功能中，獲得每個環節的點選數和轉化數字，以衡量購買階段的效果。

Web Tracking連結： ofollow,noindex" target="_blank">https://help.aliyun.com/document_detail/31752.html

服務端埋點連結： https://help.aliyun.com/document_detail/28979.html

資料採集挑戰

從上面例子來看，資料採集是數字化IT的基礎。讓我們來看一個典型的資料採集架構：

1. 購買一批機器搭建網路伺服器
2. 為伺服器搭建負載均衡裝置
3. 在網路伺服器（例如Nginx）模組中使用Kafka等中介軟體寫入資料

該方案通過無狀態設計解決了高可用，按需擴容等問題，也是眾多廠商採用的方案，在理想狀態下執行得非常好。但在現實過程中，往往會遇到如下挑戰：

步驟	模組	挑戰	成本
端	協議封裝與客戶端開發	需要開發眾多SDK，例如Android、IOS、嵌入式等	研發成本、運維
	客戶端傳輸	面向網路不可用	斷點續傳功功能
	客戶端傳輸	傳輸過程中安全問題	HTTPS協議支援與證書
	客戶端升級	客戶端如果有Bug如何升級	運維成本
傳輸	網路質量差	網路質量差	購買昂貴專線
	地域與合規	使用者資料不能出國，例如歐盟等協議	在全球建各資料中心
	網路選擇	運營商速度、質量不一，質量差	購買第三方加速服務
服務端	擴容	流量上漲時，如何自動擴容	購買伺服器、手動運維
	防攻擊	採集伺服器可能被DDOS	運維伺服器
	認證	進行使用者認證與管理	開發負責的認證與管理模組
	資料加工	資料到服務端後，增加來源IP、服務端時間等欄位	服務端開發成本
	上下游對接	對接各種流計算、離線處理系統	硬體採購、程式開發與維護

作為使用者最終的目標是為了分析資料。但這些問題的存在，需要在業務、規模與增長上消耗大量人力、精力和物力，幹了不一定幹得好。

日誌服務LogHub功能

阿里雲日誌服務（Log Service，/原SLS） 是針對實時資料一站式服務，其中的LogHub模組就是專為資料採集定製的功能，該功能有如下特點：

1. 30+實時採集手段

LogHub提供 30+種開箱即用的資料採集手段 ，包括直接和雲產品打通的日誌、移動端、服務端、程式、SDK、網頁、嵌入端等，以下我們分別介紹下最常用的四種與試用場景：

方式	應用場景	當前規模	優勢
Logtail	X86伺服器採集	百萬-千萬	功能強
Android/IOS SDK	移動端資料採集、手機、POS機等	千萬DAU	斷點續傳
C Producer Library	硬體資源受限的系統（如 IoT、嵌入式、RTOS等）	千萬-億級	資源消耗低
Web Tracking	網頁靜態資料採集	千萬-億級	輕量級，無驗證

1.1 Logtail（部署量最大Agent）

Logtail安裝在X86裝置上，通過中央伺服器進行管控，只需點點滑鼠或API就能夠在幾秒鐘內對百萬機器下達資料採集指令。Logtail目前每天有幾百萬的執行例項，適配所有Linux版本、Window、Docker、K8S等環境；支援幾十種資料來源對接，關於Logtail功能可以參見介紹文件。

得益於阿里巴巴集團場景的不斷錘鍊，Logtail和開源Agent（例如Fluentd、Logstash、Beats）相比，效能、資源消耗、可靠性和多組合隔離等硬指標上較為領先。可以滿足國內最大的直播網站、最大的教育類網站、最大的金融類網站的苛刻要求。和開源Agent主要差距在於日誌格式的豐富性（當前Logtail版本已支援Logstash、Beats協議，既可以將這些開源外掛無縫跑在Logtail之上）。

2018年Logtail針對Docker/K8S等場景做了非常多的適配工作，包括：

• 一條命令一個引數即可實現部署，資源自動初始化
• 支援CRD方式配置，支援K8S控制檯、kubectl、kube api等，與K8S釋出、部署無縫整合
• K8S RBAC鑑權，日誌服務STS鑑權管理

可以自豪地說，Logtail方案是K8S下所有Agent中最全，最完整的之一，感興趣可以參見 LC3視角：Kubernetes下日誌採集、儲存與處理技術實踐 ：

1.2 C Producer Library系列（面向嵌入式裝置新秀）

​ 除X86機器外，我們可能會面對各種更底層IoT/嵌入式裝置。針對這種場景，LogHub推出C Producer Library系列SDK，該SDK可以定位是一個“輕量級Logtail”，雖沒有Logtail實時配置管理機制，但具備除此之外70%功能，包括：

• 多租戶概念：可以對多種日誌（例如Metric，DebugLog，ErrorLog）進行優先順序分級處理，同時配置多個客戶端，每個客戶端可獨立配置採集優先順序、目的project/logstore等
• 支援上下文查詢：同一個客戶端產生的日誌在同一上下文中，支援檢視某條日誌前後相關日誌
• 併發傳送，斷點續傳：支援快取上線可設定，超過上限後日志寫入失敗
  專門為IoT準備功能：
• 本地除錯：支援將日誌內容輸出到本地，並支援輪轉、日誌數、輪轉大小設定
• 細粒度資源控制：支援針對不同型別資料/日誌設定不同的快取上線、聚合方式
• 日誌壓縮快取：支援將未傳送成功的資料壓縮快取，減少裝置記憶體佔用

關於C Producer Library的更多內容參見目錄： https://yq.aliyun.com/articles/304602

目前針對不同的環境（例如網路伺服器、ARM裝置、以及RTOS等裝置）從大到小我們提供了3種方案：

​ 在X86以及ARM裝置測試場景中，C-Producer系列SDK能在穩定服務情況下，極大優化效能和記憶體空間佔用，勝任只有4KB執行記憶體的火火兔場景（Brick版本）。

使用C Producer系列的客戶有： 百萬日活的天貓精靈、小朋友們最愛的故事機火火兔、 遍佈全球的碼牛、釘釘路由器、 相容多平臺的視訊播放器、 實時傳輸幀影象的攝像頭等。

這些智慧SDK每天DAU超百萬，遍佈在全球各地的裝置上，一天傳輸百TB資料。關於C Producer Library 的細節可以參考這篇文章: 智慧裝置日誌利器：嵌入式日誌客戶端（C Producer）釋出 。

2. 服務端多地域支援

​ 客戶端問題解決了後，我們來看看服務端。LogHub 是阿里雲化基礎設施，在 全球阿里雲所有Region都有部署 。確保無論業務在哪個Region開展，都可以選擇就近的Region。

例如歐盟、新加坡等國家有相關的法律約束資料不能出境，對於這類場景我們可以選擇合適的資料中心來提供服務。對於同Region下ECS、Docker等服務，我們可以直接使用同Region服務進行處理，節省跨洋傳輸的成本。

3. 全球加速網路

​ 對全球化業務而言，使用者可能分佈在全球各地（例如遊戲，App、物聯網等場景），但在構建數倉業務的過程中，我們往往需要對資料進行集中化處理。例如一款移動App使用者散佈在全國各省市

• 將日誌採集中心定在杭州，那對於西南（例如成都）使用者而言，遠端進行日誌傳輸的延時和質量難以保障
• 將日誌採集中心定在成都，那對位於東部和東北使用者又難以權衡，更不用說中國的三大運營商鏈路質量的影響

​ 2018年6月初LogHub 聯合 CDN 推出了一款全球自動上傳加速方案：“基於阿里雲CDN硬體資源，全球資料就近接入邊緣節點，通過內部高速通道路由至LogHub，大大降低網路延遲和抖動 ”。只需簡單配置即可構建起快速、穩定的全球資料採集網路，任意LogHub SDK都可以通過Global域名獲得自動加速的支援。

​

在我們測試case中，經過全球7個區域對比整體延時下降50%，在中東，歐洲、澳洲和新加坡等效果明顯。除了平均延時下降外，整體穩定性也有較大提升（參見最下圖，幾乎沒有任何抖動）。確保如何在世界各地，只要訪問一個統一域名，就能夠高效、便捷將資料採集到期望Region內。

4. 服務端彈性伸縮

​ 在解決網路接入問題後，我們把問題聚焦在服務端流量這個問題上。熟悉Kafka都知道，通過Partition策略可以將服務端處理資源標準化：例如定義一個標準的單元Partition或Shard（例如每個Shard固定5MB/S寫，10MB/S讀）。當業務高峰期時，可以後臺Split Shard以獲取2倍的吞吐量。

這種方法看起來很工程化，但在使用過程中有兩個難以繞開的現實問題：

• 業務無法預測：事先無法準確預估資料量，預設多少個shard才合適呢
• 人的反應滯後：資料量隨時會突增，人不一定能夠及時處理，長時間超出服務端負載能力會有資料丟失風險

​ 針對以上情況，LogHub提供了全球首創Shard自動分裂功能：在使用者開啟該功能後，後臺系統實時監控每個shard的流量，如果發現一個shard的寫入在一段時間內，有連續出現超過shard處理能力的情況，會觸發shard的自動分裂，時刻保障業務流量。

更多細節可以參考這篇文章:支援Shard自動分裂

5. 豐富上下游生態與場景支援

LogHub也提供豐富上下游與生態對接，包括各種主流流計算、資料倉庫等引擎支援：

• 採集端：Logstash、Beats、Log4J等
• 實時消費端（流計算）：Flink/Blink、Storm、Samza等
• 儲存端（數倉）：Hadoop、Spark、Presto、Hive等

通過LogHub與日誌服務其他功能+產品組合，可以輕鬆支撐安全、運營、運維和研發對於資料處理的各種場景需求，更多可以參考學習路徑 和使用者手冊。

寫在最後

日誌服務是阿里自產自用的產品，在雙十一、雙十二和新春紅包期間 承載阿里雲/螞蟻全站、阿里電商板塊、雲上幾千商家資料鏈路，每日處理來自百萬節點幾十PB資料，峰值流量達到每秒百GB， 具備穩定、可靠、低成本，生態豐富等特性。

阿里雲官網上提供同款產品，只要5分鐘便可開通並開啟數字化IT之旅，歡迎試用。