Pull to refresh
17
2
Антон Кондауров@koanse

User

Send message

Особенности ALL как модификатора CALCULATE и как «создателя» новой таблицы в FILTER

Reading time6 min
Reach and readers5.3K

DAX содержит гибкие возможности фильтрации, и важными функциями являются ALL и REMOVEFILTERS. При использовании ALL и REMOVEFILTERS в качестве модификатора CALCULATE они ведут себя одинаково, т.к. в этом случае REMOVEFILTERS является псевдонимом ALL, однако ALL в FILTER возвращает «новую таблицу» и очищает влияние всех фильтров, что важно учитывать с точки зрения производительности и результатов.

Интересующимся особенностями ALL и сравнением ALL и REMOVEFILTERS  — добро пожаловать под кат :)

Читать далее

Особенности снижения гранулярности таблицы в Power BI на примере REMOVEFILTERS

Reading time6 min
Reach and readers4.7K

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

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

При использовании некоторых функций, например, REMOVEFILTERS, снижение гранулярности может приводить к интуитивно непонятным результатам и считаться плохой практикой. Интересующимся особенностями снижения гранулярности на примере REMOVEFILTERS — добро пожаловать под кат :)

Читать далее

Особенности агрегации SUMMARIZE в Power BI

Reading time4 min
Reach and readers5.5K

Привет, Хабр! Некоторые функции DAX из Power BI могут выглядеть интуитивно понятными, но при детальном рассмотрении ведут себя не совсем ожидаемо. Например, SUMMARIZE не агрегирует «сразу», в месте использования, но SUMMARIZE реализуется через «виртуальную», «отложенную» агрегацию за счет сохранения состояния. Для суммы, т.е. SUM, промежуточное состояние и есть сумма и особенности SUMMARIZE не проявляются, но для любой другой агрегации (например, среднего AVERAGE) становится понятно, что в Power BI уже учитывается так называемое состояние для корректного расчета SUMMARIZE, т.е. данные по всем записям сохраняются в состоянии. В других СУБД единственный аналог — только State и Merge комбинаторы из ClickHouse, поэтому для иллюстрации состояний будет рассмотрен пример из ClickHouse, соответствующий DAX с SUMMARIZE и AVERAGE. Интересующимся особенностями SUMMARIZE в Power BI — добро пожаловать под кат :)

Читать далее

Особенности REMOVEFILTERS в DAX из Power BI

Level of difficultyEasy
Reading time7 min
Reach and readers5.6K

Привет, Хабр! Одной из важных функций-модификаторов в DAX является REMOVEFILTERS, он позволяет, например, убрать фильтр для расчета знаменателя в доле. Однако логика REMOVEFILTERS для столбцов может выглядеть неочевидной, например, REMOVEFILTERS только для одного поля, по которому есть условие в FILTER, не влияет на результат DAX запроса. Так, REMOVEFILTERS(customer[customer_id]) не влияет на FILTER в SUMMARIZECOLUMNS вида FILTER(customer, customer[customer_id] > 2) и для сброса фильтра нужен REMOVEFILTERS(customer) по всей таблице. В связи с этим удобно представить принципы работы REMOVEFILTERS более формально, например, в виде ER диаграммы с подписанными связями. Для построения ER диаграммы был выбран Mermaid и генерация кода диаграммы реализована на C#. Интересующимся особенностями REMOVEFILTERS — добро пожаловать под кат :)

Читать далее

DAX-style подход в C# для SUMMARIZECOLUMNS из Power BI

Level of difficultyEasy
Reading time6 min
Reach and readers1.3K

Привет, Хабр! Одной из важных функций в аналитическом языке DAX является SUMMARIZECOLUMNS, т.к. она готовит данные для дашбордов за счет декартова произведения полей группировки, если поля группировки из разных таблиц. Понятно, что на любом языке программирования можно реализовать логику, в чем-то аналогичную SUMMARIZECOLUMNS из DAX. Интересующимся DAX-style логикой для C# из NuGet пакета DaxSharp для функцииSUMMARIZECOLUMNS — добро пожаловать под кат :)

Читать далее

Балансирование нагрузки при разделяемых ресурсах при помощи очередей в Hangfire

Level of difficultyEasy
Reading time5 min
Reach and readers1.4K

