[Big Data] Descripción general de Apache Iceberg y construcción del código fuente

Cuando utilizamos diferentes motores para cálculos de big data, necesitamos adaptar los datos según los motores de cálculo. Se trata de un problema bastante intratable, para el que ha surgido una nueva solución: una capa intermedia entre el motor informático superior y el formato de almacenamiento subyacente. Esta capa intermedia no es un método de almacenamiento de datos, solo define la organización de los metadatos de los datos y proporciona al motor informático una semántica unificada similar a la "tabla" de las bases de datos tradicionales. Su capa inferior siguen siendo formatos de almacenamiento como Parquet y ORC.

En base a esto, Netflix desarrolló Iceberg, que actualmente es el proyecto de nivel superior de Apache, https://iceberg.apache.org/ .

1. Soluciones de lago de datos: Iceberg

1.1 ¿Qué es el iceberg?

Apache Iceberg es un formato de tabla abierta para grandes conjuntos de datos analíticos. Iceberg agrega tablas a motores informáticos, incluidos Flink Trino Spark y Hive, utilizando un formato de tabla de alto rendimiento que funciona como una tabla SQL.

Iceberg es un formato de tabla de lago de datos abierto. Puede entenderse simplemente como una capa intermedia basada en la capa informática (Flink, Spark) y la capa de almacenamiento (ORC, Parquet, Avro), que utiliza Flink o Spark para escribir datos en Iceberg y luego leer la tabla de otras formas, como como Spark, Flink, Presto, etc.

Implemente la semántica de la tabla además del formato del archivo ( Parquet// Avroetc ):ORC

• Soporte para definir y cambiar el esquema.
• Admite partición oculta y cambio de partición
• Semántica ácida
• Retroceso de la versión histórica
• Poda de particiones con la ayuda de estadísticas de particiones y columnas
• No vincula ningún motor de almacenamiento, se puede extender a HDFS// S3etc.OSS
• Se permiten varias writerescrituras simultáneas y el mecanismo de bloqueo optimista resuelve los conflictos

1.2 Introducción al formato de tabla de Iceberg

Iceberg está diseñado para analizar datos masivos y se define como formato de tabla , que se encuentra entre la capa informática y la capa de almacenamiento.

Table Format administra archivos en el sistema de almacenamiento hacia abajo y proporciona interfaces ricas para la capa informática hacia arriba. El almacenamiento de archivos en el sistema de almacenamiento adoptará una determinada forma organizativa. Por ejemplo, al leer una tabla de Hive, el sistema de archivos HDFS llevará alguna partición, formato de almacenamiento de datos, formato de compresión de datos, información del directorio HDFS de almacenamiento de datos, etc., todo que existen en Metastore , Metastore puede denominarse formato de organización de archivos.

Un excelente formato de organización de archivos , como Iceberg, puede admitir de manera más eficiente que la capa informática superior acceda a archivos en el disco, realice algunas operaciones listo renamebusque.

Tabla y formato de tabla son dos conceptos. Una tabla es un concepto concreto, un concepto a nivel de aplicación. La tabla de la que hablamos todos los días es una simple combinación de filas y columnas. El formato de tabla es un concepto abstracto en el nivel de implementación del sistema de base de datos. Define la definición del esquema de una tabla: qué campos se incluyen, la forma de organización de los archivos debajo de la tabla (modo de partición), información de metadatos (información estadística relacionada con la tabla). , información de índice de tabla )

El lado derecho de la figura anterior muestra la posición de Iceberg en el ecosistema del almacén de datos, y un componente que es casi equivalente a él es Metastore. Pero Metastore es un servicio y Iceberg es un conjunto de jarpaquetes. Para el formato de tabla, creo que contiene principalmente $Los\; significados\; de\; los\; cuatro$ niveles sondefinición del esquema de la tabla(si se admiten tipos de datos complejos),forma de organización de los archivos en la tabla,información estadística relacionada con la tabla,información del índice de la tabla e información de API de lectura y escritura de la tabla.

