Вы поддерживаете 220 аналитиков и руководителей, которые используют 14 семантических моделей Power BI и 90 дашбордов поверх 1,2 ТБ данных продаж и финансов; годовой бюджет платформы равен 180 000 долларов, свежесть должна оставаться в пределах 30 минут, а архитектура должна прослужить 12 месяцев. Вы построите одну корпоративную модель или доменные модели?

Я построю семантические модели с владельцами по доменам, согласованными измерениями и тонкими отчётами, а не одну корпоративную модель. - Продажи и финансы получат по звёздной схеме с назначенным BI-владельцем, а Date, Customer, Product и утверждённое определение выручки будут поступать из версионируемых общих контрактов. - Минимум 70 из 90 дашбордов должны стать тонкими отчётами поверх 6-8 сертифицированных моделей; переход с 14 до 8 сокращает число поверхностей моделей на 43 процента, но экономию refresh нужно измерить, а не выводить из этого числа. - Архитектурное решение ограничит модель явным бизнес-грануляром и 20-минутным бюджетом refresh, оставив 10 минут на загрузку и проверку в рамках 180 000 долларов.

Среда Fabric обслуживает 320 аналитиков через 18 семантических моделей и 140 дашбордов Power BI на 8 ТБ в OneLake; годовой бюджет capacity равен 260 000 долларов, SLO свежести составляет 15 минут, горизонт планирования равен 18 месяцам. Как вы организуете семантический слой Direct Lake?

Я размещу доменные модели Direct Lake с владельцами поверх подготовленных таблиц OneLake, а междоменные определения вынесу в явные общие контракты. - Команды финансов, продаж, операций и клиентов владеют грануляром модели, мерами и оперативными метаданными, а согласованные измерения публикуются один раз с тестами совместимости. - Я сокращу 18 моделей примерно до 10 переиспользуемых и сохраню тонкие отчёты; уменьшение на 44 процента убирает восемь поверхностей владения и релиза, а фактическая экономия CU и поддержки остаётся измеряемым результатом. - Архитектурная запись потребует p95 визуалов ниже 5 секунд и возраст данных ниже 15 минут, а Capacity Metrics будут пересматриваться при устойчивой загрузке 70 процентов до расходов сверх 260 000 долларов.

В компании 180 аналитиков, 12 моделей LookML с 24 Explore в Looker, 75 дашбордов и 3 ТБ в BigQuery; годовые расходы на Looker и хранилище равны 220 000 долларов, p95 запросов дашбордов должен быть ниже 20 секунд, а модели должны поддерживать следующий год. Как вы структурируете проекты LookML?

Я создам управляемый основной проект LookML и доменные проекты, импортирующие стабильные общие определения. - Основной проект владеет каноническими пользователями, датами, счетами, фискальной логикой и 12 метриками правления; доменные CODEOWNERS утверждают представления продаж, продукта и финансов на заявленном грануляре. - Я сокращу 24 пересекающихся Explore до 10-12 подготовленных и буду держать покрытие переиспользуемыми полями выше 80 процентов, обменивая часть локальной свободы на меньшее число конфликтующих join. - Манифест проекта, каталог семантики и проверка стоимости запросов заблокируют merge, если p95 превысит 20 секунд или прогноз BigQuery увеличит годовой темп расходов 220 000 долларов более чем на 10 процентов.

Шесть доменных проектов Looker импортируют общий проект LookML со 140 управляемыми полями; изменение базового view должно дойти до 110 дашбордов без нового ломающего rollout, а интерактивный p95 должен остаться ниже 15 секунд. Как версионировать и выпускать зависимость?

Я буду считать общий проект LookML версионируемым контрактом и переводить потребителей через закреплённые ссылки на зависимость вместо неограниченной последней версии. - Владелец платформы классифицирует аддитивные и ломающие изменения, публикует release manifest для всех 140 полей и сохраняет предыдущую major-ссылку на 60-дневное окно миграции. - CI проверяет каждый из 6 потребляющих проектов через LookML validation, Content Validator, 30 golden queries, access-фикстуры и сравнение p95 до продвижения ссылки на зависимость. - Rollout закрывается, когда все 110 дашбордов используют одобренную ссылку, метрики совпадают точно, p95 остаётся ниже 15 секунд и ни один потребитель не остаётся на удаляемой major-версии.

Развёртывание Cube обслуживает 450 аналитиков и руководителей через 16 моделей данных Cube и 130 встроенных дашбордов поверх 12 ТБ в Snowflake; годовой бюджет равен 260 000 долларов, p95 ответа должен быть ниже 3 секунд, горизонт проектирования равен 18 месяцам. Как вы сформируете семантический слой?

Я определю доменные cubes на стабильном бизнес-грануляре и опубликую пользовательские views поверх выборочных pre-aggregations. - Orders, subscriptions, marketing spend и support cases получают ответственных владельцев, проверенные join и общие измерения, а views открывают 130 дашбордам только утверждённые меры. - История запросов определяет дневные и месячные rollup для 80 процентов самых частых запросов; я не буду предварительно агрегировать каждую комбинацию, потому что стоимость хранения и refresh растёт мультипликативно. - Манифест моделей требует p95 ниже 3 секунд, свежесть pre-aggregation ниже 15 минут и годовой темп расходов Snowflake плюс Cube не выше 260 000 долларов с пересмотром при достижении 70 процентов любого лимита.

В предприятии 380 BI-пользователей, 20 семантических моделей разделены между Power BI и Looker, есть 200 дашбордов и 25 ТБ в Snowflake; общие расходы на BI равны 600 000 долларов в год, метрики разных инструментов должны совпадать на 99 процентов, целевое состояние нужно получить за 12 месяцев. Где должна жить каноническая семантика?

Я закреплю бизнес-грануляр и аддитивные факты в управляемых витринах хранилища, а презентационную семантику сохраню нативной для каждого BI-инструмента. - Версионируемые контракты один раз определяют заказ, клиента, фискальный календарь и конвертацию валют; меры DAX и поля LookML могут различаться только там, где этого требует модель взаимодействия. - Набор reconciliation-тестов ежедневно сравнивает 25 критических метрик в обоих инструментах и блокирует выпуск ниже 99 процентов совпадения, а назначенный владелец домена разбирает каждое исключение. - Перестройка обоих инструментов вокруг 8 общих витрин уменьшает число изолированных путей трансформации с 20 на 60 процентов, но именно измеренные compute, поведение cache и стоимость поддержки решают, укладывается ли дизайн в 600 000 долларов.

Пять бизнес-юнитов имеют 500 пользователей Power BI, 22 семантические модели, 240 дашбордов и 4 ТБ импортированных данных; годовая стоимость равна 350 000 долларов, дашборды закрытия месяца должны быть готовы к 06:00, архитектура должна служить два года. Как вы зададите границы моделей и владение?

Я сопоставлю границы моделей с бизнес-процессами, имеющими ответственных, и буду делиться измерениями через контракты, а не через цепочки владения. - Финансы владеют моделями ledger и close, продажи владеют pipeline, операции владеют fulfillment; каждая модель объявляет грануляр, steward, уровень поддержки и число зависимых дашбордов. - Customer, legal entity, product и fiscal calendar получают версионируемые ключи и reconciliation-тесты, а междоменные отчёты объединяют сертифицированные результаты вместо создания 22 вариантов. - Я нацелен на 12-14 моделей и выведу остальные только после назначения владельцев для 95 процентов из 240 дашбордов, сохраняя 90-минутное окно refresh до 06:00 и бюджет 350 000 долларов.

