В модели продаж Power BI есть 12 миллионов строк заказов, а клиенты могут ежемесячно менять регион; как смоделировать историю регионов для дашборда выручки за пять лет?

Я бы использовал измерение клиентов типа 2 и относил каждый заказ к версии клиента, действовавшей на дату заказа. - При каждом изменении клиента создаётся новый суррогатный ключ с полями valid-from, valid-to и признаком текущей строки, а бизнес-идентификатор клиента сохраняется. - В 12 миллионах строк фактов хранится суррогатный ключ версии, поэтому историческая выручка региона не перемещается при смене региона клиентом. - Перед публикацией модели Power BI я бы проверил отсутствие пересекающихся интервалов действия и наличие ровно одной подходящей версии измерения для каждого заказа.

В таблице SCD2 клиентов в Snowflake есть 8 миллионов версий, а исправления могут приходить с опозданием на 14 дней; как сохранить историческую корректность retention-дашборда в Looker?

Я бы перестроил все интервалы клиента, затронутые 14-дневным горизонтом опозданий, а затем переназначил ключи retention-фактам, чей EventTimestamp попал в изменённый интервал. - dbt-модель упорядочивает строки источника по CustomerID, EffectiveAt и SourceUpdatedAt, вычисляет исключающую границу ValidTo через LEAD и отклоняет дубли начала действия. - Merge обновляет CustomerVersionKey у существующих и новых фактов, для которых EventTimestamp не меньше ValidFrom и меньше ValidTo, а не обрабатывает только новые факты. - Explore в LookML соединяет fact.CustomerVersionKey с customer.CustomerVersionKey как many_to_one, а тесты требуют одну строку IsCurrent на CustomerID и ровно одну версию на retention-событие.

В модели заказов Power BI есть Order Date, Ship Date и Delivery Date для 40 миллионов строк; как поддержать все три календарных представления без неоднозначных связей?

Я бы использовал одно согласованное измерение Date с одной активной и двумя неактивными ролевыми связями. - Связь по Order Date была бы активной, поскольку она управляет стандартным дашбордом продаж, а связи по Ship Date и Delivery Date оставались бы неактивными. - Меры Shipped Revenue и Delivered Orders активировали бы нужную связь через USERELATIONSHIP внутри CALCULATE. - Я бы сгруппировал и назвал меры по роли даты, чтобы авторы отчётов случайно не совместили ось Ship Date с мерой по Order Date.

Дашборд клиентов в Tableau охватывает 6 миллионов покупок, а каждый клиент может одновременно относиться к пяти маркетинговым сегментам; как смоделировать связь с сегментами?

Я бы сохранил покупки на гранулярности PurchaseLineID и материализовал членство в сегментах на дату события до выполнения запросов Tableau. - Источник членства хранит CustomerID, SegmentID, ValidFrom и исключающую границу ValidTo, но хранилище разрешает интервалы в мост PurchaseSegment, чтобы Tableau не разрешал many-to-many non-equi join во время запроса. - Полную выручку можно независимо показывать для каждого пересекающегося сегмента, но строки сегментов неаддитивны по портфелю; для сверяемого итога нужен AllocationWeight. - Я бы проверил уникальность PurchaseLineID плюс SegmentID, сумму весов 1 на PurchaseLineID и distinct count клиентов при одиночном и множественном выборе сегментов.

Модель Power BI для университета должна показывать право на посещение и фактическую посещаемость 80 000 студентов для каждого занятия, включая имеющих право студентов без события посещения; какую структуру фактов вы выберете?

Я бы использовал таблицу фактов покрытия EligibilityFact и отдельную таблицу событий AttendanceFact на общей гранулярности студента и занятия курса. - EligibilityFact содержит одну строку на StudentKey и CourseSessionKey и строится разворачиванием регистраций на семестр по занятиям, которые студент должен был посетить. - AttendanceFact содержит одну строку на наблюдаемые StudentKey и CourseSessionKey с AttendanceStatusKey и CheckInTimestamp, а обе таблицы используют общие измерения Student, Course, Session и Date. - Пропуск посещения определяется антисоединением ожидаемых и наблюдаемых строк по StudentKey плюс CourseSessionKey, поэтому несобытие считается явно, а не угадывается по транзакционной таблице.

В воронке продаж Looker есть 3 миллиона возможностей и семь этапов от создания до оплаты; как смоделировать длительность этапов и текущий backlog?

Я бы использовал накапливающийся снимок с одной строкой на OpportunityID и семью датами этапов, обновляемыми по мере продвижения сделки. - Строка хранит CreatedAt, QualifiedAt, DemoAt, ProposalAt, WonAt, InvoicedAt и PaidAt вместе с CurrentStageKey и TerminalStatusKey. - Измерения LookML вычисляют время между соседними непустыми этапами, а меры backlog считают сделки, у которых текущий этап заполнен, а следующий ещё равен null. - Пайплайн выполняет merge по OpportunityID, а для повторных этапов, переоткрытий и полного аудита переходов нужна отдельная таблица фактов OpportunityStageEvent.

Дашборд запасов Power BI хранит ежедневные данные по 15 000 товаров на 120 складах за два года; как смоделировать остатки и движения?

Я бы разделил ежедневный снимок запасов и таблицу движений, потому что остатки и потоки имеют разную гранулярность и аддитивность по времени. - Плотный снимок на уровне ProductKey, WarehouseKey и SnapshotDate содержал бы около 1,314 миллиарда строк за 730 дней до исключения неактивных сочетаний товара и склада. - Приёмки, отгрузки и корректировки остаются на гранулярности MovementLineID со знаковыми QuantityChange и ValueChange для анализа потоков и сверки. - Меры остатка Power BI выбирают последний допустимый снимок в периоде, а меры движения суммируются по датам и сверяют начальный остаток плюс движения с конечным.

В модели аккаунтов Power BI есть 2 миллиона аккаунтов, каждый может быть закреплён за четырьмя торговыми представителями с меняющимися процентами зачёта; как предотвратить двойной подсчёт в дашбордах квот?

