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

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

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

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

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

Поиск и обработка дублирующихся записей.
Выявление и работа с пустыми значениями (NULL).
Проверка однородности и корректности заполнения полей (например, лишние символы).
Обнаружение и анализ аномалий и статистических выбросов.

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

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

Традиционно разведочный анализ выполняется в специализированных средах. Однако многие задачи первичной проверки и очистки данных можно эффективно решать непосредственно в AW BI.

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

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

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

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

Для демонстрации используем данные сети книжных магазинов. Информация о книгах хранится в таблице books со следующими полями:

product_id — уникальный идентификатор книги.
title — название книги.
author — автор.
genre — жанр.
purchase_price — закупочная цена.
quantity_in_stock — количество на складе.

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

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

Типы данных

Соответствие типов данных их смысловому назначению можно проверить прямо в модели на вкладке «Описание столбцов».

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

Чтобы узнать общее число записей в таблице, в модели используйте кнопку «Обновить количество записей».

После короткого ожидания система отобразит итог.

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

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

Рассмотрим 5 типов некорректных данных:

дубли,
NULL-значения,
неоднородность записи,
аномалии,
выбросы.

Для каждого типа покажем методы поиска и варианты решения.

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

Приведенные решения не являются единственно возможными и могут адаптироваться под ваши задачи.

Дубли

Поиск дублей

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

Создайте виджет типа «Таблица агрегатов».
Перенесите в группы виджета столбцы, по которым нужно искать повторы
В показатель добавьте поле с уникальным идентификатором (например, product_id) и выберите агрегацию «Количество».
Примените фильтр к столбцу с подсчетом как “> 1”

Решение

Чтобы получить только уникальные строки, используйте SQL-запрос с оператором DISTINCT:

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`

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

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

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

Пустые значения (NULL)

Поиск NULL-значений

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

В нашем примере обнаружились пропущенные значения в столбце авторов книг.

Обратите внимание
Иногда пустые значения представлены не как 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-фильтрации AW BI используют синтаксис библиотеки RE2. Подробнее можно узнать в → Документации RE2 от Microsoft.

Решение

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

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

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

Запрос для замены суффиксов на пустую строку:

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

Обратите внимание
При написании регулярных выражений в SQL-запросах в модели учитывайте особенности Spark SQL. Актуальный синтаксис описан в Документация regepx for Spark SQL

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

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

Аномалии - это значения, нарушающие бизнес-логику (например, отрицательное количество товара).
Выбросы - это статистически редкие значения, резко выделяющиеся на общем фоне (например, чрезмерно высокая цена).

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

Аномалии (На примере отрицательного количества)

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

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

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`

Выбросы (На примере закупочной цены)

Поиск: Для статистического поиска выбросов часто используют метод межквартильного размаха (IQR). Выбросами считаются значения, лежащие за пределами:

Нижняя граница = Q1 - 1.5 * IQR
Верхняя граница = Q3 + 1.5 * IQR
Где Q1 — первый квартиль (25-й перцентиль), Q3 — третий квартиль (75-й перцентиль), IQR = Q3 - Q1.

Следующий SQL-запрос находит выбросы в столбце 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-запросов и регулярных выражений.

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