遇到了點取樣的問題，發現取樣的文件很少，示例也很少，翻譯下，順便理解下配置。

Downsampling（降取樣）

Downsampling是降低資料取樣率或解析度的過程。例如，假設溫度感測器每秒向OpenTSDB系統傳送資料。如果使用者在一小時的時間跨度內查詢資料，他們將收到3,600個數據點，這些資料點可以很容易地繪製出來。但是現在，如果使用者要求整整一週的資料，他們將收到604,800個數據點，這樣圖形可能變得非常混亂。使用Downsampling（降取樣），把單位時間範圍內的多個數據點經過數學函式運算，聚合成一個時間戳對齊的值。這樣可以減少從604,800到168的值的數量。

Downsampling（降取樣）至少需要兩個引數：

時間間隔Interval - 也就是一個時間範圍。例如，我們可以聚合1分鐘或1小時甚至一整天內的多個值。時間間隔Interval的書寫格式為指定，如1h代表1小時，30分鐘寫成30m。從2.3開始，all也作為一個時間間隔出現，可用於將時間範圍內的所有結果取樣到一個值。例如，如果downsample設定為0all-sum將從查詢開始到結束的所有值相加sum。請注意，仍然需要有個數值，但它可以是零或任何其他值。

聚合函式Aggregation Function - 一個合併時間間隔中的所有值的數學函式。用的是聚合函式文件中的聚合函式，參見連結。

例如，如果有以下時間序列A和B。資料覆蓋70秒的時間範圍，每10秒鐘一次。假設我們想要縮短取樣到30秒，因為使用者正在檢視更長時間跨度的圖表。另外，我們使用sum聚合器將這兩個系列分組為一個。我們可以指定一個降取樣器30s-sum，它將建立30秒的儲存bucket,並對每個儲存bucket中的所有資料點求和。這將為每個系列提供三個資料點：

對於每個時間序列，生成一個合成的時間序列，其時間戳在區間邊界上標準化（每30秒），這樣得到一個值t0，t0+30s和t0+60s。每個間隔或儲存bucket將包含儲存bucket時間戳（開始）的資料點，並且不包括儲存bucket的結束時間戳。在這種情況下，第一個bucket將從延伸t0到t0+29.9999s。使用提供的聚合器，所有值都合併為一個新值。最後，使用sum對查詢進行分組，以便合成時間序列。

**注意：**對於早期版本的OpenTSDB，取樣後的資料點的時間戳是時間跨度中每個資料點的時間戳的平均值。從2.1及更高版本開始，取樣後的資料點的時間戳計算方式發生變化，是基於時間間隔、當前時間和當前時間與時間間隔的模計算出的一個值，下面會說。

Java程式碼表示為timestamp - (timestamp % interval_ms)。例如，給定時間戳為1388550980000或者1/1/2014 04:36:20 UTC ，時間隔為1小時或者3600000毫秒，生成的時間戳將四捨五入為1388548800000。所有4到5 點之間的所有資料點將在4 點的bucket中。如果時間間隔為1小時，查詢一天的資料的取樣，將收到24個數據點（假設所有24小時都有資料）。

使用0all-時間間隔時時，結果的時間戳將是查詢的開始時間。

這種時間戳規範化對於常見的查詢非常有效，例如將一天的資料按1分鐘或1小時取樣。但是，如果在奇怪的間隔（例如36分鐘）下采樣，則由於模數計算的性質，時間戳可能看起來有點奇怪。給定36分鐘的間隔和上面的示例，間隔將是2160000毫秒，結果時間戳1388549520或04:12:00 UTC。04:12到04:48之間的所有資料點會在同一個bucket中。

日曆邊界Calendar Boundaries
從OpenTSDB 2.3開始，使用者可以指定基於日曆的下采樣而不是快速模數方法（上面是快速模數法）。這對於報告目的更有用，例如檢視與人類相關的時間值，例如月報，周寶或日報。此外，下采樣可以考慮時區，並結合夏令時時移和區域偏移。

要使用日曆邊界Calendar Boundaries，請檢視使用方式及版本（API的話檢視API文件）的文件。例如，V2 URI方式具有要有特定時區引數，引數示例為&timezone=Asia/Kabul，基於日曆的downsampling取樣通過將c加在時間間隔來啟用，如&m=sum:1dc-sum:my.metric。對於JSON查詢，在JSON的頂層使用單獨的欄位timezone以及useCalendar布林標誌來啟用日曆邊界。如果未提供時區，則日曆使用UTC時間。

使用日曆降取樣時，第一個間隔將從查詢的那年的一月一日0點開始。從此開始，計算間隔bucket直到查詢結束。每個儲存bucket都標有儲存桶開頭的時間戳（包括），幷包括直到下一個儲存bucket開始的所有值(不包括)。

補齊政策
降取樣downsampling通常用於對齊時間戳，以避免在執行分組時進行插值。由於OpenTSDB不對時間對齊施加約束，本來認為應該有的值，可能也沒有，因此必須在查詢時需要作此類約束。使用downsampling降取樣執行分組聚合時，如果所有序列都缺少預期間隔的值，則不會發出任何內容。例如，如果一個系列的寫入資料從每分鐘t0到t0+6m，但由於某種原因源未能在t0+3m寫入資料，只有5個值將被序列化時，然而使用者期望的是6個點。2.2及更高版本的補齊策略中，可以選擇t0+3m的值，以便使用者（或應用程式）看到特定時間戳缺少值，而不必使用者去確定缺少哪個時間戳。只要下采樣bucket為空，填充策略就會發出預定義的值。

可用的政策包括：

• None（none） - 預設行為，在序列化期間不輸出缺失值，在聚合序列時執行線性插值（或以其他方式指定插值）的。
• NaN（nan） - 當序列中缺少所有值時，在序列化輸出中輸出NaN 。缺少值時跳過聚合中的NaN，而不是將整個分組計算轉換為NaN（參見下表）。
• Null（null） - 與NaN的行為相同，只是在序列化期間它會發出一個null，而不是一個NaN。
• 零（zero） - 缺少時間戳時替換為零。零值將合併到彙總結果中。

要使用填充策略，將策略名稱（括號中的術語）附加到由連字元分隔的降取樣聚合函式的末尾。例如1h-sum-nan或1m-avg-zero。

在此示例中，我們每隔10秒報告一次資料，並且我們希望通過每10秒進行一次下采樣並使用NaN通過10s-sum-nan以下方式填充缺失值來強制執行10秒的查詢時策略：

在沒有填充策略的情況下輸出，則在t0+20s和t0+40s將不會有任何值或時間戳。另外，B的t0+30s和t0+50s將通過線性插值的方式來填充，最終與A的值相加。