Привет, Хабр! При создании фоновых работ, например, через Hangfire, может быть актуально учитывать разделяемые ресурсы (например, базы данных, внешнюю API или файловую систему). Поскольку такие ресурсы являются ограниченными, возникает потребность управления количеством параллельно исполняемых задач без написания сложной логики. Интересующимся особенностями распределения ресурсов в Hangfire при помощи очередей — пожаловать под кат :)

Читать далее

Особенности SUMMARIZECOLUMNS в DAX

Level of difficultyEasy
Reading time2 min
Reach and readers860

Привет, Хабр! В аналитическом языке DAX одной из важных функций является SUMMARIZECOLUMNS. Эта функция готовит данные для дашбордов, также реализует декартово произведение полей группировки (если поля группировки из разных таблиц). Для понимания DAX полезно ознакомиться с особенностями SUMMARIZECOLUMNS, интересующимся деталями SUMMARIZECOLUMNS — добро пожаловать под кат :)

Читать далее

Сравнение средних значений в BI: однофакторный критерий Кохрена-Кокса

Level of difficultyHard
Reading time6 min
Reach and readers1.4K

В рамках BI решаются различные задачи, в том числе и с помощью статистических методов, для корректного выбора которых важно обращать внимание на содержание задачи. Например, если нужны только средние значения для графика, то действительно достаточно их рассчитать. Но иногда требуется решить другие задачи, например, не просто расчет средних значений двух выборок, но и сравнение средних двух выборок, чтобы узнать, в какой выборке среднее больше или меньше. Кроме того, данных для сравнения может быть столько, что они могут не умещаться на графике. В этом случае важно переключиться на подходящую статистическую гипотезу и использовать корректные статистические методы, намного более интересные, чем отображение средних значений на графике. Здесь могут быть эффективны методы дисперсионного анализа (ANOVA), или, в частном случае, когда речь идет о расчетах для одного фактора — методы сравнения средних двух выборок, и, например, метод Кохрена-Кокса. О том, какие результаты подобный подход дает на практике, а также о преимуществах работы с DAX при сравнении средних значений, читайте под катом.

Читать далее

BI в тестировании — сравнение результатов бенчмарков двух веток с помощью однофакторного ANOVA (критерий Кохрена-Кокса)

Reading time5 min
Reach and readers623

Business Intelligence (BI) находит применение в самых разных сферах, в том числе, например, при анализе результатов бенчмарков. Часто возникает задача сравнения производительности двух версий приложения на основе результатов бенчмарков (время выполнения тестов для нескольких прогонов и нескольких тестов), например, сравнение master ветки и feature ветки. Улучшение производительности в feature ветке (особенно, если она для улучшения производительности и создавалась) проверить можно условно и вручную, но также важно проверить, что нет деградации в других кейсах бенчмарков для feature ветки по сравнению с master веткой. Это можно решить статистическими методами, например, достаточно однофакторного дисперсионного анализа (ANOVA), здесь будет рассмотрен критерий Кохрена-Кокса, особенности его имплементации на PostgreSQL и возможные виды графиков для представления результатов. Интересующимся применением BI и ANOVA для сравнения производительности двух версий приложения на бенчмарках — добро пожаловать под кат :)

Читать далее

Проверка отсутствия деградации бенчмарков для двух версий статистическими методами

Reading time4 min
Reach and readers652

Привет, Хабр! Часто при тестировании идет сравнение производительности двух версий, например, master ветки и feature ветки. Допустим, идет сравнение по бенчмаркам, т.е. сравнивается время выполнения запросов для некоторого количества кейсов. Понятно, что если, например, в feature ветке есть улучшение производительности (и ветка создавалась как раз для улучшения производительности), это улучшение на целевых кейсах можно проверить даже вручную. Однако, осталось проверить, нет ли ухудшения производительности в остальных кейсах. Относительно точное вычисление производительности в смысле среднего времени выполнения запроса в конкретном кейсе требует нескольких прогонов кейса и может занять некоторое время, поэтому полная проверка всех кейсов (с десятками прогонов каждого кейса для получения более точного среднего результата) может занять, например, дни.

Однако, часто требуется лишь проверить лишь наличие деградации в feature ветке по сравнению с master, а не знать относительно точное время выполнения каждого запроса в feature ветке, это зачастую актуально для PR. Например, в feature ветке в одном кейсе два запроса выполняются за 300 и 300 секунд, а в master ветке для этого кейса за 12, 11, 10 секунд, нужно ли проводить несколько запусков кейса в feature ветке, или и так понятно, что есть деградация? Методы математической статистики позволяет формально ответить на этот вопрос с заданной вероятностью, например, 0.95, чтобы можно было принять решение формально, а не интуитивно. Интересующимся статистическими методами проверки отсутствия деградации — добро пожаловать под кат :)

