Apache Kylin 4.0 usa Spark como motor de compilación y Parquet como almacenamiento, lo que facilita la implementación y el escalado en la nube. Sin embargo, en comparación con HDFS que usa el disco local, el almacenamiento de objetos en la nube puede tener algunos problemas de compatibilidad y rendimiento. Ante tales problemas, hoy te traemos las soluciones optimizadas de JuiceFS. ¡El potente motor de consulta de Kylin 4.0 y la caché local eficiente de JuiceFS pueden lograr una situación de beneficio mutuo en cuanto a compatibilidad y rendimiento! Para obtener más detalles, eche un vistazo a este buen artículo producido conjuntamente por Kylin y Juicedata.
¿Qué es Apache Kylin?
Apache Kylin es un motor de análisis distribuido de código abierto diseñado para datos a gran escala. Proporciona interfaces de consulta SQL y capacidades de análisis en línea multidimensional (OLAP) en Hadoop / Spark. Fue desarrollado originalmente por eBay y contribuido a la Apache Software Foundation. Frente a datos masivos, Kylin también puede lograr una respuesta de consulta inferior a un segundo.
[Diagrama de arquitectura de Apache Kylin]
Como motor de consulta de ultra alto rendimiento, Kylin puede descargar varias fuentes de datos, como Hive y Kafka, y conectar varios sistemas de BI como Tableau y Superset. También proporciona API JDBC / ODBC / REST para la integración de varias aplicaciones. Desde el código abierto, Kylin ha sido ampliamente utilizado, como Meituan, Xiaomi, 58.com, Shell Search, Huawei, Autohome, Ctrip, Tongcheng, Vivo, Yahoo Japan, OLX Group, etc., con visitas diarias que van desde decenas de miles Con un rango de decenas de millones, la mayoría de las consultas se pueden completar en 1-3 segundos.
Si el lado de su producto / negocio lo encuentra y dice que necesita hacer consultas resumidas flexibles en miles de millones o incluso cientos de miles de millones de registros, la respuesta debe ser rápida, la concurrencia debe ser alta y el uso de recursos debe ser bajo; para respaldar el desarrollo de aplicaciones, También es totalmente compatible con la sintaxis SQL y puede integrar BI a la perfección, entonces Apache Kylin es su mejor opción.
La idea central de Kylin es el cálculo previo, que calcula todos los posibles resultados de la consulta (es decir, cubo, cubo multidimensional) en función de dimensiones e indicadores especificados, y utiliza el espacio para el tiempo para acelerar las consultas OLAP con modos de consulta fijos. Cada combinación de dimensiones se llama Cuboide, y la colección de todos los Cuboides es un Cubo. El Cuboide compuesto por todas las dimensiones se denomina Cuboide base, y se pueden agregar otros Cuboides desde Base Cuboide. Al realizar una consulta, Kylin seleccionará automáticamente el Cuboide más adecuado que cumpla las condiciones. En comparación con el cálculo de la tabla original del usuario, tomar datos de Cuboid para el cálculo puede reducir en gran medida la cantidad de datos escaneados y el cálculo.
[Un ejemplo de cubo de cuatro dimensiones]
Kylin eligió HBase como motor de almacenamiento desde el principio de su nacimiento, que básicamente cumple con los requisitos de rendimiento de consultas; sin embargo, hay una serie de puntos débiles basados en la solución HBase, como la complejidad de la operación y el mantenimiento de HBase, el problema de un solo punto de los nodos de consulta y HBase no es una eficiencia de E / S de almacenamiento en columnas pura. mayor. Apache Kylin v4 utiliza la combinación de Parquet + Spark y ya no utiliza HBase, que separa la informática y el almacenamiento. Es una importante actualización de la arquitectura y está más adaptada a la tendencia de la tecnología nativa de la nube.
Kylin sobre los desafíos de Parquet en la nube
En comparación con antes, basados en la nueva generación de Kylin 4, los usuarios pueden implementar rápida y fácilmente servicios de análisis de datos de alto rendimiento y bajo TCO en la nube. La separación de la informática y el almacenamiento, así como la reducción de la complejidad de la arquitectura, hacen de Kylin una de las mejores opciones para el análisis de datos en la nube. Sin embargo, la gran diferencia entre el sistema de archivos abstraído basado en el almacenamiento de objetos en la nube y el HDFS tradicional trae una serie de problemas que requieren atención, como la ubicación de los datos, la restricción en la frecuencia de las llamadas a la API de almacenamiento de objetos y la dificultad en la consistencia de las operaciones de movimiento de datos. Las garantías, etc., traen algunos desafíos de estabilidad y rendimiento a la construcción y consulta de Kylin. En cuanto a cómo paliar e incluso lograr la excelente experiencia de rendimiento del HDFS nativo, podemos ver algunas soluciones exitosas, JuiceFS es una de ellas.
¿Qué es JuiceFS?
JuiceFS es un sistema de archivos distribuido diseñado para un entorno nativo en la nube. Es totalmente compatible con POSIX y HDFS. Es adecuado para big data, capacitación en aprendizaje automático, almacenamiento compartido de Kubernetes y escenarios de administración de archivos de datos masivos. Es compatible con todos los proveedores de servicios de nube pública en el mundo y proporciona servicios totalmente administrados.Los clientes no necesitan invertir en ningún esfuerzo de operación y mantenimiento, e inmediatamente tienen un sistema de archivos elásticamente escalable que puede expandirse a una capacidad de 100 PB.
Como se puede ver en el diagrama de arquitectura a continuación, JuiceFS ya es compatible con varios productos de almacenamiento de objetos en la nube pública, así como con almacenamiento de objetos de código abierto, como Ceph, MinIO, Swift, etc. El cliente FUSE se proporciona en Linux y macOS, y el cliente nativo también se proporciona en el sistema Windows. Ambos pueden montar el sistema de archivos JuiceFS en el sistema y la experiencia es exactamente la misma que la del disco local. Proporcione Java SDK en el entorno Hadoop, la experiencia es la misma que HDFS. El servicio de metadatos de JuiceFS ha implementado servicios completamente administrados en todas las nubes públicas. Los clientes no necesitan mantener ningún servicio por sí mismos y el umbral de aprendizaje y uso es extremadamente bajo.
[Diagrama de arquitectura de JuiceFS]
¿Por qué deben usarse juntos Kylin y JuiceFS?
Si un cliente usa Kylin en una nube pública y quiere almacenar datos en el almacenamiento de objetos, se encontrará con dos problemas:
El primer problema es la compatibilidad. Kylin admite HDFS y Amazon S3 de forma predeterminada, y otras nubes públicas también proporcionan almacenamiento de objetos "compatible con S3". Sin embargo, en pruebas reales, descubrimos que, además de AWS y Azure, otros objetos de la nube pública El almacenamiento es incompatible. Por ejemplo, si ejecutamos Kylin en Alibaba Cloud basado en OSS, ya sea un clúster autoconstruido basado en Alibaba Cloud EMR y CDH, fallará durante la etapa de construcción del Cubo.
El segundo problema es el rendimiento: desde el punto de vista del usuario, cuando HDFS se reemplaza por almacenamiento de objetos en un escenario de big data, se puede sentir la degradación del rendimiento. Hay varias razones para la degradación del rendimiento:
1. Aumento de la sobrecarga de la red: el uso de HDFS para el almacenamiento tiene características de localidad de datos. Después de cambiar al almacenamiento de objetos, toda la transmisión de datos pasará a través de la red, lo que aumentará una cierta cantidad de sobrecarga y provocará una degradación del rendimiento;
2. Degradación del rendimiento de los metadatos: durante el proceso de construcción del cubo, hay muchas operaciones de metadatos de archivos, especialmente Listado y Cambio de nombre. El rendimiento de estas dos operaciones en el almacenamiento de objetos es muy pobre en comparación con HDFS, lo que llevará al consumo de tiempo de todo el trabajo. Aumento, lo que resulta en una degradación del rendimiento;
3. Degradación del rendimiento causada por la amplificación de lectura: cuando los datos de Kylin se cambian al formato de archivo Parquet, a menudo no es necesario leer el archivo Parquet completo al consultar los datos, solo se debe leer el encabezado o pie de página, lo que requiere un buen sistema de almacenamiento para proporcionar La capacidad de lectura aleatoria, que es precisamente la deficiencia del almacenamiento de objetos, provocará amplificación de lectura, aumentará la E / S de toda la tarea de consulta y provocará una degradación del rendimiento.
JuiceFS puede resolver completamente los problemas de compatibilidad y rendimiento en escenarios de big data. Hablemos de cómo hacerlo.
En primer lugar, hablemos de la compatibilidad. El servicio de metadatos de JuiceFS proporciona un SDK de Java. Su función es equivalente a la del SDK de Java de HDFS. Implementa la interfaz de todas las API de interfaz de archivo de HDFS. Se garantiza que el comportamiento será coherente con HDFS, siempre que sea compatible con HDFS. Todos los motores informáticos pueden utilizar JuiceFS sin problemas de compatibilidad. Además, JuiceFS admite todos los servicios de nube pública en todo el mundo, brindando una experiencia consistente, y los usuarios ya no necesitan preocuparse por las diferencias en el almacenamiento de objetos de diferentes proveedores de nube.
A continuación, hablemos del rendimiento y expliquemos cómo JuiceFS resuelve la degradación del rendimiento causada por los tres aspectos anteriores:
1. El clúster de computación que utiliza JuiceFS también es una arquitectura de separación de almacenamiento y computación. También pierde la función de localidad de datos de HDFS, pero JuiceFS proporciona capacidades de almacenamiento en caché de datos en el cliente. Todos los datos leídos de JuiceFS se almacenarán automáticamente en caché en el nodo donde se encuentra el cliente ( En el almacenamiento local de una máquina virtual o contenedor, la próxima vez que acceda a estos datos, se leerán directamente desde el almacenamiento local y ya no pasarán por la red. En escenarios de análisis y consulta de big data, los datos suelen tener puntos calientes. Con la compatibilidad con la caché de JuiceFS, el rendimiento se puede mejorar significativamente (consulte los resultados de las pruebas a continuación). Es posible que también le preocupe la administración, la caducidad y la coherencia de la caché. JuiceFS tiene un conjunto completo de mecanismos de procesamiento, lo cual es digno de un artículo separado, y este artículo no se expandirá.
2. Rendimiento de metadatos. JuiceFS tiene su propio servicio de metadatos independiente. Los metadatos de JuiceFS responden a las operaciones de listado y cambio de nombre. El rendimiento es decenas de veces más rápido que el almacenamiento de objetos y también se mejora en más del 50% en comparación con HDFS. Consulte JuiceFS para obtener más detalles. Casos de prueba.
3. La caché JuiceFS puede reducir eficazmente el retraso de las lecturas aleatorias y reducir la amplificación de la lectura.Tiene ventajas obvias de rendimiento en escenarios de análisis de consultas basados en formatos de datos Parquet y ORC.
En resumen, JuiceFS puede obtener un rendimiento equivalente a HDFS, al tiempo que proporciona un soporte de compatibilidad perfecto para los productos ecológicos de Hadoop. Más importante aún, no importa qué nube pública use el cliente, pueden usar JuiceFS para obtener una experiencia consistente.
Comparación de rendimiento
Lo anterior explicó los beneficios de usar Kylin en Parquet y JuiceFS juntos, echemos un vistazo a los resultados de la prueba de rendimiento.
Como se mencionó anteriormente, existen problemas de compatibilidad en la construcción de Cube basada en OSS, y Cube no se puede construir correctamente. Pero es posible copiar los datos de Cube creados en JuiceFS a OSS para ejecutar Query, por lo que probamos Query1 a Query22 según el conjunto de datos TPC-H de 10GB. JuiceFS es más rápido que OSS en tiempo de ejecución total Eso es 38%.
• JuiceFS usa 70,423 ms
• OSS usa 113,670 ms
La siguiente tabla muestra la configuración detallada del entorno de prueba y el tiempo de ejecución de todas las consultas de prueba:
Configuración de la máquina
Utilice CDH 5.16 para crear un clúster en Alibaba Cloud. La configuración detallada y la versión del software son las siguientes:
Todo el tiempo de ejecución de la consulta de prueba
para resumir
Kylin 4.0 presenta una arquitectura separada para la computación y el almacenamiento, lo que facilita la implementación y el escalado de Kylin en la nube. Sin embargo, en comparación con HDFS que usa discos locales, el almacenamiento de objetos en la nube tiene problemas con el desarrollo y la compatibilidad del acoplamiento. Por otro lado, el rendimiento disminuirá. Al usar JuiceFS con Kylin, puede usar servicios de almacenamiento en la nube para cálculos de big data en EMR o clústeres de Hadoop autoconstruidos sin una adaptación especial en todas las nubes públicas. JuiceFS permite que su clúster logre una arquitectura de separación de almacenamiento y computación, al tiempo que reduce el costo de cada E / S de red a través de un almacenamiento en caché local eficiente. En el escenario de análisis de consultas basado en el formato Parquet, puede reducir efectivamente el retraso para lecturas aleatorias y reducir la amplificación de lectura , Para obtener un rendimiento cercano a HDFS. En nuestro escenario de prueba, el uso de JuiceFS mejora el rendimiento en un 38% en comparación con el uso directo del almacenamiento de objetos.
Si planea usar Kylin en la nube pública para completar los requisitos de análisis de datos y usa JuiceFS para el almacenamiento con almacenamiento de objetos, puede lograr una situación de beneficio mutuo en cuanto a compatibilidad y rendimiento.