

# 使用 DynamoDB 与 OpenSearch Service 的零 ETL 集成的最佳实践
<a name="bp-integration-opensearch"></a>

DynamoDB 已实现 [DynamoDB 与 Amazon OpenSearch Service 的零 ETL 集成](OpenSearchIngestionForDynamoDB.md)。有关更多信息，请参阅 [DynamoDB plugin for OpenSearch Ingestion](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/configure-client-ddb.html) 和 [specific best practices for Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/bp.html)。

## 配置
<a name="bp-integration-opensearch-configuration"></a>
+ 仅对需要执行搜索的数据编制索引。请务必使用映射模板（`template_type: index_template` 和 `template_content`）和 `include_keys` 来实现这一点。
+ 监控日志中是否存在与类型冲突相关的错误。OpenSearch Service 期望给定键的所有值都具有相同的类型。如果不匹配，则会引发异常。如果您遇到其中一个错误，可以添加一个处理器来捕获给定的键始终是相同的值。
+ 通常使用 `primary_key` 元数据值作为 `document_id` 值。在 OpenSearch Service 中，文档 ID 等同于 DynamoDB 中的主键。使用主键可以轻松找到您的文档，并确保更新始终如一地复制到该文档而不会发生冲突。

  您可以使用帮助程序函数 `getMetadata` 来获取您的主键（例如，`document_id: "${getMetadata('primary_key')}"`）。如果您使用的是复合主键，则帮助程序函数会将它们连接在一起。
+ 通常，使用 `opensearch_action` 元数据值进行 `action` 设置。这将确保以这样的方式复制更新，使 OpenSearch Service 中的数据与 DynamoDB 中的最新状态相匹配。

  您可以使用帮助程序函数 `getMetadata` 来获取您的主键（例如，`action: "${getMetadata('opensearch_action')}"`）。对于筛选等用例，您也可以通过 `dynamodb_event_name` 获取流事件类型。但是，通常不应将其用于 `action` 设置。

## 可观测性
<a name="bp-integration-opensearch-observability"></a>
+ 始终在 OpenSearch 接收器上使用死信队列（DLQ）来处理丢弃的事件。DynamoDB 的结构化通常不如 OpenSearch Service，而且总是有可能发生意想不到的事情。使用死信队列，您可以恢复各个事件，甚至自动执行恢复过程。这将有助于您避免重建整个索引。
+ 请务必设置警报，让您的复制延迟不会超过预期值。通常情况下，假设为一分钟比较安全，警报也不会太吵。这可能会有所不同，具体取决于您的写入流量激增程度以及管道上的 OpenSearch 计算单位（OCU）设置。

  如果您的复制延迟超过 24 小时，则您的流将开始丢弃事件，除非您从头开始完全重建索引，否则您将遇到准确性问题。

## 扩展
<a name="bp-integration-opensearch-scaling"></a>
+ 对管道使用自动扩缩来协助纵向或横向扩展 OCU 以很好地满足工作负载需求。
+ 对于没有自动扩缩的预置吞吐量表，我们建议根据写入容量单位（WCU）除以 1000 来设置 OCU。将最小值设置为低于该数量 1 个 OCU（但至少为 1），并将最大值设置为至少比该数量高出 1 个 OCU。
  + **公式：**

    ```
    OCU_minimum = GREATEST((table_WCU / 1000) - 1, 1)
    OCU_maximum = (table_WCU / 1000) + 1
    ```
  + **示例：**您的表已置 25000 个 WCU。您管道的 OCU 应设置为最少 24（25000/1000 - 1），最大值应设置为至少 26（25000/1000 \$1 1）。
+ 对于有自动扩缩的预置吞吐量表，我们建议根据最小和最大 WCU 除以 1000 来设置 OCU。将最小值设置为低于 DynamoDB 中最小值 1 个 OCU，并将最大值设置为至少比 DynamoDB 中最大值高 1 个 OCU。
  + **公式：**

    ```
    OCU_minimum = GREATEST((table_minimum_WCU / 1000) - 1, 1)
    OCU_maximum = (table_maximum_WCU / 1000) + 1
    ```
  + **示例：**您的表具有自动扩缩策略，最小值为 8000，最大值为 14000。您管道的 OCU 应最少设置为 7（8000/1000 - 1），最大值应设置为 15（14000/1000 \$1 1）。
+ 对于按需吞吐量表，我们建议根据每秒写入请求单位的典型峰值和谷值来设置 OCU。您可能需要取更长时间段的平均值，具体取决于可用的聚合。将最小值设置为低于 DynamoDB 中最小值 1 个 OCU，并将最大值设置为至少比 DynamoDB 中最大值高 1 个 OCU。
  + **公式：**

    ```
    # Assuming we have writes aggregated at the minute level
    OCU_minimum = GREATEST((min(table_writes_1min) / (60 * 1000)) - 1, 1)
    OCU_maximum = (max(table_writes_1min) / (60 * 1000)) + 1
    ```
  + **示例：**您表的平均谷值为每秒 300 个写入请求单位，平均峰值为 4300。您管道的 OCU 应最少设置为 1（300/1000 - 1，但至少为 1），最大值应设置为 5（4300/1000 \$1 1）。
+ 请遵循扩展目标 OpenSearch Service 索引的最佳实践。如果您的索引规模不足，则会减慢 DynamoDB 的摄取速度，并可能导致延迟。

**注意**  
[https://docs.aws.amazon.com/redshift/latest/dg/r_GREATEST_LEAST.html](https://docs.aws.amazon.com/redshift/latest/dg/r_GREATEST_LEAST.html) 是一个 SQL 函数，在给定一组参数的情况下，它返回值最大的参数。