Возможности для разведочного анализа в AW BI

o.v.kilina · 30.Январь.2026 09:32:26

Разведочный анализ - это

Разведочный анализ - процесс первичной проверки данных, в котором подготавливают информацию для дальнейшего анализа, очищая и преобразуя данные.

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

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

AW BI и разведочный анализ

Разведочный анализ данных обычно выполняется в специализированных программах и средах, включая Python, R, SAS и прочие инструменты для анализа данных, однако в данной статье будут рассматриваться варианты поиска и изменения условно неподходящих данных в виджетах и моделях, используя встроенную фильтрацию полей виджетов, SQL-фильтрацию и запросы на SQL к источнику, где мы рассмотрим начальные данные и проведем разведочный анализ, используя модели и виджеты AW BI.

В зависимости от задачи и типа найденной проблемы решение тоже не универсально, в статье будут рассматриваться различные варианты работы с проблемными данными.

Практика. Начальный этап

Практику рассмотрим на данных сети книжных магазинов, данные по книгам которой записаны в отдельную таблицу books с полями product_id (идентификатор книги), title (название), author (автор), genre (жанр), purchase_price (закупочная цена) и quantity (количество на складе).

В модели данные таблицы вынесены на схему drag-and-drop’ом и загружены в хранилище.

Проверка данных начинается с ознакомления с типами и количеством данных, с которыми в последующем придется работать.

Типы данных

Проверка типов данных на соответствие смысловой нагрузке можно сделать без использования кода на странице модели во вкладке “Описание столбцов”.

Количество данных

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

Таким образом мы выяснили, что всего в таблице 50 тысяч строк и типы данных в модели делятся на int64 и object.

Работа над данными

В данной статье мы рассмотрим 5 вариантов некорректности данных - дубли, null-значения, однородность записи, аномалии и выбросы. В каждом из вариантов будем рассматривать поиск и решение.

Заметка
Представленные решения в виде запросов данного раздела рекомендуется выполнять в модели в запросе к источнику:

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

Дубли

Поиск

В таблицах при случайных (или не очень) обстоятельствах могут появится идентичные записи. Для их обнаружения можно воспользоваться типом виджета Таблица агрегатов:

Вынести столбцы, по которым надо найти повторы, в группы виджета
Поле с идентификатора записи использовать для количества подсчета строк
Фильтровать столбец с подсчетом как “> 1”

Решение

Запрос, который позволяет вывести только уникальные строки:

SELECT DISTINCT
  title,
  genre,
  author,
  purchase_price,
  quantity_in_stock
FROM
  `books`

Заметка
В данном примере идентификатор продукта (product_id) автоинкрементируемый*, поэтому при запросах в разделе работы с дублями он не используется, т.к. он не повторяется из условий создания таблицы.

Вы также можете в проверку запроса включить и идентификатор, например,

SELECT DISTINCT
  product_id,
  title,
  genre,
  author,
  purchase_price,
  quantity_in_stock
FROM
  `books`

автоинкрементируемый - это

Автоинкрементируемый — это свойство столбца в базе данных, при котором каждому новому добавляемому элементу автоматически присваивается уникальное последовательное целое число. Оно увеличивается каждый раз при вставке новой записи, начиная с заранее определенного начального значения (чаще всего с 1).

!Важно
Выход из ситуации с дублями есть, НО! важно заметить, что запрос с конструкцией DISTINCT на больших объемах данных может потреблять значительные вычислительные ресурсы и занимать длительное время исполнения. Поэтому не рекомендуется использовать такой вариант решения работы с дублями, если работаете с большим объемом информации; лучше обратиться к ответственным сотрудникам, которые могли бы очистить данные в источнике.

NULL

Поиск

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

В виджете, применив встроенную фильтрацию, можно определить строки с пустыми значениями.

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

Заметка
При работе с данными пустые значения (null) могут являться пустыми строками, таким образом, вариант поиска пустых строк может измениться, например, на формулу в SQL-фильтрации:

