Я в том смысле, что когда данные в SQLServere - там понятно, открываю Management Studio и с помощью SQL запросов узнаю, что там где записано. Может, где-то нолик в данных лишний. Или какую-то строчку удалить надо, добавить или узнать конкретное значение в конкретной строке.
В общем, с данными удобно работать в SQLServer, но как их просматривать в PowerBI?

Второе: с помощью SSIS я в DWH могу пополнять данные из разных источников. Могу немного неправильные задать условия и у меня вместо замены старых значений обновлёнными будут создаваться новые строки. Это могу вычислить и лишние строки потереть, а ошибку в SSIS поправить. Как это происходит в PowerBI? Не совсем понимаю...

Спасибо, это очень интформативно и развёрнуто.
vikkiv но Power BI явно не для этого, и такие тяжелые (держать всё внутри) решения выйдут боком
это к тому что контроль версии ETL данных лучше осуществлять вне Power BI.
Как тогда, получается, это следует делать?
С помощью PowerBI нужно делать аналитику, напр., за несколько последних лет - это получается, что нужно всё выгрузить в powerBI и выглядит это так, будто SQLServer вообще не нужен.
Ну, т.е. 50 пользователей подключатся к PowerBI - там не поймёшь, что каждому нужно. У всех разные права доступа (на уровне строк), и разные цели. Как определить, что в PowerBI грузить нужно, а что нет?
Плюс, какую-то устаревшую информацию нужно из PowerBI как-то удалять.

Я спрашиваю, потому что не нашёл нормального обзорного описания PowerBI, его возможностях и технических ограничениях, где он полезен, а как лучше его не использовать и примеры архитектуры сетей с использованием PowerBI. Везде ограничиваются только: "вау, графики" или "а сейчас мы будем загружать данные".

а по-моему, в пт у всех активность была большая)

Обо мне:
У кулинарная, так сказать, компания и находимся в 8 городах европейской части России.
Создал большой проект. Из 1С и пары других систем данные через SSIS идут в DWH, оттуда в OLAP SSAS
В качестве клиента OLAP - excel и мной написанная прога на C#. Реализовано построчное разделение прав в DWH и SSAS.
Всё работало отлично. Но без спецэффектов.
Сам я после этого перешёл к выполнению задач на C++ и мелкие программки вспомогательные на C#+WPF (wpf без надобности, просто попробовать решил).

Людям захотелось графики.
Поступил запрос - что за PowerBI и нужен ли он нам.
Я стал изучать этот вопрос. Хотел найти внятную презентацию (статью или видео - что угодно), описывающую архитектуру PowerBI в контексте промышленного внедрения. Какое место Microsoft отводит ему, какое оставляет SSEngine и SSAS. Какие варианты взаимодействия - не просто на уровне "PowerBI может высосать данные откуда угодно", а именно в контексте разумного взаимодействия.

И уже имея эти данные решить, искать нам спеца или нет. Какую квалификацию с него спрашивать.

Все презентации PowerBI сводятся к намозолившим мне глаз "столбикам на карте мира" и "вааау, ты посмотри какие диаграммки", а ещё "PowerBI очень мощная вещь и источниками данных может служить что угодно".
Если бы я планировал изучать PowerBI - то да, я бы пошёл на курсы, изучал бы его со всех сторон, протестировал бы объёмы данных и уже на собственном опыте понял бы, что годится, а что нет.


хорошо я согласенСпасибо, это очень интформативно и развёрнуто.
я на самом деле был в курсе 80% того, что было сказано в вашем первом комментарии. Напр., в PowerQuery прощупал язык M этот, пока пробовал. Просто "пионерка должна быть вежливой" - я поблагодарил за уделённое время и описанную информацию.

Мне не нужна практическая информация - именно не то, что можно прощупать (синтаксис M и пр.), а описание архитектурны и корректного использования. Поэтому и стал задавать вопросы. Я не тролль :)

Вот, пока ищу такую информацию.

а исходные данные такие:
компания, 500 пользователей аналитики, у каждого индивидуальные права (смотрят только своих подчинённых, либо свою отрасль, либо только себя, либо на список офисов, и т.д.)
В Москве есть источники данных (1с и Journal (наша самописная прога, туда все сотрудники свои успехи вносят)), скидывают в текстовый файлик в расшаренную папочку.

SSIS собирает, отправляет в DWH и каждую ночь собирается куб в SSAS.

Пользователи коннектятся к SSAS из C# программки и любуются данными.

как впилить DWH?

Перенести DWH в SQL Database (т.е. в облаке) - или отказаться от SQL Servera вообще, т.к. PowerBI всё равно хранит данные? А надёжно хранит, не потеряются? А бекапы? А разделение прав (да, спасибо за первый коммент, на это отвечено)

Через Data Gateway наполнять базу, напр., SQL Database, а оттуда в PowerBI - сразу всю кучу без остатка?

Где должна храниться какая-нибудь клиентская (админская т.е.) прога, в которой можно будет указывать разделение прав? Я её напишу на C#, но что это, где должна располагаться, - не понятно. Аналогичная сейчас работает в нынешнем клиенте на C# - там админы могут распределять права доступа индивидуально для каждого пользователя. Группы не годятся.

Короче, вот примерно такие архитектурные недопонимания у меня есть.

вот этот коммент очень здорово пролил свет на происходящее.
Спасибо!! Прямо вот то, что нужно. Теперь всё встало на свои места.

iShvedsky(см. https://docs.microsoft.com/ru-ru/power-bi/power-bi-reports-performance )
очень забавные вещи пишут в приведённой статье.
Распространенная ошибка заключается в том, что в представлении по умолчанию не используется фильтрация, то есть отображается более 100 млн строк. Данные для этих строк должны загружаться в память и распаковываться при каждом обновлении. Это приводит к чрезмерной загрузке памяти. Чтобы решить эту проблему, сократите максимальное количество элементов, которые отображаются в таблице, с помощью фильтра "Ведущие N"
Каждый день пользователи вводят данные в базу о своих покупках и продажах.
А аналитик теперь захотел посмотреть график по годам за весь период.
Не понимаю, о каких "последних 10000 элементах" (как написано в статье) может идти речь, если речь идёт о визуализации. Т.е. о графиках.
График на последних 10 000 записей о доходах и график на всех 200 000 000 записях о доходах на выбранном периоде с 2010 по 2018 года - это два совершенно разных графика.

Да пусть даже с 2014 по 2018 года. Всё равно не понятно, как "ведущие N" можно вообще применять.