非時間序列數據的德魯伊

對於daya在生成時立即發送給德魯伊的情況，一切都很好（如在IoT中）。愛它。非時間序列數據的德魯伊

但現在我有不同的情況，源於後期的數據輸入。

最終用戶可以脫機（失去互聯網連接），數據存儲在她的手機中，並且只有在她重新聯機後纔會發送給德魯伊。這意味着，當她恢復互聯網時，發送給Druid的數據（例如通過Tranquility服務器）將被Druid拒絕（因爲Druid實時不接受過去的數據）。

當然，我可以設置時間戳到數據發送到服務器的時間。但是這會歪曲報告...，除非......，如果我添加另一個字段（比如說：generated_ts），並將其聲明爲另一個維度。

但是，我不會從你在德魯伊（？）免費獲得的基於時間的自動回捲中受益。我將不得不使用GROUPBY（與generated_ts作爲一個維度），像這樣：

{ 
    "queryType": "groupBy", 
    "dataSource": "my_datasource", 
    "granularity": "none", 
    "dimensions": [ 
    "city", 
    { 
     "type" : "extraction", 
     "dimension" : "generated_ts", 
     "outputName" : "dayOfWeek", 
     "extractionFn" : { 
     "type" : "timeFormat", 
     "format" : "EEEE" 
     } 
    } 
    ], 
    ... 
}

我的問題是：

是該方法是否有效？
如果是：懲罰是什麼？（？我想這將是性能，而是如何壞）

感謝，拉嘎

以下回應Ramkumar的反應，後續問題：

我仍然不太瞭解這批批次的攝取：

讓我們假設事件A.它在時間戳3生成，直到時間戳15才被髮送到服務器。

而當它在時間戳15的報表格式，它有這個值：{TS：15，generated_ts：3，metric1：12，DIMENSION1： 'A'}

他們時間戳鍵值爲「TS」。

這是不準確的，理想是{ts：3，generated_ts：3，metric1：12，dimension1：'a'}，但我必須指定15作爲inserted_ts，以便Tranquility接受它。

現在，在批次攝取期間，我想修復它，現在它有正確的ts {ts：3，generated_ts：3，metric1：12，dimension1：'a'}。

問題：我會有重複的事件嗎？

或...（這個我懷疑）：批量攝取一個指定的時間間隔基本上會替換該間隔內的所有數據？（我希望是這樣的話，那麼我可以不用擔心數據重複）

附加說明（只是）：我碰到這樣的：https://github.com/druid-io/tranquility/blob/master/docs/overview.md#segment-granularity-and-window-period

，上面寫着：

我們的方法Metamarkets將通過Tranquility實時發送所有數據，同時通過在S3中存儲副本並跟進夜間Hadoop批量索引作業以重新提取數據來緩解這些風險。這讓我們可以保證，最終，每個事件在德魯伊中都只有一次表示。

所以...這是一個重新攝取，其含義（我猜）是一個完全替代，對吧？

來源

2016-10-12 Cokorda Raka

你的方法是有效的，但正如你所說，在涉及的延遲方面肯定會有成本。雖然德魯伊使用緩存，但它仍然沒有本地彙總那麼高效。我們遇到了類似的問題，我們的解決方案是使用批量攝入來修復後期數據。雖然不夠高雅，但它是我們能想到的最好的。 –

我還是不太明白這批批次的攝入量。上面的問題（在最後的原文中）。 –

這將是所有細分的完全替代，不會有任何重複。我可能會解釋我們作爲一個單獨的答案做什麼，看看它是否能幫助你。 –

我們遇到了類似的問題，我們使用lambda體系結構解決了它。在我們的設置中，我們有2個管道：

我們的實時管道從Kafka + Spark中提取並攝入到德魯伊中。這將成爲實時數據。雖然比德魯伊期望的粒度更早的數據將被拒絕。所以這對遲到的數據到達有數據丟失。
我們的批處理管道會每隔一小時將數據接收到Hadoop中，然後我們會觸發一個批處理接收作業到德魯伊。這將爲密鑰中提到的時間戳創建分段，執行聚合並用相同的時間戳替換舊分段。實際上，德魯伊的存儲原則基於不變性，MVCC和日誌結構存儲。所以當新版本的細分市場出現相同的時間戳時，舊的細分市場會被垃圾收集。

在批攝取更多細節：我們的批處理作業從HDFS，其被組織成文件夾每小時運行數據。我們得到的任何遲到事件都會被放入正確的小時桶中。我們對後期數據的SLA有XXX小時（如果您已閱讀great article，則稱爲水印）。因此，我們採取當前小時，減去XXX並採取相應的每小時文件夾文件，並在該特定小時觸發德魯伊的批量攝取作業。請注意，如果事件在水印之前到達，這仍然會導致數據丟失，但是我們需要做出妥協，因爲德魯伊不支持在特定小時內對分段進行就地更新，並且我們也不能有任意長的水印，因爲我們的HDFS端的存儲非常有限。

來源

2016-10-14 07:00:44

感謝所有的答案和指針！因此，完整的解決方案需要外部任務調度程序，對吧？我正在考慮RunDeck。 –

非時間序列數據的德魯伊

回答

相關問題