• El esquema de tabla define una tabla que admite tipos de campos, como int, y tipos de datos complejos.stringlong
• La forma más típica de organización de archivos en la tabla es el modo de partición, que es partición de rango o partición hash.
• Estadísticas de datos de metadatos.
• API de lectura y escritura de tablas. El motor superior lee o escribe los datos de la tabla a través de la API correspondiente.

1.3 La idea central de Iceberg

La idea central de Iceberg es rastrear todos los cambios de la tabla en el eje temporal :

• Una instantánea representa una colección completa de archivos de datos de tablas.
• Cada operación de actualización genera una nueva instantánea.

1.4 Gestión de metadatos del Iceberg

Como se puede ver en la figura, Iceberg administra los datos de manera jerárquica, que se divide principalmente en capa de administración de metadatos y capa de almacenamiento de datos . La capa de gestión de metadatos se puede subdividir en tres capas:

• Archivo de metadatos
• Instantánea
• Manifiesto

El archivo de metadatos almacena la información de metadatos de la versión actual (toda la información de la instantánea); la instantánea representa una instantánea de la operación actual, se commitgenera una instantánea cada vez y una instantánea contiene varios manifiestos. Cada Manifiesto registra la dirección del archivo correspondiente a los datos generados por la operación actual, es decir, la dirección del archivo de datos. Basado en el método de administración de instantáneas, Iceberg puede realizar time travel(lectura de versión histórica y lectura incremental) y proporciona serializable isolation.

La capa de almacenamiento de datos admite diferentes formatos de archivos y actualmente admite Parquet, ORC y AVRO.

1.5 Características importantes de Iceberg

Apache Iceberg se diseñó originalmente para resolver el problema de la computación lenta en el almacén de datos fuera de línea de Hive . Después de años de iteración, se ha convertido en un estándar tabular para crear servicios de lago de datos. Para obtener más información sobre Apache Iceberg, consulte el sitio web oficial de Apache Iceberg.

Actualmente Iceberg proporciona las siguientes capacidades básicas:

1.5.1 Motor informático rico

• La excelente abstracción del kernel hace que no esté vinculado a un motor específico. Actualmente, son compatibles Spark, Flink, Presto y Hive.
• Iceberg proporciona una API nativa de Java, que puede acceder a las tablas de Iceberg sin un motor específico.

1.5.2 Organización de archivos flexible

• Proporciona un modelo de computación incremental basado en flujos y un modelo de computación de tablas a gran escala basado en lotes . Las tareas por lotes y las tareas de flujo pueden usar el mismo modelo de almacenamiento (HDFS, OZONE) y los datos ya no están aislados para construir datos livianos de bajo costo. Servicio de almacenamiento en lago.
• Iceberg admite particiones ocultas ( Hidden Partitioning) y cambios en el diseño de las particiones ( Partition Evolution), lo que facilita a las empresas actualizar las estrategias de partición de datos.
• Admite Parquet, ORC, Avro y otros formatos de almacenamiento.

1.5.3 Optimización del proceso de entrada de datos al lago

• Iceberg proporciona capacidad de transacción ACID y los datos ascendentes se pueden ver inmediatamente después de escribirlos, sin afectar las tareas de procesamiento de datos actuales, lo que simplifica enormemente el ETL.
• Iceberg proporciona cambios de datos Upserta Merge Intonivel de fila, lo que puede reducir en gran medida el retraso en el almacenamiento de datos.

1.5.4 Capacidad de procesamiento de lectura incremental

• Iceberg admite la lectura de datos incrementales en forma de transmisión, logrando la conexión perfecta entre los principales motores informáticos de código abierto que ingresan al lago y analizan escenarios.
• 支持 Streaming estructurado por Spark.
• Admite fuente de tabla Flink.
• Se admite el seguimiento de versiones históricas.

1.6 Estructura del archivo de datos