Я бы оставил выручку компании в таблице строк счетов, а зачёт торговым представителям материализовал в отдельной распределённой таблице фактов. - Хранилище разрешает AccountID, InvoiceDate, RepID, ValidFrom, ValidTo и AllocationPercent в строки с ключом InvoiceLineID плюс RepID, потому что связи Power BI не вычисляют соединения по интервалу действия. - Каждая строка хранит CreditedRevenue, а тесты требуют сумму AllocationPercent 1 и сумму CreditedRevenue, равную исходной LineRevenue для каждого InvoiceLineID. - Company Revenue читает базовый факт, а Credited Revenue распределённый, поэтому выбор нескольких представителей не умножает юридический итог компании.

Дашборд электронной торговли в Tableau получает 25 миллионов строк заказов с доставкой на уровне заказа и скидками на уровне строки; какую гранулярность вы выберете для таблицы фактов?

Я бы задал основную таблицу фактов продаж на уровне одной строки заказа и не повторял бы меры заголовка как аддитивные значения. - Количество товара, выручка строки и скидка строки принадлежат непосредственно таблице фактов на 25 миллионов строк. - Доставка может находиться в отдельной таблице фактов заголовков заказов или распределяться по строкам по документированному правилу, например пропорционально выручке. - Расчёты Tableau используют выбранное представление доставки последовательно, а тест гранулярности проверяет уникальность пары ID заказа и ID строки.

Финансовой модели Looker нужны ежедневные движения денежных средств из 90 миллионов транзакций и остатки на конец месяца для 400 счетов; использовать одну таблицу фактов или две?

Я бы использовал транзакционную таблицу фактов для денежных потоков и периодический снимок для остатков на конец месяца. - Транзакционная таблица на 90 миллионов строк поддерживает аддитивные меры притока и оттока по дате проводки, счёту и типу транзакции. - Снимок содержит одну строку на счёт и дату конца месяца, явно задавая выбор отчётного остатка вместо восстановления каждого закрытия из всей истории. - Explores в Looker могут разделять views Account и Date, но меры остатка должны выбирать последний снимок и не должны суммироваться по месяцам.

В модели поддержки Power BI есть 18 миллионов тикетов, 12 флагов с низкой кардинальностью и номера тикетов для страниц drill-through; где разместить эти атрибуты?

Я бы оставил TicketNumber вырожденным измерением и сначала сравнил 12 флагов как столбцы факта с вариантом мусорного измерения. - TicketNumber остаётся в факте, потому что отдельное измерение на 18 миллионов строк без других атрибутов добавляет связь, но не уменьшает гранулярность. - VertiPaq часто хорошо сжимает 12 низкокардинальных Boolean-столбцов; мусорное измерение оправдано, только если наблюдаемые сочетания и управляемые подписи измеримо уменьшают модель или упрощают срезы. - В обоих вариантах я открою бизнес-подписи, скрою суррогатные ключи и проверю drill-through по TicketNumber и размер модели через VertiPaq Analyzer.

dbt-модель для дашборда страховых требований в Tableau получает 5 миллионов фактов раньше некоторых строк измерения поставщиков, а SLA обновления равен 24 часам; как обработать неизвестных поставщиков?

Я бы создавал предварительные записи поставщиков, чтобы каждое требование сохраняло корректный ключ измерения в течение 24-часового окна отчётности. - Отсутствующий бизнес-ключ поставщика сопоставляется минимальной суррогатной строке с признаком Inferred, а не null-ключу и не удалённому требованию. - Когда атрибуты поставщика приходят, dbt обновляет эту предварительную строку на месте, поэтому факту на 5 миллионов строк не требуется смена ключа. - Тесты данных отслеживают возраст неразрешённых предварительных записей, а Tableau подписывает их Pending Provider, не смешивая с действительно неизвестными данными.

Почему в модели Power BI с 30 миллионами строк продаж CALCULATE внутри SUMX может вернуть другой результат, чем SUMX с обычным выражением SUM?

CALCULATE выполняет переход контекста, превращая текущий контекст строки итератора в контекст фильтра для вычисления меры. - SUMX создаёт контекст строки для входной таблицы, но обычная агрегация не фильтрует модель по текущей строке автоматически. - Обёртка агрегации в CALCULATE или вызов существующей меры с неявным CALCULATE применяет столбцы текущей строки как фильтры. - Я бы не итерировал 30 миллионов строк фактов, если та же мера отчёта может пройти по меньшей таблице Product или сводной таблице нужной гранулярности.

В дашборде маржи Power BI есть 60 миллионов строк счетов; как написать меру CALCULATE для выручки прибыльных товаров без построчной фильтрации всей таблицы фактов?

Я бы фильтровал измерение Product или компактный набор товаров, а затем позволил связям распространить фильтр на факты. - CALCULATE может применить FILTER к таблице Product на 80 000 строк с мерой маржи на уровне товара или управляемым атрибутом прибыльности. - FILTER по всем 60 миллионам строк счетов обычно дороже и может задать семантику прибыльности на уровне строки вместо уровня товара. - До завершения меры я бы уточнил, означает ли прибыльность текущую классификацию каталога или прибыльность в выбранном периоде отчёта.

В отчёте ценообразования Power BI есть 12 миллионов строк с разными количествами и маржой на единицу; какой итератор DAX использовать для взвешенной маржи на единицу?

Я бы использовал SUMX для общей маржи строк и разделил её на общее количество вместо среднего значений UnitMargin. - Числитель проходит по строкам счетов и умножает Quantity на UnitMargin с учётом текущих фильтров ProductKey и DateKey. - Знаменатель суммирует Quantity в том же контексте фильтра, а DIVIDE возвращает blank или согласованный альтернативный результат при нулевом количестве. - Я бы сверил результат с SQL хранилища, потому что AVERAGEX по UnitMargin даёт одинаковый вес строке с одной единицей и строке с тысячей единиц.

Мера DAX в модели Power BI из 25 таблиц четыре раза повторяет одно выражение предыдущего периода; как переменные изменят её поведение и сопровождаемость?

