El análisis de datos a menudo se organiza así: aquí tenemos los desarrolladores del repositorio, y aquí tenemos los analistas. En DWH (almacenamiento de datos, almacenamiento) pueden SQL, y nuestros analistas pueden trabajar con Excel. Si necesitamos analizar algo, entonces diríjase a los analistas, y ellos van a buscar datos a DWH. Parece ser lógico. Y muchos perciben que esta es una división normal del trabajo. En este artículo quiero transmitir la idea de que esta división del trabajo es errónea y reduce drásticamente la eficiencia y la productividad de todo el proceso de análisis de datos.
Un ciclo de trabajo típico en un problema analítico se ve así:
- Una empresa presenta un problema y pide una respuesta.
- Los analistas están discutiendo con las empresas lo que hay que hacer.
- Los analistas se dieron cuenta de que quieren negocios de ellos y entienden lo que más o menos necesitan en los datos.
- Los analistas escriben una consulta en DWH para obtener los datos.
- DWH toma una solicitud, lee, pregunta, aclara, recupera datos, da.
- Los analistas entienden que no tomaron todo o los malinterpretaron, escriben nuevamente la solicitud en DWH para obtener los datos.
- DWH toma una solicitud, lee, pregunta, aclara, recupera datos, da.
- Los analistas entienden que no tomaron todo o los malinterpretaron, escriben nuevamente la solicitud en DWH para obtener los datos.
- Repita los pasos 7 y 8.
Una vez, los chicos de DWH dicen que no pueden dar datos o que no están listos para procesar tantas solicitudes de analistas. En respuesta, los analistas comienzan a acumular sus datos lejos de DWH en algún tipo de excelencia. Allí comienzan a recopilar sus procesos ETL, como pueden, en función de lo que pueden obtener de DWH "sin luchar".
¿Qué tenemos como resultado?
- DWH no cubre adecuadamente las necesidades de los consumidores (bueno, por parte de DWH, parece que los usuarios no saben lo que quieren).
- Los analistas comienzan a escribir procesos ETL incorrectos y a crear pseudo DWH de acuerdo con su volumen de datos, pero sin reserva, control de acceso, bajo rendimiento, etc.
- La interacción de DWH y analistas sufre porque A uno no le importan mucho los negocios, y el segundo no entiende como el "lenguaje de los pájaros".
- El proceso de obtener una respuesta a una pregunta comercial se retrasa, porque ahora el proceso de procesamiento de datos es un montón de trabajo manual fuera de DWH. ¿Y por qué creamos DWH, a excepción de un único repositorio?
- Cambios menores en la declaración del problema por parte de la empresa comienzan el ciclo de análisis de datos desde casi cero, porque DWH nuevamente no mostrará flexibilidad, y los analistas no tendrán datos en un nuevo contexto.
¿Cuál podría ser la solución? Si desea deshacerse del problema de interacción entre DWH y los analistas, debe acercar las competencias de DWH y los analistas. Una persona que combina estas competencias puede llamarse analista de datos.
¿Qué debería hacer un analista de datos de pila completa?
- Trabaja con fuentes de datos sin procesar, comprende cómo funciona el almacenamiento de datos.
- Para formular lo que debe cambiarse en el repositorio en términos de contenido de datos, qué datos agregar y cómo procesarlos metodológicamente para que los desarrolladores de DWH puedan implementarlos.
- Comprenda las necesidades del negocio, discuta los requisitos y ayude a su cliente, interno o externo, a formular un problema y una solución.
- Ser capaz de diseñar una solución analítica, es decir comprender cómo resolver el problema, qué datos se necesitan, qué se debe "inventar", qué suposiciones se deben hacer
- Poder visualizar sus resultados e informar a sus clientes (internos o externos)
- Para poder hacer un estudio "reproducible", este es un análisis que siempre se puede repetir con los mismos datos y obtener el mismo resultado. Para hacer esto, debe poder trabajar con R / python o sistemas que le permitan formalizar el proceso de análisis.
Si combina competencias técnicas y analíticas en una analítica, entonces obtiene un empleado verdaderamente integral que puede resolver el problema de extremo a extremo. Y esto es muy importante para las tareas analíticas, ya que solo este analista comprende lo que está haciendo y por qué. La división entre los que "analizan" y los que "procesan los datos" lleva al hecho de que cada uno de estos empleados está discapacitado: el analista no tiene manos, porque no puede obtener y procesar nada a escala, y el ingeniero de datos está "sin cerebro", por así decirlo. No piensa cómo se usará y qué hipótesis hay.
La división del trabajo es muy importante, pero debe tener lugar en un plano ligeramente diferente. El analista debe poder obtener todo lo que necesita para el análisis, y la tarea del ingeniero de datos es construir sistemas que proporcionen datos de manera efectiva en cualquier posible sección de interés para el analista. Para Data Engineer, esto significa que los datos deben almacenarse en una forma bastante flexible, pero al mismo tiempo en una forma conveniente para su uso: parcialmente desnormalizado, parcialmente con acceso a través de cubos, parcialmente previamente agregado y calculado.
Y si no puede encontrar el Full Stack Analyst por sí mismo, al menos incluya Data Engeneer en el equipo de análisis para que la competencia en el trabajo con datos no se transfiera del análisis a un servicio externo.
No es asunto del analista de datos apoyar la recuperación de datos de la API de Google AdWords, pero no es asunto de Data Engeneer escribir una selección para obtener datos sobre los ingresos del último mes.