[MÚSICA] [MÚSICA] Hola, vamos a proseguir a continuación con el preproceso de los datos, tras una primera inspección donde vimos cómo estaba configurada la base de datos y un pequeño análisis exploratorio de las variables que contenía. El paso que necesitamos llevar a cabo es el del preproceso, con el objetivo de validar los datos y revisar posibles inconsistencias, valores anómalos y datos faltantes. Hay una segunda etapa de preproceso que la veremos posteriormente, dedicada a la creación de nuevas variables. Para empezar, la primera tarea consiste en capturar los datos de nuevo. Los datos provienen de esta base de datos CCV. Mediante esta librería podemos inferir el esquema, de forma que la lectura es automática. La primera etapa de lectura requería un filtro de las columnas, identificando las columnas de interés para el objetivo. Y a continuación un filtro de las filas, de los datos para facilitar la gestión de la misma, es decir, que tenga un volumen un poco más reducido para desde una perspectiva didáctica, la ejecución de los procesos sea más ágil. La base de datos transformada BD2 la registrábamos como tabla para poder aplicar operaciones mediante sintaxis de CQL. La etapa de validación empieza revisando valores anómalos. Para la variable retraso, r delay esto se puede llevar a cabo empleando la función describe y obteniendo los índices de resumen clásicos, recuento, mediana, desviación estándar, mínimo, máximo. Aquí vemos pues que el valor más elevado es 2028, esto podría ser considerado un valor anómalo. Para aplicar esta misma metodología con el resto de variables de una forma más estructurada y exhaustiva, aplicamos la función a todas las variables generando este resultado, este resultado es un poco, un poco díficil de leer por una cuestión de tipo de letra y formato de spark. Es quizás más práctico transformar la base de datos a pandas, bases de datos de Python y llevar a cabo una pequeña operación de trasposición para poder visualizar la información de una forma un poco más agradable. Aquí vemos las distintas variables y los distintos índices de resumen pertinentes, donde podemos comprobar valores máximo y mínimo para identificar a valores anómalos. Y finalmente también, recuento de casos válidos para identificar potenciales, incidencias en relación a datos faltantes. Vemos aquí estas cuatro variables con un número de datos faltantes considerable, la variable retraso con un pequeño número de datos faltantes. Las inconsistencias las podemos revisar llevando a cabo consultas muy específicas. Por ejemplo podríamos plantearnos hasta que punto las variables origen y destino, para las variables origen y destino la columna distancia es coherente. Es decir, hasta que punto todos los vuelos con el mismo origen y el mismo destino tienen identificada la misma distancia. Este análisis de posibles inconsistencias requiere no el promedio como está aquí planteado. Más bien aquí la idea sería describir estas distancias, sino otras herramientas, como la diferencia entre el mínimo y el máximo para constatar que el valor es constante o bien la desviación estándar con el mismo objetivo. Por una cuestión numérica, algunos cálculos en particular de la desviación estándar pueden dar lugar a valores aparentemente extraños. Estos dos valores, estos dos valores no son cinco ni uno, sino que son valores extremadamente pequeños. Aquí simplemente esto está recortado falta la notación científica asociada al valor. Esto se puede acabar de visualizar, llevando a cabo exactamente la misma consulta y exportando, transformando la base de datos a base de datos de Python, en formato pandas. En particular aquí vemos los valores mencionados y podemos comprobar que efectivamente son valores que esencialmente son cero. Simplemente por una cuestión numérica, los valores se representaban anteriormente de forma truncada. Seguidamente, tras validar la variable distancia podemos proseguir con la identificación de valores faltantes y la eliminación o bien imputación de otros valores para completar la información no recogida. Para las variables r delay y d delay que vemos, es que sí hay algunos casos con información faltante. Podemos proseguir e intentar identificar su causa describiendo bueno, inicialmente, contando exactamente el número de casos faltantes. Aquí veremos las operaciones pertinentes. Fijaros que aquí hay una función drop NA muy interesante, que permite eliminar de la base de datos los casos con datos faltantes directamente serían eliminados. Por lo tanto, el recuento de la base de datos tras eliminar los datos faltantes y el recuento de la base de datos sin esta operación, da lugar al número exacto de datos faltantes. Los datos faltantes asociados al retraso podrían ser atribuibles al hecho de que los vuelos en realidad fueran o bien cancelados o bien desviados. Vamos a contar el número de casos con estas propiedades mediante la función zoom, puesto que estas variables cancelled y diverted, son variables indicadores cuyos valores son simplemente cero y uno. Por tanto, la suma de esas columnas da lugar al número de vuelos que fueron o bien cancelados o bien desviados. El número total de vuelos con estas propiedades coincide con el número de casos con retraso faltante. Por lo tanto, podría ser pertinente aquí proceder filtrando, por lo tanto, eliminando los vuelos con que fueron cancelados y desviados puesto que el campo retraso no es pertinente. Tras esta operación, lo que vemos es que ahora todas estas variables contiene el mismo número de casos válidos. No obstante, las variables asociadas a las razones del retraso, continúan mostrando número de casos faltantes muy elevado. Para identificar si existe alguna relación con otras variables, identificar las causas, podemos mostrar algunos casos que no tuvieron retraso, con retraso negativo. Este pequeño, esta pequeña muestra de casos nos permite comprobar que no de forma exhaustiva, pero sí para estos casos mostrados. Cuando el retraso es negativo, todos los campos asociados a los tiempos atribuibles a cada una de las causas, son efectivamente nulos. Podríamos proceder inspeccionando lo mismo, para los casos que sí tuvieron retraso efectivo. Es la misma consulta pero modificando el filtro. Aquí lo que vemos es que incluso con retraso positivo, hay casos con valores nulos. Vemos que para el caso, para un caso particular con catorce minutos de retraso los datos continúan siendo nulos. No obstante, un caso con retraso de dieciséis minutos you no tiene estas limitaciones. Podría ser, podría ser y lo vamos a comprobar que el punto de corte que generen datos faltantes sean exactamente quince, con valores exactamente quince no hay datos faltantes. Con valores más grandes o iguales de quince lo que tenemos es un recuento de casos equivalente e igual al número de casos válidos, perdón. El número de casos válidos de las variables asociadas al motivo. Por lo tanto, aquí tendríamos la sugerencia solo hay datos faltantes o bien hay datos faltantes cuando el retraso es menor de quince minutos. De esta forma, puede ser coherente asignar a los valores faltantes, simplemente un valor cero indicando que no hay retraso efectivo. La forma de proceder es mediante la función NA fill, reemplazar datos faltantes mediante estos valores predeterminados. Tras esta operación, llevamos a cabo la función de descripción y visualizamos el resultado en, habiendo transformado la base de datos a Python. Lo que vemos es que ahora mismo, todas las columnas tienen exactamente el número de casos válidos. Aquí terminaría, simplemente un ejemplo de cómo proceder con la validación de los datos, esta etapa de validación puede ser de nuevo muy, muy compleja y puede llevar una carga de trabajo muy relevante. Hemos visto las operaciones necesarias para pulir la base de datos, pero en bases de datos más complejas, éstas operaciones también pueden ser mucho más costosas. Hasta aquí la sesión dedicada al preproceso. [MÚSICA] [AUDIO EN BLANCO]
