Руководство Data Engineer по нетрадиционным хранилищам данных

Инжиниринг данных

С появлением больших данных и науки о данных многие роли инженеров оспариваются и расширяются. Одной из ролей нового века является разработка данных .

Первоначально целью разработки данных была загрузка внешних источников данных и проектирование баз данных (проектирование и разработка конвейеров для сбора, обработки, хранения и анализа данных).

С тех пор он вырос, чтобы поддерживать объем и сложность больших данных. Таким образом, инженерия данных теперь включает в себя широкий спектр навыков, от веб-сканирования, очистки данных, распределенных вычислений, хранения и поиска данных.

Для инженеров данных и инженеров данных хранение и извлечение данных являются критически важным компонентом конвейера, а также тем, как данные могут использоваться и анализироваться.

В последнее время появилось много новых и различных технологий хранения данных. Однако какой из них лучше всего подходит и имеет наиболее подходящие функции для обработки данных?

Большинство инженеров знакомы с базами данных SQL, такими как PostgreSQL, MSSQL и MySQL, которые структурированы в виде реляционных таблиц данных с построчным хранилищем.

Учитывая повсеместное распространение этих баз данных, мы не будем их сегодня обсуждать. Вместо этого мы исследуем три типа альтернативных хранилищ данных, популярность которых растет и в которых представлены различные подходы к работе с данными.

В контексте обработки данных такими технологиями являются поисковые системы, хранилища документов и столбцовые хранилища.

• Поисковые системы отлично справляются с текстовыми запросами. По сравнению с текстовыми совпадениями в базах данных SQL, таких как LIKE , поисковые системы предлагают более широкие возможности запросов и более высокую производительность.
• Хранилища документов обеспечивают лучшую адаптивность схемы данных, чем традиционные базы данных. Сохраняя данные в виде отдельных объектов документа, часто представляемых в виде JSON, они не требуют предварительного определения схемы.
• Столбчатые хранилища специализируются на запросах с одним столбцом и агрегациях значений. Операции SQL, такие как SUM и AVG , выполняются значительно быстрее при хранении по столбцам, поскольку данные одного и того же столбца хранятся ближе друг к другу на жестком диске.

В этой статье мы исследуем все три технологии: Elasticsearch как поисковую систему, MongoDB как хранилище документов и Amazon Redshift как хранилище столбцов.

Понимая альтернативное хранилище данных, мы можем выбрать наиболее подходящий для каждой ситуации.

Чтобы сравнить эти технологии, мы рассмотрим, как они индексируют, сегментируют и агрегируют данные.

Каждая стратегия индексации данных улучшает одни запросы, препятствуя другим.

Знание того, какие запросы используются чаще всего, может повлиять на выбор хранилища данных.

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

Выбор того, который соответствует нашему плану роста и бюджету, имеет решающее значение, и это относится к любой фирме, занимающейся наукой о данных, независимо от ее размера.

Наконец, каждая из этих технологий агрегирует свои данные по-разному.

Когда мы имеем дело с гигабайтами и терабайтами данных, неправильная стратегия агрегирования может ограничить типы и производительность отчетов, которые мы можем генерировать.

Как инженеры данных, мы должны учитывать все три аспекта при оценке различных хранилищ данных.

Претенденты

Поисковая система: Elasticsearch

Elasticsearch быстро завоевал популярность среди своих коллег благодаря своей масштабируемости и простоте интеграции. Построенный на основе Apache Lucene, он предлагает мощные готовые функции текстового поиска и индексирования. Помимо традиционных задач поисковой системы, текстового поиска и запросов с точным значением, Elasticsearch также предлагает возможности многоуровневой агрегации.

Магазин документов: MongoDB

На данный момент MongoDB можно считать базовой базой данных NoSQL. Простота использования и гибкость быстро завоевали популярность. MongoDB поддерживает многофункциональные и адаптируемые запросы для изучения сложных документов. Часто запрашиваемые поля можно ускорить за счет индексации, а при агрегировании больших объемов данных MongoDB предлагает многоэтапный конвейер.

