The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Открыт код SQL-движка BlazingSQL, использующего GPU для ускорения

05.08.2019 21:43

Объявлено об открытии исходных текстов SQL-движка BlazingSQL, использующего GPU для ускорения обработки данных. BlazingSQL не является полноценной СУБД, а позиционируется как движок для анализа и обработки больших наборов данных, сравнимый по своим задачам с Apache Spark. Код написан на языке Python и открыт под лицензией Apache 2.0.

BlazingSQL подходит для выполнения единичных аналитических запросов над большими наборами данных (десятки гигабайт), хранимых в табличных форматах (например, логи, статистика NetFlow и т.п.). BlazingSQL может выполнять запросы из raw-файлов в форматах CSV и Apache Parquet, размещённых в сетевых и облачных ФС, подобных HDSF и AWS S3, напрямую передавая результат в память GPU. Благодаря распараллеливанию операций в GPU и использованию более быстрой видеопамяти выполнение запросов в BlazingSQL осуществляется до 20 раз быстрее, чем в Apache Spark.

Для работы с GPU применяется развиваемый при участии компании NVIDIA набор открытых библиотек RAPIDS, позволяющий создавать приложения для обработки данных и аналитики, выполняемые целиком на стороне GPU (предоставляется Python-интерфейс для использования низкоуровневых примитивов CUDA и распараллеливания вычислений).

BlazingSQL предоставляет возможность использования SQL вместо API обработки данных cuUDF (на базе Apache Arrow), применяемого в RAPIDS. BlazingSQL является дополнительной прослойкой, работающей поверх cuDF и использующей для чтения данных с диска библиотеку cuIO. SQL-запросы транслируются в вызовы функций cuUDF, позволяющие загружать данные в GPU и выполнять над ними операции слияния, агрегирования и фильтрации. Поддерживается создание распределённых конфигураций, охватывающих тысячи GPU.

