El 18 de julio se celebró en el Centro Nacional de Convenciones de Beijing el "Foro de Desarrollo Ecológico de Usuarios de la Nube y la Tercera Conferencia de Usuarios de Computación en la Nube de China". En la reunión de la tarde, el ingeniero de sistemas de QingCloud y líder de la plataforma de big data, Li Wei, pronunció un maravilloso discurso sobre el tema "Mejores prácticas de la plataforma de big data en la nube". La siguiente es la transcripción de su discurso:
Li. Wei: Hola a todos, soy Li Wei, ingeniero de sistemas de QingCloud. El tema del que hablo hoy puede ser un poco técnico y puede requerir una lluvia de ideas. Romper en trozos. Primero, hablemos de la relación entre la computación en la nube y el big data. En segundo lugar, ¿cuáles son los desafíos únicos de construir una plataforma de big data en la nube? En tercer lugar, hablaremos de la plataforma de big data que tiene una arquitectura de sistema relativamente básica o general. Finalmente, compartamos algunas de las nuestras, incluidas algunas de las mejores prácticas de nuestros clientes relacionadas con big data.
No entraré en muchos ejemplos de big data, pero hablaré de algunos de nuestros clientes corporativos. Por ejemplo, la primera es una empresa social multinacional de Internet muy grande. Luego utilizarán algunas de nuestras plataformas de big data en la nube, incluidas algunas tecnologías específicas, para crear retratos de usuarios, por ejemplo. Por eso estás en una red social, por eso los amigos que te recomendaron resultan ser personas que quizás conozcas, y por eso la información que te recomendaron puede ser de tu interés. Todo esto se hace utilizando big data para retratos de usuarios.
En segundo lugar, al igual que una gran empresa financiera de Internet, utilizará big data para realizar algunos análisis de control de riesgos. Porque en las finanzas de Internet, especialmente en la industria de las finanzas de Internet, la razón por la que puede competir con las finanzas tradicionales es porque puede utilizar tecnología de big data para controlar los riesgos a un nivel muy pequeño en términos de control de riesgos. Puedes pensarlo, en la plataforma P2P, ¿por qué no vienen varias personas a investigarte como en el pasado en los bancos tradicionales? No hay depósito, pero puedes usar el dinero. Incluyendo la recuperación masiva de información de los departamentos gubernamentales. Por ejemplo, es necesario unir varios departamentos en todo el país. Entonces necesito tener un sospechoso criminal. ¿Es posible que tenga otros datos en varios lugares? luego realizar algunos análisis.
El big data es muy popular. ¿Qué tiene que ver con la computación en la nube? De hecho, creemos que el big data es algo que todo el mundo puede escuchar en todas partes. De hecho, es muy probable que todo el mundo lo diga. de manera diferente, y depende de la persona. Estamos hablando de una plataforma de big data, algunas personas hablan de un determinado producto de big data y otras pueden estar hablando de una determinada aplicación de big data, como Alpha Go.
Especialmente en las empresas, cuando hablamos con los clientes, lo primero que no entienden es que hay demasiados productos y tecnologías de big data, y que las diferencias en cada escenario no son tan obvias. Por lo tanto, en la tecnología de big data, lo primero que tenemos que resolver es cómo elegir soluciones de big data y cómo proporcionar soluciones de big data para empresas. Sin embargo, las necesidades de cada empresa cambian mucho. Puede haber muchas empresas, es decir, empresas tradicionales cuyas necesidades de big data no son muy claras, mientras que las necesidades de las empresas de Internet cambian muy rápidamente. Según los métodos tradicionales, construir una plataforma de big data puede costar mucho tiempo, mano de obra y dinero. Pero para las plataformas en la nube, todo el mundo conoce IaaS, PaaS y SaaS. Al final, todo se convierte en un servidor. Cuando desea construir una solución muy compleja, el costo es bajo porque solo necesita seguir el método de construcción del servicio y es muy flexible. Si encuentra que hay un problema con una determinada parte de la solución, puede hacerlo. reemplácelo rápidamente, porque muchos Todos son servicios en la plataforma. Por lo tanto, puede satisfacer sus necesidades de incertidumbre empresarial, incluidas las necesidades de flexibilidad empresarial. Porque todo el mundo sabe que las cosas están cambiando demasiado rápido ahora.
En segundo lugar, ¿cuáles son los beneficios que la computación en la nube aporta a los big data? Por ejemplo, puede automatizar la operación y el mantenimiento. No es necesario que usted mismo realice la instalación, implementación y monitoreo de algunos sistemas complejos. . La interfaz es muy rápida. Eso es todo, es muy fácil de hacer. Luego hay otras cosas que incluyen la estabilidad y el rendimiento. No entraré en detalles sobre esto. Todos deben saber mucho sobre los beneficios de la computación en la nube.
Por ejemplo, cambiar entre red y almacenamiento, motor informático, esto es más interesante. Es decir, cuando su plataforma es lo suficientemente compleja y grande, cada parte es un servidor. Después de que cada parte se convierte en un servidor, puede reemplazarla de manera muy flexible, reemplazarla con otras implementaciones de productos u otras implementaciones técnicas. Este último es la orquestación de servicios. Por ejemplo, si tiene una interfaz y necesita dibujar varios diagramas o herramientas, tienen un defecto muy fatal. El diagrama que dibuja no se puede ejecutar, es decir, no se puede implementar ni ejecutar. Service Orchestration le ofrece un gran mapa de topología. Este también es un producto lanzado por Qingyun a principios de este año, llamado orquestación de recursos. Se puede implementar un conjunto completo de arquitecturas en la plataforma en la nube. Estos son algunos de los beneficios que aportan a la nube.
Retos de las plataformas de big data en la nube. Muchas empresas construyen plataformas de big data en máquinas físicas, ¿por qué no en la nube? Porque existen muchos desafíos. Primero, los desafíos de estabilidad, como la alta disponibilidad y la recuperación ante desastres. En segundo lugar, el rendimiento. Siempre ha sido criticado porque eres una máquina virtual y definitivamente no es tan rápida como el disco duro de la máquina de red. La estabilidad de la primera capa IaaS de Qingyun ha estado funcionando durante varios años y no hay mucho que decir al respecto. En términos de rendimiento, el año pasado trabajamos en la red definida por software 2.0. Después de que salió 2.0, este era un conjunto de SDN especialmente desarrollado para computación en la nube y grandes plataformas IaaS. Puede lograr una transmisión de red punto a punto. Tarjeta de red física. En segundo lugar, los discos duros siempre han estado plagados de problemas. Nuestra tecnología de contenedores puede reducir la tecnología del disco duro a un nivel muy bajo. El tercer beneficio es la migración. La tecnología de migración es muy buena porque ya existen algunas relativamente establecidas, como bases de datos relacionales y no relacionales.
Dijimos que después de resolver estos desafíos, tendremos una arquitectura de sistema de plataforma de big data. Esta arquitectura es en realidad una arquitectura muy general. Es decir, lo que puedes ver en muchas empresas, ya sea JD.com, Meituan o Amazon, es básicamente así. De hecho, comenzando desde la izquierda, en realidad es un ciclo de vida de datos, que es desde donde se recopilan los datos. Pueden ser registros o sensores. Se recopilan y se envían a la plataforma central en el medio. y todas las capas PaaS de Qingyun Todos los servicios se basan en IaaS, es decir, todos están en la nube. Entonces el primero es el almacenamiento. Hay tres grandes bloques en el medio. El primero se llama computación en tiempo real, llamado Storm. Por supuesto, lo que Twitter está lanzando ahora puede pretender ser más fuerte que Storm. El segundo es el procesamiento por lotes y el tercero es Big SQL, incluido Kylim, etc. A la derecha está lo que puede hacer en todas las plataformas, incluida la gestión de datos, el monitoreo y la seguridad, incluido algo que se usa para crear un centro de configuración distribuido.
Después de almacenar y calcular todos los datos, puede utilizarlos de maneras muy fáciles de usar. Generalmente podemos enviar los datos, por ejemplo, a algunos de los componentes técnicos con una interactividad relativamente buena. es más conveniente realizar visualización en el nivel superior, ya sea informes o visualización, que es más popular en el ecosistema Hadoop.
La imagen que estoy dibujando ahora cubre básicamente los productos o tecnologías centrales, o más convencionales, en el ciclo de vida de big data. También se incluye la propia plataforma de big data de Qingyun.
Permítanme hablar de ello primero. Lo hablaré uno por uno de acuerdo con esta estructura. Primero, hablemos de cálculos. El más clásico en informática es Hadoop. Esta imagen no requiere mucha explicación. Si sueles estudiar big data, puedes mencionar que a partir de 2.0, su HDFS tiene alta disponibilidad y el anterior es compatible con Yarn, lo que mejorará enormemente el rendimiento. La segunda arquitectura informática es Spark, que tiene algunas funciones principales. Si realiza cálculos en tiempo real, Storm es definitivamente la primera opción. La latencia de MapReduce es muy alta, pero el rendimiento es alto.
El disco duro de MapReduce es muy alto y el cálculo de Spark Streaming no es malo porque es un cálculo del disco duro. Si ya tiene alguna base en el ecosistema de Hadoop, puede ser mejor elegir Spark si no necesita mucho tiempo real, porque la plataforma Spark es muy poderosa y es una plataforma en sí misma, y la plataforma actual se está desarrollando. muy rápido, así que puedes elegir Spark, que es muy exigente contigo, ahora conocemos a todos los clientes. En segundo lugar, en Big SQL, hay algunos que mencionar. Uno es Phoenix, que proporciona productos empaquetados en lenguaje SQ. El segundo tipo es MPP.
Almacenamiento. Fue HDFS desde el principio. Primero, debe estar diseñado para archivos grandes, no para archivos pequeños masivos. Si desea procesar cantidades masivas de archivos pequeños, una idea en la plataforma Qingyun es el almacenamiento de objetos. Cuando la diseñamos, podíamos usar este almacenamiento sin importar el tipo o tamaño del archivo. ¿Por qué HDFS no puede almacenar archivos pequeños masivos? La razón es muy simple. Como todos los datos en Linux, hay un índice. Si almacena archivos pequeños masivos, los datos indexados tienen una característica, no importa si el archivo de datos es grande o pequeño. Los datos indexados tendrán el mismo tamaño. Al almacenar una gran cantidad de archivos pequeños, los archivos en realidad no son muy grandes, lo que afectará en gran medida el rendimiento y provocará que todo el espacio de almacenamiento de los datos no se utilice, pero el rendimiento ya no esté disponible.
El segundo almacenamiento más común es Hbase. Hbase está construido sobre HDFS. Puede almacenar tablas de muestra muy amplias y tablas de muestra muy altas. Los datos de todas las tablas se distribuyen en cada tabla. En realidad, es mucho más complicado que esto. De hecho, puedes pensar que corresponde al concepto de mesa. No sé si alguno de ustedes ha leído Hbase. Puede que al principio le resulte difícil entender Hbase porque es un almacenamiento en columnas, que es diferente de las bases de datos que ha visto antes. De hecho, su definición es muy simple, es decir, la oración en la segunda línea superior es una alusión escasa, distribuida, multidimensional y persistente. Sparse es la proporción de una celda unitaria. Hbase ha resuelto este problema en términos de formato de almacenamiento y puede almacenar una tabla dispersa. En segundo lugar, no es necesario explicar el distribuido. En esta imagen, puede ver que hay algunos conceptos de marcas de tiempo. Por ejemplo, el primero es la clave de fila de un registro, luego están las familias de columnas y luego está el número de versión.
Selección de almacenamiento, solo mencioné algunos, ¿cómo elegir el almacenamiento? No necesariamente al principio, definitivamente escuchará a muchas personas decir que Hbase debe ser más rápido que HDFS. Estas opiniones no son ciertas. ser en determinadas circunstancias. Por ejemplo, en Hadoop, este método es rápido cuando se realiza un escaneo global de archivos, pero es rápido cuando se realiza un almacenamiento aleatorio como Hbase, por lo que también es diferente según el escenario. Pero al igual que el KUDU en el medio, ayer un cliente dijo que está usando un KUDU, que es una solución intermedia, un motor de almacenamiento entre HDFS y Hbase. Aún no se han visto aplicaciones de producción a gran escala. Este es un almacén de datos construido a principios de este año, Greenplum Database, que fue de código abierto el año pasado. En el pasado, el núcleo de Greenplum podía ser desarrollado por la propia industria. Uno de sus mayores beneficios es que creemos que hay varios. El primero es SQL estándar. Es posible que vea que muchos productos en el mercado dicen que son compatibles con SQL. Pero en realidad no son estándar. ¿Qué significa que no es estándar? Por ejemplo, muchas sintaxis son diferentes. Si solía ser ingeniero o analista de datos, no podrá utilizar los usos más avanzados que ellos usaban. Sin embargo, Greenplum Database es diferente porque creemos que su motor informático central es mejor que MySQL y tiene muchas otras características.
Una vez que hayamos terminado de hablar sobre productos informáticos y productos de almacenamiento, pasemos a algo de transmisión de datos. Para la transmisión de datos hablamos del Kafka más clásico, que es distribuido, particionable, multicopia y de baja latencia.
¿Qué significa baja latencia? Las dos imágenes de la izquierda y la derecha son muy similares. De hecho, Kafka es equivalente a la entrada y salida de datos. Kafka es de código abierto por LinkedIn porque nuestra plataforma proporciona servicios de Kafka y ellos también los utilizan. ahora. Este es un producto que se usa. Esto significa que la latencia de Kafka es muy baja y los datos básicos se envían directamente sin caerse.
¿Por qué puede ser así? Hay dos razones muy esenciales: primero, cuando escribe datos, los escribe directamente en PageCatch y cuando los envía, los envía directamente a través de Linux, por lo que es La latencia de rendimiento es muy baja, debido a los dos núcleos. La arquitectura de Kafka es muy simple y consta de tres acoplamientos flexibles. Por ejemplo, la capa superior es su productor, luego un clúster, la del medio es un servidor, el servidor Kafka y la inferior es su consumidor. Un grupo de sus productores puede enviar datos al corredor, lo que equivale a que el corredor envíe los datos a la primera Partición y el segundo a la segunda Partición. El primer concepto principal de la Partición es que el mensaje que publica es Qué. los mensajes que genera tienen varias colas en Kafka y cada cola es una partición.
El segundo grupo es su consumidor. Los consumidores pueden mencionar un punto más importante. Tiene el concepto de grupo de consumidores. Cuando desee transmitir un mensaje de tema más veces y desee que muchos consumidores lo procesen, deberá crear varios grupos de consumidores para que el mensaje pueda ser consumido por varios consumidores. Si solo se crea un grupo de consumidores, incluso si el grupo de consumidores tiene varios consumidores, será procesado por un consumidor cada vez. La segunda pregunta es el número de consumidores en el grupo de consumidores. Uno de ellos es dos y el otro es cuatro. Es decir, hay cuatro particiones en un mensaje, es exactamente uno a uno. y cada consumidor Un consumidor consume una Partición. Si solo hay un consumidor, un consumidor consumirá dos Particiones. Esta situación es mejor. Hay una situación que debe evitarse, por ejemplo, si hay 5 consumidores y su tema solo tiene 4 colas, desperdiciará un consumidor. Es necesario señalar esto.
Después de hablar de cálculo, terminar de hablar de almacenamiento, terminar de hablar de transmisión y luego hablar de algunos problemas que encontramos. El primer gran problema es el factor de replicación. ¿Por qué no es necesario considerarlo para los nativos, pero por qué debería considerarse únicamente en la nube? La razón es muy simple, porque todos los servicios en la nube se basan en IaaS. la capa IaaS en sí tiene alta disponibilidad, lo que significa que los datos en sí tienen copias. Si aún copia el método en la máquina física, encontrará tres copias. Si lo piensa bien, 2 × 3 es 6. Por lo tanto, lo primero es ir a la copia y usar dos copias. Este es el plan que pensamos originalmente, solo use dos copias. Sin embargo, más tarde sentimos que las dos copias seguían siendo 2×2=4, lo que desperdiciaría más espacio.
Más tarde pensamos en una solución más avanzada, es decir, proporcionamos una capacidad en la capa IaaS para que la capa PaaS pueda elegir. Si digo que quiero varias copias, se convierte en una opción, así que. Por ejemplo, como big data o aplicaciones muy frágiles, pero a veces no es necesario, tiene su propia estrategia de copia y no es necesaria una copia de la capa IaaS. En este momento, se basa en su propia configuración, o. Según su propio producto Si es necesario, puede configurar la política de copia de la capa IaaS, para que sea la misma que la física.
Este ajuste de parámetros, por ejemplo, en big data típico, cada producto o plataforma tiene entre doscientos y trescientos parámetros. Este es el primer paso importante para el ajuste. que debemos hacer todo lo posible para conocer la relación entre estos parámetros de ajuste y cuál es la relación entre ellos. No podemos simplemente saber qué hace cada parámetro; de lo contrario, ajustar uno afectará al otro o el ajuste no tendrá ningún efecto. es porque no has descubierto la relación.
En una imagen como esta, puede hacer que el Administrador de nodos en hilo sea más pequeño que él y luego la memoria asignada en hilo. La relación entre estos es muy importante al realizar ajustes de rendimiento.
La última práctica recomendada importante está en el formato de datos, que mucha gente definitivamente ignorará. Pero es muy importante en big data. ¿Por qué? Porque los datos son muy grandes, y cuando la cantidad de datos es muy grande, si no se presta atención al formato de los datos, se producirán estos problemas. Por ejemplo, el rendimiento puede disminuir y entonces se desperdiciará mucho espacio, lo que aumentará exponencialmente.
De hecho, hay muchos elementos a los que prestar atención en el formato de datos. Hemos seleccionado dos criterios más importantes. En primer lugar, el formato de los datos debe ser separable. Los formatos que se pueden separar incluyen estos. La mayoría de ellos son Avro, índice Parquet Lzop y SequenceFile. Los que no son compatibles son archivos XML y JSON.
Los que se pueden comprimir en bloque son Avro, Parquet, Lzop index y SequenceFile. Los que no son compatibles son los registros CSV y JSON. Puede pensarlo, nuestros cálculos en la plataforma de big data son todos cálculos paralelos, todos sus datos se calculan por separado y luego cada fragmento los calcula, por lo que el segundo se puede comprimir en bloque. De hecho, hay muchos otros puntos, como si el formato de datos es compatible con gafas, como Avro, es decir, la versión anterior y la nueva versión del formato de datos siguen siendo compatibles. Incluye cosas como SequenceFile, escalable y comprimible, pero solo está en el ecosistema Hadoop, a diferencia de Avro y Parquet. Tendremos la conferencia de usuarios de Qingyun en el Hotel Beijing el 28 de julio. Solo somos responsables de los servicios. Las élites de diversas industrias hablarán sobre sus propias tecnologías y productos.