Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
Nika gnome
Member

Откуда:
Сообщений: 560
Возьмём стек Microsoft, т.к. ветка посвящена именно ему.

+
Есть SQL Server:
  • SSIS - реализует ETL
  • SSEngine - собственно, сама реляционная база
  • SSAS - кубы, те самые, что "используются только в гос.конторах", "ушедшие в прошлое".
  • SSRS - позволяет всё это дело визуализировать

    Есть PowerBI - грубо говоря, всё то же самое, только более "плюшевое", т.к. позволяет excel-знатоку сделать себе отчёт на основе разрозненных данных:
  • Power Query - реализует ETL
  • Power Pivot - схема данных
  • Power View - визуализирует данные, там же с помощью DAX можно сделать то же, что можно сделать с помощью кубов.

    И есть облако - там вообще дохрена всего. Но компания против того, чтобы выносить все данные на внешние сервера (по деньгам, по безопасности и т.п.).

    Если реализовывается хранилище данных (Data warehouse), то часто делается так:
  • SSIS+SSE+PowerBI

  • Теперь к сути.
    Что не так с 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]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    L_argo
    Member

    Откуда:
    Сообщений: 932
    Что не так с SSRS, про который я ото всюду слышу, то он архаичен?
    Это печаталка отчетов.
    Поэтому для задач анализа данных неудобна, т.к. по настоящему гибкий и быстрый анализ можно получить с помощью BI.

    Покрутите к-л сложный БИ-дашборд, тогда поймете разницу.
    20 май 19, 12:16    [21888737]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    Dimitry Sibiryakov
    Member

    Откуда:
    Сообщений: 48414
    Nika gnome
    Что даёт куб?

    Как и любой другой хранимый агрегат, единственное, что он даёт - скорость выборки.
    20 май 19, 13:41    [21888855]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    Ferdipux
    Member

    Откуда: Москва
    Сообщений: 508
    Nika gnome
    Что даёт куб?

    Если отвлечься от исторического аспекта, то:
  • Семантическую модель (измерения - меры), готовую к использованию в Excel Pivot.
  • Скорость извлечения данных для семантической модели
  • Некие возможности вычислений
  • 20 май 19, 14:23    [21888909]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    StarikNavy
    Member

    Откуда: Москва
    Сообщений: 2259
    Nika gnome,

    у вас кони и люди не смешались? в заголовке вопрос про SSAS (кубы) внутри про SSRS (репортинг)

    имхо, главная проблема в том что ребята не обновляют движок олапа, поэтому конкуренты поджимают со всех сторон (оба направления)

    начальство желает красивые отчетики на смартфонах, а тут скучные древние эксельки
    20 май 19, 14:29    [21888913]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    Nika gnome
    Member

    Откуда:
    Сообщений: 560
    L_argo
    Что не так с SSRS, про который я ото всюду слышу, то он архаичен?
    Это печаталка отчетов.
    Поэтому для задач анализа данных неудобна, т.к. по настоящему гибкий и быстрый анализ можно получить с помощью BI.

    Покрутите к-л сложный БИ-дашборд, тогда поймете разницу.

    тфуты блин.... я имел в виду SSAS
    C отчётами там всё предельно ясно.
    20 май 19, 15:30    [21888987]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    Nika gnome
    Member

    Откуда:
    Сообщений: 560
    StarikNavy
    у вас кони и люди не смешались? в заголовке вопрос про SSAS (кубы) внутри про SSRS (репортинг)

    смешались. Вернее, опечатка произошла.
    20 май 19, 15:30    [21888988]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    Nika gnome
    Member

    Откуда:
    Сообщений: 560
    Спрошу иначе:
    OLAP кубы сейчас используются или им на замену что-то пришло?
    20 май 19, 15:32    [21888990]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    Критик
    Member

    Откуда: Москва / Калуга
    Сообщений: 32265
    Блог
    Nika gnome,

    используются
    20 май 19, 16:09    [21889004]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    vikkiv
    Member

    Откуда: London
    Сообщений: 2468
    Nika gnome,

    и на замену тоже пришло
    20 май 19, 16:38    [21889022]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    alexeyvg
    Member

    Откуда: Moscow
    Сообщений: 29284
    Nika gnome
    Что не так с SSAS, про который я ото всюду слышу, то он архаичен? Что он - "лишний элемент"? Во множестве мест, где заходит дискуссия, мне какие-то комментаторы гооворят, что нужно реализовывать Inmemory решения.
    Про кубы, я тоже слышал, что общая тенлденция - вместо кубов в BI всё больше используются реляционные источники данных.
    Действительно, "уходят в прошлое", "госконторы", точнее, просто унаследованный код, как мэйнфреймы.

    Думаю, из за того, что реляционные хранилища стали очень хороши, а кубы содержат концепцию обработки, загрузки, пересчёта, и т.п.
    А сейчас требуют реальное время, и объёмы данных стали велики.
    Раньше запрос к 10 гб в РСУБД было сделать трудно, а вот специализированные аналитические хранилища могли это загружать и обрабатывать. Пусть "за ночь", но могли.
    А сейчас 10 или 100 гб РСУБД обрабатывают легко, а петабайтные базы в кубы "за ночь" не зальёшь.
    20 май 19, 19:37    [21889172]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    vikkiv
    Member

    Откуда: London
    Сообщений: 2468
    Как-бы и да и нет, это конечно существенный фактор (объёмы/производительность, т.е. расчётные мощности) но основной фактор (коррелирующий с указанным 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]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    vikkiv
    Member

    Откуда: London
    Сообщений: 2468
    Сейчас для Competitive Advantage
    (конкуренция, ценообразование, доля рынка и его динамика)
    этого уже не достаточно, реакция необходима практически мгновенно
    (e-Commerce начиная от цен, маркетинга и до Recommender engine, Fraud Detection,
    Credit(default)-Risk, Market Risk, Insurance, AML {Anti-Money-Laundering} и пр.)

    К сообщению приложен файл. Размер - 133Kb
    20 май 19, 20:36    [21889210]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    vikkiv
    Member

    Откуда: London
    Сообщений: 2468
    А это уже совсем другие 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]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    vikkiv
    Member

    Откуда: London
    Сообщений: 2468
    Вот например что по этой тенденции нагуглилось от Gartner ещё 10-ти летней давности!


    Другое дело что ТС просто не знает как правильно управлять ролями в том-же PowerBI..
    там не такое уж сложное администрирование при правильной реализации (Best Practices),
    но если будут по старинке на коленке писать через RLS на клиенте - то сами себе злые буратино.

    К сообщению приложен файл. Размер - 60Kb
    20 май 19, 20:37    [21889212]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    vikkiv
    Member

    Откуда: London
    Сообщений: 2468
    кстати тот-же 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]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    H5N1
    Member

    Откуда: Yo.! из "Сравнения субд"
    Сообщений: 235
    ноги, крылья ... главное хвост !
    судя по всему майкрософт как минимум в свой реляционный огрызок в аналитике совсем не верит. теперь мс делает ставку на spark+hadoop. на замену всяких олапов и ролапов в mssql2019 прикрутили полноценную hdfs и spark2. если они сделают spark как энжин мсскл это будет хорошая заявка на успех.
    20 май 19, 21:59    [21889248]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    vikkiv
    Member

    Откуда: London
    Сообщений: 2468
    H5N1,

    на замену это когда одно прикрутили, а другое откручивают,
    так что это явно не "на замену", а в дополнение, расширение горизонтов/возможностей

    я конечно не спец по этому вопросу - но в чём преимущества и нужны-ли они?
    дешевое дисковое пространство и в родной MS среде не проблема,
    разнести запрос по множеству расчётных нод и собрать для выдачи клиенту на главной
    - тоже давно решалось без затруднений на родных MPP (PDW, APS, Azure DWH) или elastic query.
    скорость (передачи/чтения)? латентность? пропускная способность? цена? надёжность? в чём суть/польза то?
    (native/optimized c++ vs scala/java по тестам производительности вроде-бы не сильно различаются)
    эдак ради сложности да мудрёности можно ведь и дюжину и сотню прослоек наставить..
    в общем конечно зависит от приоритета решения - но по балансу факторов лучше стек технологий поуже держать да без лишних прослоек..
    20 май 19, 22:39    [21889255]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    H5N1
    Member

    Откуда: Yo.! из "Сравнения субд"
    Сообщений: 235
    vikkiv
    на замену это когда одно прикрутили, а другое откручивают,
    так что это явно не "на замену", а в дополнение, расширение горизонтов/возможностей

    вангую что это такая же замена как олап->ролап

    vikkiv
    я конечно не спец по этому вопросу - но в чём преимущества и нужны-ли они?
    дешевое дисковое пространство и в родной MS среде не проблема,
    разнести запрос по множеству расчётных нод и собрать для выдачи клиенту на главной
    - тоже давно решалось без затруднений на родных MPP (PDW, APS, Azure DWH) или elastic query.
    скорость (передачи/чтения)? латентность? пропускная способность? цена? надёжность? в чём суть/польза то?
    (native/optimized c++ vs scala/java по тестам производительности вроде-бы не сильно различаются)
    эдак ради сложности да мудрёности можно ведь и дюжину и сотню прослоек наставить..
    в общем конечно зависит от приоритета решения - но по балансу факторов лучше стек технологий поуже держать да без лишних прослоек..

    у спарка есть киллер фичи и он сейчас по сути отраслевым стандартом становится. спарк есть у хадупа, в любом облаке, есть у оракла (в виде bigdata applience), будешь смеятся но спарк есть даже на мейнфрейме. т.е. готовые тучи спецов знакомые с технологией и заказчик думающий что это спасет от вендор лока. изучать всякую муть только лишь от майкрософта и для майкрософта с каждым годом будет сложней, особенно если эта муть уже лет 10 так и не может сформулировать, что оно может противопоставить, причем за неслабые деньги.

    что касается спарка, то концептуально там есть прикольные фичи. правда оговорюсь, у нас на cloudera hadoop, где спарк на каждую киллер фичу генерит киллер хрень.
    так вот, там не только и не сколько SQL. там можно писать жава код с датафреймами в стиле
    dataframe1.select("col1", "col2");
    dataframe1.select("col1").filter ...;
    obj1.process(dataframe1);
    т.е. то что ты в классике жанра вынужден пихать в один многостраничный и не читаемый SQL тут можно раскладывать по разным классам, передавать в методы. при этом операции с датафреймами это лишь декларация о хотелках, которые выполнятся только когда от датафрейма попросили некой терминальной операции. типа вывести на экран или записать в файл.
    внутрь датафрейма можно втыкать вызовы любой жаба библиотеки. т.е. внутри датафрейма можно хоть гугловский тензерфлоу приладить и получится что процесс что читает данные и эти же данные скармливает либе. в классике у тебя пол любому данные доступны лишь встроенным в скл движок функциям. в случае с мсскл если надо что-то большее чем встроено - данные из скл ядра копируются в .Net машину со всеми вытекающими.
    плюс там все кластеризуется из коробки, есть понятие спарк стриминга, что в связке с кафкой тоже слегка меняет подходы к обработке инфы. поскольку это по сути галимая жава, то можно писать полноценные юнит и интегрейшен тесты. вобщем если это заработает у мс как задумано, это будет новая эпоха. концепции там заложены обалденные, сыро только очень ...
    20 май 19, 23:33    [21889275]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    vikkiv
    Member

    Откуда: London
    Сообщений: 2468
    H5N1,

    млин, спасибо за объяснения, мне уже казалось что со своим стеком десятка языков захлёбываюсь,
    а тут ещё это начнут к SQL серверу докручивать, честно говоря уже иногда руки опускаются
    как посмотрю сколько постоянно догонять нужно чтобы хотя-бы на уровне держаться..
    21 май 19, 00:02    [21889284]     Ответить | Цитировать Сообщить модератору
     Re: Часто встречаю мнение: "OLAP кубы ушли в прошлое". Какая тогда им альтернатива?  [new]
    vikkiv
    Member

    Откуда: London
    Сообщений: 2468
    Nika gnome
    ...Что получается в Inmemory (как я это вижу)
    Создаётся 50 отчётов PowerBI. В каждом из них заново необходимо прописывать какие-то права на 1000 пользователей,
    формулы (коэффициенты какие-нибудь). И т.п. И все эти отчёты нужно ещё сопровождать каким-то образом.
    Изменились права пользователей - пошёл по всем отчётам править доступы...
    Покопайся в директории Power BI, там DLL вполне достаточно - и по PBI, и ML, и AI
    (правда большинство методов/функций внутренние), но в принципе 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 Ответить