簡介

提到日誌實時分析，很多人都會想到很火的ELK Stack（Elastic/Logstash/Kibana）來搭建。ELK方案開源，在社群中有大量的內容和使用案例。

阿里雲日誌服務產品在新版中增強查詢分析功能（LogSearch/Analytics），支援對日誌資料實時索引與查詢分析，並且對查詢效能和計算資料量做了大量優化。在這裡我們做一個全方位的比較，對於使用者關心的點，我們依次展開分析：

• 易用：上手及使用過程中的代價
• 功能（重點）：主要針對查詢與分析兩塊
• 效能（重點）：對於單位大小資料量查詢與分析需求，延時如何
• 規模（重點）：能夠承擔的資料量，擴充套件性等
• 成本（重點）：同樣功能和效能，使用分別花多少錢

易用

對日誌分析系統而言，有如下使用過程：

1. 採集：將資料穩定寫入
2. 配置：如何配置資料來源
3. 擴容：接入更多資料來源，更多機器，對儲存空間，機器進行擴容
4. 使用：這部分在功能這一節介紹
5. 匯出：資料能否方便匯出到其他系統，例如做流計算、放到物件儲存中進行備份
6. 多租戶：如何將資料能否分享給他人使用，使用是否安全等

以下是比較結果：

總體而言：

ELK 有非常多的生態和寫入工具，使用中的安裝、配置等都有較多工具可以參考。LogSearch/Anlaytics是一個託管服務，從接入、配置、使用上整合度非常高，普通使用者5分鐘就可以接入。並且過程中不需要擔心容量、併發等問題，按量計費，彈性伸縮。

功能（查詢+分析）

查詢主要將符合條件的日誌快速命中，分析功能是對資料進行統計與計算。

例如我們有如下需求：所有大於200讀請求，根據Ip統計次數和流量，這樣的分析請求就可以轉化為兩個操作：查詢到指定結果，對結果進行統計分析。在一些情況下我們也可以不進行查詢，直接對所有日誌進行分析。

1: Status in (200,500] and Method:Get* 
2: select count(1) as c, sum(inflow) as sum_inflow, ip group by Ip

查詢能力對比

ElasticSearch 支援的資料型別，以及查詢方式上要更強。Log-Search/Analytics 支援大部分常用查詢，也有一些特色（例如程式日誌上下文查詢與展開）。

分析能力對比

從結果看Log-Search/Analytics 提供的功能是ES 超集，完整支援SQL 92 語義，只要會寫SQL 都能直接使用。

效能

接下來我們測試針對相同資料集，分別對比寫入資料及查詢，和聚合計算能力。

實驗環境

1、 測試配置

2、測試資料

• 5列double
• 5列long
• 5列text，字典大小分別是256，512，768，1024，1280

• 以上欄位完全隨機，如下為一條測試日誌樣例：

  timestamp:August 27th 2017, 21:50:19.000 
  long_1:756,444 double_1:0 text_1:value_136 
  long_2:-3,839,872,295 double_2:-11.13 text_2:value_475 
  long_3:-73,775,372,011,896 double_3:-70,220.163 text_3:value_3 
  long_4:173,468,492,344,196 double_4:35,123.978 text_4:value_124 
  long_5:389,467,512,234,496 double_5:-20,10.312 text_5:value_1125
  

3、 資料集大小

• 原始資料大小：50 GB
• 原始資料除去Key後內容大小：27 GB（LogSearch/Analytics 以該大小作為儲存計費單元）
• 日誌行數：162,640,232 (約為1.6億條)

寫入測試結果

ES採用bulk api批量寫入，LogSearch/Analytics 用PostLogstoreLogs API批量寫入，結果如下：

備註：LogSearch/Analytics 產生計費的儲存量包括壓縮的原始資料寫入量(23G)+索引流量(27G)，共50G儲存費用。

從測試結果來看

• LogSearch/Analytics寫入延時好於ES，40ms vs 14 ms

