Encontré lo siguiente en un artículo, enlace para el artículo completo: https://www.linkedin.com/pulse/b…
Arquitectura de análisis de datos adoptada por Facebook:
- ¿Debo usar un cursor o usar el paquete R directamente?
- ¿Cuál es el análisis de opinión en el caso de TripAdvisor? ¿Como funciona?
- ¿Cómo escribe Google las pruebas para su algoritmo de búsqueda para que sepan que no lo rompieron al hacer cambios?
- ¿Qué es el aprendizaje automático basado en modelos?
- Cómo optimizar el ANFIS de MATLAB usando el método de descenso de gradiente conjugado
Facebook recopila datos de dos fuentes. El nivel federado de MySQL contiene datos de usuario y los servidores web generan datos de registro basados en eventos. Los datos de los servidores web se recopilan en los servidores Scribe, que se ejecutan en clústeres de Hadoop. Los servidores Scribe agregan datos de registro, que se escriben en Hadoop Distributed File System (HDFS). Los datos HDFS se comprimen periódicamente y se transfieren a clústeres de producción Hive-Hadoop para su posterior procesamiento. Los datos del MySQL federado se vuelcan, comprimen y transfieren al clúster de producción Hive-Hadoop. Facebook usa dos grupos diferentes para el análisis de datos. Los trabajos con plazos estrictos se ejecutan en el clúster Production Hive-Hadoop. Los trabajos de menor prioridad y los trabajos de análisis ad hoc se ejecutan en el clúster Ad hoc Hive-Hadoop. Los datos se replican desde el clúster de producción al clúster ad hoc. Los resultados del análisis de datos se guardan nuevamente en el clúster Hive-Hadoop o en el nivel MySQL para los usuarios de Facebook. Las consultas de análisis ad hoc se especifican con una interfaz gráfica de usuario (HiPal) o con una interfaz de línea de comandos de Hive (CLI de Hive). Facebook utiliza un marco de Python para la ejecución (Databee) y la programación de trabajos por lotes periódicos en el clúster de producción. Facebook también utiliza las herramientas de Microstrategy Business Intelligence (BI) para el análisis dimensional.
Arquitectura de análisis de datos adoptada por LinkedIn:
Los datos se recopilan de dos fuentes: instantáneas de la base de datos y datos de actividad de los usuarios de LinkedIn. Los datos de actividad comprenden eventos de transmisión, que se recopilan en función del uso de los servicios de LinkedIn. Kafka es un sistema de mensajería distribuido, que se utiliza para recopilar los eventos de transmisión. Los productores de Kafka informan los eventos a los temas en un corredor de Kafka, y los consumidores de Kafka leen los datos a su propio ritmo. Los datos del evento de Kafka se transfieren al clúster ETL de Hadoop para su posterior procesamiento (combinación, desduplicación). Los datos del clúster ETL de Hadoop se copian en clústeres de producción y desarrollo. Azkaban se utiliza como un planificador de carga de trabajo, que admite un conjunto diverso de trabajos. Se ejecuta una instancia de Azkaban en cada uno de los entornos Hadoop. Las cargas de trabajo programadas de Azkaban se realizan como trabajos MapReduce, Pig, shell script o Hive. Por lo general, las cargas de trabajo se experimentan en el clúster de desarrollo y se transfieren al clúster de producción después de una revisión y prueba exitosas. Los resultados del análisis en el entorno de producción se transfieren a una base de datos de depuración fuera de línea oa una base de datos en línea. Los resultados también pueden retroalimentarse al grupo de Kafka. Avatara se utiliza para la preparación de datos OLAP. Los datos analizados se leen de la base de datos de Voldemort, se procesan previamente y se agregan / cubifican para OLAP, y se guardan en otra base de datos de solo lectura de Voldemort.
Arquitectura de análisis de datos adoptada por Twitter:
En la infraestructura de Twitter para servicios en tiempo real, un Blender corre todas las solicitudes que llegan a Twitter. Las solicitudes incluyen la búsqueda de tweets o cuentas de usuario a través de un servicio QueryHose. Los tweets se ingresan a través de un servicio FireHose a una tubería de ingestión para la tokenización y la anotación. Posteriormente, los tweets procesados ingresan a los servidores EarlyBird para el filtrado, la personalización y la indexación invertida. Los servidores EarlyBird también atienden solicitudes entrantes de QueryHose / Blender. EarlyBird es un motor de recuperación en tiempo real, diseñado para proporcionar baja latencia y alto rendimiento para consultas de búsqueda.
Además, se implementan motores de asistencia de búsqueda. El recopilador de estadísticas en el motor de asistencia de búsqueda guarda estadísticas en tres almacenes en memoria, cuando se sirve una consulta o un tweet. Las sesiones de usuario se guardan en el almacén de Sesiones, las estadísticas sobre consultas individuales se guardan en el almacén de estadísticas de consultas y las estadísticas sobre pares de consultas concurrentes se guardan en el almacén de coincidencias de consultas. Un algoritmo de clasificación obtiene datos de los almacenes en memoria y analiza los datos. Los resultados del análisis persisten en Hadoop HDFS. Finalmente, el caché front-end sondea los resultados del análisis del HDFS y sirve a los usuarios de Twitter.
Twitter tiene tres fuentes de transmisión de datos (Tweets, Updater, consultas), de las cuales se extraen los datos. Tweets y consultas se transmiten a través de REST API en formato JSON. Por lo tanto, se pueden considerar como transmisión de datos semiestructurados. Se desconoce el formato de datos de Updater (fuente de datos de transmisión). La canalización de ingestión y Blender se pueden considerar como almacenes de datos temporales de Stream. La tokenización, la anotación, el filtrado y la personalización se modelan como procesamiento continuo. Los servidores EarlyBird contienen datos procesados basados en transmisión (Almacén de datos de transmisión). El recopilador de estadísticas se modela como procesamiento de flujo. Los almacenes estadísticos pueden considerarse almacenes de datos de Stream, que almacenan información estructurada de datos procesados. El algoritmo de clasificación realiza la funcionalidad de análisis de flujo. Hadoop HDFS que almacena los resultados del análisis se modela como un almacén de datos de análisis de Stream. El caché front-end (Servir almacén de datos) sirve a la aplicación de usuario final (aplicación de Twitter).
Referencia: Arquitectura de referencia y clasificación de tecnologías por Pekka Pääkkönen y Daniel Pakkala (la arquitectura de referencia de facebook, twitter y linkedin aquí mencionada se deriva de esta publicación)
Arquitectura de soluciones basada en la nube de AWS (Análisis ClickStream):
