Уловки SQL для специалистов по данным - проверка качества данных

Все специалисты по данным немного знают SQL, но его можно использовать не только для извлечения данных в «настоящую» среду анализа.

В некотором смысле SQL - это забытый секрет науки о данных, воспринимаемый как само собой разумеющееся как необходимое, но немного не крутое средство получения данных из баз данных, в которых он часто находится, без кеша Pandas или тидиверсии.

В некотором смысле это тоже справедливо, поскольку набор функций, предлагаемых в большинстве реализаций SQL, имел тенденцию не соответствовать потребностям того, кто занимается подготовкой данных, помимо необходимости объединять таблицы и применять фильтры для уменьшения объема данных. для переноса в среду, в которой будет выполняться собственно анализ - обычно в R или Python.

Книги по SQL усугубляют проблему, поскольку трудно найти книги, которые выходят далеко за пределы основного диапазона простых операторов SELECT и объединений, возможно, приправленных некоторыми агрегатными функциями.

Тем не менее, многие из них регулярно используют SQL, потому что данные, которые мы используем, находятся в базе данных, совместимой с SQL, и если мы хотим что-то с ними сделать, нам нужно написать запрос, и если мы собираемся написать запрос, мы можем как хорошо делать это правильно.

Точно так же, учитывая, что для многих анализов первым шагом является перемещение группы данных в R или Python, мы могли бы сделать это правильно - по крайней мере, мы могли бы попытаться переместить самую маленькую, но наиболее полезную таблицу данных, которую мы может. Следовательно, может быть полезен анализ, который устанавливает, насколько полезен каждый столбец и выделяет недостающие и экстремальные значения, которые могут привести к исключению этой строки или столбца из окончательной модели.

Кажется, что определение пропорций пропущенных значений в определенных столбцах должно быть доступно из коробки. Это не так, но все же может быть достигнуто с минимальными усилиями, хотя и с парой уловок.

SELECT CAST

(SUM (CASE WHEN column1 is NULL THEN 1 ELSE 0 END)

as float) / COUNT(*) AS ProportionMissing

FROM YourDB.YourTable

Фактически мы реализуем эквивалент СУММЕСЛИ в Excel с помощью оператора CASE. Очевидно, нам нужно использовать CAST для плавания, потому что SUM возвращает целое число, и если мы забудем CAST, запрос вернет 0 почти во всех случаях.

Суть этого запроса в том, что если степень отсутствия в каком-либо конкретном столбце означает, что столбец бесполезен, перенос столбца в среду моделирования - пустая трата времени.

Еще одна базовая проверка качества данных - поиск крайностей. Очевидно, что в SQL есть функции MAX () и MIN (), но также может быть полезно пойти немного дальше и изучить несколько крайних переменных. Достаточно распространенный способ обнаружения экстремальных значений - это поиск значений, которые представляют собой чрезмерное количество стандартных отклонений от среднего - 4 стандартных отклонения используются в качестве эталона ниже.

WITH STATS (Col1_AVG,Col1_SD) AS
    (SELECT STDEV(Col1),AVG(Col1)
    FROM Db1.Tbl1)
 
 SELECT Col1,DWT_AVG,DWT FROM STATS JOIN Tbl1
 ON 1=1
 WHERE ABS(Col1-Col1_AVG)/Col1_SD > 4

Мы используем обычное табличное выражение (раздел, начинающийся с ключевого слова «WITH»), потому что мы собираемся сравнить результаты агрегатных функций со значениями, на которых они основаны. Приведенная выше версия возвращает сами экстремальные значения, чтобы их можно было изучить на предмет обоснованности (когда данные собирались вручную, крайние значения нередко возникали из ошибок транскрипции), но изменение знака больше чем на противоположное, очевидно, просто сокращает значения.

Последней предыдущей статьей Роберта де Граафа для Medium была Объяснимость: последняя миля.

Он также является автором готовящейся к выходу книги Apress Управление проектами в области науки о данных

Следуйте за ним в Twitter: https://twitter.com/RobertdeGraaf2