BlazingSQL существенно упрощает работу с данными - вместо сотни вызовов функций cuDF можно обойтись одним SQL-запросом. Применение SQL даёт возможность обеспечить интеграцию RAPIDS с существующими системами аналитики, без написания специфичных обработчиков и не прибегая к промежуточной загрузке данных в дополнительную СУБД, но сохраняя при этом полную совместимость со всеми частями RAPIDS, транслируя в SQL имеющуюся функциональность и обеспечивая производительность на уровне cuDF. В том числе обеспечена поддержка интеграции с библиотеками XGBoost и cuML для решения задач аналитики и машинного обучения.

  1. Главная ссылка к новости (https://blog.blazingdb.com/bla...)
  2. OpenNews: Открыт код СУБД MapD Core, использующей GPU для хранения и обработки данных
  3. OpenNews: Для PostgreSQL развиваются механизмы ускорения за счёт привлечения GPU
  4. OpenNews: Открыт код VictoriaMetrics, СУБД для временных рядов, совместимой с Prometheus
  5. OpenNews: Выпуск распределённой СУБД TiDB 3.0
  6. OpenNews: Анонсирован Apache Spark 1.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/51222-sql
Ключевые слова: sql, gpu, blazingsql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (34) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 22:22, 05/08/2019 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +3 +/
     

  • 1.5, Аноним (5), 23:52, 05/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    > большими наборами данных (десятки гигабайт)

    Сейчас на дворе точно 2019-й, а не 2000-й?

     
     
  • 2.12, Аноним (12), 07:16, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • +14 +/
    Речь про БД, а не твою коллекцию порнухи.
     
     
  • 3.13, anonymous (??), 07:30, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Десятки гигабайт для СУБД -- это действительно не так много в наше время. В аналитические СУБД обычно загоняют много терабайт.
     
     
  • 4.17, лютый жабист__ (?), 08:56, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >В аналитические СУБД обычно загоняют много терабайт.

    По ссылкам не ходил, но полагаю, что SQL там убогий и это поделие никак задачи Орацле подхватить не смогёт.

    А десятки терабайт сейчас обычно грузят в хламоэластики от хламо-IOT или просто журналы. Васянская бигдата без обработки и агрегирования, ценность данных меньше, чем у коллекции порнухи... :)

     
     
  • 5.22, Аноним (22), 09:28, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    бигдейта начинается тогда, когда вы не можете ни за какие деньги купить сервер, в память которого вместятся данные, которые надо держать там для обработки. Поэтому сравнивать spark - решение для кластера - с blazingsql - решением для отдельной машины - некорректно. Разумеется Hadoop-based решения будут медленнее. Зато они прожуют такой объём данных, на котором обычные базы поперхнутся.
     
     
  • 6.45, лютый жабист__ (?), 07:32, 08/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >бигдейта начинается тогда, когда вы не можете ни за какие деньги купить сервер, в память которого вместятся данные

    В какую из памятей/памятёв? :) Спарк это больше про ОЗУ, Хадуп больше про сторадж.

    Например одиночный сервер спланк с полкой на 100 терабайт это ещё не бигдата по меркам анонимусов опеннета? :)))

     
  • 4.18, Онаним (?), 08:57, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Для питона - уже чересчур.
     
     
  • 5.21, Аноним (21), 09:28, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Она, похоже, не питон. Про питон, судя по всему, автор новости от себя добавил. На питоне только какая-то демонстрашка выложена. Впрочем, будут ли байндинги под что-то полезное, ещё большой вопрос...
     
  • 4.19, Аноним (19), 09:00, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Сотни гигабайт. Терабайты мб у гугла или у какого-то сбера, но на таких объёмах и своё можно запилить.
     
     
  • 5.24, Аноним (-), 09:44, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > на таких объёмах и своё можно запилить.

    Чтобы что-то пилить, нужно, чтобы программисты толковые были. Откуда они у Сбера? Если только речь не про Ignite.

     
  • 5.25, Аноним (5), 10:06, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Это перепись админов локалхоста, что ли?

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

    Размер БД менее 1 Тб сейчас - обычный hello word, не о чем говорить.

     
     
  • 6.37, ыы (?), 15:46, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    недотянул ты до админа локолхоста... увы...
     
  • 6.39, Аноним (39), 16:04, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >hello word
    >word
     
     
  • 7.41, Аноним (5), 18:38, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я спецом так написал из гуманных соображений, чтобы админам локалхоста было до чего докопаться.
     
  • 3.28, пох. (?), 10:41, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    коллекция-то тоже побогаче "десятков" нынче будет - что это за порнуха, не в 4k ?

     
  • 3.38, ыы (?), 15:53, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Речь идет не о БД как таковой, а о
    "данных (десятки гигабайт), хранимых в табличных форматах (например, логи, статистика NetFlow и т.п.). "

    Что сейчас с одной стороны- реально, а с другой- обычно в б_О_льших объемах и не существует.
    Единичный лог на десяток гигов? Легко. Больше? Вы что ротацию логам не делаете вообще? Гнать вас в шею... Поэтому рассуждения про экзабайты баз данных (и про базы данных вообще) - они просто от невнимательного чтения и непонимания проблемы.

     
     
  • 4.40, пох. (?), 17:45, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > "данных (десятки гигабайт), хранимых в табличных форматах (например, логи, статистика
    > NetFlow и т.п.). "

    хм, а зачем вы логи храните в "табличных форматах"?!

    > Что сейчас с одной стороны- реально, а с другой- обычно в б_О_льших
    > объемах и не существует.

    Яровая и товарищмайор уже идут к вам! Несут расширятель хранимой емкости - очень почему-то похожий на бутылку, так что на всякий случай - запаситесь вазелином.

    > Единичный лог на десяток гигов? Легко. Больше? Вы что ротацию логам не
    > делаете вообще? Гнать вас в шею...

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

    > Поэтому рассуждения про экзабайты баз данных (и про базы данных вообще) - они просто от
    > невнимательного чтения и непонимания проблемы.

    ну авторов никто за язык на тему сравнения со spark не тянул, он вообще-то совсем не для netflow.


     
     
  • 5.43, Аноним (43), 11:44, 07/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > хм, а зачем вы логи храните в "табличных форматах"?!

    Так это нынче модно

     

  • 1.15, Аноним (15), 08:34, 06/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Код написан на языке Python и открыт

    Какая красота, что это не правда. Что и подтверждается ссылкой https://github.com/rapidsai

    Впрочем, во времена быстрой аналитики странно, что вообще ещё кто-то мыслит о том, чтобы использовать питон....

     
     
  • 2.16, Аноним (16), 08:51, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Код написан на языке Python и открыт
    > Какая красота, что это не правда. Что и подтверждается ссылкой https://github.com/rapidsai

    Речь про BlazingSQL, а вы кидайте ссылку на Rapidsai. В новости следом расписано, что  BlazingSQL лишь надстройка над RAPIDSai, который понятное дело не на Python.

     
     
  • 3.20, Аноним (21), 09:15, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    https://github.com/BlazingDB - здесь написано, что они BlazingSQL. Тоже не питон
     
     
  • 4.26, nuzhny (?), 10:27, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    https://github.com/BlazingDB/pyBlazing
    Питон же
     
  • 4.27, Аноним (16), 10:28, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > https://github.com/BlazingDB - здесь написано, что они BlazingSQL. Тоже не питон

    Там как раз везде написано, что Python. Первый же репозиторий "BlazingSQL is a lightweight, GPU accelerated, SQL engine built on RAPIDS. Python". Остальное левые надстройки или форки других проектов. С++ только для BlazingDB, а это совсем другой продукт.
    Из Python они генерируют код для CUDA при помощи cuDF от RAPIDSai.

     
     
  • 5.29, Аноним (-), 10:52, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Из Python они генерируют код для CUDA при помощи cuDF от RAPIDSai.

    Жуть какая.... Ретрограды и старпёры... В 21-м веке тащить питон в реальный проект.....

     
     
  • 6.30, пох. (?), 11:01, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    да, полная фигня - в 2k19 уже давно пора было делать на node.js

     
     
  • 7.31, Аноним (-), 11:15, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если интерфейс под аналитику, то Julia или R
     
     
  • 8.33, nuzhny (?), 12:49, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    С тебя песок сыпется дядя - swift https www tensorflow org swift ... текст свёрнут, показать
     
     
  • 9.34, Аноним (-), 14:32, 06/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Для начала, разверни сервис на Свифте на каком-нибудь типовом сервере RHEL CentO... текст свёрнут, показать
     
     
  • 10.42, специалист (?), 10:41, 07/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    я один не вижу вашего предложения по оплате P S почасовой,разумеется ... текст свёрнут, показать
     

  • 1.35, Аноним (35), 14:57, 06/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Пихтон, гигабайты датасета, raw хранение на сетевых дисках? Нет на них ClickHouse...
     
     
  • 2.44, Аноним (43), 11:45, 07/08/2019 [^] [^^] [^^^] [ответить]  
  • +/
    адепты яндекса должны гореть в аду
     

  • 1.36, Аноним (35), 14:59, 06/08/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    https://www.scylladb.com/
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру