Думаю, все зависит от задачи. Все-таки, МРР больше предназначена для ADWH / ODS, чем для "кладбища данных" / HDS. Кстати, согласно исследованиям, 68-73% данных, попадающих в хранилище, никогда не используются. Держать данные в "горячей" доступности - очень недешевое удовольствие, надо понимать зачем это нужно:

• Понятно зачем МРР (тот же Exasol) Ситимобайлу - надо знать, где какая машина, чтобы оперативно предложить подходящий подходящий вариант клиенту - выслать предложение таксистам недалеко от места вызова, или которые скоро закончат поездку в данном районе и предложить варианты клиенту, спрогнозировать спрос, оптимизировать логистику и распределение машин, рассчитать стоимость поездки и комиссионные.
  
• Понятно, зачем МРР Байде и прочим Тиндерам - показать варианты, основываясь на ряде совпадающих параметров / интересов и предыдущем опыте / рейтинге.
  
• Понятно, зачем МРР банкам: онлайн формирование персонализированных предложений (Next Best Offer), онлайн-скорринг, кредитный конвейер, система лояльности, выявление склонных к оттоку клиентов, возможно - решение части фродовых задач или тюнинг фрод-параметров.
  
• Понятно, зачем МРР крупным интернет-магазинам: помощь в формировании корзины, Next Best Offer "вам понравится / с этим товаром берут", лояльность, отток.
  

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

Я не очень понимаю, зачем МРР использовать для хранения дикого объёма исторических данных. А вот BigData для этого вполне подходит, так как стоимость хранения данных там сильно ниже.

Поэтому мы и видим подобное разделение - часть данных в BD (пусть будет, потом разберемся / HDS), часть - в быстрый ODS, который можно реализовать с помощью МРР-технологии.

С Уважением,
Георгий

Вполне может быть, кстати. Да, тоже интересно. Но, имхо, можно хранить много параметров (вместимость, есть ли детское кресло/кресла, можно ли брать на доставку грузов / еды, перевозит ли животных - хотя это копейки данных) и телематику - разгон/торможение, расход бензина, музыку в салоне и т.д., для оценки водителей и стилей вождения, отзывы пассажиров, их оценки и стоп-листы, чтобы подобрать "более комфортного" водителя. Но было бы интересно узнать "из первых рук".

С Уважением,
Георгий

1. Да, вижу движение в этой сторону. Вернее, вижу некое разделение: BD + песочницы для датасатанистов и ODS на МРР для оперативной отчетности и решений задач по оптимизации, в т.ч. многофакторной.
2. А по тут пока не видно ничего - в МРР обычно хранится индексированная структурированная информация, NoSQL тут каким боком?

Это да, и как раз решают вышеприведенные мной задачи, но видно было движение сначала в сторону Splunk, теперь - в сторону Clickhouse (хранение логов и часть онлайн аналитики по логам) + Greenplum / Аренадата для более глубокого анализа. Честно, не видел чтобы там транзакции хранились - это строго на Oracle, но потом поднимаются с МРР. Кстати, несколько участников плотно её занимались, Vovaka (как раз в телекоме - Йоте или МФ, точно не помню), ASCRUS...

С Уважением,
Георгий

мигель1, учить бизнес-пользователя SQL / MDX / DAX - бесполезно. Они-то и со своими непосредственными обязанностями не все справляются, а тут еще такая нагрузка. Да и не все технари, для них это тёмный лес. Поэтому и были придуманы Self-Service BI, чтобы инкапсулировать бизнес-пользователей от разработки, и при этом разгрузить ИТ и аналитический отделы. Но большинство SS BI не переваривает большой объём информации, они каждый раз БД дергают и работают со скоростью отклика от БД. Поэтому и была придумана связка - реляционная БД (быстро пишет, медленно извлекает) или витрины КХД - МРР (обычно в неё медленная запись, так как сразу строится индекс и данные хранятся уже индексируемые и быстроизвлекаемые) и сверху Self-Service BI для издевательств бизнес-пользователей. Ставить МРР "просто так", без вышеуказанных задач онлайн-оптимизации или построения оперативной аналитики - ну, не знаю... хотя, если платят, можно и поэкспериментировать

С Уважением,
Георгий

Главное - не учить DELETE, BULK INSERT и, возможно, DISTINCT COUNT Но тут такэ.... они же их достанут тогда своими хотелками. Я как раз и рассказываю сейчас про Дата Литераси - не просто так, а как выстроить корпоративную культуру массового распространения аналитики, про переход от аналитического отдела, который становится "бутылочным горлышком" и децентрализованной аналитики (Excel-анархии) до массового использования аналитики и демократизации данных. У нас на проекте за год 1700 аналитических приложений пользователи напаяли, большинство из них прошли сертификацию. Ни один партнёр, ни десять аналитических отделов с подобным объёмом работ бы не справилось - только обучение, институт наставничества, поиск "дата-звёздочек", работа с ними, их поддержка и обучение. Плюс разъяснительная работа про карты показателей, фиксирование ответственных за показатель, базы знаний показателей и расчетов, политики доступа к данным и много чего ещё. Ну и поддержка руководства.

С Уважением,
Георгий

Увы, если не будет задачи - никто не будет искать решение. Если есть одна учетная система, никто не будет делать хранилище - все будут данные из ERP дергать и потом Ёхелем ковырять. А вот когда систем несколько... а вот когда нужно хранить историю, а вот когда понадобится получать оперативную отчетность - ну, вы и сами знаете предпосылки к DWH. Следовательно, одна из важнейших задач - объяснить бизнесу, зачем им вообще эта аналитика (под которую нужно DHL / ETL и т.д.). Это очень важно - не пытаться отгрызть кусок от пирога, а сделать ВЕСЬ пирог больше, тогда всем хватит и еще останется. И чем больше в компании пользователей BI, в т.ч. гражданских аналитиков, то тем востребованнее весь стек BI / ETL / DWH / DataLake решений.

С Уважением,
Георгий