Primero comprendamos el diseño de Iceberg en el sistema de archivos. En términos generales, Iceberg se divide en dos partes de datos.

• La primera parte es el archivo de datos , como el archivo de la figura siguiente .parquet.
• La segunda parte es el archivo de metadatos de la tabla (archivo de metadatos), incluido el archivo de instantánea ( snap-*.avro), el archivo de manifiesto ( .avro), el archivo TableMetadata ( *.json), etc.

1.6.1 Archivos de metadatos

Entre ellos, el directorio de metadatos almacena los datos de la capa de administración de metadatos. Los metadatos de la tabla no se pueden modificar y siempre se iteran hacia adelante, y la instantánea actual se puede revertir.

1.6.1.1 Metadatos de la tabla

version[number].metadata.json: almacena elementos de cambio de datos para cada versión.

1.6.1.2 Instantánea (Instantánea)

snap-[snapshotID]-[attemptID]-[commitUUID].avro: Almacena archivos de instantáneas.

Una instantánea representa el estado de una tabla Iceberg en un momento determinado, también conocida como lista de manifiesto ( Manifest List), que almacena una lista de archivos de manifiesto, y cada archivo de manifiesto ocupa una fila de datos. El archivo de lista de manifiesto snapcomienza y termina con avroel sufijo, y cada actualización genera un archivo de lista de manifiesto. Cada línea almacena la ruta al archivo de manifiesto.

El archivo de lista ( Manifest Files) almacena información como el rango de partición de los archivos de datos, cuántos archivos de datos se han agregado y cuántos archivos de datos se han eliminado. Los archivos de datos (archivos de datos) se almacenan en diferentes archivos de manifiesto, los archivos de manifiesto se almacenan en un archivo de lista de manifiesto y un archivo de lista de manifiesto representa una instantánea.

1.6.1.3 Archivo de manifiesto

[commitUUID]-[attemptID]-[manifestCount].avro: Archivo de manifiesto.

El archivo de manifiesto se avroalmacena en el formato y avrotermina con el sufijo, y cada operación de actualización generará múltiples archivos de manifiesto. Enumera la lista de archivos de datos que componen una instantánea (Snapshot). Cada fila es una descripción detallada de cada archivo de datos, incluido el estado del archivo de datos , la ruta del archivo , la información de la partición , la información estadística a nivel de columna (como los valores máximo y mínimo de cada columna, el número de valores nulos, etc.), el tamaño del archivo y el número de filas de datos y otra información. La información estadística a nivel de columna puede proporcionar datos que los operadores pueden presionar durante el escaneo, de modo que se puedan filtrar los archivos innecesarios.

1.6.2 Archivos de datos

dataLa forma de organización del directorio es similar a la de Hive y la organización del directorio se basa en particiones ( dtla columna de partición en la figura).

Los archivos de datos de Iceberg generalmente se almacenan en datael directorio. Hay tres formatos de almacenamiento (Avro, ORC y Parquet), dependiendo principalmente del formato de almacenamiento que elija, y los sufijos corresponden a avroo . En un directorio suele haber varios archivos de datos.orcparquet

2. Detalles de implementación de Apache Iceberg

2.1 Método de diseño de instantáneas

2.1.1 Aislamiento de instantáneas

• Las operaciones de lectura solo se aplican a la instantánea generada actualmente.
• Las operaciones de escritura generan nuevas instantáneas aisladas que se confirman atómicamente una vez completada la escritura.

Como se muestra en la figura siguiente, el cuadro de línea de puntos (Instantánea-1) indica que hay una operación de escritura en progreso, pero la operación aún no se ha producido. commitEn este momento, la Instantánea-1 no se puede leer y el usuario solo puede leer commitel Instantánea que ha pasado. De manera similar, Snapshot-2 y Snapshot-3 indican que ya son legibles.

