從 kinesis 流/firehose 填充 dynamodb 表

Question

問題

使用來自 kinesis 數據源（流或流水）的數據填充 dynamodb 表的推薦方法是什么？

當前工作流程

• 數據被攝取到 kinesis firehose 中
• lambda 在寫入 kinesis firehose 的每條記錄上觸發，並將數據發送到 dynamodb

為什么

我想就此獲得一些建議，因為

• 我不確定這種方法是否不會造成不必要的工作。 即我需要為 lambda 編寫和維護代碼
• 我發現我可以將 redshift 或 s3 之類的東西配置為我的 kinesis 數據源的使用者。 為什么我不能用 dynamodb 做同樣的事情？ 是否有一個原因？ 其他人不使用這種工作流程嗎？

Answer 1

我的觀點是，您的工作流程目前或多或少是正確的方法。 我唯一要改變的是，我會使用 Kinesis Streams 而不是 Firehose。 然后，您可以將您的流配置為您的 Lambda 事件源，並且有一個用於配置批處理大小的選項。 這將大大降低您的 lambda 成本，因為不是每條記錄執行一次 lambda，而是每批執行一次 lambda（例如，500 條記錄的大小）。 AWS 文檔 ( https://docs.aws.amazon.com/lambda/latest/dg/with-kinesis.html ) 中解釋了詳細信息

我不確定不提供 DynamoDB 作為目的地背后的真正原因。 我的猜測是； Kinesis 不知道您的內容的結構。 Kinesis 的當前目標要么具有某種機制來根據其需要構建傳入數據，要么根本不關心對象結構 (S3)。 另一方面，DynamoDB 需要用戶做出一些決定。 這些架構決策對每個表都非常重要（性能、成本、分區、訪問模式等）。 哪個字段將是您的分區鍵，您會使用排序鍵嗎？ 你會格式化你的任何字段嗎？ 您將如何確保您的主鍵值是唯一的？ 每個字段的類型是什么（字符串、十進制等）？ 我認為，Lambda 是最適合這些決策的機制，因為它具有靈活性。

有一些自動機制可以從數據本身推斷架構（如 AWS Glue 使用），但在 DynamoDB 情況下，這並不簡單。