Читать далее

Кардинальность при оптимизации DAX запросов в ClickHouse

Reading time7 min
Reach and readers1.4K

Привет, Хабр! Мы уже неоднократно поднимали вопросы оптимизации запросов к СУБД ClickHouse, которую все чаще используют как универсальное высокопроизводительное хранилище для аналитических задач. В случае с Visiology этот вопрос приобретает двойную ценность, так как мы используем оптимизацию для эффективного выполнения запросов в языке DAX.

Сегодня мы поговорим о применении группировок GROUP BY с учетом их производительности для относительно больших таблиц, например, с миллионами записей. Таким образом, речь пойдет об оценке кардинальности одного или нескольких столбцов. Эта задача, кстати, является достаточно нетривиальной. Но если Вы можете ее решить, появляется возможность для эффективных оптимизаций SQL. О них мы и поговорим сегодня.

Читать далее

Представление иерархии и выполнение иерархических запросов в ClickHouse с использованием хешей

Level of difficultyEasy
Reading time7 min
Reach and readers892

Привет, Хабр! Достаточно часто используются иерархические фильтры или отчеты с иерархией, и представление иерархии может быть актуально как для UI (например, иерархических фильтров), так и для отчетов или дашбордов. Если рассматривать только структуру запроса с иерархией, без расчета промежуточных итогов и т.д., то сохранение структуры иерархического UI элемента при большом уровне вложенности, а также передача этой иерархии с UI на бэкенд и дальше, например, в виде SQL запроса в СУБД может быть относительно нетривиальной задачей. При относительно большом уровне вложенности (например, иерархия в 10 уровней), при решении «в лоб» и сохранении всех 10 выбранных значений на последнем уровне иерархии, станет неудобно хранить и передавать в качестве параметров с UI на бэкенд (для 1000 строк и 10 уровней вложенности может быть уже условно 10000 параметров), также растет и количество параметров в SQL, и проблемы усугубляются в случае микросервисной архитектуры, когда запрос SQL не сразу отправляется, например, в ClickHouse, а ещё эти 10000 параметров «путешествуют» из UI в один или несколько микросервисов, пока не попадут в ClickHouse. В связи с этим хочу рассмотреть одно из возможных решений проблемы с помощью хеширования на примере C# и ClickHouse, но это «не идеи, проверенные на продакшене», больше тема к обсуждению. Тем, кому интересно решение проблем иерархических запросов на примере C# и ClickHouse — добро пожаловать под кат :)

Читать далее

Изучаем DAX Time Intelligence с помощью ViTalk GPT

Reading time3 min
Reach and readers930

Привет, Хабр! Сегодня я хочу поговорить о возможностях и ограничениях функций Time Intelligence в Visiology. Это очень интересный раздел языка DAX, который позволяет быстро делать показательные расчеты, например, сравнивая показатели текущего периода с предыдущими. Однако в его реализации для Visiology и Power BI есть некоторые различия (впрочем, не влияющие на результат). В этой статье мы поговорим об этой разнице, а также я наглядно покажу, как чат-бот ViTalk GPT помогает разобраться с особенностями работы различных функций.

Читать далее

Использование dax.do для произвольной схемы данных на основе перевода DAX в Contoso через Telegram бот

Reading time3 min
Reach and readers737

Привет, Хабр! В работе Business Intelligence аналитика могут встречаться задачи проверки DAX запроса на произвольной схеме, к которой может не быть доступа. Перевод DAX запроса из исходной схемы в схему, к которой есть доступ и есть возможность выполнения DAX запроса, может занимать некоторое время и требовать определенных усилий. В век AI, безусловно, хочется делать перевод в схему автоматически, при помощи AI. Кроме того, ресурс dax.do является достаточно удобной песочницей для Contoso схемы данных, поэтому такое впечатление, что одним из быстрых решений для анализа и запуска DAX без схемы данных является перевод произвольного DAX в dax.do (например, автоматически при помощи Telegram бота), что позволяет уже дальше смотреть полученный DAX в песочнице dax.do на схеме Contoso без каких-то ограничений. Это позволяет проверить работоспособность DAX на незнакомой схеме за секунды. Интересующимся новыми возможностями DAX песочниц — добро пожаловать под кат :)

