Руководство пользователя по self-service анализу данных

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

Рекомендации по источникам данных

Базовые источники данных

Основные рекомендации:

Database Table. Скорость работы дашборда напрямую связана со скоростью работы базы данных (БД). Если расчет агрегированных значений на стороне БД занимает более 5 секунд, рекомендуется оптимизировать БД перед ее интеграцией в качестве источника данных на стороне FineBI.
SQL Dataset. Неоптимальные или сложные SQL-запросы, обработка которых занимает много времени, могут стать причиной потери производительности. Рекомендуется ограничивать сложность SQL-запросов тремя уровнями операций объединения. Например, тремя LEFT/RIGHT JOIN или UNION объединениями.

FineBI версии 6.0.10 и более поздней располагает модулем мониторинга производительности SQL (BI Tools > Update Information > SQL Performance Monitoring), где содержится более детальная информация, например, о времени выполнения запроса.

Excel Dataset. При работе с источниками данных, загруженными из Excel файлов, рекомендуется обеспечивать объем данных на одном листе файла, не превышающий 1 миллион ячеек (строки * столбцы). Для соблюдения данной рекомендации следует оставлять только те данные, которые необходимы для анализа, и удалять избыточные и несущественные.

Рекомендации по работе с данными в режиме Spider (выгрузка данных)

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

Процесс обновления данных можно оптимизировать. Например, если у родительской таблицы есть множество дочерних и не все они нуждаются в частом обновлении, можно использовать опцию Do not follow the parent table update и настроить режим менее частых регулярных обновлений для этих дочерних таблиц. Это позволит родительской таблице обновляться с меньшим объемом данных и сократит время, необходимое для обновления данных в системе.
Даже если требования к актуальности данных высоки, рекомендуется устанавливать максимально возможный интервал времени между обновлениями одной и той же задачи. Если объем данных относительно невелик, то такие источники можно обновлять один раз в два часа (но, желательно, не более 10 раз в день). Если объем данных значительный, то стоит их обновлять один раз в несколько часов или же настроить обновление с определенной частотой - одно обновление днем и одно ночью.
Убедитесь в отсутствии дубликатов в данных, перед тем как настраивать объединение источников/связи между данными или обновление источников.
Рекомендуется сократить создание несущественных связей в результирующем наборе данных и добавлять в него только те столбцы, которые действительно необходимы для анализа.
Если объем базовых данных для анализа большой, то стоит помнить, что на этапе создания Analysis subject, FineBI предварительно обработает весь массив данных, но на этапе предобработки будет использовать только часть из них. При этом не стоит беспокоиться о потере точности данных на этапе проектирования, поскольку непосредственно визуализации на дашборде будут рассчитываться на основе полного набора данных.

Рекомендации по работе данным в режиме Direct (прямое подключение)

При работе с SQL Dataset в теле запроса избегайте использования операций SELECT * и старайтесь явно указывать названия столбцов для всех операций.
Старайтесь минимизировать использование функций агрегации в теле запроса в SQL Dataset, а также сведите к минимуму применение функций и арифметических операций в условиях WHERE.
Логику предрасчётов рекомендуется закладывать на стороне систем хранения данных/обрабатывать с использованием ETL инструментов. Например, если планируется использовать более трех LEFT/RIGHT JOIN объединений, более трех уровней вложенных запросов, если время обработки SQL-запроса превышает 5 секунд.
В отношении источников данных с высокой частотой использования, но с довольно низкой производительностью запросов, могут быть применены настройки кэширования на основе актуальности данных для сокращения количества запросов к БД и повышения производительности дашборда.

Политика кэширования в режиме прямого подключения:

Сценарий запроса записывается в кеш. В случае изменения условий запроса происходит обновление содержимого кэша.
Условия запроса не изменяются, но результат кеширования не актуален: общий объем кеша фиксирован, и может возникнуть ситуация, когда ранее закешированные данные будут удалены в цикле кэширования. Общий объем кэша: XMX JVM * 0,2, разделяется между Spider и Direct подключением.
Предобработка источников данных

Рекомендации по операциям с данными

Выбор полей. На этапе обработки источников данных во вкладке Data следует выбирать только те поля, которые требуются для дальнейшего анализа, и не рекомендуется выбирать все поля сразу, чтобы избежать чрезмерного использования ресурсов сервера и увеличения времени обработки данных.
Фильтрация. Там, где это необходимо, задайте фильтрации приоритет, чтобы не использовать в вычислениях весь набор данных.
Объединение данных. Количество LEFT/RIGHT JOIN объединений не должно превышать трех, источник данных должен быть предварительно отфильтрован до применения операций объединения. При использовании UNION операций не рекомендуется превышать размер результирующего набора данных более чем в 10 млн. строк.
Группировка данных (Group Summary). Прежде всего, рекомендуется отфильтровать данные (для уменьшения их объема), а только затем приступить к агрегации с группировкой по измерениям. Рекомендуемое количество полей для группировки - не более 10. Также стоит избегать превышения размера результирующего набора данных более чем в 10 млн. строк.
Обработка данных. У источников с довольно большим количеством этапов обработки данных может наблюдаться снижение производительности. Рекомендуемое вендором количество этапов - не более 15. Если данное ограничение не удовлетворяет требованиям анализа, перенести обработку данных на сторону ETL инструмента/систему хранения данных.