Apache Kudu

Publicado por

En septiembre de 2015, Cloudera anunció la versión Beta de Apache Kudu, y dos meses más tarde, decidió donar el proyecto en su totalidad a la Apache Software Foundation para abrirla a toda la comunidad de desarrolladores open-source. En Enero de 2017 Cloudera lanza la versión Enterprise 5.10 y una de las principales diferencias con respecto a versiones anteriores es la incorporación de Kudu.

Índice

  1. Introducción
  2. Conceptos y términos
  3. Arquitectura
  4. Modelo de datos

1. Introducción

Kudu es un gestor de almacenamiento columnar desarrollado para la plataforma Hadoop. Kudu comparte las propiedades técnicas de las aplicaciones para ecosistemas Hadoop: se ejecuta sobre commodity hardware, es escalable horizontalmente, y admite operaciones en alta disponibilidad.

Las ventajas de Kudu son:

  • Procesamiento rápidos sobre trabajos OLAP
  • Integración con MapReduce, Spark y otros componentes del ecosistema Hadoop
  • Integración “strecha” con Impala (incubando), convirtiéndolo en una buena alternativa al uso de HDFS con  Parquet
  • Tiene un modelo de consistencia fuerte pero flexible
  • Gran rendimiento al ejecutar simultáneamente cargas de trabajo secuenciales y aleatorias
  • Fácil de administrar desde Cloudera
  • Alta disponibilidad. Los Tablet Servers y Masters utilizan el algoritmo de consenso de Raft, que asegura que mientras más de la mitad del número total de réplicas este disponible, la tablet estará disponible para lecturas y escrituras
  • Modelo de datos estructurado

Algunas de las aplicaciones de Kudu son:

  • Aplicaciones de reporting donde los datos recién llegados deban estar disponibles inmediatamente para los usuarios finales
  • Aplicaciones de series temporales que deben soportar simultáneamente:
    • Consultas sobre grandes cantidades de datos históricos
    • Consultas muy rápidas sobre una entidad
  • Aplicaciones que utilizan modelos predictivos para tomar decisiones en tiempo real con un refresco periódico de los modelos utilizando datos históricos

2. Conceptos y términos

Kudu es un almacén de datos columnar que se caracteriza por tener los datos guardados en columnas fuertemente tipadas. Con un diseño adecuado las cargas de datos de trabajo analíticas o de data warehouse, son muy rápidas.

Para consultas analíticas, se puede leer una sola columna, o una parte de esa columna, mientras se ignoran otras columnas, dando así mucha eficiencia en la lectura. Esto significa que una consulta lee el número mínimo de bloques en disco posible.

Como una columna solo tiene un tipo de dato, la compresión basada en patrones puede ser de un orden de magnitud mayor en eficiencia que la compresión de tipos de datos mixtos, que se utilizan en soluciones basadas en filas.

  • Tabla: es donde se encuentran los datos guardados en Kudu. Una tabla tiene un esquema y una clave primaria totalmente ordenada. La tabla se divide en segmentos llamados tablets.
  • Tablet: es un segmento contiguo de una tabla, similar a la partición en otros sistemas de almacenamiento. Una tablet esta replicada sobre múltiples servidores de tablets, y en un instante dado en el tiempo, una de éstas replicas es considerada la lider de la tablet. Cualquier tablet puede servir para leer, y para escribir, se necesita consenso sobre todo el conjunto de servidores sirviendo la tablet.
  • Tablet Server: el servidor de tablets almacena y sirve tablets a los clientes. Para una tablet existe un solo servidor líder, el resto actúan como seguidores que replican la tablet. Solo los líderes pueden tramitar solicitudes de escritura, mientras que los seguidores se encargan de atender las peticiones de lectura de los usuarios.
    Los servidores de tablets envían latidos al master cada cierto tiempo.
  • Master: se encarga de mantener el registro de todas las tablets, de los servidores, de la tabla Catalog, y otros metadatos relacionados con el clúster. En un punto dado en el tiempo, sólo puede existir un master (el líder). Si el master desaparece, un nuevo líder es elegido utilizando el algoritmo de consenso de Raft.
    El master además coordina el intercambio de metadatos  con los clientes. Toda la información del master esta guardada en una tabla, que es replicada en todos los candidatos a master.
  • Tabla Catalog: es el repositorio central de metadatos de Kudu. Almacena información sobre las tablas y las tablets. Esta tabla no puede ser accedida directamente para lecturas o escrituras, sino que se realiza a traves de una API Rest que tiene ciertas operaciones expuestas.

Kudu utiliza el algoritmo de Raft como medida para garantizar la tolerancia a fallos y la consistencia entre servidores, para tablets regulares y datos del master. A través de Raft, múltiples réplicas de una tablet eligen un líder, que es responsable de aceptar peticiones de escritura y de replicar la información entre sus seguidores. Una vez que la escritura persiste en la mayoría de réplicas se le informa al cliente del éxito de la operación.