Столбчатый магазин: Amazon Redshift

Наряду с ростом популярности NoSQL столбцовые базы данных также привлекли внимание, особенно для анализа данных. Благодаря хранению данных в столбцах вместо обычных строк операции агрегирования могут выполняться непосредственно с диска, что значительно повышает производительность. Несколько лет назад Amazon развернул свой хостинг для магазина с колонками под названием Redshift.

Индексация

Возможность индексирования Elasticsearch

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

В то время как другие хранилища данных создают индексы на основе точных значений поля, поисковые системы позволяют извлекать только фрагмент поля (обычно текстового).

По умолчанию этот поиск выполняется автоматически для каждого поля через анализаторы.

Анализатор — это модуль, который создает несколько ключей индекса, оценивая значения полей и разбивая их на более мелкие значения.

Например, базовый анализатор может исследовать фразу «быстрая коричневая лиса перепрыгнула через ленивую собаку» по словам, таким как «тот», «быстрый», «коричневый», «лиса» и так далее.

Этот метод позволяет пользователям находить данные путем поиска фрагментов в результатах, ранжированных по тому, сколько фрагментов соответствует одним и тем же данным документа.

Более сложный анализатор может использовать редактирование расстояний, n-граммы и фильтрацию по стоп-словам для построения комплексного поискового индекса.

Возможности индексирования MongoDB

Как универсальное хранилище данных, MongoDB обладает большой гибкостью для индексации данных.

В отличие от Elasticsearch, он по умолчанию индексирует только поле _id , и нам нужно создавать индексы для часто запрашиваемых полей вручную.

По сравнению с Elasticsearch анализатор текста MongoDB не такой мощный. Но он обеспечивает большую гибкость методов индексирования, от составного и геопространственного для оптимальных запросов до TTL и разреженного для уменьшения объема хранилища.

Возможность индексирования Redshift

В отличие от Elasticsearch, MongoDB или даже традиционных баз данных, включая PostgreSQL, Amazon Redshift не поддерживает метод индексации.

Вместо этого он сокращает время запроса, поддерживая согласованную сортировку на диске.

Как пользователи, мы можем настроить упорядоченный набор значений столбца в качестве ключа сортировки таблицы. С данными, отсортированными на диске, Redshift может пропустить целый блок во время извлечения, если его значение выходит за пределы запрошенного диапазона, что значительно повышает производительность.

Разделение

Возможность сегментирования Elasticsearch

Elasticsearch был построен поверх Lucene для горизонтального масштабирования и готовности к работе.

Масштабирование выполняется путем создания нескольких экземпляров (осколков) Lucene и их распределения по нескольким узлам (серверам) в кластере.

По умолчанию каждый документ направляется в соответствующий сегмент через его поле _id .

Во время извлечения главный узел отправляет каждому сегменту копию запроса, прежде чем окончательно агрегировать и ранжировать их для вывода.

Возможности разделения MongoDB

В кластере MongoDB есть три типа серверов: маршрутизатор, конфигурация и сегмент.

Масштабируя маршрутизатор, серверы могут принимать больше запросов, но основная работа выполняется на серверах сегментов.

Как и в случае с Elasticsearch, документы MongoDB направляются (по умолчанию) через _id в соответствующие сегменты. Во время запроса сервер конфигурации уведомляет маршрутизатор, который разбивает запрос, а затем сервер маршрутизатора распределяет запрос и собирает результаты.

Возможности разделения Redshift

Кластер Amazon Redshift состоит из одного ведущего узла и нескольких вычислительных узлов.

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

В отличие от серверов-маршрутизаторов MongoDB, ведущий узел непротиворечив и не может масштабироваться по горизонтали.

Хотя это создает узкое место, оно также позволяет эффективно кэшировать скомпилированные планы выполнения для популярных запросов.

Агрегирование

Агрегирующие возможности Elasticsearch

Документы в Elasticsearch можно группировать по точным, ранжированным или даже временным значениям и значениям геолокации.

