新功能：日志服務指令行工具ETL釋出！

日志服務托管服務資料加工已經釋出,參考: https://yq.aliyun.com/articles/704935

背景

使用日志服務，在搜尋、分析時是否經常遇到以下資料格式規整的痛點？

1. 采集時ETL的痛點：

• 交換機、伺服器、容器、Logging子產品等，通過檔案、标準輸出、syslog、網絡等途徑收集時，裡面是各種日志格式的混合，隻能做部分提取，例如使用logtail先提取某些基礎字段，例如時間、log level、IP等，但是日志主體

  message

  中很多有價值的資訊因為混合了各種日志，無法在導入時提取？
• 單一場景下的日志，例如NGNIX，的

  QueryString

  中的字元串，或者

  HttpCookie

  、甚至

  HttpBody

  資訊等，裡面字段内容變化巨大，格式資訊複雜度也很高，難以在提取的時候一次性使用正規表達式完成提取。
• 某些正常日志包含了敏感資訊（例如秘鑰的密碼，使用者手機号、内部資料庫連接配接字元串等），很難在提取時過濾掉或者做脫敏。
• 某些JSON日志資訊包含多條日志，需要分裂為多條日志進行處理等，但無法操作？
• 其他方法例如使用SDK規則後再上傳、通過Logstash channel轉換後導入等方法試圖解決時，事情變得複雜，資料收集的性能也變得更慢？

2. 查詢分析時做ETL的痛點：

• 因為日志非常複雜，SQL本身處理時，語句膨脹的比較厲害，難以修改和維護？
• 好不容易使用SQL的正規表達式完成了某一類日志的提取，但是因為計算的動态字段沒有索引，性能又受到很大影響？
• 某些字段的關鍵字名都是不固定，例如KV格式、甚至待轉義的KV等，使用SQL提取字段時，更加困難。
• 對多個特定字段進行

  lookup

  富化時，

  Join

  後多個關聯的複雜度和性能比較難以接受。
• JSON日志格式的分析有一定的限制，例如：基于數組的對象内容無法很好的分析、複雜的JSON格式無法很好關聯等。

3. 投遞歸檔時做ETL的痛點：

• 投遞到OSS、MaxCompute等并不支援内容上的過濾或者格式轉換？

4. 對接外部系統做ETL時的痛點：

• 可以在其他系統（例如DataWorks、FunctionCompute）等中将日志導入進行規整後再導回日志服務，但在整個過程中因為要解決程式設計、配置、調試等方面的工作，相對要耗費不少功夫。

5. 花費大量時間在ETL上

以上隻是部分舉例，事實上，這些都是非常典型的ETL的問題。并且在業界，一種普遍的共識是大資料分析中大部分時間（有時達到80%）花費在了資料規整（Data Wangling、或者ETL）上，真正重要的分析在時間占比上反而并不高。

概述

我們希望提供一套簡單的（稍微配置一下）、可靠（性能、穩定性、擴充性）、一站式的（不引入額外資源、概念、技術）的方案來緩解在以上日志服務場景中的主要ETL相關的痛點。

我們首先提供指令行工具（通過日志服務 CLI）的方式的解決方案，可以看到，通過指令行工具+簡單配置檔案将源日志庫中日志經過處理後流出到另外一個logstore。與托管服務比起來，更加靈活、強大、可控性強，但需要您在特定Region部署運作環境。

從經濟角度出發，推薦将源logstore保留1-7天，臨時存儲，無索引，将目标logstore作為真正分析消費的logstore。

運作場景1：實時流式處理, 自動平衡與恢複

通過依賴日志服務的消費組，完成實時流式處理，并可以自動獲得負載均衡與斷點恢複功能，而這些都不需要程式設計和額外配置：

運作場景2：批處理曆史資料

通過相對直接的方式，并發、切分的方式，将特定時間段、分區的日志進行ETL處理：

使用場景1：自由編排

通過一個簡單的Python風格的配置檔案進行編排，一般情況下不需要寫代碼即可達到80%的ETL的需求和自由度：

提供内置的編排能力包括如下，并具備擴充能力：

• 分派轉換
• 串聯轉換
• 分裂事件
• 保留事件
• 丢棄事件
• 保留字段
• 丢棄字段
• 自動提取KV
• 重命名字段

這裡的配置檔案選擇Python，而不是其他如JSON、YAML、ini、XML等方式，主要是以下幾個原因：

1. 使用通用語言例如Python，比使用一套JSON、YMAL上的DSL（Domain Specific Language）要靈活、簡單、學習曲線平滑。
2. Python本身語言特性有利于學習和擴充，Python自身對于資料結構的靈活性和處理就很強（無論是tuple、dict、list、set、字元串）還是函數式計算（map、filter、reduce、labmda等）支援都是非常自然的。這就使得其做資料處理時，代碼簡單易讀。
3. Python擴充性和生态比較強大，可以借力豐富的Python庫做任何自由的ETL處理。預設任意的Python庫都可以無縫作為ETL的插件進行使用、Python的其他生态工具都可以支援ETL的編寫與調試等。
4. 性能上使用Pypy與多程序可以較好的解決Python的GIl與性能問題。