Организация Looker поддерживает 140 аналитиков, 12 моделей LookML, 65 дашбордов и 2 ТБ в BigQuery; годовые расходы равны 160 000 долларов, новый домен должен публиковать управляемую аналитику за 10 рабочих дней, операционная модель должна работать 18 месяцев. Кто чем должен владеть?

Я применю федеративное доменное владение, а небольшая платформенная команда будет отвечать за семантический контракт и путь выпуска. - Четыре доменные команды владеют views, мерами, качеством дашбордов и поддержкой пользователей, а команда BI-платформы владеет шаблонами проектов, общими измерениями, правилами доступа и production deployment. - CODEOWNERS требует одного доменного и одного платформенного ревьюера для общего LookML; цель 10 дней делится на 3 дня моделирования, 3 проверки и 4 пользовательской приёмки. - Ежеквартальная матрица владения отмечает модели без активного владельца или с менее чем 5 месячными пользователями, удерживая поддержку в бюджете 160 000 долларов вместо централизации каждого изменения.

В tenant Power BI есть 300 пользователей, 18 семантических моделей, 150 дашбордов и 9 ТБ исходных данных; годовая стоимость равна 280 000 долларов, изменения метрик должны доходить до всех управляемых отчётов за 5 рабочих дней, роадмап охватывает два года. Как вы повысите переиспользование мер без гигантской модели?

Я стандартизирую контракты мер и шаблоны вычислений, оставив факты в семантических моделях доменного размера. - Реестр метрик хранит формулу, грануляр, владельца, измерения и дату вступления в силу; переиспользуемые calculation groups обрабатывают временную аналитику и валюты вместо копирования DAX в 18 моделей. - Исходники TMDL и автоматический анализ зависимостей находят 150 затронутых дашбордов, а целевое покрытие мер, созданных или проверенных по реестру, составляет 90 процентов. - Шаблон выпуска оставляет 2 дня на impact analysis, 2 на PR моделей и 1 на deployment, допуская ограниченное дублирование, когда централизация нарушит размер модели, задержку или capacity-лимит 280 000 долларов.

SaaS-компания обслуживает 80 внутренних аналитиков и 400 клиентов через 14 моделей Cube и 80 встроенных дашбордов поверх 5 ТБ; годовая стоимость платформы ограничена 200 000 долларов, p95 запросов должен быть ниже 2 секунд, горизонт продукта равен 24 месяцам. Как вы спроектируете владение и переиспользование?

Я отделю внутреннее доменное владение от подготовленного embedded-контракта, на который могут опираться продуктовые команды. - Владельцы доменов сопровождают cubes заказов, биллинга, использования и поддержки, а владелец embedded analytics публикует стабильные views и версионируемый каталог мер для 80 дашбордов. - Общие pre-aggregations покрывают 20 форм запросов, создающих минимум 80 процентов трафика; tenant-specific rollup добавляются только при измеримом выигрыше у общих по задержке и хранению. - Набор тестов совместимости и ежемесячный cost scorecard блокируют breaking changes, p95 выше 2 секунд или годовой темп расходов выше 200 000 долларов, обменивая произвольные клиентские поля на предсказуемый API на 24 месяца.

У вас 260 пользователей Power BI, 9 семантических моделей, 70 дашбордов и 1,8 ТБ в Azure SQL; годовые расходы ограничены 140 000 долларов, данные могут отставать на 30 минут, решение должно работать 18 месяцев. Вы выберете Import или DirectQuery?

Я выберу Import с incremental refresh, потому что допустимая свежесть 30 минут не оправдывает интерактивные запросы, завязанные на источник. - Большие факты партиционируются по дате, каждые 30 минут обновляются только последние 2 дня, а измерения импортируются полностью, чтобы дашборды работали через in-memory движок. - Тестирование capacity должно удержать refresh в пределах 20 минут и p95 визуалов ниже 4 секунд; DirectQuery останется исключением для drill-through полей, которые нельзя хранить. - Архитектурная запись сравнивает память импортированной модели и 48 refresh в день со стоимостью concurrency Azure SQL, выбирая вариант дешевле 140 000 долларов в год.

Программа Fabric обслуживает 350 пользователей через 12 семантических моделей и 100 дашбордов поверх 6 ТБ Delta-таблиц в OneLake; годовой бюджет F64 равен 240 000 долларов, нужна свежесть 10 минут, план рассчитан на два года. Вы выберете Direct Lake или Import?

Я сделаю Direct Lake вариантом по умолчанию для подготовленных Delta-таблиц, а неподдерживаемые шаблоны изолирую в небольших Import-моделях. - Direct Lake устраняет копирование 6 ТБ в плановые импорты и позволяет семантическим моделям читать OneLake, но каждой таблице нужны стабильный грануляр, оптимизированные файлы и поддерживаемое поведение безопасности. - Проба на 20 самых загруженных страницах должна удерживать p95 ниже 5 секунд и возраст данных ниже 10 минут; любое переключение на DirectQuery или достижение guardrail фиксируется, а не принимается молча. - Capacity Metrics должны оставаться ниже 70 процентов устойчивой нагрузки при 20 000 долларов в месяц, а исключение Import оправдано, когда его сжатие и предсказуемый кеш дешевле настройки lake-пути.

Диспетчерская операция имеет 180 пользователей, 6 семантических моделей Power BI, 45 дашбордов и 900 ГБ в Azure SQL; годовая стоимость равна 200 000 долларов, операционные данные должны быть моложе 2 минут при p95 визуалов ниже 5 секунд, горизонт проектирования равен одному году. Подходит ли DirectQuery?

Я применю DirectQuery для узкого операционного среза и уберу историческую аналитику из этого пути. - Источник получает индексированные serving views на грануляре диспетчера, автомобиля и 5 минут, а 12 месяцев истории импортируются в отдельную модель для трендов. - Я проведу нагрузочный тест 180 пользователей на двойном ожидаемом пике, потребовав p95 ниже 5 секунд и менее 30 одновременных запросов к источнику после сокращения запросов визуалов и страниц. - Телеметрия Azure SQL и capacity делит годовой лимит 200 000 долларов; если compute источника вырастет более чем на 20 процентов, Import-агрегация или более короткое живое окно дешевле бесконечного масштабирования DirectQuery.

У ритейлера 420 пользователей Power BI, 15 семантических моделей, 180 дашбордов и 7 ТБ данных заказов; годовой бюджет равен 300 000 долларов, сегодняшним продажам нужна свежесть 5 минут, а старые данные можно обновлять ежедневно, архитектура должна служить 24 месяца. Как вы примените composite model?

Я объединю импортированные историю и агрегаты с DirectQuery только для детальных заказов текущего дня. - Измерения Date, Store и Product в Dual mode обслуживают оба пути, Import-агрегат хранит метрики магазин-час за два года, а DirectQuery покрывает текущий рабочий день. - Aggregation mappings должны обслуживать минимум 90 процентов запросов 180 дашбордов из памяти с p95 ниже 4 секунд, оставляя живую детализацию осознанно более медленным drill-through. - Проектный документ ограничивает живой срез 50 миллионами строк, а общий темп расходов 25 000 долларов в месяц, принимая сложность источника ради свежести 5 минут только там, где пользователи могут действовать.

