SnappyData

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 00:19, 30 января 2019.
SnappyData
Snappy.png
Разработчик GemFire
Дата первого релиза 2016; 4 years ago (2016)
Последний релиз 2.х
Доступно в Английский
Лицензия 2009 - 2012 Stanford University
Официальный веб-сайт SnappyData

SnappyData (снэпидата) - это высокопроизводительная платформа хранения данных в памяти для приложений со смешанной рабочей нагрузкой. Построенная на Apache Spark, Snappy Data обеспечивает единую модель программирования для потоковой передачи, транзакций, машинного обучения и аналитики SQL в одном кластере. [Источник 1]

История создания

Рисунок 1 - Разработка SnappyData

SnappyData была инкубирована высококвалифицированной командой инженеров, уполномоченных создать революционную платформу OSS BigData (рисунок 1). Руководили командой первоначально основатели GemFire, которые первыми применили технологию сетки данных в памяти более десяти лет назад. Команда появилась в январе 2016 года как отдельная организация. [Источник 2]

Принцип работы

На схеме представлено упрощенное представление работы SDE (рисунок 2). SDE глубоко интегрирована с хранилищем данных Snappy и его обработчиком запросов SQL общего назначения. Входящие строки (могут поступать из статических или потоковых источников) непрерывно отбираются в одну или несколько таблиц "sample". Эти образцы можно рассматриваются как база, использующая индексы для оптимизации. При выполнении запросов пользователь может дополнительно указать допуск для ошибок с помощью простых расширений SQL. SDE прозрачно проходит процесс выборки, чтобы оценить, может ли запрос быть удовлетворен в ограничении ошибок. [1]

Рисунок 2 - Принцип работы SnappyData

Основные концепции

SDE Snappy Data использует два метода аппроксимации:

  • Стратифицированная выборка [2]

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

  • Эскиз

Хотя стратифицированная выборка обеспечивает захват данных с низким представлением, она по-прежнему плохо работает, когда требуется захватить большое количество данных. Вместо этого используются другие структуры данных, такие как Count-min-sketch для захвата частот данных в потоке. Это структура данных, которая требует, чтобы она фиксировала, как часто выводится элемент в потоке для элементов в начале списка. Хотя эскиз Count-min-sketch хорошо описан, SDE расширяет его с поддержкой предоставления оценок данных временных рядов.

Возможности аналитики

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

Другие варианты использования в этом пространстве включают тиковую аналитику, где данные из каналов реального времени передаются в SnappyData, а поток предоставляет аналитику для оконных потоков, которые затем возвращаются пользователю. Основная цель контроля рынка заключается в выявлении закономерностей, которые указывают на инсайдерскую торговлю и манипулирование рынком со стороны инсайдеров. Эти варианты использования требуют большего параллелизма, чем это предусмотрено традиционными системами аналитики.

Работа с данными

SnappyData объединяет низкую задержку, высокодоступную транзакционную базу данных в памяти в Spark с управлением общей памятью и несколькими оптимизациями, которые обеспечивают производительность и параллелизм для смешанных рабочих нагрузок. Данные в хранилище высокой доступности в памяти размещаются с использованием пользовательского столбчатого формата, немного похожего на макет, используемый кэшированием Spark. Операторы механизма запросов оптимизируются за счет лучшей векторизации и генерации кода. Конечным результатом этих изменений является повышение производительности на порядок по сравнению с собственным кэшированием Spark и повышение производительности Spark более чем на два порядка при работе с внешними источниками данных. [3]

Рисунок 3 - Работа с данными в SnappyData

Spark превращается в оперативную базу данных в памяти, способную выполнять транзакции, точечные операции: чтение, запись, работу с потоками и выполнение аналитических SQL-запросов. Слияние с Spark позволяет SnappyData работать с большим количеством источников данных, таких как HDFS, NoSQL и т.д. через индивидуальные коннекторы (рисунок 3). В то время как ядро SnappyData в основном предназначено для обработки SQL, приложения могут работать с объектами через Rdds Spark и API наборов данных Spark. По умолчанию при запуске кластера хранилище данных загружается, а при отправке любых запросов Spark Jobs/OLAP исполнители Spark автоматически запускаются в пространстве процессов SnappyData (JVM). Нет необходимости подключать кластеры внешних хранилищ данных и управлять ими.

Основные характеристики

