Комментарии 3
Большое спасибо.
Я не очень хорошо понял, что подразумевается под
Я не очень хорошо понял, что подразумевается под
Logical DWHВы не могли бы рассказать немного подробнее и привести примеры, пожалуйста. Сначала я подумал, что это что-то типа Cisco Information Server — для data virtualisation, но Trifacta в списке софта меня несколько смущает. Ведь это просто инструмент для «начального» анализа данных и встроен в GCP Dataprep насколько я понимаю…
Вы правы, я скорее всего ошибся при наборе тескта, я бы Trifacta перенес бы в раздел Self Service BI.
Logical DWH — это по сути еще одно название для data virtualisation, я почитал про Cisco Information Server (я так понял, их весь бизнес по виртуализации данных приобрела компания Tibco, которая тоже была на конференции, но я на нее не обратил внимания), да, похоже это Logical DWH в терминологии Gartner и есть.
Ключевое отличие от классического DWH заключается в том, что то место, через которое осуществляются все запросы к данным, не является физически тяжеловесным централизованным хранилищем данных, я представляет собой лишь тонкий слой метаданных (ну может еще и кэш), который знает, где в Enterprise какие данные лежат.
Причем для пользователя такая архитектура является абсолютно прозрачной, т.е. он все так же работает с данными, как до этого привык, и не замечает никакой разницы. Всю работу по прокидыванию запросов пользователя к реальным данным, хранящимся, вообще говоря, в разных технологиях, осуществляет под капотом софт этого самого Logical DWH.
И что самое главное, это может быть не просто проксирование запросов к месту хранения данных, это может быть и джойн нескольких физических источников в одном запросе на Logical DWH. То есть я, как пользователь, захожу на Logical DWH и вижу, что мне доступны «таблицы» Client и Transactions, я определяю витрину, содержащую join этих таблиц, а Logical DWH сам определяет, как бы ему пооптимальней отдать мне результат этого запроса, учитывая, что, например, история Transactions это петабайтный файл на Hadoop, а Client это 100-тысячная таблица на неком слабеньком mySQL.
Все вендоры в один голос утверждали, что их софт обработает такую ситуацию корректно, а именно, разобьет один логический запрос на два (для Hadoop и mySQL), соптимизирует каждый из запросов, отправит на источники, и потом склеит (где-то) результат и вернет его мне, причем сделает это достаточно быстро.
Logical DWH — это по сути еще одно название для data virtualisation, я почитал про Cisco Information Server (я так понял, их весь бизнес по виртуализации данных приобрела компания Tibco, которая тоже была на конференции, но я на нее не обратил внимания), да, похоже это Logical DWH в терминологии Gartner и есть.
Ключевое отличие от классического DWH заключается в том, что то место, через которое осуществляются все запросы к данным, не является физически тяжеловесным централизованным хранилищем данных, я представляет собой лишь тонкий слой метаданных (ну может еще и кэш), который знает, где в Enterprise какие данные лежат.
Причем для пользователя такая архитектура является абсолютно прозрачной, т.е. он все так же работает с данными, как до этого привык, и не замечает никакой разницы. Всю работу по прокидыванию запросов пользователя к реальным данным, хранящимся, вообще говоря, в разных технологиях, осуществляет под капотом софт этого самого Logical DWH.
И что самое главное, это может быть не просто проксирование запросов к месту хранения данных, это может быть и джойн нескольких физических источников в одном запросе на Logical DWH. То есть я, как пользователь, захожу на Logical DWH и вижу, что мне доступны «таблицы» Client и Transactions, я определяю витрину, содержащую join этих таблиц, а Logical DWH сам определяет, как бы ему пооптимальней отдать мне результат этого запроса, учитывая, что, например, история Transactions это петабайтный файл на Hadoop, а Client это 100-тысячная таблица на неком слабеньком mySQL.
Все вендоры в один голос утверждали, что их софт обработает такую ситуацию корректно, а именно, разобьет один логический запрос на два (для Hadoop и mySQL), соптимизирует каждый из запросов, отправит на источники, и потом склеит (где-то) результат и вернет его мне, причем сделает это достаточно быстро.
Уверен, что ни один софт не обработает такую ситуацию по настоящему корректно. То есть при выборе не всех клиентов а только лишь например нерезидентов — зафильтровать таблицу транзакций из хадупа по ним. А при частой выборке — вообще партицировать её по этому типу. А при реалтайм запросах по избранным клиентам — вообще перегружать в rdbms для бытрого индексного доступа. И все это автоматически, под капотом у Logical DWH.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Gartner Data & Analytics Summit 2018