.cloud.databricks.com/oidc/v1/token', auth_scope = 'all-apis,sql';
```
### Listar tablas
```sql theme={null}
SHOW TABLES FROM unity
```
```response theme={null}
┌─name───────────────────────────────────────────────┐
│ unity.logs │
│ unity.single_day_log │
└────────────────────────────────────────────────────┘
```
### Explora el esquema
```sql theme={null}
SHOW CREATE TABLE unity.`icebench.single_day_log`
CREATE TABLE unity.`icebench.single_day_log`
(
`pull_request_number` Nullable(Int64),
`commit_sha` Nullable(String),
`check_start_time` Nullable(DateTime64(6, 'UTC')),
`check_name` Nullable(String),
`instance_type` Nullable(String),
`instance_id` Nullable(String),
`event_date` Nullable(Date32),
`event_time` Nullable(DateTime64(6, 'UTC')),
`event_time_microseconds` Nullable(DateTime64(6, 'UTC')),
`thread_name` Nullable(String),
`thread_id` Nullable(Decimal(20, 0)),
`level` Nullable(String),
`query_id` Nullable(String),
`logger_name` Nullable(String),
`message` Nullable(String),
`revision` Nullable(Int64),
`source_file` Nullable(String),
`source_line` Nullable(Decimal(20, 0)),
`message_format_string` Nullable(String)
)
ENGINE = Iceberg('s3://...')
```
Esta tabla contiene \~283 millones de filas de logs de ejecuciones de pruebas de CI de ClickHouse: un conjunto de datos realista para explorar el rendimiento analítico.
```sql theme={null}
SELECT count()
FROM unity.`icebench.single_day_log`
```
```response theme={null}
┌───count()─┐
│ 282634391 │ -- 282.63 millones
└───────────┘
1 row in set. Elapsed: 1.265 sec.
```
## Consulta en la tabla del lago de datos
Ejecutemos una consulta que filtre los logs por nombre de hilo y tipo de instancia, busque errores en el texto del mensaje y agrupe los resultados por logger:
```sql theme={null}
SELECT
logger_name,
count() AS c
FROM icebench.`icebench.single_day_log`
WHERE (thread_name = 'TCPHandler')
AND (instance_type = 'm6i.4xlarge')
AND hasToken(message, 'error')
GROUP BY logger_name
ORDER BY c DESC
LIMIT 5
```
```response theme={null}
┌─logger_name──────────────┬────c─┐
│ executeQuery │ 6907 │
│ TCPHandler │ 4145 │
│ TCP-Session │ 790 │
│ PostgreSQLConnectionPool │ 530 │
│ ContextAccess (default) │ 392 │
└──────────────────────────┴──────┘
5 rows in set. Elapsed: 8.921 sec. Processed 282.63 million rows, 5.42 GB (31.68 million rows/s., 607.26 MB/s.)
Peak memory usage: 4.35 GiB.
```
La consulta tarda casi **9 segundos** porque ClickHouse debe realizar un escaneo completo de la tabla en todos los archivos Parquet del almacenamiento de objetos. El rendimiento podría mejorar con el particionamiento, pero columnas como `logger_name` pueden tener una cardinalidad demasiado alta para particionarlas de forma eficaz. Además, no tenemos índices como [índices de texto](/es/reference/engines/table-engines/mergetree-family/mergetree#text) para descartar aún más datos. Aquí es donde MergeTree destaca.
## Cargar datos en MergeTree
### Crear una tabla optimizada
Creamos una tabla MergeTree prestando especial atención a la optimización del esquema. Observe algunas diferencias clave con respecto al esquema de Iceberg:
* **Sin envoltorios `Nullable`**: eliminar `Nullable` mejora la eficiencia del almacenamiento y el rendimiento de las consultas.
* **`LowCardinality(String)`** en las columnas `level`, `instance_type`, `thread_name` y `check_name`: aplica codificación por diccionario a columnas con pocos valores distintos para mejorar la compresión y acelerar el filtrado.
* **Un [índice de texto completo](/es/reference/engines/table-engines/mergetree-family/textindexes)** en la columna `message`: acelera las búsquedas de texto basadas en tokens, como `hasToken(message, 'error')`.
* **Una clave `ORDER BY`** de `(instance_type, thread_name, toStartOfMinute(event_time))`: alinea los datos en disco con patrones de filtro habituales para que el [índice primario disperso](/es/guides/clickhouse/data-modelling/sparse-primary-indexes) pueda omitir gránulos irrelevantes.
```sql theme={null}
SET enable_full_text_index = 1;
CREATE TABLE single_day_log
(
`pull_request_number` Int64,
`commit_sha` String,
`check_start_time` DateTime64(6, 'UTC'),
`check_name` LowCardinality(String),
`instance_type` LowCardinality(String),
`instance_id` String,
`event_date` Date32,
`event_time` DateTime64(6, 'UTC'),
`event_time_microseconds` DateTime64(6, 'UTC'),
`thread_name` LowCardinality(String),
`thread_id` Decimal(20, 0),
`level` LowCardinality(String),
`query_id` String,
`logger_name` String,
`message` String,
`revision` Int64,
`source_file` String,
`source_line` Decimal(20, 0),
`message_format_string` String,
INDEX text_idx(message) TYPE text(tokenizer = splitByNonAlpha)
)
ENGINE = MergeTree
ORDER BY (instance_type, thread_name, toStartOfMinute(event_time))
```
### Insertar datos desde el catálogo
Usa `INSERT INTO SELECT` para cargar los \~300 millones desde la tabla del lago de datos a nuestra tabla de ClickHouse:
```sql theme={null}
INSERT INTO single_day_log SELECT * FROM icebench.`icebench.single_day_log`
```
```response theme={null}
282634391 rows in set. Elapsed: 237.680 sec. Processed 282.63 million rows, 5.42 GB (1.19 million rows/s., 22.79 MB/s.)
Peak memory usage: 18.62 GiB.
```
## Vuelve a ejecutar la consulta
Si ahora ejecutamos la misma consulta sobre la tabla MergeTree, veremos que el rendimiento mejora drásticamente:
```sql theme={null}
SELECT
logger_name,
count() AS c
FROM single_day_log
WHERE (thread_name = 'TCPHandler')
AND (instance_type = 'm6i.4xlarge')
AND hasToken(message, 'error')
GROUP BY logger_name
ORDER BY c DESC
LIMIT 5
```
```response theme={null}
┌─logger_name──────────────┬────c─┐
│ executeQuery │ 6907 │
│ TCPHandler │ 4145 │
│ TCP-Session │ 790 │
│ PostgreSQLConnectionPool │ 530 │
│ ContextAccess (default) │ 392 │
└──────────────────────────┴──────┘
5 rows in set. Elapsed: 0.220 sec. Processed 13.84 million rows, 2.85 GB (62.97 million rows/s., 12.94 GB/s.)
Peak memory usage: 1.12 GiB.
```
La misma consulta ahora se ejecuta en **0.22 segundos** - una **mejora de rendimiento de \~40x**. Dos optimizaciones clave impulsan esta mejora:
* **Índice primario disperso** - La clave `ORDER BY (instance_type, thread_name, ...)` permite que ClickHouse salte directamente a los gránulos que coinciden con `instance_type = 'm6i.4xlarge'` y `thread_name = 'TCPHandler'`, lo que reduce las filas procesadas de 283 millones a solo 14 millones.
* **Índice de texto completo** - El índice `text_idx` de la columna `message` permite que `hasToken(message, 'error')` se resuelva mediante el índice, en lugar de analizar cada cadena de mensaje, lo que reduce aún más los datos que ClickHouse necesita leer.
El resultado es una consulta capaz de sustentar sin problemas un dashboard en tiempo real, con una escala y una latencia que las consultas sobre archivos Parquet en almacenamiento de objetos no pueden igualar.