Эволюция от механизмов запросов на основе SQL для больших данных к механизмам озера данных, включая его влияние на хранилища данных и озера данных
Введение
С точки зрения высокого уровня, большинство решений для обработки данных и аналитики строились одинаково уже много лет. Вкратце, состоящий из разнообразных процессов интеграции для загрузки всех данных в одно центральное место, служащий единым источником правды для будущего моделирования данных и аналитических сценариев использования. В то время как раньше эти центральные места были в основном дорогими и негибкими, тесно связанными аппаратными / программными системами, в настоящее время обычно используются преимущества облачной и распределенной архитектуры, включая разделение вычислений и хранилищ. Тем не менее, несмотря на огромный технический прогресс, достигнутый в последние годы, общий подход к централизации данных по-прежнему является наиболее очевидным способом получения максимальной отдачи от данных и правильного управления данными.
Централизация
Так что же плохого в этом централизованном подходе и какое отношение он имеет к механизмам распределенных запросов?
Начнем с того, что ничего не сказать против этого - как раз наоборот - создание массивных хранилищ данных или озер данных, содержащих все данные в одном месте в ясном и свежем состоянии, часто является единственным способом обеспечить согласованность, чтобы все в использовании тех же определений. В этом отношении, особенно сервисы облачных озер данных, такие как Microsoft Azure Data Lake Storage или Amazon Web Service S3, представляют собой интересный поворот, предоставляя еще больше преимуществ централизации благодаря очень масштабируемому и недорогому способу хранения огромных объемов любых данных.
Рекомендации
Тем не менее существует множество причин, по которым централизация всех данных становится все труднее. Количество источников данных растет, как и универсальность наборов данных, необходимых для удовлетворения растущего числа различных бизнес-областей, полагающихся на эти данные. Бизнес-пользователи в целом приближаются к данным, требующим большей гибкости по сравнению со статическими предварительно созданными наборами данных. То же самое относится и к вариантам использования расширенной аналитики: методы часто необходимо применять к необработанным и непреобразованным данным. Более того, в некоторых случаях организациям даже запрещается перемещать данные из-за каких-либо внутренних или внешних правил. В других случаях все еще существуют конвейеры поверх централизованной загрузки данных в любые последующие системы для удовлетворения всех аналитических требований. Это, в свою очередь, может даже привести к той же блокировке, что и в традиционных локальных системах. Или случаи использования, когда централизации данных недостаточно для оправдания затраченных усилий или, возможно, данные слишком велики и их перемещение займет слишком много времени. И так далее…
Так что же делать в таких обстоятельствах?
Федерация
Сегодня существует множество вариантов, когда речь идет об аналитических решениях и управлении их данными. Не только разные поставщики, включая их предложения, но и различные виды технологий огромны, а темпы технологического прогресса быстрее, чем когда-либо прежде. Также нет явного победителя, все они вместе помогут преобразовать больше этих калорий данных во что-то полезное, в этом нет никаких сомнений. Тем не менее, действительно существует заметная тенденция к тому, что механизмы распределенных запросов на основе SQL помогают справиться с ростом объемов данных. Это также подтверждает линейку продуктов существующего поставщика услуг данных и аналитики и их последние разработки. Все они стремятся беспрепятственно интегрировать эти рентабельные облачные хранилища и разрешать интерактивные запросы SQL поверх них с использованием именно таких механизмов запросов. Таким образом, они могут заполнить недостающие пробелы, упомянутые выше, и позволить зрелым предприятиям достичь расширенных возможностей больших данных, сохраняя при этом организационную стабильность и стабильность платформы, сохраняя при этом центральную точку истины.
Виртуализация данных
Основная идея распределенных механизмов запросов - это не что иное, как виртуализация данных и попытка создать уровень абстракции, который обеспечивает доступ к данным из разрозненных источников данных. Отличие от традиционного программного обеспечения для виртуализации данных (связанных серверов, DBLink и т. Д.) Заключается в том, что вы можете запрашивать реляционные и нереляционные данные вместе в горизонтальном масштабе для повышения производительности запросов. Следовательно, слово «распределенный» относится не только к самому запросу, но также к вычислению и хранению. В основном они предназначены для интенсивных запросов OLAP и, как таковые, не так уж хрупки и непоследовательны с точки зрения производительности.
SQL-на-Hadoop
Первоначально использовавшаяся для этого технология называлась SQL-on-Hadoop, а точнее, ее до сих пор часто называют SQL-on-Hadoop, основанной на механизмах MPP (Massive Parallel Processing). Он позволяет запрашивать и анализировать данные, хранящиеся в HDFS (распределенная файловая система Hadoop), используя знакомый SQL-подобный язык, чтобы скрыть сложность MapReduce / Tez и сделать его более доступным для разработчиков баз данных. Hive, возможно, был первым механизмом SQL в Hadoop и до сих пор широко используется для пакетной обработки данных, поскольку зарекомендовал себя как очень надежный, не считая достижений, сделанных за эти годы. Hive переводит SQL-запросы на несколько этапов и сохраняет промежуточные результаты на диски. Тем временем в экосистеме Hadoop изначально были разработаны другие специализированные инструменты, такие как Impala, которые также поддерживают HBase в качестве источника данных. По сравнению с Hive он использует преимущества технологий в памяти и кэширования, которые больше предназначены для интерактивного анализа, чем для длительных пакетных заданий. Другим примером в этой категории может быть SparkSQL. Все они требуют предварительного определения метаданных, также известного как схема при чтении, например представления или внешние таблицы. Это определение хранится в централизованном хранилище, таком как хранилище метаданных Hive.
SQL-on-Anything
По мере развития технологий требовалось больше открытости, и она не была строго привязана к Hadoop, а была слабо связана с поддержкой многих других типов баз данных. Таким образом, механизмы запросов обеспечивали своего рода автоматическое обнаружение огромного количества данных без каких-либо предварительных условий и подготовки. Кроме того, в качестве интерфейса был предоставлен стандартный ANSI SQL, который сделал его еще более доступным для аналитиков данных и разработчиков. В то же время схему больше не нужно было обязательно определять заранее, некоторые движки даже могут разрешать ее автоматически на исходном уровне хранения, отправляя запросы вниз, такие как Drill. Еще один новаторский инструмент в этой области - Presto, который даже позволяет запрашивать данные в реальном времени, поступающие от Kafka и Redis. Presto - это распределенный механизм SQL-запросов в памяти, разработанный Facebook именно для этих нужд, чтобы управлять интерактивной аналитикой разрозненных наборов данных. Для таких компаний, как Netflix, Twitter, Airbnb или Uber, это имеет решающее значение для их повседневного бизнеса, иначе они не смогут обрабатывать и анализировать свои петабайты данных. Presto можно использовать вместе со многими различными инструментами бизнес-аналитики, включая Power BI, Looker, Tableau, Superset или любой другой инструмент, совместимый с ODBC и JDBC. В этом контексте впервые было придумано название SQL-on-Anything.
Механизмы озера данных
Технологический подход движков озера данных не сильно отличается. В конце концов, это просто виртуализация данных и объединение данных из разных источников. Обычно они отличаются предоставлением большего количества функций в отношении моделирования данных, преобразования данных, структуры данных и безопасности данных. Как правило, они также больше ориентированы на облако, и можно утверждать, что они тем временем объединяются с богатым пользовательским интерфейсом, предлагая своего рода философию самообслуживания данных даже для нетехнических пользователей. Такой подход позволяет в полной мере использовать преимущества централизации данных в общедоступных облаках и обеспечивает интерактивный анализ с меньшими затратами благодаря эластичности облака по цене без риска блокировки. Data Lake Engines также не обязательно поддерживает больше источников данных, но из-за их позднего появления они могут использовать преимущества новейших технологий с нуля. Databricks, например, недавно анонсировала SQL Analytics на базе своего Delta Engine, который напрямую запрашивает таблицы Delta Lake в озерах данных. Кроме того, он предоставляет собственный SQL-интерфейс для исследования данных, а информационные панели могут использоваться совместно друг с другом. Еще один очень многообещающий инструмент и один из моих любимых в этом отношении - это Dremio, который в основном имеет открытый исходный код, но поддерживается одноименной компанией, предлагающей коммерческую корпоративную версию с некоторыми дополнительными функциями.
Dremio создает прямой мост между инструментами бизнес-аналитики и системами запрашиваемых источников данных в отличие от традиционных многоуровневых архитектур. Основные технологии, используемые за кулисами: Drill, Arrow, Calcite и Parquet. Эта комбинация обеспечивает SQL без схемы для различных источников данных, а также механизм выполнения аналитики в памяти по столбцам с функцией выталкивания вниз, и можно легко материализовать запросы для повышения производительности запросов. Между тем, Arrow пока что считается своего рода стандартом де-факто для аналитики в памяти.
Заключение
В конце концов, централизовать ли данные физически или нет, полностью зависит от варианта использования, и такие механизмы предоставляют вам альтернативное решение, запрашивая данные там, где они на самом деле находятся. Точно так же, даже если такие механизмы запросов могут показаться универсальными для всех решений, все равно будут существовать варианты использования, которые нельзя решить на лету и которые по-прежнему требуют процессов интеграции данных и надлежащего моделирования данных, не говоря уже о реальных- данные о времени на основе микросервисных архитектур. Также важно отметить, что старые механизмы распределенных запросов не уйдут так быстро, как Hive, они слишком хорошо работают в уже столь многих существующих архитектурах данных и, кроме того, легко интегрируются с большинством новых технологий. Посмотрим, что нас ждет в будущем.
