Оцените новый подход к обработке данных — альтернатива map-reduce, SQL, pandas
Ранее я реализовал веб-приложение на этих принципах с обсуждением и ценными советами здесь dou.ua/forums/topic/20203
После этого я реализовал этот же подход но только как библиотеку, которая может встраиваться в другие приложения, где нужна потенциально сложная обработка данных, например, для миграции данных, импорта-экспорта, генерация отчетов, СУБД, анализ потоков и др. Система здесь:
Bistro: github.com/asavinov/bistro
Суть идеи в том, что обработка данных описывается через операции с колонками (а не с таблицами), и соответственно выполняется путем вычисления этих колонок (через данных в другие колонки). В отличие от этого, традиционные подходы используют операции с множествами для обработки данных, например, join, map, reduce, group-by.
В простейшем случае (операция calc) новую колонку можно определить как операции с другими, например, c = a+b (колонка c будет равна сумме a и b).
Есть еще две основные операции: link это для связи таблиц аналог join, и accu это для агрегирования данных аналог group-by или reduce.
В целом, определение новых данных могло бы выглядеть так:
// Определить колонки col1.calc(lambda_f1,...); col2.link(lambda_f2,...); col3.accu(lambda_f3,...); colN.calc(lambda_fN,...); // Вычислить все колонки schema.eval(); // Использовать результат Object val1 = col1.getValue(0);
Будет ли это вообще работать на практике? Кому и где это могло быть наиболее полезно сейчас и в будущем? Для каких приложений или задач может быть актуально? Что можно улучшить в данной реализации?
Заранее спасибо.
11 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівКак по мне, бесполезно практически полностью. Хранение по-прежнему выполняется атомарно.
Я так понимаю, что вся суть этой фенечки — декларативное описание данных. Старая добрая идея SQL, которая из всей своей простоты переросла в пятитомный справочник с привязкой к конкретной базе данных.
Если цель хранить данные — существующие способы достаточно неплохи, вплоть до файловой системы которая тоже по сути база данных. Если цель доставать данные — кто имеет к ним физический доступ, тот и заказывает музыку.
Очень неплоха OLAP-модель, которая просто таки прекрасно дружит с поставщиками данных, и которая по сути и есть то что ты хочешь — декларативно заданный обработчик. А все зачачи что после этого остаются — по сути могут быть решены профессионалом обработки данных. Ты же хочешь сделать таким, чтобы любой дурак воспользоваться мог. Один из законов Мэрфи утверждает, что только дурак и захочет этим пользоваться.
Потоковый анализ — идея хорошая. Но ровно до тех пор, пока не будет построена модель самого потока, которая будет понятна человеку. Далее лишь вопрос физической структуры мета-информации о потоках, и на этом вопрос исчерпан, поток получает интерфейс для прямой агрегации.
В общем, как ни крути, а по затратам не выиграешь. Почему? Да потому что ты вторгаешься в область прикладных задач, которым на роду написано часто меняться — в связи с несогласованностью модели и реальных сущностей. Забодаешься натягивать сову на глобус при помощи написания кода, для этого нужны GUI-инструменты. И да, тем у кого есть потребность — гораздо проще заплатить деньги и купить инструмент, чем пользоваться программной моделью.
В чому різниця з pandas? Він якраз зі стовпчиками працює напряму.
В pandas только колнки одной таблицы можно так определить с помощью df.apply(lamda_fn). Это действительно очень удобно, и по сути совпадает с Bistro. Но это не поддерживает работу с несколькими таблицами — для этого используется join. И также pandas использует для агрегации group-by.
В Bistro нет join. Вместо генерации новой таблицы используется линкование (операция link), т.е. колонка таблицы может ссылаться на записи другой — и это делается с помощью пользовательской функции.
В Bistro нет group-by. Данные не надо группировать явно. Агрегирование (операция accu) выполняется также с помощью пользовательской функции, но она устроена по-другому. Она вызывается для каждого значения группы и обновляет текущий агрегат (потому называется функция аккумуляции).
Ок, зробіть тест на час pandas vs Bistro для операції, наприклад, добуток матриць dot.
да кто ж матрицы в БД засовывает?
надо что-то другое тестить. какие-то цены в интернет-магазинах, или список авиа рейсов, или базу украденных аккоунтов с паролями
Так це і є матриці :)
Не совсем понятно, в чем «новый подход»
Column Store довольно старый подход, который сейчас уже существует у mysql, у оракла, у большинства активных игроков.
Более новый (ну как новый, с2010-х) — in Memory data management (blogs.sap.com/...se-an-in-memory-database).
Все идет к тому, что с удешевлением памяти, скорости дисков, других ресурсов,
наступает момент, когда от классических агрегатов можно будет отказаться, так как мы в любой момент за приемлемое время
сможем получить актуальную информацию .
Это относится к физической модели, т.е. как реализован уровень хранения данных. В большинстве column store все запросы по-прежнему пишутся на SQL-подбном языке (который потом может транслироваться в колончатые операции, но этого никто не видит), т.е. на логическом уровне это самая обычная реляционная СУБД (за некоторыми исключениями и фичами).
В Bistro речь идет о логической модели, т.е., как данные видны пользователю. И видятся они как набор колонок, которые можно определять и преобразовывать.
Это уже другой вопрос. Они говорят, что агрегаты не надо хранить (постоянно), а можно по необходимости считать на лету. Но ведь все равно, чтобы подсчитать, надо определить что считать, т.е. указать запрос (а сохранять или следующий раз пересчитывать, это уже другой вопрос). Так что вопрос в том, как описывать агрегацию данных. Обычный подход это group-by или reduce. Суть их в том, что функция агрегации получает подмножество, а возвращает одно значение. Например, функция SUM может получить {1,3,5}, будет вызвана один раз и вернет 9.
Bistro использует другой подход. Здесь эта функция получает одно (следующее) значение группы, и обновляет текущий агрегат. Например, для суммирования такая функция будет вызвана 3 раза (для каждого значения из {1,3,5}, и вернет {1,4,9}. Последнее значение будет результат.
Да тот же самый. Джойны вы «заменили» какими-то линками, аггрегаты... хммм... такими же аггрегатами (вид сбоку). Не очень понятно, а какая собственно проблема этим решается?
Join — операция на множествах. Link — операция на функциях. Это одно и то же?
Агрегирование — функция применяется к множеству. Аккумулирование — функция применяется к одном элементу. Это одно и то же?
Почему пользователи Excel не используют SQL? Ведь SQL такой крутой. Прикрутил его и далее пиши себе любимые join и group-by. Да бог с ними с эксельщиками. Попросите спецов написать пару запросов к 3 таблицами и половина из них наделает ошибок. Случайно? А теперь еще добавить туда агрегацию. А потом еще вычисления с аналитикой. А в конце заменить их на другую команду и попросить их что-то подкрутить. Будет интересно посмотреть на результат. Это с точки зрения практики. С точки зрения теории тоже есть серьезные вопросы, но это не для здесь.
Если коротко, то проблема — сложность (а значит время, ошибки, деньги). Цель — упрощение. Чтобы нормальный здоровый человек мог написать что-то сложное, быстро, без ошибок, и его сменщик мог быть потом без ошибок это изменить.
Ну хорошо, Bistro и этот подход не нужен. А какие тогда проблемы интересуют заказчиков? Что бы они хотели поменять или упростить или удешевить? Где лежать принципиальные проблемы? Куда смотреть? Чего бы вы хотели увидеть хотя бы примерно?
Операции над функциями, говорите? Ваша документация (github.com/...vinov/bistro#link-columns) с вами не согласна: «...their [Links — K.S.] output essentially is a reference to some element in the output table». Вот прямо очень не согласна: «Therefore, we define a new link column which will directly reference elements from «THINGS». Не вижу «операций над функциями», вижу явное подобие ключа...
А аггрегируете вы что? Обратимся к документации: «Table with the data being aggregated, called fact table (type of the link column)». Не, ну можно конечно зажмуриться крепко-крепко, и не заметить тут реляционной модели (вид сбоку). «Жопа есть, а слова нет», как грицца...
Потому же, почему не используют 90% остальных его продвинутых инструментов (включая большинство имеющихся формул), потому же, почему в 2018 году эксель до сих пор из коробки не умеет в регулярки (или умеет уже?) и т.п. — потому что все это не нужно подавляющему большинству его среднестатистических пользователей. Для серьезной аналитики используются другие инструменты (хотя имхо — эксель очень неплох как olap-клиент), а остальным юзерам он нужен максимум чтобы бюджетик сверстать или тому подобный полу-игрушечный буллшит на пятьдесят строк максимум с десятком тривиальных формул... А некоторые и формулами не заморачиваются, предпочитая обезьянью ручную работу (потому что учиться лень — при всем многообразии учебных материалов на любой вкус и уровень). Не, ну есть конечно пользователи и попродвинутее. Те и сиквел бывают пользуют чтобы в эксель данные из какого-то источника дернуть, и скрипты наворачивают трехэтажные... Сколько их? Полпроцента?
Стоит пересмотреть систему рекрутинга, если у вас половина спецов не в состоянии собрать в кучу данные из трех таблиц. Проблема высосана из пальца ящитаю — любой инструмент, если не изучать, будет бить по пальцам, а не куда положено — но это не проблема инструмента...