Sprout Social es, en esencia, una empresa basada en datos. Sprout procesa miles de millones de mensajes de múltiples redes sociales todos los días. Debido a esto, los ingenieros de Sprout enfrentan un desafío único: cómo almacenar y actualizar varias versiones del mismo mensaje (es decir, retweets, comentarios, etc.) que ingresan a nuestra plataforma en un volumen muy alto.
Dado que almacenamos múltiples versiones de mensajes, los ingenieros de Sprout tienen la tarea de “recrear el mundo” varias veces al día, un proceso esencial que requiere iterar a través de todo el conjunto de datos para consolidar cada parte de un mensaje social en una “fuente de la verdad”.
Por ejemplo, realizar un seguimiento de los me gusta, comentarios y retweets de una sola publicación de Twitter. Históricamente, hemos confiado en los clústeres de Hadoop autogestionados para mantener y trabajar con grandes cantidades de datos. Cada clúster de Hadoop sería responsable de diferentes partes de la plataforma Sprout, una práctica en la que confía todo el equipo de ingeniería de Sprout para administrar proyectos de big data a escala.
Claves del enfoque de big data de Sprout
Nuestro ecosistema Hadoop dependía de Apache Hbase, una base de datos NoSQL escalable y distribuida. Lo que hace que Hbase sea crucial para nuestro enfoque sobre el procesamiento de big data es su capacidad no solo para realizar escaneos de rango rápido en conjuntos de datos completos, sino también para realizar búsquedas rápidas, aleatorias y de un solo registro.
Hbase también nos permite cargar datos de forma masiva y actualizar datos aleatorios para que podamos manejar más fácilmente los mensajes que llegan desordenados o con actualizaciones parciales, y otros desafíos que vienen con los datos de las redes sociales. Sin embargo, los clústeres de Hadoop autogestionados cargan a nuestros ingenieros de infraestructura con altos costos operativos, incluida la gestión manual de la recuperación ante desastres, la expansión del clúster y la gestión de nodos.
Para ayudar a reducir la cantidad de tiempo que implica administrar estos sistemas con cientos de terabytes de datos, los equipos de infraestructura y desarrollo de Sprout se unieron para encontrar una mejor solución que ejecutar clústeres de Hadoop autoadministrados. Nuestros objetivos eran:
- Permita que los ingenieros de Sprout construyan, administren y operen mejor grandes conjuntos de datos
- Minimice la inversión de tiempo de los ingenieros para poseer y mantener manualmente el sistema
- Reduzca los costos innecesarios del aprovisionamiento excesivo debido a la expansión del clúster
- Proporcionar mejores métodos de recuperación ante desastres y confiabilidad
A medida que evaluamos las alternativas a nuestro sistema de big data actual, nos esforzamos por encontrar una solución que se integrara fácilmente con nuestros patrones y procesamiento actuales, y que aliviara el trabajo operativo que conlleva la administración manual de un clúster.
Evaluación de nuevas alternativas de patrones de datos
Una de las soluciones que consideraron nuestros equipos fueron los almacenes de datos. Los almacenes de datos actúan como un almacén centralizado para el análisis y la agregación de datos, pero se asemejan más a las bases de datos relacionales tradicionales en comparación con Hbase. Sus datos están estructurados, filtrados y tienen un modelo de datos estricto (es decir, tener una sola fila para un solo objeto).
Para nuestro caso de uso de almacenamiento y procesamiento de mensajes sociales que tienen muchas versiones de un mensaje que coexisten, los almacenes de datos tenían un modelo ineficiente para nuestras necesidades. No pudimos adaptar nuestro modelo existente de manera efectiva a los almacenes de datos y el rendimiento fue mucho más lento de lo que esperábamos. Reformatear nuestros datos para adaptarlos al modelo de almacén de datos requeriría una gran sobrecarga para volver a trabajar en la línea de tiempo que teníamos.
Otra solución que analizamos fueron los lagos de datos. Los lagos de datos amplían los conceptos de almacenamiento de datos para permitir datos menos estructurados, un almacenamiento más económico y una capa adicional de seguridad en torno a los datos confidenciales. Si bien los lagos de datos ofrecían más de lo que podían ofrecer los almacenes de datos, no eran tan eficientes como nuestra solución Hbase actual. Al probar nuestro registro combinado y nuestros patrones de procesamiento de inserción y eliminación, no pudimos generar latencias de escritura aceptables para nuestros trabajos por lotes.
Reducción de gastos generales y mantenimiento con AWS EMR
Dado lo que aprendimos sobre el almacenamiento de datos y las soluciones Lakehouse, comenzamos a buscar herramientas alternativas que ejecutaran Hbase administrado. Si bien decidimos que nuestro uso actual de Hbase era efectivo para lo que hacemos en Sprout, nos preguntamos: “¿Cómo podemos ejecutar mejor Hbase para reducir nuestra carga operativa y al mismo tiempo mantener nuestros principales patrones de uso?”
Fue entonces cuando comenzamos a evaluar el servicio administrado Elastic Map Reduce (EMR) de Amazon para Hbase. La evaluación de EMR requería evaluar su rendimiento de la misma manera que probamos los almacenes de datos y los lagos, como probar la ingestión de datos para ver si podía cumplir con nuestros requisitos de rendimiento. También tuvimos que probar el almacenamiento de datos, la alta disponibilidad y la recuperación ante desastres para garantizar que EMR se adaptara a nuestras necesidades desde una perspectiva administrativa/de infraestructura.
Las funciones de EMR mejoraron nuestra solución autoadministrada actual y nos permitieron reutilizar nuestros patrones actuales para leer, escribir y ejecutar trabajos de la misma manera que lo hicimos con Hbase. Uno de los mayores beneficios de EMR es el uso del sistema de archivos EMR (EMRFS), que almacena datos en S3 en lugar de en los propios nodos.
Un desafío que encontramos fue que EMR tenía opciones limitadas de alta disponibilidad, lo que nos restringía a ejecutar múltiples nodos principales en una sola zona de disponibilidad, o un nodo principal en múltiples zonas de disponibilidad. Este riesgo se mitigó al aprovechar EMRFS, ya que proporcionó tolerancia adicional a fallas para la recuperación ante desastres y el desacoplamiento del almacenamiento de datos de las funciones informáticas. Al usar EMR como nuestra solución para Hbase, podemos mejorar nuestra escalabilidad y recuperación de fallas, y minimizar la intervención manual necesaria para mantener los clústeres. Finalmente, decidimos que EMR era la mejor opción para nuestras necesidades.
El proceso de migración se probó fácilmente de antemano y se ejecutó para migrar miles de millones de registros a los nuevos clústeres de EMR sin tiempo de inactividad del cliente. Los nuevos clústeres mostraron un rendimiento mejorado y costos reducidos en casi un 40 %. Para obtener más información sobre cómo el cambio a EMR ayudó a reducir los costos de infraestructura y mejorar nuestro rendimiento, consulte el caso de estudio de Sprout Social con AWS.
lo que aprendimos
El tamaño y el alcance de este proyecto nos dieron a nosotros, el equipo de ingeniería de confiabilidad de la base de datos de infraestructura, la oportunidad de trabajar de forma transversal con varios equipos de ingeniería. Si bien fue un desafío, resultó ser un ejemplo increíble de los proyectos a gran escala que podemos abordar en Sprout como una organización de ingeniería colaborativa. A través de este proyecto, nuestro equipo de Infraestructura obtuvo una comprensión más profunda de cómo se usan, almacenan y procesan los datos de Sprout, y estamos más equipados para ayudar a solucionar problemas futuros. Hemos creado una base de conocimientos común entre varios equipos que puede ayudarnos a crear la próxima generación de características para el cliente.
Si está interesado en lo que estamos construyendo, únase a nuestro equipo y solicite uno de nuestros puestos abiertos de ingeniería hoy.
Source link