Я бы один раз вычислил результат предыдущего периода в именованной переменной и повторно использовал это скалярное значение в итоговом выражении. - Переменные делают порядок вычислений видимым и не дают четырём копиям сложной ветки CALCULATE разойтись при изменениях. - Переменная вычисляется в контексте фильтра места объявления, поэтому перенос за пределы итератора или условия может изменить результат. - Я бы использовал доменные имена вроде PriorQuarterRevenue и SelectedTarget и сохранил отображаемое выражение модели из 25 таблиц достаточно коротким для ревью.

Розничная модель Power BI использует фискальный календарь 4-4-5 за шесть лет; как реализовать годовые сравнения в дашборде?

Я бы использовал полное фискальное измерение Date с явными фискальными неделями и ключами сопоставимых периодов вместо григорианских сокращений. - Шестилетний календарь назначает каждой дате фискальный год, квартал, период, неделю и ключ сопоставимой недели прошлого года. - Меры выполняют сдвиг через эти фискальные атрибуты или calculation group, чтобы год из 53 недель следовал согласованному правилу сравнения розницы. - Я бы протестировал итоги периодов у границ фискального года, потому что предположения DATEADD и SAMEPERIODLASTYEAR могут неверно совместить календарь 4-4-5.

Дашборд руководства в Power BI обновляется ежедневно в 07:00, а в текущем месяце загружено только 18 дней; как сделать годовое сравнение MTD корректным?

Я бы сравнил 18 загруженных дней текущего периода с таким же завершённым срезом дней прошлого года. - Мера Last Complete Data Date берётся из watermark загрузки фактов, а не из TODAY, поскольку обновление в 07:00 может отставать от активности источника. - Текущий MTD и прошлогодний MTD фильтруют диапазоны Date по эквивалентному порядковому дню или сопоставленной бизнес-дате. - Подзаголовок дашборда показывает дату среза, чтобы пользователи знали, что более поздние дни прошлого года исключены.

В логистической модели Power BI есть 45 миллионов заказов, активная связь по Order Date и неактивная по Ship Date; как рассчитать отгруженную выручку по месяцам?

Я бы определил Shipped Revenue через CALCULATE и USERELATIONSHIP между Date и Ship Date. - USERELATIONSHIP активирует существующую неактивную связь только для этой меры, а стандартная Order Revenue продолжает использовать Order Date. - В 45 миллионах строк фактов сохраняются оба ключа даты, а измерение Date остаётся единым источником атрибутов месяца и фискального периода. - Я бы сочетал визуализации по Ship Date с явно названными мерами отгрузки, поскольку общая мера Revenue продолжила бы следовать активному пути Order Date.

Модель Power BI сравнивает 20 000 целевых значений кампаний с 80 миллионами строк продаж, но таблица целей намеренно не связана; как применить выбранные кампании в DAX?

Я бы использовал TREATAS, чтобы проецировать ключи выбранных кампаний на управляемый столбец ключа кампании или продаж для меры сравнения. - Несвязанная таблица остаётся поверхностью параметров и не создаёт физической связи с неоднозначными путями в semantic model. - TREATAS должен передавать стабильные ID кампаний, а не отображаемые имена, особенно для 20 000 целей с возможными одинаковыми подписями. - Я бы держал меры целей и факта раздельно и рассчитывал отклонение только после применения нужных фильтров отчёта к обеим.

Вопросы на собеседовании: BI-разработчик

100 реальных вопросов с образцовыми ответами и пояснениями для уровня Middle.

Смотреть пример резюме: BI-разработчик →

Тренировка флешкарточками

Интервальное повторение · Hunter Pass

Вопросы

bipower-bidashboards

Я бы использовал измерение клиентов типа 2 и относил каждый заказ к версии клиента, действовавшей на дату заказа.

При каждом изменении клиента создаётся новый суррогатный ключ с полями valid-from, valid-to и признаком текущей строки, а бизнес-идентификатор клиента сохраняется.
В 12 миллионах строк фактов хранится суррогатный ключ версии, поэтому историческая выручка региона не перемещается при смене региона клиентом.
Перед публикацией модели Power BI я бы проверил отсутствие пересекающихся интервалов действия и наличие ровно одной подходящей версии измерения для каждого заказа.

Зачем это спрашивают: Интервьюер проверяет, умеете ли вы сохранять историческую атрибуцию с помощью SCD2, а не перезаписывать историю бизнеса.

bilookersnowflake

Я бы перестроил все интервалы клиента, затронутые 14-дневным горизонтом опозданий, а затем переназначил ключи retention-фактам, чей EventTimestamp попал в изменённый интервал.

dbt-модель упорядочивает строки источника по CustomerID, EffectiveAt и SourceUpdatedAt, вычисляет исключающую границу ValidTo через LEAD и отклоняет дубли начала действия.
Merge обновляет CustomerVersionKey у существующих и новых фактов, для которых EventTimestamp не меньше ValidFrom и меньше ValidTo, а не обрабатывает только новые факты.
Explore в LookML соединяет fact.CustomerVersionKey с customer.CustomerVersionKey как many_to_one, а тесты требуют одну строку IsCurrent на CustomerID и ровно одну версию на retention-событие.

Зачем это спрашивают: Сильный ответ охватывает поздние исправления SCD2 в измерении, переатрибуцию существующих фактов и контракт связи Looker.

bipower-bi

Я бы использовал одно согласованное измерение Date с одной активной и двумя неактивными ролевыми связями.

Связь по Order Date была бы активной, поскольку она управляет стандартным дашбордом продаж, а связи по Ship Date и Delivery Date оставались бы неактивными.
Меры Shipped Revenue и Delivered Orders активировали бы нужную связь через USERELATIONSHIP внутри CALCULATE.
Я бы сгруппировал и назвал меры по роли даты, чтобы авторы отчётов случайно не совместили ось Ship Date с мерой по Order Date.

Зачем это спрашивают: Интервьюер оценивает, умеете ли вы явно представить несколько ролей даты без неоднозначных путей фильтрации.

bitableaudashboards

