Comprenda el ecosistema tecnológico de big data en un artículo
Comprenda el ecosistema tecnológico de big data en un artículo
Big data en sí es un concepto muy amplio, y el ecosistema Hadoop (o panecosistema) está básicamente diseñado para procesar cosas más allá. La báscula monomáquina Nacida del procesamiento de datos. Puedes compararlo con una cocina, por lo que se necesitan varias herramientas. Las ollas, tazones y sartenes tienen cada uno sus propios usos y se superponen entre sí. Puedes usar la olla sopera como tazón para comer y beber sopa directamente, y puedes usar un cuchillo o un cepillo para pelarla. Pero cada herramienta tiene sus propias características y, si bien las combinaciones extrañas pueden funcionar, es posible que no sean la mejor opción. Para big data, en primer lugar, debe poder almacenar big data. Los sistemas de archivos tradicionales son independientes y no pueden abarcar diferentes máquinas. HDFS (Hadoop Distributed FileSystem) está diseñado esencialmente para que grandes cantidades de datos abarquen cientos o miles de máquinas, pero lo que ve es un sistema de archivos en lugar de muchos sistemas de archivos. Por ejemplo, si dice que quiero obtener los datos de /hdfs/tmp/file1, se refiere a una ruta de archivo, pero los datos reales se almacenan en muchas máquinas diferentes. Como usuario, no necesita saber esto, al igual que no le importa en qué pistas y sectores están dispersos los archivos en una sola máquina. HDFS administra estos datos por usted. Después de guardar los datos, comienza a pensar en cómo procesarlos. Aunque HDFS puede administrar datos en diferentes máquinas en su conjunto, los datos son demasiado grandes. Para que una máquina lea los datos de P sobre T (datos muy grandes, como el tamaño de todas las películas de alta definición en la historia de la Fiebre de Tokio o incluso más grandes), pueden pasar varios días o incluso semanas hasta que una máquina lea lentamente correr. Para muchas empresas, el procesamiento en una sola máquina es intolerable. Por ejemplo, si Weibo quiere actualizar los blogs más populares las 24 horas, debe completar estos procesos en 24 horas. Entonces, si quiero usar muchas máquinas para procesar, me enfrentaré a cómo distribuir el trabajo, cómo reiniciar las tareas correspondientes si una máquina se bloquea, cómo comunicar e intercambiar datos entre máquinas para completar cálculos complejos, etc. Esto es lo que hace MapReduce/Tez/Spark. MapReduce es el motor informático de primera generación y Tez y Spark son la segunda generación. El diseño de MapReduce adopta un modelo informático muy simplificado, con solo dos procesos informáticos: Map y Reduce (el uso aleatorio se puede utilizar en serie para resolver gran parte de los problemas en el campo de big data). Entonces, ¿qué es Map y qué es Reduce? Considere si desea contar un archivo de texto enorme almacenado en algo como HDFS y desea saber la frecuencia de cada palabra en el texto. Inicia un programa MapReduce. En la etapa de Mapa, cientos de máquinas leen varias partes del archivo al mismo tiempo y cuentan por separado las frecuencias de palabras de las partes que leen, lo que da como resultado pares como (hola, 12100 veces), (mundo, 15214 veces), etc. (I Map y Combine se mencionan juntos aquí por simplicidad). Cada uno de estos cientos de máquinas genera la colección anterior, y luego cientos de máquinas comienzan a reducir el procesamiento. La máquina reductora A recibirá todos los resultados estadísticos que comiencen con A de la máquina Mapper, y la máquina B recibirá resultados estadísticos léxicos que comiencen con B (por supuesto, en realidad no comenzará con una letra como base, sino que usará una función para generar una Valor hash para evitar la serialización de datos. Porque las palabras que comienzan con X definitivamente son muchas menos que otras y no desea que la carga de trabajo del procesamiento de datos varíe mucho entre máquinas). Luego, estos Reductores se agregarán nuevamente, (hola, 12100) + (hola, 12311) + (hola, 345881) = (hola, 370292). Cada Reductor se procesa como se indica arriba y obtendrá los resultados de frecuencia de palabras de todo el archivo. Este parece ser un modelo muy simple, pero este modelo puede describir muchos algoritmos. El modelo simple de Map+Reduce es muy tosco y violento. Aunque es fácil de usar, es muy engorroso. Además de nuevas características como la memoria caché, la segunda generación de Tez y Spark esencialmente hace que el modelo Map/Reduce sea más versátil, desdibuja los límites entre Map y Reduce, hace que el intercambio de datos sea más flexible y requiere menos lecturas de disco escritas en más. Describe fácilmente algoritmos complejos y logra un mayor rendimiento.
Después de tener MapReduce, Tez y Spark, los programadores descubrieron que escribir programas MapReduce era realmente problemático. Quieren simplificar el proceso. Es como si tuvieras lenguaje ensamblador. Aunque puedes hacer casi cualquier cosa, todavía te resulta engorroso. Quiere una capa de lenguaje más abstracta y de nivel superior para describir algoritmos y procesos de procesamiento de datos. Entonces están Pig y Hive. Pig describe MapReduce como si fuera un script, mientras que Hive usa SQL. Traducen scripts y lenguajes SQL a programas MapReduce y los envían al motor de cálculo para su cálculo, y usted se libera de los engorrosos programas MapReduce y puede escribir programas en un lenguaje más simple e intuitivo. Con Hive, la gente ha descubierto que SQL tiene enormes ventajas sobre Java. Una es que es muy fácil de escribir. La frecuencia de palabras descrita hace un momento solo se puede describir en una o dos líneas en SQL, pero se necesitan docenas o cientos de líneas para escribirla en MapReduce. Y lo que es más importante, los usuarios que no tienen experiencia en informática finalmente se sienten amados: ¡también puedo escribir SQL! Así, los analistas de datos finalmente se liberan de pedir ayuda a los ingenieros, y los ingenieros se liberan de escribir extraños programas de procesamiento únicos. Todos están felices. Hive se ha convertido gradualmente en un componente central del big data warehouse. Incluso los conjuntos de trabajos de canalización de muchas empresas se describen completamente en SQL, porque es fácil de escribir y cambiar, fácil de entender de un vistazo y fácil de mantener. Desde que los analistas de datos comenzaron a usar Hive para analizar datos, descubrieron que Hive es realmente lento cuando se ejecuta en MapReduce. Es posible que el conjunto de trabajos de canalización no importe, como las recomendaciones actualizadas las 24 horas del día, pero de todos modos se puede ejecutar dentro de las 24 horas. Pero en el análisis de datos, la gente siempre quiere correr más rápido. Por ejemplo, quiero ver cuántas personas permanecieron en la página de muñecas inflables en la última hora y cuánto tiempo permanecieron. Para un sitio web gigante con datos masivos, este proceso puede llevar decenas de minutos o incluso muchas horas. Y este análisis puede ser sólo el primer paso en su larga marcha. También necesita observar cuántas personas hojearon el vibrador y cuántas vieron el CD de Rachmaninov, para poder informar a su jefe que nuestros usuarios son hombres miserables y amenazadores. Las mujeres, en su mayoría, son jóvenes/niñas artísticas. No puedes soportar la tortura de esperar, así que solo puedes decirle al apuesto ingeniero Grasshopper, ¡apúrate, apúrate, apúrate! Así nacieron Impala, Presto y Drill (por supuesto, hay innumerables motores SQL interactivos no famosos, por lo que no los enumeraré todos). El concepto central de los tres sistemas es que el motor MapReduce es demasiado lento porque es demasiado versátil, demasiado fuerte y demasiado conservador. Nuestro SQL necesita ser más liviano, más agresivo en la adquisición de recursos y más especializado en la optimización de SQL, y eso es todo. no requiere tanta garantía de tolerancia a fallas (porque si el sistema falla, la tarea se reiniciará si el tiempo de procesamiento total es más corto, por ejemplo, en unos pocos minutos). Estos sistemas permiten a los usuarios procesar tareas SQL más rápidamente, sacrificando características como la versatilidad y la estabilidad. Si MapReduce es un machete capaz de cortar cualquier cosa, entonces los tres anteriores son cuchillos para deshuesar, que son inteligentes y afilados, pero no pueden manejar nada que sea demasiado grande o demasiado duro. Estos sistemas, para ser honesto, nunca alcanzaron la popularidad que la gente esperaba. Porque en este momento se crearon dos especies alienígenas más. Son Hive en Tez/Spark y SparkSQL. Su concepto de diseño es que MapReduce es lento, pero si uso una nueva generación de motor informático general Tez o Spark para ejecutar SQL, entonces puedo ejecutarlo más rápido. Y los usuarios no necesitan mantener dos sistemas. Esto es como si su cocina es pequeña, es vago y tiene requisitos limitados para una buena cena, entonces puede comprar una olla arrocera, que puede cocinar al vapor, cocinar y cocinar, y ahorrar muchos utensilios de cocina. La introducción anterior es básicamente la arquitectura de un almacén de datos. El HDFS subyacente ejecuta MapReduce/Tez/Spark y Hive y Pig se ejecutan en él. O ejecute Impala, Drill y Presto directamente en HDFS. Esto aborda los requisitos de procesamiento de datos de velocidad media a baja. ¿Qué pasa si quiero un procesamiento más rápido? Si fuera una empresa similar a Weibo, me gustaría ver un blog de actualidad que no esté disponible las 24 horas del día. Me gustaría ver una lista de novedades en constante cambio. Si la actualización se retrasa en un minuto, ninguno de los métodos anteriores. será adecuado. Entonces se desarrolló otro modelo informático, que es la informática Streaming. Storm es la plataforma informática de flujo más popular.
La idea de la computación en flujo es que, si quiero lograr más actualizaciones en tiempo real, ¿por qué no procesar los datos a medida que llegan? Por ejemplo, en el caso de las estadísticas de frecuencia de palabras, mi flujo de datos es palabra por palabra, así que las dejo fluir y empiezo a contarlas. La computación en flujo es muy poderosa y básicamente no tiene demora. Sin embargo, su desventaja es que es inflexible. Lo que se desea contar debe saberse de antemano. Después de todo, los datos desaparecen y no se puede compensar. no lo has calculado. Por lo tanto, es algo bueno, pero no puede reemplazar el almacén de datos y el sistema de procesamiento por lotes mencionados anteriormente. También hay un módulo algo independiente llamado KV Store, como Cassandra, HBase, MongoDB y muchos, muchos, muchos, muchos otros (demasiados para imaginar). Entonces, KV Store significa que tengo un montón de valores clave y puedo obtener rápidamente los datos vinculados a esta clave. Por ejemplo, puedo utilizar tu número de DNI para obtener tus datos de identidad. Esta acción también se puede completar usando MapReduce, pero es probable que escanee todo el conjunto de datos. KV Store está especialmente diseñada para manejar esta operación, y todos los depósitos y retiros están especialmente optimizados para esto. Puede que solo se necesiten unas décimas de segundo para encontrar un número de identificación entre varios P de datos. Esto permite optimizar en gran medida algunas operaciones especializadas de las empresas de big data. Por ejemplo, tengo una página en mi sitio web que busca contenido del pedido según el número de pedido, pero la cantidad del pedido de todo el sitio web no se puede almacenar en una base de datos independiente, por lo que consideraré usar KV Store para almacenarlo. El concepto de KV Store es que básicamente no puede manejar cálculos complejos, la mayoría de ellos no se pueden unir y es posible que no se puedan agregar, y no existe una garantía de coherencia sólida (se distribuyen datos diferentes en diferentes máquinas y usted puede lee resultados diferentes cada vez que lo lees. Tampoco puede manejar operaciones con fuertes requisitos de coherencia, como transferencias bancarias). Pero es rápido. Extremadamente rápido. Cada diseño diferente de KV Store tiene diferentes compensaciones: algunas son más rápidas, otras tienen mayor capacidad y algunas pueden admitir operaciones más complejas. Debe haber uno adecuado para ti. Además, existen algunos sistemas/componentes más especializados, como Mahout, que es una biblioteca distribuida de aprendizaje automático, Protobuf, que es una biblioteca y codificación para el intercambio de datos, ZooKeeper, que es un sistema de colaboración de acceso distribuido altamente consistente, etc. en. Con tantas herramientas desordenadas ejecutándose en el mismo clúster, todos deben respetarse unos a otros y trabajar de manera ordenada. Otro componente importante es el sistema de programación. El más popular ahora es Yarn. Puedes considerarlo como una gestión central, como si tu madre supervisara el trabajo en la cocina. Oye, tu hermana terminó de cortar verduras y tú puedes tomar el cuchillo para matar el pollo. Mientras todos sigan las instrucciones de tu madre, todos podrán cocinar felices. Se puede pensar en el ecosistema de big data como un ecosistema de herramientas de cocina. Para cocinar diferentes platos, comida china, comida japonesa, comida francesa, necesitas todo tipo de herramientas diferentes. Y las necesidades de los invitados son cada vez más complicadas. Los utensilios de cocina se inventan constantemente y no existe un utensilio de cocina único que pueda manejar todas las situaciones, por lo que será cada vez más complejo.
Lo anterior es el contenido relevante compartido por el editor sobre cómo comprender el ecosistema tecnológico de big data en un artículo. Para obtener más información, puede seguir a Global Ivy para compartir más información útil.