# Gestión de las actualizaciones de los esquemas En esta sección, se proporciona orientación sobre cómo gestionar las actualizaciones de los esquemas con formatos de datos distintos. Athena es un motor de consultas de esquema sobre lectura. Esto significa que, al crear una tabla en Athena, aplica los esquemas al leer los datos. No cambia ni reescribe los datos subyacentes. Si prevé cambios en los esquemas de las tablas, considere la posibilidad de crearlas en un formato de datos adecuado a sus necesidades. Su objetivo consiste en reutilizar las consultas de Athena existentes a medida que evolucionan los esquemas y evitar errores de discrepancia de esquemas al consultar tablas con particiones. Para alcanzar este objetivo, elija un formato para los datos de una tabla basándose en la tabla del siguiente tema. **Topics** + [Operaciones de actualización de esquemas compatibles por formato de datos](#summary-of-updates) + [Descripción del acceso a los índices para Apache ORC y Apache Parquet](#index-access) + [Actualizaciones de esquema](make-schema-updates.md) + [Actualización de tablas con particiones](updates-and-partitions.md) ## Operaciones de actualización de esquemas compatibles por formato de datos En la siguiente tabla, se resumen los formatos de almacenamiento de datos y las manipulaciones de esquemas compatibles. Utilice esta tabla como ayuda para elegir el formato que le permitirá continuar utilizando las consultas de Athena incluso si los esquemas cambian a lo largo del tiempo. En esta tabla, observe que Parquet y ORC son formatos de columna con diferentes métodos de acceso predeterminados a las columnas. De forma predeterminada, Parquet obtendrá acceso a las columnas por nombre y ORC por índice (valor ordinal). Por lo tanto, Athena proporciona una propiedad del SerDe definida al crear una tabla para cambiar el método de acceso predeterminado a las columnas, lo que permite una mayor flexibilidad en la evolución del esquema. En Parquet, la propiedad `parquet.column.index.access` puede configurarse como `true`, lo que indica al método de acceso a las columnas que debe utilizar el número ordinal de la columna. Si establece esta propiedad en `false`, el método de acceso a las columnas utilizará el nombre de la columna. Del mismo modo, en ORC, utilice la propiedad `orc.column.index.access` para controlar el método de acceso a las columnas. Para obtener más información, consulte [Descripción del acceso a los índices para Apache ORC y Apache Parquet](#index-access). CSV y TSV le permiten realizar todas las manipulaciones de esquemas, excepto la reordenación de columnas y la adición de columnas al principio de la tabla. Por ejemplo, si la evolución del esquema requiere únicamente cambiar el nombre de las columnas pero no eliminarlas, puede optar por crear las tablas en CSV o TSV. Si necesita eliminar columnas, no utilice CSV ni TSV, sino cualquiera de los demás formatos compatibles, preferiblemente un formato de columna, como Parquet u ORC. **Actualizaciones de esquemas y formatos de datos en Athena** | Tipo esperado de actualización de esquema | Resumen | CSV (con y sin encabezados) y TSV | JSON | AVRO | PARQUET: lectura por nombre (predeterminado) | PARQUET: lectura por índice | ORC: lectura por índice (predeterminado) | ORC: lectura por nombre | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | [Cambio del nombre de las columnas](updates-renaming-columns.md) | Almacene los datos en CSV y TSV, o en ORC y Parquet si se leen por índice. | S | N | N | N | S | S | N | | [Adición de columnas al principio o en medio de la tabla](updates-add-columns-beginning-middle-of-table.md) | Almacene los datos en JSON o AVRO, o en Parquet y ORC si se leen por nombre. No utilice CSV ni TSV. | N | S | S | S | N | N | S | | [Adición de columnas al final de la tabla](updates-add-columns-end-of-table.md) | Almacene los datos en CSV o TSV, JSON, AVRO, ORC o Parquet. | S | S | S | S | S | S | S | | [Eliminación de columnas](updates-removing-columns.md) | Almacene los datos en JSON o AVRO, o en Parquet y ORC si se leen por nombre. No utilice CSV ni TSV. | N | S | S | S | N | N | S | | [Reordenación de columnas](updates-reordering-columns.md) | Almacene los datos en AVRO, JSON u ORC y en Parquet si se leen por nombre. | N | S | S | S | N | N | S | | [Cambio del tipo de datos de una columna](updates-changing-column-type.md) | Almacene los datos en cualquier formato, pero pruebe la consulta en Athena para asegurarse de que los tipos de datos son compatibles. Para Parquet y ORC, el cambio de tipo de datos funciona solo para las tablas con particiones. | S | S | S | S | S | S | S | ## Descripción del acceso a los índices para Apache ORC y Apache Parquet PARQUET y ORC son formatos de almacenamiento de datos en columnas que se pueden leer por índice o por nombre. Si almacena los datos en cualquiera de estos formatos, podrá realizar todas las operaciones en los esquemas y ejecutar consultas de Athena sin errores de discrepancia de esquemas. + Athena *lee ORC por índice de forma predeterminada*, tal como se define en `SERDEPROPERTIES ( 'orc.column.index.access'='true')`. Para obtener más información, consulte [ORC: lectura por índice](#orc-read-by-index). + Athena lee *Parquet por nombre de forma predeterminada*, tal y como se define en `SERDEPROPERTIES ( 'parquet.column.index.access'='false')`. Para obtener más información, consulte [Parquet: lectura por nombre](#parquet-read-by-name). Dado que estos son valores predeterminados, es opcional especificar estas propiedades del SerDe en las consultas `CREATE TABLE`, ya que se utilizan implícitamente. Cuando se utilizan, le permiten ejecutar algunas operaciones de actualización de esquemas al mismo tiempo que impiden llevar a cabo otras operaciones similares. Para habilitar esas operaciones, ejecute otra consulta `CREATE TABLE` y cambie la configuración del SerDe. **nota** Las propiedades de SerDe *no* se propagan automáticamente en cada partición. Utilice declaraciones de `ALTER TABLE ADD PARTITION` para configurar las propiedades de SerDe para cada partición. Para automatizar este proceso, escriba un script que ejecute declaraciones de `ALTER TABLE ADD PARTITION`. En las siguientes secciones se describen estos casos de manera detallada. ### ORC: lectura por índice Una tabla con *formato ORC se lee por índice*, de forma predeterminada. Esto lo define la siguiente sintaxis: ``` WITH SERDEPROPERTIES ( 'orc.column.index.access'='true') ``` La *lectura por índice* le permite cambiar el nombre de las columnas. Sin embargo, perderá la capacidad de eliminar columnas o añadirlas en medio de la tabla. Para que ORC lea por nombre, lo que le permitirá añadir columnas en medio de la tabla o eliminar columnas en ORC, establezca la propiedad del SerDe `orc.column.index.access` en `false` en la instrucción `CREATE TABLE`. En esta configuración, perderá la capacidad de cambiar el nombre de las columnas. **nota** En la versión 2 del motor de Athena, cuando las tablas ORC están configuradas para leer por nombre, Athena exige que todos los nombres de columna de los archivos ORC estén en minúsculas. Como Apache Spark no tiene nombres de campo en minúsculas cuando genera archivos ORC, es posible que Athena no pueda leer los datos así generados. La solución consiste en cambiar el nombre de las columnas para que estén en minúsculas o usar la versión 3 del motor de Athena. El siguiente ejemplo ilustra cómo cambiar el formato ORC para que lea por nombre: ``` CREATE EXTERNAL TABLE orders_orc_read_by_name ( `o_comment` string, `o_orderkey` int, `o_custkey` int, `o_orderpriority` string, `o_orderstatus` string, `o_clerk` string, `o_shippriority` int, `o_orderdate` string ) ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.orc.OrcSerde' WITH SERDEPROPERTIES ( 'orc.column.index.access'='false') STORED AS INPUTFORMAT 'org.apache.hadoop.hive.ql.io.orc.OrcInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.orc.OrcOutputFormat' LOCATION 's3://amzn-s3-demo-bucket/orders_orc/'; ``` ### Parquet: lectura por nombre Una tabla con *formato Parquet se lee por nombre*, de forma predeterminada. Esto lo define la siguiente sintaxis: ``` WITH SERDEPROPERTIES ( 'parquet.column.index.access'='false') ``` La *lectura por nombre* le permite añadir columnas en medio de la tabla y eliminar columnas. Sin embargo, perderá la capacidad de cambiar el nombre de las columnas. Para que Parquet lea por índice, lo que le permitirá cambiar el nombre de las columnas, debe crear una tabla con la propiedad del SerDe `parquet.column.index.access` establecida en `true`. # Actualizaciones de esquema En este tema se describen algunos de los cambios que puede realizar en el esquema en instrucciones `CREATE TABLE` sin alterar realmente los datos. Para actualizar un esquema, en algunos casos se puede utilizar un comando `ALTER TABLE`, pero en otros no se modifica realmente una tabla existente. En su lugar, se crea una tabla con un nombre nuevo que modifica el esquema que utilizó en la instrucción `CREATE TABLE` original. Elija un formato de datos compatible que le permita seguir utilizando las consultas de Athena teniendo en cuenta la evolución prevista de los esquemas. Supongamos que tiene una aplicación que lee información de pedidos de una tabla `orders` que existe en dos formatos: CSV y Parquet. El ejemplo siguiente crea una tabla en Parquet: ``` CREATE EXTERNAL TABLE orders_parquet ( `orderkey` int, `orderstatus` string, `totalprice` double, `orderdate` string, `orderpriority` string, `clerk` string, `shippriority` int ) STORED AS PARQUET LOCATION 's3://amzn-s3-demo-bucket/orders_ parquet/'; ``` El ejemplo siguiente crea la misma tabla en CSV: ``` CREATE EXTERNAL TABLE orders_csv ( `orderkey` int, `orderstatus` string, `totalprice` double, `orderdate` string, `orderpriority` string, `clerk` string, `shippriority` int ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' LOCATION 's3://amzn-s3-demo-bucket/orders_csv/'; ``` En los temas siguientes, se muestra cómo afectan las actualizaciones de estas tablas a las consultas de Athena. **Topics** + [Adición de columnas al principio o en medio de la tabla](updates-add-columns-beginning-middle-of-table.md) + [Adición de columnas al final de la tabla](updates-add-columns-end-of-table.md) + [Eliminación de columnas](updates-removing-columns.md) + [Cambiar el nombre de las columnas](updates-renaming-columns.md) + [Reordenación de columnas](updates-reordering-columns.md) + [Cambio del tipo de datos de una columna](updates-changing-column-type.md) # Adición de columnas al principio o en medio de la tabla La adición de columnas es uno de los cambios de esquema más frecuentes. Por ejemplo, se puede añadir una columna para enriquecer una tabla con datos nuevos. O añadir una columna si el origen de una columna existente ha cambiado y se desea mantener la versión anterior de esta columna para que sigan funcionando las aplicaciones que dependen de ella. Para añadir columnas al principio o en medio de la tabla y continuar ejecutando consultas en las tablas existentes, utilice AVRO, JSON, Parquet u ORC si su propiedad del SerDe está configurada para la lectura por nombre. Para obtener más información, consulte [Descripción del acceso a los índices para Apache ORC y Apache Parquet](handling-schema-updates-chapter.md#index-access). No añada columnas al principio o en medio de la tabla en los formatos CSV y TSV, ya que estos dependen de la ordenación. La adición de una columna en estos casos dará lugar a errores de discrepancia de esquemas cuando cambie el esquema de las particiones. En el siguiente ejemplo, se crea una tabla nueva que agrega una columna `o_comment` en el centro de una tabla en función de los datos JSON. ``` CREATE EXTERNAL TABLE orders_json_column_addition ( `o_orderkey` int, `o_custkey` int, `o_orderstatus` string, `o_comment` string, `o_totalprice` double, `o_orderdate` string, `o_orderpriority` string, `o_clerk` string, `o_shippriority` int, ) ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe' LOCATION 's3://amzn-s3-demo-bucket/orders_json/'; ``` # Adición de columnas al final de la tabla Si crea tablas en cualquiera de los formatos que admite Athena, como Parquet, ORC, Avro, JSON, CSV y TSV, puede usar la instrucción `ALTER TABLE ADD COLUMNS` para agregar columnas detrás de las columnas existentes pero antes de las columnas de partición. En el ejemplo siguiente se agrega una columna `comment` al final de la tabla `orders_parquet` antes de cualquier columna de partición: ``` ALTER TABLE orders_parquet ADD COLUMNS (comment string) ``` **nota** Para ver una nueva columna de tabla en el Editor de consultas de Athena después de ejecutar `ALTER TABLE ADD COLUMNS`, actualice manualmente la lista de tablas en el editor y vuelva a expandirla. # Eliminación de columnas Es posible que sea necesario eliminar columnas de las tablas si ya no contienen datos o para restringir el acceso a los datos que contienen. + Puede eliminar columnas de tablas en JSON, Avro, Parquet y ORC si se leen por nombre. Para obtener más información, consulte [Descripción del acceso a los índices para Apache ORC y Apache Parquet](handling-schema-updates-chapter.md#index-access). + No recomendamos eliminar columnas de las tablas en CSV y TSV si se desea conservar las tablas ya creadas en Athena. La eliminación de una columna rompe el esquema y requiere que se vuelva a crear la tabla sin la columna eliminada. En este ejemplo, se elimina una columna ``totalprice`` de una tabla en Parquet y se ejecuta una consulta. En Athena, el formato Parquet se lee por nombre de forma predeterminada, por lo que omitimos la configuración SERDEPROPERTIES que especifica la lectura por nombre. Observe que la consulta siguiente se realiza correctamente, aunque haya cambiado el esquema: ``` CREATE EXTERNAL TABLE orders_parquet_column_removed ( `o_orderkey` int, `o_custkey` int, `o_orderstatus` string, `o_orderdate` string, `o_orderpriority` string, `o_clerk` string, `o_shippriority` int, `o_comment` string ) STORED AS PARQUET LOCATION 's3://amzn-s3-demo-bucket/orders_parquet/'; ``` # Cambiar el nombre de las columnas Es posible que desee cambiar el nombre de las columnas de las tablas para corregir errores de ortografía, hacer que los nombres de las columnas sean mas descriptivos o reutilizar una columna existente para evitar la reordenación de columnas. Puede cambiar el nombre de las columnas si almacena los datos en CSV y TSV, o en Parquet y ORC si están configurados para leer por índice. Para obtener más información, consulte [Descripción del acceso a los índices para Apache ORC y Apache Parquet](handling-schema-updates-chapter.md#index-access). Athena lee los datos con formato CSV y TSV en el orden que tienen las columnas en el esquema y los devuelve en el mismo orden. No utiliza los nombres de las columnas para el mapeo de datos a una columna y por ello es posible cambiar el nombre de las columnas en CSV o TSV sin invalidar las consultas de Athena. Una estrategia para cambiar el nombre de las columnas consiste en crear una nueva tabla basada en los mismos datos subyacentes, pero utilizando nuevos nombres de columna. En el siguiente ejemplo, se crea una nueva tabla `orders_parquet` llamada `orders_parquet_column_renamed`. En el ejemplo se cambia el nombre de la columna ``o_totalprice`` a ``o_total_price`` y, a continuación, se ejecuta una consulta en Athena: ``` CREATE EXTERNAL TABLE orders_parquet_column_renamed ( `o_orderkey` int, `o_custkey` int, `o_orderstatus` string, `o_total_price` double, `o_orderdate` string, `o_orderpriority` string, `o_clerk` string, `o_shippriority` int, `o_comment` string ) STORED AS PARQUET LOCATION 's3://amzn-s3-demo-bucket/orders_parquet/'; ``` En el caso de la tabla en Parquet, la consulta siguiente se ejecuta, pero la columna cuyo nombre ha cambiado no muestra datos, ya que se estaba obteniendo acceso a ella por nombre (comportamiento predeterminado en Parquet) en lugar de por índice: ``` SELECT * FROM orders_parquet_column_renamed; ``` Una consulta con una tabla en CSV tiene un aspecto similar: ``` CREATE EXTERNAL TABLE orders_csv_column_renamed ( `o_orderkey` int, `o_custkey` int, `o_orderstatus` string, `o_total_price` double, `o_orderdate` string, `o_orderpriority` string, `o_clerk` string, `o_shippriority` int, `o_comment` string ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' LOCATION 's3://amzn-s3-demo-bucket/orders_csv/'; ``` En el caso de la tabla en CSV, se ejecuta la consulta siguiente y los datos se muestran en todas las columnas, incluida aquella cuyo nombre se ha cambiado: ``` SELECT * FROM orders_csv_column_renamed; ``` # Reordenación de columnas Solo podrá reordenar las columnas de las tablas que tengan datos en formatos que lean por nombre, como JSON o Parquet, que leen por nombre de forma predeterminada. También puede hacer que ORC lea por nombre, si es necesario. Para obtener más información, consulte [Descripción del acceso a los índices para Apache ORC y Apache Parquet](handling-schema-updates-chapter.md#index-access). En el siguiente ejemplo, se crea una tabla nueva con las columnas en un orden diferente: ``` CREATE EXTERNAL TABLE orders_parquet_columns_reordered ( `o_comment` string, `o_orderkey` int, `o_custkey` int, `o_orderpriority` string, `o_orderstatus` string, `o_clerk` string, `o_shippriority` int, `o_orderdate` string ) STORED AS PARQUET LOCATION 's3://amzn-s3-demo-bucket/orders_parquet/'; ``` # Cambio del tipo de datos de una columna Es posible que desee utilizar un tipo de columna diferente cuando el tipo existente ya no pueda contener la cantidad de información requerida. Por ejemplo, los valores de una columna de ID pueden superar el tamaño del tipo de datos `INT` y requerir el uso del tipo de datos `BIGINT`. ## Consideraciones Cuando tenga previsto utilizar un tipo de datos diferente para una columna, tenga en cuenta los siguientes puntos: + En la mayoría de los casos, no puede cambiar el tipo de datos de una columna de forma directa. En su lugar, se vuelve a crear la tabla de Athena y se define la columna con el tipo de datos nuevo. + Solo es posible leer determinados tipos de datos como otros tipos de datos. Consulte en la tabla de esta sección los tipos de datos que se pueden gestionar de esa manera. + En el caso de los datos en formato Parquet y ORC, no es posible utilizar un tipo de datos diferente para una columna si la tabla no se encuentre particionada. + Para las tablas particionadas con formato Parquet y ORC, el tipo de las columnas de una partición puede ser diferente al que tienen en otra y Athena aplicará `CAST` para asignar el deseado, si es posible. Para obtener más información, consulte [Evitar los errores de discrepancia de esquemas en las tablas con particiones](updates-and-partitions.md#partitions-dealing-with-schema-mismatch-errors). + En el caso de las tablas que solo se crearon con [LazySimpleSerDe](lazy-simple-serde.md), es posible utilizar la instrucción `ALTER TABLE REPLACE COLUMNS` para sustituir las columnas existentes por un tipo de datos diferente, pero todas las columnas existentes que desee conservar también deben redefinirse en la instrucción o, de lo contrario, se eliminarán. Para obtener más información, consulte [ALTER TABLE REPLACE COLUMNS](alter-table-replace-columns.md). + Solo en el caso de las tablas de Apache Iceberg, puede utilizar la instrucción [ALTER TABLE CHANGE COLUMN](querying-iceberg-alter-table-change-column.md) para cambiar el tipo de datos de una columna. `ALTER TABLE REPLACE COLUMNS` no es compatible con las tablas de Iceberg. Para obtener más información, consulte [Evolución del esquema de tabla de Iceberg](querying-iceberg-evolving-table-schema.md). **importante** Recomendamos encarecidamente que compruebe y verifique las consultas antes de realizar traducciones de tipos de datos. Si Athena no puede utilizar el tipo de datos de destino, es posible que falle la consulta `CREATE TABLE`. ## Uso de tipos de datos compatibles Siempre que sea posible, utilice tipos de datos compatibles. En la siguiente tabla se enumeran los tipos de datos que se pueden gestionar como otros tipos de datos: | Tipo de datos original | Tipos de datos de destino disponibles | | --- | --- | | STRING | BYTE, TINYINT, SMALLINT, INT, BIGINT | | BYTE | TINYINT, SMALLINT, INT, BIGINT | | TINYINT | SMALLINT, INT, BIGINT | | SMALLINT | INT, BIGINT | | INT | BIGINT | | FLOAT | DOUBLE | En el siguiente ejemplo, se utiliza la instrucción `CREATE TABLE` de la tabla `orders_json` original para crear una tabla nueva denominada `orders_json_bigint`. La tabla nueva utiliza `BIGINT` en lugar de `INT` como tipo de datos para la columna ``o_shippriority``. ``` CREATE EXTERNAL TABLE orders_json_bigint ( `o_orderkey` int, `o_custkey` int, `o_orderstatus` string, `o_totalprice` double, `o_orderdate` string, `o_orderpriority` string, `o_clerk` string, `o_shippriority` BIGINT ) ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe' LOCATION 's3://amzn-s3-demo-bucket/orders_json'; ``` La consulta siguiente se ejecuta correctamente, de forma similar a la consulta `SELECT` original, antes de cambiar el tipo de datos: ``` Select * from orders_json LIMIT 10; ``` # Actualización de tablas con particiones En Athena, una tabla y sus particiones deben utilizar los mismos formatos de datos, pero sus esquemas pueden ser diferentes. Al crear una partición, esta normalmente hereda el esquema de la tabla. Con el tiempo, los esquemas puede comenzar a ser diferentes. Los motivos pueden ser: + Si se modifica el esquema de la tabla, los esquemas de las particiones no se actualizan para continuar sincronizados con el esquema de la tabla. + El rastreador de AWS Glue permite descubrir datos en particiones con esquemas distintos. Esto significa que, si se crea una tabla en Athena con AWS Glue, cuando el rastreador finalice el procesamiento, los esquemas de la tabla y los de sus particiones podrán ser distintos. + Si se agregan particiones directamente a través de una API de AWS. Athena procesa correctamente las tablas con particiones si se cumplen las restricciones siguientes. Si no se cumplen estas restricciones, Athena genera un error HIVE\$1PARTITION\$1SCHEMA\$1MISMATCH. + El esquema de cada partición es compatible con el esquema de la tabla. + El formato de datos de la tabla permite del tipo de actualización que se desea realizar: añadir, eliminar, cambiar el orden de las columnas o cambiar el tipo de datos de una columna. Por ejemplo, en el caso de los formato CSV y TSV, solo se puede cambiar el nombre de las columnas, añadir columnas al final de la tabla y cambiar el tipo de datos de una columna si los tipos son compatibles, pero no se pueden eliminar columnas. Para otros formatos, se pueden añadir o eliminar columnas, o cambiar el tipo de datos de una columna por otro si los tipos son compatibles. Para obtener información, consulte [Resumen: Actualizaciones y formatos de datos en Athena](handling-schema-updates-chapter.md#summary-of-updates). ## Evitar los errores de discrepancia de esquemas en las tablas con particiones Al principio de la ejecución de las consultas, Athena verifica el esquema de la tabla verificando que el tipo de datos de cada columna es compatible entre la tabla y la partición. + Para los tipos de almacenamiento de datos Parquet y ORC, Athena tiene en cuenta los nombres de las columnas y los utiliza para la verificación de esquemas basada en el nombre de las columnas. Esto elimina los errores `HIVE_PARTITION_SCHEMA_MISMATCH` para las tablas con particiones en Parquet y ORC. (Esto es válido para ORC si la propiedad del SerDe está establecida para obtener acceso al índice por nombre: `orc.column.index.access=FALSE`. Parquet lee el índice por nombre de forma predeterminada). + Para CSV, JSON y Avro, Athena utiliza una verificación de esquemas basada en índices. Esto significa que, si detecta un error de discrepancia de esquemas, debe eliminar la partición que está provocando la discrepancia y volver a crearla para que Athena pueda consultarla sin que se produzcan errores. Athena compara el esquema de la tabla con los esquemas de las particiones. Si se crea una tabla con formato CSV, JSON y AVRO en Athena usando el rastreador de AWS Glue, cuando el rastreador finalice el procesamiento los esquemas de la tabla y los de sus particiones podrán ser distintos. Si hay una discrepancia entre el esquema de la tabla y los esquemas de las particiones, las consultas de Athena generan errores de verificación de esquema similares a este: 'crawler\$1test.click\$1avro' is declared as type 'string', but partition 'partition\$10=2017-01-17' declared column 'col68' as type 'double' ('crawler\$1test.click\$1avro' se ha declarado como de tipo 'cadena', pero la partición 'partition\$10=2017-01-17' ha declarado la columna 'col68' como de tipo 'doble'). Una solución típica para este tipo de errores consiste en eliminar la partición que provoca el error y volver a crearla. Para obtener más información, consulte [ALTER TABLE DROP PARTITION](alter-table-drop-partition.md) y [ALTER TABLE ADD PARTITION](alter-table-add-partition.md).