Я бы сохранил покупки на гранулярности PurchaseLineID и материализовал членство в сегментах на дату события до выполнения запросов Tableau.

Источник членства хранит CustomerID, SegmentID, ValidFrom и исключающую границу ValidTo, но хранилище разрешает интервалы в мост PurchaseSegment, чтобы Tableau не разрешал many-to-many non-equi join во время запроса.
Полную выручку можно независимо показывать для каждого пересекающегося сегмента, но строки сегментов неаддитивны по портфелю; для сверяемого итога нужен AllocationWeight.
Я бы проверил уникальность PurchaseLineID плюс SegmentID, сумму весов 1 на PurchaseLineID и distinct count клиентов при одиночном и множественном выборе сегментов.

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

bipower-bidesign

Я бы использовал таблицу фактов покрытия EligibilityFact и отдельную таблицу событий AttendanceFact на общей гранулярности студента и занятия курса.

EligibilityFact содержит одну строку на StudentKey и CourseSessionKey и строится разворачиванием регистраций на семестр по занятиям, которые студент должен был посетить.
AttendanceFact содержит одну строку на наблюдаемые StudentKey и CourseSessionKey с AttendanceStatusKey и CheckInTimestamp, а обе таблицы используют общие измерения Student, Course, Session и Date.
Пропуск посещения определяется антисоединением ожидаемых и наблюдаемых строк по StudentKey плюс CourseSessionKey, поэтому несобытие считается явно, а не угадывается по транзакционной таблице.

Зачем это спрашивают: Интервьюер хочет увидеть таблицу покрытия ожидаемых событий, которую можно корректно сравнить с фактической посещаемостью.

bici-cdlooker

Я бы использовал накапливающийся снимок с одной строкой на OpportunityID и семью датами этапов, обновляемыми по мере продвижения сделки.

Строка хранит CreatedAt, QualifiedAt, DemoAt, ProposalAt, WonAt, InvoicedAt и PaidAt вместе с CurrentStageKey и TerminalStatusKey.
Измерения LookML вычисляют время между соседними непустыми этапами, а меры backlog считают сделки, у которых текущий этап заполнен, а следующий ещё равен null.
Пайплайн выполняет merge по OpportunityID, а для повторных этапов, переоткрытий и полного аудита переходов нужна отдельная таблица фактов OpportunityStageEvent.

Зачем это спрашивают: Сильный ответ различает текущий снимок процесса и историю событий и явно задаёт все семь указанных этапов.

warehousegrainbi

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

Плотный снимок на уровне ProductKey, WarehouseKey и SnapshotDate содержал бы около 1,314 миллиарда строк за 730 дней до исключения неактивных сочетаний товара и склада.
Приёмки, отгрузки и корректировки остаются на гранулярности MovementLineID со знаковыми QuantityChange и ValueChange для анализа потоков и сверки.
Меры остатка Power BI выбирают последний допустимый снимок в периоде, а меры движения суммируются по датам и сверяют начальный остаток плюс движения с конечным.

Зачем это спрашивают: Интервьюер проверяет дисциплину гранулярности, правильную арифметику числа строк и понимание полуаддитивности складских остатков по времени.

bipower-bidashboards

Я бы оставил выручку компании в таблице строк счетов, а зачёт торговым представителям материализовал в отдельной распределённой таблице фактов.

Хранилище разрешает AccountID, InvoiceDate, RepID, ValidFrom, ValidTo и AllocationPercent в строки с ключом InvoiceLineID плюс RepID, потому что связи Power BI не вычисляют соединения по интервалу действия.
Каждая строка хранит CreditedRevenue, а тесты требуют сумму AllocationPercent 1 и сумму CreditedRevenue, равную исходной LineRevenue для каждого InvoiceLineID.
Company Revenue читает базовый факт, а Credited Revenue распределённый, поэтому выбор нескольких представителей не умножает юридический итог компании.

Зачем это спрашивают: Интервьюер проверяет, разрешаете ли вы меняющееся many-to-many распределение на рабочей гранулярности, а не передаёте его неоднозначному пути фильтрации Power BI.

bitableaudashboards

Я бы задал основную таблицу фактов продаж на уровне одной строки заказа и не повторял бы меры заголовка как аддитивные значения.

Количество товара, выручка строки и скидка строки принадлежат непосредственно таблице фактов на 25 миллионов строк.
Доставка может находиться в отдельной таблице фактов заголовков заказов или распределяться по строкам по документированному правилу, например пропорционально выручке.
Расчёты Tableau используют выбранное представление доставки последовательно, а тест гранулярности проверяет уникальность пары ID заказа и ID строки.

Зачем это спрашивают: Сильный ответ не позволяет столбцам разной гранулярности создавать правдоподобные, но завышенные итоги дашборда.

transactionsmodelingbi

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

Транзакционная таблица на 90 миллионов строк поддерживает аддитивные меры притока и оттока по дате проводки, счёту и типу транзакции.
Снимок содержит одну строку на счёт и дату конца месяца, явно задавая выбор отчётного остатка вместо восстановления каждого закрытия из всей истории.
Explores в Looker могут разделять views Account и Date, но меры остатка должны выбирать последний снимок и не должны суммироваться по месяцам.

Зачем это спрашивают: Интервьюер оценивает, выбираете ли вы типы фактов из BI-вопроса и аддитивности каждой меры.

bipower-bidrill-through

Я бы оставил TicketNumber вырожденным измерением и сначала сравнил 12 флагов как столбцы факта с вариантом мусорного измерения.

TicketNumber остаётся в факте, потому что отдельное измерение на 18 миллионов строк без других атрибутов добавляет связь, но не уменьшает гранулярность.
VertiPaq часто хорошо сжимает 12 низкокардинальных Boolean-столбцов; мусорное измерение оправдано, только если наблюдаемые сочетания и управляемые подписи измеримо уменьшают модель или упрощают срезы.
В обоих вариантах я открою бизнес-подписи, скрою суррогатные ключи и проверю drill-through по TicketNumber и размер модели через VertiPaq Analyzer.

