Empecemos por el punto de vista: porque no he encontrado uno mejor.
A continuación, hablemos de las razones: Primero, echemos un vistazo a lo que están haciendo las plataformas de big data.
razón
La computación de datos estructurados sigue siendo una prioridad
La plataforma de big data es principalmente para satisfacer las necesidades de almacenamiento y análisis masivo de datos. El almacenamiento masivo de datos es realmente cierto. Además de los datos estructurados generados por la producción y la operación, también hay una gran cantidad de datos no estructurados, como audio y video. Esta parte de los datos es muy grande y ocupa una gran cantidad de datos, también hay mucho espacio, y en ocasiones más del 80% de las plataformas de big data almacenan datos no estructurados. Sin embargo, el almacenamiento de datos no es suficiente, y solo cuando se utiliza puede generar valor, lo que requiere análisis.
El análisis de big data debe discutirse en dos partes: datos estructurados y no estructurados.
Los datos estructurados son principalmente datos comerciales generados en el proceso de producción y operación de una empresa, que se puede decir que es el núcleo de la empresa. En el pasado, cuando no había una plataforma de big data, la empresa utilizaba principal o completamente esta parte de los datos. Con la acumulación continua de negocios, esta parte de los datos es cada vez más grande, y las soluciones de bases de datos tradicionales enfrentan grandes desafíos.La construcción de una plataforma de big data naturalmente necesita resolver esta parte del problema central del análisis de datos.
Con la plataforma de big data, también hay más espacio para la imaginación de todos. Los datos no estructurados como registros, imágenes, audio y video que no se podían usar en el pasado también generarán valor, lo que implica el análisis de datos no estructurados. En relación con el análisis de datos comerciales centrales, el análisis de datos no estructurados se parece más a la guinda del pastel. Aun así, el análisis de datos no estructurados no existe de forma aislada, y además vendrá acompañado de una gran cantidad de procesamiento de datos estructurados. Cuando se recopilan datos no estructurados, a menudo se acompaña de la recopilación de una gran cantidad de datos estructurados relacionados, como el productor de audio y video, el tiempo de producción, la categoría, la duración, ...; algunos datos no estructurados también se transformarán en estructura después del procesamiento. Datos, como el desmantelamiento de la IP del visitante, tiempo de acceso, términos clave de búsqueda, etc. del registro web. El llamado análisis de datos no estructurados a menudo está dirigido a estos datos estructurados que lo acompañan.
El análisis de datos estructurados sigue siendo una prioridad para las plataformas de big data. La tecnología de procesamiento de datos estructurados es relativamente madura, como nuestra base de datos relacional (SQL) de uso común basada en el modelo de datos relacionales.
SQL sigue siendo la tecnología informática de datos estructurados más utilizada
Regresar a SQL es una tendencia de desarrollo de la sintaxis actual de computación de big data. En el sistema Hadoop, se eliminó el primer PIG Latin, pero Hive siempre ha sido fuerte; Spark SQL también se usa más en Spark, mientras que Scala se usa mucho menos (Scala es fácil de aprender y difícil de dominar, y como lenguaje compilado no es compatible con la implementación en caliente, también hay muchos inconvenientes). Algunos otros nuevos sistemas informáticos de big data generalmente usan SQL como la sintaxis informática preferida. Después de varios años de lucha cuerpo a cuerpo, SQL ha recuperado gradualmente la iniciativa.
Probablemente hay dos razones para este fenómeno:
1. Realmente no hay nada más útil
Las bases de datos relacionales son demasiado populares, los programadores están bastante familiarizados con SQL e incluso sus hábitos de pensamiento son similares a los de SQL. También es relativamente simple usar SQL para hacer algunas consultas generales. Aunque no es conveniente manejar cálculos de procedimientos complejos u operaciones ordenadas, otras tecnologías alternativas no son mucho mejores. Cuando se trata de operaciones que son difíciles de escribir en SQL, es es necesario escribir lo mismo que UDF.Código bastante complejo, es problemático de todos modos, es mejor seguir usando SQL.
2. Fuerte apoyo de los proveedores de big data
La esencia técnica de los grandes datos es el alto rendimiento, y SQL es la posición clave para la competencia por el rendimiento. Solo tiene sentido enfrentar la misma operación que el rendimiento. Las operaciones demasiado especializadas y complejas involucran demasiados factores que influyen, y no es fácil evaluar las capacidades de la plataforma de big data en sí. Y SQL tiene una serie TPC estándar internacional, que todos los usuarios pueden entender, por lo que existe una clara comparabilidad, y los fabricantes también se centrarán en la optimización del rendimiento en SQL.
Compatible con SQL es más propicio para la portabilidad
Los beneficios de que una plataforma de big data sea compatible con SQL son obvios. SQL se usa ampliamente y muchos programadores conocen SQL. Si continúa usando SQL, puede evitar muchos costos de aprendizaje. También hay muchos software front-end que admiten SQL, y las plataformas de big data que usan SQL se pueden integrar fácilmente en este ecosistema ya hecho. La base de datos tradicional que la plataforma de big data pretende reemplazar también usa sintaxis SQL, por lo que la compatibilidad será muy buena y el costo del trasplante será relativamente bajo.
Bueno, hemos terminado por qué la plataforma de big data volverá al modelo de datos relacionales. Entonces, ¿cuáles son los problemas de continuar usando el modelo de datos relacionales (SQL)?
pregunta
bajo rendimiento
El mayor problema de seguir usando SQL es que es difícil obtener el alto rendimiento que más necesita la computación de big data.
La falta de algunos tipos de datos necesarios y definiciones de operaciones en SQL hace que sea imposible describir algunos algoritmos de alto rendimiento y solo puede esperar la optimización del motor de cálculo en ingeniería. Después de décadas de desarrollo de bases de datos comerciales tradicionales, la experiencia de optimización ha sido bastante rica, pero aun así, todavía hay muchos escenarios que son difíciles de optimizar, y los problemas a nivel teórico son difíciles de resolver a nivel de ingeniería . Sin embargo, la experiencia en la optimización de las plataformas de big data emergentes es mucho menor que la de las bases de datos tradicionales.Si el algoritmo no es dominante, solo puede confiar en agrupar más máquinas para mejorar el rendimiento. Además, la capacidad de SQL para describir el proceso no es muy buena y no es bueno para especificar rutas de ejecución Para lograr un alto rendimiento, a menudo se requiere una ruta de ejecución especialmente optimizada, lo que requiere agregar muchos modificadores especiales para la intervención humana. Es mejor usar procedimental directamente.La sintaxis es más sencilla, lo que también evita escribir código de alto rendimiento en SQL.
Al comienzo de la invención de SQL, las capacidades del hardware de la computadora eran relativamente pobres. Para garantizar la practicidad, el diseño de SQL debe adaptarse a las condiciones del hardware en ese momento, lo que dificultó que SQL utilizara completamente las capacidades del hardware de los contemporáneos. computadoras, específicamente memoria grande, paralelismo y clusters. JOIN en SQL corresponde al valor clave, pero en el caso de una memoria grande, puede corresponder directamente a la dirección, sin necesidad de calcular el valor HASH y la comparación, el rendimiento se puede mejorar mucho; la tabla de datos SQL está fuera de servicio, y es fácil hacer un cálculo de tabla única Cuando se trata de paralelismo segmentado, en operaciones de asociación de tablas múltiples, generalmente solo se pueden hacer segmentos fijos por adelantado, y es difícil lograr una segmentación dinámica síncrona. En teoría, no hay distinción entre tablas de dimensiones y tablas de hechos. La operación JOIN se define simplemente como un postfiltrado de productos cartesianos. Para implementar una tabla grande JOIN, inevitablemente ocurrirá una acción HASH Shuffle que consume una gran cantidad de recursos de la red. Cuando la cantidad de nodos del clúster es demasiado grande, la red El retraso causado por la transmisión superará los beneficios de tener más nodos.
Para dar un ejemplo específico, queremos sacar los 10 datos principales en 100 millones de datos, que están escritos en SQL de esta manera:
select top 10 x,y from T order by x desc
Hay un orden por en esta declaración. Ejecutarlo estrictamente implicará una gran clasificación, y la clasificación es muy lenta. De hecho, podemos crear un algoritmo que no requiera una ordenación grande, pero no se puede describir en SQL y solo podemos confiar en el optimizador de la base de datos. Para el caso simple descrito por este SQL, muchas bases de datos comerciales pueden optimizarse, y el rendimiento suele ser muy bueno utilizando algoritmos que no requieren una gran clasificación. Pero la situación es un poco más complicada, por ejemplo, para tomar el top 10 en cada grupo, use funciones de ventana y subconsultas para escribir SQL como este:
select * from
(select y,*,row_number() over (partition by y order by x desc) rn from T)
where rn<=10
En este momento, el optimizador de la base de datos estará mareado, incapaz de adivinar el propósito de esta declaración SQL y solo puede ejecutar honestamente la lógica de clasificación (todavía existe el orden de las palabras en esta declaración), lo que resulta en una fuerte caída en el rendimiento.
baja eficiencia de desarrollo
No solo se ejecuta lentamente, sino que la eficiencia de desarrollo no es alta, especialmente en términos de cálculos complejos, la implementación de SQL es muy engorrosa. Por ejemplo, para consultar los días de aumento continuo más largos de una acción en función de los registros de acciones, el SQL (oráculo) se escribe de la siguiente manera:
select code, max(ContinuousDays) - 1
from (
select code, NoRisingDays, count(*) ContinuousDays
from (
select code,
sum(RisingFlag) over (partition by code order by day) NoRisingDays
from (
select code, day,
case when price>lag(price) over (partittion by code order by day)
then 0 else 1 end RisingFlag
from stock ) )
group by NoRisingDays )
group by code
Se implementa de una manera muy enrevesada, sin mencionar escribirlo, lleva medio día entenderlo.
Además, SQL es difícil de implementar cálculos de procedimiento. ¿Qué es la computación procedimental? Es decir, no se puede escribir en un solo paso y se requieren múltiples operaciones paso a paso, especialmente las relacionadas con el orden de los datos.
Tomemos algunos ejemplos:
Proporción de usuarios que han iniciado sesión durante más de una hora en una semana, excluyendo operaciones erróneas con una duración de inicio de sesión de menos de 10 segundos
La distribución de los días de mayor consumo consecutivo de tarjetas de crédito en los últimos tres meses, considerando la implementación de la promoción de puntos triples después de 10 días consecutivos
¿Cuántos usuarios en un mes realizan continuamente la acción de agregar al carrito de compras y comprar después de ver el producto durante 24 horas y cuántos usuarios se dan por vencidos en el paso intermedio?
...
(Para facilitar la comprensión, estos ejemplos se han simplificado y la operación real es mucho más complicada)
Este tipo de operación de procedimiento es muy difícil de escribir en SQL y, a menudo, es necesario escribir UDF para completarla. Si no puede escribir SQL, el efecto de SQL se reducirá considerablemente.
La baja eficiencia de desarrollo conduce a un bajo rendimiento
La eficiencia de ejecución de SQL complejo suele ser muy baja, lo que vuelve al problema del rendimiento. De hecho, la eficiencia del desarrollo y el rendimiento informático están estrechamente relacionados, y muchos problemas de rendimiento son causados esencialmente por la eficiencia del desarrollo.
El efecto de optimización del SQL complejo es muy pobre Después de algunas capas de anidamiento, el motor de la base de datos se desvanecerá y no sé cómo optimizarlo. Para mejorar el rendimiento de operaciones tan complejas, no es fiable esperar la optimización automática de la plataforma informática, y el medio fundamental es escribir algoritmos de alto rendimiento. Por ejemplo, en las operaciones de procedimiento, a menudo es necesario guardar los resultados intermedios para su reutilización. SQL necesita usar tablas temporales, y más operaciones de IO afectarán el rendimiento. Estas no son cosas que la optimización del motor pueda resolver, y el proceso de cálculo debe reescribirse. .
Por lo tanto, en esencia, mejorar el rendimiento o reducir la dificultad de desarrollo. El software no puede mejorar el rendimiento del hardware. Solo puede encontrar formas de diseñar algoritmos con menor complejidad. Si estos algoritmos se pueden implementar de forma rápida y económica, se puede lograr el objetivo de mejorar el rendimiento. Si el sistema de sintaxis es difícil o incluso imposible de describir algoritmos de alto rendimiento, y los programadores deben verse obligados a adoptar algoritmos de mayor complejidad, será difícil mejorar el rendimiento. La optimización de las operaciones de SQL no ayudará a reducir la dificultad de su desarrollo. El sistema de sintaxis de SQL es así. No importa cómo optimizar su rendimiento, la dificultad de desarrollo no cambiará. Muchos algoritmos de alto rendimiento aún no se pueden implementar, y es difícil mejorar sustancialmente el rendimiento informático.
De hecho, escribir UDF puede mejorar el rendimiento en muchos escenarios, pero por un lado, es muy difícil de desarrollar y, por otro lado, los programadores lo escriben con dificultad y no pueden aprovechar las capacidades de optimización del motor SQL. . Además, a menudo no es posible escribir la operación completa como UDF, solo se puede usar la interfaz proporcionada por la plataforma informática y su tipo de datos aún debe usarse en el marco SQL, lo que limitará la implementación de algoritmos de alto rendimiento. .
La solución fundamental es permitir que la plataforma de big data realmente tenga una sintaxis mejor.
solución
El uso de la fuente abierta esProc SPL se puede usar como un buen reemplazo y extensión de SQL.Como un lenguaje informático especial para plataformas de big data, puede continuar con las ventajas de SQL y mejorar sus desventajas.
SPL es un motor informático de datos de código abierto profesional que proporciona una sintaxis informática independiente. Todo el sistema no depende de modelos de datos relacionales, por lo que ha logrado grandes avances en muchos aspectos, especialmente en términos de eficiencia de desarrollo y rendimiento informático. Echemos un vistazo a qué características de SPL son adecuadas para las plataformas de big data contemporáneas.
Fuerte integración
El primero es la integración, no importa cuán bueno sea SPL, será en vano si no se puede usar junto con la plataforma de big data. De hecho, es muy conveniente usar SPL en la plataforma de big data, se puede usar introduciendo un paquete jar (también es de código abierto, puedes usarlo como quieras). SPL proporciona un controlador JDBC estándar, que puede ejecutar directamente secuencias de comandos SPL o llamar a archivos de secuencias de comandos SPL.
…
Class.forName("com.esproc.jdbc.InternalDriver");
Connection conn =DriverManager.getConnection("jdbc:esproc:local://");
//PreparedStatement st = (PreparedStatement)conn.createStatement();;
//直接执行SPL脚本
//ResultSet rs = st.executeQuery("=100.new(~:baseNum,~*~:square2)");
//调用SPL脚本文件
CallableStatement st = conn.prepareCall("{call SplScript(?, ?)}");
st.setObject(1, 3000);
st.setObject(2, 5000);
ResultSet result=st.execute();
...
Desarrollo eficiente
Gramática ágil
En términos de computación de datos estructurados, SPL proporciona una sintaxis de computación independiente y una rica biblioteca de clases de computación, y admite la computación de procesos para hacer que la implementación de la computación compleja sea muy simple. El ejemplo anterior de cálculo de la racha más larga de días para una acción se implementa utilizando SPL de la siguiente manera:
| A | |
|---|---|
| 1 | = db.query ("seleccione * de la orden de existencias por día") |
| 2 | =A1.grupo@i(precio<precio[-1]).max(~.len())-1 |
Organícelos de acuerdo con el día de negociación, agrupe los registros ascendentes consecutivos en un grupo y luego encuentre el valor máximo de -1, que es el día ascendente continuo más largo.
Otro ejemplo es enumerar el último intervalo de inicio de sesión de cada usuario según el registro de inicio de sesión del usuario:
| A | ||
|---|---|---|
| 1 | =ulogin.groups(uid;top(2,-logtime)) | Últimos 2 registros de inicio de sesión |
| 2 | =A1.nuevo(uid,#2(1).tiempo de registro-#2(2).tiempo de registro:intervalo) | intervalo de cálculo |
Es conveniente admitir la sintaxis SPL paso a paso para completar los cálculos de procedimiento.
SPL proporciona una rica biblioteca de clase informática, que puede simplificar aún más la operación.
Entorno de desarrollo intuitivo y fácil de usar
Al mismo tiempo, SPL también proporciona un entorno de desarrollo conciso y fácil de usar, ejecución de un solo paso, configuración de puntos de interrupción y una ventana de vista previa de resultados WYSIWYG... y la eficiencia del desarrollo también es mayor.
Compatibilidad con múltiples fuentes de datos
SPL también brinda soporte para diversas fuentes de datos, y se pueden usar múltiples fuentes de datos directamente.En comparación con las plataformas de big data, que requieren que los datos se "almacenen" antes de calcularlos, el sistema de SPL es más abierto.
Algunas fuentes de datos compatibles con SPL (todavía en expansión...)
No solo eso, SPL también es compatible con la computación mixta de múltiples fuentes de datos, aprovechando al máximo las ventajas de varias fuentes de datos y expandiendo la apertura de la plataforma de big data. Al mismo tiempo, es más sencillo usar directamente múltiples fuentes de datos para el desarrollo y la implementación, lo que mejora aún más la eficiencia del desarrollo.
intercambio en caliente
SPL se interpreta y ejecuta y, naturalmente, admite la conmutación en caliente, lo que es un gran beneficio para la plataforma de big data bajo el sistema Java. La escritura, la modificación, la operación y el mantenimiento de la lógica informática de big data basada en SPL no necesitan reiniciarse y surten efecto en tiempo real, lo que hace que el desarrollo, la operación y el mantenimiento sean más convenientes.
Alto rendimiento informático
Como dijimos anteriormente, alto rendimiento y alta eficiencia de desarrollo son esencialmente lo mismo, y es más fácil escribir algoritmos de alto rendimiento basados en la sintaxis concisa de SPL. Al mismo tiempo, SPL también proporciona muchos mecanismos de algoritmos y almacenamiento de datos de alto rendimiento. Los algoritmos de alto rendimiento y las soluciones de almacenamiento que son difíciles de implementar en SQL se pueden implementar fácilmente con SPL. La clave para mejorar el rendimiento del software radica en algoritmos y almacenamiento.
Por ejemplo, la operación TopN mencionada anteriormente, en SPL, TopN se entiende como una operación de agregación, que puede convertir una clasificación de alta complejidad en una operación de agregación de baja complejidad, y también puede ampliar el ámbito de aplicación.
| A | ||
|---|---|---|
| 1 | =archivo(“datos.ctx”).crear().cursor() | |
| 2 | =A1.grupos(;arriba(10,cantidad)) | 10 pedidos principales |
| 3 | =A1.groups(área;arriba(10,cantidad)) | Los 10 pedidos principales por región |
No hay una palabra de ordenación en la instrucción aquí, y no se producirá una gran acción de ordenación.La sintaxis para calcular TopN en el conjunto completo o agrupación es básicamente la misma, y ambos tendrán un mayor rendimiento.
Estos son algunos casos de computación de alto rendimiento implementados con SPL:
SPL de código abierto mejora el análisis de autoservicio bancario de 5 a 100 simultáneos
SPL de código abierto acelera los informes de posición de capital bancario en más de 20 veces
SPL de código abierto acelera los acuerdos de préstamos bancarios más de 10 veces
SPL de código abierto optimiza las carreras de la compañía de seguros de 2 horas a 17 minutos
SPL de código abierto acelera los informes de transacciones de POS bancarios en más de 30 veces
SPL de código abierto acelera las tareas de aprobación de préstamos bancarios más de 150 veces
SPL de código abierto acelera el balance 60 veces
Unas pocas palabras más, SPL no se basa en un modelo de datos relacionales, sino que adopta un sistema teórico innovador, que es innovador a nivel teórico. El motivo del espacio no se mencionará demasiado aquí. Está escrito de manera simple y se ejecuta rápidamente . El lenguaje de base de datos SPL tiene una introducción más detallada aquí, y los socios interesados también pueden buscar y descargar por sí mismos.