Puede admitir lecturas concurrentes, por ejemplo, los datos de instantáneas de S1, S2 y S3 se pueden leer al mismo tiempo y, al mismo tiempo, se pueden rastrear hasta Instantánea-2 o Instantánea-3. commitUna vez completada la Instantánea-4 , la Instantánea-4 se ha convertido en una línea continua en este momento y los datos se pueden leer.

Por ejemplo, cuando el Current Snapshotpuntero actual se mueve a S3, la operación de lectura del usuario en una tabla es toda para Current Snapshotla instantánea señalada por el puntero de lectura, pero no afectará la operación de lectura de la instantánea anterior.

Cuando todo esté listo, el archivo de metadatos se operará de forma atómica commit, de modo que se complete una escritura de datos de Iceberg. Con cada escritura, Iceberg genera un patrón de organización de archivos como el que se muestra a continuación.

2.1.2 Datos de lectura incremental

Cada instantánea de Iceberg contiene todos los datos de la instantánea anterior, lo que equivale a leer la cantidad total de datos cada vez. Para todo el enlace, el costo de leer los datos es muy alto.

Si solo queremos leer los datos incrementales en el momento actual, podemos implementarlo de acuerdo con el mecanismo de seguimiento de instantáneas en Iceberg, y solo leer los datos incrementales de la Instantánea-1 a la Instantánea-2, que es la parte de datos violeta en el la siguiente figura.

De manera similar, S3 también puede leer solo los datos incrementales de la parte roja o leer los datos incrementales de S1 - S3.

Iceberg admite la separación de lectura y escritura, lo que significa que puede admitir lecturas simultáneas y lecturas incrementales.

2.1.3 Operaciones atómicas

Todas las modificaciones a la lista de archivos son operaciones atómicas.

• Agregar datos en la partición.
• Fusionar o reescribir particiones.

• Iceberg envía transacciones con la granularidad de los archivos , por lo que no hay forma de enviar transacciones en segundos; de lo contrario, el volumen de datos del archivo se expandirá.
• Por ejemplo, Flink utiliza Checkpoint como unidad de escritura. Una vez que los datos físicos se escriben en Iceberg, no se pueden consultar directamente. Solo cuando se activa Checkpoint se escribirán metadatos. En este momento, los datos cambiarán de invisibles a visibles. Y cada ejecución de CheckPoint también lleva una cierta cantidad de tiempo.

2.2 Compromiso transaccional

2.2.1 Requisitos de operación de escritura

El reemplazo atómico asegura una historia lineal. Los reemplazos atómicos están garantizados mediante las siguientes operaciones:

• Registre la versión actual de metadatos base version.
• Cree nuevos metadatos y archivos de manifiesto.
• Se reemplaza atómicamente base versioncon la nueva versión.

2.2.2 Resolución de conflictos: bloqueo optimista

• Supongamos que actualmente no hay otras operaciones de escritura en curso.
• Si se encuentra un conflicto, vuelva a intentarlo según los metadatos más recientes.
• Capacidades proporcionadas por el administrador de metadatos.
• HDFS o la renamecapacidad atómica proporcionada por el sistema de archivos local.

3. Iceberg combinado con el intercambio de escenas de Flink

3.1 Construyendo un canal de datos casi en tiempo real

Iceberg puede extraer datos casi en tiempo real a nivel de minutos.

En primer lugar, uno de los escenarios más clásicos de Flink Iceberg es construir un Data Pipeline en tiempo real . Una gran cantidad de datos de registro generados por el final comercial se importan a una cola de mensajes como Kafka. Después de utilizar el motor informático de flujo Flink para ejecutar ETL, impórtelo a la tabla original de Apache Iceberg. En algunos escenarios empresariales, es necesario ejecutar trabajos de análisis directamente para analizar los datos de la tabla original, mientras que en otros escenarios empresariales es necesario purificar aún más los datos. Luego, podemos iniciar un nuevo trabajo de Flink para consumir datos incrementales de la tabla Apache Iceberg y escribirlos en la tabla Iceberg purificada después del procesamiento. En este momento, es posible que el negocio necesite agregar más datos, por lo que continuamos iniciando el trabajo incremental de Flink en la tabla Iceberg y escribimos los resultados de los datos agregados en la tabla de agregación.