Kudu no replica las operaciones en disco, por eso se dice que tiene una replicación lógica, no física. Esto tiene unas ventajas:

  • Aunque las inserciones y actualizaciones transmiten datos a través de la red, las eliminaciones no necesitan mover ningún dato. La operación de eliminación se envía a cada servidor de tablets, que lo elimina localmente.
  • Las operaciones físicas, como la compactación, no necesitan transmitir datos a través de la red en Kudu. Esto es diferente de los sistemas basados en HDFS, donde los bloques necesitan enviarse por la red.
  • Las tablets no tienen porque ser compactadas todas al mismo tiempo, así disminuye la posibilidad de que todos los servidores de tablets tengan una latencia alta, debido a compactaciones o cargas de escrituras pesadas.

3. Arquitectura

El siguiente diagrama muestra un cluster de Kudu con tres masters y varios seguidores, cada uno sirviendo múltiples tablets. La imagen muestra como el consenso de Raft es utilizado para permitir tanto a los líderes como a los seguidores obtener el control de la tablet.

kudu-architecture-2

Img: kudu.apache.org/docs/

4. Modelo de datos

Las tablas en Kudu tiene un modelo de datos estructurado similar a las tablas de los sistemas relacionales. El diseño del esquema es fundamental para lograr un rendimiento óptimo y una estabilidad operacional en Kudu. Cada carga de trabajo es única, y no hay un diseño de esquema único que sea el mejor para cada tabla.

A alto nivel hay tres conceptos que deben preocuparnos a la hora de crear una tabla: diseño columnar, diseño de la clave primaria y el diseño de la partición. De estos tres, solo la partición resulta novedosa para aquellos que hayan tenido práctica con sistemas de bases de datos relacionales no distribuidas.

¿Como sería el esquema perfecto?

  • Los datos se distribuirían de tal manera que las lecturas y escrituras serían distribuidas uniformemente entre los servidores de tablets (Partición)
  • Las tablets crecerían a una velocidad uniforme, predecible y la carga de las tablets se mantendría estable con el tiempo (Partición)
  • Las lecturas completas (scan) leerían la cantidad mínima de datos para completar una consulta. (Primary Key y Partición)

4.1 Diseño columnar

Una tabla consiste en un conjunto de columnas, cada uno con un tipo de dato. Las columnas que no son parte de la clave primaria, puede ser nulas.  Kudu aprovecha las columnas tipadas y un formato de almacenamiento columnar en disco para proporcionar codificación y serialización eficientes.

Especificando el tipo apropiado aprovechamos las características de Kudu, en lugar de  simular un tabla “schemaless” utilizando columnas tipo cadena o binarias para datos que podrían estar estructurados.

Cada columna puede crearse con una codificación basada en el tipo de la columna. Codificación sencilla, de longitud de ejecución, de diccionario o de prefijo.

Kudu permite comprimir las columnas utilizando los codecs LZ4, Snappy y zlib. Por defecto las columnas se almacenan descomprimidas. Hay que considerar la compresión cuando reducir el espacio de almacenamiento sea más importante que el rendimiento de los análisis de datos en bruto.

4.2 Diseño de la clave primaria

Todas las tablas en Kudu deben tener un índice de clave primaria formada por una o más columnas. No pueden ser nulas, y no pueden ser un booleano o un tipo de coma flotante. Se establece durante la creación de la tabla y no puede ser alterada en el futuro. Tienen que ser valores únicos, si se intenta insertar una clave duplicada se devuelve un error al usuario.

Kudu no proporciona la característica de columas auto-incrementales, por lo que la aplicación siempre debe proporcionar una clave primaria a la hora de insertar, también cuando se actualizan o se borran filas. Kudu no soporta operaciones de rango para actualizar o modificar una columna. Una clave primaria no puede ser actualizada, hay que borrarla primero y volver a insertarla después.

Al igual que muchas bases de datos relacionales la clave primaria de Kudu es un índice agrupado. Todas las filas de una tablet se mantienen ordenadas por su clave primaria. Los scans en Kudu que especifican restricciones de igualdad o rango en la clave primaria se saltarán las filas que no satisfacen el predicado.

4.3 Partición

Para proporcionar scalabilidad las tablas en Kudu están particionadas en unidades llamadas tablets y distribuidas entre multitud de servidores. Una fila siempre pertenece a una sola tablet. El método para asignar filas a las tablets está determinado por la partición de la tabla, que se establece durante su creación.

Escoger la estrategia de particionado requiere entender el modelo de datos y la carga esperada sobre las tablas. Para escenarios en los que la escritura sea importante, hay que tener en cuenta a la hora de diseñar la clave primaria que lo mejor es distribuir las escrituras a través de las tablets para evitar la sobrecarga de una en particular. Para trabajos en los que se realicen muchas lecturas, donde las comunicaciones con servidores remotos predomina, el rendimiento se puede mejorar si todos los datos para el análisis se encuentran en la misma tablet.

Kudu no asigna una estrategia de particionado por defecto a la hora de crear una tabla. Se recomienda que las tablas nuevas que se generen tengan un número de particiones o tablets por lo menos igual al número de servidores dedicados.

Existen dos tipos de particionado: partición por rango y partición hash. Las tablas pueden tener particionado multinivel, combinando los dos tipos.

Enlaces

Apache Kudu

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s