使用場景2：使用内置轉換子產品

日志服務CLI ETL功能提供了完整的内置的處理子產品，尤其對于正規表達式、KV、JSON、Lookup等支援靈活且完整。總體内置轉換子產品對正常ETL轉換支援度完整，可以覆寫總體80%的轉換需求：

• 設定列值(靜态/複制/UDF)：各種函數計算支援
• 正則提取列：正則的完整支援，包括動态提取字段名等
• CSV格式提取：CSV标準的支援
• 字典映射：直接字段映射
• 外部CSV多列映射：從外部CSV關聯對資料進行富化，支援寬比對等。
• 自動KV：自動提取KV，也支援自定義分隔符、auto-escape場景
• JSON自動展開：支援自動展開JSON内容，包括數組，支援展開過程的定制。
• JSON-JMES過濾：支援基于JMES的動态選擇與計算後再處理。
• 分裂事件(基于JSON數組或字元串)：基于字元串數組或JSON數組進行事件分裂
• 多列合并(基于JSON數組或字元串)：基于字元串數組或JSON數組進行多字段合并

使用場景3：擴充插件或UDF

理論上任意Python的庫都可以無縫在配置檔案中使用，與此同時，内置的子產品也提供了更加輕量級的細微的政策或者邏輯上的UDF支援：

編排級别擴充:

• 自定義條件轉換

内置函數擴充:

• 設定列值-動态值
• JSON自動展開格式

一個例子

這裡我們舉一個伺服器上多鐘複雜日志格式的混合通過syslog發送給日志服務後的ETL的例子：

部署安裝

推薦使用pypy3來安裝部署：

pypy3 -m pip insall aliyun-log-python-sdk>= 0.6.42 aliyun-log-cli           

編寫配置檔案

可以使用任何Python适配的編輯器（例如sublime、Pycharm、VIM等），推薦自帶Python插件的工具，這樣可以自動高亮代碼以及檢查文法錯誤。

# 丢棄所有無關的元字段，例如__tag:...___等
DROP_FIELDS_f1 = [F_TAGS, "uselss1", "useless2"]

# 分發：根據正規表達式規則，設定__topic__的值
DISPATCH_EVENT_data = [
    ({"data": "^LTE_Information .+"}, {"__topic__": "let_info"}),
    ({"data": "^Status,.+"}, {"__topic__": "machine_status"}),
    ({"data": "^System Reboot .+"}, {"__topic__": "reboot_event"}),
    ({"data": "^Provision Firmware Download start .+"}, {"__topic__": "download"}),
    (True, {"__topic__": "default"})]       # 不比對的預設__topic__值

# 轉換：根據特定__topic__使用特定正規表達式，對字段`data`進行字段提取
TRANSFORM_EVENT_data = [
    ({"__topic__": "let_info"}, ("data", r"LTE_Information (?P<RSPR>[^,]+),(?P<SINR>[^,]+),(?P<global_cell_id>[^,]+),")),
    ({"__topic__": "machine_status"}, ("data", r"Status,(?P<cpu_usage_usr>[\d\.]+)% usr (?P<cpu_usage_sys>[\d\.]+)% sys,(?P<memory_free>\d+)(?P<memory_free_unit>[a-zA-Z]+),")),
    ({"__topic__": "reboot_event"}, ("data", r"System Reboot \[(?P<reboot_code>\d+)\]")),
    ({"__topic__": "download"}, ("data", r"Provision Firmware Download start \[(?P<firmware_version>[\w\.]+)\]"))
    ]           

這裡雖然是Python檔案，但并沒有任何程式設計内容，但卻可以借助于Python的工具進行文法校驗。

運作程式

批量運作，這裡僅僅針對

shard 0

做一個2分鐘的資料ETL做一個檢驗：

aliyunlog log transform_data --config=./my_etl.py --project=p1 --logstore=abc --to_project=p2 --to_logstore=xyz --to_client=account1 --client-name=account2 --shard_list=0 --from_time="2019-1-15 12:59:00+8:00" --to_time="2019-1-15 13:01:00+8:00"           

驗證OK後，可以直接使用持續運作，額外增加一個參數

cg_name

即可（表示消費組名稱）：

aliyunlog log transform_data --config=./my_etl.py --project=p1 --logstore=abc --to_project=p2 --to_logstore=xyz --to_client=account1 --client-name=account2 --from_time="2019-1-15 12:59:00+8:00" --cg_name="elt1"           

進一步資料

• 日志服務CLI ETL - 介紹與場景
• 日志服務CLI ETL - 部署與管理
• 日志服務CLI ETL - 編排與轉換
• 日志服務CLI ETL - 擴充UDF

相關連結

• 日志服務SLS指令行工具（CLI）
• 依賴的子產品Python SDK
• Github上的ETL的配置代碼案例
• 掃碼加入官方釘釘群 (11775223):