Объявлено (https://blog.blazingdb.com/blazingsql-is-now-open-source-b85...) об открытии исходных текстов SQL-движка BlazingSQL (https://rapids.ai/blazingsql.html), использующего GPU для ускорения обработки данных. BlazingSQL не является полноценной СУБД, а позиционируется как движок для анализа и обработки больших наборов данных, сравнимый по своим задачам с Apache Spark (https://spark.apache.org/). Код написан на языке Python и открыт (https://github.com/blazingdb/pyBlazing/) под лицензией Apache 2.0.
BlazingSQL подходит для выполнения единичных аналитических запросов над большими наборами данных (десятки гигабайт), хранимых в табличных форматах (например, логи, статистика NetFlow и т.п.). BlazingSQL может выполнять запросы из raw-файлов в форматах CSV и Apache Parquet, размещённых в сетевых и облачных ФС, подобных HDSF и AWS S3, напрямую передавая результат в память GPU. Благодаря распараллеливанию операций в GPU и использованию более быстрой видеопамяти, выполнение запросов в BlazingSQL осуществляется до 20 раз (https://blog.blazingdb.com/blazingsql-the-gpu-sql-engine-now...) быстрее, чем в Apache Spark.
Для работы с GPU применяется развиваемый при участии компании NVIDIA набор открытых (https://github.com/rapidsai/) библиотек RAPIDS (https://rapids.ai/), позволяющий создавать приложения для обработки данных и аналитики, выполняемые целиком на стороне GPU (предоставляется Python-интерфейс (https://rapidsai.github.io/projects/cudf/en/0.8.0/api.html) для использования низкоуровневых примитивов CUDA и распараллеливания вычислений).
BlazingSQL предоставляет возможность использования SQL вместо API обработки данных cuUDF (https://github.com/rapidsai/cudf) (на базе Apache Arrow (http://arrow.apache.org/)), применяемого в RAPIDS. BlazingSQL является дополнительной прослойкой, работающей поверх cuDF и использующей для чтения данных с диска библиотеку cuIO. SQL-запросы транслируются в вызовы функций cuUDF, позволяющие загружать данные в GPU и выполнять над ними операции слияния, агрегирования и фильтрации. Поддерживается создание распределённых конфигураций, охватывающих тысячи GPU.BlazingSQL существенно упрощает работу с данными - вместо сотни вызовов функций cuDF можно обойтись одним SQL-запросом. Применение SQL даёт возможность обеспечить интеграцию RAPIDS с существующими системами аналитики, без написания специфичных обработчиков и не прибегая к промежуточной загрузке данных в дополнительную СУБД, но
сохраняя при этом полную совместимость со всеми частями RAPIDS, транслируя в SQL имеющуюся функциональность и обеспечивая производительность на уровне cuDF. В том числе обеспечена поддержка интеграции с библиотеками XGBoost (https://xgboost.readthedocs.io/en/latest/) и cuML (https://github.com/rapidsai/cuml) для решения задач аналитики и машинного обучения.URL: https://blog.blazingdb.com/blazingsql-is-now-open-source-b85...
Новость: https://www.opennet.ru/opennews/art.shtml?num=51222
AMD как всегда остался на обочине достижений XXI века.
> AMD как всегда остался на обочине достижений XXI века.знаете, глядя на эти ваши "достижения", мы лучше еще немного на обочине постоим - подождем пока все достигатели улягутся на бочок в кювет.
> большими наборами данных (десятки гигабайт)Сейчас на дворе точно 2019-й, а не 2000-й?
Речь про БД, а не твою коллекцию порнухи.
Десятки гигабайт для СУБД -- это действительно не так много в наше время. В аналитические СУБД обычно загоняют много терабайт.
>В аналитические СУБД обычно загоняют много терабайт.По ссылкам не ходил, но полагаю, что SQL там убогий и это поделие никак задачи Орацле подхватить не смогёт.
А десятки терабайт сейчас обычно грузят в хламоэластики от хламо-IOT или просто журналы. Васянская бигдата без обработки и агрегирования, ценность данных меньше, чем у коллекции порнухи... :)
бигдейта начинается тогда, когда вы не можете ни за какие деньги купить сервер, в память которого вместятся данные, которые надо держать там для обработки. Поэтому сравнивать spark - решение для кластера - с blazingsql - решением для отдельной машины - некорректно. Разумеется Hadoop-based решения будут медленнее. Зато они прожуют такой объём данных, на котором обычные базы поперхнутся.
>бигдейта начинается тогда, когда вы не можете ни за какие деньги купить сервер, в память которого вместятся данныеВ какую из памятей/памятёв? :) Спарк это больше про ОЗУ, Хадуп больше про сторадж.
Например одиночный сервер спланк с полкой на 100 терабайт это ещё не бигдата по меркам анонимусов опеннета? :)))
Для питона - уже чересчур.
Она, похоже, не питон. Про питон, судя по всему, автор новости от себя добавил. На питоне только какая-то демонстрашка выложена. Впрочем, будут ли байндинги под что-то полезное, ещё большой вопрос...
Сотни гигабайт. Терабайты мб у гугла или у какого-то сбера, но на таких объёмах и своё можно запилить.
> на таких объёмах и своё можно запилить.Чтобы что-то пилить, нужно, чтобы программисты толковые были. Откуда они у Сбера? Если только речь не про Ignite.
Это перепись админов локалхоста, что ли?У гугла экзабайты, у сбера петабайты, десятки терабайт - даже у средне-мелких контор.
Размер БД менее 1 Тб сейчас - обычный hello word, не о чем говорить.
недотянул ты до админа локолхоста... увы...
>hello word
>word
Я спецом так написал из гуманных соображений, чтобы админам локалхоста было до чего докопаться.
коллекция-то тоже побогаче "десятков" нынче будет - что это за порнуха, не в 4k ?
Речь идет не о БД как таковой, а о
"данных (десятки гигабайт), хранимых в табличных форматах (например, логи, статистика NetFlow и т.п.). "Что сейчас с одной стороны- реально, а с другой- обычно в б_О_льших объемах и не существует.
Единичный лог на десяток гигов? Легко. Больше? Вы что ротацию логам не делаете вообще? Гнать вас в шею... Поэтому рассуждения про экзабайты баз данных (и про базы данных вообще) - они просто от невнимательного чтения и непонимания проблемы.
> "данных (десятки гигабайт), хранимых в табличных форматах (например, логи, статистика
> NetFlow и т.п.). "хм, а зачем вы логи храните в "табличных форматах"?!
> Что сейчас с одной стороны- реально, а с другой- обычно в б_О_льших
> объемах и не существует.Яровая и товарищмайор уже идут к вам! Несут расширятель хранимой емкости - очень почему-то похожий на бутылку, так что на всякий случай - запаситесь вазелином.
> Единичный лог на десяток гигов? Легко. Больше? Вы что ротацию логам не
> делаете вообще? Гнать вас в шею...делают (более того, единичный лог на десяток гигов - это вот как раз "гнать в шею"), но от этого старые логи, внезапно, не перестают быть нужны.
И эффективный поиск по ним - тоже.> Поэтому рассуждения про экзабайты баз данных (и про базы данных вообще) - они просто от
> невнимательного чтения и непонимания проблемы.ну авторов никто за язык на тему сравнения со spark не тянул, он вообще-то совсем не для netflow.
> хм, а зачем вы логи храните в "табличных форматах"?!Так это нынче модно
> Код написан на языке Python и открытКакая красота, что это не правда. Что и подтверждается ссылкой https://github.com/rapidsai
Впрочем, во времена быстрой аналитики странно, что вообще ещё кто-то мыслит о том, чтобы использовать питон....
>> Код написан на языке Python и открыт
> Какая красота, что это не правда. Что и подтверждается ссылкой https://github.com/rapidsaiРечь про BlazingSQL, а вы кидайте ссылку на Rapidsai. В новости следом расписано, что BlazingSQL лишь надстройка над RAPIDSai, который понятное дело не на Python.
https://github.com/BlazingDB - здесь написано, что они BlazingSQL. Тоже не питон
https://github.com/BlazingDB/pyBlazing
Питон же
> https://github.com/BlazingDB - здесь написано, что они BlazingSQL. Тоже не питонТам как раз везде написано, что Python. Первый же репозиторий "BlazingSQL is a lightweight, GPU accelerated, SQL engine built on RAPIDS. Python". Остальное левые надстройки или форки других проектов. С++ только для BlazingDB, а это совсем другой продукт.
Из Python они генерируют код для CUDA при помощи cuDF от RAPIDSai.
> Из Python они генерируют код для CUDA при помощи cuDF от RAPIDSai.Жуть какая.... Ретрограды и старпёры... В 21-м веке тащить питон в реальный проект.....
да, полная фигня - в 2k19 уже давно пора было делать на node.js
Если интерфейс под аналитику, то Julia или R
С тебя песок сыпется дядя - swift: https://www.tensorflow.org/swift
Для начала, разверни сервис на Свифте на каком-нибудь типовом сервере RHEL/CentOS...
я один не вижу вашего предложения по оплате?P.S. почасовой,разумеется
Пихтон, гигабайты датасета, raw хранение на сетевых дисках? Нет на них ClickHouse...
адепты яндекса должны гореть в аду
https://www.scylladb.com/