Читать далее

Возможности комбинаторов в ClickHouse

Reading time9 min
Reach and readers2.2K

Что делать с запросами к СУБД, выполнение которых затягивается на десятки минут, как можно оптимизировать вложенные операторы, чтобы получить нужные данные за секунды? За счет чего подобные операции выполняются в Visiology автоматически? Ответы на эти вопросы мы попробуем дать сегодня на примере небольшого синтетического теста со сложным SQL-запросом, и разберемся при чем тут комбинаторы в ClickHouse. Эта статья будет полезна тем, кто интересуется SQL-оптимизаторами, а также всем существующим и будущим пользователям Visiology, кто хочет заглянуть под капот системы. Если вы из их числа, добро пожаловать под кат :)

Читать далее

«DAX Fiddle» в виде Telegram бота

Reading time2 min
Reach and readers788

Для многих языков есть свои online песочницы, например, для POSTGRES есть условный PostgreSQL Fiddle, также и для аналитического языка DAX хотелось бы побольше подобных инструментов. Существующий dax.do позволяет выполнять запросы условно только на стандартной схеме Contoso, и в век AI хотелось бы иметь инструмент для быстрого выполнения DAX запросов для произвольной схемы данных. Также генерация самой схемы и заполнение её данными также являются трудоемкими, и хотелось бы отдать это всё AI.

Кроме того, сейчас популярны Telegram боты, в связи с этим появилась идея создания Telegram бота для выполнения DAX (и построения простейшего дашборда-таблицы) на произвольной схеме данных, с автоматически сгенерированными данными, своего рода DAX Fiddle. Интересующимся DAX Fiddle — добро пожаловать под кат :)

Читать далее

Плюсы и минусы SUMMARIZE

Reading time6 min
Reach and readers1.8K

При использовании DAX аналитикам важно следить не только за корректностью результатов, но и за производительностью системы при обработке запросов. Одним из инструментов повышения эффективности является корректное использование функции SUMMARIZE. Всем, кто работает с большими объемами данных, активно изучает синтаксис DAX, а также интересующимся особенностями SUMMARIZE — добро пожаловать под кат!

Читать далее

Планы и факты: работаем с денормализованной таблицей

Reading time6 min
Reach and readers2.8K

Привет, Хабр! В этой статье я хотел бы поговорить про особенности план-факт анализа, а также о работе с денормализованной таблицей, которая «была, есть и будет использоваться», потому что оказывается удобной для некоторых приемов работы с BI. Под катом вы найдете 7 примеров решения типовых задач план-факт анализа, включая расчет долей, отображение данных с учетом иерархии, разбивку по регионам и так далее. Всех, кому интересны эти практические аспекты, жду под катом :)

Читать далее

Выполнение DAX запроса AI DAX движка в СУБД на примере PostgreSQL

Reading time3 min
Reach and readers1K

Привет, Хабр! DAX является мощным аналитическим языком запросов и активно используется во множестве проектов. Кроме того, на текущем уровне развития AI он способен условно в режиме реального времени преобразовать DAX запросы в запросы одной из СУБД, например, PostgreSQL, но, конечно, с рядом ограничений на сложность DAX запроса, схему данных и т.д. В связи с этим может быть актуальным вопрос, реально ли использовать «AI DAX движок» в сочетании с выполнением SQL запросов, сгенерированных этим движком, в одной из СУБД, т.е. выполнить DAX без Power BI на PostgreSQL источнике? Интересующимся возможностями DAX AI на примере PostgreSQL — добро пожаловать под кат :)

Читать далее

Получение SQL для PostgreSQL из DAX на основе AI

Reading time3 min
Reach and readers2.2K

Привет, Хабр! Популярным аналитическим языком является DAX, и он используется во множестве проектов. Соответственно, значительная часть бизнес-логики дашбордов реализована на DAX, и при переходе с Power BI на другой продукт требуется время на перевод DAX логики из Power BI. В связи с этим актуальны инструменты расширения списка платформ, на которых можно использовать DAX без Power BI.

Тем, кто интересуется «переводом» DAX на PostgreSQL — добро пожаловать под кат :)

Читать далее
1

Information

Rating
1,332-nd
Location
Россия
Works in
Date of birth
Registered
Activity

Specialization

Фулстек разработчик
Ведущий