Маркетплейс обслуживает 500 пользователей Power BI через 10 семантических моделей и 220 дашбордов, запрашивающих 30 ТБ; годовая стоимость хранилища и BI равна 450 000 долларов, p95 визуалов должен быть ниже 4 секунд при свежести 15 минут, план охватывает 18 месяцев. Как вы спроектируете агрегации?

Я построю Import-агрегации по наблюдаемому грануляру дашбордов и сохраню DirectQuery-детализацию для исключительного исследования. - Rollup заказ-день-категория-регион и продавец-час покрывают основные меры, а relationships и aggregation mappings сохраняют доступ к детальной таблице на 30 ТБ. - Логи запросов должны показать минимум 90 процентов попаданий в агрегаты на 50 главных страницах и p95 ниже 4 секунд; неиспользуемые rollup удаляются через 30 дней. - Для каждого rollup нужна оценка хранения, refresh и сканирования хранилища, а портфель отклоняется, если годовой прогноз превысит 450 000 долларов, даже когда ещё одна агрегация ускоряет отдельный дашборд.

У платёжной команды 300 пользователей Power BI, 8 семантических моделей, 95 дашбордов и 12 ТБ с ростом 500 ГБ в день; годовые расходы ограничены 220 000 долларов, последнему часу нужна свежесть 5 минут, а истории достаточно ежедневного обновления, горизонт равен одному году. Как вы настроите incremental refresh?

Я применю incremental refresh для ограниченных исторических партиций и гибридную DirectQuery-партицию только для текущего часа. - При росте 500 ГБ в день я не стану импортировать 24 месяца сырых транзакций; модель хранит только проверенное тестом недавнее окно детализации и дневные агрегаты по продавцам за 24 месяца, а сырая история остаётся в хранилище для drill-through. - RangeStart, RangeEnd, надёжная колонка обнаружения изменений и reconciliation партиций хранятся в source control; партиции с поздними данными обновляются ежедневно, а индексированная live-партиция ограничена последними 60 минутами. - Стоимость capacity и источника должна оставаться не выше 220 000 долларов в год, а гибридный путь убирается, если пятиминутные данные нужны менее чем 10 процентам пользователей или стоимость источника вырастет на 20 процентов.

В компании 40 авторов и 360 читателей Power BI, 20 семантических моделей, 160 дашбордов и 5 ТБ исходных данных; за три года можно потратить 330 000 долларов, нужна доступность 99,5 процента, численность стабильна. Вы выберете Pro, Premium Per User или Fabric capacity?

Я выберу зарезервированную capacity F64 плюс Pro-лицензии для 40 авторов, если проверка нагрузки покажет, что лимитов общей Pro-capacity недостаточно. - По указанным ценам Pro для всех 400 пользователей стоит 400 умножить на 14 долларов и 36 месяцев, то есть 201 600 долларов; PPU стоит 400 умножить на 24 доллара и 36 месяцев, то есть 345 600 долларов, поэтому PPU уже превышает лимит 330 000 долларов. - Резервация F64 по 95 000 долларов в год плюс Pro для авторов стоит 305 160 долларов за три года; читателям всё равно нужны учётные записи Fabric Free и доступ к контенту на F64 или более крупной capacity. - Решение проверяет размер моделей, частоту refresh и concurrency нагрузочным тестом, а доступность по контракту сервиса и recovery drills; Pro побеждает, если проходит лимиты общей capacity, потому что он дешевле на 103 560 долларов.

Tenant Fabric обслуживает 480 пользователей с 25 семантическими моделями, 210 дашбордами и 18 ТБ в OneLake; бюджет capacity на 18 месяцев равен 500 000 долларов, 99 процентов визуалов должны отображаться за 5 секунд, пиковая нагрузка равна 1200 запросам визуалов в минуту. Как вы определите размер capacity?

Я определю размер по репрезентативному тесту concurrency и Capacity Metrics, а не по 18 ТБ хранения. - Я воспроизведу 30 самых загруженных страниц при 1200 запросах визуалов в минуту одновременно с плановым refresh и framing Direct Lake, затем запишу интерактивное и фоновое потребление CU по item. - Начну с минимального SKU, где p99 интерактивной задержки равен нулю, p99 визуалов ниже 5 секунд, а устойчивая загрузка ниже 70 процентов; затем проверю следующий SKU для запаса роста. - Мемо по sizing сравнивает резервацию и scale-up на 18 месяцев и сохраняет 20 процентов бюджета в резерве, поэтому утверждённая база не может превышать 400 000 долларов до contingency.

В группе 350 пользователей Power BI, 18 семантических моделей, 140 дашбордов и 8 ТБ финансовых и self-service данных; годовые расходы capacity равны 300 000 долларов, finance refresh должен завершаться к 06:00 в 99,9 процента случаев, схема должна работать 24 месяца. Разделите ли вы нагрузки между capacity?

Я изолирую production-финансы от разработки и всплесков self-service, сохранив низкорисковые домены вместе. - Одна зарезервированная production capacity содержит сертифицированные финансовые модели и 60 критических дашбордов; меньшая pay-as-you-go capacity содержит разработку и 80 self-service дашбордов и ставится на паузу вне рабочих часов. - Назначение workspaces, deployment pipelines и матрица маршрутизации capacity становятся контрольными артефактами, а финансы сохраняют 30 процентов запаса в окне refresh с 04:00 до 06:00. - Я утвержу разделение, только если обе capacity вместе с операциями остаются в общем месячном лимите 25 000 долларов; иначе временное разделение нагрузок на одной более крупной capacity будет дешевле.

В региональной компании 240 BI-пользователей, 12 семантических моделей Fabric, 90 дашбордов Power BI и 4 ТБ в OneLake; двухлетний compute-бюджет равен 180 000 долларов, production работает постоянно, разработка используется 50 часов в неделю, p95 дашбордов должен быть ниже 6 секунд. Как вы купите и запланируете Fabric capacity?

Я зарезервирую стабильную production capacity и применю pausable pay-as-you-go capacity для разработки. - Предложение поставщика на 90 000 долларов за два года резервации против 150 000 долларов pay-as-you-go делает резервацию рациональной для production-базы 24 на 7. - Разработка использует около 2600 часов в год вместо 8760; по указанной цене 5 долларов в час она стоит 26 000 долларов за два года, если автоматизация ставит её на паузу без активных jobs. - Capacity-план включает месячные пороги p95 ниже 6 секунд и загрузки 70 процентов, оставляя 64 000 долларов из бюджета 180 000 на краткие production scale-up и рост.

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

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

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

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

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

Вопросы

semantic-layerbipower-bi

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

Продажи и финансы получат по звёздной схеме с назначенным BI-владельцем, а Date, Customer, Product и утверждённое определение выручки будут поступать из версионируемых общих контрактов.
Минимум 70 из 90 дашбордов должны стать тонкими отчётами поверх 6-8 сертифицированных моделей; переход с 14 до 8 сокращает число поверхностей моделей на 43 процента, но экономию refresh нужно измерить, а не выводить из этого числа.
Архитектурное решение ограничит модель явным бизнес-грануляром и 20-минутным бюджетом refresh, оставив 10 минут на загрузку и проверку в рамках 180 000 долларов.

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

capacityslosemantic-layer

Я размещу доменные модели Direct Lake с владельцами поверх подготовленных таблиц OneLake, а междоменные определения вынесу в явные общие контракты.