[author] = ''

Решение

Строки с пустым заполнением могут помешать дальнейшему построению виджетов. Для того, чтобы избавиться от них в окне запроса к источнику можно вписать следующий код:

SELECT
  *
FROM
  `books`
WHERE
  author IS NOT NULL

, который позволит получить строки без пропущенных значений.

Заметка
При работе с данными пустые значения (null) могут являться пустыми строками (‘’), таким образом, вариант исключения пустых строк может поменяться на:

SELECT
  *
FROM
  `books`
WHERE
  author <> ''

Однородность данных

Поиск

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

Рассмотрим столбец genre (жанр), по логике в данном столбце могут содержаться только буквы, соответственно, можно создать регулярное выражение, которое бы означало поиск лишних символов и цифр, так мы сможем вычислить только неподходящие строки.

Screenshot_25

Регулярное выражение использует REGEXP_MATCH → документация для regexp_match.

Регулярное выражение получится таким:

REGEXP_MATCH([genre], '\d')
AND REGEXP_MATCH([genre], '[^a-zA-Zа-яА-Я0-9]')

, где
‘\d’ - выражение для поиска цифр,
‘[^a-zA-Zа-яА-Я0-9]’ - выражение для поиска символов.

Чтобы использовать выражение, воспользуемся SQL-фильтрацией:

Заметка
Регулярные выражения в SQL-фильтрации нужно писать с учетом синтаксиса и функционала встроенной библиотеки RE2, материал для ознакомления находится в документации по ссылке → Документация RE2 от Microsoft.

Решение

Есть простой подход к решению со строками с лишними символами, где мы меняем в обратную сторону логику запроса поиска ошибок на поиск только правильных, подходящих маске, строк:

SELECT
  *
FROM
  `books`
WHERE
  genre RLIKE '^[А-ЯЁа-яё\\d]+(\\s+[а-яё\\d]+)?$'

Таким образом мы получим таблицу, в которой просто будут исключены неподходящие значения.

Также есть вариант с исправлением таких строк. Если всмотреться в значения, можно увидеть повторяющиеся паттерны добавления символов в строки, это “_v2” и “-new”. Есть возможность очистить такие данные с помощью функции regexp_replace.

Запрос для получения всех данных с исправленным заполнением genre будет выглядеть следующим образом:

SELECT
  product_id,
  title,
  REGEXP_REPLACE(genre, '-new$|_v2$', '') AS genre,
  author,
  purchase_price,
  quantity_in_stock
FROM
  `books`

!Заметка

Регулярные выражения при работе с моделями нужно писать с учетом особенностей Spark SQL, материал для ознакомления находится в документации по ссылке → Документация regepx for Spark SQL

Аномалии и выбросы

Показатели, которые выбиваются логически из общего числа значений, являются аномалиями или выбросами.

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

Работа с аномалиями и выбросами должна проходить аккуратно, так как нужно проводить более подробную работу по поиску причин их появления.

Аномалии

Примером аномалии в нашем датасэте могут являться строки с отрицательным значением количества товара на складе. Найдем такие строки с помощью фильтрации поля:

Если количество строк не значительно для анализа и ими можно пренебречь, можно исключить такие строки в самой модели:

SELECT
  *
FROM
  `books`
WHERE
  quantity_in_stock >= 0

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

SUM_IF([purchase_price], [quantity_in_stock] >= 0)

, либо, возвращаясь к модели, можно заменить значения на 0 или null, используя следующий запрос:

SELECT
  product_id,
  title,
  author,
  genre,
  purchase_price,
  CASE
    WHEN quantity_in_stock < 0 THEN 0
    ELSE quantity_in_stock
  END AS quantity_in_stock
FROM
  `books`

Выбросы

Значения, которые можно охарактеризовать как выбросы, можно найти с помощью метода квартилей, который также можно написать с помощью SQL.

