Uso de una canalización de OpenSearch Ingestion con Amazon DynamoDB
Puede usar el complemento DynamoDB
Puede procesar datos de DynamoDB con o sin una instantánea inicial completa.
-
Con una instantánea completa, DynamoDB utiliza la recuperación en un momento dado (PITR) para crear una copia de seguridad y la carga en Amazon S3. A continuación, OpenSearch Ingestion indexa la instantánea en uno o varios índices de OpenSearch. Para mantener la coherencia, la canalización sincroniza todos los cambios de DynamoDB con OpenSearch. Esta opción requiere que habilite PITR y DynamoDB Streams.
-
Sin una instantánea: OpenSearch Ingestion solo transmite los eventos nuevos de DynamoDB. Elija esta opción si ya tiene una instantánea o si necesita una transmisión en tiempo real sin datos históricos. Esta opción requiere que habilite únicamente DynamoDB Streams.
Para obtener más información, consulte Integración sin ETL de DynamoDB con Amazon OpenSearch Service en la Guía para desarrolladores de Amazon DynamoDB.
Temas
Requisitos previos
Para configurar la canalización, debe tener una tabla de DynamoDB con DynamoDB Streams activado. La transmisión debe usar el tipo de vista de transmisión NEW_IMAGE. Sin embargo, las canalizaciones de OpenSearch Ingestion también pueden transmitir eventos con NEW_AND_OLD_IMAGES si este tipo de vista de transmisión se ajusta a su caso de uso.
Si utiliza instantáneas, también debe habilitar la recuperación en un momento dado en su tabla. Para obtener más información, consulte Creación de una tabla, Habilitación de la recuperación en un momento dado y Habilitación de una transmisión en la Guía para desarrolladores de Amazon DynamoDB.
Paso 1: configurar el rol de canalización
Una vez configurada la tabla de DynamoDB, configure el rol de canalización que desee usar en la configuración de canalización y añada los siguientes permisos de DynamoDB al rol:
También puede usar una clave administrada por el cliente de AWS KMS para cifrar los archivos de datos de exportación. Para descifrar los objetos exportados, especifique s3_sse_kms_key_id para el ID de clave en la configuración de exportación de la canalización con el siguiente formato: arn:aws:kms:. La siguiente política incluye los permisos necesarios para utilizar una clave administrada por el cliente:region:account-id:key/my-key-id
{ "Sid": "allowUseOfCustomManagedKey", "Effect": "Allow", "Action": [ "kms:GenerateDataKey", "kms:Decrypt" ], "Resource":arn:aws:kms:}region:account-id:key/my-key-id
Paso 2: crear la canalización
A continuación, puede configurar una canalización de OpenSearch Ingestion como la siguiente, en la que se especifica a DynamoDB como el origen. Este ejemplo de canalización incorpora los datos de la table-a con la instantánea de PITR, seguidos de los eventos de DynamoDB Streams. Una posición inicial de LATEST indica que la canalización debe leer los datos más recientes de DynamoDB Streams.
version: "2" cdc-pipeline: source: dynamodb: tables: - table_arn: "arn:aws:dynamodb:region:account-id:table/table-a" export: s3_bucket: "my-bucket" s3_prefix: "export/" stream: start_position: "LATEST" aws: region: "us-east-1" sink: - opensearch: hosts: ["https://search-mydomain.region.es.amazonaws.com"] index: "${getMetadata(\"table-name\")}" index_type: custom normalize_index: true document_id: "${getMetadata(\"primary_key\")}" action: "${getMetadata(\"opensearch_action\")}" document_version: "${getMetadata(\"document_version\")}" document_version_type: "external"
Puede utilizar un esquema preconfigurado de DynamoDB para crear esta canalización. Para obtener más información, consulte Uso de esquemas.
Coherencia de datos
OpenSearch Ingestion admite el reconocimiento integral para garantizar la durabilidad de los datos. Cuando una canalización lee instantáneas o transmisiones, crea particiones de forma dinámica para el procesamiento paralelo. La canalización marca una partición como completa cuando recibe un reconocimiento después de incorporar todos los registros en el dominio o la colección de OpenSearch.
Si desea incorporarlos a una colección de búsquedas de OpenSearch sin servidor, puede generar un ID de documento en la canalización. Si quiere incorporarlos a una colección de series temporales de OpenSearch sin servidor, tenga en cuenta que la canalización no genera un ID de documento.
Una canalización de OpenSearch Ingestion también asigna las acciones de los eventos entrantes a las correspondientes acciones de indexación masiva para facilitar la incorporación de documentos. Esto mantiene la coherencia de datos, de modo que cada cambio de datos en DynamoDB se concilie con los cambios de documento correspondientes en OpenSearch.
Asignación de tipos de datos
OpenSearch Service asigna de manera dinámica los tipos de datos de cada documento entrante al tipo de datos correspondiente en DynamoDB. En la siguiente tabla se muestra cómo OpenSearch Service asigna de forma automática varios tipos de datos.
| Tipo de datos | OpenSearch | DynamoDB |
|---|---|---|
| Número |
OpenSearch asigna automáticamente los datos numéricos. Si el número es un número entero, OpenSearch lo asigna como un valor largo. Si el número es fraccionario, OpenSearch lo asigna como un valor flotante. OpenSearch asigna de manera dinámica varios atributos en función del primer documento enviado. Si tiene una combinación de tipos de datos para el mismo atributo en DynamoDB, como un número entero y un número fraccionario, es posible que se produzca un error en la asignación. Por ejemplo, si el primer documento tiene un atributo que es un número entero y un documento posterior tiene el mismo atributo como un número fraccionario, OpenSearch no podrá incorporar el segundo documento. En estos casos, debe proporcionar una plantilla de asignación explícita, como la siguiente:
Si necesita una precisión doble, utilice la asignación de campos de tipo cadena. No hay ningún tipo numérico equivalente que admita 38 dígitos de precisión en OpenSearch. |
DynamoDB admite números. |
| Conjunto de números | OpenSearch asigna automáticamente un conjunto de números a una matriz de valores largos o flotantes. Al igual que con los números escalares, esto depende de si el primer número incorporado es un número entero o un número fraccionario. Puede proporcionar asignaciones para conjuntos de números de la misma manera que asigna cadenas escalares. |
DynamoDB admite tipos que representan conjuntos de números. |
| Cadena |
OpenSearch asigna automáticamente los valores de cadena en forma de texto. En algunas situaciones, como en el caso de los valores enumerados, puede asignarlos al tipo de palabra clave. En el siguiente ejemplo se muestra cómo asignar un atributo de DynamoDB denominado
|
DynamoDB admite cadenas. |
| Conjunto de cadenas |
OpenSearch asigna de manera automática un conjunto de cadenas en una matriz de cadenas. Puede proporcionar asignaciones para conjuntos de cadenas de la misma manera que asigna cadenas escalares. |
DynamoDB admite tipos que representan conjuntos de cadenas. |
| Binario |
OpenSearch asigna de manera automática los datos binarios en forma de texto. Puede proporcionar una asignación para escribirlos como campos binarios en OpenSearch. En el siguiente ejemplo se muestra cómo asignar un atributo de DynamoDB denominado
|
DynamoDB es compatible con los atributos de tipo binarios. |
| Conjunto binario |
OpenSearch asigna de manera automática un conjunto binario a una matriz de datos binarios en forma de texto. Puede proporcionar asignaciones para conjuntos de números de la misma manera que asigna el binario escalar. |
DynamoDB admite tipos que representan conjuntos de valores binarios. |
| Booleano |
OpenSearch asigna un tipo booleano de DynamoDB a un tipo booleano de OpenSearch. |
DynamoDB admite atributos de tipo booleano. |
| Nulo |
OpenSearch puede incorporar documentos del tipo nulos de DynamoDB. Guarda el valor como un valor nulo en el documento. No hay ninguna asignación para este tipo y este campo no está indexado ni se puede buscar en él. Si se utiliza el mismo nombre de atributo para un tipo nulo y, posteriormente, se cambia a un tipo diferente, como una cadena, OpenSearch crea una asignación dinámica para el primer valor no nulo. Los valores subsiguientes pueden seguir siendo valores nulos de DynamoDB. |
DynamoDB admite atributos de tipo nulo. |
| Asignación |
OpenSearch asigna los atributos de asignación de DynamoDB a campos anidados. Las mismas asignaciones se aplican dentro de un campo anidado. En el siguiente ejemplo se asigna una cadena de un campo anidado a un tipo de palabra clave en OpenSearch:
|
DynamoDB admite atributos de tipo asignación. |
| Enumeración |
OpenSearch proporciona resultados diferentes para las listas de DynamoDB, según el contenido de la lista. Cuando una lista contiene todos los tipos escalares del mismo tipo (por ejemplo, una lista de todas las cadenas), OpenSearch incorpora la lista como una matriz de ese tipo. Esto funciona para los tipos cadena, número, booleano y nulo. Las restricciones para cada uno de estos tipos son las mismas que las restricciones para un escalar de ese tipo. También puede proporcionar asignaciones para listas de mapas con la misma asignación que usaría para un mapa. No puede proporcionar una lista de tipos mixtos. |
DynamoDB admite atributos de tipo lista. |
| Establezca |
OpenSearch proporciona resultados diferentes para los conjuntos de DynamoDB en función del contenido del conjunto. Cuando un conjunto contiene todos los tipos escalares del mismo tipo (por ejemplo, un conjunto de todas las cadenas), entonces OpenSearch incorpora el conjunto como una matriz de ese tipo. Esto funciona para los tipos cadena, número, booleano y nulo. Las restricciones para cada uno de estos tipos son las mismas que las restricciones para un escalar de ese tipo. También puede proporcionar asignaciones para conjuntos de mapas con la misma asignación que usaría para un mapa. No puede proporcionar un conjunto de tipos mixtos. |
DynamoDB admite tipos que representan conjuntos. |
Le recomendamos configurar la cola de mensajes fallidos (DLQ) en su canalización de OpenSearch Ingestion. Si ha configurado la cola, OpenSearch Service envía todos los documentos con errores que no se pueden incorporar debido a errores de asignación dinámica.
En caso de que las asignaciones automáticos fallen, puede usar template_type y template_content en su configuración de canalización para definir reglas de asignación explícitas. Como alternativa, puede crear plantillas de asignación directamente en su dominio o colección de búsqueda antes de iniciar la canalización.
Limitaciones
Tenga en cuenta las siguientes limitaciones cuando configure una canalización de OpenSearch Ingestion para DynamoDB:
-
En la actualidad, la integración de OpenSearch Ingestion con DynamoDB no admite la ingesta entre regiones. La tabla de DynamoDB y la canalización de OpenSearch Ingestion deben estar en la misma Región de AWS.
-
La tabla de DynamoDB y la canalización de OpenSearch Ingestion deben estar en la misma Cuenta de AWS.
-
Una canalización de OpenSearch Ingestion solo admite una tabla de DynamoDB como su origen.
-
DynamoDB Streams solo almacena datos en un registro durante un máximo de 24 horas. Si la ingesta de una instantánea inicial de una tabla grande demora 24 horas o más, se producirá una pérdida inicial de datos. Para mitigar esta pérdida de datos, calcule el tamaño de la tabla y configure las unidades de computación adecuadas de las canalizaciones de OpenSearch Ingestion.
Alarmas de CloudWatch recomendadas para DynamoDB
Se recomiendan las siguientes métricas de CloudWatch para supervisar el rendimiento de la canalización de ingesta. Estas métricas pueden ayudarle a identificar la cantidad de datos procesados a partir de exportaciones y flujos, los errores al procesar eventos de transmisión y exportación y la cantidad de documentos escritos en el destino. Puede configurar las alarmas de CloudWatch para que lleven a cabo una acción cuando una de estas métricas supere un valor especificado durante un periodo de tiempo determinado.
| Métrica | Descripción |
|---|---|
dynamodb-pipeline.BlockingBuffer.bufferUsage.value |
Indica qué cantidad del búfer se está utilizando. |
dynamodb-pipeline.dynamodb.activeExportS3ObjectConsumers.value
|
Muestra el número total de OCU que procesan activamente objetos de Amazon S3 para la exportación. |
dynamodb-pipeline.dynamodb.bytesProcessed.count
|
Recuento de bytes procesados desde el origen de DynamoDB. |
dynamodb-pipeline.dynamodb.changeEventsProcessed.count
|
Número de eventos de cambio procesados desde el flujo de DynamoDB. |
dynamodb-pipeline.dynamodb.changeEventsProcessingErrors.count
|
Número de errores de eventos de cambio procesados desde DynamoDB. |
dynamodb-pipeline.dynamodb.exportJobFailure.count
|
Number of export job submission attempts that have failed. |
dynamodb-pipeline.dynamodb.exportJobSuccess.count
|
Number of export jobs that have been submitted successfully. |
dynamodb-pipeline.dynamodb.exportRecordsProcessed.count
|
Número total de registros procesados desde la exportación. |
dynamodb-pipeline.dynamodb.exportRecordsTotal.count
|
Número total de registros exportados desde DynamoDB, esencial para el seguimiento de los volúmenes de exportación de datos. |
dynamodb-pipeline.dynamodb.exportS3ObjectsProcessed.count
|
Total number of export data files that have been processed successfully from Amazon S3. |
dynamodb-pipeline.opensearch.bulkBadRequestErrors.count
|
Count of errors during bulk requests due to malformed request. |
dynamodb-pipeline.opensearch.bulkRequestLatency.avg
|
Average latency for bulk write requests made to OpenSearch. |
dynamodb-pipeline.opensearch.bulkRequestNotFoundErrors.count
|
Number of bulk requests that failed because the target data could not be found. |
dynamodb-pipeline.opensearch.bulkRequestNumberOfRetries.count
|
Number of retries by OpenSearch Ingestion pipelines to write OpenSearch cluster. |
dynamodb-pipeline.opensearch.bulkRequestSizeBytes.sum
|
Total size in bytes of all bulk requests made to OpenSearch. |
dynamodb-pipeline.opensearch.documentErrors.count
|
Number of errors when sending documents to OpenSearch. The documents causing the errors witll be sent to DLQ. |
dynamodb-pipeline.opensearch.documentsSuccess.count
|
Number of documents successfully written to an OpenSearch cluster or collection. |
dynamodb-pipeline.opensearch.documentsSuccessFirstAttempt.count
|
Number of documents successfully indexed in OpenSearch on the first attempt. |
|
|
Count of errors due to version conflicts in documents during processing. |
|
|
Average latency of OpenSearch Ingestion pipeline to process the data by reading from the source to writint to the destination. |
dynamodb-pipeline.opensearch.PipelineLatency.max
|
Maximum latency of OpenSearch Ingestion pipeline to process the data by reading from the source to writing the destination. |
dynamodb-pipeline.opensearch.recordsIn.count
|
Count of records successfully ingested into OpenSearch. This metric is essential for tracking the volume of data being processed and stored. |
dynamodb-pipeline.opensearch.s3.dlqS3RecordsFailed.count
|
Number of records that failed to write to DLQ. |
dynamodb-pipeline.opensearch.s3.dlqS3RecordsSuccess.count
|
Number of records that are written to DLQ. |
dynamodb-pipeline.opensearch.s3.dlqS3RequestLatency.count
|
Count of latency measurements for requests to the Amazon S3 dead-letter queue. |
dynamodb-pipeline.opensearch.s3.dlqS3RequestLatency.sum
|
Total latency for all requests to the Amazon S3 dead-letter queue |
dynamodb-pipeline.opensearch.s3.dlqS3RequestSizeBytes.sum
|
Total size in bytes of all requests made to the Amazon S3 dead-letter queue. |
dynamodb-pipeline.recordsProcessed.count
|
Total number of records processed in the pipeline, a key metric for overal throughput. |
dynamodb.changeEventsProcessed.count
|
No records are being gathered from DynamoDB streams. This could be due to no activitiy on the table, an export being in progress, or an issue accessing the DynamoDB streams. |
|
|
The attempt to trigger an export to S3 failed. |
|
|
Count of bulk request errors in OpenSearch due to invalid input, crucial for monitoring data quality and operational issues. |
opensearch.EndToEndLatency.avg
|
The end to end latnecy is higher than desired for reading from DynamoDB streams. This could be due to an underscaled OpenSearch cluster or a maximum pipeline OCU capacity that is too low for the WCU throughput on the DynamoDB table. This end to end latency will be high after an export and should decrease over time as it catches up to the latest DynamoDB streams. |