Команды финансов, продаж, операций и клиентов владеют грануляром модели, мерами и оперативными метаданными, а согласованные измерения публикуются один раз с тестами совместимости.
Я сокращу 18 моделей примерно до 10 переиспользуемых и сохраню тонкие отчёты; уменьшение на 44 процента убирает восемь поверхностей владения и релиза, а фактическая экономия CU и поддержки остаётся измеряемым результатом.
Архитектурная запись потребует p95 визуалов ниже 5 секунд и возраст данных ниже 15 минут, а Capacity Metrics будут пересматриваться при устойчивой загрузке 70 процентов до расходов сверх 260 000 долларов.

Зачем это спрашивают: Сильный ответ использует Direct Lake как режим обслуживания внутри управляемой семантической архитектуры, а не считает OneLake достаточным governance.

querieswarehousebigquery

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

Основной проект владеет каноническими пользователями, датами, счетами, фискальной логикой и 12 метриками правления; доменные CODEOWNERS утверждают представления продаж, продукта и финансов на заявленном грануляре.
Я сокращу 24 пересекающихся Explore до 10-12 подготовленных и буду держать покрытие переиспользуемыми полями выше 80 процентов, обменивая часть локальной свободы на меньшее число конфликтующих join.
Манифест проекта, каталог семантики и проверка стоимости запросов заблокируют merge, если p95 превысит 20 секунд или прогноз BigQuery увеличит годовой темп расходов 220 000 долларов более чем на 10 процентов.

Зачем это спрашивают: Интервьюер оценивает границы проектов LookML, владение, переиспользование и контроль стоимости BigQuery и задержки запросов.

dependenciesbilooker

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

Владелец платформы классифицирует аддитивные и ломающие изменения, публикует release manifest для всех 140 полей и сохраняет предыдущую major-ссылку на 60-дневное окно миграции.
CI проверяет каждый из 6 потребляющих проектов через LookML validation, Content Validator, 30 golden queries, access-фикстуры и сравнение p95 до продвижения ссылки на зависимость.
Rollout закрывается, когда все 110 дашбордов используют одобренную ссылку, метрики совпадают точно, p95 остаётся ниже 15 секунд и ни один потребитель не остаётся на удаляемой major-версии.

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

modelingsnowflakedesign

Я определю доменные cubes на стабильном бизнес-грануляре и опубликую пользовательские views поверх выборочных pre-aggregations.

Orders, subscriptions, marketing spend и support cases получают ответственных владельцев, проверенные join и общие измерения, а views открывают 130 дашбордам только утверждённые меры.
История запросов определяет дневные и месячные rollup для 80 процентов самых частых запросов; я не буду предварительно агрегировать каждую комбинацию, потому что стоимость хранения и refresh растёт мультипликативно.
Манифест моделей требует p95 ниже 3 секунд, свежесть pre-aggregation ниже 15 минут и годовой темп расходов Snowflake плюс Cube не выше 260 000 долларов с пересмотром при достижении 70 процентов любого лимита.

Зачем это спрашивают: Интервьюер проверяет моделирование Cube, экономику pre-aggregation, владение и ориентированное на потребителя переиспользование.

monitoringbipower-bi

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

Версионируемые контракты один раз определяют заказ, клиента, фискальный календарь и конвертацию валют; меры DAX и поля LookML могут различаться только там, где этого требует модель взаимодействия.
Набор reconciliation-тестов ежедневно сравнивает 25 критических метрик в обоих инструментах и блокирует выпуск ниже 99 процентов совпадения, а назначенный владелец домена разбирает каждое исключение.
Перестройка обоих инструментов вокруг 8 общих витрин уменьшает число изолированных путей трансформации с 20 на 60 процентов, но именно измеренные compute, поведение cache и стоимость поддержки решают, укладывается ли дизайн в 600 000 долларов.

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

semantic-layerbipower-bi

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

Финансы владеют моделями ledger и close, продажи владеют pipeline, операции владеют fulfillment; каждая модель объявляет грануляр, steward, уровень поддержки и число зависимых дашбордов.
Customer, legal entity, product и fiscal calendar получают версионируемые ключи и reconciliation-тесты, а междоменные отчёты объединяют сертифицированные результаты вместо создания 22 вариантов.
Я нацелен на 12-14 моделей и выведу остальные только после назначения владельцев для 95 процентов из 240 дашбордов, сохраняя 90-минутное окно refresh до 06:00 и бюджет 350 000 долларов.

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

bilookerbigquery

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

Четыре доменные команды владеют views, мерами, качеством дашбордов и поддержкой пользователей, а команда BI-платформы владеет шаблонами проектов, общими измерениями, правилами доступа и production deployment.
CODEOWNERS требует одного доменного и одного платформенного ревьюера для общего LookML; цель 10 дней делится на 3 дня моделирования, 3 проверки и 4 пользовательской приёмки.
Ежеквартальная матрица владения отмечает модели без активного владельца или с менее чем 5 месячными пользователями, удерживая поддержку в бюджете 160 000 долларов вместо централизации каждого изменения.

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

monitoringbipower-bi

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

Реестр метрик хранит формулу, грануляр, владельца, измерения и дату вступления в силу; переиспользуемые calculation groups обрабатывают временную аналитику и валюты вместо копирования DAX в 18 моделей.
Исходники TMDL и автоматический анализ зависимостей находят 150 затронутых дашбордов, а целевое покрытие мер, созданных или проверенных по реестру, составляет 90 процентов.
Шаблон выпуска оставляет 2 дня на impact analysis, 2 на PR моделей и 1 на deployment, допуская ограниченное дублирование, когда централизация нарушит размер модели, задержку или capacity-лимит 280 000 долларов.

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

dashboardsdesignqueries

Я отделю внутреннее доменное владение от подготовленного embedded-контракта, на который могут опираться продуктовые команды.

Владельцы доменов сопровождают cubes заказов, биллинга, использования и поддержки, а владелец embedded analytics публикует стабильные views и версионируемый каталог мер для 80 дашбордов.
Общие pre-aggregations покрывают 20 форм запросов, создающих минимум 80 процентов трафика; tenant-specific rollup добавляются только при измеримом выигрыше у общих по задержке и хранению.
Набор тестов совместимости и ежемесячный cost scorecard блокируют breaking changes, p95 выше 2 секунд или годовой темп расходов выше 200 000 долларов, обменивая произвольные клиентские поля на предсказуемый API на 24 месяца.

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

bipower-bisql

Я выберу Import с incremental refresh, потому что допустимая свежесть 30 минут не оправдывает интерактивные запросы, завязанные на источник.

Большие факты партиционируются по дате, каждые 30 минут обновляются только последние 2 дня, а измерения импортируются полностью, чтобы дашборды работали через in-memory движок.
Тестирование capacity должно удержать refresh в пределах 20 минут и p95 визуалов ниже 4 секунд; DirectQuery останется исключением для drill-through полей, которые нельзя хранить.
Архитектурная запись сравнивает память импортированной модели и 48 refresh в день со стоимостью concurrency Azure SQL, выбирая вариант дешевле 140 000 долларов в год.

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

dashboardssemantic-layer

Я сделаю Direct Lake вариантом по умолчанию для подготовленных Delta-таблиц, а неподдерживаемые шаблоны изолирую в небольших Import-моделях.

