Realtime Compute for Apache Flink:Funciones de tabla

Descripción general

• remote storage: Para garantizar una baja latencia, los datos más recientes se conservan en discos locales. Los datos antiguos se migran de forma asíncrona al almacenamiento remoto para reducir los costos de almacenamiento local.

• column pruning: Durante una consulta, solo se leen las columnas necesarias y se omiten las irrelevantes, lo que reduce la cantidad de datos leídos.

• predicate pushdown: El servidor utiliza estadísticas de columnas para omitir bloques de datos que no coinciden con los filtros. Esto reduce la E/S de red y la sobrecarga de deserialización.

• log compression: Esta función utiliza el mecanismo de compresión nativo de Arrow para reducir significativamente los costos de transferencia de red y almacenamiento.

Almacenamiento remoto

El almacenamiento remoto hace referencia a un sistema de almacenamiento externo más rentable y confiable, como Amazon S3, Hadoop Distributed File System (HDFS) o Alibaba Cloud OSS. De forma predeterminada, Fluss utiliza Alibaba Cloud OSS como su almacenamiento remoto.

• Fluss utiliza el almacenamiento remoto para la organización de datos en niveles y la tolerancia a fallos.

• En las tablas de registros, el almacenamiento remoto guarda segmentos de registro organizados por niveles.

• En las tablas de clave primaria, el almacenamiento remoto guarda instantáneas y segmentos de datos del registro de cambios.

Poda de columnas

La poda de columnas es una optimización que reduce la cantidad de datos leídos al leer únicamente las columnas requeridas y omitir las irrelevantes durante una consulta. Fluss admite la poda de columnas para lecturas de flujo, lo que lo convierte en uno de los pocos sistemas en la industria con esta capacidad para escenarios de procesamiento de flujos en tiempo real.

• Fluss admite la poda de columnas tanto para tablas de registros como para los registros de cambios de tablas de clave primaria. Esta función reduce la E/S de almacenamiento, disminuye el tráfico de red y reduce la carga de análisis sintáctico en el cliente, lo que mejora significativamente el rendimiento de las consultas.

• Tanto para el procesamiento por lotes como para el procesamiento de flujos, el sistema siempre procesa solo los campos necesarios, lo que maximiza la utilización de recursos.

Cuando un motor de cómputo, como Flink, ejecuta una consulta, analiza las columnas requeridas e indica a Fluss que devuelva solo esas columnas.

SELECT id, name FROM log_table WHERE timestamp > '2023-01-01'

Esta consulta lee únicamente las columnas id, name y timestamp. Fluss no lee otras columnas de la tabla, como address y status, desde el almacenamiento, lo que evita lecturas innecesarias.

Pushdown de predicados

El pushdown de predicados es una optimización del lado del servidor que se aplica únicamente a tablas de registros. El servidor evalúa los predicados de filtro con base en las estadísticas de columna (min, max y nullCount) de cada RecordBatch. Luego omite lotes completos que no pueden contener filas coincidentes, lo que reduce la E/S de red y la sobrecarga de deserialización.

CREATE TABLE log_table (
  order_id BIGINT,
  item_id BIGINT,
  amount INT,
  address STRING
) WITH (
  'table.statistics.columns' = 'order_id,amount'
);

ALTER TABLE log_table SET ('table.statistics.columns' = 'order_id,amount');

Compresión de registros

Fluss utiliza el mecanismo de compresión nativo de Arrow. Los datos comprimidos siguen cumpliendo con el estándar de formato Arrow. Fluss comprime cada columna de forma independiente, lo que permite que funcione la poda de columnas y no afecta el rendimiento de las consultas.

Proceso de compresión

• Para tablas de registros, el escritor en el lado del cliente comprime los datos y los escribe en el almacenamiento en un formato comprimido. Al leer los datos, el escáner de registros los descomprime.

• Para los registros de cambios de tablas de clave primaria, el servidor genera y comprime el registro.

Beneficios de la compresión

La compresión reduce significativamente los costos de transferencia de red y almacenamiento. Las pruebas de rendimiento muestran que ZSTD en el nivel de compresión 3 puede lograr una relación de compresión de aproximadamente 5:1 (por ejemplo, comprimir 5 GB de datos a 1 GB). La reducción en la sobrecarga de red también aumenta el rendimiento de lectura y escritura.

Configuración

Ejemplo de configuración

-- Set the compression algorithm to ZSTD and the compression level to 2
CREATE TABLE log_table (
  order_id BIGINT,
  item_id BIGINT,
  amount INT,
  address STRING
) WITH (
  'table.log.arrow.compression.type' = 'ZSTD',
  'table.log.arrow.compression.zstd.level' = '2'
);