Algunas personas pueden pensar que este escenario también se puede realizar a través de Flink Hive. De hecho, Flink Hive se puede implementar, pero los datos escritos en Hive son más para el análisis de datos del almacén de datos que para la extracción incremental . En términos generales, la escritura incremental de Hive toma la partición como unidad y el tiempo es $Durante\; más\; de\; 15minutos$ , la escritura de alta frecuencia a largo plazo de Flink provocará la expansión de la partición. Y Iceberg permite lograr$1min$ o incluso$Escritura\; incremental\; de$$30\; segundos$ , que puede mejorar en gran medida el rendimiento en tiempo real de los datos de un extremo a otro. El trabajo de análisis de nivel superior puede ver los datos actualizados y el trabajo incremental descendente puede leer los datos actualizados.

3.2 Entrada y salida en tiempo real de datos de los CDC

Flink CDC ( Change Data Capture) escribe datos incrementales en Iceberg.

• Admite la entrada de datos en tiempo casi real en el lago y el análisis de datos.
• El motor informático admite CDC de forma nativa sin agregar componentes adicionales.
• Adopte una solución de almacenamiento de lago de datos unificada y admita múltiples motores de análisis de datos.
• Admite lectura de datos incremental.

Flink Iceberg se puede utilizar para analizar datos de bases de datos relacionales como MySQL binlog. Por un lado, Apache Flink ya admite el análisis de datos CDC de forma nativa. Después de extraer un binlogdato , se convierte automáticamente en cuatro mensajes , , , ververica flink-cdc-connectorque pueden ser reconocidos por Flink Runtime , para que los usuarios puedan seguir haciéndolo en tiempo real. cálculos.INSERTDELETEUPDATE_BEFOREUPDATE_AFTER

Además, una vez que los datos de CDC hayan ingresado con éxito al lago Iceberg, también abriremos motores informáticos comunes, como Presto, Spark, Hive, etc., y podrán leer los datos más recientes en la tabla de Iceberg en tiempo real.

MySQL Binlog es un archivo de registro en formato binario, pero binlogel archivo no puede equipararse con el archivo específico en un determinado directorio del sistema operativo, que es limitado. Binlog se utiliza para registrar cambios en la base de datos dentro de MySQL (solo registra operaciones de modificación de datos) y se utiliza principalmente para la replicación maestro-esclavo y la recuperación incremental de la base de datos.

3.3 Iniciar tareas de Flink a partir de datos históricos de Iceberg

La arquitectura anterior utiliza datos completos de Iceberg y datos incrementales de Kafka para impulsar nuevos trabajos de Flink. Si necesita datos de mucho tiempo en el pasado, como un año, puede usar la arquitectura Lambda común y el enlace fuera de línea se Kafka → Flink → Icebergescribe sincrónicamente en el lago de datos. Debido al alto costo de Kafka, conserve los $7$ días de datos son suficientes. Iceberg tiene un bajo costo de almacenamiento y puede almacenar una cantidad completa de datos históricos. Al iniciar un nuevo trabajo de Flink, solo necesita extraer los datos de Iceberg y luego conectarse sin problemas a los datos de Kafka después de ejecutarlo.

3.4 Uso de datos de Iceberg para corregir resultados de agregación en tiempo real

Además, bajo la arquitectura Lambda, debido a la pérdida de eventos o al orden de llegada de los enlaces en tiempo real, los resultados de la computación de transmisión pueden no ser completamente precisos. En este momento, generalmente se requiere la cantidad total de datos históricos para corregir los resultados del cálculo en tiempo real. Y nuestro Iceberg puede desempeñar muy bien este papel porque puede gestionar datos históricos de forma rentable.

