字典和表格是對資料進行富化時主要使用的兩種資料結構,本文檔主要介紹這兩種資料結構的常見構建方式,並對比不同構建方式的優缺點。
字典構建
直接構建
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,配置過程相對比較繁瑣。 |