Метод квартилей - это эффективный и широко используемый способ поиска выбросов в данных. Выбросами считаются значения, находящиеся за пределами нижнего (25% от общего количества значений значений) и верхнего квартиля (75% от общего количества значений).

Для поиска выбросов в значениях для примера будет использоваться столбец с закупочной ценой (purchase_price). Запрос при обращении к источнику может быть таким:

WITH
  quartiles AS (
    SELECT
      PERCENTILE_CONT(0.25) WITHIN GROUP (
        ORDER BY
          purchase_price
      ) AS q1,
      PERCENTILE_CONT(0.75) WITHIN GROUP (
        ORDER BY
          purchase_price
      ) AS q3
    FROM
      `books`
  ),
  iqr AS (
    SELECT
      q3 - q1 AS interquartile_range
    FROM
      quartiles
  )
SELECT
  `books`.*
FROM
  `books`
  CROSS JOIN quartiles
  CROSS JOIN iqr
WHERE
  purchase_price < (Quartiles.q1 - 1.5 * iqr.interquartile_range)
  OR purchase_price > (Quartiles.q3 + 1.5 * iqr.interquartile_range)

Логика запроса

Сначала определяются границы среднего диапазона (центральная часть данных).
q1: первый квартиль (нижняя граница центральной части распределения). Это значение, ниже которого находятся 25% всех значений столбца purchase_price.
q3: третий квартиль (верхняя граница центральной части распределения). Это значение, выше которого находятся 25% всех значений столбца purchase_price.

Эти расчеты позволяют определить центральную часть данных («ядро») и потенциальные выбросы.

Затем рассчитывается межквартильный диапазон (разброс средней части данных).
Рассчитывается разница между третьим и первым квартилями (q3 - q1), известная как межквартильный диапазон (Interquartile Range, IQR).

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

Запись считается выбросом, если её значение сильно отличается от основного кластера данных (меньше нижней границы или больше верхней границы).

Этот этап выбирает строки таблицы books, значения поля purchase_price которых лежат вне границ нормального разброса данных:

Значение меньше первого квартиля минус полтора IQR (Q1 - 1.5*IQR)
Или больше третьего квартиля плюс полтора IQR (Q3 + 1.5*IQR)

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

Решения, основанные на неправильно интерпретированных данных, увеличивают вероятность дорогостоящих ошибок. Выбросы также могут мешать для дальнейшего анализа. Например, компания может выбрать поставщика с высоким уровнем неопределенности цен, полагаясь на показатели, включающие выбросы. Их можно также исключить с помощью следующего запроса:

WITH
  quartiles AS (
    SELECT
      PERCENTILE_CONT(0.25) WITHIN GROUP (
        ORDER BY
          purchase_price
      ) AS q1,
      PERCENTILE_CONT(0.75) WITHIN GROUP (
        ORDER BY
          purchase_price
      ) AS q3
    FROM
      `books`
  ),
  iqr AS (
    SELECT
      q3 - q1 AS interquartile_range
    FROM
      quartiles
  )
SELECT
  `books`.*,
  CASE
    WHEN purchase_price < (quartiles.q1 - 1.5 * iqr.interquartile_range)
    OR purchase_price > (quartiles.q3 + 1.5 * iqr.interquartile_range) THEN 1
    ELSE 0
  END AS is_outlier
FROM
  `books`
  CROSS JOIN quartiles
  CROSS JOIN iqr

Заключение

В данной статье были рассмотрены основные этапы разведывательного анализа данных с использованием инструментов AW BI : изучены методы выявления и обработки пяти ключевых видов некорректных данных: дублирования, пустых значений, неоднородности заполнения, аномалий и выбросов.

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

Подводя итоги, важно отметить, что качество исходных данных существенно влияет на точность результатов аналитики. Регулярный мониторинг и своевременная обработка отклонений позволят избежать ошибок и повысить надежность принимаемых решений. Внедрение рассмотренных методик в рабочий процесс обеспечит повышение эффективности анализа и создаст основу для принятия обоснованных управленческих решений.