Direct Lake устраняет копирование 6 ТБ в плановые импорты и позволяет семантическим моделям читать OneLake, но каждой таблице нужны стабильный грануляр, оптимизированные файлы и поддерживаемое поведение безопасности.
Проба на 20 самых загруженных страницах должна удерживать p95 ниже 5 секунд и возраст данных ниже 10 минут; любое переключение на DirectQuery или достижение guardrail фиксируется, а не принимается молча.
Capacity Metrics должны оставаться ниже 70 процентов устойчивой нагрузки при 20 000 долларов в месяц, а исключение Import оправдано, когда его сжатие и предсказуемый кеш дешевле настройки lake-пути.

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

designsemantic-layerbi

Я применю DirectQuery для узкого операционного среза и уберу историческую аналитику из этого пути.

Источник получает индексированные serving views на грануляре диспетчера, автомобиля и 5 минут, а 12 месяцев истории импортируются в отдельную модель для трендов.
Я проведу нагрузочный тест 180 пользователей на двойном ожидаемом пике, потребовав p95 ниже 5 секунд и менее 30 одновременных запросов к источнику после сокращения запросов визуалов и страниц.
Телеметрия Azure SQL и capacity делит годовой лимит 200 000 долларов; если compute источника вырастет более чем на 20 процентов, Import-агрегация или более короткое живое окно дешевле бесконечного масштабирования DirectQuery.

Зачем это спрашивают: Интервьюер оценивает, ограничен ли DirectQuery действительно свежей операционной нагрузкой с контролем источника и concurrency.

semantic-layerbipower-bi

Я объединю импортированные историю и агрегаты с DirectQuery только для детальных заказов текущего дня.

Измерения Date, Store и Product в Dual mode обслуживают оба пути, Import-агрегат хранит метрики магазин-час за два года, а DirectQuery покрывает текущий рабочий день.
Aggregation mappings должны обслуживать минимум 90 процентов запросов 180 дашбордов из памяти с p95 ниже 4 секунд, оставляя живую детализацию осознанно более медленным drill-through.
Проектный документ ограничивает живой срез 50 миллионами строк, а общий темп расходов 25 000 долларов в месяц, принимая сложность источника ради свежести 5 минут только там, где пользователи могут действовать.

Зачем это спрашивают: Интервьюер проверяет корректные границы composite model, Dual-измерения, долю попаданий в агрегаты и стоимость живого детального пути.

queriesaggregationwarehouse

Я построю Import-агрегации по наблюдаемому грануляру дашбордов и сохраню DirectQuery-детализацию для исключительного исследования.

Rollup заказ-день-категория-регион и продавец-час покрывают основные меры, а relationships и aggregation mappings сохраняют доступ к детальной таблице на 30 ТБ.
Логи запросов должны показать минимум 90 процентов попаданий в агрегаты на 50 главных страницах и p95 ниже 4 секунд; неиспользуемые rollup удаляются через 30 дней.
Для каждого rollup нужна оценка хранения, refresh и сканирования хранилища, а портфель отклоняется, если годовой прогноз превысит 450 000 долларов, даже когда ещё одна агрегация ускоряет отдельный дашборд.

Зачем это спрашивают: Senior-ответ проектирует агрегации Power BI по измеренным формам запросов и учитывает стоимость refresh и хранения.

configbipower-bi

Я применю incremental refresh для ограниченных исторических партиций и гибридную DirectQuery-партицию только для текущего часа.

При росте 500 ГБ в день я не стану импортировать 24 месяца сырых транзакций; модель хранит только проверенное тестом недавнее окно детализации и дневные агрегаты по продавцам за 24 месяца, а сырая история остаётся в хранилище для drill-through.
RangeStart, RangeEnd, надёжная колонка обнаружения изменений и reconciliation партиций хранятся в source control; партиции с поздними данными обновляются ежедневно, а индексированная live-партиция ограничена последними 60 минутами.
Стоимость capacity и источника должна оставаться не выше 220 000 долларов в год, а гибридный путь убирается, если пятиминутные данные нужны менее чем 10 процентам пользователей или стоимость источника вырастет на 20 процентов.

Зачем это спрашивают: Интервьюер проверяет знание партиций incremental refresh, гибридных real-time данных и экономического оправдания дополнительной сложности.

capacitysemantic-layerbi

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

По указанным ценам Pro для всех 400 пользователей стоит 400 умножить на 14 долларов и 36 месяцев, то есть 201 600 долларов; PPU стоит 400 умножить на 24 доллара и 36 месяцев, то есть 345 600 долларов, поэтому PPU уже превышает лимит 330 000 долларов.
Резервация F64 по 95 000 долларов в год плюс Pro для авторов стоит 305 160 долларов за три года; читателям всё равно нужны учётные записи Fabric Free и доступ к контенту на F64 или более крупной capacity.
Решение проверяет размер моделей, частоту refresh и concurrency нагрузочным тестом, а доступность по контракту сервиса и recovery drills; Pro побеждает, если проходит лимиты общей capacity, потому что он дешевле на 103 560 долларов.

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

capacitysemantic-layerqueries

Я определю размер по репрезентативному тесту concurrency и Capacity Metrics, а не по 18 ТБ хранения.

Я воспроизведу 30 самых загруженных страниц при 1200 запросах визуалов в минуту одновременно с плановым refresh и framing Direct Lake, затем запишу интерактивное и фоновое потребление CU по item.
Начну с минимального SKU, где p99 интерактивной задержки равен нулю, p99 визуалов ниже 5 секунд, а устойчивая загрузка ниже 70 процентов; затем проверю следующий SKU для запаса роста.
Мемо по sizing сравнивает резервацию и scale-up на 18 месяцев и сохраняет 20 процентов бюджета в резерве, поэтому утверждённая база не может превышать 400 000 долларов до contingency.

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

capacitysemantic-layerbi

Я изолирую production-финансы от разработки и всплесков self-service, сохранив низкорисковые домены вместе.

Одна зарезервированная production capacity содержит сертифицированные финансовые модели и 60 критических дашбордов; меньшая pay-as-you-go capacity содержит разработку и 80 self-service дашбордов и ставится на паузу вне рабочих часов.
Назначение workspaces, deployment pipelines и матрица маршрутизации capacity становятся контрольными артефактами, а финансы сохраняют 30 процентов запаса в окне refresh с 04:00 до 06:00.
Я утвержу разделение, только если обе capacity вместе с операциями остаются в общем месячном лимите 25 000 долларов; иначе временное разделение нагрузок на одной более крупной capacity будет дешевле.

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

capacitysemantic-layerbi

Я зарезервирую стабильную production capacity и применю pausable pay-as-you-go capacity для разработки.

Предложение поставщика на 90 000 долларов за два года резервации против 150 000 долларов pay-as-you-go делает резервацию рациональной для production-базы 24 на 7.
Разработка использует около 2600 часов в год вместо 8760; по указанной цене 5 долларов в час она стоит 26 000 долларов за два года, если автоматизация ставит её на паузу без активных jobs.
Capacity-план включает месячные пороги p95 ниже 6 секунд и загрузки 70 процентов, оставляя 64 000 долларов из бюджета 180 000 на краткие production scale-up и рост.

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

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