Эти сегменты могут быть дополнительно сгруппированы с более высокой степенью детализации посредством вложенной агрегации.

Метрики, в том числе средние значения и стандартные отклонения, могут быть рассчитаны для каждого слоя, что обеспечивает возможность расчета иерархии анализов в рамках одного запроса.

Будучи хранилищем на основе документов, оно имеет ограничения на сравнение полей внутри документа.

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

В качестве альтернативы мы можем внедрять скрипты как пользовательские предикаты. Эта функция отлично подходит для одноразового анализа, но производительность страдает в производственной среде.

Агрегирующие возможности MongoDB

Конвейер агрегации является мощным и быстрым.

Как следует из названия, он работает с возвращаемыми данными поэтапно.

На каждом этапе можно фильтровать, объединять и преобразовывать документы, вводить новые показатели или раскручивать ранее объединенные группы.

Поскольку эти операции выполняются поэтапно, а документы и поля сводятся только к фильтрации, затраты памяти могут быть сведены к минимуму. По сравнению с Elasticsearch и даже с Redshift Aggregation Pipeline — чрезвычайно гибкий способ просмотра данных.

Несмотря на свою адаптивность, MongoDB страдает тем же недостатком сравнения полей внутри документа, что и Elasticsearch.

Кроме того, некоторые операции, в том числе $group , требуют передачи результатов на главный узел.

Таким образом, они не используют распределенные вычисления.

Те, кто не знаком с поэтапным расчетом конвейера, сочтут некоторые задачи неинтуитивными. Например, для суммирования количества элементов в поле массива потребуется два шага: сначала операция $unwind , а затем операция $group .

Агрегирующие возможности Redshift

Преимущества Amazon Redshift нельзя недооценивать.

Разочаровывающе медленное агрегирование в MongoDB при анализе мобильного трафика быстро решается Amazon Redshift.

Благодаря поддержке SQL традиционным инженерам баз данных будет легко перенести свои запросы в Redshift.

Помимо времени адаптации, SQL — это проверенный, масштабируемый и мощный язык запросов, который с легкостью поддерживает сравнение полей внутри документа/строки. Amazon Redshift дополнительно повышает производительность за счет компиляции и кэширования популярных запросов, выполняемых на вычислительных узлах.

Будучи реляционной базой данных, Amazon Redshift не обладает гибкостью схемы, которой обладают MongoDB и Elasticsearch. Оптимизированный для операций чтения, он страдает от снижения производительности во время обновлений и удалений.

Чтобы поддерживать наилучшее время чтения, строки должны быть отсортированы, добавляя дополнительные операционные усилия.

Разработанный для тех, у кого проблемы размером с петабайт, он недешев и, вероятно, не стоит вложений, если только нет проблем с масштабированием с другими базами данных.

Выбор победителя

В этой статье мы рассмотрели три разные технологии — Elasticsearch, MongoDB и Amazon Redshift — в контексте обработки данных. Однако явного победителя не существует, поскольку каждая из этих технологий лидирует в своей категории типов хранения.

Для обработки данных, в зависимости от варианта использования, одни варианты лучше других.

• MongoDB — фантастическая база данных для начинающих. Это обеспечивает гибкость, которую мы хотим, когда схема данных еще не определена. Тем не менее, MongoDB не превосходит конкретные варианты использования, на которых специализируются другие базы данных.
• Хотя Elasticsearch предлагает похожую на MongoDB гибкую схему, она оптимизирована для нескольких индексов и текстовых запросов за счет производительности записи и размера хранилища. Таким образом, нам следует подумать о переходе на Elasticsearch, когда мы обнаружим, что поддерживаем многочисленные индексы в MongoDB.
• Redshift требует предопределенной схемы данных, и ему не хватает адаптивности, которую обеспечивает MongoDB. В свою очередь, он превосходит другие базы данных для запросов, включающих только один (или несколько) столбцов. Когда позволяет бюджет, Amazon Redshift становится отличным секретным оружием, когда другие не могут справиться с объемом данных.