4. Compilación del código fuente de Iceberg 0.11.1

4.1 Compilar Iceberg

Construir Iceberg requiere calificación $5.6$ y Java$8$ ambientes.

4.1.1 Descargar el paquete Iceberg 0.11.1

enlace de descarga:

• https://github.com/apache/iceberg/releases/tag/apache-iceberg-0.11.1
• https://www.apache.org/dyn/closer.cgi/iceberg/apache-iceberg-0.11.0/apache-iceberg-0.11.0.tar.gz

4.1.2 Descomprimir el paquete Iceberg 0.11.1

[bigdata@bigdata185 software]$ tar -zxvf iceberg-apache-iceberg-0.11.1.tar.gz -C /opt/module/ 
[bigdata@bigdata185 software]$ cd /opt/module/iceberg-apache-iceberg-0.11.1/

4.1.3 Modificar la versión correspondiente

Elegimos la versión más estable para compilar, Hadoop $\mathrm{2.7.7}$、 Colmena$\mathrm{2.3.9}$、 Fink$\mathrm{1.11.6}$、 Chispa$\mathrm{3.0.3}$。

org.apache.flink:* = 1.11.6 
org.apache.hadoop:* = 2.7.7
org.apache.hive:hive-metastore = 2.3.9 
org.apache.hive:hive-serde = 2.3.9 
org.apache.spark:spark-hive_2.12 = 3.0.3

4.1.4 Editar el archivo build.gradle y agregar fuentes nacionales

(1) Agregue el buildscriptde repositories:

maven { url 'https://mirrors.huaweicloud.com/repository/maven/' }

Después de agregarlo se ve así:

buildscript {
  repositories {
    jcenter()
    gradlePluginPortal()
    maven { url 'https://mirrors.huaweicloud.com/repository/maven/' }
  }
  dependencies {
    classpath 'com.github.jengelman.gradle.plugins:shadow:5.0.0'
    classpath 'com.palantir.baseline:gradle-baseline-java:3.36.2'
    classpath 'com.palantir.gradle.gitversion:gradle-git-version:0.12.3'
    classpath 'com.diffplug.spotless:spotless-plugin-gradle:3.14.0'
    classpath 'gradle.plugin.org.inferred:gradle-processors:2.1.0'
    classpath 'me.champeau.gradle:jmh-gradle-plugin:0.4.8'
  }
}

allprojectsAgregue (2) :

maven { url 'https://mirrors.huaweicloud.com/repository/maven/' }

Después de agregarlo se ve así

allprojects {
  group = "org.apache.iceberg"
  version = getProjectVersion()
  repositories {
    maven { url 'https://mirrors.huaweicloud.com/repository/maven/' }
    mavenCentral()
    mavenLocal()
  }
}

4.1.5 Descargar dependencias (opcional)

Ingrese al directorio raíz del proyecto y ejecute el script:

[bigdata@bigdata185 iceberg-apache-iceberg-0.11.1]$ ./gradlew dependencies

4.1.6 Compilación oficial

(1) Ingrese al directorio raíz del proyecto y ejecute:

[bigdata@bigdata185 iceberg-apache-iceberg-0.11.1]$ ./gradlew build

(2) El comando anterior ejecutará la prueba unitaria en el código; de lo contrario, ejecute el siguiente comando:

[bigdata@bigdata185 iceberg-apache-iceberg-0.11.1]$ ./gradlew build -x test -x scalaStyle

4.1.7 Directorio generado

4.2 Despliegue del entorno Iceberg

En los siguientes capítulos, presentamos cómo integrar Iceberg 0.11.1y Flink 1.11.6, respectivamente .Spark 3.0.3Hive 2.3.9

5. Resumen

• Introducción a Iceberg, una solución de lago de datos.
• Detalles técnicos de implementación de Apache Iceberg.
• Iceberg combina el intercambio de escenas con Flink.
• Iceberg $\mathrm{0.11.1}$ compilación del código fuente.