Зачем это спрашивают: Вопрос проверяет, применяете ли вы размерные шаблоны по измерениям, а не предполагаете, что мусорное измерение всегда лучше сжимает модель Power BI.

bidbttableau

Я бы создавал предварительные записи поставщиков, чтобы каждое требование сохраняло корректный ключ измерения в течение 24-часового окна отчётности.

Отсутствующий бизнес-ключ поставщика сопоставляется минимальной суррогатной строке с признаком Inferred, а не null-ключу и не удалённому требованию.
Когда атрибуты поставщика приходят, dbt обновляет эту предварительную строку на месте, поэтому факту на 5 миллионов строк не требуется смена ключа.
Тесты данных отслеживают возраст неразрешённых предварительных записей, а Tableau подписывает их Pending Provider, не смешивая с действительно неизвестными данными.

Зачем это спрашивают: Интервьюер оценивает, как вы сохраняете полноту фактов, пока поздние измерения догоняют SLA дашборда.

bipower-bidax

CALCULATE выполняет переход контекста, превращая текущий контекст строки итератора в контекст фильтра для вычисления меры.

SUMX создаёт контекст строки для входной таблицы, но обычная агрегация не фильтрует модель по текущей строке автоматически.
Обёртка агрегации в CALCULATE или вызов существующей меры с неявным CALCULATE применяет столбцы текущей строки как фильтры.
Я бы не итерировал 30 миллионов строк фактов, если та же мера отчёта может пройти по меньшей таблице Product или сводной таблице нужной гранулярности.

Зачем это спрашивают: Интервьюер проверяет понимание контекста вычисления DAX и связь корректности с решениями о масштабе модели.

measuresdaxmodeling

Я бы фильтровал измерение Product или компактный набор товаров, а затем позволил связям распространить фильтр на факты.

CALCULATE может применить FILTER к таблице Product на 80 000 строк с мерой маржи на уровне товара или управляемым атрибутом прибыльности.
FILTER по всем 60 миллионам строк счетов обычно дороже и может задать семантику прибыльности на уровне строки вместо уровня товара.
До завершения меры я бы уточнил, означает ли прибыльность текущую классификацию каталога или прибыльность в выбранном периоде отчёта.

Зачем это спрашивают: Сильный ответ объединяет семантику CALCULATE, эффективную форму фильтра и точное определение показателя дашборда.

bipower-bicss

Я бы использовал SUMX для общей маржи строк и разделил её на общее количество вместо среднего значений UnitMargin.

Числитель проходит по строкам счетов и умножает Quantity на UnitMargin с учётом текущих фильтров ProductKey и DateKey.
Знаменатель суммирует Quantity в том же контексте фильтра, а DIVIDE возвращает blank или согласованный альтернативный результат при нулевом количестве.
Я бы сверил результат с SQL хранилища, потому что AVERAGEX по UnitMargin даёт одинаковый вес строке с одной единицей и строке с тысячей единиц.

Зачем это спрашивают: Интервьюер проверяет, реализуют ли итератор и знаменатель заявленное взвешивание по объёму, а не постороннее среднее процентов.

measuresdaxbi

Я бы один раз вычислил результат предыдущего периода в именованной переменной и повторно использовал это скалярное значение в итоговом выражении.

Переменные делают порядок вычислений видимым и не дают четырём копиям сложной ветки CALCULATE разойтись при изменениях.
Переменная вычисляется в контексте фильтра места объявления, поэтому перенос за пределы итератора или условия может изменить результат.
Я бы использовал доменные имена вроде PriorQuarterRevenue и SelectedTarget и сохранил отображаемое выражение модели из 25 таблиц достаточно коротким для ревью.

Зачем это спрашивают: Вопрос проверяет понимание и пользы переменных DAX для читаемости, и семантики их контекста вычисления.

bipower-bidashboards

Я бы использовал полное фискальное измерение Date с явными фискальными неделями и ключами сопоставимых периодов вместо григорианских сокращений.

Шестилетний календарь назначает каждой дате фискальный год, квартал, период, неделю и ключ сопоставимой недели прошлого года.
Меры выполняют сдвиг через эти фискальные атрибуты или calculation group, чтобы год из 53 недель следовал согласованному правилу сравнения розницы.
Я бы протестировал итоги периодов у границ фискального года, потому что предположения DATEADD и SAMEPERIODLASTYEAR могут неверно совместить календарь 4-4-5.

Зачем это спрашивают: Интервьюер оценивает, отражает ли time intelligence бизнес-календарь, а не просто использует встроенные функции дат.

bipower-bidashboards

Я бы сравнил 18 загруженных дней текущего периода с таким же завершённым срезом дней прошлого года.

Мера Last Complete Data Date берётся из watermark загрузки фактов, а не из TODAY, поскольку обновление в 07:00 может отставать от активности источника.
Текущий MTD и прошлогодний MTD фильтруют диапазоны Date по эквивалентному порядковому дню или сопоставленной бизнес-дате.
Подзаголовок дашборда показывает дату среза, чтобы пользователи знали, что более поздние дни прошлого года исключены.

Зачем это спрашивают: Сильный ответ предотвращает смещение неполного периода и связывает time intelligence с фактическим состоянием обновления.

bipower-bidax

Я бы определил Shipped Revenue через CALCULATE и USERELATIONSHIP между Date и Ship Date.

USERELATIONSHIP активирует существующую неактивную связь только для этой меры, а стандартная Order Revenue продолжает использовать Order Date.
В 45 миллионах строк фактов сохраняются оба ключа даты, а измерение Date остаётся единым источником атрибутов месяца и фискального периода.
Я бы сочетал визуализации по Ship Date с явно названными мерами отгрузки, поскольку общая мера Revenue продолжила бы следовать активному пути Order Date.

Зачем это спрашивают: Интервьюер проверяет точное использование неактивных связей и ясные семантические имена для авторов отчётов.

bipower-bidax

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

