Руководство пользователя по 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 инструмента/систему хранения данных.
Рекомендации по созданию дашбордов
Работа с компонентами
-
Рекомендуемое количество Components и Filter Components на дашборде - не более 30.
- При количестве компонентов менее 6, используется параллельная их загрузка в браузере, что не требует ожидания и обеспечит быструю загрузку.
- Если количество компонентов находится в диапазоне от 6 до 30, то они будут поставлены в очередь, что может привести к значительному увеличению времени их загрузки.
- При количестве компонентов более 30, будет наблюдаться очень медленная скорость загрузки и низкая производительность дашборда.
- Рекомендуется использовать Tab Component для ассинхронной загрузки элементов дашборда. Не рекомендуется размещать слишком много компонентов на одной странице, т.к. чем больше компонентов, тем ниже производительность.
- Используя логику пошаговой детализации (Drill-down) там, где это применимо, вы можете сократить количество компонентов на одной странице. Однако не забудьте про визуальные подсказки для пользователей, чтобы обеспечить понимание процесса перехода между уровнями информации.
Работа с фильтр-компонентами
- В качестве значений для Filter Component задавайте изменения из справочников, для обращения же к данным таблицы с фактами используйте параметры на стороне SQL Dataset.
- Оптимальное количество условий для Filter Components по версии вендора - не более 30. Стоит помнить, что один Filter Component может содержать несколько условий, например, city = «Moscow» OR (city = «Sochi» AND city = «Omsk»), что соответствует 3 условиям.
Создание компонентов
- Если в одном Filter Component добавлено довольно много полей, присвойте ему в режиме редактирования значение по умолчанию.
- При работе с данными с низкой гранулярностью рациональным решением будет использование фильтрации, ТОП-N и иных опций, ограничивающих общий объем информации.
- При наличии большого количества полей на дашборде, их рендеринг может занимать временя. В таких случаях, сложные логические расчеты, такие как новые вычисляемые поля, вычисления для фильтрации заголовков таблиц, вычисления для фильтрации значений и др., рекомендуется выносить во вкладку Data настолько, насколько это возможно. Это поможет снизить нагрузку на дашборд и ускорить его загрузку.
Рекомендации по вычислениям
- При наличии более четырех вложенных IF в вычисляемом поле, рекомендуется использовать функцию SWITCH вместо оператора IF.
- Не рекомендуется использовать DEF функции в Filter Detail полей.
-
Вычисляемое поле с преобразованием даты должно быть максимально простым:
- Рекоменуется: TODATE(TOSTRING(${DATE}),"yyyyMMdd")
- Не рекомендуется: TODATE(CONCATENATE(LEFT(${DATE},4),"-",MID(${DATE},5,2),"-",RIGHT(${DATE},2)))
