En 2022, Sohu Smart Media completó el proyecto de computación elástica de migrar a Tencent Cloud, en el que todo el negocio de big data se migró a Tencent Cloud.Después de migrar a la nube, el rendimiento general del servicio, el control de costos y la operación y mantenimiento eficiencia han logrado buenos resultados, se han alcanzado las metas esperadas de reducción de costos y aumento de eficiencia.
Este artículo presenta principalmente el negocio de big data de Sohu Smart Media, el trabajo y la experiencia relacionados con la migración de sistemas básicos, datos históricos, sistemas comerciales, etc. en el proceso de migración de Tencent Cloud Big Data EMR, así como los aspectos técnicos clave. transformación en el proceso.
Autor de este artículo:
Zhai Dongbo Ingeniero sénior de desarrollo del Centro de I+D de medios inteligentes de Sohu
Qi Laijun, ingeniero de desarrollo sénior, centro de investigación y desarrollo de medios inteligentes de Sohu
Descripción general del negocio de Big Data
1.1 Clasificación empresarial de Big Data
Figura 1 - Diagrama de clasificación empresarial de Big Data
Basado en la clasificación del negocio de big data de medios inteligentes, se lleva a cabo principalmente a partir de dos dimensiones ortogonales, una es la dimensión de la operación de datos, la otra es la dimensión de la oportunidad de los datos.
1. Según la dimensión de operación de datos, se divide principalmente en aplicaciones de producción y análisis de datos.
La producción de datos puede entenderse como producción ETL generalizada, que incluye principalmente una serie de operaciones de datos, como limpieza de datos, conversión de formato y asociación de datos. Sus características principales se basan en primer lugar en cálculos a gran escala, entrada y salida de gran volumen de datos y tiempo de ejecución prolongado. En segundo lugar, el procesamiento de datos debe tener una alta tolerancia a fallas, como MapReduce, Spark y otros motores informáticos, que pueden realizar tolerancia a fallas y Vuelva a intentarlo si falla una sola tarea. Tales operaciones no afectan la ejecución de todo el trabajo o la aplicación.
Las aplicaciones analíticas, basadas en los datos producidos por los datos, realizan operaciones de nivel superior, principalmente análisis multidimensionales, como scrolling, drill down, slicing, etc. La característica principal es que el conjunto de resultados de la consulta es pequeño, es decir, no es una gran cantidad de entrada de datos y una pequeña cantidad de salida de datos, pero para La puntualidad de la respuesta a la consulta es muy alta, generalmente en el segundo o incluso sub-segundo nivel.
2. Según la dimensión de puntualidad de los datos, se divide principalmente en datos fuera de línea y datos en tiempo real.
Los datos fuera de línea requieren puntualidad a nivel de día u hora, y los datos fuera de línea se administrarán y operarán utilizando modelos jerárquicos.
Para los datos en tiempo real, generalmente se requiere que la puntualidad esté en el nivel de minuto/segundo. Para algunos escenarios de IoT, incluso se requiere que el retraso de la puntualidad de los datos se controle en el nivel de subsegundos. Dado que el análisis de datos en tiempo real representa una proporción relativamente pequeña del análisis de datos general, los métodos de desarrollo de chimeneas se utilizan generalmente para la gestión y operación, y se establecen diferentes tareas de datos en tiempo real para diferentes requisitos de producción y análisis de datos; actualmente en la práctica, hay también llevan a cabo una arquitectura de modelo en capas similar a los datos fuera de línea, realizan un modelado en capas en datos en tiempo real, escriben los datos del modelo subyacente en Kafka en tiempo real y los proporcionan al modelo de alto nivel; con el desarrollo de open bases de datos de origen como StarRocks que admiten la escritura en tiempo real de datos de gran rendimiento Apareció, en la práctica de aplicación de datos en tiempo real, comenzó a utilizar el modo de "cálculo posterior", es decir, los datos originales se escriben en la base de datos en tiempo real tiempo como una tabla ODS a través de ETL, y en función de estos datos de la tabla ODS, se escriben anuncios de clase compleja, como Unirse y agregación.Hoc SQL consulta declaraciones para cumplir con diferentes análisis y requisitos de consulta.
De acuerdo con la división de las dos dimensiones anteriores, el negocio de datos se puede dividir en cuatro escenarios:
1) Análisis fuera de línea, principalmente el tipo de negocio de almacén de datos tradicional, generalmente escenario de análisis T+1, las principales tecnologías utilizadas en la práctica de la ingeniería incluyen Impala, Presto, StarRocks, etc.;
2) Análisis en tiempo real, dirigido a escenarios de almacenamiento de datos en tiempo real, la principal tecnología utilizada es StarRocks, etc.;
3) ETL sin conexión está dirigido al escenario de procesamiento por lotes, y las principales tecnologías utilizadas incluyen HIVE/Spark/MapReduce, etc.
4) ETL en tiempo real está dirigido a escenarios de procesamiento de flujo. Las principales tecnologías utilizadas incluyen StarRocks, Flink, Spark Streaming, etc. Dado que la carga rutinaria de StarRocks admite la limpieza de datos, la conversión de formato y otros efectos, en algunos escenarios comerciales en tiempo real de medios inteligentes, carga de rutina de uso directo para operaciones ETL de datos en tiempo real.
1.2 Arquitectura empresarial de Big Data
Figura 2 - Diagrama de arquitectura empresarial de Big Data
De acuerdo con la clasificación anterior del negocio de big data, la imagen de arriba muestra la estructura general del negocio de big data de los medios inteligentes, que se divide principalmente en tres capas: capa de fuente de datos, computación y almacenamiento de datos y aplicación de datos.
1. La capa de fuente de datos incluye principalmente dos categorías: datos comerciales, que son los datos operados directamente por el sistema comercial, que se almacenan principalmente en bases de datos como MySQL, Oracle y MongoDB; datos de registro, que son los datos que representan el sistema comercial eventos, Los datos recopilados del cliente a través de puntos enterrados, o los registros impresos por el servidor.
2. La computación y el almacenamiento de datos es el nivel central de toda la arquitectura comercial de big data. El lado izquierdo de la figura anterior es la parte comercial de datos fuera de línea, que adopta un modelo en capas y generalmente se divide en almacenes de datos fuera de línea como STG/ODS/DWD/DWS/ADS; el lado derecho es la parte comercial de datos en tiempo real , que adopta tres métodos de desarrollo de datos, de izquierda a derecha, el método de desarrollo de chimenea, modelado en capas y cálculo posterior.
1) El desarrollo de Chimney crea tareas de datos en tiempo real para diferentes empresas, y el procesamiento complejo, como Join, se realizará dentro de la tarea ETL. Dado que el procesamiento de operaciones Join en Stream Processing es muy complicado y habrá problemas como la precisión de los datos. , el desarrollo de la chimenea también está disminuyendo gradualmente;
2) Modelado jerárquico, que utiliza modelos comerciales fuera de línea para estratificar los datos y reducir el desarrollo de la chimenea.Se utiliza principalmente en escenarios como actualización de datos en tiempo real y modelos de recomendación en tiempo real para negocios en línea;
3) Cálculo posterior, generación de datos de tablas ODS en la capa de origen a través de ETL en tiempo real, escritura de declaraciones SQL directamente basadas en datos de tablas ODS para requisitos de análisis comercial y operaciones de cálculo posterior como unión de datos, ventana y agregación para consulta tiempo;
3. La capa de aplicación de datos está principalmente conectada al sistema de BI interno del departamento, basado en Impala, Presto y StarRocks para satisfacer las necesidades de consulta rápida de datos en diferentes escenarios.
1.3 Arquitectura técnica de big data bajo la nube
Figura 3-Diagrama de Arquitectura Técnica de Big Data bajo la Nube
De acuerdo con la arquitectura empresarial de big data, la arquitectura técnica de big data bajo la nube se muestra en la figura anterior.
Para los datos sin conexión, la sincronización de datos de registro utiliza principalmente Flume, la sincronización de datos empresariales utiliza Sqoop y MongoDB, Elasticsearch, Redis y otros complementos de desarrollo propio de Sqoop; el almacenamiento de datos utiliza HDFS y el procesamiento por lotes utiliza HIVE y Spark basados en la gestión de recursos YARN. basado en el desarrollo propio La plataforma de gestión de datos fuera de línea adopta un modelo jerárquico para construir un almacén de datos fuera de línea y, al mismo tiempo, administra el DAG de las tareas de procesamiento de datos ODS/DWD/DWS/ADS, y tiene funciones como complemento, calidad de datos, y gestión de metadatos; análisis fuera de línea basado principalmente en motores de consulta MPP como Impala/Presto/StarRocks.
Para datos en tiempo real, Flume se utiliza principalmente para la sincronización de datos de registro, Canal y otros productos de CDC se utilizan para la sincronización de datos empresariales; Kafka y StarRocks se utilizan para el almacenamiento de datos, Flink y Spark Streaming se utilizan para ETL en tiempo real y StarRocks se utiliza principalmente para el análisis en tiempo real.
Lo anterior es una introducción general a la arquitectura técnica de big data bajo la nube.El resumen general de big data bajo la nube es el siguiente:
1) Sistema básico: Cloud usa la plataforma Hadoop proporcionada por Sohu y tiene un equipo dedicado responsable de la operación y el mantenimiento; StarRocks es construido y operado por el propio equipo.
2) Datos históricos: el volumen actual de datos históricos acumulados está en el nivel de 10 PB.
3) Sistema empresarial: incluye informes, OLAP, Ad Hoc y otros sistemas de BI de creación propia, y una plataforma de gestión de datos fuera de línea de desarrollo propio, que gestiona las tareas de modelado en capas de datos fuera de línea. La migración de todo el negocio de big data a la nube gira en torno a las tres partes anteriores.
La arquitectura de big data bajo la nube también ha encontrado algunos puntos débiles durante los años de desarrollo, como el largo período de expansión de la sala de cómputo, es difícil reponer rápidamente los recursos de cómputo de acuerdo con las necesidades del negocio, independientemente de si hay tareas de cómputo. , los recursos deben reservarse en cualquier momento, y múltiples negocios El problema de la asignación de costos para los departamentos que comparten recursos informáticos. Estos puntos débiles también se han resuelto satisfactoriamente en el proceso de migración a la nube.
El camino hacia la reducción de costos en la nube y el aumento de la eficiencia
2.1 Arquitectura técnica de big data en la nube
Figura 4-Diagrama de Arquitectura Técnica de Big Data en la Nube
Para garantizar la rápida migración de los servicios de big data a la nube, los componentes de big data se migran a Tencent Cloud EMR en forma de reubicación plana.Mientras que EMR optimiza los componentes de código abierto a nivel de kernel, también garantiza una compatibilidad perfecta con el componentes de código abierto, evitando problemas debido a que las versiones de componentes conducen a problemas de incompatibilidad comercial y minimizan la carga de trabajo, la dificultad, el riesgo y otros factores de la migración a la nube.
Las tareas principales de la migración de big data a Tencent Cloud EMR son las siguientes:
1. Sistema básico:
1) Hadoop bajo la nube usa la versión CDH 5.XX, y EMR en la nube elegimos 2.6 En el uso real, las funciones de los componentes de las dos versiones de Hadoop son básicamente compatibles;
2) Los componentes del clúster de StarRocks independientes se pueden seleccionar en EMR, que pueden reemplazar completamente a StarRocks bajo la nube;
3) Flink Utilizamos Oceanus de Tencent, que proporciona una capacidad de gestión de tareas más potente y un entorno operativo más estable sobre la base de proporcionar un método de desarrollo rápido de Flink SQL. Debido a que Oceanus está completamente en contenedores, puede lograr una gestión de recursos más refinada que la programación tradicional basada en YARN.En el escenario de enlace ETL, incluso 0.25 CPU se puede usar para ejecutar un operador, lo que ahorra en gran medida los costos informáticos;
2. Datos históricos:
Teniendo en cuenta el problema de los costos, y como una plataforma de big data nativa de la nube, EMR es naturalmente compatible con la arquitectura de separación de computación y almacenamiento y puede usar directamente el almacenamiento de objetos como el sistema de archivos para el almacenamiento de datos.Componentes como Hive, Spark, Impala y Presto puede operar directamente COS/ datos en OFS; por lo que decidimos migrar los datos históricos en HDFS a OFS, el cubo de aceleración de metadatos de almacenamiento de objetos, que resuelve el problema del alto costo de los datos históricos masivos y permite la retención posterior Es posible analizar más datos históricos o entrenamiento de aprendizaje automático.
3. Sistema de negocios:
La migración del sistema de BI es relativamente simple, después de migrar los datos y los sistemas básicos, basta con configurar la información de enlace de la base de datos a los nuevos sistemas Impala, Presto, StarRocks y otros; para la plataforma de gestión de datos fuera de línea, la carga de trabajo de migrar a la nube es relativamente grande, y los datos acumulados Para miles de tareas de datos fuera de línea, la tarea DAG debe ejecutarse con éxito en la plataforma de la nube.
2.2 Trabajo principal de migración
2.2.1 Migración del sistema básico
La migración del sistema básico incluye principalmente los siguientes aspectos:
1. Planificación y construcción de clústeres:
De acuerdo con los escenarios comerciales de big data y el flujo de procesamiento de datos, se planean principalmente dos conjuntos de clústeres de EMR: uno se usa para el procesamiento de datos fuera de línea y el otro se usa para tareas de Spark Streaming de datos en tiempo real. La razón por la que se crean dos conjuntos de clústeres se debe principalmente a que el uso de recursos del procesamiento de datos fuera de línea tiene características de picos y valles evidentes, y se puede usar la función de escalado elástico de recursos de EMR; mientras que las tareas de Spark Streaming son todas tareas de ejecución prolongada, el consumo de recursos aumentará Muy suave. Dado que EMR tiene la capacidad de crear clústeres rápidamente a nivel de minuto, el aislamiento de recursos a nivel de clúster es más efectivo que la división de colas dentro del mismo clúster y también es más conveniente para compartir los costos posteriores.
Para el clúster de StarRocks, solo se construyeron dos conjuntos de clústeres de grano grueso debido a la limitación de las máquinas y los costos de mantenimiento en la nube. La construcción de clústeres de StarRocks en la nube ya no está limitada por los recursos, y el costo de creación y mantenimiento es mucho menor. Hemos creado múltiples clústeres de granularidad fina según las divisiones comerciales para reducir la interferencia de uso entre empresas.
La tarea de Flink utiliza directamente Oceanus, una plataforma de computación de flujo proporcionada por Tencent, y encapsula la API de SQL, el conector de fuente de datos de fuente de datos común, etc. en Flink, y ha realizado muchas mejoras basadas en la versión comunitaria kernel y CDC, que es mejor que eso solo en el clúster de Hadoop. Usar Flink es mucho más conveniente. Al mismo tiempo, Oceanus también puede controlar el uso de recursos de tareas al nivel de 0,25 CU. En comparación con el Flink de código abierto, cada CPU solo puede asignar una única ranura, lo que aumenta considerablemente el uso de recursos de las tareas informáticas de transmisión.
2. Optimización de la configuración e implementación del clúster fuera de línea de EMR.
1) Configuración dinámica de política de expansión y contracción elástica: Al principio, usamos el escalado de carga para realizar la expansión elástica. Sin embargo, durante el proceso de escalado de carga de prueba, descubrimos que las tareas informáticas enviadas por los usuarios a menudo no especifican activamente el uso de recursos, lo que resulta en utilización de recursos Error en el monitor. Si la sensibilidad de monitoreo del umbral de carga está configurada demasiado alta, es fácil activar repetidamente la expansión.Si la sensibilidad de monitoreo del umbral de carga está configurada demasiado baja, es probable que la respuesta de expansión se retrase. Después de discutir con los arquitectos de Tencent Cloud, observamos que la mayoría de las tareas fuera de línea se ejecutan en las primeras horas de la mañana, con un período de tiempo obvio, por lo que usamos directamente el modo de expansión de escalado de tiempo, que satisface los requisitos comerciales de manera simple y rápida. para la programación de tiempo compartido recursos.necesidades;
2) Programación YARN: dado que el clúster de Hadoop en la nube es un gran grupo de recursos fijo y todos los usuarios comparten el costo por igual, la estrategia de programación utiliza un método de programación justo. Al migrar a la nube, esperamos mejorar la utilización de recursos tanto como sea posible. En comparación con la cola residente de IDC con más de 10 000 núcleos, en EMR, podemos lograr que la cola residente habitual sea solo unos pocos miles de núcleos más pequeña. Si continúa utilizando la estrategia de programación justa en este momento, una gran cantidad de tareas pueden solicitar recursos del RM al mismo tiempo, lo que provocará que cada tarea no obtenga suficientes recursos. Bajo la sugerencia de los arquitectos de Tencent Cloud, cambiamos el método de programación de capacidad y los recursos se pueden asignar a las tareas en la cola avanzada en Ejecución primero para garantizar que las tareas se completen a tiempo;
3) Configuración de HIVE: según la experiencia de ajuste del clúster de Hive en la nube y la exploración en el uso de EMR, se han ajustado muchos parámetros, como la memoria de almacenamiento dinámico de JVM, la memoria de tareas de MR, el nivel de registro, el número de conexiones de sesión, etc.;
4) Impala/Presto: EMR admite el uso de nodos de tareas independientes para la implementación del motor de consultas ad hoc para evitar la contención de recursos causada por la implementación mixta con el administrador de nodos. Cuando se encuentre con algunas consultas grandes o escenarios de consultas de alta simultaneidad, no ejercerá presión sobre el nodo maestro e incluso puede realizar una expansión rápida del motor de consultas solo para consultas.
3. Operación y mantenimiento del clúster:
El EMR de Tencent Cloud es un producto PaaS semigestionado, que es más flexible y personalizable que los clústeres de Hadoop en la nube. Incluso si los clientes no tienen una rica experiencia en operación y mantenimiento, pueden participar fácilmente en el trabajo de operación y mantenimiento con la ayuda de la herramienta de operación y mantenimiento de pantalla blanca proporcionada por EMR, y realizar una configuración flexible de acuerdo con las necesidades comerciales para obtener un mejor rendimiento. y escalabilidad.
Para el clúster de Hadoop en la nube, la empresa cuenta con un equipo dedicado a la operación y el mantenimiento, y necesita compartir los costos laborales de la operación y el mantenimiento con el equipo comercial todos los meses. Después de migrar a la nube, Tencent Cloud brindó un equipo profesional de operación y mantenimiento para brindar a los clientes un completo soporte técnico gratuito las 24 horas del día, los 7 días de la semana. Los clientes pueden obtener soporte técnico oportuno y resolución de problemas, y la eficiencia de operación y mantenimiento se ha mejorado significativamente para asegurar la operación estable del negocio.
Sobre esta base, esperamos transformar aún más el trabajo de operación y mantenimiento en la dirección de la automatización y la inteligencia. En la actualidad, Sohu y Tencent construyen conjuntamente un método de operación y mantenimiento basado en alarmas, y configuran el monitoreo de alarmas desde múltiples aspectos, que incluyen principalmente alarmas de monitoreo de hardware/software EMR, alarmas de inspección de fondo de Tencent Cloud y alarmas de monitoreo comercial de Sohu. una unión Cubra todos los posibles escenarios de falla del EMR tanto como sea posible. A través de la operación y el mantenimiento proactivos, las fallas se reducen antes de que ocurran, lo que mejora significativamente la capacidad de solucionar problemas y la eficiencia de la operación y el mantenimiento.
Figura 5-Diagrama de composición de alarma de monitoreo completo
2.2.2 Migración de datos históricos
La migración de datos históricos incluye principalmente los siguientes aspectos:
1. Almacén de datos
Para ahorrar costos de almacenamiento, migramos los datos históricos de los datos del almacén en HDFS bajo la nube al almacenamiento de objetos y resolvimos una serie de problemas en el proceso:
1) El clúster de Hadoop en la nube es compartido por varios departamentos comerciales, por lo que la autenticación Kerberos está habilitada. En la nube, se implementaron la red, el grupo de seguridad y el aislamiento a nivel de clúster, y el lado comercial solo puede enviar código a través del sistema de programación Para facilitar el equipo de administración, el clúster en la nube no habilita Kerberos, y la tarea Distcp de migración de datos se extrae de Hadoop en la nube;
2) Dado que COS-Distcp necesita introducir paquetes de dependencia de almacenamiento de objetos en el clúster de Hadoop, para evitar cambios en el clúster de producción de Hadoop en la nube, la migración de datos se realiza mediante el clúster de EMR en la nube. migró a HDFS en la nube a través de Distcp. Luego use COS-Distcp para sincronizar los datos de HDFS en la nube con el almacenamiento de objetos. Una vez completada la migración, use el parámetro SkipTrash para borrar directamente los datos de transferencia de HDFS en la nube;
3) Limitado por la limitación de ancho de banda, dado que existe una limitación de ancho de banda entre la sala de computadoras en la nube y la sala de computadoras en la nube, siempre debemos prestar atención al impacto en el ancho de banda al copiar datos y al mismo tiempo introducir los parámetros Bandwidth y m al ejecutar Hadoop Distcp para controlar la tarea de migración Bandwidth y Map concurrencia;
4) Problema de verificación de datos. Dado que el comando Hadoop Distcp no puede verificar la consistencia de HDFS y los datos de almacenamiento de objetos, es necesario usar la herramienta COS-Distcp proporcionada por Tencent Cloud para verificar después de la migración de datos;
5) Para problemas de tiempo de archivo, use el parámetro -pt para migrar los atributos de tiempo de archivo en el HDFS bajo la nube al almacenamiento de objetos y luego realice operaciones de archivado basadas en los atributos de tiempo de archivo.
2. Migración de metadatos de Hive
Con base en el módulo de administración de metadatos de la plataforma de administración de datos fuera de línea, obtenga todas las bases de datos y tablas de datos en la nube y obtenga la declaración de creación de tablas de la tabla de datos a través de Show Create Table XXX. La ubicación de la tabla de datos es consistente con la ruta en la nube, y a través de la gestión de datos fuera de línea en la nube La plataforma implementa la creación por lotes de tablas de datos.
3. Migración de registros sin procesar
Migre los datos de registro sin procesar almacenados en HDFS en la nube a COS. Combinados con los escenarios de uso de datos de la empresa, los datos que básicamente no se usaron hace un mes se almacenan en el archivo profundo, y los datos de registro sin procesar hace una semana son se usa con poca frecuencia Almacenamiento Aproveche las capacidades de archivo profundo y baja frecuencia de COS para reducir aún más los costos de almacenamiento.
4. Migración de StarRocks
Actualmente, existen tres formas principales de migrar datos de StarRocks en la nube a StarRocks en la nube:
1) Exporte los datos de StarRocks bajo la nube a HDFS a través de EXPORTAR y luego importe los datos a StarRocks en la nube a través de Broker Load. Este método es adecuado para la migración de datos a gran escala sin tipos de campos especiales.
2) Cree la tabla externa de StarRocks bajo la nube en StarRocks en la nube y luego importe los datos a través del método Insertar en XXX Seleccione XXX Este método es adecuado para la migración de tablas de datos con campos HLL y de mapa de bits, pero si es una mesa grande, la velocidad de importación es relativamente más lenta
3) Para la migración de datos del sistema Apache Doris heredado, debido a la incompatibilidad entre los formatos de datos StarRocks y Apache Doris, el método Expro no se puede usar para redirigir los resultados de la consulta de datos al local a través del cliente MySQL y luego importar los datos a StarRocks en la nube a través de Stream Load.
2.2.3 Migración del sistema empresarial
Figura 6 - Diagrama esquemático de implementación distribuida de sistemas comerciales
Trabajo de migración del sistema empresarial
Principalmente la migración de la plataforma de gestión de datos fuera de línea,
1. El proceso de servicio se implementa en el nodo del enrutador. En comparación con la nube, los recursos del nodo de la máquina son más abundantes y el nodo del enrutador se puede escalar según sea necesario;
2. Hay tareas de datos y metainformación de tablas en MySQL, que se pueden sincronizar fácilmente con la nube mediante el uso de herramientas como DTS;
3. Migración de tareas de datos: con el apoyo del equipo de big data de Tencent Cloud, se ejecutan y prueban miles de tareas de datos a través de herramientas, principalmente para verificar las declaraciones HIVE y Spark SQL en las tareas de datos. la nube son básicamente compatibles. Solo se encontraron algunos problemas de compatibilidad de declaraciones SQL entre miles de tareas de datos. Durante la prueba, se descubrió que la CLI de HIVE de EMR y Beeline ocuparían una gran cantidad de CPU al comienzo de la ejecución, y Jar relacionado se realizaron reemplazos;
Finalmente, a través de pruebas, ejecución doble y cambio de transmisión, todo el DAG de tareas de datos se migra gradualmente a la nube.
2.3 Transformación de tecnologías clave
2.3.1 Separación de almacenamiento y cálculo
Transformación de tecnología de separación de almacenamiento y cálculo
Creo que cuando todas las empresas cambian de IDC fuera de la nube tradicional a servicios en la nube, cómo elegir el almacenamiento de datos es el mayor problema que se encuentra en el proceso de migración a la nube Tencent Cloud ofrece tres opciones:
1. Utilice la solución de disco local HDFS plus nativo de EMR, que puede lograr un mayor rendimiento local y menores costos de almacenamiento.
2. Use la solución de disco en la nube HDFS plus nativa de EMR, que puede obtener una mayor flexibilidad y puede expandir la capacidad del disco en cualquier momento según sea necesario.
3. Mediante el uso de COS de almacenamiento de objetos, esta solución puede permitir a los clientes lograr una alta disponibilidad de datos mientras solo guardan una copia, lo que ahorra costos de almacenamiento de datos, pero debido al cambio de lectura local a lectura en red, se sacrificará algo de lectura y escritura. y rendimiento de rendimiento.
Antes de elegir un plan, primero veamos los precios de estos recursos:
Tabla 1 - Lista de precios de recursos
1) La existencia de todos los HDFS hará que el costo de EMR sea demasiado alto.
De acuerdo con las estadísticas del volumen de datos 1P, use almacenamiento HDFS, use D3 como DataNode y calcule de acuerdo con 3 copias (la tasa de falla del disco es 3/1000 por año, la configuración de menos de 3 copias puede tener el riesgo de pérdida de datos) , al menos 70 Un nodo cuesta alrededor de 457 600/mes; mientras que el almacenamiento estándar OFS cuesta alrededor de 123 700/mes, también puede usar la función de archivo para reducir aún más el costo, y la diferencia de costo entre los dos es más de 5 veces. Además, el uso extensivo de HDFS también hará que el clúster no sea fácil de escalar elásticamente. Los nodos de DataNode solo pueden estar fuera de línea por menos de 2 a la vez. El nodo fuera de línea también causará problemas como el reequilibrio, lo que afectará el negocio normal.
2) Utilice el almacenamiento de objetos (OFS) para lograr una separación completa de almacenamiento y cálculo
Debido a que cada cubo de almacenamiento de objetos tiene un límite de ancho de banda de red, que es de decenas de Gb/s, durante la ejecución de una gran cantidad de tareas simultáneas, afectará la eficiencia de la ejecución de tareas de datos.Con DataNode, el ancho de banda de cada nodo de máquina es de 10 Gb/s, el ancho de banda acumulativo de docenas de máquinas es de cientos de Gb/s.
3) Separación de almacenamiento y cálculo de Hadoop y OFS
Después de analizar en profundidad la arquitectura de datos y la lógica comercial actuales de Sohu Smart Media con Tencent Cloud, nos basamos en la arquitectura popular actual de la industria y diseñamos conjuntamente una arquitectura de separación de almacenamiento e informática que combina Hadoop y el almacenamiento de objetos. En la estructura de datos de Sohu Smart Media, el efecto temporal de los datos fuera de línea es muy evidente. Cuanto más cerca esté el ciclo de vida de los datos, mayor será la frecuencia de uso. Una gran cantidad de tareas fuera de línea durante la noche calculan principalmente los datos del día. Por lo tanto, dividimos los datos en calientes y fríos en función de una semana. Los datos fríos de hace una semana se asientan en el almacenamiento de objetos (OFS) para reducir los costos de almacenamiento; los datos calientes de la última semana se almacenan en HDFS para garantizar el eficiencia de las tareas de datos. Dado que Hadoop ya no almacena una gran cantidad de datos, podemos comprimir al límite la cantidad de recursos de la máquina HDFS DataNode y desplegar recursos informáticos YARN en los nodos D3 y SA3, entre los cuales SA3 realiza un escalado elástico según el tiempo o los requisitos informáticos, lo que reduce considerablemente los costes informáticos y garantiza la eficacia. Los datos en HDFS incluyen no solo los datos generados regularmente por las tareas diarias de datos fuera de línea, sino también los datos históricos generados por medio de datos complementarios, que pueden acumular una gran cantidad de datos en un corto período de tiempo. Los datos a OFS deben hacerse de manera oportuna y eficiente. Fiable, y no puede afectar el clúster todavía.
Figura 7 - Diagrama de arquitectura de tecnología de alta disponibilidad de migración de datos de separación de cálculo y almacenamiento
Arquitectura de tecnología de alta disponibilidad de migración de datos con separación de almacenamiento y computación Como se muestra en la figura anterior, la función de migración está diseñada en la plataforma de administración de datos fuera de línea mencionada anteriormente y se implementa en base a la arquitectura de programación de tareas distribuidas de Quartz. Ejecute el trabajo del distribuidor en Quartz. A través de la arquitectura de alta disponibilidad de Quartz, se puede garantizar que el trabajo del distribuidor se ejecutará todo el tiempo. El trabajo del distribuidor obtendrá los metadatos de HIVE en tiempo real y juzgará si la ubicación corresponde a la partición hace una semana. particionado por fecha está en OFS, si no está en OFS, la información de la tabla se coloca en la cola de programación de tareas. Para controlar el impacto de las tareas de migración de datos en la carga del sistema, el sistema solo configura 10 trabajos de trabajador para ejecutar tareas de migración de datos. Cuando se ejecuta un trabajo de trabajador, el distribuidor creará un nuevo trabajo de trabajador en Quartz para la migración de datos. Estos Los trabajos de los trabajadores se distribuyen uniformemente a cada nodo por Quartz. Dentro de cada Worker Job, los datos se migrarán de HDFS a OFS, la información de metadatos como Hive e Impala se actualizará y, finalmente, se eliminarán los datos en HDFS. El efecto práctico de la separación de almacenamiento y cálculo:
1) El uso del espacio de almacenamiento de todo el clúster HDFS se puede controlar en aproximadamente un 65 %, como se muestra en la siguiente figura. Ahorre en gran medida la sobrecarga de almacenamiento de HDFS causada por el crecimiento de los datos comerciales.
Figura 8: gráfico de tendencias de la capacidad de almacenamiento HDFS de Tencent Cloud EMR en los últimos 7 días
2) El clúster de EMR fuera de línea escala y se expande elásticamente según el tiempo. 2/3 de los recursos totales se extraerán a las 12:00 de la mañana todos los días, y estos recursos se liberarán después de las 6:00 de la mañana. En esta etapa, la tasa de utilización de Vcore está básicamente por encima del 90 %, como se muestra en la siguiente figura; durante el día y la noche, solo se reserva 1/3 del total de recursos. Se puede ver que la tasa de uso de recursos de esta parte se mantiene en torno al 60%, y hay algunos picos de uso en puntos de corta duración.
Figura 9: Gráfico de tendencia de YARN Vcores del clúster EMR de Tencent Cloud en los últimos 7 días
2.3.2 Gestión de costes
En términos de costo, Tencent Cloud EMR actualmente solo proporciona el costo de todo el clúster y no puede ver el costo de una sola tarea. Por otro lado, esperamos poder realizar una gestión detallada de los costos, recopilar información de recursos de tareas ejecutada por una persona y luego contar la información de recursos utilizada por individuos y equipos. En respuesta a este requisito, recopilamos datos relevantes y utilizamos StarRocks para el análisis estadístico de los datos. La recogida de datos se divide en dos partes:
Parte de ella se recopila de YARN. La API de aplicaciones de clúster proporcionada por YARN incluye campos como ID, MB asignados y VCores asignados. Como se muestra en la siguiente figura, utilice una tarea programada para recopilar datos cada 5 segundos y escribir los datos en Kafka.
Figura 10: Introducción a los parámetros relacionados proporcionados por la API de aplicaciones de clúster proporcionada por YARN
La otra parte de los datos se basa en la plataforma de gestión de datos fuera de línea. Dado que la Solicitud en YARN se envía desde la plataforma de gestión de datos fuera de línea, corresponde a un Trabajo en la plataforma de gestión. Como se muestra en la figura a continuación, la plataforma de administración recopilará la información de registro impresa por clientes como HIVE/Spark, obtendrá la identificación de la aplicación y escribirá la identificación de la aplicación y la identificación del trabajo asociado en Kafka. Vale la pena señalar que si se trata de una tarea HIVE, una ID de trabajo puede estar asociada con varias ID de aplicación.
Figura 11 - Diagrama esquemático de la interacción entre la plataforma de datos fuera de línea y EMR YARN
En StarRocks, se establecerán dos tareas Routie Load para consumir datos en Kafka, y se creará una tabla MySQL para obtener información como el ID y Author del trabajo de la plataforma de datos. ", confiando en el poderoso poder de cómputo de StarRocks, los datos de las tres fuentes de datos se asocian, se agregan y se realizan otras operaciones para varios análisis, como estadísticas sobre qué usuario usa la mayoría de los recursos de Vcore dentro de un cierto período de tiempo.
2.4 El efecto de migrar a la nube
1. En términos de reducción de costos:
1) Comparado con el costo total de Hadoop bajo la nube, el control de costos de big data en la nube ha logrado resultados satisfactorios;
2) La gestión de gastos es más clara, puede ser precisa para el equipo, las tareas individuales e individuales y controlar las necesidades informáticas innecesarias;
3) Más métodos de control de costos, como el escalado elástico EMR, el archivo COS/OFS y otras funciones, mejoran continuamente el control de costos.
2. Mejora de la eficiencia:
1) La ejecución de una sola tarea de datos en la nube es más rápida que en la nube. Hadoop en la nube se comparte principalmente entre varios departamentos. La tasa de utilización de recursos se ha mantenido en un nivel alto y las tareas tienen un gran influenciarse unos a otros;
2) La tasa de cumplimiento de línea de base diaria se ha mejorado significativamente y las tareas de datos se pueden completar antes de ir a trabajar, lo que mejora la eficiencia del uso de datos;
3) Respuesta ágil a los requisitos de expansión de recursos Cuando hay una gran demanda de cómputo, los recursos se pueden expandir rápidamente para satisfacer la demanda de cómputo;
4) El soporte técnico es más poderoso y Tencent Cloud movilizará recursos de varios aspectos para resolver varios problemas.
Planificación posterior
Continuaremos practicando en el camino de la reducción de costos y el aumento de la eficiencia, y continuaremos construyendo junto con Tencent Cloud.
1. En términos de reducción de costos:
1) habilitar el archivo OFS y el archivo profundo, y desarrollar funciones de recuperación de apoyo para reducir los costos de almacenamiento de datos cada vez mayores;
2) Pruebe la versión de contenedor EMR, y la demanda de recursos informáticos se puede escalar de acuerdo con la carga para lograr una elasticidad completa;
3) Intente utilizar productos PAAS/SAAS alojados para reducir los costos de operación y mantenimiento.
2. Mejora de la eficiencia:
1) Usar StarRocks para reemplazar Impala/Presto como una entrada unificada para el análisis interactivo. StarRocks tiene funciones como vectorización y CBO, y su rendimiento tiene ventajas obvias sobre Impala/Presto;
2) Utilice varios cubos OFS para mejorar el rendimiento general del ancho de banda y mejorar la eficiencia del uso de datos;
3) Intente utilizar las nuevas tecnologías de la industria, como lagos de datos y otros productos, para mejorar la eficiencia general del desarrollo de datos.