Комментарии 10
Можно подробнее о конечном результате? Судя по первым абзацам, у Баду есть своя СУБД, которая быстрее работает на ваших объемах. Интересно, удалось ли опередить тот же MemSQL, и пытались ли как-то еще решать задачу (писать MapReduce с нуля на C++, например)?
Я процитирую выводы статьи: "если вы делаете интерпретатор языка, похожего на SQL, то вам, вероятно, стоит просто взять любую из многочисленных доступных реляционных баз данных. "
Словом, в Бадуу много интересных проектов, но (Р)СУБД — не один из них :-) Все проще.
Данная конкретная система — статический индекс, который генерируется из Хадупа раз в день. В индексе хранятся пользовательские сессии (цепочки событий) в формате, который можно на лету распаковать и проанализировать. Искать интересные сессии для сбора статистики можно на языке вроде регулярных выражений.
Конкретно интерпретаторы SQL нам были интересны для ограниченного расширения возможностей языка. PigletQL — прототип, на котором я разбирал самый популярный вид интерпретаторов.
Но, кстати, для наших видов запросов и на наших объемах данных индекс даст MemSQL сто очков вперед как по компактности представления, так и скорости вычисления результатов. Специализация она такая.
Там в статье есть ссылка на статью про регулярки в движке, кстати.
Очень интересно! У меня сейчас есть подобная задача с сохранением всех пользовательских сессий и поиска паттернов, которые соответствуют фроду, поведению потенциальных вип клиентов, других интересных групп клиентов. Сейчас для меня самое непонятное — как из истории сессии (которая переменной длины) собрать нечто вроде вектора Х, который можно использовать для обучения классификатора (который из фиксированного набора фич). Много есть костыльных идей типа булевых фич на то, что было некое событие, использования текстовых классификаторов, но чего-либо красивого пока не видел. Может подскажете, куда копнуть?)
Я уже много лет не занимался именно машинным обучением, аж с 2012-2013 года, поэтому тут мои познания не слишком актуальны :-)
Если работать с векторами, то придется придумывать способ кодировать в них именно последовательности событий. Скажем, ячейка 0 будет показывать наличие 3-граммы из событий ABC, ячейка 1 — BCA и так далее. Длина такого вектора будет зависеть от количества типов событий и длины используемых n-грамм.
Это только один вариант, полет фантазий тут неограничен, пробовать и пробовать.
Ближайшая схожая задача, что приходит в голову — классификация музыки по жанрам при помощи нейронок… Но тут нужно данных побольше. В интернетах полно статей на эту тему.
А что вы уже запихивать в векторы пробовали?
Пока ML под это дело не подключал — только программировал эвристики. Но из того, что думал пробовать, — считать промежутки времени между конкретными парами событий, те же n-граммы, соотношения количества одних и других событий, ну и, отсекать первые n минут сессии (просто выкидывая сессии короче), и строить статистику только по ним.
Я бы на вашем месте все же попробовал следующее: взял n-граммы (скажем, четверки или даже длинней) последовательностей событий и сделал байесовский классификатор. Это не какое-то там мощное машинное обучение, но делается легко и быстро, даже безо всяких библиотек. Если будет хоть какая-то ощутимая предсказательная сила, то можно копать в эту сторону.
Эвристики в этих делах слабо помогают, я пробовал в свое время: довелось работать в небольшой азиатской поисковой компании, где мне поставили задачу классификации сайтов :-)
Но, опять же, задача звучит вот прям почти типовой, имеет смысл ознакомиться с коллективным опытом.
В принципе, могу спросить у наших специально обученных машинковедов, какие имеются подходы.
исходники я делал на draw.io, потом еще корпоративный дизайнер цвета, толщину линий и шрифт менял. Вот одна из исходных иллюстраций: https://github.com/vkazanov/sql-interpreters-post/blob/master/img/Compiling%20PigletQL%20Query%20Tree.png
Если вдруг есть заинтересовавшиеся в теме, рекомендую почитать про PostgreSQL:
- сначала документацию: планировщик/оптимизатор и исполнитель;
- затем README в коде;
- затем хорошо документированный код: например, один из самых простых узлов — LIMIT.
Автору спасибо за статью, было приятно почитать.
Вулканический поросенок, или SQL своими руками