• 空間：原始資料50G，因測試資料比較隨機所以儲存空間會有膨脹（大部分真實場景下，儲存會因壓縮後會比原始資料小）。ES脹到86G，膨脹率為172%，在儲存空間超出LogSearch/Analytics 58%

讀取（查詢+分析）測試

測試場景

我們在此選取兩種比較常見的場景：日誌查詢和聚合計算。分別統計併發度為1，5，10時，兩種case的平均延時。

1. 針對全量資料，對任意text列計算group by，計算5列數值的avg/min/max/sum/count，並按照count排序，取前1000個結果，例如：

    select count(long_1) as pv,sum(long_2),min(long_3),max(long_4),sum(long_5) 
    group by text_1 order by pv desc limit 1000
   

2. 針對全量資料，隨機查詢日誌中的關鍵詞，例如查詢 "value_126"，獲取命中的日誌數目與前100行，例如：

   value_126
   

測試結果

結果分析

• 從結果看，對於1.5億資料量這個規模，兩者都達到了秒級查詢與分析能力
• 針對統計類場景（case 1）， ES和日誌服務延時處同一量級。ES採用SSD硬碟，在讀取大量資料時IO優勢比較高
• 針對查詢類場景（case 2）， LogAnalytics在延時明顯優於ES。隨著併發的增加，ELK延時對應增加，而LogAnalytics延時保持穩定甚至略有下降

規模

1. LogSearch/Analytics 一天可以索引PB級資料，一次查詢可以在秒級過幾十TB規模資料，在資料規模上可以做到彈性伸縮與水平擴充套件

2. ES比較適合服務場景為：寫入GB-TB/Day、儲存在TB級。主要受限於2個原因：

   • 單叢集規模：比較理想為20臺左右，業界比較大的為100節點一個叢集
   • 寫入擴容：shard建立後便不可再修改，當吞吐率增加時，需要動態擴容節點，最多可使用的節點數便是shard的個數
   • 儲存擴容：主shard達到磁碟的上線時，要麼遷移到更大的一塊磁碟上，要麼只能分配更多的shard。一般做法是建立一個新的索引，指定更多shard，並且rebuild舊的資料

   LogSearch/Analytics 則沒有擴充套件性方面的問題，每個shard都是分散式儲存。並且當吞吐率增加時，可以動態分裂shard，達到處理能力水平擴充套件。

成本

以上述測試資料為例，一天寫入50GB資料（其中27GB 為實際的內容），儲存90天，平均一個月的耗費。

1、 日誌服務（LogSearch/LogAnalytics）計費規則參考文件，包括讀寫流量、索引流量、儲存空間等計費項，查詢功能免費。

2、 ES費用包括機器費用，及儲存資料SSD雲盤費用

• 雲盤一般可以提供高可靠性，因此我們這裡不計費副本儲存量
• 儲存盤一般需要預留15%剩餘空間，以防空間寫滿，因此乘以一個1.15係數

​ 同樣效能，使用LogSearch/Analytics與ELK（SSD）費用比為 13.6%。在測試過程中，我們也嘗試把SSD換成SATA以節省費用（LogAnalytics與SATA版費用比為 34%），但測試發現延時會從40ms上升至150ms，在長時間讀寫下，查詢和讀寫延時變得很高，無法正常工作了。

總結

​ LogSearch/Analytics在提供同樣查詢速度、更高吞吐量、更強分析能力背後，只需要開源方案13%成本（集團使用者預設7折，計算後只有10%成本），並且按量付費免運維，讓你把精力放在業務分析上。

​ 日誌服務除了LogSearch/Analytics外，還提供LogHub、LogShipper功能，支援實時採集資料、與流計算系統（Spark、Storm、Flink、StreamCompute）、離線分析系統（MaxCompute、E-MapReduce、Presto、Hive等）打通，提供一站式實時資料解決方案。

原文連結