21
BI-платформа обслуживает 300 аналитиков и руководителей через 14 семантических моделей и 120 дашбордов поверх 6 ТБ; годовые расходы равны 280 000 долларов, бизнес-домены запрашивают свежесть от 15 минут до суток, SLO должны заработать за один квартал. Как вы определите refresh SLO?
slosemantic-layerdashboards
22
В BI-среде 450 пользователей, 25 семантических моделей, 200 дашбордов и 10 ТБ в Fabric и Looker; годовая стоимость равна 500 000 долларов, governance review проходит ежеквартально, выполнение SLO свежести критических данных должно превышать 99,5 процента. Что войдёт в BI scorecard?
slosemantic-layerbi
23
11 семантических моделей и 80 дашбордов обслуживают 220 аналитиков поверх 3 ТБ клиентских и биллинговых данных; годовой бюджет равен 180 000 долларов, свежесть должна оставаться в пределах 30 минут, команды источников планируют изменения схем в следующие 12 месяцев. Какой data contract вы потребуете?
data-contractssemantic-layerschema
24
В компании 380 BI-пользователей, 20 семантических моделей, 160 дашбордов и 14 ТБ в Fabric и Snowflake; годовой платформенный бюджет на lineage равен 420 000 долларов, критические данные должны быть моложе 1 часа, покрытие lineage 90 процентов нужно получить за 9 месяцев. Как вы построите lineage?
lineagesemantic-layercoverage
25
В команде Power BI 160 разработчиков и аналитиков, 16 семантических моделей, 110 дашбордов и 5 ТБ исходных данных; годовая стоимость платформы равна 240 000 долларов, управляемые релизы должны выходить еженедельно, CI/CD должен работать 18 месяцев. Какой пайплайн вы установите?
ci-cdbipower-bi
26
Развёртывание Looker поддерживает 190 аналитиков с 14 моделями LookML, 85 дашбордами и 4 ТБ в BigQuery; годовая стоимость равна 200 000 долларов, утверждённые изменения должны достигать production за 2 рабочих дня, workflow планируется на год. Как вы спроектируете CI/CD?
ci-cddeploymentbi
27
В организации Power BI 320 пользователей, 18 семантических моделей, 140 дашбордов и 8 ТБ исходных данных; годовая стоимость равна 320 000 долларов, релизы происходят еженедельно с целью rollback 30 минут, схема должна служить два года. За что должны отвечать deployment pipelines, а что должно оставаться вне их?
deploymentrollbackbi
28
Платформа Cube обслуживает 140 аналитиков и 160 пользователей приложения через 13 моделей данных и 70 дашбордов поверх 9 ТБ в Snowflake; годовая стоимость равна 190 000 долларов, p95 должен быть ниже 3 секунд, семантические релизы выходят ежедневно в течение следующего года. Как вы встроите observability в CI/CD?
modelingsnowflakeci-cd
29
Шесть команд поддерживают 500 BI-пользователей через 28 семантических моделей и 230 дашбордов поверх 20 ТБ; годовые расходы равны 600 000 долларов, общий семантический стандарт нужно утвердить за 6 месяцев, критические отчёты имеют SLO свежести 30 минут. Что войдёт в ваш cross-team RFC?
slosemantic-layerdecision-making
30
BI-платформа обслуживает 400 пользователей с 22 семантическими моделями, 180 дашбордами и 16 ТБ в Fabric, Looker и Snowflake; годовая стоимость равна 480 000 долларов, критическая свежесть должна выполняться на 99,5 процента при 15 минутах, observability нужно предоставить за один квартал. Что вы инструментируете?
observabilitybilooker
31
В отделе продаж 300 BI-пользователей, 16 семантических моделей, 145 дашбордов и 5 ТБ в Power BI; годовая стоимость равна 300 000 долларов, консолидацию нужно завершить за 6 месяцев, критические pipeline-данные должны оставаться моложе 30 минут. Как вы сократите дублирование?
bici-cdpower-bi
32
Tenant Power BI обслуживает 420 пользователей с 24 семантическими моделями, 260 дашбордами и 11 ТБ данных; годовые расходы равны 450 000 долларов, вывод zombie reports должен уложиться в 90 дней, tier-one дашборды требуют месячного выполнения свежести 99,5 процента. Какую политику retirement вы внедрите?
bipower-bidashboards
33
В компании 180 аналитиков, 10 семантических моделей, 75 дашбордов и 7 ТБ в Snowflake; за три года можно потратить 250 000 долларов, нужен p95 запросов ниже 4 секунд, за 8 недель нужно выбрать между Cube Cloud и собственным metrics API. Что порекомендует ваше build-versus-buy мемо?
queriessnowflakeapi
34
Бизнес планирует перенести 500 пользователей, 25 семантических моделей и 300 дашбордов Tableau поверх 20 ТБ в Power BI и Fabric; трёхлетний лимит равен 1,2 миллиона долларов, миграция должна завершиться за 18 месяцев, критические дашборды требуют свежесть 99,5 процента в пределах 1 часа. Что предложит ваше migration memo?
bipower-bitableau
35
Компания рассматривает перенос 260 пользователей, 18 моделей LookML и 130 дашбордов Looker поверх 9 ТБ в BigQuery в Power BI; трёхлетний бюджет равен 700 000 долларов, переходное окно равно 12 месяцам, p95 дашбордов должен оставаться ниже 8 секунд. Как вы примете решение?
bipower-bilooker
36
В устаревшей среде SSAS Multidimensional есть 14 кубов, 430 вычисляемых элементов MDX, 190 отчётов Excel и 11 ТБ данных; компания хочет перейти на semantic models Power BI за 18 месяцев без изменения аудированных финансовых итогов. Как спланировать миграцию?
excelbipower-bi
37
Среда Snowflake и Power BI обслуживает 400 пользователей через 20 семантических моделей и 200 дашбордов поверх 40 ТБ; руководство рассматривает Fabric, текущий трёхлетний TCO равен 1,5 миллиона долларов, оценка длится 18 месяцев, критическая свежесть равна 15 минутам. Будете ли вы мигрировать хранилище вместе с BI?
warehousesnowflakebi
38
Модель Power BI на 620 миллионов строк обслуживает 46 отчётов, но новый item calculation group повысил p95 с 4 до 28 секунд, потому что оборачивает 180 мер и повторяет context transition внутри итератора. Какое архитектурное исправление вы одобрите?
bipower-biarchitecture
39
В глобальной компании 450 BI-пользователей, 26 семантических моделей, 310 дашбордов и 18 ТБ разделены между Power BI и Looker; текущий трёхлетний TCO равен 1 миллиону долларов, консолидацию нужно завершить за 12 месяцев, критические дашборды имеют SLO свежести 30 минут. Как вы консолидируете портфель?
bipower-bilooker
40
Производителю нужно перенести 200 аналитиков, 20 семантических моделей Qlik и 170 дашбордов поверх 8 ТБ в Looker; трёхлетний бюджет миграции равен 750 000 долларов, завершение требуется за 15 месяцев, операционным дашбордам нужна свежесть 20 минут. Как вы организуете migration factory?
bilookermigrations
41
Tenant Power BI обслуживает 500 пользователей в финансах, продажах и операциях через 18 семантических моделей и 160 дашбордов поверх 12 ТБ; годовая стоимость равна 400 000 долларов, изменения прав должны применяться за 4 часа, security-дизайн должен служить два года. Как вы спроектируете многодоменный RLS?
designsemantic-layerbi
42
В компании 320 пользователей Power BI, 14 семантических моделей, 120 дашбордов и 5 ТБ финансовых и HR-данных; годовая стоимость равна 300 000 долларов, изменения доступа должны появляться за 24 часа, отчётность закрытия месяца должна оставаться доступной три года. Как вы объедините RLS и OLS?
bipower-bidashboards
43
Instance Looker обслуживает 260 пользователей через 16 моделей LookML и 100 дашбордов поверх 7 ТБ; годовые расходы равны 250 000 долларов, обновления прав должны укладываться в SLO 30 минут, архитектура должна работать 18 месяцев. Как вы обеспечите многодоменный доступ?
bilookerarchitecture
44
Платформа Cube обслуживает 60 внутренних аналитиков и 400 клиентов через 12 моделей данных и 90 встроенных дашбордов поверх 10 ТБ; годовая стоимость равна 350 000 долларов, p95 tenant-scoped запросов должен быть ниже 2 секунд, модель изоляции должна служить три года. Как вы обеспечите изоляцию tenant?
queriesmodelingdashboards
45
В BI-программе 500 пользователей, 24 семантические модели, 220 дашбордов и 15 ТБ в Fabric и Looker; годовая стоимость равна 500 000 долларов, аналитикам нужно публиковать полезный контент за 5 рабочих дней, governance-модель должна заработать за 12 месяцев. Как вы будете управлять self-service?
bilookerdashboards
46
В организации Power BI 360 пользователей, 20 семантических моделей, 150 дашбордов и 8 ТБ исходных данных; годовые расходы платформы равны 300 000 долларов, certification пересматривается ежеквартально, свежесть критических моделей должна превышать 99,5 процента. Как вы будете управлять endorsed semantic models?
bipower-bidashboards
47
Среда Fabric и Power BI обслуживает 300 пользователей через 15 семантических моделей и 130 дашбордов поверх 6 ТБ; трёхлетний бюджет resilience равен 400 000 долларов, бизнес требует RTO 8 часов и RPO 24 часа, recovery-дизайн нужно проверять дважды в год. Что вы внедрите?
designsemantic-layerbi
48
Развёртывание Looker поддерживает 180 аналитиков через 12 моделей LookML и 80 дашбордов поверх 4 ТБ в BigQuery; двухлетний бюджет resilience равен 250 000 долларов, RTO составляет 4 часа, RPO равен 1 часу, восстановление нужно репетировать ежеквартально. Как вы защитите семантический слой и контент?
deploymentbilooker
49
BI-среда обслуживает 420 пользователей через 25 семантических моделей и 190 дашбордов поверх 13 ТБ; годовая стоимость равна 500 000 долларов, breaking changes метрик требуют уведомления за 30 дней, change policy должна работать 18 месяцев. Как вы будете управлять развитием семантического слоя?
dashboardsmonitoringsemantic-layer
50
В предприятии 480 пользователей, 30 семантических моделей в Power BI, Looker и Cube, 240 дашбордов и 25 ТБ данных; годовая стоимость равна 700 000 долларов, управляемые изменения выпускаются ежеквартально, операционная модель должна оставаться стабильной два года. Как вы скоординируете изменения семантики между инструментами?
bipower-bilooker
51
В 06:20 глобальная модель продаж нарушила SLO обновления к 06:00 после сбоя одной партиции, её открывают 1 800 продавцов, а полный перезапуск займёт примерно 52 минуты. Что вы сделаете?
estimationpartitioningslo
52
Финансовая модель нарушила SLO обновления к 07:00 в 4 из последних 10 рабочих дней: завершение было между 07:18 и 08:05, а согласование зарплат начинается в 07:30. Какое изменение вы одобрите?
slo
53
В 09:05 загрузка Microsoft Fabric F64 держится на 92%, p95 интерактивных отчётов вырос с 6 до 48 секунд, а системой пользуются 700 руководителей и менеджеров. Как вы отреагируете?
capacity
54
Fabric F128 начинает throttling в 08:00, потому что 140 обновлений по расписанию совпадают с утренним входом 2 400 пользователей, а дашборд CFO открывается 75 секунд. Что вы измените сегодня?
dashboardscapacity
55
XMLA-деплой в 14:10 сделал общую Power BI semantic model недоступной и сломал 86 отчётов для 4 200 сотрудников перед операционным обзором в 15:00. Вы откатите или исправите на месте?
deploymentrollbackbi
56
Переименование столбца в измерении клиентов одновременно сломало опубликованный источник Tableau и модель Looker, из-за чего в 07:40 отключились 63 executive-дашборда. Как вы восстановите систему?
bitableaulooker
57
В 05:50 все три узла кластера локального data gateway перестали устанавливать исходящий TLS после истечения корневого сертификата корпоративного proxy, заблокировав 47 обновлений Power BI со сроком до 07:00. Каков ваш план инцидента?
proxygatewaybi
58
Один узел gateway начал отклонять подключения к Snowflake после изменения firewall: 19 из 120 обновлений периодически падают, хотя остальные узлы выглядят исправными. Как вы ограничите проблему?
gatewaynetworkingsnowflake
59
В Tableau Server для 3 600 пользователей остановились два процесса VizQL, очередь Backgrounder выросла до 240 задач, а p95 загрузки workbook достиг 58 секунд. Что вы сделаете?
deploymentbitableau
60
Production-деплой Looker исчерпал пул соединений, 95% Explores возвращают ошибки для 1 100 пользователей, а 34 PDT всё ещё строятся. Что вы сделаете?
deploymentbilooker
61
CEO видит ARR $128,4 млн в Power BI, CFO видит $124,9 млн в Tableau, а Sales видит $131,2 млн в Looker за два часа до фиксации board pack. Как вы решите расхождение?
bipower-bitableau
62
Два executive-дашборда показывают gross margin 31,8% и 28,6%, потому что одна модель распределяет cloud cost по выручке, а другая по использованию; голосование по инвестиции $20 млн состоится завтра. Что вы решите?
dashboardscss
63
Обновление финансового календаря сдвинуло недельную выручку на 9% в 14 executive-дашбордах, а 22 операционных дашборда всё ещё используют старую границу недели; прогноз на квартал нужен через 24 часа. Что вы сделаете?
dashboards
64
Регрессия RLS позволила 214 региональным менеджерам в течение 37 минут видеть суммы компенсаций по всем 18 регионам в Power BI. Как вы отреагируете?
bipower-birow-level-security
65
Деплой удалил OLS с четырёх payroll-столбцов, открыв national ID и банковские реквизиты 62 авторам отчётов на 3 часа, хотя ни один дашборд их не показывает. Что вы сделаете?
dashboardsdeploymentschema
66
Ошибка Power BI Embedded token позволила 17 клиентам в течение 11 минут открыть дашборд использования другого tenant, потенциально затронув 46 000 строк аккаунтов. Как вы возглавите инцидент?
bipower-biincidents
67
Изменение Looker access_filter открыло складские остатки одного ритейлера 8 пользователям другого на 26 минут, при этом произошло две выгрузки CSV. Что вы сделаете?
bilooker
68
Переименование dbt-модели сломало lineage 63 сертифицированных дашбордов, но кэш продолжал показывать результаты 9 часов и оповещение не сработало. Как восстановить доверенный lineage?
alertingdbtcaching
69
Исправленное правило sales credit уменьшает квартальную комиссию на $2,4 млн для 380 сотрудников после согласования payroll-файлов, но до выплаты. Что вы сделаете?
70
Internal Audit спрашивает, почему 126 продавцам переплатили $740 000 за два квартала, и требует воспроизводимые доказательства за 5 рабочих дней. Как вы ответите?
reproducibility
71
В миграции Tableau в Power BI перенесено 140 из 220 дашбордов, но 18 процентов выбранных KPI расходятся, а 600 активных пользователей всё ещё создают 70 процентов недельных сессий в Tableau за три недели до окончания 2 400 лицензий. Что вы сделаете?
bipower-bitableau
72
Консолидация Power BI, Looker и Qlik в Looker отстаёт на шесть месяцев, уже потрачено $1,8 млн, а перешли только 22% из 900 пользователей. Что вы порекомендуете?
bipower-bilooker
73
После перевода 75 отчётов на DirectQuery к Snowflake утренний p95 вырос с 9 до 64 секунд, а расходы warehouse утроились при 1 300 одновременных пользователях. Что вы сделаете?
warehousesnowflakeconcurrency
74
После переноса 28 semantic model на Direct Lake 11 из них переходят в fallback на DirectQuery, Fabric CU достигает 96%, а p95 executive-отчётов вырос до 41 секунды. Как восстановить rollout?
semantic-layer
75
Looker-рефакторинг заменяет 420 дублирующихся метрик на 38 переиспользуемых views, но первый деплой ломает 27 Explores и 160 рассылок. Как вы продолжите?
deploymentbilooker
76
Рефакторинг переиспользуемой LookML-метрики проходит компиляцию, но меняет net revenue на 2,7% в 84 дашбордах из-за наследования фильтров. Что вы сделаете?
refactoringownershipoop
77
BI-вендор повышает годовую лицензию с $1,4 млн до $2,35 млн с уведомлением за 90 дней, при этом 2 800 пользователей зависят от 760 дашбордов. Что вы порекомендуете?
dashboardsprocurement
78
Контракт Looker меняет цену embedded views и увеличивает прогноз затрат на 42% для 65 клиентов и 9 млн месячных сессий. Как вы отреагируете?
bilookersessions
79
CFO отказывается выводить 9-летний дашборд для 14 пользователей, потому что он использовался в прошлом аудите, хотя дашборд стоит $86 000 в год и дублирует сертифицированный отчёт. Что вы сделаете?
dashboards
80
Operations блокирует вывод 46 старых Tableau workbook перед пиковым сезоном через 8 недель, хотя недельные пользователи есть только у 11, а security support закончится через 12 недель. Какой план вы одобрите?
bitableau
81
Каждый понедельник 900 пользователей открывают 380 Power BI отчётов, p95 растёт до 33 секунд, а 12% visuals падают на общей F128 capacity. Какое архитектурное изменение вы сделаете первым?
capacitybipower-bi
82
В 09:00 350 пользователей Looker запускают 1 800 запросов за 10 минут, пул соединений базы достигает 100%, а 70 рассылок не укладываются в окно. Что вы измените?
databasequeriespooling
83
Один self-service Looker Explore создаёт 28 процентов расходов Snowflake, а запросы 240 пользователей выполняются до 19 минут. Какой query budget вы введёте?
queriessnowflakebi
84
Один Power BI отчёт потребляет 31% F64 CU во время закрытия месяца: в нём 42 visuals и шесть метрик выполняются более 8 секунд каждая. Как вы будете им управлять?
bipower-bimeasures
85
Четыреста восемьдесят обновлений semantic model должны завершаться между 01:00 и 06:00, но текущее окно заканчивается в 07:25 и задерживает 38 страновых дашбордов. Как вы переделаете окно?
dashboards
86
Расходы BI-warehouse выросли со $120 000 до $230 000 в месяц при росте активных пользователей только на 6%, а у 54% затрат нет тега владельца дашборда. Что вы сделаете?
dashboardswarehouse
87
Хранилище Tableau extracts достигло 94 ТБ, ежедневное обновление занимает 68% maintenance window, а 1 600 пользователям всё ещё нужна утренняя свежесть 15 минут. Что вы измените?
bitableau
88
Среда Looker обслуживает 62 дашборда поверх 40 ТБ в BigQuery; стоимость сканирования выросла на 68 процентов, p95 достиг 24 секунд, 38 процентов запросов не используют фильтры партиций, а свежесть должна оставаться в пределах 30 минут. Какое архитектурное изменение вы сделаете?
queriespartitioningbigquery
89
Администратор удалил production workspace Fabric с 12 семантическими моделями и 74 отчётами Power BI; исходные данные сохранились, бизнес заявляет RTO 4 часа и RPO 1 час, а у deployment pipeline больше нет production stage. Может ли pipeline всё восстановить?
deploymentbici-cd
90
Четыре бизнес-юнита потребляют $1,1 млн годовой BI-capacity, но один создаёт 57% CU и отвергает chargeback, потому что его дашборды используются всей компанией. Какое распределение вы введёте?
dashboardscapacity
91
Finance требует одну enterprise-метрику revenue, четырём продуктовым командам нужны контрактные варианты с годовой разницей 18 миллионов долларов, а RFC заблокирован после 28 комментариев и 6 недель. Какую модель принятия решений и миграцию вы установите?
measuresmigrationsdecision-making
92
Security требует Power BI для identity control, Data Science хочет Sigma для warehouse-native анализа, а Procurement финансирует только два BI-инструмента для 3 200 пользователей. Как закрыть RFC?
bipower-bidecision-making
93
Self-service программа за квартал создала 73 несертифицированные semantic model и 260 дашбордов; 19 конфликтов KPI дошли до руководителей, а support tickets выросли на 64%. Что вы измените?
dashboardskpisemantic-layer
94
Значок certified стоит на 44 Power BI дашбордах, хотя у 17 нет владельца, 9 нарушают freshness SLO, а 6 используют локальные метрики вне semantic layer. Что вы сделаете?
slosemantic-layerbi
95
Upstream-контракт customer удаляет country_code с уведомлением за 24 часа, ломая RLS и tax-логику в 31 semantic model для 12 рынков. Что вы сделаете?
row-level-securitysemantic-layer
96
В 08:40 COO просит убрать предупреждение об устаревших данных с операционного дашборда возрастом 7 часов перед звонком с кредитором, потому что цифры выглядят плохо. Что вы сделаете?
dashboards
97
CEO просит опубликовать рост 14,2 процента, хотя сертифицированная метрика равна 9,6 процента, а большая цифра исключает refunds на 4,8 миллиона долларов; черновик отчётности закрывается через 90 минут. Что вы сделаете?
monitoring
98
Mid-level BI-разработчик должен выбрать пилотный домен для Fabric-миграции 90 моделей, но stakeholders дают противоречивые приоритеты, а complete lineage нет ни у одной модели. Как вы будете его менторить?
mentoringcommunicationmigrations
99
Во время capacity-инцидента для 2 000 пользователей mid-level инженер хочет немедленно увеличить размер, но причина трёхкратного скачка CU не доказана, а дашборд CFO падает. Как вы будете его направлять и принимать решение?
dashboardsincidentscapacity
100
Вы получаете 520 дашбордов в Power BI и Tableau, 46 семантических моделей, 1 400 пользователей Microsoft 365, 80 процентов активных сессий уже идут через Power BI, годовой бюджет 1,9 миллиона долларов, требование executive freshness 30 минут и цель сократить стоимость на 25 процентов за 12 месяцев. Какую архитектуру вы выберете?
bipower-bitableau