如何處理多個關聯的日誌消息？

Question

我有一個服務可以計算項目的一堆東西。用戶可以每天多次觸發該計算。每個計算都會產生一些有趣的指標（我們稱之爲A，B，C）。

我將這些指標報告給具有單獨日誌消息的日誌服務。日誌消息如下所示：

date | calculationID1 | projectID1 | metricA | valueA 
date | calculationID1 | projectID1 | metricB | valueB 
date | calculationID1 | projectID1 | metricC | valueC 
date | calculationID2 | projectID2 | metricA | valueA 
date | calculationID2 | projectID2 | metricB | valueB 
date | calculationID2 | projectID2 | metricC | valueC 
date | calculationID3 | projectID1 | metricA | valueA 
date | calculationID3 | projectID1 | metricB | valueB 
date | calculationID3 | projectID1 | metricC | valueC 

在此示例中，ID爲1的項目在該特定日期運行了兩次。在我的分析後端我有一個蜂巢集羣來分析這些數據，我想生成與上次報告指標表爲每個項目的某一天一天：

date | calculationID3 | projectID1 | valueA | valueB | valueC 
date | calculationID2 | projectID2 | valueA | valueB | valueC 

顯然，這種計算是非常昂貴的，因爲我做的很多連接。我的公司有嚴格的日誌記錄格式，這就是爲什麼我爲每個日誌消息創建一個值。我是否應該創建一條包含所有指標的日誌消息來緩解報告？

任何人都可以指出我對這些問題的最佳做法嗎？

Answer 1

如果我們使用DB，在SQL中支持PIVOT clause，那麼我們可以使用以下查詢從日誌報告中收集數據。

無需PIVOT即可獲取相同的結果，但另一種方式需要大量的複製粘貼和雜耍，並且由於您的帳號是"pragmatic with implementation"，所以我想我們不需要談論那些骯髒的東西。

要看看發生了什麼在查詢中，你可以做3個步驟：

• 運行查詢，而不PIVOT（只是刪除PIVOT關鍵字和其他代碼）
• 然後運行它是
• 比較第一和第二步驟的結果，識別如何行被轉置到列

---

個

WITH 
    data_table (stamp, calculation_ID, project_ID, metric_name, metric_value) as (select 

     timestamp '2015-01-01 00:00:01', 'calc_ID_1', 'project_WHITE', 'metric_A', 11 from dual union all select 
     timestamp '2015-01-01 00:00:02', 'calc_ID_1', 'project_WHITE', 'metric_B', 21 from dual union all select 
     timestamp '2015-01-01 00:00:03', 'calc_ID_1', 'project_WHITE', 'metric_C', 31 from dual union all select 
     timestamp '2015-01-01 00:01:04', 'calc_ID_2', 'project_WHITE', 'metric_A', 12 from dual union all select 
     timestamp '2015-01-01 00:01:05', 'calc_ID_2', 'project_WHITE', 'metric_B', 22 from dual union all select 
     timestamp '2015-01-01 00:01:06', 'calc_ID_2', 'project_WHITE', 'metric_C', 32 from dual union all select 

     timestamp '2015-01-01 00:00:11', 'calc_ID_3', 'project_BLACK', 'metric_A', 41 from dual union all select 
     timestamp '2015-01-01 00:00:12', 'calc_ID_3', 'project_BLACK', 'metric_B', 51 from dual union all select 
     timestamp '2015-01-01 00:00:13', 'calc_ID_3', 'project_BLACK', 'metric_C', 61 from dual union all select 
     timestamp '2015-01-01 00:01:14', 'calc_ID_4', 'project_BLACK', 'metric_A', 42 from dual union all select 
     timestamp '2015-01-01 00:01:15', 'calc_ID_4', 'project_BLACK', 'metric_B', 52 from dual union all select 
     timestamp '2015-01-01 00:01:16', 'calc_ID_4', 'project_BLACK', 'metric_C', 62 from dual  
) 
SELECT * 
    FROM (
     select trunc(stamp) AS day, 
      calculation_id, 
      project_id, 
      metric_name, 
      metric_value 
     from (
     select t.*, 
       rank() OVER (PARTITION BY project_ID, metric_name, trunc(stamp) ORDER BY stamp DESC) calculation_rank 
     from data_table t 
     -- take only the last log row for (project_ID, metric_name) for every given day 
    ) where calculation_rank = 1 
) 
PIVOT (
    -- aggregate function is required here, 
    -- and SUM can be replaced with something more relevant to custom logic 
    SUM(metric_value) 
    FOR 
    metric_name IN ('metric_A' AS "Metric A", 
        'metric_B' AS "Metric B", 
        'metric_C' AS "Metric C") 
); 

結果：

DAY  | CALCULATION_ID | PROJECT_ID | Metric A | Metric B | Metric C 
------------------------------------------------------------------------------ 
2015-01-01 | calc_ID_4  | project_BLACK | 42  | 52  | 62 
2015-01-01 | calc_ID_2  | project_WHITE | 12  | 22  | 32 

在此查詢calculation_ID是多餘的（I僅將它用於使例如用於讀碼器更清晰）。但是，您仍然可以應用此信息來檢查日誌記錄數據格式的完整性，並探究是否相同calculation_ID對應於同一組/時間段中涉及的度量標準。