建立資料模型 - Amazon Timestream

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

建立資料模型

的 Amazon Timestream LiveAnalytics 旨在收集、存放和分析來自應用程式和裝置的時間序列資料,以時間戳記發出一系列資料。為了獲得最佳效能,傳送至 Timestream for 的資料 LiveAnalytics 必須具有時間特性,且時間必須是資料的基本元件。

的 Timestream LiveAnalytics 可讓您靈活地以不同的方式建立資料模型,以符合應用程式的需求。在本節中,我們涵蓋了多種模式,並提供指導方針以最佳化成本和效能。熟悉關鍵的 Timestream,了解維度和指標等 LiveAnalytics 概念。在本節中,您將進一步了解:

決定建立單一資料表或多個資料表來存放資料時,請考慮下列事項:

  • 當您想要在多個資料表和資料庫之間分隔資料時,要放在相同資料表中的資料。

  • 如何在 Timestream 之間選擇 LiveAnalytics 多重測量記錄與單一測量記錄,以及使用多重測量記錄建立模型的優點,特別是當您的應用程式同時追蹤多個測量時。

  • 要建模為維度或量值的屬性。

  • 如何有效地使用量值名稱屬性來最佳化查詢延遲。

單一資料表與多個資料表

當您在應用程式中建立資料模型時,另一個重要的層面是如何將資料模型化為資料表和資料庫。Timestream for 中的資料庫和資料表 LiveAnalytics 是存取控制的抽象,指定KMS金鑰、保留期間等。的 LiveAnalytics Timestream 會自動分割您的資料,旨在擴展資源以符合應用程式的擷取、儲存和查詢載入和需求。

的 Timestream 中的資料表 LiveAnalytics 可以擴展到儲存的 PB 資料、數十 GB/秒的資料寫入,而查詢可以TBs每小時處理數百個。的 Timestream 中的查詢 LiveAnalytics 可以跨越多個資料表和資料庫,提供聯結和聯集,以跨多個資料表和資料庫無縫存取您的資料。因此,決定如何在 Timestream 中組織資料時,資料或請求磁碟區規模通常不是主要考量 LiveAnalytics。以下是決定要在相同資料表中與不同資料表中或不同資料庫中的資料表中共同放置哪些資料時的一些重要考量。

  • 資料表的精細程度支援資料保留政策 (記憶體存放區保留、磁性存放區保留等)。因此,需要不同保留政策的資料必須位於不同的資料表中。

  • AWS KMS 用於加密資料的金鑰是在資料庫層級設定。因此,不同的加密金鑰需求表示資料將需要位於不同的資料庫中。

  • 的 Timestream LiveAnalytics 支援以資料表和資料庫精細程度進行資源型存取控制。在決定寫入至相同資料表與不同資料表的資料時,請考慮您的存取控制需求。

  • 在決定要存放在哪個資料表中的資料時,請注意維度、測量名稱和多測量屬性名稱的限制

  • 在決定如何組織資料時,請考慮您的查詢工作負載和存取模式,因為查詢延遲和撰寫查詢的便利性取決於此。

    • 如果您將經常查詢的資料存放在相同的資料表中,這通常會簡化您撰寫查詢的方式,因此您通常可以避免撰寫聯結、聯集或常見的資料表表達式。這通常也會降低查詢延遲。您可以在維度和量值名稱上使用述詞,以篩選與查詢相關的資料。

      例如,請考慮一個案例,您存放來自位於六大洲之裝置的資料。如果您的查詢經常從各洲存取資料,以取得全域彙總檢視,則將來自這些洲的資料儲存在同一個資料表中將更容易寫入查詢。另一方面,如果您將資料存放在不同的資料表上,您仍然可以在相同的查詢中結合資料,但是,您需要撰寫查詢,以將資料從跨資料表聯集起來。

    • 的 Timestream LiveAnalytics 會在您的資料上使用自適應分割和索引。因此,查詢只會針對與您的查詢相關的資料收取費用。例如,如果您有資料表存放六大洲上百萬部裝置的資料,如果您的查詢具有 或 WHERE device_id = 'abcdef' 的述詞WHERE continent = 'North America',則查詢只會針對裝置或 大洲的資料收取費用。

    • 在可能的情況下,如果您使用量值名稱來分隔相同資料表中未同時發出或未經常提出查詢的資料,則使用查詢WHERE measure_name = 'cpu'中的述詞,例如 不僅可以獲得計量優勢, 的 Timestream LiveAnalytics 也可以有效地消除沒有查詢述詞中使用的量值名稱的分割區。這可讓您將具有不同度量名稱的相關資料存放在相同資料表中,而不會影響查詢延遲或成本,並避免將資料分散到多個資料表。量值名稱基本上用於分割資料和剪除與查詢無關的分割區。

