Prueba de rendimiento de comparación de recuperación y clasificación basada en Spark SQL

He realizado investigación y desarrollo de Spark durante un año antes, y también he realizado Hive durante mucho tiempo en Alibaba y Tencent, por lo que entiendo bien este aspecto.

Primero: de hecho, además de la implementación técnica de Spark y Hive, la velocidad está estrechamente relacionada con el rendimiento de la máquina y la optimización de los parámetros del sistema operativo subyacente, y no se puede generalizar.

Segundo: Hive debería seguir siendo la corriente principal en la industria. Después de todo, la velocidad y la lentitud no son cruciales para un sistema de producción. Después de todo, lo más importante es la chispa. El negocio relativamente nuevo es realmente rápido, pero está lejos de ser una colmena en términos de estabilidad. Con respecto a Spark, también hemos solucionado muchos errores relacionados con pérdidas de memoria. Dado que preguntas sobre el rendimiento, no los presentaremos en detalle (puedes solicitarme la Guía de programación de YDB, que contiene mis correcciones a estos errores). /p>

Tres: con respecto al rendimiento, es posible que mi prueba no sea lo suficientemente completa. Solo puedo proporcionar mi informe anterior de prueba de clasificación BLOCK basado en YDB sobre clasificación y filtrado de recuperación para su referencia (es demasiado laborioso publicarlo en Baidu). , puedes pedirme el documento de word).

Se puede decir que la clasificación es un indicador estricto de muchos sistemas de registro (como la clasificación en orden cronológico inverso). Si un sistema de big data no se puede ordenar, básicamente significa que el sistema no está disponible y la clasificación. Puede considerarse como un sistema de big data una "necesidad rígida", no importa si big data usa Hadoop, Spark, Impala o Hive, la clasificación es indispensable y las pruebas de rendimiento de la clasificación también son indispensables.

La clasificación global Sort Benchmark, conocida como las Olimpíadas de la Computación, se celebra cada año. Cada año, los gigantes invierten mucho en la clasificación. ¡Esto demuestra lo importante que es la velocidad de clasificación! Sin embargo, para la mayoría de las empresas, la inversión en hardware de cientos de millones simplemente no vale la pena e incluso excede con creces el presupuesto del proyecto de la empresa. ¿Existe una forma más económica de implementarlo que la clasificación violenta en el campo del big data?

Aquí te presentamos un nuevo método de clasificación económico, al que llamamos blockSort.

Con datos de 500G y 30 mil millones de datos, solo se pueden usar 4 máquinas virtuales con 16 núcleos, memoria de 32G y tarjetas de red Gigabit para lograr la clasificación en 2 a 15 segundos (se puede ordenar toda la tabla , o se puede ordenar con cualquier Orden después de las condiciones de filtrado).

1. La idea básica es la siguiente, como se muestra en la siguiente figura:

1 Divida previamente los datos según el tamaño, como dividirlos en tres bloques: grande. , mediano y pequeño).

2. Si desea encontrar los datos más grandes, solo necesita encontrarlos en el bloque más grande.

3. Este bloque todavía tiene una estructura jerárquica. Si hay muchos datos en cada bloque, puede continuar buscando en los subbloques a continuación y ordenarlos en varias capas.

4. Con este método, para datos de un billón de niveles (como el tipo largo), en el peor de los casos extremos, solo se pueden realizar 2048 búsquedas de archivos para filtrar los resultados.

¿Qué te parece? El principio es muy simple, incluso si la cantidad de datos es muy grande, el número de clasificación y búsqueda es fijo.

2. Esta es la prueba de rendimiento que hicimos antes basada en Spark, para su referencia.

En términos de clasificación, YDB tiene una ventaja absoluta, ya sea para toda la tabla o para el filtrado. basado en cualquier combinación de condiciones, básicamente elimina cualquier formato Spark.

Resultados de la prueba (la unidad de tiempo es segundos)

3. Por supuesto, además de ordenar, nuestro otro rendimiento también es mucho mayor que el de Spark, también puedes aprender sobre esto

1. Prueba de comparación de rendimiento con Spark txt en recuperación.

Nota: Nota.

No hay nada especial en el área en la imagen a continuación, es solo que debido a las características del propio índice de YDB, no es tan violento como Spark, lo que hace que el rendimiento del escaneo sea mucho mayor que el de Spark. No es de extrañar que el rendimiento sea cientos de veces mayor.

La siguiente imagen muestra las múltiples mejoras de ydb en comparación con spark txt

2. Estos se comparan con el formato Parquet (la unidad es segundos)

3. con comparación de rendimiento de ORACLE

La comparación con las bases de datos tradicionales no tiene sentido. Cualquier herramienta de big data supera con creces el rendimiento de Oracle.

4. Auditar la prueba de rendimiento del escenario de implementación

4. ¿Cómo acelera YDB la chispa?

Basado en el motor de análisis, estadísticas y consultas interactivo, multidimensional y en tiempo real bajo la arquitectura distribuida de Hadoop, tiene un rendimiento de segundo nivel bajo billones de escala de datos y tiene estabilidad a nivel empresarial. y rendimiento confiable.

YDB es un índice detallado, un índice detallado. Los datos se importan instantáneamente, los índices se generan instantáneamente y los datos relevantes se pueden ubicar de manera eficiente a través de índices. YDB está profundamente integrado con Spark. Spark analiza y calcula directamente el conjunto de resultados de búsqueda de YDB. En el mismo escenario, el rendimiento de Spark se puede acelerar cien veces.

5. ¿Qué usuarios son adecuados para utilizar YDB?

1. Los datos relacionales tradicionales ya no pueden acomodar más datos y la eficiencia de las consultas se ve seriamente afectada por los usuarios.

2. Actualmente, estoy usando SOLR y ES para la búsqueda de texto completo. Siento que las funciones de análisis proporcionadas por solr y ES son muy pocas para completar una lógica empresarial compleja, o que SOLR y ES se vuelven inestables. a medida que aumenta la cantidad de datos, en un círculo vicioso de fragmentación y equilibrio, los servicios no se pueden restaurar automáticamente y el personal de operación y mantenimiento a menudo necesita levantarse en medio de la noche para reiniciar el clúster.

3. Usuarios que se basan en el análisis de datos masivos, pero sufren la velocidad y el tiempo de respuesta de la plataforma informática fuera de línea existente que no puede cumplir con los requisitos comerciales.

4. Usuarios que necesitan realizar un análisis direccional multidimensional de los datos de comportamiento del retrato del usuario.

5. Usuarios que necesitan recuperar una gran cantidad de datos UGC (Contenido generado por el usuario).

6. Cuando necesita realizar consultas rápidas e interactivas en grandes conjuntos de datos.

7. Cuando necesite realizar análisis de datos, no solo un simple almacenamiento de valores-clave.

8. Cuando quieras analizar datos generados en tiempo real.

ps:? Después de hablar mucho, para decirlo sin rodeos, el método más adecuado es el análisis de seguimiento porque la cantidad de datos es grande, los datos deben ser en tiempo real y la consulta debe ser rápido. Ésta es la clave.