從日誌到雙十一大屏只要一步：LOG/SLS+DataV 打通

提到雙十一人人都會想到天貓霸氣的實時大屏。提及實時大屏，都會想到最典型的流式計算架構：

• 數據採集：未來自各源頭數據實時採集
• 中間存儲：利用類Kafka Queue進行生產系統和消費系統解耦
• 實時計算：環節中最重要環節，訂閱實時數據，經過計算規則對窗口中數據進行運算
• 結果存儲：計算結果數據存入SQL和NoSQL
• 可視化：經過API調用結果數據進行展現

在阿里集團內，有大量成熟的產品能夠完成此類工做，通常可供選型的產品以下：

​ 除這種方案外，今天給你們介紹一種新的方法：經過日誌服務（LOG，原SLS）查詢分析LogSearch/Analytics API 直接對接DataV進行大屏展現。

2017年9月日誌服務(原SLS)增強日誌實時分析功能(LogSearch/Analytics)，可使用查詢+SQL92語法對日誌進行實時分析。在結果分析可視化上，除了使用自帶Dashboard外，還支持Grafana、Tableua（JDBC）等對接方式

兩種方式差異

計算通常根據數據量、實時性和業務需求會分爲兩種方式：實時計算（流計算）、離線計算（數據倉庫+離線計算），日誌服務（原SLS）對實時採集數據提供兩種方式對接。

除此以外，對於數據量偏大，對實時性有要求的日誌分析場景，咱們提供實時索引LogHub中數據機制，以後可經過LogSearch/Anlaytics直接進行查詢分析。這種方法好處是什麼：

• 快速：API傳入Query立馬拿到結果，無需等待和預計算結果
• 實時：日誌產生到反饋大屏99.9%狀況下1秒內
• 動態：不管修改統計方法、補數據能立馬刷新結果，不須要等待從新計算

固然沒有一個計算系統是萬能的，這種方式限制以下：

• 數據量：單次計算數據量在百億如下，超過須要限定時間段
• 計算靈活度：目前計算限於SQL92語法，不支持自定義UDF

實際案例：不斷調整統計口徑下實時大屏

雲棲大會期間有個臨時需求，統計線上（網站）在全國各地訪問量。因爲以前採集全量日誌數據而且在日誌服務中打開了查詢分析，因此只要寫一個查詢分析Query便可。以統計UV爲例子：咱們對全部訪問日誌中nginx下forward字段獲取10月11日到目前惟一計數：

* | select approx_distinct(forward) as uv

線上已跑了1天需求變動了，只須要統計yunqi這個域名下的數據。咱們增長了一個過濾條件（host），立馬拿到結果：

host:yunqi.aliyun.com | select approx_distinct(forward) as uv

後來發現Nginx訪問日誌中有多個IP狀況，默認狀況下只要第一個ip便可，在查詢中對Query進行處理

host:yunqi.aliyun.com | select approx_distinct(split_part(forward,',',1)) as uv

到第三天接到需求，針對訪問計算中須要把uc中廣告訪問去掉，因而咱們加上一個過濾條件（not …）既立刻算到最新結果：

host:yunqi.aliyun.com not url:uc-iflow  | select approx_distinct(split_part(forward,',',1)) as uv

最後大屏效果以下：

使用說明：SLS對接DataV

主要分3個步驟：

1. 數據採集，參考文檔
2. 索引設置 與控制檯查詢，參考索引設置與可視化，或最佳實踐中網站日誌分析案例
3. 對接DataV插件，將實時查詢SQL轉化爲視圖

咱們主要演示步驟3，在作完一、2步驟後，在查詢頁面能夠看到原始日誌：

建立dataV數據源

類型指定『簡單日誌服務-SLS』

名稱自定義

AK ID和AK Secret填寫主帳號，或者有權限讀取日誌服務的子賬號的AK。

Endpoint填寫 日誌服務的project所在region的地址。圖中爲杭州的region地址。

建立一個折線圖

建立一個折線圖，在折線圖的數據配置中，數據源類型選擇『簡單日誌服務-SLS』，而後選擇剛剛建立的數據源『log_service_api』在查詢中輸入參數。

查詢參數樣例以下：

{
    "projectName": "dashboard-demo",
    "logStoreName": "access-log",
    "topic": "",
    "from": ":from",
    "to": ":to",
    "query": "*| select approx_distinct(remote_addr) as uv ,count(1) as pv , date_format(from_unixtime(date_trunc('hour',__time__) ) ,'%Y/%m/%d %H:%i:%s')   as time group by date_trunc('hour',__time__) order by time limit 1000" ,
    "line": 100,
    "offset": 0
  }

projectName填寫本身的project。

logstoreName填寫日誌的logstore。

from和to分別是日誌的起始和結束時間。

注意,上文的咱們填寫的是:from和:to。 在測試時，能夠先填寫unix time,例如1509897600。等發佈以後，換成:from和:to這種形式，而後咱們能夠在url參數裏控制這兩個數值的具體時間範圍。例如，預覽是的url是http://datav.aliyun.com/screen/86312, 打開http://datav.aliyun.com/screen/86312?from=1510796077&to=1510798877後，會按照指定的時間進行計算。

query填寫查詢的條件，query的語法參考分析語法文檔。樣例中是展現每分鐘的pv數。 query中的時間格式，必定要是2017/07/11 12:00:00這種，因此採用date_format(from_unixtime(date_trunc('hour',__time__) ) ,'%Y/%m/%d %H:%i:%s') 把時間對齊到整點，再轉化成目標格式。

其餘參數採用默認值。

配置完成後，點擊『查看數據響應結果』：

點擊上方『使用過濾器』，而後新建一個過濾器:

過濾器內容填寫：

return Object.keys(data).map((key) => {
  let d= data[key];
  d["pv"] = parseInt(d["pv"]);
  return d;
}
)

在過濾器中，要把y軸用到的結果變成int類型，上述樣例中，y軸是pv，因此須要轉換pv列。

能看到在結果中有t和pv兩列，那麼咱們在x軸配置爲t，y軸配置成pv。

配置一個餅狀圖

查詢填寫：

{
    "projectName": "dashboard-demo",
    "logStoreName": "access-log",
    "topic": "",
    "from": 1509897600,
    "to": 1509984000,
    "query": "*| select count(1) as pv ,method group by method" ,
    "line": 100,
    "offset": 0
  }

在查詢中，咱們計算不一樣method的佔比。

添加一個過濾器，過濾器填寫：

return Object.keys(data).map((key) => {
  let d= data[key];
  d["pv"] = parseInt(d["pv"]);
  return d;
}
)

餅圖的type填寫method, value填寫pv。

預覽和發佈

點擊預覽和發佈，一個大屏就建立成功了。開發者和業務同窗能夠在雙十一當天實時看到本身的業務訪問狀況！

附上：Demo地址。url中的參數from和to，你們能夠隨意切換成任意時間。