Несвязанная таблица остаётся поверхностью параметров и не создаёт физической связи с неоднозначными путями в semantic model.
TREATAS должен передавать стабильные ID кампаний, а не отображаемые имена, особенно для 20 000 целей с возможными одинаковыми подписями.
Я бы держал меры целей и факта раздельно и рассчитывал отклонение только после применения нужных фильтров отчёта к обеим.

Зачем это спрашивают: Вопрос проверяет, умеете ли вы намеренно создавать виртуальную связь, не скрывая семантику меры.

Закрытые вопросы

21
В казначейском дашборде Power BI есть 10 миллионов ежедневных остатков по счетам с пропусками в выходные; как рассчитать конечный остаток для любого выбранного месяца?
bipower-bidashboards
22
В модели Power BI есть 70 базовых мер, четыре сравнения по времени и три валюты отображения; как calculation groups сократят поверхность мер?
bipower-bimeasures
23
Матрица Power BI показывает процент маржи для 60 товаров, а общий итог не равен среднему видимых строк; это ошибка и как определить меру?
bipower-bicss
24
Матрица Power BI раскрывается от Region к Store для 1 200 магазинов и требует разную формулу промежуточного итога на каждом уровне; как управлять итогами в DAX?
bipower-bimatrix
25
Отчёту Power BI с 35 миллионами строк продаж нужна доля каждой категории в выбранных регионе и году; использовать ALL, ALLSELECTED или REMOVEFILTERS?
bipower-bi
26
В semantic model Power BI есть 90 мер, используемых 14 отчётами; как ветвление мер сохранит согласованность DAX-итогов и определений?
measuresdaxbi
27
Explore заказов в Looker соединяет 50 миллионов строк товаров заказа с клиентами, возвратами и промоакциями; как объявить связи и предотвратить fanout?
bilookerjoins
28
В проекте Looker есть 24 доменных Explores, повторяющих фискальные поля и логику статусов заказов; как переиспользовать LookML, не скрывая различия доменов?
bilookerlookml
29
Explore в Looker соединяет 12 миллионов заказов с несколькими платежами и отгрузками; когда symmetric aggregates защищают меры дашборда и что должна предоставить модель?
joinsaggregationbi
30
Финансовый дашборд Looker запрашивает журнал BigQuery на 300 миллионов строк и должен быть готов ежедневно к 08:00; как использовать PDT и datagroup?
queriesbigquerybi
31
Workbook Tableau показывает выручку 1 500 магазинов, а LOD FIXED по магазину игнорирует обычный фильтр Region; почему и как сделать поведение дашборда намеренным?
bitableaudashboards
32
В дашборде клиентов Tableau есть 9 миллионов покупок и нужно показать lifetime value клиента по сегменту и региону; когда использовать выражения LOD FIXED, INCLUDE или EXCLUDE?
bitableaudashboards
33
Матрица Tableau показывает месячные продажи для 40 регионов и требует накопительный итог и ранг внутри страны; как настроить addressing и partitioning табличных вычислений?
configbitableau
34
Workbook Tableau сканирует 70 миллионов событий, а фильтр Top 20 Customer должен применяться только внутри выбранного рынка; как контекстные фильтры изменят результат?
bitableau
35
В устаревшем кубе SSAS Multidimensional есть 600 миллионов ячеек продаж, а финансовому отчёту нужен переиспользуемый вычисляемый элемент Gross Margin; где определить его в MDX?
daxcss
36
Куб SSAS Multidimensional обслуживает 30 отчётов Excel и требует rolling 12-month set с учётом выбранного элемента календаря; как выразить и ограничить его в MDX?
excel
37
dbt-модель питает дашборд Power BI из 250 миллионов событий Snowflake с SLA обновления 45 минут; как спроектировать инкрементальную сборку?
bidbtpower-bi
38
Инкрементальная dbt-модель заказов питает Looker, а 2 процента из 80 миллионов строк приходят с опозданием до пяти дней; как выбрать окно повторной обработки?
bidbtlooker
39
dbt-март питает 18 workbook в Tableau и должен содержать одну строку на клиента в месяц; какие тесты данных обязательны до обновления?
bidbttableau
40
dbt-март выручки обслуживает 11 отчётов Power BI, а схема источника может еженедельно добавлять или удалять столбцы; как защитить контракт semantic model?
bidbtpower-bi
41
Pipeline Power Query объединяет 35 миллионов строк Orders с 4 миллионами строк Customers из одной базы SQL Server, но folding прекращается на пользовательской функции сегмента клиента, а обновление занимает 96 минут. Как изменить решение?
sqldatabasequeries
42
Политика инкрементального обновления Power BI хранит пять лет из 180 миллионов строк и обновляет последние семь дней; как folding Power Query должен использовать RangeStart и RangeEnd?
bipower-bipower-query
43
DAG в Cloud Composer должен публиковать финансовый дашборд Looker к 07:30 после завершения трёх источников BigQuery и dbt-марта; как смоделировать зависимости?
dependenciesbidbt
44
Airflow-пайплайн обновляет dataset Power BI из 22 таблиц к 06:00, но два измерения могут приходить на 90 минут позже фактов; как обработать зависимости и поздние данные?
dependenciesbiairflow
45
Вы владеете semantic model Power BI с таблицей фактов продаж на 140 миллионов строк, восемью измерениями и 16 thin reports; как структурировать её для переиспользования?
bipower-bimodeling
46
Semantic model Power BI обслуживает 4 000 сотрудников в 12 регионах, а менеджеры могут видеть несколько регионов; как спроектировать динамический RLS?
designsemantic-layerbi
47
Три semantic models Power BI содержат 6 миллионов строк клиентов и используют разные уровни клиентов; как создать общие измерения для кросс-доменных дашбордов?
bipower-bidashboards
48
Модель Power BI открывает 110 мер для 25 авторов отчётов; какие правила именования и стиля вы установите?
bipower-bimeasures
49
Сертифицированная модель Power BI питает 30 self-service отчётов из 70 миллионов строк; что разрешить менять авторам отчётов, а что оставить централизованным?
bipower-bi
50
Semantic model Power BI поддерживает финансовые и торговые дашборды из таблицы фактов на 200 миллионов строк, и обе команды хотят собственную иерархию Product; как установить границу?
bipower-bidashboards
51
Страница продаж в Power BI с 14 визуалами становится интерактивной за 9,2 секунды при целевом времени менее 4 секунд. Как вы локализуете узкое место?
bipower-bitracking
52
DAX Studio показывает меру длительностью 8,4 секунды: 7,1 секунды в formula engine и 1,0 секунды в storage engine на модели из 90 миллионов строк. Что вы делаете дальше?
measuresdax
53
Модель Power BI на 220 миллионов строк выросла с 1,4 до 3,8 ГБ после добавления ID транзакции и временной метки. Как вернуть приемлемый размер, не сломав drill-through?
bipower-bitransactions
54
На одной странице Power BI размещено 28 визуалов, и при каждом изменении слайсера отправляется 64 запроса, из-за чего ожидание достигает 12 секунд. Как вы переделаете страницу?
bipower-biqueries
55
Визуал удержания клиентов строится 6,7 секунды, потому что мера DISTINCTCOUNT сканирует 180 миллионов строк фактов для каждого месяца. Как вы ускорите его в Power BI?
retentionmeasuresdax
56
У отчёта Power BI в режиме DirectQuery p95 задержки визуала составляет 18 секунд при работе со Snowflake, но тот же SQL выполняется в хранилище за 5 секунд. Как найти пропавшие 13 секунд?
sqlwarehousesnowflake
57
В composite-модели Power BI вчерашняя импортированная выручка показана рядом с живыми заказами DirectQuery, из-за чего за текущий день возникает расхождение 2,6 процента. Как исправить поведение модели?
bipower-bi
58
Executive-дашборд в DirectQuery сканирует 400 миллионов строк при каждом взаимодействии, хотя руководители смотрят только дневные итоги по регионам. Какой дизайн Power BI вы протестируете?
bipower-bidesign
59
Обновление датасета Power BI успешно завершается за 22 минуты, но потребляет на пике 9 ГБ и вытесняет две другие модели из capacity на 10 ГБ. Как сократить потребление?
bipower-bicapacity
60
Релиз ускоряет страницу Power BI с 7,5 до 3,1 секунды на ноутбуке разработчика, но production-цель требует p95 ниже 4 секунд для 300 пользователей. Какие доказательства нужны до деплоя?
deploymentbipower-bi
61
Tableau workbook с 36 листами открывается 14 секунд при целевом времени команды 5 секунд. Как определить, проблема в запросах, вычислениях или layout?
bitableauqueries
62
Tableau extract на 480 миллионов строк обновляется 95 минут и дважды в неделю пропускает окно публикации 06:00. Что вы измените?
bitableau
63
Live-дашборд Tableau отправляет 18 запросов в Snowflake и потребляет 22 кредита за 30-минутный региональный review. Как ускорить его, не потеряв drill-путь?
queriessnowflakebi
64
Tile подписок в Looker показывает итоги по месяцу, тарифу и региону, но сгенерированный SQL включает SubscriptionID и возвращает 3 миллиона строк за 72 секунды. Как исправить путь запроса?
sqlqueriesbi
65
PDT Looker по 2,1 миллиарда событий BigQuery перестраивается 80 минут каждую ночь, хотя изменяться могут только две последние даты событий. Как сделать её инкрементальной и не пропустить исправления?
bilookerbigquery
66
Расход Snowflake на BI вырос со 110 до 180 кредитов в день после запуска трёх новых дашбордов, а weekly active users увеличились только на 5 процентов. Как найти и сдержать рост?
dashboardssnowflakezero-to-one
67
Дашборд на BigQuery тарифицирует 11 ТиБ при каждом почасовом обновлении, хотя пользователям нужны только последние 30 дней. Что вы измените?
dashboardsbigquery
68
Looker-дашборд повторяет одну дневную агрегацию выручки в 12 tiles, создавая 12 похожих заданий BigQuery и 6 ТБ тарифицируемых данных за загрузку. Как это сократить?
aggregationbigquerybi
69
В 08:00 приходят 120 пользователей Tableau, пока выполняются два extract refresh, и p95 загрузки растёт с 4 до 19 секунд. Как стабилизировать сервис?
bitableau
70
Инкрементальное обновление Power BI для факта SQL Server на 180 миллионов строк выросло с 18 до 74 минут после Merge Queries с локальным CSV-справочником. Как восстановить путь запроса?
sqlqueriesjoins
71
Power BI показывает monthly recurring revenue на 4,8 процента выше Looker для тех же 12 400 аккаунтов. Как вы проведёте сверку?
bipower-bilooker
72
Тест RLS в Power BI показывает, что 37 региональных менеджеров видят карточку национального итога, хотя детальные строки ограничены правильно. Как вы реагируете?
bipower-birow-level-security
73
Calculation group валюты в Power BI форматирует Margin Percent как доллары и конвертирует YoY Percent после добавления нового элемента времени. Как исправить взаимодействие?
bipower-bicss
74
HR-модель Power BI использует RLS для ограничения менеджеров по отделам, но SalaryAmount также должен быть недоступен роли Manager через Analyze in Excel. Достаточно ли скрыть поле?
excelbipower-bi
75
UAT finance-дашборда выявил 23 дефекта за два дня до закрытия месяца: 5 расхождений KPI и 18 проблем layout или фильтров. Как восстановить релиз?
defectsuatdashboards
76
Executive-отчёт говорит, что обновлён в 07:00, но источник показывает, что последнему заказу соответствует 23:00 прошлого дня в 4 из 10 последних дней. Как исправить сигнал устаревшего отчёта?
77
Weekly active users дашборда customer success упали с 420 до 210 за 8 недель при неизменном размере команды. Как исследовать снижение adoption?
dashboardsdecision-making
78
Новый релиз семантической модели изменяет историческую конверсию с 18,2 до 16,9 процента за 24 месяца, но в release note указана только чистка названий. Что вы делаете?
79
После добавления связи many-to-many между клиентом и территорией один дашборд Power BI завышает выручку на 12 процентов только при выборе двух регионов. Как найти причину?
bipower-bidashboards
80
В вашем домене 3 устаревших отчёта, 2 противоречивых executive-KPI и 1 нестабильный refresh перед встречей в 09:00. Как расставить приоритеты на следующие 4 часа?
prioritization
81
Четыре stakeholder-команды прислали 27 запросов для нового operations-дашборда, но на работу есть только 6 недель. Как провести discovery?
dashboardscommunicationstakeholder-management
82
Вы получаете BI-домен customer success с 45 отчётами, 17 отсутствующими владельцами и 3 разными расписаниями refresh. Как выглядит ownership в первые 30 дней?
ownership
83
Sales, finance и product используют три определения net revenue с расхождением 7 процентов, и все хотят свою версию на общем дашборде. Как создать metric contract?
dashboardsmonitoring
84
Восемьдесят self-service пользователей Looker создали 26 несовместимых полей выручки за 3 месяца. Какие guardrails добавить, не закрывая exploration?
bilookerguardrails
85
На 60-минутном workshop sales хочет считать pipeline по created date, а finance настаивает на expected-close date, что даёт квартальное расхождение 15 процентов. Как решить конфликт?
ci-cd
86
VP просит дашборд из 70 визуалов, повторяющий ежемесячный PDF на 42 страницы, но usage logs показывают, что только 9 страниц смотрят более 5 человек. Что вы отклоните?
dashboards
87
Региональный директор просит отключить RLS на 2 дня, чтобы 14 менеджеров экспортировали национальный список клиентов перед планированием. Как вы ответите?
row-level-security
88
Operations просит свежесть дашборда 5 минут, но источник поступает раз в час, а предложенное изменение добавит 600 долларов в день к стоимости хранилища. Что нужно отклонить или пересогласовать?
dashboardswarehouse
89
Пятьдесят пять web-авторов Tableau создали 18 extracts с четырьмя определениями выручки, а управляемый источник должен обновляться к 07:00 и сохранять фильтры прав уровня строк. Какую границу self-service вы установите?
bitableauboundaries
90
В вашем BI-домене есть capacity на 4 изменения в квартал, но поступило 18 запросов на дашборды от 6 команд. Как выбрать задачи и не стать очередью тикетов?
dashboardscapacitydata-structures
91
Нужно консолидировать 32 marketing-отчёта максимум в 8, сохранив workflow 140 weekly users. Как провести миграцию?
migrations
92
Четырнадцать дашбордов получили менее 3 просмотров каждый за 90 дней, но по-прежнему выполняют 48 плановых refresh в день. Как безопасно вывести их из эксплуатации?
dashboards
93
LookML PR добавляет 18 полей и меняет join с many_to_one на many_to_many для Explore, который используют 24 дашборда. Что вы проверите до approval?
dashboardsjoinsbi
94
dbt PR меняет customer_month с одной строки на клиента в месяц на customer-product-month и питает 17 BI-дашбордов. Как провести review?
dbtdashboards
95
Семантическая модель Power BI обслуживает 11 отчётов и должна пройти development, test и production с перерывом менее 15 минут. Как спроектировать deployment pipeline?
deploymentbici-cd
96
Релиз Tableau workbook меняет 9 вычислений, используемых в 6 дашбордах. Какой regression suite нужен до публикации?
bitableauregression
97
Looker-дашборд выручки 6 раз за месяц нарушил SLO свежести к 07:00, а среднее восстановление заняло 94 минуты. Какой мониторинг и runbook вы добавите?
monitoringbirunbooks
98
Стоимость хранилища для одного дашборда удвоилась после релиза с 35 до 70 долларов в день, но refresh не падает. Как это мониторить и исправлять?
dashboardsmonitoringwarehouse
99
Через 10 минут после деплоя семантической модели падают 8 из 20 smoke tests отчётов Power BI, а доля ошибок refresh растёт до 30 процентов. Что вы делаете?
deploymentbipower-bi
100
Junior BI-разработчик должен за 5 дней добавить новый сегмент churn в Looker-дашборд для 85 account managers. Как вы проведёте его через изменение?
bilookermentoring

