Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Nika gnome Member Откуда: Сообщений: 626 |
Возьмём стек Microsoft, т.к. ветка посвящена именно ему.
Теперь к сути. Что не так с SSRS, про который я ото всюду слышу, то он архаичен? Что он - "лишний элемент"? Во множестве мест, где заходит дискуссия, мне какие-то комментаторы гооворят, что нужно реализовывать Inmemory решения. Что получается в Inmemory (как я это вижу) Создаётся 50 отчётов PowerBI. В каждом из них заново необходимо прописывать какие-то права на 1000 пользователей, формулы (коэффициенты какие-нибудь). И т.п. И все эти отчёты нужно ещё сопровождать каким-то образом. Изменились права пользователей - пошёл по всем отчётам править доступы. Почему после этого так хвалят inmemory как самое лучшее решение? Что даёт куб? Все агрегации, вся аналитика - на 1 сервере. А powerBI-отчёты только визуализируют данные, при этом не хранят их, а каждый раз запрашивают у куба. Вопрос возник после прочтения ветки https://pikabu.ru/story/a_teper_davayte_uznaem_istinnuyu_prichinu_zarplat_itshnikov_6706769?cid=140945312 |
|
20 май 19, 11:32 [21888681] Ответить | Цитировать Сообщить модератору |
L_argo Member Откуда: Сообщений: 1406 |
Поэтому для задач анализа данных неудобна, т.к. по настоящему гибкий и быстрый анализ можно получить с помощью BI. Покрутите к-л сложный БИ-дашборд, тогда поймете разницу. |
||
20 май 19, 12:16 [21888737] Ответить | Цитировать Сообщить модератору |
Dimitry Sibiryakov Member Откуда: Сообщений: 52541 |
Как и любой другой хранимый агрегат, единственное, что он даёт - скорость выборки. |
||
20 май 19, 13:41 [21888855] Ответить | Цитировать Сообщить модератору |
Ferdipux Member Откуда: Москва Сообщений: 584 |
Если отвлечься от исторического аспекта, то: |
||
20 май 19, 14:23 [21888909] Ответить | Цитировать Сообщить модератору |
StarikNavy Member Откуда: Москва Сообщений: 2395 |
Nika gnome, у вас кони и люди не смешались? в заголовке вопрос про SSAS (кубы) внутри про SSRS (репортинг) имхо, главная проблема в том что ребята не обновляют движок олапа, поэтому конкуренты поджимают со всех сторон (оба направления) начальство желает красивые отчетики на смартфонах, а тут скучные древние эксельки |
20 май 19, 14:29 [21888913] Ответить | Цитировать Сообщить модератору |
Nika gnome Member Откуда: Сообщений: 626 |
тфуты блин.... я имел в виду SSAS C отчётами там всё предельно ясно. |
||||
20 май 19, 15:30 [21888987] Ответить | Цитировать Сообщить модератору |
Nika gnome Member Откуда: Сообщений: 626 |
смешались. Вернее, опечатка произошла. |
||
20 май 19, 15:30 [21888988] Ответить | Цитировать Сообщить модератору |
Nika gnome Member Откуда: Сообщений: 626 |
Спрошу иначе: OLAP кубы сейчас используются или им на замену что-то пришло? |
20 май 19, 15:32 [21888990] Ответить | Цитировать Сообщить модератору |
Критик Member Откуда: Москва / Калуга Сообщений: 34762 Блог |
Nika gnome, используются |
20 май 19, 16:09 [21889004] Ответить | Цитировать Сообщить модератору |
vikkiv Member Откуда: EU Сообщений: 2921 |
Nika gnome, и на замену тоже пришло |
20 май 19, 16:38 [21889022] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31785 |
Действительно, "уходят в прошлое", "госконторы", точнее, просто унаследованный код, как мэйнфреймы. Думаю, из за того, что реляционные хранилища стали очень хороши, а кубы содержат концепцию обработки, загрузки, пересчёта, и т.п. А сейчас требуют реальное время, и объёмы данных стали велики. Раньше запрос к 10 гб в РСУБД было сделать трудно, а вот специализированные аналитические хранилища могли это загружать и обрабатывать. Пусть "за ночь", но могли. А сейчас 10 или 100 гб РСУБД обрабатывают легко, а петабайтные базы в кубы "за ночь" не зальёшь. |
||
20 май 19, 19:37 [21889172] Ответить | Цитировать Сообщить модератору |
vikkiv Member Откуда: EU Сообщений: 2921 |
Как-бы и да и нет, это конечно существенный фактор (объёмы/производительность, т.е. расчётные мощности) но основной фактор (коррелирующий с указанным alexeyvg) это сдвиг парадигмы фокусирующийся на немного другие аспекты OLAP изначально предназначен для Self-Service и Drill-Down сегмента BI, в то время как BI обеспечивает не настолько большую часть потребностей организации в аналитике/информации для data-driven decision По факту BI это в основном ограниченный Descriptive Analytics сегмент, немного Diagnostic (через Drill-Through/Drill-Down linked-функциями, и немного какого-то подобия Data-Mining), плюс очень малая часть Predictive Analytics (за счёт интеграции в OLAP например Forecasts отдельными группами мер на этапе ETL/ELT) К сообщению приложен файл. Размер - 47Kb |
20 май 19, 20:36 [21889209] Ответить | Цитировать Сообщить модератору |
vikkiv Member Откуда: EU Сообщений: 2921 |
Сейчас для Competitive Advantage (конкуренция, ценообразование, доля рынка и его динамика) этого уже не достаточно, реакция необходима практически мгновенно (e-Commerce начиная от цен, маркетинга и до Recommender engine, Fraud Detection, Credit(default)-Risk, Market Risk, Insurance, AML {Anti-Money-Laundering} и пр.) К сообщению приложен файл. Размер - 133Kb |
20 май 19, 20:36 [21889210] Ответить | Цитировать Сообщить модератору |
vikkiv Member Откуда: EU Сообщений: 2921 |
А это уже совсем другие latency где на классический ETL действительно нет времени, там уже вступают в силу другая логика/алгоритмы (ML/AI, Cognitive, и т.д.) и архитектуры (Lambda - hot), поэтому наблюдается явный рост на Data Science, БигДату (хотя я и не совсем согласен с её ролью в этой цепи) т.к. здесь раздел MS/ SQL Server - то в принципе M$ вполне неплохо адаптируется развивая Microsoft Data Platform Ecosystem, добавляя элементы, технологии (R, Python, AML {Azure Machine Learning - Studio, Server, Service}, Stream Analytics, Time Series Insight, Auto ML, ML.NET, Spark/Data Bricks и пр.) и интеграционные решения, причём уже чётко сделав ставку на рост спроса гибкости вычислительных мощностей (Azure) К сообщению приложен файл. Размер - 30Kb |
20 май 19, 20:37 [21889211] Ответить | Цитировать Сообщить модератору |
vikkiv Member Откуда: EU Сообщений: 2921 |
Вот например что по этой тенденции нагуглилось от Gartner ещё 10-ти летней давности! Другое дело что ТС просто не знает как правильно управлять ролями в том-же PowerBI.. там не такое уж сложное администрирование при правильной реализации (Best Practices), но если будут по старинке на коленке писать через RLS на клиенте - то сами себе злые буратино. К сообщению приложен файл. Размер - 60Kb |
20 май 19, 20:37 [21889212] Ответить | Цитировать Сообщить модератору |
vikkiv Member Откуда: EU Сообщений: 2921 |
кстати тот-же Azure Data Warehouse на ColumnStore и нескольких нодах отличная замена OLAP (или дополнение через ROLAP) через DirectQuery (который из PBI работает и к SQL источникам и к SSAS), хотя по желанию можно и Import делать для не особо секретного (или осторожней с доступом распостранением).. если для BI нет своего приложения - те-же .NET Assemblies неплохое дополнение в SSAS для расширения функциональности под аналитику через user_functions/stored_procedure заодно - Power BI , это ведь тоже OLAP, там то-же табличное ядро как и в SSAS на основе xVelocity/Vertipaq под приложением msmdsrv.exe который принимает локальные подключения к табличной модели из любых других клентов (Excel, SSMS и т.д.) если настроить правильный порт. в общем всё устаревает (и в последнее время - быстрее) а изменения неизбежны, т.е. многие технологии списываются в утиль (а с ними и знания/навыки, как-бы этого не хотелось ![]() |
20 май 19, 20:59 [21889222] Ответить | Цитировать Сообщить модератору |
H5N1 Member Откуда: Yo.! из "Сравнения субд" Сообщений: 445 |
ноги, крылья ... главное хвост ! судя по всему майкрософт как минимум в свой реляционный огрызок в аналитике совсем не верит. теперь мс делает ставку на spark+hadoop. на замену всяких олапов и ролапов в mssql2019 прикрутили полноценную hdfs и spark2. если они сделают spark как энжин мсскл это будет хорошая заявка на успех. |
20 май 19, 21:59 [21889248] Ответить | Цитировать Сообщить модератору |
vikkiv Member Откуда: EU Сообщений: 2921 |
H5N1, на замену это когда одно прикрутили, а другое откручивают, так что это явно не "на замену", а в дополнение, расширение горизонтов/возможностей я конечно не спец по этому вопросу - но в чём преимущества и нужны-ли они? дешевое дисковое пространство и в родной MS среде не проблема, разнести запрос по множеству расчётных нод и собрать для выдачи клиенту на главной - тоже давно решалось без затруднений на родных MPP (PDW, APS, Azure DWH) или elastic query. скорость (передачи/чтения)? латентность? пропускная способность? цена? надёжность? в чём суть/польза то? (native/optimized c++ vs scala/java по тестам производительности вроде-бы не сильно различаются) эдак ради сложности да мудрёности можно ведь и дюжину и сотню прослоек наставить.. в общем конечно зависит от приоритета решения - но по балансу факторов лучше стек технологий поуже держать да без лишних прослоек.. |
20 май 19, 22:39 [21889255] Ответить | Цитировать Сообщить модератору |
H5N1 Member Откуда: Yo.! из "Сравнения субд" Сообщений: 445 |
вангую что это такая же замена как олап->ролап
у спарка есть киллер фичи и он сейчас по сути отраслевым стандартом становится. спарк есть у хадупа, в любом облаке, есть у оракла (в виде bigdata applience), будешь смеятся но спарк есть даже на мейнфрейме. т.е. готовые тучи спецов знакомые с технологией и заказчик думающий что это спасет от вендор лока. изучать всякую муть только лишь от майкрософта и для майкрософта с каждым годом будет сложней, особенно если эта муть уже лет 10 так и не может сформулировать, что оно может противопоставить, причем за неслабые деньги. что касается спарка, то концептуально там есть прикольные фичи. правда оговорюсь, у нас на cloudera hadoop, где спарк на каждую киллер фичу генерит киллер хрень. так вот, там не только и не сколько SQL. там можно писать жава код с датафреймами в стиле dataframe1.select("col1", "col2"); dataframe1.select("col1").filter ...; obj1.process(dataframe1); т.е. то что ты в классике жанра вынужден пихать в один многостраничный и не читаемый SQL тут можно раскладывать по разным классам, передавать в методы. при этом операции с датафреймами это лишь декларация о хотелках, которые выполнятся только когда от датафрейма попросили некой терминальной операции. типа вывести на экран или записать в файл. внутрь датафрейма можно втыкать вызовы любой жаба библиотеки. т.е. внутри датафрейма можно хоть гугловский тензерфлоу приладить и получится что процесс что читает данные и эти же данные скармливает либе. в классике у тебя пол любому данные доступны лишь встроенным в скл движок функциям. в случае с мсскл если надо что-то большее чем встроено - данные из скл ядра копируются в .Net машину со всеми вытекающими. плюс там все кластеризуется из коробки, есть понятие спарк стриминга, что в связке с кафкой тоже слегка меняет подходы к обработке инфы. поскольку это по сути галимая жава, то можно писать полноценные юнит и интегрейшен тесты. вобщем если это заработает у мс как задумано, это будет новая эпоха. концепции там заложены обалденные, сыро только очень ... |
||||
20 май 19, 23:33 [21889275] Ответить | Цитировать Сообщить модератору |
vikkiv Member Откуда: EU Сообщений: 2921 |
H5N1, млин, спасибо за объяснения, мне уже казалось что со своим стеком десятка языков захлёбываюсь, а тут ещё это начнут к SQL серверу докручивать, честно говоря уже иногда руки опускаются как посмотрю сколько постоянно догонять нужно чтобы хотя-бы на уровне держаться.. |
21 май 19, 00:02 [21889284] Ответить | Цитировать Сообщить модератору |
vikkiv Member Откуда: EU Сообщений: 2921 |
(правда большинство методов/функций внутренние), но в принципе API понемногу развивается, много чего скриптуется/автоматизируется (в основном для онлайн сервиса Power BI), так что в ручную лазить по сотням отчётам - это уже перебор. Для PBI есть отдельный API, дот.нетовские сборки, специальные модули https://docs.microsoft.com/en-us/rest/api/power-bi/ https://www.nuget.org/packages/Microsoft.PowerBI.Api/ https://docs.microsoft.com/en-us/dotnet/api/overview/azure/powerbi-embedded https://docs.microsoft.com/en-us/power-bi/developer/rest-api-reference вот по ML.NET https://docs.microsoft.com/en-us/dotnet/machine-learning/ https://docs.microsoft.com/en-us/dotnet/api/?view=ml-dotnet но это если уж совсем ручной работы много - т.к. всё сырое ещё, меняется часто, пока не стабилизируется и функционал не отточат - смысла привязываться нет особого, потому что исторически у них много продуктов вроде-бы и в релиз пускают, рекламируют сильно, народ подсаживают, а потом вдруг через год-два списывают в утиль т.к. не взлетает (или по др. причинам), и резко становится жалко потраченного времени. |
||
24 май 19, 05:10 [21892605] Ответить | Цитировать Сообщить модератору |
Все форумы / Microsoft SQL Server | ![]() |