Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# ¿Qué es AWS Clean Rooms?
AWS Clean Rooms le ayuda a usted y a sus socios a analizar y colaborar en sus conjuntos de datos colectivos para obtener nuevos conocimientos sin revelarse los datos subyacentes entre sí. AWS Clean Rooms es un espacio de trabajo de colaboración seguro, en el que puede crear sus propias salas limpias en cuestión de minutos y analizar sus conjuntos de datos colectivos en tan solo unos pasos. Tú eliges los socios con los que quieres colaborar, seleccionas sus conjuntos de datos y configuras los controles que mejoran la privacidad de esos socios.
Con él AWS Clean Rooms, puede colaborar con miles de empresas que ya los utilizan. AWS La colaboración no requiere mover los datos de otro proveedor de servicios en la nube AWS ni cargarlos en él. Cuando ejecuta consultas o trabajos, AWS Clean Rooms lee los datos de su ubicación original y aplica reglas de análisis integradas para ayudarle a mantener el control sobre esos datos.
AWS Clean Rooms proporciona controles de acceso a los datos y controles de soporte de auditoría integrados que puede configurar. Estos controles incluyen:
+ [Reglas de análisis](analysis-rules.md) para restringir las consultas SQL y proporcionar restricciones de salida.
+ [Computación criptográfica Clean Rooms para](crypto-computing.md) mantener los datos cifrados, incluso mientras se procesan las consultas, a fin de cumplir con las estrictas políticas de manejo de datos.
+ [Registros de análisis](query-logs.md) para revisar las consultas y los trabajos AWS Clean Rooms y ayudar a respaldar las auditorías.
+ [Privacidad diferencial](differential-privacy.md) para proteger a los usuarios de los intentos de identificación. AWS Clean Rooms La privacidad diferencial es una capacidad totalmente gestionada que protege la privacidad de sus usuarios con técnicas respaldadas matemáticamente y controles intuitivos que puede aplicar en unos pocos pasos.
+ [AWS Clean Rooms ML](machine-learning.md) permite a dos partes identificar a usuarios similares en sus datos sin necesidad de compartir sus datos entre sí. La primera parte crea y configura un modelo similar a partir de sus datos de entrenamiento. A continuación, los datos iniciales se traen a la colaboración para crear un segmento similar que se parece a los datos de entrenamiento.
En el siguiente vídeo se explica más sobre AWS Clean Rooms.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/0S6icreVCO0)
## ¿Es la primera vez que lo usa AWS Clean Rooms ?
Si es la primera vez que lo utiliza AWS Clean Rooms, le recomendamos que comience leyendo las siguientes secciones:
+ [¿Cómo funciona AWS Clean Rooms](#how-it-works)
+ [Acceder AWS Clean Rooms](#accessing-service)
+ [Con AWS Clean Rooms figuración](setting-up.md)
+ [AWS Clean Rooms Glosario](glossary.md)
## ¿Cómo funciona AWS Clean Rooms
En AWS Clean Rooms, puedes crear una colaboración y añadir la Cuentas de AWS que quieras invitar, o bien crear una membresía para unirte a una colaboración a la que te hayan invitado. A continuación, vincule los recursos de datos necesarios para su caso de uso: tablas configuradas para datos de eventos, modelos configurados para el modelado de ML o espacios de nombres de ID para la resolución de entidades. Tiene la opción de crear o aprobar plantillas de análisis para acordar de antemano las consultas y los trabajos exactos que desea permitir en una colaboración. Por último, analiza los datos conjuntos mediante la ejecución de consultas o PySpark trabajos de SQL en las tablas configuradas, la resolución de entidades en las tablas de mapeo de ID o el uso de modelos de aprendizaje automático para generar segmentos de audiencia similares.
En el siguiente diagrama se muestra cómo AWS Clean Rooms funciona.
![\[Diagrama que explica cómo AWS Clean Rooms funciona\]](http://docs.aws.amazon.com/es_es/clean-rooms/latest/userguide/images/how-it-works.png)
## Servicios relacionados
### AWS servicios
Los siguientes Servicios de AWS están relacionados con AWS Clean Rooms:
+ **Amazon Athena**
Los miembros de Collaboration pueden almacenar los datos que incorporan AWS Clean Rooms como AWS Glue Data Catalog vistas en Amazon Athena. Para obtener más información, consulte los temas siguientes:
Para obtener más información, consulte los temas siguientes:
[Preparación de tablas de datos para consultas en AWS Clean Rooms](prepare-data.md)
[Creación de una tabla configurada: fuente de datos de Amazon Athena](create-config-table-athena.md)
[¿Qué es Amazon Athena?](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) en la Guía del *usuario de Amazon Athena*
+ **CloudFormation**
Cree los siguientes recursos en CloudFormation: colaboraciones, tablas configuradas, asociaciones de tablas configuradas y membresías
Para obtener más información, consulte [Creación de AWS Clean Rooms recursos con AWS CloudFormation](creating-resources-with-cloudformation.md).
+ **AWS CloudTrail**
Úselo AWS Clean Rooms con CloudTrail los registros para mejorar el análisis de la Servicio de AWS actividad.
Para obtener más información, consulte [Registro de llamadas a la AWS Clean Rooms API mediante AWS CloudTrail](logging-using-cloudtrail.md).
+ **AWS Entity Resolution**
Úselo AWS Clean Rooms con AWS Entity Resolution para realizar la resolución de entidades.
Para obtener más información, consulte [AWS Entity Resolution in AWS Clean Rooms](working-with-entity-resolution.md).
+ **AWS Glue**
Los miembros de Collaboration pueden crear AWS Glue tablas a partir de sus datos en Amazon S3 para usarlas en ellas AWS Clean Rooms.
Para obtener más información, consulte los temas siguientes:
[Preparación de tablas de datos para consultas en AWS Clean Rooms](prepare-data.md)
[¿Qué es AWS Glue?](https://docs.aws.amazon.com/glue/latest/dg/what-is-glue.html) en la *Guía para desarrolladores de AWS Glue *
+ **Amazon Simple Storage Service (Amazon S3)**
Los miembros de Collaboration pueden almacenar los datos que introduzcan AWS Clean Rooms en Amazon S3.
Para obtener más información, consulte los temas siguientes:
[Preparación de tablas de datos para consultas en AWS Clean Rooms](prepare-data.md)
[Creación de una tabla configurada: fuente de datos de Amazon S3](create-config-table-s3.md)
[¿Qué es Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) en la *Guía del usuario de Amazon Simple Storage Service*
+ **AWS Secrets Manager**
Los miembros de la colaboración pueden crear secretos para acceder a los datos almacenados en Snowflake y leerlos.
Para obtener más información, consulte los temas siguientes:
[Cree un rol de servicio para leer los datos de Snowflake](setting-up-roles.md#create-service-role-third-party)
[Preparación de tablas de datos para consultas en AWS Clean Rooms](prepare-data.md)
¿[Qué es AWS Secrets Manager?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) en la * Guía del usuario de AWS Secrets Manager *
### Servicios de terceros
El siguiente servicio de terceros está relacionado con: AWS Clean Rooms
+ **Snowflake**
Los miembros de Collaboration pueden almacenar los datos que introduzcan AWS Clean Rooms en un almacén de Snowflake.
Para obtener más información, consulte los temas siguientes:
[Preparación de tablas de datos para consultas en AWS Clean Rooms](prepare-data.md)
[Creación de una tabla configurada: fuente de datos de Snowflake](create-config-table-snowflake.md)
## Acceder AWS Clean Rooms
Puede acceder a AWS Clean Rooms través de las siguientes opciones:
+ Directamente a través de la AWS Clean Rooms consola en [https://console.aws.amazon.com/cleanrooms/](https://console.aws.amazon.com/cleanrooms/).
+ Programáticamente a través de la AWS Clean Rooms API. Para obtener más información, consulte la [Referencia de la API de *AWS Clean Rooms *](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html).
## Precios para AWS Clean Rooms
Para obtener información acerca de los precios, consulte [Precios de AWS Clean Rooms](https://aws.amazon.com/clean-rooms/pricing/).
**nota**
En el caso de los miembros de la colaboración que hayan asociado datos almacenados en Snowflake, el proveedor de almacenamiento de datos o el proveedor de la nube respectivos les cobrará tanto la salida como el cálculo de los datos cada vez que se ejecute una consulta que utilice datos almacenados en esas ubicaciones.
## Facturación para AWS Clean Rooms
AWS Clean Rooms permite al creador de la colaboración designar qué miembro pagará los costes de cálculo de la consulta o del trabajo en la colaboración.
En la mayoría de los casos, el [miembro que puede realizar consultas](glossary.md#glossary-member-who-can-query) es también el [miembro que paga los costos de computación de las consultas](glossary.md#glossary-member-paying-for-query-compute). No obstante, si el miembro que puede realizar consultas y el miembro que paga los costos de computación de las consultas son diferentes, cuando el miembro que puede realizar consultas ejecuta las consultas en su propio recurso de pertenencia, se factura al recurso de pertenencia del miembro que paga los costos de computación de las consultas.
El miembro que paga los costes de cálculo de las consultas no ve ningún evento relacionado con las consultas que se estén ejecutando en su historial de CloudTrail eventos porque el pagador no es quien ejecuta las consultas ni es el propietario del recurso con el que se ejecutan las consultas. Sin embargo, el pagador ve los cargos generados en su recurso de membresía por todas las consultas realizadas por el miembro que puede ejecutar consultas en la colaboración.
Para obtener más información acerca de cómo crear una colaboración y configurar el miembro que paga los costos de computación de las consultas, consulte [Crear una colaboración](create-collaboration.md).
# Reglas de análisis en AWS Clean Rooms
Como parte de la habilitación de una tabla para utilizarla en AWS Clean Rooms el análisis de la colaboración, el miembro de la colaboración debe configurar una *regla de análisis*.
Una regla de análisis es un control que mejora la privacidad y que cada propietario de datos define en una tabla configurada. Una regla de análisis determina cómo se puede analizar la tabla configurada.
La regla de análisis es un control de nivel de cuenta en la tabla configurada (un recurso de nivel de cuenta) y que se aplica a cualquier colaboración a la que esté asociada la tabla configurada. Si no hay ninguna regla de análisis configurada, la tabla configurada se puede asociar a colaboraciones, pero no se puede consultar. Las consultas solo pueden hacer referencia a tablas configuradas con el mismo tipo de regla de análisis.
Para configurar una regla de análisis, primero debe seleccionar un tipo de análisis y, a continuación, especificar la regla de análisis. En ambos pasos, debe tener en cuenta el caso de uso que desea habilitar y cómo desea proteger los datos subyacentes.
AWS Clean Rooms aplica los controles más restrictivos en todas las tablas configuradas a las que se hace referencia en una consulta.
En los siguientes ejemplos se ilustran los controles restrictivos.
**Example Control restrictivo: restricción de salida**
+ El colaborador A tiene una restricción de salida de 100 en la columna de identificador.
+ El colaborador B tiene una restricción de salida de 150 en la columna de identificador.
Una consulta de agregación que haga referencia a ambas tablas configuradas requiere al menos 150 valores diferenciados de identificador dentro de una fila de salida para que se muestre en el resultado de la consulta. El resultado de la consulta no indica que los resultados se eliminan debido a la restricción de salida.
**Example Control restrictivo: plantilla de análisis no aprobada**
+ El colaborador A ha permitido una plantilla de análisis con una consulta que hace referencia a tablas configuradas de los colaboradores A y B en su regla de análisis personalizada.
+ El colaborador B no ha permitido la plantilla de análisis.
Como el colaborador B no ha permitido la plantilla de análisis, el miembro que puede realizar consultas no puede ejecutar dicha plantilla de análisis.
## Tipos de regla de análisis
Existen tres tipos de reglas de análisis: de [agregación](analysis-rules-aggregation.md), de [lista](analysis-rules-list.md) y [personalizadas](analysis-rules-custom.md). En las siguientes tablas se comparan los tipos de reglas de análisis. Cada tipo tiene dedicada una sección independiente en la que se describe la especificación de la regla de análisis.
**nota**
Existe un tipo de regla de análisis llamado regla de análisis de tablas de asignación de ID. Sin embargo, esta regla de análisis la administra AWS Clean Rooms y no se puede modificar. Para obtener más información, consulte [Regla de análisis de tablas de asignación de ID](analysis-rules-id-mapping-table.md).
En las siguientes secciones se describen los casos de uso admitidos y los controles para cada tipo de regla de análisis.
### Casos de uso admitidos
En las siguientes tablas se muestra un resumen comparativo de los casos de uso admitidos para cada tipo de regla de análisis.
| Caso de uso | [Agregación](analysis-rules-aggregation.md) | [Lista](analysis-rules-list.md) | [Personalizada](analysis-rules-custom.md) |
| --- | --- | --- | --- |
| Análisis admitidos | Consultas que agregan estadísticas mediante las funciones COUNT, SUM y AVG en dimensiones opcionales | Consultas que generan listas de nivel de fila de la superposición entre varias tablas | Cualquier análisis personalizado, siempre que la plantilla de análisis o el creador del análisis se hayan revisado y permitido |
| Casos de uso comunes | Análisis de segmentos, medición y atribución | Enriquecimiento, creación de segmentos | Atribución de primer toque, análisis incrementales, detección de audiencias |
| Constructos SQL | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/clean-rooms/latest/userguide/analysis-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/clean-rooms/latest/userguide/analysis-rules.html) | La mayoría de las funciones SQL y constructos SQL están disponibles con el comando SELECT |
| Subconsultas y expresiones de tabla comunes () CTEs | No | No | Sí |
| Plantillas de análisis | No | No | Sí |
### Controles admitidos
En las siguientes tablas se muestra un resumen comparativo del modo en que cada tipo de regla de análisis protege los datos subyacentes.
| Controlar | [Agregación](analysis-rules-aggregation.md) | [Lista](analysis-rules-list.md) | [Personalizada](analysis-rules-custom.md) |
| --- | --- | --- | --- |
| Mecanismo de control | Controle cómo se pueden usar los datos de la tabla en una consulta*(por ejemplo, permitir COUNT y SUM de la columna hashed\$1email).* | Controle cómo se pueden usar los datos de la tabla en una consulta*(por ejemplo, permitir el uso de la columna hashed\$1email solo en combinaciones).* | Controle qué consultas pueden ejecutarse en la tabla*(por ejemplo, permitir solo las consultas definidas en las plantillas de análisis "Consulta personalizada 1").* |
| Técnicas de mejora de la privacidad integrada | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/clean-rooms/latest/userguide/analysis-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/clean-rooms/latest/userguide/analysis-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/clean-rooms/latest/userguide/analysis-rules.html) |
| Revisar la consulta antes de que pueda ejecutarse | No | No | Sí, con plantillas de análisis |
Para obtener más información sobre las reglas de análisis disponibles en AWS Clean Rooms, consulte los siguientes temas.
+ [Regla de análisis de agregación](analysis-rules-aggregation.md)
+ [Regla de análisis de lista](analysis-rules-list.md)
+ [Regla de análisis personalizada en AWS Clean Rooms](analysis-rules-custom.md)
# Regla de análisis de agregación
En AWS Clean Rooms, una *regla de análisis de agregación* genera estadísticas agregadas mediante las funciones COUNT, SUM y and/or AVG en dimensiones opcionales. Cuando la regla de análisis de agregación se agrega a una tabla configurada, permite al miembro que puede realizar la consulta ejecutar consultas en la tabla configurada.
La regla de análisis de agregación admite casos de uso tales como la planificación de campañas, el alcance mediático, la medición de la frecuencia y la atribución.
La estructura y sintaxis de consulta admitidas se definen en [Estructura y sintaxis de consultas de agregación](#agg-query-structure-syntax).
Los parámetros de la regla de análisis, definidos en [Regla de análisis de agregación: controles de consulta](#agg-query-controls), incluyen los controles de consulta y los controles de resultados de las consultas. Sus controles de consulta incluyen la posibilidad de imponer como requisito que una tabla configurada se una a al menos una tabla configurada propiedad del miembro que puede realizar la consulta, ya sea de forma directa o transitiva. Este requisito le permite asegurarse de que la consulta se ejecute en la intersección (INNER JOIN) entre su tabla y la de ellos.
## Estructura y sintaxis de consultas de agregación
Las consultas en tablas que tienen una regla de análisis de agregación deben respetar la siguiente sintaxis.
```
--select_aggregate_function_expression
SELECT
aggregation_function(column_name) [[AS] column_alias ] [, ...]
--select_grouping_column_expression
[, {column_name|scalar_function(arguments)} [[AS] column_alias ]][, ...]
--table_expression
FROM table_name [[AS] table_alias ]
[[INNER] JOIN table_name [[AS] table_alias] ON join_condition] [...]
--where_expression
[WHERE where_condition]
--group_by_expression
[GROUP BY {column_name|scalar_function(arguments)}, ...]]
--having_expression
[HAVING having_condition]
--order_by_expression
[ORDER BY {column_name|scalar_function(arguments)} [{ASC|DESC}]] [,...]]
```
En la siguiente tabla se explica cada una de las expresiones enumeradas en la sintaxis anterior.
| Expression | Definición | Ejemplos |
| --- | --- | --- |
| select\$1aggregate\$1function\$1expression | Una lista separada por comas que contiene las siguientes expresiones: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/clean-rooms/latest/userguide/analysis-rules-aggregation.html) Debe haber al menos una `select_aggregation_function_expression` en la `select_aggregate_expression`. | `SELECT SUM(PRICE), user_segment` |
| select\$1aggregation\$1function\$1expression | Una o más funciones de agregación admitidas aplicadas a una o más columnas. Solo se permiten columnas como argumentos de las funciones de agregación. Debe haber al menos una `select_aggregation_function_expression` en la `select_aggregate_expression`. | `AVG(PRICE)` `COUNT(DISTINCT user_id)` |
| select\$1grouping\$1column\$1expression | Expresión que puede contener cualquier expresión que utilice lo siguiente: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/clean-rooms/latest/userguide/analysis-rules-aggregation.html) `select_aggregate_expression` puede asignar un alias a las columnas con o sin el parámetro `AS`. Para obtener más información, consulte [Referencia de SQL de AWS Clean Rooms](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html). | `TRUNC(timestampColumn)` `UPPER(campaignName)` |
| table\$1expression | Una tabla o combinación de tablas que conecta expresiones condicionales de unión con `join_condition`. `join_condition` devuelve un valor booleano. La `table_expression` admite: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/clean-rooms/latest/userguide/analysis-rules-aggregation.html) | FROM consumer_table
INNER JOIN provider_table
ON
consumer_table.identifier1 = provider_table.identifier1
AND
consumer_table.identifier2 = provider_table.identifier2
|
| where\$1expression | Una expresión condicional que devuelve un valor booleano. Puede constar de lo siguiente: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/clean-rooms/latest/userguide/analysis-rules-aggregation.html) Las condiciones de comparación admitidas son (`=, >, <, <=, >=, <>, !=, NOT, IN, NOT IN, LIKE, IS NULL, IS NOT NULL`). Los operadores lógicos admitidos son (`AND, OR`). La `where_expression` es opcional. | `WHERE where_condition` `WHERE price > 100` `WHERE TRUNC(timestampColumn) = '1/1/2022'` `WHERE timestampColumn = timestampColumn2 - 14` |
| group\$1by\$1expression | Lista separada por comas de expresiones que cumplen con los requisitos de `select_grouping_column_expression`. | `GROUP BY TRUNC(timestampColumn), UPPER(campaignName), segment` |
| having\$1expression | Una expresión condicional que devuelve un valor booleano. Tienen una función de agregación admitida aplicada a una sola columna (por ejemplo, `SUM(price)`) y se comparan con un literal numérico. Las condiciones admitidas son (`=, >, <, <=, >=, <>, !=`). Los operadores lógicos admitidos son (`AND, OR`). La `having_expression` es opcional. | `HAVING SUM(SALES) > 500` |
| order\$1by\$1expression | Lista de expresiones separadas por comas que es compatible con los mismos requisitos definidos anteriormente en `select_aggregate_expression`. La `order_by_expression` es opcional. `order_by_expression` admite los parámetros `ASC` y `DESC`. Para obtener más información, consulte los parámetros ASC DESC en [Referencia de SQL de AWS Clean Rooms](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html). | `ORDER BY SUM(SALES), UPPER(campaignName)` |
En cuanto a la estructura y sintaxis de las consultas de agregación, tenga en cuenta lo siguiente:
+ No se admiten comandos SQL distintos de SELECT.
+ No se admiten subconsultas ni expresiones de tabla comunes (por ejemplo, WITH).
+ No se admiten operadores que combinen varias consultas (por ejemplo, UNION).
+ No se admiten los parámetros TOP, LIMIT ni OFFSET.
## Regla de análisis de agregación: controles de consulta
Los controles de consulta de agregación permiten controlar cómo se utilizan las columnas de la tabla para consultarla. Por ejemplo, puede controlar qué columna se usa para combinar, qué columna se puede contar o qué columna se puede usar en instrucciones WHERE.
En las secciones siguientes se explica cada uno de los controles.
**Topics**
+ [Controles de agregación](#agg-functions)
+ [Controles de combinación](#join-controls)
+ [Controles de dimensión](#dimension-controls)
+ [Funciones escalares](#scalar-functions)
### Controles de agregación
El uso de *controles de agregación* permite definir qué funciones de agregación se van a permitir y a qué columnas se deben aplicar. Las funciones de agregación se pueden usar en las expresiones SELECT, HAVING y ORDER BY.
| Control | Definición | De uso |
| --- | --- | --- |
| aggregateColumns | Columnas de tablas configuradas que se permite utilizar en las funciones de agregación. | `aggregateColumns` se puede usar dentro de una función de agregación en las expresiones SELECT, HAVING y ORDER BY. Algunas `aggregateColumns` también se pueden categorizar como `joinColumn` (definición disponible más adelante). La `aggregateColumn` dada no se puede categorizar también como `dimensionColumn` (definición disponible más adelante). |
| function | Las funciones COUNT, SUM y AVG que se permite utilizar además de aggregateColumns. | La `function` se puede aplicar a una `aggregateColumns` que esté asociada a ella. |
### Controles de combinación
Se utiliza una cláusula `JOIN` para combinar filas de dos o más tablas en función de una columna relacionada entre ellas.
Puede usar *los controles de unión* para controlar cómo se puede unir su tabla a otras tablas del`table_expression`. AWS Clean Rooms solo admite INNERJOIN. INNERJOINlas declaraciones solo pueden usar columnas que se hayan clasificado explícitamente como una `joinColumn` en su regla de análisis, sujetas a los controles que usted defina.
INNER JOIN deben operar en una `joinColumn` de la tabla configurada y en una `joinColumn` de otra tabla configurada de la colaboración. Usted decide qué columnas de la tabla se pueden usar como `joinColumn`.
Cada condición de coincidencia de la cláusula ON debe utilizar la condición de comparación de igualdad (`=`) entre dos columnas.
Las condiciones de coincidencia múltiples dentro de una cláusula ON pueden ser:
+ Combinación con el operador lógico `AND`
+ Separación mediante el operador lógico `OR`
**nota**
Todas las condiciones de coincidencia JOIN deben coincidir con una fila de cada lado de JOIN. Todos los condicionales conectados por un operador lógico `OR` o `AND` también deben cumplir este requisito.
A continuación se muestra un ejemplo de consulta con un operador lógico `AND`.
```
SELECT some_col, other_col
FROM table1
JOIN table2
ON table1.id = table2.id AND table1.name = table2.name
```
A continuación se muestra un ejemplo de consulta con un operador lógico `OR`.
```
SELECT some_col, other_col
FROM table1
JOIN table2
ON table1.id = table2.id OR table1.name = table2.name
```
| Control | Definición | De uso |
| --- | --- | --- |
| joinColumns | Las columnas (si las hay) que se desea permitir que el miembro que puede realizar la consulta utilice en la instrucción INNER JOIN. | También se puede categorizar una `joinColumn` como `aggregateColumn` (consulte[Controles de agregación](#agg-functions)). La misma columna no se puede usar como `joinColumn` y `dimensionColumns` a la vez (consulte más adelante). A menos que también se haya categorizado como `aggregateColumn`, una `joinColumn` no se puede usar en ninguna otra parte de la consulta que no sea INNER JOIN. |
| joinRequired | Controle si necesita una INNER JOIN con una tabla configurada del miembro que puede realizar la consulta. | Si habilita este parámetro, INNER JOIN es obligatorio. Si no habilita este parámetro, INNER JOIN es opcional. Presuponiendo que se habilite este parámetro, el miembro que puede realizar la consulta debe incluir una tabla de su propiedad en INNER JOIN. Debe combinar su tabla JOIN con la suya, ya sea de forma directa o transitiva (es decir, combinar su tabla con otra tabla que, a su vez, está combinada con la suya). |
A continuación se muestra un ejemplo de transitividad.
```
ON
my_table.identifer = third_party_table.identifier
....
ON
third_party_table.identifier = member_who_can_query_table.id
```
**nota**
El miembro que puede realizar la consulta también puede usar el parámetro `joinRequired`. En ese caso, la consulta debe combinar su tabla con al menos otra tabla.
### Controles de dimensión
Los *controles de dimensión* controlan la columna en la cual se pueden filtrar, agrupar o agregar las columnas de agregación.
| Control | Definición | De uso |
| --- | --- | --- |
| dimensionColumns | Las columnas (si las hay) que se permite que el miembro que puede realizar la consulta utilice en SELECT, WHERE, GROUP BY y ORDER BY. | Se puede usar una `dimensionColumn` en SELECT (`select_grouping_column_expression`), WHERE, GROUP BY y ORDER BY. La misma columna no puede ser a`dimensionColumn`, a y a `joinColumn` la vez`aggregateColumn`. and/or |
### Funciones escalares
Las *funciones escalares* controlan qué funciones escalares se pueden usar en las columnas de dimensión.
| Control | Definición | De uso |
| --- | --- | --- |
| scalarFunctions | Las funciones escalares que se pueden utilizar en `dimensionColumns` en la consulta. | Especifica las funciones escalares (si las hay) que se permite (por ejemplo, CAST) aplicar a `dimensionColumns`. Las funciones escalares no se pueden usar además de otras funciones ni dentro de otras funciones. Los argumentos de las funciones escalares pueden ser columnas, literales de cadena o literales numéricos. |
Se admiten las siguientes funciones escalares:
+ Funciones matemáticas: ABS, CEILING, FLOOR, LOG, LN, ROUND, SQRT
+ Funciones de formato de tipo de datos: CAST, CONVERT, TO\$1CHAR, TO\$1DATE, TO\$1NUMBER, TO\$1TIMESTAMP
+ Funciones de cadena: LOWER, UPPER, TRIM, RTRIM, SUBSTRING
+ En el caso de RTRIM, no se permiten conjuntos de caracteres personalizados para recortar.
+ Expresiones condicionales: COALESCE
+ Funciones de fecha EXTRACT, GETDATE, CURRENT\$1DATE, DATEADD
+ Otras funciones: TRUNC
Para obtener más información, consulte [Referencia de SQL de AWS Clean Rooms](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html).
## Regla de análisis de agregación: controles de resultados de consulta
Los controles de resultados de consulta de agregación le permiten controlar qué resultados se devuelven especificando una o más condiciones que debe cumplir cada fila de salida. AWS Clean Rooms admite restricciones de agregación en forma de `COUNT (DISTINCT column) >= X`. Este formato requiere que cada fila agregue al menos X valores diferenciados de una selección de la tabla configurada (por ejemplo, un número mínimo de valores `user_id` diferenciados). Este umbral mínimo se aplica automáticamente, incluso si la consulta enviada en sí misma no utiliza la columna especificada. Se aplican de manera conjunta en cada tabla configurada de la consulta desde las tablas configuradas de cada miembro de la colaboración.
Cada tabla configurada debe tener al menos una restricción de agregación en su regla de análisis. Los propietarios de las tablas configuradas pueden añadir varios `columnName` y su `minimum` asociado y estos se aplicarán conjuntamente.
### Restricciones de agregación
Las *restricciones de agregación* controlan qué filas de los resultados de la consulta se devuelven. Para incluirse en los resultados devueltos, una fila debe cumplir con el número mínimo especificado de valores diferenciados en cada columna especificada en la restricción de agregación. Este requisito se aplica incluso si la columna no se menciona explícitamente en la consulta o en otras partes de la regla de análisis.
| Control | Definición | De uso |
| --- | --- | --- |
| columnName | La `aggregateColumn` que se usa en la condición que debe cumplir cada fila de salida. | Puede tratarse de cualquier columna de la tabla configurada. |
| minimum | El número mínimo de valores diferenciados de la `aggregateColumn` asociada que debe tener la fila de salida (por ejemplo, COUNT DISTINCT) para que se devuelva en los resultados de la consulta. | El `minimum` debe tener al menos un valor de 2. |
## Estructura de la regla de análisis de agregación
El siguiente ejemplo muestra una estructura predefinida para una regla de análisis de agregación.
En el siguiente ejemplo, *`MyTable`* hace referencia a nuestra tabla de datos. Puedes reemplazar cada una *user input placeholder* con tu propia información.
```
{
"aggregateColumns": [
{
"columnNames": [MyTable column names], "function": [Allowed Agg Functions]
},
],
"joinRequired": ["QUERY_RUNNER"],
"joinColumns": [MyTable column names],
"dimensionColumns": [MyTable column names],
"scalarFunctions": [Allowed Scalar functions],
"outputConstraints": [
{
"columnName": [MyTable column names], "minimum": [Numeric value]
},
]
}
```
## Regla de análisis de agregación: ejemplo
El siguiente ejemplo demuestra cómo dos empresas pueden colaborar en el AWS Clean Rooms uso del análisis de agregación.
La empresa A tiene datos de clientes y de ventas. La empresa A está interesada en conocer la actividad de devolución de productos. La empresa B es uno de los minoristas de la empresa A y dispone de datos sobre devoluciones. La empresa B también tiene atributos de segmento sobre los clientes que son útiles para la empresa A (por ejemplo, compra de productos relacionados o uso del servicio de atención al cliente del minorista). La empresa B no quiere proporcionar información sobre atributos ni datos sobre devoluciones de los clientes por fila. La empresa B solo quiere habilitar un conjunto de consultas para que la empresa A obtenga estadísticas agregadas sobre los clientes que se superponen dentro de un umbral de agregación mínimo.
La empresa A y la empresa B deciden colaborar para que la empresa A pueda entender la actividad de devolución de productos y ofrecer mejores productos en la empresa B y en otros canales.
Para crear la colaboración y realizar un análisis de agregación, las empresas hacen lo siguiente:
1. La empresa A crea una colaboración y crea una pertenencia. La colaboración tiene a la empresa B como otro miembro de la colaboración. La empresa A habilita el registro de consultas en la colaboración y habilita el registro de consultas en su cuenta.
1. La empresa B crea una pertenencia en la colaboración. Habilita el registro de consultas en su cuenta.
1. La empresa A crea una tabla configurada de ventas.
1. La empresa A añade la siguiente regla de análisis de agregación a la tabla configurada de ventas.
```
{
"aggregateColumns": [
{
"columnNames": [
"identifier"
],
"function": "COUNT_DISTINCT"
},
{
"columnNames": [
"purchases"
],
"function": "AVG"
},
{
"columnNames": [
"purchases"
],
"function": "SUM"
}
],
"joinColumns": [
"hashedemail"
],
"dimensionColumns": [
"demoseg",
"purchasedate",
"productline"
],
"scalarFunctions": [
"CAST",
"COALESCE",
"TRUNC"
],
"outputConstraints": [
{
"columnName": "hashedemail",
"minimum": 2,
"type": "COUNT_DISTINCT"
},
]
}
```
`aggregateColumns`: la empresa A quiere contar el número de clientes únicos que se superponen entre los datos de ventas y los datos de devoluciones. La empresa A también quiere sumar el número de `purchases` fabricados para compararlo con el número de `returns`.
`joinColumns`: la empresa A desea usar `identifier` para cotejar los clientes de los datos de ventas con los clientes de los datos de devoluciones. Esto ayudará a la empresa A a relacionar las devoluciones con las compras correctas. También ayudará a la empresa A a segmentar los clientes superpuestos.
`dimensionColumns`: la empresa A usa `dimensionColumns` para filtrar por un producto específico, comparar las compras y las devoluciones correspondientes a un periodo de tiempo determinado, asegurarse de que la fecha de devolución sea posterior a la fecha del producto y ayudar a segmentar los clientes superpuestos.
`scalarFunctions`: la empresa A selecciona la función escalar `CAST` para ayudar a actualizar los formatos de tipo de datos si es necesario, basándose en la tabla configurada que la empresa A ha asociado a la colaboración. También añade funciones escalares para ayudar a dar formato a las columnas si es necesario.
`outputConstraints`: la empresa A establece restricciones de salida mínimas. No necesita restringir los resultados, ya que el analista puede ver los datos de la tabla de ventas por fila.
**nota**
La empresa A no incluye `joinRequired` en la regla de análisis. Ofrece flexibilidad para que el analista consulte solo la tabla de ventas.
1. La empresa B crea una tabla configurada de devoluciones.
1. La empresa B añade la siguiente regla de análisis de agregación a la tabla configurada de devoluciones.
```
{
"aggregateColumns": [
{
"columnNames": [
"identifier"
],
"function": "COUNT_DISTINCT"
},
{
"columnNames": [
"returns"
],
"function": "AVG"
},
{
"columnNames": [
"returns"
],
"function": "SUM"
}
],
"joinColumns": [
"hashedemail"
],
"joinRequired": [
"QUERY_RUNNER"
],
"dimensionColumns": [
"state",
"popularpurchases",
"customerserviceuser",
"productline",
"returndate"
],
"scalarFunctions": [
"CAST",
"LOWER",
"UPPER",
"TRUNC"
],
"outputConstraints": [
{
"columnName": "hashedemail",
"minimum": 100,
"type": "COUNT_DISTINCT"
},
{
"columnName": "producttype",
"minimum": 2,
"type": "COUNT_DISTINCT"
}
]
}
```
`aggregateColumns`: la empresa B permite a la empresa A sumar las `returns` para compararlas con el número de compras. Tienen al menos una columna agregada porque han habilitado una consulta agregada.
`joinColumns`: la empresa B permite a la empresa A combinar por `identifier` para cotejar los clientes de los datos de devoluciones con los clientes de los datos de ventas. Los datos de `identifier` son especialmente sensibles, y tenerlos como `joinColumn` garantiza que los datos no se incluyan nunca en una consulta.
`joinRequired`: la empresa B impone como requisito que las consultas sobre los datos de devoluciones se superpongan con los datos de ventas. No quieren permitir que la empresa A consulte todas las personas de su conjunto de datos. También acordaron esa restricción en su contrato de colaboración.
`dimensionColumns`: la empresa B permite a la empresa A filtrar y agrupar por `state`, `popularpurchases` y `customerserviceuser`, que son atributos únicos que podrían ayudar a realizar el análisis para la empresa A. La empresa B permite a la empresa A usar `returndate` para filtrar la salida por `returndate` que sea posterior a `purchasedate`. Con este filtrado, la salida es más precisa a la hora de evaluar el impacto del cambio de producto.
`scalarFunctions`: la empresa B habilita lo siguiente:
+ TRUNC para las fechas
+ LOWER y UPPER en caso de que `producttype` se introduzca en un formato distinto en sus datos
+ CAST si la empresa A necesita convertir los tipos de datos de las ventas para que sean iguales a los tipos de datos de las devoluciones.
La empresa A no habilita otras funciones escalares porque no cree que sean necesarias para las consultas.
`outputConstraints`: la empresa B establece restricciones de salida mínimas en `hashedemail` para reducir en mayor medida la posibilidad de volver a identificar a los clientes. También añade una restricción de salida mínima en `producttype` para reducir en mayor medida la posibilidad de volver a identificar los productos específicos devueltos. Determinados tipos de productos podrían ser más dominantes en función de las dimensiones de la salida (por ejemplo, `state`). Sus restricciones de salida se aplicarán siempre, independientemente de las restricciones de salida que añada la empresa A a sus datos.
1. La empresa A crea una asociación a la tabla de ventas en la colaboración.
1. La empresa B crea una asociación a la tabla de devoluciones en la colaboración.
1. La empresa A realiza consultas, como las del ejemplo siguiente, para entender mejor la cantidad de devoluciones de la empresa B en comparación con el total de compras por ubicación en 2022.
```
SELECT
companyB.state,
SUM(companyB.returns),
COUNT(DISTINCT companyA.hashedemail)
FROM
sales companyA
INNER JOIN returns companyB ON companyA.identifier = companyB.identifier
WHERE
companyA.purchasedate BETWEEN '2022-01-01' AND '2022-12-31' AND
TRUNC(companyB.returndate) > companyA.purchasedate
GROUP BY
companyB.state;
```
1. La empresa A y la empresa B revisan los registros de consultas. La empresa B comprueba que la consulta se ajusta a lo acordado en el contrato de colaboración.
## Solución de problemas relacionados con reglas de análisis de agregación
Utilice la información que se incluye aquí para diagnosticar y solucionar problemas frecuentes cuando utilice reglas de análisis de agregación.
**Topics**
+ [Mi consulta no ha devuelto ningún resultado](#query-no-results)
### Mi consulta no ha devuelto ningún resultado
Esto puede ocurrir cuando no hay resultados coincidentes o cuando los resultados coincidentes no cumplen uno o más umbrales de agregación mínimos.
Para obtener más información sobre los umbrales de agregación mínimos, consulte [Regla de análisis de agregación: ejemplo](#agg-analysis-rule-example).
# Regla de análisis de lista
En AWS Clean Rooms, una *regla de análisis de listas* genera listas a nivel de fila de la superposición entre la tabla configurada a la que se agrega y las tablas configuradas del miembro que puede realizar la consulta. El miembro que puede realizar consultas ejecuta consultas que incluyen una regla de análisis de lista.
El tipo de regla de análisis de listas admite casos de uso como el enriquecimiento y la creación de audiencia.
Para obtener más información sobre la estructura y la sintaxis de consulta predefinidas de esta regla de análisis, consulte [Estructura predefinida de la regla de análisis de lista](#intersection-list-params-template).
Los parámetros de la regla de análisis de lista, que se define en [Regla de análisis de lista: controles de consulta](#parameters-list-query-controls), tienen controles de consulta. Estos controles de consulta incluyen la posibilidad de seleccionar las columnas que se pueden enumerar en la salida. La consulta debe tener al menos una combinación con una tabla configurada del miembro que puede realizar consultas, ya sea de forma directa o transitiva.
No hay controles de resultados de consulta como los que existen para la [regla de análisis de agregación](analysis-rules-aggregation.md).
Las consultas de lista solo pueden utilizar operadores matemáticos. No pueden usar otras funciones (por ejemplo, de agregación o escalares).
**Topics**
+ [Estructura y sintaxis de las consultas de lista](#list-query-controls)
+ [Regla de análisis de lista: controles de consulta](#parameters-list-query-controls)
+ [Estructura predefinida de la regla de análisis de lista](#intersection-list-params-template)
+ [Regla de análisis de lista: ejemplo](#list-example)
## Estructura y sintaxis de las consultas de lista
Las consultas de las tablas que tienen una regla de análisis de lista deben respetar la siguiente sintaxis.
```
--select_list_expression
SELECT DISTINCT column_name [[AS] column_alias ] [, ...]
--table_expression
FROM table_name [[AS] table_alias ]
[[INNER] JOIN table_name [[AS] table_alias] ON join_condition] [...]
--where_expression
[WHERE where_condition]
--limit_expression
[LIMIT number]
```
En la siguiente tabla se explica cada una de las expresiones enumeradas en la sintaxis anterior.
| Expression | Definición | Ejemplos |
| --- | --- | --- |
| select\$1list\$1expression | Una lista separada por comas que contiene al menos un nombre de columna de tabla. Es obligatorio un parámetro `DISTINCT`. La `select_list_expression` pueden asignar un alias a las columnas con o sin el parámetro `AS`. Para obtener más información, consulte [Referencia de SQL de AWS Clean Rooms](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html). | `SELECT DISTINCT segment` |
| table\$1expression | Una tabla, o combinación de tablas, con `join_condition` para conectarla a `join_condition`. `join_condition` devuelve un valor booleano. La `table_expression` admite: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/clean-rooms/latest/userguide/analysis-rules-list.html) | FROM consumer_table
INNER JOIN provider_table
ON
consumer_table.identifier1 = provider_table.identifier1
AND
consumer_table.identifier2 = provider_table.identifier2
|
| where\$1expression | Una expresión condicional que devuelve un valor booleano. Puede constar de los siguientes elementos:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/clean-rooms/latest/userguide/analysis-rules-list.html)Las condiciones de comparación admitidas son (`=, >, <, <=, >=, <>, !=, NOT, IN, NOT IN, LIKE, IS NULL, IS NOT NULL`). Los operadores lógicos admitidos son (`AND, OR`).La `where_expression` es opcional. | `WHERE state + '_' + city = 'NY_NYC'` `WHERE timestampColumn = timestampColumn2 - 14` |
| limit\$1expression | Esta expresión debe tener adoptar un entero positivo. La `limit_expression` es opcional. | `LIMIT 100` |
En cuanto a la estructura y sintaxis de las consultas de lista, tenga en cuenta lo siguiente:
+ No se admiten comandos SQL distintos de SELECT.
+ No se admiten subconsultas ni expresiones de tabla comunes (por ejemplo, WITH).
+ No se admiten las cláusulas HAVING, GROUP BY ni ORDER BY.
+ No se admite el parámetro OFFSET.
## Regla de análisis de lista: controles de consulta
Los controles de consulta de lista le permiten controlar cómo se utilizan las columnas de su tabla a la hora de consultar esta última. Por ejemplo, puede controlar qué columna se usa para combinar, o qué columna se puede usar en una instrucción SELECT y en una cláusula WHERE.
En las secciones siguientes se explica cada uno de los controles.
**Topics**
+ [Controles de combinación](#list-controls-join-controls)
+ [Controles de lista](#list-controls)
### Controles de combinación
Los *controles de combinación* le permiten controlar cómo se puede combinar su tabla a otras tablas en la **table\$1expression**. AWS Clean Rooms solo admite INNER JOIN. En la regla de análisis de lista, se requiere al menos una INNER JOIN, y el miembro que puede realizar consultas debe incluir una tabla de su propiedad en la INNER JOIN. Esto significa que deben combinar su tabla con la suya, ya sea de forma directa o transitiva.
A continuación se muestra un ejemplo de transitividad.
```
ON
my_table.identifer = third_party_table.identifier
....
ON
third_party_table.identifier = member_who_can_query_table.id
```
Las instrucciones INNER JOIN solo pueden usar columnas que se hayan categorizado explícitamente como `joinColumn` en la regla de análisis.
La instrucción INNER JOIN debe operar en una `joinColumn` de su tabla configurada y en una `joinColumn` de otra tabla configurada de la colaboración. Usted decide qué columnas de la tabla se pueden usar como `joinColumn`.
Cada condición de coincidencia de la cláusula ON debe utilizar la condición de comparación de igualdad (`=`) entre dos columnas.
Las condiciones de coincidencia múltiples dentro de una cláusula ON pueden ser:
+ Combinación con el operador lógico `AND`
+ Separación mediante el operador lógico `OR`
**nota**
Todas las condiciones de coincidencia JOIN deben coincidir con una fila de cada lado de JOIN. Todos los condicionales conectados por un operador lógico `OR` o `AND` también deben cumplir este requisito.
A continuación se muestra un ejemplo de consulta con un operador lógico `AND`.
```
SELECT some_col, other_col
FROM table1
JOIN table2
ON table1.id = table2.id AND table1.name = table2.name
```
A continuación se muestra un ejemplo de consulta con un operador lógico `OR`.
```
SELECT some_col, other_col
FROM table1
JOIN table2
ON table1.id = table2.id OR table1.name = table2.name
```
| Control | Definición | De uso |
| --- | --- | --- |
| joinColumns | Las columnas que se desea permitir que el miembro que puede realizar consultas utilice en la instrucción INNER JOIN. | Una misma columna no se puede categorizar como `joinColumn` y `listColumn` a la vez (consulte [Controles de lista](#list-controls)). `joinColumn` no se puede usar en ninguna otra parte de la consulta que no sea INNER JOIN. |
### Controles de lista
Los *controles de lista* controlan las columnas que se pueden mostrar en el resultado de la consulta (es decir, que se pueden usar en la instrucción SELECT) o que se pueden usar para filtrar los resultados (es decir, que se pueden usar en la instrucción WHERE).
| Control | Definición | De uso |
| --- | --- | --- |
| listColumns | Las columnas que se permite que el miembro que puede realizar consultas utilice en SELECT y WHERE | Se puede usar una listColumn en SELECT y WHERE.Una misma columna no se puede usar como `listColumn` y `joinColumn` a la vez. |
## Estructura predefinida de la regla de análisis de lista
El siguiente ejemplo incluye una estructura predefinida que muestra cómo completar una regla de análisis de lista.
En el siguiente ejemplo, *`MyTable`* hace referencia a nuestra tabla de datos. Puede reemplazar cada una de ellas *user input placeholder* con su propia información.
```
{
"joinColumns": [MyTable column name(s)],
"listColumns": [MyTable column name(s)],
}
```
## Regla de análisis de lista: ejemplo
El siguiente ejemplo demuestra cómo dos empresas pueden colaborar en el AWS Clean Rooms uso del análisis de listas.
La empresa A dispone de datos de administración de las relaciones con los clientes (CRM). La empresa A desea obtener datos de segmento adicionales sobre sus clientes para conocer mejor a estos últimos y, posiblemente, utilizar los atributos como entrada en otros análisis. La empresa B tiene datos de segmento compuestos por atributos de segmento únicos que creó basándose en sus datos de primera parte. La empresa B desea proporcionar los atributos de segmento únicos a la empresa A solo para aquellos clientes que se superponen entre sus datos y los datos de la empresa A.
Las empresas deciden colaborar para que la empresa A pueda enriquecer los datos superpuestos. La empresa A es el miembro que puede realizar consultas y la empresa B es el colaborador.
Para crear una colaboración y ejecutar en ella un análisis de lista, las empresas hacen lo siguiente:
1. La empresa A crea una colaboración y crea una pertenencia. La colaboración tiene a la empresa B como un miembro más de la colaboración. La empresa A habilita el registro de consultas en la colaboración y habilita el registro de consultas en su cuenta.
1. La empresa B crea una pertenencia en la colaboración. Habilita el registro de consultas en su cuenta.
1. La empresa A crea una tabla configurada de CRM.
1. La empresa A agrega la regla de análisis a la tabla configurada por el cliente, como se muestra en el siguiente ejemplo.
```
{
"joinColumns": [
"identifier1",
"identifier2"
],
"listColumns": [
"internalid",
"segment1",
"segment2",
"customercategory"
]
}
```
`joinColumns`— La empresa A quiere utilizarla `hashedemail` and/or `thirdpartyid` (obtenida de un proveedor de identidad) para hacer coincidir los clientes a partir de los datos de CRM con los clientes a partir de los datos segmentados. Esto ayudará a garantizar que la empresa A relacione los datos enriquecidos con los clientes correctos. Tienen dos JoinColumns para mejorar potencialmente la tasa de coincidencia del análisis.
`listColumns`: la empresa A usa `listColumns` para obtener columnas enriquecidas junto con un `internalid` que utiliza en sus propios sistemas. Añade `segment1`, `segment2` y `customercategory` para, potencialmente, limitar el enriquecimiento a segmentos específicos mediante su uso en filtros.
1. La empresa B crea una tabla configurada de segmento.
1. La empresa B añade la regla de análisis a la tabla configurada por de segmento.
```
{
"joinColumns": [
"identifier2"
],
"listColumns": [
"segment3",
"segment4"
]
}
```
`joinColumns`: la empresa B permite a la empresa A combinarse con `identifier2` para relacionar a los clientes de los datos de segmento con los datos de CRM. La empresa A y la empresa B trabajaron con el proveedor de identidades para obtener un `identifier2` que se ajustara a la colaboración. No añadieron otras `joinColumns` porque creían que `identifier2` proporciona la tasa de coincidencia más alta y precisa y que no se precisaban otros identificadores para las consultas.
`listColumns`: la empresa B permite a la empresa A enriquecer sus datos con los atributos `segment3` y `segment4`, que son atributos únicos que han creado, recopilado y alineado en (con el cliente A) para formar parte del enriquecimiento de datos. Quieren que la empresa A obtenga estos segmentos para solaparlos a nivel de fila, ya que se trata de una colaboración de enriquecimiento de datos.
1. La empresa A crea una asociación a la tabla de CRM en la colaboración.
1. La empresa B crea una asociación a la tabla de segmento en la colaboración.
1. La empresa A ejecuta consultas, como la siguiente, para enriquecer los datos de clientes que se solapan.
```
SELECT companyA.internalid, companyB.segment3, companyB.segment4
INNER JOIN returns companyB
ON companyA.identifier2 = companyB.identifier2
WHERE companyA.customercategory > 'xxx'
```
1. La empresa A y la empresa B revisan los registros de consultas. La empresa B comprueba que la consulta se ajusta a lo acordado en el contrato de colaboración.
# Regla de análisis personalizada en AWS Clean Rooms
En AWS Clean Rooms, una *regla de análisis personalizada* es un nuevo tipo de regla de análisis que permite ejecutar consultas personalizadas en la tabla configurada. Las consultas SQL personalizadas siguen restringidas a tener solo el SELECT comando, pero pueden usar más construcciones SQL que las consultas de [agregación](analysis-rules-aggregation.md#agg-query-controls) y [lista](analysis-rules-list.md#list-query-controls) (por ejemplo, funciones de ventana, OUTER JOIN o subconsultas; consulte la [Referencia de AWS Clean Rooms SQL](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html) para obtener una lista completa). CTEs Las consultas SQL personalizadas no tienen que seguir una estructura de consulta como las consultas de [agregación](analysis-rules-aggregation.md#agg-query-structure-syntax) y las consultas de [lista](analysis-rules-list.md#list-query-controls).
La regla de análisis personalizada admite casos de uso más avanzados que los que admite una regla de análisis de agregación y de lista, como análisis de atribución personalizado, análisis comparativo, análisis de incrementalidad y detección de audiencias. Esto se suma a un superconjunto de casos de uso compatibles con la regla de análisis de agregación y de lista.
La regla de análisis personalizado también admite privacidad diferencial. La privacidad diferencial es un marco matemáticamente riguroso para la protección de la privacidad de los datos. Para obtener más información, consulte [AWS Clean Rooms Privacidad diferencial](differential-privacy.md). Al crear una plantilla de análisis, AWS Clean Rooms Differential Privacy comprueba la plantilla para determinar si es compatible con la estructura de consultas de uso general de Differential Privacy. AWS Clean Rooms Esta validación garantiza que no se cree una plantilla de análisis que no esté permitida con una tabla con protección de privacidad diferencial.
Para configurar la regla de análisis personalizada, los propietarios de los datos pueden optar por permitir que determinadas consultas personalizadas, almacenadas en [plantillas de análisis](create-analysis-template.md), se ejecuten en sus tablas configuradas. Los propietarios de los datos revisan las plantillas de análisis antes de añadirlas al control de análisis permitido en la regla de análisis personalizada. Las plantillas de análisis están disponibles y visibles solo en la colaboración en la que se crean (incluso si la tabla está asociada a otras colaboraciones) y solo las puede ejecutar el miembro que pueda realizar consultas en esa colaboración.
Como alternativa, los miembros pueden optar por permitir que otros miembros (proveedores de consultas) creen consultas sin revisión. Los miembros añaden las cuentas de proveedores de consultas que los proveedores de consultas permitidos pueden controlar en la regla de análisis personalizada. Si el proveedor de consultas es el miembro que puede realizar la consulta, este puede ejecutar cualquier consulta directamente en la tabla configurada. Los proveedores de consultas también pueden crear consultas mediante la [creación de plantillas de análisis](create-analysis-template.md). Todas las consultas que hayan creado los proveedores de consultas pueden ejecutarse automáticamente en la tabla en todas las colaboraciones en las que Cuenta de AWS esté presente y la tabla esté asociada.
Los propietarios de los datos solo pueden permitir que las plantillas de análisis o las cuentas creen consultas, pero no ambas. Si el propietario de los datos lo deja en blanco, el miembro que puede realizar la consulta no puede ejecutar consultas en la tabla configurada.
**Topics**
+ [Estructura predefinida de la regla de análisis personalizada](#custom-predefined-structure)
+ [Ejemplo de regla de análisis personalizada](#custom-example)
+ [Regla de análisis personalizada con privacidad diferencial](#custom-diff-privacy)
## Estructura predefinida de la regla de análisis personalizada
El siguiente ejemplo incluye una estructura predefinida que muestra cómo completar una regla de análisis personalizada con la privacidad diferencia activada. El valor `userIdentifier` es la columna que identifica de forma exclusiva a los usuarios, como *user\$1id*. Cuando se activan dos o más tablas con la privacidad diferencial activada en una colaboración, AWS Clean Rooms requiere que configure la misma columna que la columna del identificador de usuario en ambas reglas de análisis para mantener una definición coherente de los usuarios en todas las tablas.
```
{
"allowedAnalyses": ["ANY_QUERY"] | string[],
"allowedAnalysisProviders": [],
"differentialPrivacy": {
"columns": [
{
"name": "userIdentifier"
}
]
}
}
```
Puede:
+ Agregue una plantilla de análisis ARNs para permitir el control de los análisis. En este caso, el control `allowedAnalysisProviders` no está incluido.
```
{
allowedAnalyses: string[]
}
```
+ Agregue un miembro Cuenta de AWS IDs al `allowedAnalysisProviders` control. En este caso, se añade `ANY_QUERY` al control `allowedAnalyses`.
```
{
allowedAnalyses: ["ANY_QUERY"],
allowedAnalysisProviders: string[]
}
```
## Ejemplo de regla de análisis personalizada
El siguiente ejemplo demuestra cómo dos empresas pueden colaborar en el AWS Clean Rooms uso de la regla de análisis personalizada.
La empresa A tiene datos de clientes y de ventas. La empresa A está interesada en conocer la incrementalidad de las ventas de una campaña publicitaria en el sitio de la empresa B. La empresa B tiene datos de visualizaciones y atributos de segmento que son útiles para la empresa (por ejemplo, el dispositivo utilizado para ver la publicidad).
La empresa A tiene una consulta de incrementalidad específica que quiere ejecutar en la colaboración.
Para crear una colaboración y ejecutar en ella un análisis personalizado, las empresas hacen lo siguiente:
1. La empresa A crea una colaboración y crea una pertenencia. La colaboración tiene a la empresa B como un miembro más de la colaboración. La empresa A habilita el registro de consultas en la colaboración y habilita el registro de consultas en su cuenta.
1. La empresa B crea una pertenencia en la colaboración. Habilita el registro de consultas en su cuenta.
1. La empresa A crea una tabla configurada de CRM.
1. La empresa A añade una regla de análisis personalizada vacía a la tabla de ventas configurada.
1. La empresa A asocia la tabla configurada de ventas a la colaboración.
1. La empresa B crea una tabla configurada de visualizaciones.
1. La empresa B agrega una regla de análisis personalizada vacía a la tabla configurada de visualizaciones.
1. La empresa B asocia la tabla configurada de visualizaciones a la colaboración.
1. La empresa A visualiza la tabla de ventas y la tabla de visualizaciones asociada a la colaboración y crea una plantilla de análisis, añadiendo la consulta de incrementalidad y el parámetro para el mes de la campaña.
```
{
"analysisParameters": [
{
"defaultValue": ""
"type": "DATE"
"name": "campaign_month"
}
],
"description": "Monthly incrementality query using sales and viewership data"
"format": "SQL"
"name": "Incrementality analysis"
"source":
"WITH labeleddata AS
(
SELECT hashedemail, deviceid, purchases, unitprice, purchasedate,
CASE
WHEN testvalue IN ('value1', 'value2', 'value3') THEN 0
ELSE 1
END AS testgroup
FROM viewershipdata
)
SELECT labeleddata.purchases, provider.impressions
FROM labeleddata
INNER JOIN salesdata
ON labeleddata.hashedemail = provider.hashedemail
WHERE MONTH(labeleddata.purchasedate) > :campaignmonth
AND testgroup = :group
"
}
```
1. La empresa A agrega la cuenta (por ejemplo, 444455556666) al control del proveedor de análisis permitido en la regla de análisis personalizada. Utilizan el control de proveedor de análisis permitido porque quieren permitir que las consultas que creen se ejecuten en su tabla configurada de ventas.
```
{
"allowedAnalyses": [
"ANY_QUERY"
],
"allowedAnalysisProviders": [
"444455556666"
]
}
```
1. La empresa B ve la plantilla de análisis creada en la colaboración y revisa su contenido, incluidos la cadena de consulta y el parámetro.
1. La empresa B determina que la plantilla de análisis cumple con el caso de uso de incrementalidad y cumple con sus requisitos de privacidad en cuanto a la forma en que se puede consultar su tabla configurada de visualizaciones.
1. La empresa B agrega la plantilla de análisis ARN al control de análisis permitido en la regla de análisis personalizada de la tabla de visualizaciones. Utilizan el control de análisis permitido porque solo quieren permitir que la consulta de incrementalidad se ejecute en su tabla configurada de visualizaciones.
```
{
"allowedAnalyses": [
"arn:aws:cleanrooms:us-east-1:111122223333:membership/41327cc4-bbf0-43f1-b70c-a160dddceb08/analysistemplate/1ff1bf9d-781c-418d-a6ac-2b80c09d6292"
]
}
```
1. La empresa A ejecuta la plantilla de análisis y utiliza el valor del parámetro `05-01-2023`.
## Regla de análisis personalizada con privacidad diferencial
En AWS Clean Rooms, la regla de análisis personalizado admite la privacidad diferencial. La privacidad diferencial es un marco matemáticamente riguroso para la protección de la privacidad de los datos que le ayuda a proteger sus datos contra los intentos de reidentificación.
La privacidad diferencial permite el análisis agregado, como la planificación de campañas publicitarias, la post-ad-campaign medición, la evaluación comparativa en un consorcio de instituciones financieras y las pruebas A/B para la investigación sanitaria.
La estructura y sintaxis de consulta admitidas se definen en [Estructura y sintaxis de las consultas](#dp-query-structure-syntax).
### Regla de análisis personalizada con privacidad diferencial
**nota**
AWS Clean Rooms La privacidad diferencial solo está disponible para las colaboraciones en las que los datos se almacenan en Amazon S3.
Analice el [ejemplo de regla de análisis personalizado](#custom-example) que se presenta en la sección anterior. En este ejemplo se demuestra cómo puede utilizar la privacidad diferencial para proteger sus datos frente a intentos de reidentificación y, al mismo tiempo, permitir que su socio obtenga información crítica para la empresa a partir de sus datos. Supongamos que la empresa B, que tiene los datos de audiencia, quiere proteger sus datos con una privacidad diferencial. Para completar la configuración de privacidad diferencial, la empresa B realiza los siguientes pasos:
1. La empresa B activa la privacidad diferencial mientras añade una regla de análisis personalizada a la tabla configurada de visualizaciones. La empresa B selecciona `viewershipdata.hashedemail` como columna de identificador de usuario.
1. La empresa B [añade una política de privacidad diferencial](configure-differential-privacy.md) a la colaboración para que su tabla de datos de audiencia esté disponible para su consulta. La empresa B selecciona la política predeterminada para completar rápidamente la configuración.
La empresa A, que desea comprender la incrementalidad de ventas de una campaña publicitaria en el sitio de la empresa B, utiliza la plantilla de análisis. Como la consulta es compatible con la [estructura](#dp-query-structure-syntax) de consulta de uso general de AWS Clean Rooms Differential Privacy, la consulta se ejecuta correctamente.
### Estructura y sintaxis de las consultas
Las consultas que contengan al menos una tabla y que tengan activada la privacidad diferencial deben seguir la siguiente sintaxis.
```
query_statement:
[cte, ...] final_select
cte:
WITH sub_query AS (
inner_select
[ UNION | INTERSECT | UNION_ALL | EXCEPT/MINUS ]
[ inner_select ]
)
inner_select:
SELECT [user_id_column, ] expression [, ...]
FROM table_reference [, ...]
[ WHERE condition ]
[ GROUP BY user_id_column[, expression] [, ...] ]
[ HAVING condition ]
final_select:
SELECT [expression, ...] | COUNT | COUNT_DISTINCT | SUM | AVG | STDDEV
FROM table_reference [, ...]
[ WHERE condition ]
[ GROUP BY expression [, ...] ]
[ HAVING COUNT | COUNT_DISTINCT | SUM | AVG | STDDEV | condition ]
[ ORDER BY column_list ASC | DESC ]
[ OFFSET literal ]
[ LIMIT literal ]
expression:
column_name [, ...] | expression AS alias | aggregation_functions | window_functions_on_user_id | scalar_function | CASE | column_name math_expression [, expression]
window_functions_on_user_id:
function () OVER (PARTITION BY user_id_column, [column_name] [ORDER BY column_list ASC|DESC])
```
**nota**
En cuanto a la estructura y sintaxis de las consultas de privacidad diferencial, tenga en cuenta lo siguiente:
No se admiten las subconsultas.
Las expresiones de tabla comunes (CTEs) deberían emitir la columna de identificador de usuario si una tabla o un CTE incluyen datos protegidos por una privacidad diferencial. Los filtros, agrupaciones y agregaciones deben realizarse en el nivel de usuario.
Final\$1select permite las funciones de agregación COUNT DISTINCT, COUNT, SUM, AVG y STDDEV.
Para obtener más información sobre qué palabras clave de SQL se admiten para una privacidad diferencial, consulte [Capacidades SQL de AWS Clean Rooms Differential Privacy](dp-sql-capabilities.md).
# Regla de análisis de tablas de asignación de ID
En AWS Clean Rooms, una *regla de análisis de tablas de mapeo de ID* no es una regla de análisis independiente. Este tipo de regla de análisis se administra mediante datos de identidad dispares AWS Clean Rooms y se utiliza para unirlos a fin de facilitar las consultas. Se agrega automáticamente a las tablas de asignación de ID y no se puede editar. Hereda los comportamientos de las demás reglas de análisis de la colaboración, siempre que esas reglas de análisis sean homogéneas.
La regla de análisis de la tabla de asignación de ID refuerza la seguridad en una tabla de asignación de ID. Impide que un miembro de la colaboración seleccione o inspeccione directamente la población no superpuesta entre los conjuntos de datos de los dos miembros mediante la tabla de asignación de ID. La regla de análisis de la tabla de asignación de ID se usa para proteger la información confidencial de la tabla de asignación de ID cuando se usa implícitamente en consultas con otras reglas de análisis.
Con la regla de análisis de la tabla de mapeo de ID, se AWS Clean Rooms impone una superposición en ambos lados de la tabla de mapeo de ID en el SQL expandido. Esto le permite realizar las siguientes tareas:
+ Utilice la superposición de la tabla de asignación de ID en las declaraciones JOIN.
AWS Clean Rooms permite una INNER o una RIGHT unión en la tabla de mapeo de ID si respeta la superposición. LEFT Para proteger la información de mapeo confidencial, la tabla de mapeo de ID siempre debe estar en el lado inner «» de cualquier JOIN operación. Por ejemplo, las siguientes JOIN operaciones son válidas:
+ table LEFT JOIN id\$1mapping\$1table
+ id\$1mapping\$1table RIGHT JOIN table
+ table INNER JOIN id\$1mapping\$1table
Las siguientes JOIN operaciones no son válidas:
+ id\$1mapping\$1table LEFT JOIN table
+ table RIGHT JOIN id\$1mapping\$1table
Esto evita la exposición de los registros de mapeo que no tienen las coincidencias correspondientes en su conjunto de datos. Permitir este tipo de operaciones podría revelar información confidencial sobre las asignaciones de datos de otros miembros de la colaboración.
+ Utilice las columnas de la tabla de asignación en las declaraciones JOIN.
No puede usar las columnas de la tabla de asignación en las siguientes declaraciones: SELECT, WHERE, HAVING, GROUP BY o ORDER BY (a menos que se modifiquen las protecciones en la asociación del espacio de nombres del ID de origen o la asociación del espacio de nombres del ID de destino).
+ En el SQL expandido, AWS Clean Rooms también es compatible con las versiones implícita OUTER JOIN y CROSSJOIN. JOIN Estas uniones no pueden satisfacer los requisitos de superposición. En su lugar, `requireOverlap` se AWS Clean Rooms utiliza para especificar en qué columnas se deben unir.
La estructura y la sintaxis de consulta admitidas se definen en [Estructura y sintaxis de consultas de la tabla de asignación de ID](#id-mapping-table-query-controls).
Los parámetros de la regla de análisis, definidos en [Controles de consulta de reglas de análisis de tablas de asignación de ID](#parameters-id-mapping-query-controls), incluyen los controles de consulta y los controles de resultados de las consultas. Sus controles de consulta incluyen la posibilidad de requerir la superposición de la tabla de asignación de ID en las instrucciones JOIN (es decir, `requireOverlap`).
**Topics**
+ [Estructura y sintaxis de consultas de la tabla de asignación de ID](#id-mapping-table-query-controls)
+ [Controles de consulta de reglas de análisis de tablas de asignación de ID](#parameters-id-mapping-query-controls)
+ [Estructura predefinida de la regla de análisis de tablas de asignación de ID](#id-mapping-table-predefined-structure)
+ [Regla de análisis de tablas de asignación de ID: ejemplo](#id-mapping-table-example)
## Estructura y sintaxis de consultas de la tabla de asignación de ID
Las consultas en tablas que tienen una regla de análisis de tabla de asignación de ID deben respetar la siguiente sintaxis.
```
--select_list_expression
SELECT
provider.data_col, consumer.data_col
--table_expression
FROM provider
JOIN idMappingTable idmt ON provider.id = idmt.sourceId
JOIN consumer ON consumer.id = idmt.targetId
```
### Tablas de colaboración
Las siguientes tablas representan las tablas configuradas que existen en una AWS Clean Rooms colaboración. La columna de **ID** en las tablas **cr\$1drivers\$1license** y **cr\$1insurance** representa una columna que coincide con la tabla de asignación de ID.
**cr\$1drivers\$1license**
| | | |
| --- |--- |--- |
| id | nombre\$1del\$1conductor | estado\$1de\$1registro |
| 1 | Eduard | TX |
| 2 | Dana | MA |
| 3 | Gweneth | IL |
**cr\$1insurance**
| | | |
| --- |--- |--- |
| id | policyholder\$1email | número\$1política |
| a | eduardo@internal.company.com | 17f9d04e-f5be-4426-bdc4-250ed59c6529 |
| b | gwen@internal.company.com | 3f0092db-2316-48a8-8d44-09cf8f6e6c64 |
| c | rosa@internal.company.com | d7692e84-3d3c-47b8-b46d-a0d5345f0601 |
### tabla de asignación de ID
La siguiente tabla representa una tabla de asignación de ID existente que coincide con las tablas **cr\$1drivers\$1license** y **cr\$1insurance**. No todas las entradas serán válidas para ambas tablas de colaboración. IDs
| | |
| --- |--- |
| cr\$1drivers\$1license\$1id | cr\$1insurance\$1id |
| 1 | a |
| 2 | null |
| 3 | b |
| null | c |
La regla de análisis de la tabla de asignación de ID solo permite que las consultas se ejecuten en el conjunto de datos superpuestos, que tendría el siguiente aspecto:
| | | | | | |
| --- |--- |--- |--- |--- |--- |
| cr\$1drivers\$1license\$1id | cr\$1insurance\$1id | nombre\$1del\$1conductor | estado\$1de\$1registro | policyholder\$1email | número\$1política |
| 1 | a | Eduard | TX | eduardo@internal.company.com | 17f9d04e-f5be-4426-bdc4-250ed59c6529 |
| 3 | b | Gweneth | IL | gwen@internal.company.com | 3f0092db-2316-48a8-8d44-09cf8f6e6c64 |
### Consultas de ejemplo
Los siguientes ejemplos muestran ubicaciones válidas para las uniones de la tabla de asignación de ID:
```
-- Single ID mapping table
SELECT
[ select_items ]FROM
cr_drivers_license cr_dl
[ INNER | LEFT ] JOIN cr_identity_mapping_table idmt ON idmt.cr_drivers_license_id = cr_dl.id
[ INNER | RIGHT ] JOIN cr_insurance cr_in ON idmt.cr_insurance_id = cr_in.id
;
-- Single ID mapping table (Subquery)
SELECT
[ select_items ]FROM (
SELECT
[ select_items ]
FROM
cr_drivers_license cr_dl
[ INNER | LEFT ] JOIN cr_identity_mapping_table idmt ON idmt.cr_drivers_license_id = cr_dl.id
[ INNER | RIGHT ] JOIN cr_insurance cr_in ON idmt.cr_insurance_id = cr_in.id
)
;
-- Single ID mapping table (CTE)
WITH
matched_ids AS (
SELECT
[ select_items ]
FROM
cr_drivers_license cr_dl
[ INNER | LEFT ] JOIN cr_identity_mapping_table idmt ON idmt.cr_drivers_license_id = cr_dl.id
[ INNER | RIGHT ] JOIN cr_insurance cr_in ON idmt.cr_insurance_id = cr_in.id
)SELECT
[ select_items ]FROM
matched_ids
;
```
### Consideraciones
Para la estructura y sintaxis de las consultas de tabla de asignación de ID, tenga en cuenta lo siguiente:
+ No puede editarlo.
+ Se aplica a la tabla de asignación de ID de forma predeterminada.
+ Utiliza una asociación de espacio de nombres de ID de origen y destino dentro de la colaboración.
+ La tabla de asignación de ID está configurada de forma predeterminada para proporcionar protecciones predeterminadas para la columna que proviene del espacio de nombres de ID. Puede modificar esta configuración para que la columna que proviene del espacio de nombres de ID (`sourceID` o `targetID`) se pueda permitir en cualquier parte de la consulta. Para obtener más información, consulte [Espacios de nombres de ID en AWS Clean Rooms](working-with-id-namespaces.md).
+ La regla de análisis de la tabla de asignación de ID hereda las restricciones de SQL de las demás reglas de análisis de la colaboración.
## Controles de consulta de reglas de análisis de tablas de asignación de ID
Con los controles de consulta de tablas de mapeo de ID, controla cómo se utilizan las columnas de la tabla para consultarla. AWS Clean Rooms Por ejemplo, controla qué columnas se utilizan para unir y qué columnas deben superponerse. La regla de análisis de tablas de asignación de ID también incluye una funcionalidad que le permite proyectar `sourceID`, `targetID` o ambas sin necesidad de JOIN.
La tabla siguiente explica cada control.
| Control | Definición | De uso |
| --- | --- | --- |
| joinColumns | Las columnas que el miembro que puede realizar consultas puede usar en la instrucción INNER JOIN. | No puede usar joinColumns en ninguna otra parte de la consulta que no sea INNER JOIN.Para obtener más información, consulte [Controles de combinación](analysis-rules-aggregation.md#join-controls). |
| dimensionColumns | Las columnas (si las hay) que el miembro que puede realizar consultas puede utilizar en las instrucciones SELECT y GROUP BY. | Se puede usar una `dimensionColumn` en SELECT y GROUP BY. Puede aparecer una `dimensionColumn` como `joinKeys`. Solo puede utilizar `dimensionColumns` en la cláusula JOIN si la especifica entre paréntesis. |
| queryContraints:RequireOverlap | Las columnas de la tabla de asignación de ID que se deben unir para que se pueda ejecutar la consulta. | Estas columnas se deben usar para UNIR la tabla de asignación de ID y una tabla de colaboración. |
## Estructura predefinida de la regla de análisis de tablas de asignación de ID
La estructura predefinida para una regla de análisis de tablas de asignación de ID incluye protecciones predeterminadas que se aplican a `sourceID` y `targetID`. Esto significa que la columna con las protecciones aplicadas se debe usar en las consultas.
Puede configurar la regla de análisis de la tabla de asignación de ID de las siguientes maneras:
+ `sourceID` y `targetID` protegidos
En esta configuración, no se pueden proyectar `sourceID` y `targetID`. `sourceID` y `targetID` se deben usar en una instrucción JOIN cuando se hace referencia a la tabla de asignación de ID.
+ Solo `targetID` protegido
En esta configuración, `targetID` no se puede proyectar. `targetID` se debe usar en una instrucción JOIN cuando se hace referencia a la tabla de asignación de ID. `sourceID` se puede usar en una consulta.
+ Solo `sourceID` protegido
En esta configuración, `sourceID` no se puede proyectar. `sourceID` se debe usar en una instrucción JOIN cuando se hace referencia a la tabla de asignación de ID. `targetID` se puede usar en una consulta.
+ Ningún `sourceID` o `targetID` protegido
En esta configuración, la tabla de asignación de ID no está sujeta a ninguna aplicación específica que pueda usarse en una consulta.
El siguiente ejemplo muestra una estructura predefinida para una regla de análisis de tablas de asignación de ID con las protecciones predeterminadas que se aplican a `sourceID` y `targetID`. En este ejemplo, la regla de análisis de la tabla de asignación de ID solo permite una instrucción INNER JOIN en la columna `sourceID` y en la columna `targetID`.
```
{
"joinColumns": [
"source_id",
"target_id"
],
"queryConstraints": [
{
"requireOverlap": {
"columns": [
"source_id",
"target_id"
]
}
}
],
"dimensionColumns": [] // columns that can be used in SELECT and JOIN
}
```
El siguiente ejemplo muestra una estructura predefinida para una regla de análisis de tablas de asignación de ID con las protecciones que se aplican a `targetID`. En este ejemplo, la regla de análisis de la tabla de asignación de ID solo permite una instrucción INNER JOIN en la columna `sourceID`.
```
{
"joinColumns": [
"source_id",
"target_id"
],
"queryConstraints": [
{
"requireOverlap": {
"columns": [
"target_id"
]
}
}
],
"dimensionColumns": [
"source_id"
]
}
```
El siguiente ejemplo muestra una estructura predefinida para una regla de análisis de tablas de asignación de ID con las protecciones que se aplican a `sourceID`. En este ejemplo, la regla de análisis de la tabla de asignación de ID solo permite una instrucción INNER JOIN en la columna `targetID`.
```
{
"joinColumns": [
"source_id",
"target_id"
],
"queryConstraints": [
{
"requireOverlap": {
"columns": [
"source_id"
]
}
}
],
"dimensionColumns": [
"target_id"
]
}
```
El siguiente ejemplo muestra una estructura predefinida para una regla de análisis de tablas de asignación de ID sin las protecciones que se aplican a `sourceID` o `targetID`. En este ejemplo, la regla de análisis de la tabla de asignación de ID permite una instrucción INNER JOIN en la columna `sourceID` y en la columna `targetID`.
```
{
"joinColumns": [
"source_id",
"target_id"
],
"queryConstraints": [
{
"requireOverlap": {
"columns": []
}
}
],
"dimensionColumns": [
"source_id",
"target_id"
]
}
```
## Regla de análisis de tablas de asignación de ID: ejemplo
En lugar de escribir una larga declaración en cascada que haga referencia a la información de identificación personal (PII), por ejemplo, las empresas pueden utilizar la regla de análisis de la tabla de mapeo de identificadores para utilizar la transcodificación LiveRamp multipartita. El siguiente ejemplo demuestra cómo puede colaborar en el AWS Clean Rooms uso de la regla de análisis de tablas de mapeo de ID.
La empresa A es un anunciante que tiene datos de clientes y ventas, que se utilizarán como origen. La empresa A también realiza la transcodificación en nombre de las partes de la colaboración y aporta las LiveRamp credenciales.
La empresa B es un publicador que tiene datos de eventos, que se utilizarán como destino.
**nota**
La empresa A o la empresa B pueden proporcionar las credenciales de LiveRamp transcodificación y realizar la transcodificación.
Para crear una colaboración que permita el análisis de tablas de asignación de ID en colaboración, las empresas hacen lo siguiente:
1. La empresa A crea una colaboración y crea una pertenencia. Se agrega la empresa B, que también crea una suscripción en la colaboración.
1. La empresa A asocia una fuente de espacio de nombres de ID existente o crea una nueva mediante la consola. AWS Entity Resolution AWS Clean Rooms
La empresa A crea una tabla configurada con sus datos de ventas y una columna vinculada a `sourceId` en la tabla de asignación de ID.
El origen del espacio de nombres de ID proporciona datos para la transcodificación.
1. La empresa B asocia un destino de espacio de nombres de ID existente o crea uno nuevo mediante la consola. AWS Entity Resolution AWS Clean Rooms
La empresa B crea una tabla configurada con sus datos de eventos y una columna vinculada a `targetId` en la tabla de asignación de ID.
El destino del espacio de nombres de ID no proporciona datos para transcodificar, solo metadatos relacionados con la configuración. LiveRamp
1. La empresa A descubre los dos espacios de nombres de ID asociados a la colaboración y crea y completa una tabla de asignación de ID.
1. La empresa A ejecuta una consulta en los dos conjuntos de datos mediante la unión en la tabla de asignación de ID.
```
--- this would be valid for Custom or List
SELECT provider.data_col, consumer.data_col
FROM provider
JOIN idMappingTable-123123123123-myMappingWFName idmt
ON provider.id = idmt.sourceId
JOIN consumer
ON consumer.id = idmt.targetId
```
# AWS Clean Rooms Privacidad diferencial
AWS Clean Rooms La privacidad diferencial le ayuda a proteger la privacidad de sus usuarios con una técnica respaldada matemáticamente que se implementa con controles intuitivos en unos pocos clics. Al tratarse de una funcionalidad totalmente gestionada, no es necesario tener experiencia previa en materia de privacidad diferencial para evitar que los usuarios vuelvan a identificarse. AWS Clean Rooms añade automáticamente una cantidad de ruido cuidadosamente calibrada a los resultados de las consultas en tiempo de ejecución para ayudar a proteger sus datos a nivel individual.
AWS Clean Rooms Differential Privacy admite una amplia gama de consultas analíticas y es ideal para una amplia variedad de casos de uso, en los que un pequeño error en los resultados de la consulta no comprometa la utilidad del análisis. Con él, sus socios pueden generar información crítica para la empresa sobre campañas publicitarias, decisiones de inversión, investigaciones clínicas y mucho más, todo ello sin necesidad de ninguna configuración adicional por parte de sus socios.
AWS Clean Rooms Differential Privacy protege contra errores de conversión excesivos o inválidos que utilizan funciones escalares o símbolos de operadores matemáticos de forma malintencionada.
Para obtener más información sobre la privacidad AWS Clean Rooms diferencial, consulte los siguientes temas.
**Topics**
+ [Privacidad diferencial](#dp-overview)
+ [Cómo funciona Differential Privacy in AWS Clean Rooms](#dp-how-it-works)
+ [Política de privacidad diferencial](dp-settings.md)
+ [Capacidades SQL de AWS Clean Rooms Differential Privacy](dp-sql-capabilities.md)
+ [Consejos y ejemplos de consultas sobre privacidad diferencial](dp-query-tips-examples.md)
+ [Limitaciones de la AWS Clean Rooms privacidad diferencial](dp-limitations.md)
## Privacidad diferencial
La privacidad diferencial solo permite obtener información agregada y oculta la contribución de los datos de cualquier persona a esa información. La privacidad diferencial protege los datos de la colaboración para que el miembro pueda obtener resultados al aprender sobre una persona específica. Sin una privacidad diferencial, el miembro que puede recibir los resultados puede intentar deducir los datos de un usuario individual añadiendo o quitando registros sobre una persona y observando la diferencia en los resultados de las consultas.
Cuando se activa la privacidad diferencial, se añade una cantidad específica de ruido a los resultados de la consulta para ocultar la contribución de los usuarios individuales. Si el miembro que puede recibir los resultados intenta observar la diferencia en los resultados de la consulta después de eliminar los registros sobre una persona de su conjunto de datos, la variabilidad del resultado de la consulta ayuda a impedir la identificación de los datos de la persona. AWS Clean Rooms Differential Privacy utiliza el [SampCert](https://github.com/leanprover/SampCert)muestreador, una implementación comprobada y correcta desarrollada por. AWS
## Cómo funciona Differential Privacy in AWS Clean Rooms
El flujo de trabajo para activar la privacidad diferencial AWS Clean Rooms requiere los siguientes pasos adicionales al [completar el flujo de trabajo para AWS Clean Rooms](what-is.md#how-it-works):
1. La privacidad diferencial se activa al añadir una [regla de análisis personalizada](analysis-rules-custom.md).
1. [Puede configurar la política de privacidad diferencial de la colaboración](configure-differential-privacy.md) para que las tablas de datos protegidas con privacidad diferencial estén disponibles para su consulta.
Tras completar estos pasos, el miembro que pueda realizar la consulta podrá empezar a ejecutar consultas sobre datos protegidos por la privacidad diferencial. AWS Clean Rooms devuelve resultados que cumplen con la política de privacidad diferencial. AWS Clean Rooms Differential Privacy registra el número estimado de consultas pendientes que puede ejecutar, de forma similar al indicador de combustible de un automóvil que muestra el nivel de combustible actual del automóvil. El número de consultas que puede ejecutar el miembro que puede realizar la consulta está limitado por los parámetros **Presupuesto de privacidad** y el **Ruido añadido por consulta** establecidos en [Política de privacidad diferencial](dp-settings.md).
### Consideraciones
Cuando utilices la privacidad diferencial en AWS Clean Rooms, ten en cuenta lo siguiente:
+ El miembro que puede recibir los resultados no puede usar la privacidad diferencial. Configurará una regla de análisis personalizada con la privacidad diferencial desactivada para las tablas configuradas.
+ El miembro que puede realizar consultas no puede unir tablas de dos o más proveedores de datos cuando ambos tienen activada la privacidad diferencial.
# Política de privacidad diferencial
La política de privacidad diferencial controla cuántas funciones de agregación puede ejecutar el miembro que puede realizar la consulta en una colaboración. El **Presupuesto de privacidad** define un recurso común y limitado que se aplica a todas las tablas durante una colaboración. El **Ruido agregado por consulta** determina la velocidad a la que se agota el presupuesto de privacidad.
Es necesaria una política de privacidad diferencial para que las tablas con protección de privacidad diferencial estén disponibles para su consulta. Se trata de un paso único en una colaboración e incluye dos entradas:
+ **Presupuesto de privacidad**: cuantificado en términos de épsilon, el presupuesto de privacidad controla el nivel de protección de la privacidad. Se trata de un recurso común y limitado que se aplica a todas las tablas protegidas con privacidad diferencial durante la colaboración, ya que el objetivo es conservar la privacidad de los usuarios, cuya información puede estar presente en varias tablas.
El **presupuesto de privacidad** se consume cada vez que se ejecuta una consulta en las tablas. Cuando el presupuesto de privacidad se agote por completo, el miembro de la colaboración que puede realizar consultas no podrá ejecutar consultas adicionales hasta que se aumente o actualice. Al establecer un presupuesto de privacidad mayor, el miembro que puede recibir los resultados puede reducir su incertidumbre acerca de las personas que contienen los datos. Elija un presupuesto de privacidad que equilibre sus requisitos de colaboración con sus necesidades de privacidad y tras consultar con los responsables de la toma de decisiones empresariales.
Si tiene previsto incorporar nuevos datos a la colaboración de forma periódica, puede seleccionar **Actualización mensual del presupuesto de privacidad** para crear automáticamente un nuevo presupuesto de privacidad cada mes natural. Al elegir esta opción, se mostrarán cantidades arbitrarias de información sobre las filas de datos cuando se consulten repetidamente durante las actualizaciones. Evite elegir esta opción si se van a consultar repetidamente las mismas filas entre las actualizaciones del presupuesto de privacidad.
+ El **Ruido agregado por consulta** se mide en función del número de usuarios cuyas contribuciones desea ocultar. Este valor determina el ritmo al que se agota el presupuesto de privacidad. Un valor de ruido mayor reduce el ritmo al que se agota el presupuesto de privacidad y, por lo tanto, permite ejecutar más consultas sobre los datos. Sin embargo, esto debe equilibrarse con la publicación de información de datos menos precisa. Al establecer este valor, tenga en cuenta la precisión deseada para obtener información sobre la colaboración.
Puede usar la política de privacidad diferencial predeterminada para completar rápidamente la configuración o personalizar su política de privacidad diferencial según su caso de uso. AWS Clean Rooms Differential Privacy proporciona controles intuitivos para configurar la política. AWS Clean Rooms Differential Privacy le permite obtener una vista previa de la utilidad en términos del número de agregaciones posibles en todas las consultas de sus datos y estimar el número de consultas que se pueden ejecutar en una colaboración de datos.
Puede utilizar los ejemplos interactivos para comprender cómo los distintos valores de **Presupuesto de privacidad** y **Ruido añadido por consulta** afectarían a los resultados de los distintos tipos de consultas SQL. En general, es necesario equilibrar sus necesidades de privacidad con el número de consultas que desea permitir y la precisión de esas consultas. Un menor **Presupuesto de privacidad** o un mayor **Ruido añadido por consulta** puede proteger mejor la privacidad de los usuarios, pero proporciona información menos significativa a sus socios de colaboración.
Si aumenta el **Presupuesto de privacidad** y mantiene igual el parámetro **Ruido añadido por consulta**, el miembro que pueda realizar la consulta podrá ejecutar más agregaciones en sus tablas durante la colaboración. Puede aumentar el **Presupuesto de privacidad** en cualquier momento durante la colaboración. Si reduce el **Presupuesto de privacidad** y mantiene igual el parámetro **Ruido añadido por consulta**, el miembro que pueda realizar la consulta podrá ejecutar menos agregaciones. No puede reducir el **Presupuesto de privacidad** una vez que el miembro que puede realizar la consulta haya empezado a analizar sus datos.
Si aumenta el **Ruido añadido por consulta** y mantiene igual la entrada de **Presupuesto de privacidad**, el miembro que pueda realizar la consulta podrá ejecutar más agregaciones en sus tablas durante la colaboración. Si reduce el **Ruido añadido por consulta** y mantiene igual la entrada en de **Presupuesto de privacidad**, el miembro que pueda realizar la consulta podrá ejecutar menos agregaciones. Puede aumentar o disminuir el **Ruido agregado por consulta** en cualquier momento durante la colaboración.
La política de privacidad diferencial se gestiona mediante las acciones de la API de la plantilla de presupuesto de privacidad.
# Capacidades SQL de AWS Clean Rooms Differential Privacy
AWS Clean Rooms Differential Privacy utiliza una estructura de consultas de uso general para admitir consultas SQL complejas. Las plantillas de análisis personalizadas se validan según esta estructura para garantizar que se puedan ejecutar en tablas protegidas por privacidad diferencial. En la siguiente tabla se indican las funciones compatibles. Para obtener más información, consulte [Estructura y sintaxis de las consultas](analysis-rules-custom.md#dp-query-structure-syntax).
| Categoría | El motor de análisis Spark admite construcciones SQL | Expresiones de tabla comunes () CTEs | Una cláusula SELECT final |
| --- |--- |--- |--- |
| Funciones de agregación | Función ANY\$1VALUE Función APPROXIMATE PERCENTILE\$1DISC Función AVG Funciones COUNT y COUNT DISTINCT Función MAX Función MEDIAN Función MIN Función PERCENTILE\$1CONT Funciones STDDEV\$1SAMP y STDDEV\$1POP Funciones SUM y SUM DISTINCT Funciones VAR\$1SAMP y VAR\$1POP | Se admiten con la condición de que el CTEs uso de tablas con protección de privacidad diferencial debe generar datos con registros a nivel de usuario. Debe escribir la expresión SELECT en las que CTEs utilicen el `SELECT userIdentifierColumn...' formato. | Agregaciones compatibles: AVG, COUNT, COUNT DISTINCT, STDDEV y SUM. |
| CTEs | Cláusula WITH, subconsulta de cláusula WITH | Se admite con la condición de que el CTEs uso de tablas con protección de privacidad diferencial debe generar datos con registros a nivel de usuario. Debe escribir la expresión SELECT en las que CTEs utilicen el `SELECT userIdentifierColumn...' formato. | N/A |
| subconsultas | SELECT HAVING JOIN Condición de JOIN FROM WHERE | Puede tener cualquier subconsulta que no haga referencia a las relaciones de privacidad diferenciales en estas construcciones. Puede tener cualquier subconsulta que haga referencia a relaciones de privacidad diferenciales únicamente en las cláusulas FROM y JOIN. |
| Unir cláusulas | INNER JOIN LEFT JOIN SEMIUNIÓN IZQUIERDA ANTIUNIÓN IZQUIERDA RIGHT JOIN FULL JOIN Operador [JOIN] OR CROSS JOIN | Se admite con la condición de que solo se admitan las funciones JOIN que son equi-joins en las columnas del identificador de usuario y son obligatorias cuando se consultan dos o más tablas con la privacidad diferencial activada. Asegúrese de que las condiciones obligatorias de equi-join sean correctas. Confirme que el propietario de la tabla haya configurado la misma columna de identificador de usuario en todas las tablas para que la definición de usuario siga siendo coherente en todas las tablas. Las funciones CROSS JOIN no se admiten cuando se combinan dos o más relaciones con la privacidad diferencial activada. |
| Operadores de establecimiento | UNION, UNION ALL, INTERSECT, EXCEPT \$1 MINUS (son sinónimos) | UNION, UNION ALL, INTERSECT, EXCEPTO \$1 MINUS (son sinónimos) | No compatible |
| Funciones de ventana | Funciones de agregación Función de ventana AVG Función de ventana COUNT Función de ventana CUME\$1DIST Función de ventana DENSE\$1RANK Función de ventana FIRST\$1VALUE Función de ventana LAG Función de ventana LAST\$1VALUE Función de ventana LEAD Funciones de ventana MAX Funciones de ventana MEDIAN Funciones de ventana MIN Función de ventana DENSE\$1NTH Las funciones de ventana STDDEV\$1SAMP y STDDEV\$1POP (STDDEV\$1SAMP y STDDEV son sinónimos) Funciones de ventana SUM Las funciones de ventana VAR\$1SAMP y VAR\$1POP (VAR\$1SAMP y VARIANCE son sinónimos) Funciones de clasificación Función de ventana DENSE\$1RANK Función de ventana NTILE Función de ventana PERCENT\$1RANK Función de ventana RANK Función de ventana ROW\$1NUMBER | Todos son compatibles con la condición de que la columna de identificación de usuario de la cláusula de partición de la función de ventana sea obligatoria cuando se consulte una relación con la privacidad diferencial activada. | No compatible |
| Expresiones condicionales | Expresión condicional CASE Expresión COALESCE Funciones GREATEST y LEAST Funciones NVL y COALESCE NVL2 función Función NULLIF | Todos son compatibles | Todos son compatibles |
| Condiciones | Condición de comparación Condiciones lógicas Condiciones de coincidencia de patrones Condiciones de rango BETWEEN Condición nula | EXISTSy no se IN pueden usar porque requieren subconsultas. Se admiten todas las demás. | Todos son compatibles |
| Funciones de fecha y hora | Funciones de fecha y hora en transacciones Operador de concatenación Funciones ADD\$1MONTHS Función CONVERT\$1TIMEZONE Función CURRENT\$1DATE Función DATEADD Función DATEDIFF Funciones DATE\$1PART Función DATE\$1TRUNC Función EXTRACT Función TO\$1TIMESTAMP Partes de fecha para funciones de fecha o marca temporal | Todas son compatibles | Todos son compatibles |
| Funciones de cadena | \$1\$1 Operador (concatenación) Función BTRIM Función CHAR\$1LENGTH Función CHARACTER\$1LENGTH Función CONCAT Funciones LEFT y RIGHT Función LEN Función LENGTH Función LOWER Funciones LPAD y RPAD Función LTRIM Funciones POSITION Función REGEXP\$1COUNT Función REGEXP\$1INSTR Función REGEXP\$1REPLACE Función REGEXP\$1SUBSTR Función REPEAT Función REPLACE Función REVERSE Función RTRIM Función SPLIT\$1PART Función SUBSTRING Función TRANSLATE Funciones TRIM Función UPPER | Todos son compatibles | Todos son compatibles |
| Funciones de formato de tipo de datos | Función CAST TO\$1CHAR Función TO\$1DATE TO\$1NUMBER Cadenas de formatos de fecha y hora Cadenas de formatos numéricos | Todos son compatibles | Todos son compatibles |
| Funciones hash | AES\$1ENCRYPT AES\$1DECRYPT ENCODE DECODE MD5 función SHA1 función SHA2 función XX\$1 HASH64 | Todos son compatibles | Todos son compatibles |
| Símbolos de operadores matemáticos | \$1, -, \$1,/,% y @ | Todos son compatibles | Todos son compatibles |
| Funciones matemáticas | Función ABS Función ACOS Función ASIN Función ATAN ATAN2 función Función CBRT Función CEILING (o CEIL) Función COS Función COT Función DEGREES Función LTRIM Función EXP Función FLOOR Función LN Función LOG Función MOD Función PI Función POWER Función RADIANS Función RANDOM Función ROUND Función SIGN Función SIN Funciones SQRT Función TRUNC | Todos son compatibles | Todos son compatibles |
| Funciones VARBYTE | SIN HEXÁGONOS, UNBASE64 MALEFICIO HLL\$1SKETCH\$1AGG, HLL\$1SKETCH\$1ESTIMATE HLL\$1UNION HLL\$1UNION\$1AGG | Todos son compatibles | Todos son compatibles |
| JSON | TO\$1JSON GET\$1JSON\$1OBJECT | Todos son compatibles | Todos son compatibles |
| Funciones de matriz | ARRAY\$1CONTIENE MATRIZ\$1DISTINCT MATRIZ\$1EXCEPTO ARRAY\$1INTERSECT ARRAY\$1JOIN ARRAY\$1REMOVE ARRAY\$1SORT ARRAY\$1UNION | No admitido | No admitido |
| GRUPO EXTENDIDO POR | AGRUPAR CONJUNTOS, ENROLLAR, CUBOS | No admitido | No admitido |
| Operación de clasificación | ORDER BY | Se admite con la condición de que la cláusula ORDER BY solo se admita en la cláusula de partición de una función de ventana cuando se consultan tablas con la privacidad diferencial activada. | compatible |
| Límites de filas | LIMIT, OFFSET | No se admite el CTEs uso de tablas con protección de privacidad diferencial | Todas son compatibles |
| Alias de tablas y columnas | | Soportado | compatible |
| Funciones matemáticas en funciones agregadas | | Soportado | compatible |
| Funciones escalares dentro de funciones agregadas | | Soportado | compatible |
## Alternativas comunes para constructos SQL no admitidos
| Categoría | Constructo SQL | Alternativa |
| --- |--- |--- |
| Funciones de ventana | LISTAGG PERCENTILE\$1CONT PERCENTILE\$1DISC | Puede utilizar la función de agregado equivalente con GROUP BY. |
| Símbolos de operadores matemáticos | \$1column \$1\$1/ 2 \$1column \$1/ 2 \$1column ^ 2 | CBRT SQRT POWER(\$1column, 2) |
| Funciones escalares | SYSDATE \$1column::integer convert(type, \$1column) | CURRENT\$1DATE CAST \$1column AS integer CAST \$1column AS type |
| Literales | INTERVALO «1 SEGUNDO» | INTERVALO «1» SEGUNDO |
| Límite de filas | TOP n | LÍMITE n |
| Join | USING NATURAL | La cláusula ON debe contener explícitamente un criterio de unión. |
# Consejos y ejemplos de consultas sobre privacidad diferencial
AWS Clean Rooms Differential Privacy utiliza una [estructura de consulta de uso general](dp-sql-capabilities.md) para admitir una amplia variedad de construcciones de SQL, como las expresiones de tabla comunes (CTEs) para la preparación de datos y las funciones agregadas de uso común, como, o. `COUNT` `SUM` Con el fin de ocultar la contribución de cualquier posible usuario a los datos y hacer más ruido al agregado de los resultados de las consultas en tiempo de ejecución, AWS Clean Rooms Differential Privacy exige que, en última `SELECT statement` instancia, las funciones de agregación se ejecuten en datos de nivel de usuario.
En el siguiente ejemplo se utilizan dos tablas denominadas `socialco_impressions` y `socialco_users` de un publicador de medios que quiere proteger los datos mediante una privacidad diferencial y, al mismo tiempo, colaborar con una marca deportiva que utiliza datos `athletic_brand_sales`. El publicador multimedia ha configurado la columna `user_id` como columna de identificador de usuario y, al mismo tiempo, ha habilitado una privacidad diferencial en AWS Clean Rooms. El anunciante no necesita una protección de privacidad diferencial y quiere ejecutar una consulta utilizando datos combinados. CTEs Puesto que su CTE utiliza tablas protegidas por la privacidad diferencial, el anunciante incluye la columna de identificador de usuario de esas tablas protegidas en la lista de columnas de CTE y une las tablas protegidas en la columna de identificador de usuario.
```
WITH matches_table AS(
SELECT si.user_id, si.campaign_id, s.sale_id, s.sale_price
FROM socialco_impressions si
JOIN socialco_users su
ON su.user_id = si.user_id
JOIN athletic_brand_sales s
ON s.emailsha256 = su.emailsha256
WHERE s.timestamp > si.timestamp
UNION ALL
SELECT si.user_id, si.campaign_id, s.sale_id, s.sale_price
FROM socialco_impressions si
JOIN socialco_users su
ON su.user_id = si.user_id
JOIN athletic_brand_sales s
ON s.phonesha256 = su.phonesha256
WHERE s.timestamp > si.timestamp
)
SELECT COUNT (DISTINCT user_id) as unique_users
FROM matches_table
GROUP BY campaign_id
ORDER BY COUNT (DISTINCT user_id) DESC
LIMIT 5
```
Del mismo modo, si desea ejecutar funciones de ventana en tablas de datos con protección de privacidad diferencial, debe incluir la columna de identificador de usuario en la cláusula `PARTITION BY`.
```
ROW_NUMBER() OVER (PARTITION BY conversion_id, user_id ORDER BY match_type, match_age) AS row
```
# Limitaciones de la AWS Clean Rooms privacidad diferencial
AWS Clean Rooms La privacidad diferencial no aborda las siguientes situaciones:
1. AWS Clean Rooms Differential Privacy solo admite consultas con tablas respaldadas por Amazon S3 AWS Glue . No admite consultas con tablas de Snowflake o Amazon Athena.
1. AWS Clean Rooms Differential Privacy no aborda los ataques cronometrados. Por ejemplo, estos ataques son posibles en situaciones en las que un usuario individual contribuye con un gran número de filas y la adición o eliminación de este usuario cambia considerablemente el tiempo de cálculo de la consulta.
1. AWS Clean Rooms La privacidad diferencial no garantiza la privacidad diferencial cuando una consulta SQL puede provocar desbordamientos o errores de conversión no válidos en tiempo de ejecución debido al uso de determinadas construcciones de SQL.
En la siguiente tabla se muestran algunos constructos de SQL, pero no todos, que pueden producir errores en tiempo de ejecución y que se deben verificar en las plantillas de análisis. Le recomendamos que apruebe plantillas de análisis que minimicen las posibilidades de que se produzcan dichos errores en tiempo de ejecución y que revise periódicamente los registros de consultas para determinar si las consultas se ajustan al acuerdo de colaboración.
Los siguientes constructos de SQL son vulnerables a los errores de desbordamiento:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/clean-rooms/latest/userguide/dp-limitations.html)
1. La función de formateo de tipos de datos CAST es vulnerable a errores de conversión no válidos.
Puede configurarlo [CloudWatch para crear un filtro de métricas para un grupo de registros](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) y, a continuación, [crear una CloudWatch alarma](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html) en ese filtro de métricas para recibir alertas en caso de que se produzca un posible desbordamiento o error de conversión.
En concreto, debe supervisar los códigos de error `CastError`, `OverflowError` y `ConversionError`. La presencia de estos códigos de error indica un posible ataque de canal lateral, pero podría indicar una consulta SQL errónea.
Para obtener más información, consulte [Inicio de sesión de Analysis AWS Clean Rooms](query-logs.md).
# AWS Clean Rooms ML
El aprendizaje automático de AWS Clean Rooms permite a dos o más partes ejecutar modelos de aprendizaje automático en sus datos sin necesidad de compartirlos entre sí. El servicio proporciona controles que mejoran la privacidad y permiten a los propietarios de los datos proteger sus datos y la IP de su modelo. Puede usar modelos AWS creados o traer su propio modelo personalizado.
Para obtener una explicación más detallada de cómo funciona esto, consulte [Trabajos entre cuentas](ml-behaviors.md#ml-behaviors-cross-account-jobs)
Para obtener más información sobre las capacidades de los modelos Clean Rooms ML, consulte los siguientes temas.
**Topics**
+ [Terminología de aprendizaje automático de AWS Clean Rooms](#ml-terminology)
+ [Cómo funciona AWS Clean Rooms ML con AWS los modelos](#ml-how-it-works)
+ [Cómo funciona AWS Clean Rooms ML con modelos personalizados](#custML-how-it-works)
+ [AWS modelos en Clean Rooms ML](aws-models.md)
+ [Modelos personalizados en Clean Rooms ML](custom-models.md)
## Terminología de aprendizaje automático de AWS Clean Rooms
Es importante entender la siguiente terminología al utilizar Clean Rooms ML:
+ *Proveedor de datos de entrenamiento*: la parte que aporta los datos de entrenamiento, crea y configura un modelo similar y, a continuación, lo asocia a una colaboración.
+ *Proveedor de datos iniciales*: la parte que aporta los datos iniciales, genera un segmento similar y exporta su segmento similar.
+ *Datos de entrenamiento*: los datos del proveedor de datos de entrenamiento, que se utilizan para generar un modelo similar. Los datos de entrenamiento se utilizan para medir la similitud en los comportamientos de los usuarios.
Los datos de entrenamiento deben contener un ID de usuario, un ID de elemento y una columna de marca de tiempo. De forma opcional, los datos de entrenamiento pueden contener otras interacciones, como características numéricas o categóricas. Algunos ejemplos de interacciones son una lista de los vídeos visualizados, los artículos comprados o los artículos leídos.
+ *Datos iniciales*: los datos del proveedor de datos iniciales, que se utilizan para crear un segmento similar. Los datos iniciales se pueden proporcionar directamente o pueden provenir de los resultados de una AWS Clean Rooms consulta. El resultado del segmento similar es un conjunto de usuarios a partir de los datos de entrenamiento que se parece más a los usuarios iniciales.
+ *Modelo similar*: un modelo de machine learning de los datos de entrenamiento que se utiliza para encontrar usuarios similares en otros conjuntos de datos.
Cuando se utiliza la API, el término *modelo de audiencia* se utiliza de manera equivalente a modelo similar. Por ejemplo, se utiliza la [CreateAudienceModel](https://docs.aws.amazon.com/cleanrooms-ml/latest/APIReference/API_CreateAudienceModel.html)API para crear un modelo similar.
+ *Segmento similar*: es un subconjunto de los datos de entrenamiento que se parecen más a los datos iniciales.
Al utilizar la API, se crea un segmento similar con la [StartAudienceGenerationJob](https://docs.aws.amazon.com/cleanrooms-ml/latest/APIReference/API_StartAudienceGenerationJob.html)API.
Los datos del proveedor de datos de entrenamiento nunca se comparten con el proveedor de datos iniciales, y viceversa. La salida del segmento similar se comparte con el proveedor de datos de entrenamiento, pero nunca con el proveedor de datos iniciales.
## Cómo funciona AWS Clean Rooms ML con AWS los modelos
![\[Información general sobre cómo funciona AWS Clean Rooms ML con AWS los modelos.\]](http://docs.aws.amazon.com/es_es/clean-rooms/latest/userguide/images/howItWorksML.png)
Para trabajar con modelos similares, es necesario que dos partes, un proveedor de datos de formación y un proveedor de datos iniciales, trabajen secuencialmente AWS Clean Rooms para integrar sus datos en una colaboración. Este es el flujo de trabajo que el proveedor de datos de entrenamiento debe completar primero:
1. Los datos del proveedor de datos de formación deben almacenarse en una tabla de catálogo de AWS Glue datos con las interacciones entre usuarios y elementos. Como mínimo, los datos de entrenamiento deben contener una columna de ID de usuario, una columna de ID de interacción y una columna de marca temporal.
1. El proveedor de datos de entrenamiento registra los datos de entrenamiento con AWS Clean Rooms.
1. El proveedor de datos de entrenamiento crea un modelo similar que se puede compartir con varios proveedores de datos iniciales. El modelo similar es una red neuronal profunda que puede tardar hasta 24 horas en entrenarse. No se reentrena automáticamente y le recomendamos que vuelva a entrenar el modelo una vez por semana.
1. El proveedor de datos de entrenamiento configura el modelo similar, que incluye si desea compartir las métricas de relevancia y la ubicación en Amazon S3 de los segmentos de salida. El proveedor de datos de entrenamiento puede crear varios modelos similares configurados a partir de un único modelo similar.
1. El proveedor de datos de entrenamiento asocia el modelo de audiencia configurado a una colaboración que se comparte con un proveedor de datos iniciales.
Este es el flujo de trabajo que el proveedor de datos iniciales debe completar a continuación:
1. Los datos del proveedor de datos iniciales se pueden almacenar en un bucket de Amazon S3 o pueden provenir de los resultados de una consulta.
1. El proveedor de datos iniciales comienza la colaboración que comparte con el proveedor de datos de entrenamiento.
1. El proveedor de datos iniciales crea un segmento similar en la pestaña de Clean Rooms ML de la página de colaboración.
1. El proveedor de datos iniciales puede evaluar las métricas de relevancia, en caso de que se hayan compartido, y exportar el segmento similar para su uso fuera de AWS Clean Rooms.
## Cómo funciona AWS Clean Rooms ML con modelos personalizados
Con Clean Rooms ML, los miembros de una colaboración pueden utilizar un algoritmo de modelo personalizado dockerizado que se almacena en Amazon ECR para analizar sus datos de forma conjunta. Para ello, el *proveedor del modelo* debe crear una imagen y almacenarla en Amazon ECR. Siga los pasos de la [Guía del usuario de Amazon Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/) para crear un repositorio privado que contendrá el modelo de aprendizaje automático personalizado.
Cualquier miembro de una colaboración puede ser el *proveedor del modelo*, siempre que cuente con los permisos correctos. Todos los miembros de una colaboración pueden aportar datos de entrenamiento, datos de inferencia o ambos al modelo. A los efectos de esta guía, los miembros que aportan datos se denominan *proveedores de datos*. El miembro que crea la colaboración es el *creador de la colaboración* y puede ser el *proveedor del modelo*, uno de los *proveedores de datos* o ambos.
En el nivel más alto, estos son los pasos que se deben completar para realizar un modelado de aprendizaje automático personalizado:
1. El creador de la colaboración crea una colaboración y asigna a cada miembro las capacidades y la configuración de pago adecuadas. En este paso, el creador de la colaboración debe asignar al miembro la capacidad de recibir los resultados del modelo o los resultados de las inferencias al miembro correspondiente, ya que no se puede actualizar una vez creada la colaboración. Para obtener más información, consulte [Crear y unirse a la colaboración en AWS Clean Rooms ML](create-custom-ml-collaboration.md).
1. El proveedor del modelo configura y asocia su modelo de aprendizaje automático en contenedores a la colaboración y se asegura de que se establezcan restricciones de privacidad para los datos exportados. Para obtener más información, consulte [Configuración de un algoritmo modelo en AWS Clean Rooms ML](configure-model-algorithm.md).
1. Los proveedores de datos aportan sus datos a la colaboración y se aseguran de que se especifiquen sus necesidades de privacidad. Los proveedores de datos deben permitir que el modelo acceda a sus datos. Para obtener más información, consulte [Contribución de datos de formación en AWS Clean Rooms ML](custom-model-training-data.md) y [Asociación del algoritmo del modelo configurado en AWS Clean Rooms ML](associate-model-algorithm.md).
1. Un miembro de la colaboración crea la configuración de aprendizaje automático, que define a dónde se exportan los artefactos del modelo o los resultados de las inferencias.
1. Un miembro de la colaboración crea un canal de entrada de aprendizaje automático que proporciona información al contenedor de formación o al contenedor de inferencias. El canal de entrada de ML es una consulta que define los datos que se utilizarán en el contexto del algoritmo del modelo.
1. Un miembro de la colaboración invoca el entrenamiento del modelo mediante el canal de entrada ML y el algoritmo del modelo configurado. Para obtener más información, consulte [Creación de un modelo entrenado en AWS Clean Rooms ML](create-trained-model.md).
1. (Opcional) El entrenador de modelos invoca el trabajo de exportación del modelo y los artefactos del modelo se envían al receptor de resultados del modelo. Solo los miembros con una configuración de aprendizaje automático válida y con la capacidad de recibir la salida del modelo pueden recibir artefactos del modelo. Para obtener más información, consulte [Exportación de artefactos modelo desde AWS Clean Rooms ML](export-model-artifacts.md).
1. (Opcional) Un miembro de la colaboración invoca la inferencia del modelo mediante el canal de entrada ML, el ARN del modelo entrenado y el algoritmo del modelo configurado por inferencia. Los resultados de la inferencia se envían al receptor de salida de la inferencia. Solo los miembros con una configuración de aprendizaje automático válida y con la capacidad de recibir los resultados de la inferencia pueden recibir los resultados de la inferencia.
Estos son los pasos que debe completar el proveedor del *modelo:*
1. Cree una imagen de docker de Amazon ECR compatible con SageMaker IA. Clean Rooms ML solo admite imágenes de docker compatibles con SageMaker IA.
1. Una vez que haya creado una imagen de docker compatible con SageMaker IA, envíe la imagen a Amazon ECR. Siga las instrucciones de la [Guía del usuario de Amazon Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/) para crear una imagen de formación sobre contenedores.
1. Configure el algoritmo del modelo para usarlo en Clean Rooms ML.
1. Proporcione el enlace al repositorio de Amazon ECR y todos los argumentos necesarios para configurar el algoritmo del modelo.
1. Proporcione un rol de acceso al servicio que permita a Clean Rooms ML acceder al repositorio de Amazon ECR.
1. Asocie el algoritmo del modelo configurado a la colaboración. Esto incluye proporcionar una política de privacidad que defina los controles para los registros de contenedores, los registros de errores, CloudWatch las métricas y los límites sobre la cantidad de datos que se pueden exportar de los resultados del contenedor.
Estos son los pasos que debe completar el *proveedor de datos* para colaborar con un modelo de aprendizaje automático personalizado:
1. Configure una AWS Glue tabla existente con una regla de análisis personalizada. Esto permite que un conjunto específico de consultas preaprobadas o cuentas preaprobadas utilice sus datos.
1. Asocie la tabla configurada a una colaboración y proporcione un rol de acceso al servicio que pueda acceder a sus AWS Glue tablas.
1. [Agregue una regla de análisis de colaboración](add-collaboration-analysis-rule.md) a la tabla que permita a la asociación de algoritmos del modelo configurado acceder a la tabla configurada.
1. Una vez que el modelo y los datos están asociados y configurados en Clean Rooms ML, el miembro con capacidad para ejecutar consultas proporciona una consulta SQL y selecciona el algoritmo del modelo que va a utilizar.
Una vez finalizado el entrenamiento del modelo, ese miembro inicia la exportación de los artefactos del entrenamiento del modelo o de los resultados de las inferencias. Estos artefactos o resultados se envían al miembro para que pueda recibir los resultados del modelo entrenado. El receptor de los resultados debe configurarlos `MachineLearningConfiguration` antes de poder recibir la salida del modelo.
# AWS modelos en Clean Rooms ML
AWS Clean Rooms ML proporciona un método que preserva la privacidad para que dos partes identifiquen a usuarios similares en sus datos sin necesidad de compartir sus datos entre sí. La primera parte aporta los datos de entrenamiento para AWS Clean Rooms poder crear y configurar un modelo similar y asociarlo a una colaboración. A continuación, los datos iniciales se traen a la colaboración para crear un segmento similar que se parece a los datos de entrenamiento.
Para obtener una explicación más detallada de cómo funciona esto, consulte [Trabajos entre cuentas](ml-behaviors.md#ml-behaviors-cross-account-jobs)
Los siguientes temas proporcionan información sobre cómo crear y configurar un AWS modelo en Clean Rooms ML.
**Topics**
+ [Protecciones de privacidad de AWS Clean Rooms ML](ml-privacy.md)
+ [Requisitos de datos de entrenamiento para Clean Rooms ML](ml-training-data-requirements.md)
+ [Requisitos de datos iniciales para Clean Rooms ML](ml-seed-data-requirements.md)
+ [Métricas de evaluación del modelo de aprendizaje automático de AWS Clean Rooms](ml-metrics.md)
# Protecciones de privacidad de AWS Clean Rooms ML
Clean Rooms ML está diseñado para reducir el riesgo de *ataques de inferencia de suscripción*, ya que el proveedor de datos de entrenamiento puede saber quién está en los datos iniciales y el proveedor de datos iniciales puede saber quién está en los datos de entrenamiento. Para prevenir este ataque, se toman varias medidas.
En primer lugar, los proveedores de datos iniciales no observan directamente los resultados de Clean Rooms ML y los proveedores de datos de entrenamiento nunca pueden observar los datos iniciales. Los proveedores de datos iniciales pueden optar por incluir los datos iniciales en el segmento de salida.
A continuación, se crea el modelo similar a partir de una muestra aleatoria de los datos de entrenamiento. Este ejemplo incluye un número significativo de usuarios que no coinciden con la audiencia inicial. Este proceso hace que sea más difícil determinar si un usuario no aparecía en los datos, lo cual es otra forma de deducir la membresía.
Además, se pueden utilizar varios clientes iniciales para cada parámetro del entrenamiento de modelos similares específicos del inicio. Esto limita cuánto puede sobreajustarse el modelo y, por lo tanto, cuánto se puede deducir sobre un usuario. Como resultado, se recomienda que el tamaño mínimo de los datos iniciales sea de 500 usuarios.
Por último, nunca se proporcionan métricas en el nivel de usuario a los proveedores de datos de entrenamiento, lo que elimina otra posibilidad de que se produzca un ataque de inferencia de pertenencia.
# Requisitos de datos de entrenamiento para Clean Rooms ML
Para crear correctamente un modelo similar, los datos de entrenamiento deben cumplir los siguientes requisitos:
+ Los datos de entrenamiento deben estar en formato Parquet, CSV o JSON.
**nota**
No se admiten los datos de Parquet comprimidos con Zstandard (ZSTD).
+ Tus datos de entrenamiento deben estar catalogados en. AWS Glue Para obtener más información, consulte [Introducción al catálogo de datos de AWS Glue](https://docs.aws.amazon.com//glue/latest/dg/start-data-catalog.html) en la Guía para AWS Glue desarrolladores. Le recomendamos que utilice AWS Glue rastreadores para crear las tablas, ya que el esquema se deduce automáticamente.
+ El depósito de Amazon S3 que contiene los datos de entrenamiento y los datos iniciales se encuentra en la misma AWS región que sus otros recursos de aprendizaje automático para salas limpias.
+ Los datos de entrenamiento deben contener al menos 100 000 usuarios únicos IDs con al menos dos interacciones entre elementos cada uno.
+ Los datos de entrenamiento deben contener al menos 1 millón de registros.
+ El esquema especificado en la [CreateTrainingDataset](https://docs.aws.amazon.com/cleanrooms-ml/latest/APIReference/API_CreateTrainingDataset.html)acción debe alinearse con el esquema definido cuando se creó la AWS Glue tabla.
+ Los campos obligatorios, tal como se definen en la tabla proporcionada, se definen en la acción [CreateTrainingDataset](https://docs.aws.amazon.com/cleanrooms-ml/latest/APIReference/API_CreateTrainingDataset.html).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/clean-rooms/latest/userguide/ml-training-data-requirements.html)
+ Opcionalmente, puede proporcionar hasta 10 características categóricas o numéricas en total.
Este es un ejemplo de un conjunto de datos de entrenamiento válido en formato CSV
```
USER_ID,ITEM_ID,TIMESTAMP,EVENT_TYPE(CATEGORICAL FEATURE),EVENT_VALUE (NUMERICAL FEATURE)
196,242,881250949,click,15
186,302,891717742,click,13
22,377,878887116,click,10
244,51,880606923,click,20
166,346,886397596,click,10
```
# Requisitos de datos iniciales para Clean Rooms ML
Los datos iniciales de un modelo similar pueden provenir directamente de un bucket de Amazon S3 o de los resultados de una consulta SQL.
Los datos iniciales que se proporcionan directamente deben cumplir los siguientes requisitos:
+ Los datos iniciales deben estar en formato de líneas JSON con una lista de usuarios IDs.
+ El tamaño de la semilla debe estar comprendido entre 25 y 500 000 usuarios únicos IDs.
+ El número mínimo de usuarios iniciales debe coincidir con el valor mínimo de tamaño inicial coincidente que se especificó al crear el modelo de audiencia configurado.
El siguiente es un ejemplo de un conjunto de datos de entrenamiento válido en formato CSV
```
{"user_id": "abc"}
{"user_id": "def"}
{"user_id": "ghijkl"}
{"user_id": "123"}
{"user_id": "456"}
{"user_id": "7890"}
```
# Métricas de evaluación del modelo de aprendizaje automático de AWS Clean Rooms
Clean Rooms ML calcula la *exhaustividad* y la *puntuación de relevancia* para determinar el rendimiento del modelo. La exhaustividad compara la similitud entre los datos similares y los datos de entrenamiento. La puntuación de relevancia se utiliza para decidir cómo de grande debe ser la audiencia, no si el rendimiento del modelo es bueno.
La *exhaustividad* es una medida imparcial de la similitud del segmento similar con los datos de entrenamiento. La exhaustividad es el porcentaje de usuarios más similares (de forma predeterminada, el 20 % más similar) de una muestra de los datos de entrenamiento que se incluyen en la audiencia inicial según el trabajo de generación de audiencia. Los valores oscilan entre 0 y 1; los valores más altos indican una mejor audiencia. Un valor de exhaustividad aproximadamente igual al porcentaje máximo de intervalo indica que el modelo de audiencia equivale a una selección aleatoria.
Consideramos que esta métrica de evaluación es mejor que la exactitud, la precisión y las puntuaciones de F1 porque Clean Rooms ML no ha etiquetado con precisión a los usuarios que realmente son negativos al crear su modelo.
La *puntuación de relevancia* del segmento es una medida de similitud con valores que van desde -1 (menos similar) a 1 (más similar). Clean Rooms ML calcula un conjunto de puntuaciones de relevancia para varios tamaños de segmento a fin de ayudarle a determinar el mejor tamaño de segmento para los datos. Las puntuaciones de relevancia disminuyen de forma monótona a medida que aumenta el tamaño del segmento, por lo que, a medida que aumenta el tamaño del segmento, pueden ser menos similares a los datos iniciales. Cuando la puntuación de relevancia del segmento llega a 0, el modelo predice que todos los usuarios del segmento similar provienen de la misma distribución que los datos iniciales. Al aumentar el tamaño de salida, es probable que se incluyan usuarios del segmento similar que no pertenezcan a la misma distribución que los datos iniciales.
Las puntuaciones de relevancia se normalizan en una sola campaña y no se deben utilizar para comparar campañas. Los puntajes de relevancia no deben utilizarse como una fuente única de evidencia para determinar ningún resultado empresarial, ya que se ven afectados por varios factores complejos además de la relevancia, como la calidad del inventario, el tipo de inventario, el momento en que se publica la publicidad, etc.
Las puntuaciones de relevancia no se deben utilizar para juzgar la calidad del inicio, sino para determinar si se puede aumentar o disminuir. Considere los siguientes ejemplos:
+ Todas las puntuaciones son positivas: esto indica que hay más usuarios de salida que se consideran similares que los que se incluyen en el segmento similar. Esto es habitual en el caso de los datos iniciales que forman parte de un mercado grande, como el de todos los que han comprado pasta de dientes en el último mes. Le recomendamos que consulte los datos iniciales más pequeños, como los de todas las personas que han comprado pasta dental más de una vez en el último mes.
+ Todas las puntuaciones negativas o negativas para su tamaño de segmento similar deseado: esto indica que Clean Rooms ML predice que no hay suficientes usuarios similares en el tamaño de segmento similar deseado. Esto se puede deber a que los datos iniciales son demasiado específicos o a que el mercado es demasiado pequeño. Recomendamos aplicar menos filtros a los datos iniciales o ampliar el mercado. Por ejemplo, si los datos iniciales originales eran clientes que habían comprado un cochecito y una silla de coche, podría ampliar el mercado a clientes que hayan comprado varios productos para bebés.
Los proveedores de datos de entrenamiento determinan si se exponen las puntuaciones de relevancia y cuáles son los contenedores de bucket en los que se calculan las puntuaciones de relevancia.
# Modelos personalizados en Clean Rooms ML
Con Clean Rooms ML, los miembros de una colaboración pueden utilizar un algoritmo de modelo personalizado dockerizado que se almacena en Amazon ECR para analizar sus datos de forma conjunta. Para ello, el *proveedor del modelo* debe crear una imagen y almacenarla en Amazon ECR. Siga los pasos de la [Guía del usuario de Amazon Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/) para crear un repositorio privado que contendrá el modelo de aprendizaje automático personalizado.
Cualquier miembro de una colaboración puede ser el *proveedor del modelo*, siempre que cuente con los permisos correctos. Todos los miembros de una colaboración pueden aportar datos al modelo. A los efectos de esta guía, los miembros que aportan datos se denominan *proveedores de datos*. El miembro que crea la colaboración es el *creador de la colaboración* y puede ser el *proveedor del modelo*, uno de los *proveedores de datos* o ambos.
En los temas siguientes se describe la información necesaria para crear un modelo de aprendizaje automático personalizado
**Topics**
+ [Requisitos previos del modelado ML personalizado](custom-model-prerequisites.md)
+ [Pautas de creación de modelos para el contenedor de formación](custom-model-guidelines.md)
+ [Directrices de creación de modelos para el contenedor de inferencias](inference-model-guidelines.md)
+ [Recibir registros y métricas del modelo](custom-model-logs.md)
# Requisitos previos del modelado ML personalizado
Antes de poder realizar un modelado de aprendizaje automático personalizado, debe tener en cuenta lo siguiente:
+ Determine si tanto el entrenamiento del modelo como la inferencia sobre el modelo entrenado se realizarán en colaboración.
+ Determine la función que desempeñará cada miembro de la colaboración y asígnele las habilidades adecuadas.
+ Asigne la `CAN_QUERY` habilidad al miembro que entrenará el modelo y realizará la inferencia sobre el modelo entrenado.
+ `CAN_RECEIVE_RESULTS`Asígnelo al menos a un miembro de la colaboración.
+ Asigne `CAN_RECEIVE_MODEL_OUTPUT` nuestras `CAN_RECEIVE_INFERENCE_OUTPUT` habilidades al miembro que recibirá las exportaciones de modelos entrenados o el resultado de inferencias, respectivamente. Puedes elegir usar ambas habilidades si así lo requiere tu caso de uso.
+ Determine el tamaño máximo de los artefactos del modelo entrenado o de los resultados de inferencia que permitirá exportar.
+ Recomendamos que todos los usuarios tengan las `CleanroomsMLFullAccess` políticas `CleanrooomsFullAccess` y políticas asociadas a su función. El uso de modelos de aprendizaje automático personalizados requiere utilizar tanto el AWS Clean Rooms ML de AWS Clean Rooms como el de AWS SDKs.
+ Tenga en cuenta la siguiente información sobre las funciones de IAM.
+ Todos los proveedores de datos deben tener una función de acceso AWS Clean Rooms al servicio que les permita leer los datos de sus AWS Glue catálogos y tablas, y de las ubicaciones subyacentes de Amazon S3. Estas funciones son similares a las que se requieren para las consultas de SQL. Esto le permite utilizar la `CreateConfiguredTableAssociation` acción. Para obtener más información, consulte [Cree un rol de servicio para crear una asociación de tablas configurada](ml-roles.md#ml-roles-custom-configure-table).
+ Todos los miembros que deseen recibir métricas deben tener una función de acceso al servicio que les permita escribir CloudWatch métricas y registros. Clean Rooms ML utiliza esta función para escribir todas las métricas y registros del modelo para el miembro Cuenta de AWS durante el entrenamiento y la inferencia del modelo. También ofrecemos controles de privacidad para determinar qué miembros tienen acceso a las métricas y los registros. Esto te permite usar la `CreateMLConfiguration` acción. Para obtener más información, consulte, [Cree un rol de servicio para el modelado de ML personalizado: Configuración de ML](ml-roles.md#ml-roles-custom-configure).
El miembro que reciba los resultados debe proporcionar un rol de acceso al servicio con permisos para escribir en su bucket de Amazon S3. Esta función permite a Clean Rooms ML exportar los resultados (artefactos de modelos entrenados o resultados de inferencias) a un bucket de Amazon S3. Esto le permite utilizar la `CreateMLConfiguration` acción. Para obtener más información, consulte [Cree un rol de servicio para el modelado de ML personalizado: Configuración de ML](ml-roles.md#ml-roles-custom-configure).
+ El proveedor del modelo debe proporcionar un rol de acceso al servicio con permisos para leer su repositorio e imagen de Amazon ECR. Esto le permite utilizar la `CreateConfigureModelAlgorithm` acción. Para obtener más información, consulte [Cree un rol de servicio para proporcionar un modelo de aprendizaje automático personalizado](ml-roles.md#ml-roles-custom-model-provider).
+ El miembro que crea el `MLInputChannel` para generar conjuntos de datos con fines de formación o inferencia debe proporcionar una función de acceso al servicio que permita a Clean Rooms ML ejecutar una consulta SQL en ella. AWS Clean Rooms Esto le permite usar las acciones `CreateTrainedModel` y`StartTrainedModelInferenceJob`. Para obtener más información, consulte [Cree un rol de servicio para consultar un conjunto de datos](ml-roles.md#ml-roles-custom-query-dataset).
+ Los autores del modelo deben seguir las [Pautas de creación de modelos para el contenedor de formación](custom-model-guidelines.md) y [Directrices de creación de modelos para el contenedor de inferenciasRecibir registros y métricas del modelo](inference-model-guidelines.md) asegurarse de que las entradas y salidas del modelo estén configuradas según lo esperado AWS Clean Rooms.
# Pautas de creación de modelos para el contenedor de formación
En esta sección se detallan las pautas que los proveedores de modelos deben seguir al crear un algoritmo de modelo de aprendizaje automático personalizado para el aprendizaje automático de salas limpias.
+ Utilice la imagen base de contenedores adecuada y compatible con la formación en SageMaker IA, tal y como se describe en la Guía para [desarrolladores de SageMaker IA](https://docs.aws.amazon.com/sagemaker/latest/dg-ecr-paths/sagemaker-algo-docker-registry-paths.html). El siguiente código te permite extraer las imágenes de la base de contenedores compatibles de puntos finales de SageMaker IA públicos.
```
ecr_registry_endpoint='763104351884.dkr.ecr.$REGION.amazonaws.com'
base_image='pytorch-training:2.3.0-cpu-py311-ubuntu20.04-sagemaker'
aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin $ecr_registry_endpoint
docker pull $ecr_registry_endpoint/$base_image
```
+ Cuando cree el modelo localmente, asegúrese de lo siguiente para poder probarlo localmente, en una instancia de desarrollo, en SageMaker AI Training en su Cuenta de AWS empresa y en Clean Rooms ML.
+ Recomendamos escribir un guion de formación que acceda a propiedades útiles del entorno de formación a través de diversas variables de entorno. Clean Rooms ML utiliza los siguientes argumentos para invocar el entrenamiento en el código del modelo:`SM_MODEL_DIR`, `SM_OUTPUT_DIR``SM_CHANNEL_TRAIN`, y. `FILE_FORMAT` Clean Rooms ML utiliza estos valores predeterminados para entrenar su modelo de aprendizaje automático en su propio entorno de ejecución con los datos de todas las partes.
+ Clean Rooms ML hace que sus canales de entrada de formación estén disponibles a través de los `/opt/ml/input/data/channel-name` directorios del contenedor docker. Cada canal de entrada de ML se mapea en función del correspondiente que `channel_name` se proporciona en la `CreateTrainedModel` solicitud.
```
parser = argparse.ArgumentParser()# Data, model, and output directories
parser.add_argument('--model_dir', type=str, default=os.environ.get('SM_MODEL_DIR', "/opt/ml/model"))
parser.add_argument('--output_dir', type=str, default=os.environ.get('SM_OUTPUT_DIR', "/opt/ml/output/data"))
parser.add_argument('--train_dir', type=str, default=os.environ.get('SM_CHANNEL_TRAIN', "/opt/ml/input/data/train"))
parser.add_argument('--train_file_format', type=str, default=os.environ.get('FILE_FORMAT', "csv"))
```
+ Asegúrese de poder generar un conjunto de datos sintético o de prueba basado en el esquema de los colaboradores que se utilizará en el código de su modelo.
+ Asegúrese de poder realizar un trabajo de formación en SageMaker IA por su cuenta Cuenta de AWS antes de asociar el algoritmo del modelo a una AWS Clean Rooms colaboración.
El siguiente código contiene un archivo Docker de muestra que es compatible con las pruebas locales, las pruebas del entorno de formación de SageMaker IA y el aprendizaje automático de salas limpias
```
FROM 763104351884.dkr.ecr.us-west-2.amazonaws.com/pytorch-training:2.3.0-cpu-py311-ubuntu20.04-sagemaker
MAINTAINER $author_name
ENV PYTHONDONTWRITEBYTECODE=1 \
PYTHONUNBUFFERED=1 \
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/local/lib"
ENV PATH="/opt/ml/code:${PATH}"
# this environment variable is used by the SageMaker PyTorch container to determine our user code directory
ENV SAGEMAKER_SUBMIT_DIRECTORY /opt/ml/code
# copy the training script inside the container
COPY train.py /opt/ml/code/train.py
# define train.py as the script entry point
ENV SAGEMAKER_PROGRAM train.py
ENTRYPOINT ["python", "/opt/ml/code/train.py"]
```
+ Para supervisar mejor los fallos de los contenedores, recomendamos exportar los registros y depurarlos en caso de que se produzcan errores. Como `GetTrainedModel` respuesta, Clean Rooms ML devuelve los primeros 1024 caracteres de este archivo. `StatusDetails`
+ Una vez que haya realizado cualquier cambio en el modelo y esté listo para probarlo en el entorno de SageMaker IA, ejecute los siguientes comandos en el orden indicado.
```
export ACCOUNT_ID=xxx
export REPO_NAME=xxx
export REPO_TAG=xxx
export REGION=xxx
docker build -t $ACCOUNT_ID.dkr.ecr.us-west-2.amazonaws.com/$REPO_NAME:$REPO_TAG
# Sign into AWS $ACCOUNT_ID/ Run aws configure
# Check the account and make sure it is the correct role/credentials
aws sts get-caller-identity
aws ecr create-repository --repository-name $REPO_NAME --region $REGION
aws ecr describe-repositories --repository-name $REPO_NAME --region $REGION
# Authenticate Doker
aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com
# Push To ECR Images
docker push $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com$REPO_NAME:$REPO_TAG
# Create Sagemaker Training job
# Configure the training_job.json with
# 1. TrainingImage
# 2. Input DataConfig
# 3. Output DataConfig
aws sagemaker create-training-job --cli-input-json file://training_job.json --region $REGION
```
Una vez que haya completado el trabajo de SageMaker IA y esté satisfecho con el algoritmo de su modelo, podrá registrar el registro de Amazon ECR en AWS Clean Rooms ML. Utilice la `CreateConfiguredModelAlgorithm` acción para registrar el algoritmo del modelo y asociarlo a una colaboración. `CreateConfiguredModelAlgorithmAssociation`
# Directrices de creación de modelos para el contenedor de inferencias
En esta sección se detallan las pautas que los proveedores de modelos deben seguir al crear un algoritmo de inferencia para Clean Rooms ML.
+ [Utilice la imagen base de contenedor adecuada compatible con la inferencia de SageMaker IA, tal y como se describe en la SageMaker Guía para desarrolladores de IA.](https://docs.aws.amazon.com/sagemaker/latest/dg-ecr-paths/sagemaker-algo-docker-registry-paths.html) El siguiente código te permite extraer las imágenes de base de contenedores compatibles de puntos finales de IA públicos SageMaker .
```
ecr_registry_endpoint='763104351884.dkr.ecr.$REGION.amazonaws.com'
base_image='pytorch-inference:2.3.0-cpu-py311-ubuntu20.04-sagemaker'
aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin $ecr_registry_endpoint
docker pull $ecr_registry_endpoint/$base_image
```
+ Cuando cree el modelo localmente, asegúrese de lo siguiente para poder probarlo localmente, en una instancia de desarrollo, en SageMaker AI Batch Transform en su Cuenta de AWS entorno y en Clean Rooms ML.
+ Clean Rooms ML hace que los artefactos de su modelo a partir de la inferencia estén disponibles para que los utilice su código de inferencia a través del `/opt/ml/model` directorio del contenedor docker.
+ Clean Rooms ML divide la entrada por línea, utiliza una estrategia por `MultiRecord` lotes y añade un carácter de nueva línea al final de cada registro transformado.
+ Asegúrese de poder generar un conjunto de datos de inferencia sintético o de prueba basado en el esquema de los colaboradores que se utilizará en el código de su modelo.
+ Asegúrese de poder ejecutar un trabajo de transformación por lotes de SageMaker IA por su cuenta Cuenta de AWS antes de asociar el algoritmo del modelo a una AWS Clean Rooms colaboración.
El siguiente código contiene un ejemplo de archivo Docker que es compatible con las pruebas locales, las pruebas de entornos de transformación mediante SageMaker IA y el aprendizaje automático de salas limpias
```
FROM 763104351884.dkr.ecr.us-east-1.amazonaws.com/pytorch-inference:1.12.1-cpu-py38-ubuntu20.04-sagemaker
ENV PYTHONUNBUFFERED=1
COPY serve.py /opt/ml/code/serve.py
COPY inference_handler.py /opt/ml/code/inference_handler.py
COPY handler_service.py /opt/ml/code/handler_service.py
COPY model.py /opt/ml/code/model.py
RUN chmod +x /opt/ml/code/serve.py
ENTRYPOINT ["/opt/ml/code/serve.py"]
```
+ Una vez que haya realizado cualquier cambio en el modelo y esté listo para probarlo en el entorno de SageMaker IA, ejecute los siguientes comandos en el orden indicado.
```
export ACCOUNT_ID=xxx
export REPO_NAME=xxx
export REPO_TAG=xxx
export REGION=xxx
docker build -t $ACCOUNT_ID.dkr.ecr.us-west-2.amazonaws.com/$REPO_NAME:$REPO_TAG
# Sign into AWS $ACCOUNT_ID/ Run aws configure
# Check the account and make sure it is the correct role/credentials
aws sts get-caller-identity
aws ecr create-repository --repository-name $REPO_NAME --region $REGION
aws ecr describe-repositories --repository-name $REPO_NAME --region $REGION
# Authenticate Docker
aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com
# Push To ECR Repository
docker push $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com$REPO_NAME:$REPO_TAG
# Create Sagemaker Model
# Configure the create_model.json with
# 1. Primary container -
# a. ModelDataUrl - S3 Uri of the model.tar from your training job
aws sagemaker create-model --cli-input-json file://create_model.json --region $REGION
# Create Sagemaker Transform Job
# Configure the transform_job.json with
# 1. Model created in the step above
# 2. MultiRecord batch strategy
# 3. Line SplitType for TransformInput
# 4. AssembleWith Line for TransformOutput
aws sagemaker create-transform-job --cli-input-json file://transform_job.json --region $REGION
```
Una vez que haya completado el trabajo de SageMaker IA y esté satisfecho con la transformación por lotes, podrá registrar el registro de Amazon ECR en AWS Clean Rooms ML. Utilice la `CreateConfiguredModelAlgorithm` acción para registrar el algoritmo del modelo y asociarlo a una colaboración. `CreateConfiguredModelAlgorithmAssociation`
# Recibir registros y métricas del modelo
Para recibir registros y métricas del entrenamiento o la inferencia de modelos personalizados, los miembros deben haber [creado una configuración de aprendizaje automático](https://docs.aws.amazon.com/clean-rooms/latest/userguide/create-custom-ml-collaboration.html) con un rol válido que proporcione los CloudWatch permisos necesarios (consulte [Crear un rol de servicio para el modelado de aprendizaje automático personalizado: configuración de aprendizaje automático](https://docs.aws.amazon.com/clean-rooms/latest/userguide/ml-roles.html#ml-roles-custom-configure)).
**Métrica del sistema**
Las métricas del sistema, tanto para el entrenamiento como para la inferencia, como el uso de la CPU y la memoria, se publican para todos los miembros en colaboración con las configuraciones de aprendizaje automático válidas. Estas métricas se pueden ver a medida que avanza el trabajo mediante CloudWatch las métricas de los espacios de `/aws/cleanroomsml/TrainedModelInferenceJobs` nombres `/aws/cleanroomsml/TrainedModels` o los espacios de nombres, respectivamente.
**Registros del modelo**
El acceso a los registros del modelo lo proporciona la política de configuración de privacidad de cada algoritmo del modelo configurado. El autor del modelo establece la política de configuración de privacidad al asociar un algoritmo de modelo configurado (mediante la consola o la `CreateConfiguredModelAlgorithmAssociation` API) a una colaboración. Al establecer la política de configuración de privacidad, se controla qué miembros pueden recibir los registros del modelo.
Además, el autor del modelo puede establecer un patrón de filtro en la política de configuración de privacidad para filtrar los eventos del registro. Todos los registros que envía un contenedor modelo `stdout` o `stderr` que coinciden con el patrón de filtro (si está establecido) se envían a Amazon CloudWatch Logs. Los registros del modelo están disponibles en grupos de CloudWatch registros `/aws/cleanroomsml/TrainedModels` o`/aws/cleanroomsml/TrainedModelInferenceJobs`, respectivamente.
**Métricas definidas personalizadas**
Al configurar un algoritmo de modelo (mediante la consola o la `CreateConfiguredModelAlgorithm` API), el autor del modelo puede proporcionar nombres de métricas e instrucciones de expresiones regulares específicos para buscarlos en los registros de salida. Se pueden ver a medida que avanza el trabajo mediante CloudWatch Metrics en el `/aws/cleanroomsml/TrainedModels` espacio de nombres. Al asociar un algoritmo de modelo configurado, el autor del modelo puede establecer un nivel de ruido opcional en la configuración de privacidad de las métricas para evitar generar datos sin procesar y, al mismo tiempo, ofrecer visibilidad de las tendencias métricas personalizadas. Si se establece un nivel de ruido, las métricas se publican al final del trabajo y no en tiempo real.
# Computación criptográfica para Clean Rooms
Computación criptográfica para Clean Rooms [(C3R) es una capacidad AWS Clean Rooms que se puede utilizar además de las reglas de análisis.](analysis-rules.md) Con C3R, las organizaciones pueden recopilar datos confidenciales para obtener nuevos conocimientos a partir del análisis de datos al tiempo que limitan criptográficamente la información que puede conocer cualquiera de las partes que interviene en el proceso. C3R lo pueden utilizar dos o más partes que deseen colaborar con sus datos confidenciales, pero que estén obligadas a usar solo datos cifrados en la nube.
El cliente de cifrado C3R es una herramienta de cifrado del lado del cliente que puede utilizar para [cifrar sus datos](glossary.md#glossary-encryption) y utilizarlos con ellos. AWS Clean Rooms Cuando utiliza el cliente de cifrado C3R, los datos permanecen protegidos criptográficamente mientras se utilizan en una colaboración. AWS Clean Rooms Al igual que en una AWS Clean Rooms colaboración habitual, los datos de entrada son tablas de bases de datos relacionales y el cálculo se expresa como una consulta SQL. Sin embargo, C3R admite solo un subconjunto limitado de consultas SQL en datos cifrados.
En concreto, C3R es compatible con SQL JOIN y SELECT declaraciones sobre datos protegidos criptográficamente. Cada columna de la tabla de entrada se puede utilizar exactamente en uno de los siguientes tipos de instrucciones SQL:
+ Columnas que están protegidas criptográficamente para su uso en JOIN las declaraciones se llaman **fingerprint columnas**.
+ Columnas que están protegidas criptográficamente para su uso en SELECT las declaraciones se llaman **sealed columnas**.
+ Columnas que no están protegidas criptográficamente para su uso en JOIN o SELECT las declaraciones se llaman **cleartext columnas**.
En algunos casos, GROUP BY las declaraciones se apoyan en fingerprint columnas. Para obtener más información, consulte [Columnas Fingerprint](crypto-computing-column-types.md#fingerprint-columns). Actualmente, C3R no admite el uso de otras construcciones de SQL en datos cifrados, como WHERE cláusulas o funciones agregadas como SUM y AVERAGE, incluso si de otro modo estarían permitidas por las reglas de análisis pertinentes.
C3R está diseñado para proteger los datos de celdas específicas de una tabla. Con la configuración predeterminada de C3R, los datos subyacentes que un cliente pone a disposición de terceros a través de una colaboración permanecen cifrados mientras el contenido se utiliza en AWS Clean Rooms. C3R utiliza el cifrado AES-GCM estándar de la industria para todos sealed columnas y una función pseudoaleatoria estándar del sector, conocida como código de autenticación de mensajes (HMAC) basado en hash, para proteger fingerprint columnas.
A pesar de que C3R cifra los datos de las tablas, es posible que aún se pueda inferir la siguiente información:
+ Información sobre las propias tablas, incluido el número de columnas, los nombres de columna y el número de filas de la tabla.
+ Como ocurre con la mayoría de las formas de cifrado estándar, C3R no intenta ocultar la longitud de los valores cifrados. C3R ofrece la posibilidad de rellenar los valores cifrados para ocultar la longitud exacta del texto sin cifrar. Sin embargo, aun así se podría revelar un límite superior de la longitud del texto sin cifrar de cada columna a un tercero.
+ Información de registro, como cuándo se agregó una fila determinada a una tabla cifrada de C3R.
Para obtener más información acerca de CR3, consulte los siguientes temas.
**Topics**
+ [Consideraciones al utilizar la computación criptográfica para Clean Rooms](crypto-computing-considerations.md)
+ [Tipos de archivo y de datos admitidos en computación criptográfica para Clean Rooms](crypto-computing-file-types.md)
+ [Nombres de columnas en computación criptográfica para Clean Rooms](crypto-computing-column-names.md)
+ [Tipos de columnas en computación criptográfica para Clean Rooms](crypto-computing-column-types.md)
+ [Parámetros de computación criptográfica](crypto-computing-parameters.md)
+ [Indicadores opcionales en computación criptográfica para Clean Rooms](crypto-computing-optional-flags.md)
+ [Consultas con computación criptográfica para Clean Rooms](crypto-computing-queries.md)
+ [Directrices para el cliente de cifrado de C3R](crypto-computing-guidelines.md)
# Consideraciones al utilizar la computación criptográfica para Clean Rooms
La computación criptográfica para Clean Rooms (C3R) busca maximizar la protección de los datos. Sin embargo, algunos casos de uso pueden beneficiarse de niveles más bajos de protección de datos a cambio de funcionalidades adicionales. Puede hacer estas concesiones específicas modificando C3R a partir de su configuración más segura. Como cliente, debe conocer estas ventajas y desventajas, y determinar si son apropiadas para su caso de uso. Entre las ventajas que debe considerar se incluyen las siguientes:
**Topics**
+ [Permitir cleartext mixto y datos cifrados en sus tablas](#allow-mixed-plaintext-and-encrypted-data)
+ [Permitir valores repetidos en columnas fingerprint](#allow-repeated-values)
+ [Disminuir las restricciones de nomenclatura de las columnas fingerprint](#loose-restrictions-on-join-column-names)
+ [Determinar cómo se representan los valores NULL](#determine-null-values)
Para obtener más información sobre cómo establecer parámetros para estos escenarios, consulte [Parámetros de computación criptográfica](crypto-computing-parameters.md).
## Permitir cleartext mixto y datos cifrados en sus tablas
Hacer que todos los datos se cifren en el cliente proporciona la máxima protección de datos. Sin embargo, esto limita ciertos tipos de consultas (por ejemplo, la función de agregación SUM). El riesgo de permitir datos de cleartext es que es factible que cualquier persona con acceso a las tablas cifradas pueda inferir cierta información sobre los valores cifrados. Esto podría hacerse realizando un análisis estadístico de los datos de cleartext y de los datos relacionados.
Por ejemplo, supongamos que tiene las columnas de `City` y `State`. La columna `City` es cleartext y la columna `State` está cifrada. Cuando ve el valor `Chicago` en la columna `City`, esto le ayuda a determinar con una alta probabilidad que el `State` es `Illinois`. Por el contrario, si una columna es `City` y la otra columna es `EmailAddress`, es poco probable que un cleartext `City` revele algo sobre una `EmailAddress` cifrada.
Para obtener más información acerca del parámetro para este escenario, consulte [Parámetro Permitir columnas cleartext](crypto-computing-parameters.md#parameter-allowcleartext).
## Permitir valores repetidos en columnas fingerprint
Para optar por un método más seguro, presuponemos que cualquier columna fingerprint contiene exactamente una instancia de una variable. En una columna fingerprint no se puede repetir ningún elemento. El cliente de cifrado de C3R asigna estos valores cleartext a valores únicos que son indistinguibles de los valores aleatorios. Por lo tanto, es imposible inferir información acerca del cleartext a partir de estos valores aleatorios.
El riesgo de los valores repetidos en una columna fingerprint es que estos valores repetidos resulten en valores repetidos que parezcan aleatorios. Por lo tanto, cualquier persona que tenga acceso a las tablas cifradas podría, en teoría, realizar un análisis estadístico de las columnas fingerprint que podría revelar información sobre los valores cleartext.
De nuevo, presupongamos que la columna fingerprint es `State`, y que cada fila de la tabla corresponde a un hogar estadounidense. Un análisis de frecuencia permitiría inferir qué estado es `California` y cuál es `Wyoming` con una alta probabilidad. Esta inferencia es posible porque `California` tiene muchos más residentes que `Wyoming`. Por el contrario, presupongamos que la columna fingerprint está en un identificador de hogar y que cada hogar aparece en la base de datos entre 1 y 4 veces en una base de datos de millones de entradas. Es poco probable que un análisis de frecuencia revele información útil.
Para obtener más información acerca del parámetro para este escenario, consulte [Parámetro Permitir duplicados](crypto-computing-parameters.md#parameter-allowduplicates).
## Disminuir las restricciones de nomenclatura de las columnas fingerprint
De forma predeterminada, presuponemos que, cuando se combinan dos tablas utilizando columnas fingerprint cifradas, dichas columnas tienen el mismo nombre en cada tabla. El motivo técnico de este resultado es que, de forma predeterminada, deducimos una clave criptográfica diferente para cifrar cada columna fingerprint. Esa clave se deriva de una combinación de la clave secreta compartida de la colaboración y el nombre de la columna. Si intentamos combinar dos columnas con nombres de columna diferentes, obtenemos claves diferentes y no podemos procesar una combinación válida.
Para solucionar este problema, puede desactivar la característica que deriva las claves a partir de cada nombre de columna. A continuación, el cliente de cifrado de C3R utiliza una única clave derivada para todas las columnas fingerprint. El riesgo reside en que se pueda realizar otro tipo de análisis de frecuencia que pueda revelar información.
Volvamos al ejemplo de `City` y `State`. Si derivamos los mismos valores aleatorios para cada columna fingerprint (al no incorporar el nombre de columna), `New York` tiene el mismo valor aleatorio en las columnas `City` y `State`. Nueva York es una de las pocas ciudades de EE. UU. donde el nombre de `City` coincide con el nombre del `State` nombre. Por el contrario, si su conjunto de datos tiene valores completamente diferentes en cada columna, no se filtra información.
Para obtener más información acerca del parámetro para este escenario, consulte [Parámetro Permitir JOIN de columnas con nombres diferentes](crypto-computing-parameters.md#parameter-allowjoin).
## Determinar cómo se representan los valores NULL
La opción que tiene a su disposición consiste en procesar criptográficamente los valores NULL (cifrado y HMAC) como cualquier otro valor. Si no procesa los valores NULL como cualquier otro valor, es posible que se revele información.
Por ejemplo, supongamos que NULL en la columna `Middle Name` de cleartext señala a las personas sin segundo nombre. Si no cifra esos valores, filtrará qué filas de la tabla cifrada se utilizan para personas sin segundo nombre. Esa información podría ser una señal de identificación para algunas personas de ciertas poblaciones. Sin embargo, si procesa los valores NULL criptográficamente, algunas consultas SQL actúan de forma diferente. Por ejemplo, las cláusulas GROUP BY no agruparán los valores fingerprint NULL en columnas fingerprint.
Para obtener más información acerca del parámetro para este escenario, consulte [Parámetro Conservar valores NULL](crypto-computing-parameters.md#parameter-preservenulls).
# Tipos de archivo y de datos admitidos en computación criptográfica para Clean Rooms
El cliente de cifrado de C3R reconoce los siguientes tipos de archivo:
+ Archivos CSV
+ Archivos de Parquet
Puede utilizar el indicador `--fileFormat` del cliente de cifrado de C3R para especificar un formato de archivo de forma explícita. Cuando se especifica de forma explícita, el formato de archivo no viene determinado por la extensión del archivo.
**Topics**
+ [Archivos CSV](#csv-file-type)
+ [Archivos de Parquet](#parquet-file-type)
+ [Cifrar valores que no son de cadena](#encrypt-non-string-values)
## Archivos CSV
Se presupone que un archivo con la extensión .csv tiene formato CSV y contiene texto codificado en UTF-8. El cliente de cifrado de C3R trata todos los valores como cadenas.
### Propiedades admitidas en los archivos .csv
El cliente de cifrado de C3R requiere que los archivos .csv tengan las siguientes propiedades:
+ Puede contener o no una fila de encabezado inicial que designe de manera exclusiva cada columna.
+ Delimitado por comas. (actualmente no se admiten delimitadores personalizados).
+ Texto codificado en UTF-8.
#### Recorte de espacios en blanco de las entradas .csv
Los espacios en blanco iniciales y finales se recortan de las entradas .csv.
#### Codificación NULL personalizada para un archivo .csv
Un archivo .csv puede utilizar una codificación personalizada NULL.
Con el cliente de cifrado de C3R, puede especificar codificaciones personalizadas para las entradas NULL de los datos de entrada utilizando el indicador `--csvInputNULLValue=`. El cliente de cifrado de C3R puede usar codificaciones personalizadas en el archivo de salida generado para las entradas NULL utilizando el indicador `--csvOutputNULLValue=`.
**nota**
Una entrada NULL se considera *carente* de contenido, especialmente en el contexto de un formato tabular más enriquecido, como una tabla SQL. Aunque el formato .csv no admite explícitamente esta caracterización por razones históricas, es una convención habitual considerar que una entrada vacía que contiene solo espacios en blanco es NULL. Por lo tanto, ese es el comportamiento predeterminado del cliente de cifrado de C3R, y se puede personalizar según sea necesario.
### ¿Cómo interpreta C3R las entradas .csv?
La siguiente tabla proporciona ejemplos de cómo se serializan las entradas .csv (de cleartext a cleartext, para mayor claridad) en función de los valores (si los hay) que se proporcionan para los indicadores `--csvInputNULLValue=` y `--csvOutputNULLValue=`. Los espacios en blanco iniciales y finales fuera de las comillas se recortan antes de que C3R interprete el significado de cualquier valor.
| `` | `` | Entrada de entrada | Entrada de salida |
| --- |--- |--- |--- |
| Ninguno | Ninguna | ,AnyProduct, | ,AnyProduct, |
| Ninguna | Ninguna | , AnyProduct , | ,AnyProduct, |
| Ninguna | Ninguna | ,"AnyProduct", | ,AnyProduct, |
| Ninguna | Ninguna | , "AnyProduct" , | ,AnyProduct, |
| Ninguna | Ninguna | ,, | ,, |
| Ninguna | Ninguna | , , | ,, |
| Ninguna | Ninguna | ,"", | ,, |
| Ninguna | Ninguna | ," ", | ," ", |
| Ninguna | Ninguna | , " " , | ," ", |
| "AnyProduct" | "NULL" | ,AnyProduct, | ,NULL, |
| "AnyProduct" | "NULL" | , AnyProduct , | ,NULL, |
| "AnyProduct" | "NULL" | ,"AnyProduct", | ,NULL, |
| "AnyProduct" | "NULL" | , "AnyProduct" , | ,NULL, |
| Ninguna | "NULL" | ,, | ,NULL, |
| Ninguna | "NULL" | , , | ,NULL, |
| Ninguna | "NULL" | ,"", | ,NULL, |
| Ninguna | "NULL" | ," ", | ," ", |
| Ninguno | "NULL" | , " " , | ," ", |
| "" | "NULL" | ,, | ,NULL, |
| "" | "NULL" | , , | ,NULL, |
| "" | "NULL" | ,"", | ,"", |
| "" | "NULL" | ," ", | ," ", |
| "" | "NULL" | , " " , | ," ", |
| "\$1"\$1"" | "NULL" | ,, | ,, |
| "\$1"\$1"" | "NULL" | , , | ,, |
| "\$1"\$1"" | "NULL" | ,"", | ,NULL, |
| "\$1"\$1"" | "NULL" | ," ", | ," ", |
| "\$1"\$1"" | "NULL" | , " " , | ," ", |
### Archivo CSV sin encabezados
No es necesario que el archivo .csv de origen tenga encabezados en la primera fila que asignen un nombre exclusivo a cada columna. Sin embargo, un archivo .csv sin una fila de encabezados requiere un esquema de cifrado posicional. Se requiere el esquema de cifrado posicional en lugar del esquema mapeado típico que se usa tanto para los archivos .csv con una fila de encabezado como para los archivos de Parquet.
Un esquema de cifrado posicional especifica las columnas de salida por posición en lugar de por nombre. Un esquema de cifrado mapeado asigna los nombres de columnas de origen a nombres de columnas de destino. Para obtener más información, incluida una explicación detallada y ejemplos de ambos formatos de esquema, consulte [Esquemas de tablas mapeados y posicionales](create-schema.md#mapped-and-positional-schemas).
## Archivos de Parquet
Se presupone que un archivo con la extensión .parquet tiene formato de Apache Parquet.
### Tipos de datos Parquet admitidos
El cliente de cifrado de C3R puede procesar cualquier dato no complejo (es decir, de tipo primitivo) de un archivo Parquet que corresponda a un tipo de datos admitido por AWS Clean Rooms.
Sin embargo, en las columnas sealed solo se pueden usar columnas de cadena.
Se admiten los siguientes tipos de datos de Parquet:
+ Tipo primitivo `Binary` con las siguientes anotaciones lógicas:
+ Ninguno si `--parquetBinaryAsString` está definido (tipo de datos `STRING`)
+ `Decimal(scale, precision)` (tipo de datos `DECIMAL`)
+ `String` (tipo de datos `STRING`)
+ Tipo de datos primitivo `Boolean` sin anotación lógica (tipo de datos `BOOLEAN`)
+ Tipo de datos primitivo `Double` sin anotación lógica (tipo de datos `DOUBLE`)
+ Tipo primitivo `Fixed_Len_Binary_Array` con anotación lógica `Decimal(scale, precision)` (tipo de datos `DECIMAL`)
+ Tipo de datos primitivo `Float` sin anotación lógica (tipo de datos `FLOAT`)
+ Tipo primitivo `Int32` con las siguientes anotaciones lógicas:
+ Ninguna (tipo de datos `INT`)
+ `Date` (tipo de datos `DATE`)
+ `Decimal(scale, precision)` (tipo de datos `DECIMAL`)
+ `Int(16, true)` (tipo de datos `SMALLINT`)
+ `Int(32, true)` (tipo de datos `INT`)
+ Tipo de datos primitivo `Int64` con las siguientes anotaciones lógicas:
+ Ninguna (tipo de datos `BIGINT`)
+ `Decimal(scale, precision)` (tipo de datos `DECIMAL`)
+ `Int(64, true)` (tipo de datos `BIGINT`)
+ `Timestamp(isUTCAdjusted, TimeUnit.MILLIS)` (tipo de datos `TIMESTAMP`)
+ `Timestamp(isUTCAdjusted, TimeUnit.MICROS)` (tipo de datos `TIMESTAMP`)
+ `Timestamp(isUTCAdjusted, TimeUnit.NANOS)` (tipo de datos `TIMESTAMP`)
## Cifrar valores que no son de cadena
Actualmente, solo se admiten valores de cadena en las columnas sealed.
En el caso de los archivos .csv, el cliente de cifrado de C3R trata todos los valores como texto codificado en UTF-8 y no intenta interpretarlos de forma diferente antes del cifrado.
En el caso de las columnas de huella digital, los tipos se agrupan en clases de equivalencia. Una clase de equivalencia es un conjunto de tipos de datos que se pueden comparar de forma inequívoca para determinar su igualdad mediante un tipo de datos representativo.
Las clases de equivalencia permiten asignar huellas dactilares idénticas al mismo valor semántico independientemente de la representación original. Sin embargo, el mismo valor en dos clases de equivalencia no dará como resultado la misma columna de huella digital.
Por ejemplo, al valor `INTEGRAL` `42` se le asignará la misma huella digital independientemente de si originalmente era `SMALLINT`, `INT` o `BIGINT`. Además, el valor `INTEGRAL` `0` nunca coincidirá con el valor `BOOLEAN` `FALSE` (que se representa mediante el valor `0`).
Las columnas de huellas digitales admiten las siguientes clases de equivalencia y los tipos de AWS Clean Rooms datos correspondientes:
| Clase de equivalencia | Tipo de datos AWS Clean Rooms admitido |
| --- | --- |
| BOOLEAN | BOOLEAN |
| DATE | DATE |
| INTEGRAL | BIGINT, INT, SMALLINT |
| STRING | CHAR, STRING, VARCHAR |
# Nombres de columnas en computación criptográfica para Clean Rooms
De forma predeterminada, los nombres de columnas son importantes en computación criptográfica para Clean Rooms.
Si el valor del parámetro **Permitir JOIN de columnas con nombres diferentes** es **false**, se utilizan los nombres de columna durante el cifrado de las columnas fingerprint. Por este motivo, de forma predeterminada, los colaboradores deben coordinarse con antelación y utilizar los mismos nombres de columna de destino para los datos que se utilizarán en las instrucciones JOIN en las consultas. De forma predeterminada, las columnas cifradas para JOIN con nombres diferentes no ejecutan correctamente la instrucción JOIN en ningún valor.
Si el valor del parámetro **Permitir JOIN de columnas con nombres diferentes** es **true**, las instrucciones JOIN en columnas cifradas como columnas fingerprint se ejecutan correctamente. Cifrar los datos con este parámetro puede permitir cierta inferencia de los valores cleartext. Por ejemplo, si una fila tiene el mismo valor de código de autenticación de mensajes basado en hash (HMAC) tanto en la columna `City` como en la columna `State`, el valor podría ser `New York`.
## Normalización de los nombres de encabezado de columna
El cliente de cifrado de C3R normaliza los nombres de los encabezados de columna. Se eliminan todos los espacios en blanco iniciales y finales, y el nombre de la columna se cambia a minúsculas en el resultado transformado.
La normalización se aplica antes de cualquier otro cómputo, cálculo u otra operación que pueda verse afectada por los nombres de columna. El archivo de salida emitido contiene solo los nombres normalizados.
# Tipos de columnas en computación criptográfica para Clean Rooms
En este tema se proporciona información sobre los tipos de columnas en computación criptográfica para Clean Rooms.
**Topics**
+ [Columnas Fingerprint](#fingerprint-columns)
+ [Columnas selladas](#sealed-columns)
+ [Columnas Cleartext](#cleartext-columns)
## Columnas Fingerprint
Las *columnas Fingerprint* son columnas que están protegidas criptográficamente para su uso en instrucciones JOIN.
Los datos de las columnas fingerprint no se pueden descifrar. Solo se pueden descifrar los datos de las columnas selladas.
Las columnas Fingerprint solo deben usarse en las siguientes cláusulas y funciones SQL:
+ JOIN (INNER, OUTER, LEFT, RIGHT, or FULL) frente a otras columnas fingerprint:
+ Si el valor del parámetro `allowJoinsOnColumnsWithDifferentNames` se establece en `false`, ambas columnas fingerprint de la JOIN deben tener también el mismo nombre.
+ `SELECT COUNT()`
+ `SELECT COUNT(DISTINCT )`
+ `GROUP BY` (usar solo si la colaboración ha definido el valor del parámetro `preserveNulls` como `true`).
Las consultas que infrinjan estas restricciones pueden arrojar resultados incorrectos.
## Columnas selladas
Las *columnas selladas* son columnas que están protegidas criptográficamente para su uso en instrucciones SELECT.
Las columnas selladas solo deben usarse en las siguientes cláusulas y funciones SQL:
+ `SELECT`
+ `SELECT ... AS`
+ `SELECT COUNT()`
**nota**
`SELECT COUNT(DISTINCT )` no se admite.
Las consultas que infrinjan estas restricciones pueden arrojar resultados incorrectos.
### Rellenar datos de una columna sealed antes del cifrado
Cuando se especifica que una columna debe ser una columna sealed, C3R pregunta qué tipo de *relleno* se desea elegir. El relleno de datos antes del cifrado es opcional. Sin relleno (un relleno de tipo `none`), la longitud de los datos cifrados indica el tamaño del cleartext. En determinadas circunstancias, el tamaño del cleartext podría dejar revelar el texto sin formato. Con el relleno (relleno de tipo `fixed` o `max`), todos los valores se rellenan primero hasta alcanzar un tamaño común, y entonces se cifran. Con el relleno, la longitud de los datos cifrados no proporciona información sobre la longitud del cleartext original, salvo por indicar un límite superior de su tamaño.
Si desea rellenar una columna y conoce la longitud máxima en bytes de los datos de esa columna, utilice el relleno `fixed`. Utilice un valor `length` que sea al menos tan grande como la mayor longitud en bytes de esa columna.
**nota**
Si un valor supera la `length` proporcionada, se produce un error y el cifrado falla.
Si desea rellenar una columna y no conoce la longitud máxima en bytes de los datos de esa columna, utilice el relleno `max`. Este modo de relleno rellena todos los datos hasta la longitud del valor más largo, más los bytes de `length` adicionales.
**nota**
Es posible que desee cifrar los datos por lotes o actualizar sus tablas con nuevos datos de forma periódica. Tenga en cuenta que el relleno `max` rellenará las entradas hasta la longitud (más el byte de `length`) de la entrada de texto sin formato más larga de un lote determinado. Esto significa que la longitud del texto cifrado puede variar de un lote a otro. Por lo tanto, si conoce la longitud máxima en bytes de una columna, entonces debe utilizar el relleno `fixed` en lugar de `max`.
## Columnas Cleartext
Las *columnas Cleartext* son columnas que no están protegidas criptográficamente para su uso en instrucciones JOIN o SELECT.
Las columnas Cleartext se pueden usar en cualquier parte de la consulta SQL.
# Parámetros de computación criptográfica
Hay parámetros de computación criptográfica disponibles para las colaboraciones que utilizan la computación criptográfica para Clean Rooms (C3R) al [crear una colaboración](create-collaboration.md). Puede crear una colaboración mediante la AWS Clean Rooms consola o la operación de la `CreateCollaboration` API. En la consola, puede establecer valores para los parámetros en **Parámetros de computación criptográfica** después de activar la opción **Admitir computación criptográfica**. Para obtener más información, consulte los siguientes temas.
**Topics**
+ [Parámetro Permitir columnas cleartext](#parameter-allowcleartext)
+ [Parámetro Permitir duplicados](#parameter-allowduplicates)
+ [Parámetro Permitir JOIN de columnas con nombres diferentes](#parameter-allowjoin)
+ [Parámetro Conservar valores NULL](#parameter-preservenulls)
## Parámetro Permitir columnas cleartext
En la consola, puede configurar el parámetro **Permitir columnas cleartext** al [crear una colaboración](create-collaboration.md) para especificar si se permiten los datos cleartext en una tabla con datos cifrados.
En la siguiente tabla se describen los valores del parámetro **Permitir columnas cleartext**.
| Valor del parámetro | Description (Descripción) |
| --- | --- |
| No | No se permiten columnas Cleartext en la tabla cifrada. Todos los datos están protegidos criptográficamente. |
| Sí | Se permiten columnas Cleartext en la tabla cifrada. Las columnas Cleartext no están protegidas criptográficamente y se incluyen como cleartext. Debe tomar nota de lo que los datos cleartext de las filas pueden revelar sobre el resto de datos de la tabla. Para ejecutar SUM o AVG en columnas específicas, las columnas deben estar en cleartext. |
Mediante la operación `CreateCollaboration` de la API, para el parámetro `dataEncryptionMetadata`, puede establecer el valor de `allowCleartext` en `true` o `false`. Para obtener más información sobre las operaciones de la API, consulte [Referencia de la API de AWS Clean Rooms](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html).
Las columnas Cleartext corresponden a columnas que se clasifican como cleartext en el esquema específico de la tabla. Los datos de estas columnas no están cifrados y se pueden utilizar de cualquier forma. Cleartextlas columnas pueden resultar útiles si los datos no son confidenciales and/or si se necesita más flexibilidad de la que permite una sealed fingerprint columna o columnas cifradas.
## Parámetro Permitir duplicados
En la consola, puede configurar el parámetro **Permitir duplicados** al [crear una colaboración](create-collaboration.md) para especificar si las columnas cifradas para consultas JOIN pueden contener valores no NULL duplicados.
**importante**
Los parámetros **Permitir duplicados**, [**Permitir JOIN de columnas con nombres diferentes**](#parameter-allowjoin) y [**Conservar los valores NULL**](#parameter-preservenulls) tienen efectos distintos pero relacionados.
En la siguiente tabla se describen los valores del parámetro **Permitir duplicados**.
| Valor del parámetro | Description (Descripción) |
| --- | --- |
| No | No se permiten valores repetidos en una columna fingerprint. Todos los valores de una misma columna fingerprint deben ser únicos. |
| Sí | Se permiten valores repetidos en una columna fingerprint. Si necesita combinar columnas con valores repetidos, defina este valor en **Sí**. Si se establece en **Sí**, los patrones de frecuencia que aparecen en las columnas fingerprint de la tabla de C3R o en los resultados pueden implicar información adicional sobre la estructura de los datos cleartext. |
Mediante la operación `CreateCollaboration` de la API, en el parámetro `dataEncryptionMetadata`, puede establecer el valor de `allowDuplicates` en `true` o `false`. Para obtener más información sobre las operaciones de la API, consulte [Referencia de la API de AWS Clean Rooms](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html).
De forma predeterminada, si se deben usar datos cifrados en consultas JOIN, el cliente de cifrado de C3R requiere que esas columnas no tengan valores duplicados. Con este requisito se pretende aumentar la protección de los datos. Este comportamiento puede contribuir a garantizar que los patrones repetidos en los datos no sean observables. Sin embargo, si desea trabajar con datos cifrados en consultas JOIN y no le preocupan los valores duplicados, el parámetro **Permitir duplicados** puede desactivar esta comprobación conservadora.
## Parámetro Permitir JOIN de columnas con nombres diferentes
En la consola, puede configurar el parámetro **Permitir JOIN de columnas con nombres diferentes** al [crear una colaboración](create-collaboration.md) para especificar si se admiten las instrucciones JOIN entre columnas con nombres diferentes.
Para obtener más información, consulte [Normalización de los nombres de encabezado de columna](crypto-computing-column-names.md#column-header-names-normalization)
En la siguiente tabla se describen los valores del parámetro **Permitir JOIN de columnas con nombres diferentes**.
| Valor del parámetro | Description (Descripción) |
| --- | --- |
| No | No se admiten las combinaciones de columnas fingerprint con nombres diferentes. Las instrucciones JOIN solo proporcionan resultados precisos en las columnas que tienen el mismo nombre. El valor **No** proporciona una mayor seguridad de la información, pero requiere que los participantes en la colaboración acuerden previamente los nombres de las columnas. Si dos columnas tienen nombres diferentes cuando se cifran como columnas fingerprint y la opción **Permitir JOIN de columnas con nombres diferentes** está establecida en **No**, las instrucciones JOIN en esas columnas no producen ningún resultado. Esto se debe a que, después del cifrado, no se comparten valores entre ellas. |
| Sí | Se admiten las combinaciones de columnas fingerprint con nombres diferentes. Para mayor flexibilidad, los usuarios pueden establecer este valor en **Sí**, lo que permite las instrucciones JOIN en las columnas independientemente del nombre de la columna. Si se establece en **Sí**, el cliente de cifrado de C3R no tiene en cuenta el nombre de la columna al proteger las columnas fingerprint. Como resultado, en la tabla de C3R se pueden observar valores comunes en distintas columnas fingerprint. Por ejemplo, si una fila tiene el mismo valor JOIN cifrado tanto en una columna `City` como en una columna `State`, sería razonable inferir que ese valor es `New York`. |
Mediante la operación `CreateCollaboration` de la API, para el parámetro `dataEncryptionMetadata`, puede establecer el valor de `allowJoinsOnColumnsWithDifferentNames` en `true` o `false`. Para obtener más información sobre las operaciones de la API, consulte [Referencia de la API de AWS Clean Rooms](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html).
De forma predeterminada, el cifrado de las columnas fingerprint se ve afectado por el `targetHeader` de esa columna, establecido en [Paso 4: generar un esquema de cifrado para un archivo tabular](gen-encryption-schema-csv.md). Por lo tanto, el mismo valor cleartext tiene diferentes representaciones cifradas en cada columna fingerprint diferente en la que se cifra.
En algunos casos, este parámetro puede resultar útil para evitar la inferencia de los valores cleartext. Por ejemplo, observar el mismo valor cifrado en las columnas fingerprint `City` y `State` podría llevar a inferir de forma razonable que el valor es `New York`. Sin embargo, el uso de este parámetro requiere una coordinación adicional por adelantado, de modo que todas las columnas que se van a combinar en consultas tengan nombres compartidos.
Puede utilizar el parámetro **Permitir JOIN de columnas con nombres diferentes** para reducir esta restricción. Si el valor del parámetro se establece en `Yes`, permite que todas las columnas cifradas para JOIN se utilicen juntas independientemente del nombre.
## Parámetro Conservar valores NULL
En la consola, puede configurar el parámetro **Conservar valores NULL** al [crear una colaboración](create-collaboration.md) para indicar que no hay ningún valor presente en esa columna.
En la siguiente tabla se describen los valores del parámetro **Conservar valores NULL**.
| Valor del parámetro | Description (Descripción) |
| --- | --- |
| No | Los valores NULL no se conservan. Los valores NULL no aparecen como NULL en una tabla cifrada. Los valores NULL aparecen como valores aleatorios únicos en una tabla de C3R. |
| Sí | Los valores NULL se conservan. Los valores NULL aparecen como NULL en una tabla cifrada. Si se requiere la semántica SQL de los NULL, puede establecer este valor en Sí. Como resultado, las entradas NULL aparecen como NULL en la tabla de C3R, independientemente de si la columna está cifrada o de la configuración del parámetro Permitir duplicados. |
Mediante la operación `CreateCollaboration` de la API, para el parámetro `dataEncryptionMetadata`, puede establecer el valor de `preserveNulls` en `true` o `false`. Para obtener más información sobre las operaciones de la API, consulte [Referencia de la API de AWS Clean Rooms](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html).
Si el parámetro **Conservar valores NULL** está establecido en **No** para la colaboración:
1. Las entradas NULL de las columnas `cleartext` permanecen inalteradas.
1. Las entradas NULL de las columnas `fingerprint` cifradas se cifran como valores aleatorios para ocultar su contenido. Combinar una columna cifrada con entradas NULL de la columna cleartext no produce ninguna coincidencia para ninguna de las entradas NULL. No se realizan coincidencias porque cada una recibe su propio contenido aleatorio único.
1. Las entradas NULL de las columnas `sealed` cifradas se cifran.
Cuando el valor del parámetro **Conservar valores NULL** se establece en **Sí** para la colaboración, las entradas NULL de todas las columnas se mantienen como NULL, independientemente de si la columna está cifrada o no.
El parámetro **Conservar valores NULL** resulta útil en escenarios tales como el enriquecimiento de datos, donde se desea compartir una falta de información expresada como NULL. El parámetro **Conservar valores NULL** también es útil en formato fingerprint o HMAC cuando se tienen valores NULL en la columna que se desea ejecutar JOIN o GROUP BY.
Si el valor de los parámetros **Permitir duplicados** y **Conservar valores NULL** se establece en **No**, tener más de una entrada NULL en una columna fingerprint produce un error y detiene el cifrado. Si el valor de cualquiera de los parámetros se establece en **Sí**, no se produce tal error.
# Indicadores opcionales en computación criptográfica para Clean Rooms
En las siguientes secciones se describen los indicadores opcionales que puede configurar al [cifrar datos](encrypt-data.md) utilizando el cliente de cifrado de C3R para personalizar y probar archivos tabulares.
**Topics**
+ [Indicador `--csvInputNULLValue`](#optional-flags-CSVinputNullValue)
+ [Indicador `--csvOutputNULLValue`](#optional-flags-CSVoutputNullValue)
+ [Indicador `--enableStackTraces`](#optional-flags-enablestacktraces)
+ [Indicador `--dryRun`](#optional-flags-dry-run)
+ [Indicador `--tempDir`](#optional-flags-working-dir)
## Indicador `--csvInputNULLValue`
Puede usar el indicador `--csvInputNULLValue` para especificar codificaciones personalizadas para las entradas NULL de los datos de entrada al [cifrar datos](encrypt-data.md) utilizando el cliente de cifrado de C3R.
En la siguiente tabla se resumen el uso y los parámetros de este indicador.
| De uso | Parameters |
| --- | --- |
| Opcional. Los usuarios pueden especificar codificaciones personalizadas para las entradas NULL de los datos de entrada. | Codificación especificada por el usuario de valores NULL en el archivo CSV de entrada |
Una entrada NULL es una entrada que se considera carente de contenido, específicamente en el contexto de un formato tabular más enriquecido, como una tabla SQL. Aunque el formato .CSV no admite explícitamente esta caracterización por razones históricas, es una convención habitual considerar que una entrada vacía que contiene solo espacios en blanco es NULL. Por lo tanto, ese es el comportamiento predeterminado del cliente de cifrado de C3R, y se puede personalizar según sea necesario.
## Indicador `--csvOutputNULLValue`
Puede usar el indicador `--csvOutputNULLValue` para especificar codificaciones personalizadas para las entradas NULL en los datos de salida al [cifrar datos](encrypt-data.md) con el cliente de cifrado de C3R.
En la siguiente tabla se resumen el uso y los parámetros de este indicador.
| De uso | Parameters |
| --- | --- |
| Opcional. Los usuarios pueden especificar codificaciones personalizadas en el archivo de salida generado para las entradas NULL. | Codificación especificada por el usuario de valores NULL en el archivo CSV de salida |
Una entrada NULL es una entrada que se considera carente de contenido, específicamente en el contexto de un formato tabular más enriquecido, como una tabla SQL. Aunque el formato .CSV no admite explícitamente esta caracterización por razones históricas, es una convención habitual considerar que una entrada vacía que contiene solo espacios en blanco es NULL. Por lo tanto, ese es el comportamiento predeterminado del cliente de cifrado de C3R, y se puede personalizar según sea necesario.
## Indicador `--enableStackTraces`
Al [cifrar datos](encrypt-data.md) utilizando el cliente de cifrado de C3R, utilice el indicador `--enableStackTraces` para proporcionar información contextual adicional para notificar errores cuando C3R detecte un error.
AWS no recopila errores. Si encuentras un error, utiliza el seguimiento de pila para solucionar el error tú mismo o envía el seguimiento de pila a Soporte para obtener ayuda.
En la siguiente tabla se resumen el uso y los parámetros de este indicador.
| De uso | Parameters |
| --- | --- |
| Opcional. Se utiliza para proporcionar información contextual adicional para notificar errores cuando el cliente de cifrado de C3R detecta un error. | Ninguno |
## Indicador `--dryRun`
Los comandos [encrypt](encrypt-data.md) y [decrypt](decrypt-data.md) del cliente de cifrado de C3R incluyen un indicador `--dryRun` opcional. El indicador toma todos los argumentos proporcionados por el usuario y comprueba su validez y coherencia.
Puede usar el indicador `--dryRun` para comprobar si su archivo de esquema es válido y coherente con el archivo de entrada correspondiente.
En la siguiente tabla se resumen el uso y los parámetros de este indicador.
| De uso | Parameters |
| --- | --- |
| Opcional. Hace que el cliente de cifrado de C3R analice los parámetros y compruebe los archivos, pero no realiza ningún cifrado ni descifrado. | Ninguno |
## Indicador `--tempDir`
Es posible que desee utilizar un directorio temporal, ya que los archivos cifrados a veces pueden superar en tamaño a los no cifrados, dependiendo de la configuración. Los conjuntos de datos también deben cifrarse por colaboración para funcionar correctamente.
Al [cifrar los datos](encrypt-data.md) utilizando C3R, utilice el indicador `--tempDir` para especificar la ubicación en la que se pueden crear los archivos temporales mientras se procesa la entrada.
En la siguiente tabla se resumen el uso y los parámetros de este indicador.
| De uso | Parameters |
| --- | --- |
| Los usuarios pueden especificar la ubicación en la que se pueden crear los archivos temporales mientras se procesa la entrada. | El valor predeterminado es el directorio temporal del sistema. |
# Consultas con computación criptográfica para Clean Rooms
En este tema se proporciona información sobre cómo escribir consultas que utilicen tablas de datos cifradas mediante computación criptográfica para Clean Rooms.
**Topics**
+ [Consultas que se ramifican en NULL](#queries-branch-on-null)
+ [Asignar una columna de origen a varias columnas de destino](#queries-mapping)
+ [Usar los mismos datos para las consultas JOIN y SELECT](#queries-using-same-data)
## Consultas que se ramifican en NULL
Tener una ramificación de consulta en una instrucción NULL significa usar una sintaxis similar a `IF x IS NULL THEN 0 ELSE 1`.
Las consultas siempre se pueden ramificar en instrucciones NULL en columnas de cleartext.
Las consultas se pueden ramificar en instrucciones NULL en columnas sealed y en columnas fingerprint solo cuando el valor del parámetro **Conservar valores NULL** (`preserveNulls`) está establecido en `true`.
Las consultas que infrinjan estas restricciones pueden arrojar resultados incorrectos.
## Asignar una columna de origen a varias columnas de destino
Una columna de origen puede asignarse a varias columnas de destino. Por ejemplo, puede que desee utilizar tanto JOIN como SELECT en una columna.
Para obtener más información, consulte [Usar los mismos datos para las consultas JOIN y SELECT](#queries-using-same-data).
## Usar los mismos datos para las consultas JOIN y SELECT
Si los datos de una columna no son confidenciales, pueden aparecer en una columna de destino de cleartext, lo que permite utilizarlos para cualquier fin.
Si los datos de una columna son confidenciales y deben usarse tanto para las consultas JOIN como para las consultas SELECT, asigne dicha columna de origen a dos columnas de destino del archivo de salida. Una columna se cifra con el `type` como columna fingerprint y la otra columna se cifra con el `type` como columna sellada. La generación de esquemas interactivos del cliente de cifrado C3R sugiere sufijos de encabezado de `_fingerprint` y `_sealed`. Estos sufijos de encabezado pueden ser una convención útil para diferenciar dichas columnas rápidamente.
# Directrices para el cliente de cifrado de C3R
El cliente de cifrado de C3R es una herramienta que permite a las organizaciones recopilar datos confidenciales para obtener nueva información procesable a partir del análisis de datos. La herramienta limita criptográficamente lo que puede aprender cualquier parte y AWS en el proceso. Si bien esto es de vital importancia, el proceso de protección criptográfica de los datos puede suponer una sobrecarga considerable, tanto en términos de recursos de computación como de almacenamiento. Por lo tanto, es importante entender las ventajas y desventajas de usar cada ajuste y saber cómo optimizar la configuración sin dejar de mantener las garantías criptográficas deseadas. Este tema se centra en las implicaciones para el rendimiento de las diferentes configuraciones del cliente de cifrado de C3R y los esquemas.
Todas las configuraciones de cifrado del cliente de cifrado de C3R ofrecen diferentes garantías criptográficas. De forma predeterminada, los ajustes más seguros son aquellos en el nivel de la colaboración. Al habilitar funciones adicionales al crear una colaboración, se debilitan las garantías de privacidad, ya que se permite realizar actividades como análisis de frecuencia en el texto cifrado. Para obtener más información sobre cómo se utilizan estas configuraciones y cuáles son sus implicaciones, consulte [Computación criptográfica para Clean Rooms](crypto-computing.md).
**Topics**
+ [Implicaciones en el rendimiento de los tipos de columnas](#performance-implications)
+ [Solución de problemas relacionados con el aumento imprevisto de tamaño del texto cifrado](#troubleshooting-ciphertext-size)
## Implicaciones en el rendimiento de los tipos de columnas
C3R utiliza tres tipos de columnas: cleartext, fingerprint y sealed. Cada uno de estos tipos de columnas proporciona diferentes garantías criptográficas y tiene distintos usos previstos. En las siguientes secciones se analizan las implicaciones de rendimiento del tipo de columna y el impacto de cada ajuste en el rendimiento.
**Topics**
+ [Columnas Cleartext](#cleartext-columns)
+ [Columnas Fingerprint](#guidelines-fingerprint-columns)
+ [Columnas Sealed](#guidelines-sealed-columns)
### Columnas Cleartext
Las columnas Cleartext no se modifican con respecto a su formato original ni se procesan criptográficamente en modo alguno. Este tipo de columna no se puede configurar y no afecta al rendimiento en términos de almacenamiento o de computación.
### Columnas Fingerprint
Las columnas Fingerprint están previstas para utilizarse para combinar datos de varias tablas. Para ello, el tamaño del texto cifrado resultante debe ser siempre el mismo. Sin embargo, estas columnas se ven afectadas por los ajustes en el nivel de la colaboración. Las columnas Fingerprint pueden incidir en distinto grado en el tamaño del archivo de salida en función del cleartext contenido en la entrada.
**Topics**
+ [Sobrecarga de base para las columnas fingerprint](#fingerprint-columns-base-overhead)
+ [Ajustes de colaboración para las columnas fingerprint](#fingerprint-columns-collab-settings)
+ [Datos de ejemplo para una columna fingerprint](#collab-set-sample-data)
+ [Solución de problemas con columnas fingerprint](#fingerprint-columns-troubleshooting)
#### Sobrecarga de base para las columnas fingerprint
Existe una sobrecarga de base para las columnas fingerprint. Esta sobrecarga es constante y sustituye al tamaño de los bytes de cleartext.
Los datos de las columnas fingerprint se procesan criptográficamente mediante una función de código de autenticación de mensajes basado en hash (HMAC), que convierte los datos en un código de autenticación de mensajes (MAC) de 32 bytes. A continuación, estos datos se procesan a través de un codificador base64, lo que aumenta el tamaño del byte aproximadamente un 33 por ciento. Va precedido de una designación C3R de 8 bytes para designar el tipo de columna a la que pertenecen los datos y la versión de cliente que los generó. El resultado final es de 52 bytes. Este resultado se multiplica entonces por el número de filas para obtener la sobrecarga de base total (utilice el número total de valores distintos de `null` si `preserveNulls` se establece en true).
En la siguiente imagen se muestra cómo * `BASE_OVERHEAD = ` ** `C3R_DESIGNATION + ` ** `(MAC * 1.33)` *
![\[La sobrecarga de base de 52 bytes de una columna fingerprint.\]](http://docs.aws.amazon.com/es_es/clean-rooms/latest/userguide/images/base-overhead-fingerprint.PNG)
El texto cifrado de salida de las columnas fingerprint siempre será de 52 bytes. Esto puede suponer una disminución significativa del almacenamiento si el promedio de los datos de cleartext de entrada es superior a 52 bytes (por ejemplo, las direcciones postales completas). Esto puede suponer un aumento significativo del almacenamiento si el promedio de los datos de cleartext de entrada es inferior a 52 bytes (por ejemplo, las edades de los clientes).
#### Ajustes de colaboración para las columnas fingerprint
##### Ajuste `preserveNulls`
Cuando el ajuste de nivel de la colaboración `preserveNulls` es `false` (predeterminado), cada valor `null` se sustituye por 32 bytes únicos y aleatorios y se procesa como si no fuera `null`. El resultado es que cada valor `null` tiene ahora 52 bytes. Esto puede añadir requisitos de almacenamiento importantes para las tablas que contienen datos muy dispersos en comparación con cuando este ajuste es `true` y los valores `null` se transfieren como `null`.
Si no necesita las garantías de privacidad de este ajuste y prefiere retener los valores `null` de sus conjuntos de datos, habilite el ajuste `preserveNulls` en el momento de crear la colaboración. El ajuste `preserveNulls` no se puede cambiar una vez creada la colaboración.
#### Datos de ejemplo para una columna fingerprint
El siguiente es un ejemplo de conjunto de datos de entrada y salida para una columna fingerprint con los ajustes de configuración que se deben reproducir. Otros ajustes a nivel de la colaboración, como `allowCleartext` y `allowDuplicates`, no afectan a los resultados y se pueden configurar como `true` o `false` si se intenta reproducirlos localmente.
**Secreto compartido de ejemplo**: `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`
**ID de colaboración de ejemplo**: `a1b2c3d4-5678-90ab-cdef-EXAMPLE11111`
**allowJoinsOnColumnsWithDifferentNames**: `True` Este ajuste no afecta al rendimiento ni a los requisitos de almacenamiento. Sin embargo, este ajuste hace que la elección del nombre de la columna sea irrelevante al reproducir los valores que se muestran en las siguientes tablas.
**Ejemplo 1**
| | |
| --- |--- |
| Input | null |
| preserveNulls | TRUE |
| Salida | null |
| Determinista | Yes |
| Bytes de entrada | 0 |
| Bytes de salida | 0 |
**Ejemplo 2**
| | |
| --- |--- |
| Entrada | null |
| preserveNulls | FALSE |
| Salida | 01:hmac:3lkFjthvV3IUu6mMvFc1a\$1XAHwgw/ElmOq4p3Yg25kk= |
| Determinista | No |
| Bytes de entrada | 0 |
| Bytes de salida | 52 |
**Ejemplo 3**
| | |
| --- |--- |
| Input | empty string |
| preserveNulls | - |
| Salida | 01:hmac:oKTgi3Gba\$1eUb3JteSz2EMgXUkF1WgM77UP0Ydw5kPQ= |
| Determinista | Yes |
| Bytes de entrada | 0 |
| Bytes de salida | 52 |
**Ejemplo 4**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyz |
| preserveNulls | - |
| Salida | 01:hmac:kU/IqwG7FMmzzshr0B9scomE0UJUEE7j9keTctplGww= |
| Determinista | Yes |
| Bytes de entrada | 26 |
| Bytes de salida | 52 |
**Ejemplo 5**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 |
| preserveNulls | - |
| Salida | 01:hmac:ks3htnQbw2vdhCRFF6JNzW5LMndJaHG57uvE26mBtSs= |
| Determinista | Yes |
| Bytes de entrada | 62 |
| Bytes de salida | 52 |
#### Solución de problemas con columnas fingerprint
**¿Por qué el texto cifrado de mis columnas fingerprint es varias veces mayor que el tamaño del cleartext que figuraba en ellas?**
El texto cifrado de una columna de fingerprint tiene siempre una longitud de 52 bytes. Si los datos de entrada eran pequeños (por ejemplo, las edades de los clientes), mostrarán un aumento considerable de tamaño. Esto también puede ocurrir si el ajuste `preserveNulls` se define como `false`.
**¿Por qué el texto cifrado de mis columnas de fingerprint es varias veces más pequeño que el cleartext que contiene?**
El texto cifrado de una columna de fingerprint tiene siempre una longitud de 52 bytes. Si los datos de entrada eran grandes (por ejemplo, las direcciones completas de los clientes), su tamaño se reducirá considerablemente.
**¿Cómo sé si necesito las garantías criptográficas que ofrece `preserveNulls`?**
Lamentablemente, la respuesta es que depende. Como mínimo, se deben revisar los [Parámetros de computación criptográfica](crypto-computing-parameters.md) en cuanto a la forma en que el ajuste `preserveNulls` protege sus datos. No obstante, le recomendamos que consulte los requisitos de manejo de datos de su organización y cualquier contrato aplicable a la colaboración correspondiente.
**¿Por qué tengo que incurrir en la sobrecarga de base64?**
Para permitir la compatibilidad con los formatos de archivo tabulares como CSV, es necesaria la codificación base64. Si bien algunos formatos de archivo como Parquet podrían admitir representaciones binarias de datos, es importante que todos los participantes en una colaboración representen los datos de la misma manera para garantizar que los resultados de las consultas sean correctos.
### Columnas Sealed
Las columnas Sealed están diseñadas para utilizarse para transferir datos entre los miembros de una colaboración. El texto cifrado de estas columnas no es determinista y tiene un impacto significativo tanto en el rendimiento como en el almacenamiento en función de cómo se configuren las columnas. Estas columnas se pueden configurar de forma individual y, a menudo, son las que más influyen en el rendimiento del cliente de cifrado de C3R y en el tamaño del archivo de salida resultante.
**Topics**
+ [Sobrecarga de base para las columnas sealed](#sealed-columns-base-overhead)
+ [Ajustes de colaboración para las columnas sealed](#sealed-columns-collab-settings)
+ [Columnas sealed de configuración de esquema: tipos de relleno](#sealed-collab-pad-type)
+ [Datos de ejemplo para una columna sealed](#sealed-collab-sample-data)
+ [Solución de problemas con columnas sealed](#troubleshooting-sealed-columns)
#### Sobrecarga de base para las columnas sealed
Existe una sobrecarga de base para las columnas sealed. Esta sobrecarga es constante y se suma al tamaño de los bytes de cleartext y de relleno (si los hubiera).
Antes de cualquier cifrado, a los datos de las columnas sealed se les añade como prefijo un carácter de 1 byte que designa el tipo de datos que contienen. Si se selecciona el relleno, los datos se rellenan y se añaden 2 bytes que indican el tamaño del relleno. Tras añadir estos bytes, los datos se procesan criptográficamente mediante AES-GCM y se almacenan con IV (12 bytes), nonce (32 bytes) y Auth Tag (16 bytes). A continuación, estos datos se procesan a través de un codificador base64, lo que aumenta el tamaño del byte aproximadamente un 33 por ciento. Los datos van precedidos de una designación C3R de 7 bytes para indicar el tipo de columna a la que pertenecen los datos y la versión de cliente utilizada para generarlos. El resultado es una sobrecarga de base final de 91 bytes. A continuación, este resultado se puede multiplicar por el número de filas para obtener la sobrecarga de base total (utilice el número total de valores no nulos si `preserveNulls` está definido como true).
En la siguiente imagen se muestra cómo * `BASE_OVERHEAD = C3R_DESIGNATION + ((NONCE + IV + DATA_TYPE + PAD_SIZE + AUTH_TAG) * 1.33)` *
![\[La sobrecarga de base de 91 bytes de una columna sealed.\]](http://docs.aws.amazon.com/es_es/clean-rooms/latest/userguide/images/base-overhead-sealed.PNG)
#### Ajustes de colaboración para las columnas sealed
##### Ajuste `preserveNulls`
Cuando el ajuste en el nivel de la colaboración `preserveNulls` es `false` (predeterminado), cada valor `null` es único, aleatorio de 32 bytes, y se procesa como si no fuera `null`. El resultado es que cada valor `null` tiene ahora 91 bytes (más si se rellena). Esto puede añadir requisitos de almacenamiento importantes para las tablas que contienen datos muy dispersos en comparación con cuando este ajuste es `true` y los valores `null` se transfieren como `null`.
Si no necesita las garantías de privacidad de este ajuste y prefiere retener los valores `null` de sus conjuntos de datos, habilite el ajuste `preserveNulls` en el momento de crear la colaboración. El ajuste `preserveNulls` no se puede cambiar una vez creada la colaboración.
#### Columnas sealed de configuración de esquema: tipos de relleno
**Topics**
+ [Tipo de relleno `none`](#pad-type-none)
+ [Tipo de relleno `fixed`](#pad-type-fixed)
+ [Tipo de relleno `max`](#pad-type-max)
##### Tipo de relleno `none`
Seleccionar el tipo de relleno `none` no añade ningún relleno al cleartext ni añade ninguna sobrecarga adicional a la sobrecarga de base descrita anteriormente. La ausencia de relleno se traduce en el tamaño de salida más eficiente en términos de espacio. Sin embargo, no proporciona las mismas garantías de privacidad que los tipos de relleno `fixed` y `max`. Esto se debe a que el tamaño del cleartext subyacente es discernible a partir del tamaño del texto cifrado.
##### Tipo de relleno `fixed`
Seleccionar un tipo de relleno `fixed` es una medida que salvaguarda la privacidad para ocultar la longitud de los datos contenidos en una columna. Esto se hace rellenando todo el cleartext hasta la `pad_length` antes del cifrado. Cualquier dato que supere ese tamaño provoca un fallo del cliente de cifrado de C3R.
Dado que el relleno se añade al cleartext antes de cifrarlo, AES-GCM utiliza un mapeo 1 a 1 de cleartext a texto cifrado en bytes. La codificación base64 añadirá un 33 por ciento. La sobrecarga de almacenamiento adicional del relleno se puede calcular restando la longitud media del cleartext del valor de `pad_length` y multiplicándola por 1,33. El resultado es la sobrecarga promedio de relleno por registro. Este resultado puede entonces multiplicarse por el número de filas para obtener la sobrecarga de relleno total (utilice el número total de valores no `null` si `preserveNulls` está definido como `true`).
`PADDING_OVERHEAD = (PAD_LENGTH - AVG_CLEARTEXT_LENGTH) * 1.33 * ROW_COUNT`
Se recomienda seleccionar la `pad_length` mínima que abarque el mayor valor de columna. Por ejemplo, si el mayor valor es de 50 bytes, basta con una `pad_length` de 50. Un valor superior a ese solo añadirá sobrecarga de almacenamiento adicional.
El relleno fijo no añade ninguna sobrecarga de computación significativa.
##### Tipo de relleno `max`
Seleccionar un tipo de relleno `max` es una medida que salvaguarda la privacidad para ocultar la longitud de los datos contenidos en una columna. Esto se hace rellenando todos los cleartext hasta el valor más alto de la columna, más la `pad_length` adicional, antes de cifrarla. Por lo general, el relleno `max` proporciona las mismas garantías que el relleno `fixed` para un único conjunto de datos, al tiempo que permite no conocer el valor de cleartext más alto de la columna. Sin embargo, es posible que el relleno `max` no ofrezca las mismas garantías de privacidad que el relleno `fixed` en todas las actualizaciones, ya que el valor más alto de cada conjuntos de datos podría variar.
Se recomienda seleccionar una `pad_length` adicional de 0 al usar el relleno `max`. Esta longitud rellena todos los valores para que tengan el mismo tamaño que el mayor valor de la columna. Un valor superior a ese solo añadirá sobrecarga de almacenamiento adicional.
Si conoce el valor de cleartext más alto de una columna determinada, le recomendamos que utilice el tipo de relleno `fixed` en su lugar. El uso del relleno `fixed` crea coherencia entre los conjuntos de datos actualizados. El uso del relleno `max` hace que cada subconjunto de datos se rellene hasta el mayor valor presente en el subconjunto.
#### Datos de ejemplo para una columna sealed
El siguiente es un ejemplo de conjunto de datos de entrada y salida para una columna sealed con los ajustes de configuración que se deben reproducir. Otros ajustes en el nivel de la colaboración, `allowCleartext`, `allowJoinsOnColumnsWithDifferentNames` y `allowDuplicates`, no afectan a los resultados y se pueden definir como `true` o `false` si se intentan reproducir localmente. Aunque estos son los ajustes básicos que se deben reproducir, la columna sealed no es determinista y los valores cambiarán de una vez a otra. El objetivo es mostrar los bytes de entrada en comparación con los bytes de salida. Los valores `pad_length` de ejemplo se han elegido de forma intencionada. Muestran que el relleno `fixed` da como resultado los mismos valores que el relleno `max` con los ajustes de `pad_length` mínima recomendada o cuando se desea un relleno adicional.
**Secreto compartido de ejemplo**: `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`
**ID de colaboración de ejemplo**: `a1b2c3d4-5678-90ab-cdef-EXAMPLE11111`
**Topics**
+ [Tipo de relleno `none`](#sealed-pad-type-none)
+ [Tipo de relleno `fixed` (ejemplo 1)](#sealed-pad-type-fixed)
+ [Tipo de relleno `fixed` (ejemplo 2)](#sealed-pad-type-fixed-2)
+ [Tipo de relleno `max` (ejemplo 1)](#sealed-pad-type-max)
+ [Tipo de relleno `max` (ejemplo 2)](#sealed-pad-type-max-2)
##### Tipo de relleno `none`
**Ejemplo 1**
| | |
| --- |--- |
| Input | null |
| preserveNulls | TRUE |
| Salida | null |
| Determinista | Yes |
| Bytes de entrada | 0 |
| Bytes de salida | 0 |
**Ejemplo 2**
| | |
| --- |--- |
| Entrada | null |
| preserveNulls | FALSE |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSPbNIJfG3iXmu6cbCUrizuV |
| Determinista | No |
| Bytes de entrada | 0 |
| Bytes de salida | 91 |
**Ejemplo 3**
| | |
| --- |--- |
| Input | empty string |
| preserveNulls | - |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSPEM6qR8DWC2PB2GMlX41YK |
| Determinista | No |
| Bytes de entrada | 0 |
| Bytes de salida | 91 |
**Ejemplo 4**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyz |
| preserveNulls | - |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9sGL5VLDQeHzh6DmPpyWNuI= |
| Determinista | No |
| Bytes de entrada | 26 |
| Bytes de salida | 127 |
**Ejemplo 5**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 |
| preserveNulls | - |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnnohrHIGSX54ua\$11/JfcVjc= |
| Determinista | No |
| Bytes de entrada | 62 |
| Bytes de salida | 175 |
##### Tipo de relleno `fixed` (ejemplo 1)
En este ejemplo, `pad_length` es 62 y la mayor entrada es de 62 bytes.
**Ejemplo 1**
| | |
| --- |--- |
| Input | null |
| preserveNulls | TRUE |
| Salida | null |
| Determinista | Yes |
| Bytes de entrada | 0 |
| Bytes de salida | 0 |
**Ejemplo 2**
| | |
| --- |--- |
| Entrada | null |
| preserveNulls | FALSE |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoNpATs0GzbnLkor4L\$1/aSuA= |
| Determinista | No |
| Bytes de entrada | 0 |
| Bytes de salida | 175 |
**Ejemplo 3**
| | |
| --- |--- |
| Input | empty string |
| preserveNulls | - |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoLB53l07VZpA6OwkuXu29CA= |
| Determinista | No |
| Bytes de entrada | 0 |
| Bytes de salida | 175 |
**Ejemplo 4**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyz |
| preserveNulls | - |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcutBAcO\$1Mb9tuU2KIHH31AWg= |
| Determinista | No |
| Bytes de entrada | 26 |
| Bytes de salida | 175 |
**Ejemplo 5**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 |
| preserveNulls | - |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnnohrHIGSX54ua\$11/JfcVjc= |
| Determinista | No |
| Bytes de entrada | 62 |
| Bytes de salida | 175 |
##### Tipo de relleno `fixed` (ejemplo 2)
En este ejemplo, `pad_length` es 162 y la mayor entrada es de 62 bytes.
**Ejemplo 1**
| | |
| --- |--- |
| Input | null |
| preserveNulls | TRUE |
| Salida | null |
| Determinista | Yes |
| Bytes de entrada | 0 |
| Bytes de salida | 0 |
**Ejemplo 2**
| | |
| --- |--- |
| Entrada | null |
| preserveNulls | FALSE |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv/xAySX\$1xcntotL703aBTBb |
| Determinista | No |
| Bytes de entrada | 0 |
| Bytes de salida | 307 |
**Ejemplo 3**
| | |
| --- |--- |
| Input | empty string |
| preserveNulls | - |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv84lVaT9Yd\$16oQx65/\$1gdVT |
| Determinista | No |
| Bytes de entrada | 0 |
| Bytes de salida | 307 |
**Ejemplo 4**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyz |
| preserveNulls | - |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwtX5Hnl\$1WyfO6ks3QMaRDGSf |
| Determinista | No |
| Bytes de entrada | 26 |
| Bytes de salida | 307 |
**Ejemplo 5**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 |
| preserveNulls | - |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwjkJXQZOgPdeFX9Yr/8alV5i |
| Determinista | No |
| Bytes de entrada | 62 |
| Bytes de salida | 307 |
##### Tipo de relleno `max` (ejemplo 1)
En este ejemplo, `pad_length` es 0 y la mayor entrada es de 62 bytes.
**Ejemplo 1**
| | |
| --- |--- |
| Input | null |
| preserveNulls | TRUE |
| Salida | null |
| Determinista | Yes |
| Bytes de entrada | 0 |
| Bytes de salida | 0 |
**Ejemplo 2**
| | |
| --- |--- |
| Entrada | null |
| preserveNulls | FALSE |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoNpATs0GzbnLkor4L\$1/aSuA= |
| Determinista | No |
| Bytes de entrada | 0 |
| Bytes de salida | 175 |
**Ejemplo 3**
| | |
| --- |--- |
| Input | empty string |
| preserveNulls | - |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoLB53l07VZpA6OwkuXu29CA= |
| Determinista | No |
| Bytes de entrada | 0 |
| Bytes de salida | 175 |
**Ejemplo 4**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyz |
| preserveNulls | - |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcutBAcO\$1Mb9tuU2KIHH31AWg= |
| Determinista | No |
| Bytes de entrada | 26 |
| Bytes de salida | 175 |
**Ejemplo 5**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 |
| preserveNulls | - |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnnohrHIGSX54ua\$11/JfcVjc= |
| Determinista | No |
| Bytes de entrada | 62 |
| Bytes de salida | 175 |
##### Tipo de relleno `max` (ejemplo 2)
En este ejemplo, `pad_length` es 100 y la mayor entrada es de 62 bytes.
**Ejemplo 1**
| | |
| --- |--- |
| Input | null |
| preserveNulls | TRUE |
| Salida | null |
| Determinista | Yes |
| Bytes de entrada | 0 |
| Bytes de salida | 0 |
**Ejemplo 2**
| | |
| --- |--- |
| Entrada | null |
| preserveNulls | FALSE |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv/xAySX\$1xcntotL703aBTBb |
| Determinista | No |
| Bytes de entrada | 0 |
| Bytes de salida | 307 |
**Ejemplo 3**
| | |
| --- |--- |
| Input | empty string |
| preserveNulls | - |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv84lVaT9Yd\$16oQx65/\$1gdVT |
| Determinista | No |
| Bytes de entrada | 0 |
| Bytes de salida | 307 |
**Ejemplo 4**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyz |
| preserveNulls | - |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwtX5Hnl\$1WyfO6ks3QMaRDGSf |
| Determinista | No |
| Bytes de entrada | 26 |
| Bytes de salida | 307 |
**Ejemplo 5**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 |
| preserveNulls | - |
| Salida | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwjkJXQZOgPdeFX9Yr/8alV5i |
| Determinista | No |
| Bytes de entrada | 62 |
| Bytes de salida | 307 |
#### Solución de problemas con columnas sealed
**¿Por qué el texto cifrado de mis columnas sealed es varias veces mayor que el tamaño del cleartext que figuraba en ellas?**
Esto depende de varios factores. Por un lado, el texto cifrado de una columna Cleartext siempre tiene una longitud mínima de 91 bytes. Si los datos de entrada eran pequeños (por ejemplo, las edades de los clientes), mostrarán un aumento considerable de tamaño. En segundo lugar, si `preserveNulls` se hubiera definido como `false` y los datos de entrada contuvieran un gran número de valores `null`, cada uno de esos valores `null` se habrá convertido en 91 bytes de texto cifrado. Por último, si se utiliza el relleno, por definición, se añaden bytes a los datos de cleartext antes de cifrarlos.
**La mayoría de los datos de una columna sealed son muy pequeños y necesito utilizar relleno. ¿Puedo simplemente eliminar los valores grandes y procesarlos por separado para ahorrar espacio?**
No le recomendamos que elimine los valores grandes y los procese por separado. Al hacerlo, se modifican las garantías de privacidad que ofrece el cliente de cifrado de C3R. Como modelo de amenaza, presuponga que un observador puede ver ambos conjuntos de datos cifrados. Si el observador ve que un subconjunto de datos tiene una columna considerablemente más o menos rellena que otro subconjunto, puede hacer inferencias sobre el tamaño de los datos de cada subconjunto. Por ejemplo, imaginemos que una columna `fullName` se rellena hasta un total de 40 bytes en un archivo y se rellena hasta 800 bytes en otro archivo. Un observador podría deducir que un conjunto de datos contiene el nombre más largo del mundo (747 bytes).
**¿Debo proporcionar un relleno adicional al usar el tipo de relleno `max`?**
No. Al utilizar el relleno `max`, se recomienda establecer en 0 la `pad_length` (también conocida como relleno adicional *complementario* al mayor valor de la columna).
**¿Puedo elegir una `pad_length` grande al usar el relleno `fixed` para evitar tener que preocuparme de que quepa el valor más grande?**
Sí, pero la gran longitud de relleno es ineficiente y utiliza más almacenamiento del necesario. Le recomendamos que compruebe el tamaño del mayor valor y que defina la `pad_length` con ese valor.
**¿Cómo sé si necesito las garantías criptográficas que ofrece `preserveNulls`?**
Lamentablemente, la respuesta es que depende. Como mínimo, se deben revisar los [Computación criptográfica para Clean Rooms](crypto-computing.md) en cuanto a la forma en que el ajuste `preserveNulls` protege sus datos. No obstante, le recomendamos que consulte los requisitos de manejo de datos de su organización y cualquier contrato aplicable a la colaboración correspondiente.
**¿Por qué tengo que incurrir en la sobrecarga de base64?**
Para permitir la compatibilidad con los formatos de archivo tabulares, como CSV, es necesaria la codificación base64. Si bien algunos formatos de archivo como Parquet podrían admitir representaciones binarias de datos, es importante que todos los participantes en una colaboración representen los datos de la misma manera para garantizar que los resultados de las consultas sean correctos.
## Solución de problemas relacionados con el aumento imprevisto de tamaño del texto cifrado
Supongamos que ha cifrado los datos y que el tamaño de los datos resultantes es sorprendentemente grande. Los siguientes pasos pueden ayudarle a identificar dónde se produjo el aumento de tamaño y qué medidas puede adoptar, si las hubiera.
### Identificar dónde se produjo el aumento de tamaño
Antes de poder averiguar por qué los datos cifrados son significativamente más grandes que los datos de cleartext, primero debe identificar dónde reside el aumento de tamaño. Las columnas de Cleartext se pueden ignorar con total seguridad porque permanecen inalteradas. Observe las columnas fingerprint y sealed restantes, y elija una que parezca significativa.
### Identificar el motivo por el que se produjo el aumento de tamaño
Una columna de fingerprint o una columna sealed pueden contribuir al aumento de tamaño.
**Topics**
+ [¿Procede el aumento de tamaño de una columna fingerprint?](#size-increase-from-fingerprint)
+ [¿Procede el aumento de tamaño de una columna sealed?](#size-increase-from-sealed)
#### ¿Procede el aumento de tamaño de una columna fingerprint?
Si la columna que más contribuye al aumento del almacenamiento es una columna fingerprint, es probable que se deba a que los datos de cleartext son pequeños (por ejemplo, la edad de los clientes). Cada texto cifrado de fingerprint resultante tiene una longitud de 52 bytes. Lamentablemente, no se puede hacer nada al respecto sobre una column-by-column base sólida. Para obtener más información, consulte [Sobrecarga de base para las columnas fingerprint](#fingerprint-columns-base-overhead) para conocer los detalles de esta columna, incluida su incidencia en los requisitos de almacenamiento.
La otra causa posible del aumento de tamaño de una columna fingerprint es el ajuste de la colaboración `preserveNulls`. Si el ajuste de la colaboración para `preserveNulls` está deshabilitado (ajuste predeterminado), todos los valores `null` de las columnas fingerprint se convertirán en 52 bytes de texto cifrado. No hay nada que se pueda hacer al respecto en la colaboración actual. El ajuste `preserveNulls` se define en el momento en que se crea la colaboración, y todos los colaboradores deben usar el mismo ajuste para garantizar que los resultados de la consulta sean correctos. Para obtener más información sobre el ajuste `preserveNulls` y sobre cómo su habilitación afecta a las garantías de privacidad de los datos, consulte [Computación criptográfica para Clean Rooms](crypto-computing.md).
#### ¿Procede el aumento de tamaño de una columna sealed?
Si la columna que más contribuye al aumento del almacenamiento es una columna sealed, hay algunos detalles que podrían contribuir al aumento de tamaño.
Si los datos de cleartext son pequeños (por ejemplo, las edades de los clientes), cada texto cifrado sealed resultante tiene una longitud mínima de 91 bytes. Lamentablemente, no se puede hacer nada al respecto. Para obtener más información, consulte [Sobrecarga de base para las columnas sealed](#sealed-columns-base-overhead) para conocer los detalles de esta columna, incluida su incidencia en los requisitos de almacenamiento.
La segunda causa principal del aumento del almacenamiento en columnas sealed es el relleno. El relleno añade bytes adicionales al cleartext antes del cifrado para ocultar el tamaño de los valores individuales de un conjunto de datos. Se recomienda establecer el relleno en el valor mínimo posible para el conjunto de datos. Como mínimo, se debe definir `pad_length` para el relleno `fixed` de manera que abarque el mayor valor posible de la columna. Todo ajuste superior a ese no aportará garantías de privacidad adicionales. Por ejemplo, si sabe que el mayor valor posible de una columna puede ser de 50 bytes, le recomendamos que defina la `pad_length` en 50 bytes. Sin embargo, si la columna sealed utiliza el relleno `max`, le recomendamos que lo defina la `pad_length` en 0 bytes. Esto se debe a que el relleno `max` se refiere al relleno *adicional* que se suma al mayor valor de la columna.
La última causa posible del aumento de tamaño de una columna sealed es el ajuste de la colaboración `preserveNulls`. Si el ajuste de la colaboración para `preserveNulls` está deshabilitado (ajuste predeterminado), todos los valores `null` de las columnas sealed se convertirán en 91 bytes de texto cifrado. No hay nada que se pueda hacer al respecto en la colaboración actual. El ajuste `preserveNulls` se define en el momento en que se crea la colaboración, y todos los colaboradores deben usar el mismo ajuste para garantizar que los resultados de la consulta sean correctos. Para obtener más información sobre los efectos de esta configuración y sobre cómo su activación afecta a las garantías de privacidad de sus datos, consulte [Computación criptográfica para Clean Rooms](crypto-computing.md).