多重測量記錄與單一測量記錄

的 Timestream LiveAnalytics 可讓您寫入資料,每個記錄包含多個量值 (多量值) 或每個記錄包含單一量值 (單一量值)。

多度量記錄

在許多使用案例中,您正在追蹤的裝置或應用程式可能會在同一時間戳記發出多個指標或事件。在這種情況下,您可以將以相同時間戳記發出的所有指標存放在相同的多測量記錄中。也就是說,儲存在相同多測量記錄中的所有量值,都會在相同資料列中顯示為不同的資料欄。

例如,請考慮您的應用程式正在從同時即時測量的裝置發出指標,例如 cpu、記憶體、disk_iops。以下是此類資料表的範例,其中同時發出多個指標會立即儲存在相同的資料列中。您將看到兩個主機每秒發出一次指標。

Hostname (主機名稱) measure_name 時間 cpu 記憶體 disk_iops
host-24Gju 指標 2021-12-01 19:00:00 35 54.9 38.2
host-24Gju 指標 2021-12-01 19:00:01 36 58 39
host-28Gju 指標 2021-12-01 19:00:00 15 55 92
host-28Gju 指標 2021-12-01 19:00:01 16 50 40

單一測量記錄

當您的裝置在不同時段發出不同的指標,或是您使用發出metrics/events at different time periods (for instance, when a device's reading/state變更的自訂處理邏輯時,單一量值記錄就很適合。) 由於每個量值都有唯一的時間戳記,因此可以在 Timestream 中將量值存放在自己的記錄中 LiveAnalytics。例如,請考慮 IoT 感應器,其會追蹤土壤溫度和濕度,只有在偵測到先前回報項目的變更時才會發出記錄。下列範例提供使用單一量值記錄發出此類資料的範例。

device_id measure_name 時間 measure_value::double measure_value::bigint
sensor-sea478 溫度 2021-12-01 19:22:32 35 NULL
sensor-sea478 溫度 2021-12-01 18:07:51 36 NULL
sensor-sea478 濕度 2021-12-01 19:05:30 NULL 21
sensor-sea478 濕度 2021-12-01 19:00:01 NULL 23

比較單一量值和多量值記錄

的 Timestream LiveAnalytics 可讓您靈活地根據應用程式的需求和特性,將資料建模為單一量值或多量值記錄。如果您的應用程式需求需要,單一資料表可以同時存放單一量值和多量值記錄。一般而言,當您的應用程式同時發出多個量值/事件時,通常建議將資料建模為多量值記錄,以用於效能資料存取和符合成本效益的資料儲存。

例如,如果您考慮DevOps 使用案例追蹤指標和來自數十萬伺服器的事件,每個伺服器會定期發出 20 個指標和 5 個事件,其中事件和指標會同時即時發出。該資料可以使用單一量值記錄或使用多量值記錄建立模型 (如需產生的結構描述,請參閱開放原始碼資料產生器)。在此使用案例中,使用多量值記錄與單一量值記錄建立資料的模型,會導致:

  • 擷取計量 - 多度量記錄會導致寫入的擷取位元組減少約 40%

  • 擷取批次處理 - 多度量記錄會導致傳送的資料批次較大,這表示用戶端需要較少的執行緒和較少的執行緒CPU來處理擷取。

  • 儲存計量 - 多度量記錄可降低約 8X的儲存,大幅節省記憶體和磁性儲存體的儲存。

  • 查詢延遲 - 與單一測量記錄相比,多測量記錄會導致大多數查詢類型的查詢延遲較低。

  • 查詢計量位元組 - 對於掃描小於 10MB 資料的查詢,單一量值和多量值記錄都是相當的。對於存取單一量值和掃描 > 10MB 資料的查詢,單一量值記錄通常會產生較低的位元組計量。對於參考 3 個或更多量值的查詢,多量值記錄會產生較低的位元組計量。

  • 易於表達多測量查詢 - 當您的查詢參考多個測量時,使用多測量記錄建立資料模型會更容易撰寫更精簡的查詢。

先前的因素會因您追蹤的指標數量、資料擁有的維度等而異。雖然上述範例提供一些具體資料作為一個範例,但我們在許多應用程式案例和使用案例中看到,如果應用程式同時發出多個量值,則將資料儲存為多量值記錄會更有效率。此外,多度量記錄可為您提供資料類型的彈性,並將多個其他值儲存為內容 (例如,儲存請求 IDs和其他時間戳記,稍後會討論)。

請注意,多度量記錄也可以建立稀疏度量的模型,例如用於單一度量記錄的先前範例:您可以使用 measure_name 來存放度量的名稱,並使用一般多度量屬性名稱,例如 value_double to store DOUBLE measures、value_bigint to store BIGINT measures、value_timestamp 來存放其他TIMESTAMP值等。

維度和量值

Timestream for 中的資料表 LiveAnalytics 可讓您存放維度 (識別您要存放之裝置/資料的屬性) 和值 (您正在追蹤的指標/值),如需更多詳細資訊,請參閱 Timestream 中的 LiveAnalytics 概念。當您在 Timestream 上建立應用程式模型時 LiveAnalytics,將資料映射到維度和指標的方式會影響您的擷取和查詢延遲。以下是如何將資料建模為適用於使用案例的維度和指標的指導方針。

選擇維度

識別傳送時間序列資料之來源的資料是維度的自然擬合,這些維度是不會隨時間變更的屬性。例如,如果您有伺服器發出指標,則識別伺服器的屬性,例如主機名稱、區域、機架、可用區域,是維度的候選項目。同樣地,對於具有多個感應器回報時間序列資料的 IoT 裝置,裝置 ID、感應器 ID 等適合維度。

如果您要將資料寫入為多度量記錄,當您在資料表上執行 DESCRIBE或執行SELECT陳述式時,維度和多度量屬性會在資料表中顯示為資料欄。因此,撰寫查詢時,您可以自由地在相同的查詢中使用維度和量值。不過,當您建構寫入記錄以擷取資料時,當您選擇哪些屬性指定為維度,以及哪些屬性為測量值時,請記住下列事項:

  • 維度名稱、值、量值名稱和時間戳記可唯一識別時間序列資料。的 Timestream LiveAnalytics 使用此唯一識別符自動刪除重複資料。也就是說,如果 的 Timestream LiveAnalytics 接收到兩個具有相同維度名稱、維度值、量值名稱和時間戳記值的資料點,則如果值具有相同的版本編號,則表示重複資料刪除的 LiveAnalytics Timestream。如果新的寫入請求的版本低於 Timestream 中已存在的資料 LiveAnalytics,則會拒絕寫入請求。如果新的寫入請求有較高的版本,則新值會覆寫舊值。因此,您選擇維度值的方式會影響此重複資料刪除行為。

  • 維度名稱和值無法更新,測量值可以是。因此,任何可能需要更新的資料,都會以更好的模型做為測量值。例如,如果您的機器位於工廠現場,其顏色可以變更,您可以建立顏色模型做為測量值,除非您想要使用顏色來識別重複資料刪除所需的屬性。也就是說,測量值可用來存放屬性,這些屬性只會隨著時間緩慢變更。

請注意, 的 Timestream 中的資料表 LiveAnalytics 不會限制維度名稱和值的唯一組合數量。例如,您可以在資料表中存放數十億個這類唯一值組合。不過,如以下範例所示,仔細選擇維度和量值可以大幅最佳化您的請求延遲,尤其是查詢。

維度IDs唯一

如果您的應用程式案例需要您為每個資料點存放唯一識別符 (例如請求 ID、交易 ID 或關聯 ID),則將 ID 屬性建模為測量值將可大幅改善查詢延遲。使用多度量記錄建立資料模型時,ID 會顯示在您其他維度和時間序列資料的上下文中,以便您的查詢可以繼續使用它們。例如,考慮DevOps 使用案例,其中伺服器發出的每個資料點都有唯一的請求 ID 屬性,將請求 ID 建模為測量值會導致不同查詢類型的查詢延遲降低高達 4 倍,而不是將唯一請求 ID 建模為維度。

您可以針對不是每個資料點完全唯一的屬性使用類似的比喻,但具有數十萬或數百萬個唯一值。您可以將這些屬性建模為維度或量值。如果值是先前討論的在寫入路徑上刪除重複的必要值,或者您經常在查詢中使用它做為述詞 (例如,在 WHERE子句中,具有該屬性值的等式述詞,例如您的應用程式正在追蹤數百萬個裝置device_id = ‘abcde’的位置),則您想要將其建模為維度。

具有多度量記錄的資料類型的豐富度

多測量記錄可讓您靈活地有效地建立資料模型。您在多度量記錄中存放的資料在表格中顯示為類似於維度的資料欄,因此提供相同的查詢維度和度量值的便利性。您在前面討論的範例中看到其中一些模式。您可以在下方找到其他模式,以有效使用多度量記錄來滿足應用程式的使用案例。

多度量記錄支援資料類型 DOUBLEBIGINTBOOLEANVARCHAR和 的屬性TIMESTAMP。因此,它們自然適合不同類型的屬性:

  • 位置資訊:例如,如果您想要追蹤位置 (以緯度和經度表示),則將其建模為多度量屬性將會導致查詢延遲低於將它們儲存為VARCHAR維度,特別是當您在緯度和經度上具有述詞時。

  • 記錄中的多個時間戳記:如果您的應用程式案例要求您追蹤時間序列記錄的多個時間戳記,您可以將它們建模為多量值記錄中的其他屬性。此模式可用來存放具有未來時間戳記或過去時間戳記的資料。請注意,每個記錄仍會使用時間欄中的時間戳記來分割、索引和唯一識別記錄。

特別是,如果您在查詢中具有述詞的數值資料或時間戳記,則將這些屬性建模為多測量屬性,而不是維度,將導致較低的查詢延遲。這是因為當您使用多測量記錄支援的豐富資料類型來建立此類資料的模型時,如果您將此類資料建模為維度,您可以使用原生資料類型來表達述詞,而不是將值從 轉換為VARCHAR其他資料類型。

將量值名稱與多量值記錄搭配使用

Timestream 中的資料表 LiveAnalytics 支援稱為量值名稱的特殊屬性 (或資料欄)。您可以為寫入 Timestream 的每個記錄指定此屬性的值 LiveAnalytics。對於單一量值記錄,使用指標的名稱 (例如 cpu、伺服器指標的記憶體或溫度、感應器指標的壓力) 是很自然的。使用多測量記錄時,由於多測量記錄中的屬性已命名 (且這些名稱會成為資料表中的資料欄名稱),Cpu、記憶體或溫度時,壓力可能會成為多測量屬性名稱。因此,自然問題是如何有效地使用量值名稱。

的 Timestream LiveAnalytics 使用量值名稱屬性中的值來分割和索引資料。因此,如果資料表有多個不同的測量名稱,而且如果查詢使用這些值做為查詢述詞,則 的 Timestream LiveAnalytics 可以使用其自訂分割和索引來刪除與查詢無關的資料。例如,如果您的資料表具有 cpu 和記憶體測量名稱,且您的查詢具有述詞 WHERE measure_name = 'cpu',則 的 Timestream LiveAnalytics 可以有效地為與查詢無關的測量名稱剪除資料,例如,此範例中具有測量名稱記憶體的資料列。即使將量值名稱與多量值記錄搭配使用,此剪除也適用。您可以有效地使用量值名稱屬性做為資料表的分割屬性。測量名稱以及維度名稱和值,以及用於分割 LiveAnalytics 資料表時間串流中資料的時間。請注意 LiveAnalytics 資料表的 Timestream 中允許的唯一量值名稱數量限制。另請注意,測量名稱也與測量值資料類型相關聯,例如,單一測量名稱只能與一種類型的測量值相關聯。該類型可以是 DOUBLEBIGINTVARCHARBOOLEAN和 之一MULTI。以量值名稱存放的多量值記錄,其資料類型為 MULTI。由於單一多度量記錄可以存放具有不同資料類型 (DOUBLEBIGINTVARCHAR、 和 TIMESTAMP) 的多個指標BOOLEAN,因此您可以在多度量記錄中將不同類型的資料建立關聯。

下列各節說明幾個不同的範例,說明如何有效地使用量值名稱屬性來將相同資料表中的不同資料類型分組。

IoT 感應器報告品質和價值

假設您有一個來自 IoT 感應器的應用程式監控資料。每個感應器都會追蹤不同的測量,例如溫度、壓力。除了實際值之外,感應器還會報告測量的品質,這是測量讀數有多準確,以及測量單位。由於品質、單位和值會一起發出,因此它們可以建模為多度量記錄,如以下範例資料所示,其中 device_id 是維度、品質、值和單位是多度量屬性:

device_id measure_name 時間 品質 Value 單位
sensor-sea478 溫度 2021-12-01 19:22:32 92 35 c
sensor-sea478 溫度 2021-12-01 18:07:51 93 34 c
sensor-sea478 pressure 2021-12-01 19:05:30 98 31 psi
sensor-sea478 pressure 2021-12-01 19:00:01 24 132 psi

此方法可讓您使用量值名稱,結合多度量記錄的優點,以及分割和刪除資料。如果查詢參考單一量值,例如溫度,您可以在查詢中包含量值名稱述詞。以下是這類查詢的範例,該查詢也會針對品質高於 90 的測量,投影單位。

SELECT device_id, time, value AS temperature, unit FROM db.table WHERE time > ago(1h) AND measure_name = 'temperature' AND quality > 90

在查詢上使用 measure_name 述詞,可讓 的 Timestream LiveAnalytics 有效地剪除與查詢無關的分割區和資料,從而改善您的查詢延遲。

如果在同一時間戳發出所有指標和/或在同一查詢中同時查詢多個指標,也可以將所有指標存放在相同的多測量記錄中。例如,您可以建構為多度量記錄,其中含有屬性 temperature_quality、perme_value、perity_unit、 pressure_quality、 pressure_value、 pressure_unit 等。先前討論使用單一量值與多量值記錄建立資料模型的許多要點,都適用於您如何建立資料模型的決定。請考慮您的查詢存取模式,以及您的資料如何產生,以選擇可最佳化成本、擷取和查詢延遲的模型,以及撰寫查詢的便利性。

相同資料表中的不同類型的指標

另一個您可以結合多度量記錄與量值名稱值的使用案例,是建立從相同裝置獨立發出的不同資料類型的模型。請考慮 DevOps 監控使用案例伺服器會發出兩種類型的資料:定期發出指標和不規則事件。此方法的範例是資料產生器建模 DevOps 使用案例中所討論的結構描述。在這種情況下,您可以使用不同的量值名稱,將從相同伺服器發出的不同資料類型存放在相同資料表中。例如,同時發出的所有指標都會與量值名稱指標一起存放。所有在與指標不同時間即時發出的事件,都會與量值名稱事件一起存放。資料表的量值結構描述 (例如SHOW MEASURES查詢的輸出) 為:

measure_name data_type 維度
事件 多重 {"data_type":"varchar","dimension_name":"availability_zone"},{"data_type":"varchar","dimension_name":"microservice_name"},{"data_type":"varchar","dimension_name":"instance_name"},{"data_type":"varchar","dimension_name":"process_name"},{"data_type":"varchar","dimension_name":"jdk_version"},{"data_type":"varchar","dimension_name":"
指標 多重 {"data_type":"varchar","dimension_name":"availability_zone"},{"data_type":"varchar","dimension_name":"microservice_name"},{"data_type":"varchar","dimension_name":"instance_name"},{"data_type":"varchar","dimension_name":"os_version"},{"data_type":"varchar","dimension_name":"cell"},{"data_type":"varchar","dimension_name"":"

在這種情況下,您可以看到事件和指標也有不同的維度集,其中事件具有不同的維度 jdk_version 和 process_name,而指標具有維度 instance_type 和 os_version。

使用不同的量值名稱可讓您使用述詞撰寫查詢WHERE measure_name = 'metrics',例如只取得指標。此外,在相同資料表中擁有從相同執行個體發出的所有資料,表示您也可以使用 instance_name 述詞撰寫更簡單的查詢,以取得該執行個體的所有資料。例如,WHERE instance_name = ‘instance-1234’沒有 measure_name 述詞的表單述詞會傳回特定伺服器執行個體的所有資料。

分割多度量記錄的建議

重要

本節已棄用!

這些建議已過期。現在可以使用客戶定義的分割區索引鍵更好地控制分割區

我們看到時間序列生態系統中越來越多的工作負載需要擷取和存放大量資料,同時在透過高基數維度集存取資料時需要低延遲查詢回應。

由於這類特性,本節中的建議對於具有下列項目的客戶工作負載很有用。

  • 已採用或想要採用多度量記錄。

  • 預期有大量資料進入系統,而這些資料將長期存放。

  • 主要存取 (查詢) 模式需要低延遲回應時間。

  • 知道最重要的查詢模式涉及述詞中某種篩選條件。此篩選條件是以高基數維度為基礎。例如,考慮事件或彙總依據 UserId DeviceId、ServerID、主機名稱等。

在這些情況下,所有多度量測量的單一名稱將沒有幫助,因為我們的引擎使用多度量名稱來分割資料,且具有單一值限制了您取得的分割區優勢。這些記錄的分割主要是以兩個維度為基礎。假設時間在 x 軸上,以及 y 軸measure_name上的維度名稱和 雜湊。measure_name 在這些情況下, 的運作方式幾乎與分割金鑰類似。

我們的建議如下。

  • 為類似我們提及的使用案例建立資料模型時,請使用 measure_name 作為主要查詢存取模式的直接衍生。例如:

    • 您的使用案例需要從最終使用者的觀點追蹤應用程式效能和 QoE。這也可能是追蹤單一伺服器或 IoT 裝置的測量。

    • 如果您要依 查詢和篩選, UserId則需要在擷取時間找到measure_name與 建立關聯的最佳方法 UserId。

    • 由於多度量資料表只能保留 8192 個不同的度量名稱,因此採用的任何公式都不應產生超過 8192 個不同的值。

  • 我們成功套用字串值的一個方法是將雜湊演算法套用至字串值。然後使用雜湊結果的絕對值 和 8192 執行模數操作。

    measure_name = getMeasureName(UserId)
    int getMeasureName(value) {
        hash_value =  abs(hash(value))
        return hash_value % 8192
    }
  • 我們也新增了 abs() 以移除 符號,消除了值從 -8192 到 8192 範圍的可能性。這應該在模數操作之前執行。

  • 透過使用此方法,您的查詢可以在未分割資料模型上執行所需的一小部分時間上執行。

  • 查詢資料時,請確定您在述詞中包含使用 measure_name 新衍生值的篩選條件。例如:

    • SELECT * FROM your_database.your_table WHERE host_name = 'Host-1235' time BETWEEN '2022-09-01' AND '2022-09-18' AND measure_name = (SELECT cast(abs(from_big_endian_64(xxhash64(CAST('HOST-1235' AS varbinary))))%8192 AS varchar))
    • 這將最大限度地減少掃描的分割區總數,以取得資料,這些資料將隨著時間轉換更快的查詢。

請注意,如果您想要從此分割區結構描述中取得優勢,則需要在用戶端計算雜湊,並將 傳遞給 Timestream LiveAnalytics 做為查詢引擎的靜態值。上述範例提供一種方法,可驗證產生的雜湊是否可以在需要時由引擎解決。

time host_name location server_type cpu_usage available_memory cpu_temp

2022-09-07 21:48:44 .000000000

host-1235

us-east1

5.8xl

55

16.2

78

R2022-09-07 21:48:44 .000000000

host-3587

us-west1

5.8xl

62

18.1

81

2022-09-07 21:48:45.000000000

host-258743

eu-central

5.8xl

88

9.4

91

2022-09-07 21:48:45 .000000000

host-35654

us-east2

5.8xl

29

24

54

R2022-09-07 21:48:45 .000000000

host-254

us-west1

5.8xl

44

32

48

若要measure_name依照我們的建議產生相關聯的 ,有兩個路徑取決於您的擷取模式。

  1. 對於歷史資料的批次擷取 - 如果您將自己的程式碼用於批次程序,則可以將轉換新增至寫入程式碼。

    在上述範例的基礎上建置 。

    List<String> hosts = new ArrayList<>(); hosts.add("host-1235"); hosts.add("host-3587"); hosts.add("host-258743"); hosts.add("host-35654"); hosts.add("host-254"); for (String h: hosts){ ByteBuffer buf2 = ByteBuffer.wrap(h.getBytes()); partition = abs(hasher.hash(buf2, 0L)) % 8192; System.out.println(h + " - " + partition); }

    輸出

    host-1235 - 6445
    host-3587 - 6399
    host-258743 - 640
    host-35654 - 2093
    host-254 - 7051
    

    產生的資料集

    time host_name location measure_name server_type cpu_usage available_memory cpu_temp

    2022-09-07 21:48:44 .000000000

    host-1235

    us-east1

    6445

    5.8xl

    55

    16.2

    78

    R2022-09-07 21:48:44 .000000000

    host-3587

    us-west1

    6399

    5.8xl

    62

    18.1

    81

    2022-09-07 21:48:45.000000000

    host-258743

    eu-central

    640

    5.8xl

    88

    9.4

    91

    2022-09-07 21:48:45 .000000000

    host-35654

    us-east2

    2093

    5.8xl

    29

    24

    54

    R2022-09-07 21:48:45 .000000000

    host-254

    us-west1

    7051

    5.8xl

    44

    32

    48

  2. 對於即時擷取 - 您需要在資料傳入時產生傳輸measure_name中。

在這兩種情況下,我們建議您測試兩端的雜湊產生演算法 (擷取和查詢),以確保您獲得相同的結果。

以下是根據 產生雜湊值的一些程式碼範例host_name

範例 Python
>>> import xxhash >>> from bitstring import BitArray >>> b=xxhash.xxh64('HOST-ID-1235').digest() >>> BitArray(b).int % 8192 ### 3195
範例 Go
package main import ( "bytes" "fmt" "github.com/cespare/xxhash" ) func main() { buf := bytes.NewBufferString("HOST-ID-1235") x := xxhash.New() x.Write(buf.Bytes()) // convert unsigned integer to signed integer before taking mod fmt.Printf("%f\n", abs(int64(x.Sum64())) % 8192) } func abs(x int64) int64 { if (x < 0) { return -x } return x }
範例 Java
import java.nio.ByteBuffer; import net.jpountz.xxhash.XXHash64; public class test { public static void main(String[] args) { XXHash64 hasher = net.jpountz.xxhash.XXHashFactory.fastestInstance().hash64(); String host = "HOST-ID-1235"; ByteBuffer buf = ByteBuffer.wrap(host.getBytes()); Long result = Math.abs(hasher.hash(buf, 0L)); Long partition = result % 8192; System.out.println(result); System.out.println(partition); } }
範例 Maven 中的相依性
<dependency> <groupId>net.jpountz.lz4</groupId> <artifactId>lz4</artifactId> <version>1.3.0</version> </dependency>