Вопросы

3В модели заказов Power BI есть Order Date, Ship Date и Delivery Date для 40 миллионов строк; как поддержать все три календарных представления без неоднозначных связей?

6В воронке продаж Looker есть 3 миллиона возможностей и семь этапов от создания до оплаты; как смоделировать длительность этапов и текущий backlog?

7Дашборд запасов Power BI хранит ежедневные данные по 15 000 товаров на 120 складах за два года; как смоделировать остатки и движения?

11В модели поддержки Power BI есть 18 миллионов тикетов, 12 флагов с низкой кардинальностью и номера тикетов для страниц drill-through; где разместить эти атрибуты?

13Почему в модели Power BI с 30 миллионами строк продаж CALCULATE внутри SUMX может вернуть другой результат, чем SUMX с обычным выражением SUM?

14В дашборде маржи Power BI есть 60 миллионов строк счетов; как написать меру CALCULATE для выручки прибыльных товаров без построчной фильтрации всей таблицы фактов?

15В отчёте ценообразования Power BI есть 12 миллионов строк с разными количествами и маржой на единицу; какой итератор DAX использовать для взвешенной маржи на единицу?

16Мера DAX в модели Power BI из 25 таблиц четыре раза повторяет одно выражение предыдущего периода; как переменные изменят её поведение и сопровождаемость?

17Розничная модель Power BI использует фискальный календарь 4-4-5 за шесть лет; как реализовать годовые сравнения в дашборде?

18Дашборд руководства в Power BI обновляется ежедневно в 07:00, а в текущем месяце загружено только 18 дней; как сделать годовое сравнение MTD корректным?

19В логистической модели Power BI есть 45 миллионов заказов, активная связь по Order Date и неактивная по Ship Date; как рассчитать отгруженную выручку по месяцам?

20Модель Power BI сравнивает 20 000 целевых значений кампаний с 80 миллионами строк продаж, но таблица целей намеренно не связана; как применить выбранные кампании в DAX?

Закрытые вопросы