Size: a a a

Power BI Group RU

2020 May 05

KK

Konstantin Kadikin in Power BI Group RU
Ivan Kizimenko
Так это вроде не в самом датасете изменения будут. А уже в отчете.
Я, конечно, поздно, но: фильтруя в PQ вы меняете именно датасет) Просто PQ хранит цепочку преобразований, и, если надо, удаление дублей можно убрать. А в облаке датасет итоговый либо есть, либо нет
источник

IK

Ivan Kizimenko in Power BI Group RU
Konstantin Kadikin
Я, конечно, поздно, но: фильтруя в PQ вы меняете именно датасет) Просто PQ хранит цепочку преобразований, и, если надо, удаление дублей можно убрать. А в облаке датасет итоговый либо есть, либо нет
Это я понимаю что он именно датасет. Просто по идее всегда будет делать эти преобразования. По сохраненной цепочке. Я думал что можно как то это упростить чтоб отказаться от этих шагов
источник

KK

Konstantin Kadikin in Power BI Group RU
Ivan Kizimenko
Это я понимаю что он именно датасет. Просто по идее всегда будет делать эти преобразования. По сохраненной цепочке. Я думал что можно как то это упростить чтоб отказаться от этих шагов
Вот вы...) Держите совет от собаки Смайла: до загрузки в PBI данные можно преобразовать, а грузить обработанные, там для этого кнопка специальная есть
источник

AS

Alexey Shcheglov in Power BI Group RU
Konstantin Kadikin
Вот вы...) Держите совет от собаки Смайла: до загрузки в PBI данные можно преобразовать, а грузить обработанные, там для этого кнопка специальная есть
++++++ 100500 +++++
как у меня горит, когда тут иногда пытаются сразу через dax нагородить решения, которые должны были быть созданы ещё в M. И настойчиво просят решение через создание столбцов в pbi =)
Данные всегда, всегда должны быть оценены на возможность упрощения, базовой агрегации, условных доп.маркеров, а только потом загружены в модель
источник

KK

Konstantin Kadikin in Power BI Group RU
Alexey Shcheglov
++++++ 100500 +++++
как у меня горит, когда тут иногда пытаются сразу через dax нагородить решения, которые должны были быть созданы ещё в M. И настойчиво просят решение через создание столбцов в pbi =)
Данные всегда, всегда должны быть оценены на возможность упрощения, базовой агрегации, условных доп.маркеров, а только потом загружены в модель
При чем тут дакс? А вообще, pbi как раз позиционируется в тч как система, позволяющая в диалоге данные обработать, а не «я в скуле все соберу, а потом себе возьму»
источник

АС

Андрей Синякин... in Power BI Group RU
Alexey Shcheglov
++++++ 100500 +++++
как у меня горит, когда тут иногда пытаются сразу через dax нагородить решения, которые должны были быть созданы ещё в M. И настойчиво просят решение через создание столбцов в pbi =)
Данные всегда, всегда должны быть оценены на возможность упрощения, базовой агрегации, условных доп.маркеров, а только потом загружены в модель
На сколько я могу судить, такие решения руководствуются тем, что PQ жрёт намного больше ресурсов системы в отличие от DAX'а, отсюда и желание минимальные агрегации выполнять на M, а самые "жирные" вещи пилить через дакс.
источник

АС

Андрей Синякин... in Power BI Group RU
Интересно было бы узнать, есть ли основание на это реально, слышал такую версию. Сам на серьёзных данных не тестил.
источник

AS

Alexey Shcheglov in Power BI Group RU
Андрей Синякин
На сколько я могу судить, такие решения руководствуются тем, что PQ жрёт намного больше ресурсов системы в отличие от DAX'а, отсюда и желание минимальные агрегации выполнять на M, а самые "жирные" вещи пилить через дакс.
я про случаи, когда человек грузит исходники без обработки, строит таблицу фактов-штрих через сводную и постоянно к ней обращается
источник

AS

Alexey Shcheglov in Power BI Group RU
и держит вечно эту самую сводную, потому что ему базовая детализация нужна именно такая. почему это не решить на уровне pq
источник

AS

Alexey Shcheglov in Power BI Group RU
Konstantin Kadikin
При чем тут дакс? А вообще, pbi как раз позиционируется в тч как система, позволяющая в диалоге данные обработать, а не «я в скуле все соберу, а потом себе возьму»
не понял, что Вы парировали) я всецело поддержал Вас. pq - прекрасен для  подготовки данных
источник

KK

Konstantin Kadikin in Power BI Group RU
Alexey Shcheglov
не понял, что Вы парировали) я всецело поддержал Вас. pq - прекрасен для  подготовки данных
Может, я не так понял тогда, извиняйте)
источник

DL

Dmitry Lebedev in Power BI Group RU
А вообще всегда актуальна тема выбора правильного соотношения в архитектуре: что на уровне SQL посчитать, что в PQ обработать, что в DAX доделать
источник

KK

Konstantin Kadikin in Power BI Group RU
Андрей Синякин
На сколько я могу судить, такие решения руководствуются тем, что PQ жрёт намного больше ресурсов системы в отличие от DAX'а, отсюда и желание минимальные агрегации выполнять на M, а самые "жирные" вещи пилить через дакс.
А с чего dax ест меньше pq? Некоторые вещи проще делать в даксе, некоторые в pq
источник

M

Max in Power BI Group RU
Андрей Синякин
Интересно было бы узнать, есть ли основание на это реально, слышал такую версию. Сам на серьёзных данных не тестил.
Вот и мне интересно, где Вы такие сказки сказочные находите/читаете/слушаете :)
источник

A

Alex in Power BI Group RU
Полностью придерживаюсь стратегии: все, что только возможно, посчитать на sql, заранее подготовил витрины для отчётов, оставив для Powerbi только простые задачи, типа sum, countrows и т.п.
источник

M

Max in Power BI Group RU
Alex
Полностью придерживаюсь стратегии: все, что только возможно, посчитать на sql, заранее подготовил витрины для отчётов, оставив для Powerbi только простые задачи, типа sum, countrows и т.п.
👍
источник

M

Max in Power BI Group RU
Хотя с таким подходом порой легко перегнуть палку :)
источник

M

Max in Power BI Group RU
и насоздавать кучу лишних полей
источник

DL

Dmitry Lebedev in Power BI Group RU
Ну, как когда-то писал Максим Зеленский здесь же, на DAX высокоуровневые аналитические расчеты писать проще, чем на SQL. Еще коллега из АТК, помнится, говорил что-то похожее много лет назад на презентации Power BI.
источник

DL

Dmitry Lebedev in Power BI Group RU
но мне идея рассчитать все, что можно, на уровне БД, всегда нравилась
источник