數字IT基礎-數據採集總線

數字化運營基礎
在現在「雙十一」再也不是線上活動的代名詞，而逐步變爲一場線上線下同時進行的消費者盛宴。銷售、運營、物流、生產商等都在開足馬力在各大渠道備戰，據統計：

消費者在期間被平均推送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=13860394XX HTTP/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埋點：

在完成數據埋點後，咱們能夠在日誌服務分析功能中，得到每一個環節的點擊數和轉化數字，以衡量購買階段的效果。

Web Tracking連接：https://help.aliyun.com/docum...
服務端埋點連接：https://help.aliyun.com/docum...

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

購買一批機器搭建網絡服務器
爲服務器搭建負載均衡設備
在網絡服務器（例如Nginx）模塊中使用Kafka等中間件寫入數據

該方案經過無狀態設計解決了高可用，按需擴容等問題，也是衆多廠商採用的方案，在理想狀態下運行得很是好。但在現實過程當中，每每會遇到以下挑戰：

做爲用戶最終的目標是爲了分析數據。但這些問題的存在，須要在業務、規模與增加上消耗大量人力、精力和物力，幹了不必定幹得好。

日誌服務LogHub功能
阿里雲日誌服務（Log Service，/原SLS）是針對實時數據一站式服務，其中的LogHub模塊就是專爲數據採集定製的功能，該功能有以下特色：

1. 30+實時採集手段

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

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/article...

目前針對不一樣的環境（例如網絡服務器、ARM設備、以及RTOS等設備）從大到小咱們提供了3種方案：

​ 在X86以及ARM設備測試場景中，C-Producer系列SDK能在穩定服務狀況下，極大優化性能和內存空間佔用，勝任只有4KB運行內存的火火兔場景（Brick版本）。

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

這些智能SDK天天DAU超百萬，遍及在全球各地的設備上，一天傳輸百TB數據。關於C Producer Library 的細節能夠參考這篇文章: 智能設備日誌利器：嵌入式日誌客戶端（C Producer）發佈。

1. 服務端多地域支持

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

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

1. 全球加速網絡

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

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

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

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

1. 服務端彈性伸縮

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

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

業務沒法預測：事先沒法準確預估數據量，預設多少個shard才合適呢
人的反應滯後：數據量隨時會突增，人不必定可以及時處理，長時間超出服務端負載能力會有數據丟失風險
​ 針對以上狀況，LogHub提供了全球獨創Shard自動分裂功能：在用戶開啓該功能後，後臺系統實時監控每一個shard的流量，若是發現一個shard的寫入在一段時間內，有連續出現超過shard處理能力的狀況，會觸發shard的自動分裂，時刻保障業務流量。

更多細節能夠參考這篇文章: 支持Shard自動分裂

1. 豐富上下游生態與場景支持

LogHub也提供豐富上下游與生態對接，包括各類主流流計算、數據倉庫等引擎支持：

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

經過LogHub與日誌服務其餘功能+產品組合，能夠輕鬆支撐安全、運營、運維和研發對於數據處理的各類場景需求，更多能夠參考學習路徑 和 用戶手冊。

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