全部產品
Search
文件中心

Simple Log Service:構建字典與表格做資料富化

更新時間:Dec 19, 2024

字典和表格是對資料進行富化時主要使用的兩種資料結構,本文檔主要介紹這兩種資料結構的常見構建方式,並對比不同構建方式的優缺點。

字典構建

  • 直接構建

    e_dict_map({"400": "error", "200": "ok", "*": "other"}, "status", "message")
  • 從任務配置資源構建

    e_dict_map(res_local("http_code_map"), "status", "message")

    其中http_code_map是任務進階配置項,值為:

    {"400": "error", "200": "ok", "*": "other"}
  • 從表格構建

    使用tab_to_dict從表格構建。而表格的構建參見本文後面的表格構建。

    e_dict_map(tab_to_dict(tab_parse_csv("status_code,status_info\n400,error\n200,ok\n*,other"), "status_code", "status_info"), "status", "message")
  • 從字典函數構建

    e_dict_map(dct_make("400", "error", "200",  "ok", "*",  "other"), "status", "message")
  • 從其他運算式構建

    e_dict_map(json_parse(v("http_code_map")), "status", "message")

    此處從源日誌的http_code_map欄位中擷取映射關係。

不同字典構建方式對比。

構建方式

優點

缺點

直接構建

直觀、簡單、方便。

如果內容較多,規則會相對冗長。且靜態不靈活。

從任務配置資源構建

內容較多且經常修改時推薦使用,易於維護。

不易於擴充和跨任務複用,不支援自動重新整理。

從表格構建

進階情境下使用,維護機制更靈活。

需要構建和維護對應的表格,過程相對繁瑣。

從字典函數構建

基於邏輯動態構建字典,特定情境下適用。

較為進階,不易於維護。

從其他運算式構建

從日誌事件的欄位中動態提取映射關係,特定情境下適用。

較為進階,不易於維護。

表格構建

  • 從文本構建

    e_table_map(tab_parse_csv("city,name,age\nshanghai,aliyun,10\ncity:nanjing,Maki,18"), "name",["city", "age"])
  • 從RDS資源中構建

    e_table_map(tab_parse_csv(res_rds_mysql(...database="db", table="city")), "name",["city", "age"])

    RDS表格city的內容為:

    content,name,age
    shanghai,aliyun,10
    nanjing,Maki,18
  • 從其他Logstore資源構建

    e_table_map(res_log_logstore_pull(..., project="project_name", logstore="logstore_name", fields=["city","name","age"]),, "name",["city", "age"])

    對應Logstore中日誌事件為:

    "日誌1"
    {
      "city": "shanghai",
      "name": "aliyun",
      "age": "10"
    }
    "日誌2"
    {
      "city": "city:nanjing and data > 100",
      "name": "Maki",
      "age": "18"
    }

不同表格構建方式對比:

構建方式

優點

缺點

從文本構建

直觀、簡單、方便。

如果內容較多,規則會相對冗長。不易於維護、擴充和複用。

從RDS資源構建

  • 內容較多且經常修改時推薦使用,易於維護。

  • 支援自動重新整理。

  • 支援跨任務複用。

需要串連外部RDS資源,配置過程相對比較繁瑣。

從其他Logstore資源構建

支援即時讀取,維護機制更靈活,進階情境下使用。

需要串連其他Logstore,配置過程相對比較繁瑣。