常見問題 - Amazon Data Firehose
Firehose 串流無法使用目的地沒有資料增加或未發出資料新鮮度指標記錄格式轉換為 Apache Parquet 失敗Lambda 轉換物件缺少欄位

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

常見問題

以下是疑難排解秘訣，可協助您在使用 Firehose 串流時解決常見問題。

Firehose 串流無法使用

Firehose 串流無法做為 CloudWatch Logs、CloudWatch Events 或 AWS IoT 動作的目標，因為某些 AWS 服務只能將訊息和事件傳送到位於相同 中的 Firehose 串流 AWS 區域。確認您的 Firehose 串流與其他服務位於相同的區域。

目的地沒有資料

如果沒有資料擷取問題，而且針對 Firehose 串流發出的指標看起來不錯，但您沒有在目的地看到資料，請檢查讀取器邏輯。確認您的讀者正確解析出所有資料。

增加或未發出資料新鮮度指標

資料新鮮度是衡量資料在 Firehose 串流內目前狀態的指標。這是 Firehose 串流中最舊資料記錄的存留期，從 Firehose 擷取資料到目前為止測量。Firehose 提供可用來監控資料新鮮度的指標。若要識別指定目的地的資料新鮮度指標，請參閱 使用 CloudWatch 指標監控 Amazon Data Firehose。

如果您啟用所有事件或所有文件的備份，請監控兩個不同的資料新鮮度指標：一個針對主要目的地，另一個則針對備份。

如果未發出資料重新整理指標，這表示 Firehose 串流沒有作用中的交付。資料交付完全封鎖時或沒有傳入資料時，就會發生這種情況。

如果資料新鮮度指標不斷增加，這表示資料交付落後。這種情況可能是由於下列其中一個原因而發生的。

  • 目的地無法處理交付率。如果 Firehose 因為高流量而遇到暫時性錯誤，則交付可能會落後。除了 Amazon S3 以外的目的地都可能發生這種情況 (OpenSearch Service、Amazon Redshift 或 Splunk 就可能發生)。確定您的目的地有足夠的容量來處理傳入流量。

  • 目的地很慢。如果 Firehose 遇到高延遲，資料交付可能會落後。監控目的地的延遲指標。

  • Lambda 函數緩慢。這可能會導致資料交付率低於 Firehose 串流的資料擷取率。如果可能的話，請提高 Lambda 函數的效率。例如，如果此函數執行網路 IO，請使用多個執行緒或非同步 IO 來增加並行性。此外，請考慮增加 Lambda 函數的記憶體大小，以便 CPU 配置可以相應地增加。這可能會導致更快的 Lambda 調用。如需設定 Lambda 函數的資訊，請參閱設定 AWS Lambda 函數。

  • 資料交付期間發生失敗。如需如何使用 Amazon CloudWatch Logs 監控錯誤的相關資訊，請參閱 使用 CloudWatch Logs 監控 Amazon Data Firehose。

  • 如果 Firehose 串流的資料來源是 Kinesis 資料串流，則可能會發生限流。檢查 ThrottledGetRecords、ThrottledGetShardIterator 和 ThrottledDescribeStream 指標。如果有多個取用者附加到 Kinesis 資料串流，請考慮下列情況：

    • 如果 ThrottledGetRecords 和 ThrottledGetShardIterator 指標很高，建議您增加針對資料串流佈建的碎片數目。

    • 如果 ThrottledDescribeStream 很高，我們建議您將 kinesis:listshards 許可新增至 KinesisStreamSourceConfiguration 中設定的角色。

  • 目的地的緩衝提示很低。這可能會增加 Firehose 需要對目的地進行的往返次數，這可能會導致交付落後。請考慮增加緩衝提示的值。如需詳細資訊，請參閱緩衝提示。

  • 當錯誤頻繁發生時，高重試持續時間可能會導致交付落後。請考慮減少重試持續時間。此外，監控錯誤並嘗試減少錯誤。如需如何使用 Amazon CloudWatch Logs 監控錯誤的相關資訊，請參閱 使用 CloudWatch Logs 監控 Amazon Data Firehose。

  • 如果目的地是 Splunk，而且 DeliveryToSplunk.DataFreshness 很高，但 DeliveryToSplunk.Success 看起來不錯，Splunk 叢集可能忙碌中。如果可能的話，釋出 Splunk 叢集。或者，請聯絡 AWS Support 並請求增加 Firehose 用來與 Splunk 叢集通訊的頻道數量。

記錄格式轉換為 Apache Parquet 失敗

如果您取得包含 Set類型的 DynamoDB 資料、透過 Lambda 將其串流至 Firehose 串流，並使用 AWS Glue Data Catalog 將記錄格式轉換為 Apache Parquet，就會發生這種情況。

當 AWS Glue 爬蟲程式為 DynamoDB 集資料類型 (StringSet、 NumberSet和 BinarySet) 編製索引時SET<BINARY>，它會分別將它們存放在資料目錄中，分別為 SET<STRING>、 SET<BIGINT>和 。不過，若要讓 Firehose 將資料記錄轉換為 Apache Parquet 格式，則需要 Apache Hive 資料類型。因為集合類型不是有效的 Apache Hive 資料類型，轉換會失敗。若要讓轉換正常運作，請以 Apache Hive 資料類型更新資料目錄。您可以在資料目錄中將 set 變更為 array 來這麼做。

將資料 AWS Glue 目錄中array的一或多個資料類型從 set 變更為

  1. 登入 AWS 管理主控台 ，並在 https：//https://console.aws.amazon.com/glue/ 開啟 AWS Glue 主控台。

  2. 在左側窗格的 Data catalog (資料目錄) 標題下，選擇 Tables (資料表)。

  3. 在資料表清單中，選擇您需要修改一或多個資料類型的資料表名稱。您將會移至該資料表的詳細資訊頁面。

  4. 選擇詳細資訊頁面右上角的編輯結構描述按鈕。

  5. 在 Data type (資料類型) 欄中，選擇第一個 set 資料類型。

  6. 在 Column type (欄類型) 下拉式清單中，將類型從 set 變更為 array。

  7. 在 ArraySchema 欄位中，根據您案例的適當資料類型，輸入 array<string>、array<int> 或 array<binary>。

  8. 選擇更新。

  9. 重複上述步驟，將其他 set 類型轉換為 array 類型。

  10. 選擇儲存。

Lambda 轉換物件缺少欄位

當您使用 Lambda 資料轉換將 JSON 資料變更為 Parquet 物件時，某些欄位可能會在轉換後遺失。如果您的 JSON 物件有大寫字母，且區分大小寫設定為 false，這可能會導致資料轉換後 JSON 金鑰不相符，導致 s3 儲存貯體中產生的 Parquet 物件遺失資料。

若要修正此問題，請確定管線組態已將 deserializationOption: case.insensitive設定為 ，true以便 JSON 金鑰在轉換後相符。