Основные характеристики SnappyData [4]:

  • 100% совместимость с Spark - использование SnappyData в качестве базы данных
  • хранение строк и столбцов в памяти, расположенных в исполнителях Spark или в собственном пространстве процесса (вычислительном кластере и кластере данных)
  • стандарт соответствия SQL: функции и расширения SQL: триггеры DML, DDL, ограничения
  • расширения на основе SQL для потоковой обработки: использование собственной потоковой передачи Spark, API DataFrame обработка потоков
  • использование в качестве базы данных SQL, JSON или произвольных объектов приложения
  • SQL можно использовать для вставки, обновления и удаления данных в таблицах. Расширения контекста Spark предоставляются для изменения данных в программах Spark
  • начиная с версии 1.0 можно добавлять индексы в таблицы формата строк, а оптимизатор запросов автоматически использует индексы в памяти для повышения производительности
  • SnappyData реализует несколько оптимизаций, чтобы улучшить локальность данных и избежать перемещения данных для запросов к секционированным наборам данных. Все связанные данные могут быть размещены с помощью декларативных пользовательских стратегий секционирования.
  • данные можно мгновенно реплицировать (по одному или пакетно) на другие узлы кластера
  • таблицы могут настраиваться на сохранение на диск (по умолчанию) и восстанавливаться при запуске. Утилиты для резервного копирования, восстановления и импорта/экспорта предоставляются с системой
  • с помощью структур данных, таких как count-min-sketch и стратифицированной выборки, вводятся несколько методов синопсиса, чтобы значительно снизить требования к пространству в памяти и обеспечить истинные интерактивные скорости для аналитических запросов. Эти структуры могут создаваться и управляться разработчиками практически без статистической подготовки и полностью прозрачны для разработчиков SQL, выполняющих запросы

Сравнение SnappyData с Spark, Kudu, Alluxio & Cassandra

Сравнение приводится по следующим операциям: загрузка данных, выполнение аналитических запросов, выполнение поиска точек, выполнение обновлений/удалений. [Источник 3]

Загрузка данных

В режиме Snappy Data embedded производительность загрузки составляет приблизительно:

  • в 2 раза быстрее, чем Alluxio
  • в 8 раз быстрее, чем Kudu
  • в 60 раз быстрее, чем Cassandra

В режиме Smart Connector SnappyData производительность загрузки составляет приблизительно:

  • в 2 раза быстрее, чем Alluxio
  • в 8 раз быстрее, чем Kudu
  • в 60 раз быстрее, чем Cassandra

Выполнение аналитических запросов

В режиме Snappy Data embedded аналитические запросы приблизительно:

  • в 6-15 раз быстрее, чем Spark
  • в 3-6 раз быстрее, чем Alluxio

В режиме Smart Connector SnappyData аналитические запросы приблизительно:

  • в 3-6 раз быстрее, чем Spark
  • в 2-3 раза быстрее, чем Alluxio

Выполнение поиска точек

В режиме Snappy Data embedded поиск точек приблизительно:

  • в 30-60 раз быстрее, чем Spark
  • в 15-30 раз быстрее, чем Alluxio
  • в 10-30 раз быстрее, чем Kudu
  • в 3000-9000 раз быстрее, чем Cassandra

В режиме Smart Connector SnappyData поиск точек приблизительно:

  • в 2-3 раз быстрее, чем Spark
  • эквивалентен Alluxio

Выполнение обновлений/удалений

В режиме Snappy Data embedded аналитические запросы приблизительно:

  • в 6-11 раз быстрее, чем Kudu
  • в 300-400 раз быстрее, чем Cassandra

В режиме Smart Connector SnappyData аналитические запросы приблизительно:

  • в 6-8 раз быстрее, чем Kudu
  • в 250-300 раза быстрее, чем Cassandra

Примечания

Источники

  1. SnappyData // Официальный сайт SnappyData [2018–2018]. Дата обновления: 08.10.2018. URL: http://www.snappydata.io/ (дата обращения: 25.12.2018)
  2. SnappyDataCompany // Официальный сайт SnappyData [2018–2018]. Дата обновления: 08.10.2018. URL: https://www.snappydata.io/company (дата обращения: 25.12.2018)
  3. Сравнение с аналогами // SnappyData vs Spark, Kudu, Alluxio & Cassandra: a Performance Benchmark [2017–2017]. Дата обновления: 15.12.2017. URL: https://medium.com/@snappydata/snappydata-vs-spark-kudu-alluxio-cassandra-a-performance-benchmark-7df50cc2d2a7 (дата обращения: 25.12.2018)