Новогоднее обещание :)

Не привычный пост :) Обычно пишу всякий рабочий треш, куча которого скопилась ещё и в draft'ах :) Но тут другое дело. Некоторый поток сознания приведший к этому можно почитать в buzz'е. Но если кратко. Часто видел/читал про американскую традицию давать в новый год всякие обещания на следующий, типа бросить курить или похудеть. Я решил, что надо поумнеть. Не знаю как у кого, но у меня знания очень трудно усваиваются после прочтения книжки, даже если делать задания в конце глав (а в некоторых таких заданий и нет). Вообщем было решено написать проектик, конечно же open source. Ничего нового и никаких startup'ов, просто проект, в котором можно было бы попробовать немного того, что прочитал или увидел в книгах, конференциях, статьях, подкастах и пр. Как всегда часто возникает вопрос, почему бы не присоединиться к существующему проекту. Всё просто, я хочу учить, попробовать много фишек, вообщем это не для проектов, которые ставят цель создать продукт, в конце я конечно надеюсь к декабрю 2010 получить продукт, но всё же основная цель поиграться, понабивать шишек, которые недоступны в hello world приложениях.

Больше двух с половиной лет, я каким то образом занимаюсь ETL и обработкой данных. И знаете, мне это нравиться. Вот и решил написать свою ETL :) Их тыщи, ещё одна не повредит. Ах да, и спасибо Андрею и Вите, вместе проработали много, делали PoC такой ETL на .NET.  Да и вся с кем я работа(л/ю). Получил бесценный опыт и большинство, что я тут напишу я знаю благодаря им. И конечно Ване, который меня познакомил со всеми этими отличными людьми.

Под катом, немного подробностей, если кому интересно.

И конечно же всех с наступившим Новым годом и успехов вам в ваших проектах!

И так, лишь общие идеи и хотелки :).

DataFlow

Центральным элементом любой ETL является Flow/Graph/Job/Task лучше всего это описывают первые два слова. Граф компонент обработки данных. В большинстве случаев на входе какой-нибудь читающий компонент, а на выходе писатель. Как всегда правильным видеться по сильнее отделять сами компоненты от Flow. В какой там очерёдности они выполняются, последовательно или каждый в своём потоке не должно их волновать. Вообщем видится что-то вроде чистой функции, на входе документ и на выходе уже изменнённый документ. Про документы потом, вообщем набор каких-то данных. Первая хотелка это Erlang. И как мне кажется он отлично подходит для разработки таких Flow, а в связи с его лёгкими процессами, каждый компонент можно в отдельный процесс заворачивать. Тут правда стоит следующий вопрос. Так как Erlang процессы не разделяют память, то каковы потери производительности при наличии большого количества компонент через которые проходят большие документы? ну что сказать, посмотрим :)

Теперь о самих компонентах. Следующая хотелка :) Erlang хорош не сам по себе, а благодаря OTP. А сам язык очень простой и писать на нём компоненты не очень приятно. Насмотревшись на CouchDB и Echo. Было решено использовать их идею и сами Flow это Erlang, а компоненты это какой-нибудь другой язык, тем более, что система портов Erlang смотриться пока не плохо. Ну и раз я упомянул эти два замечательных проекта, то языками компонент было решено сделать javascript и Ocaml. Благодаря Google V8, javascript неплох по производительности и к тому же обладает интересным синтаксисом и динамической типизацией. С другой стороны Ocaml отличный статически типизированный язык с кучей очень вкусной функциональщины, и очень хорош с точки зрения производительности. Кстати, язык компонент очень важен, например в нашем прошлом проекте мы почти все стандартные переписали на кастомные и много других кастомных было. Так что это очень важно, чтобы можно было легко написать дополнительные компоненты, а не циклы мышкой перетаскивать.

Мало какой ETL обходиться без промежуточной БД. Некоторые реализуют просто набор компонент, которые умеют читать и писать во все приличные СУБД, так как в любом случае полезно, данные для обработки ведь там и могут быть, другие идут своим путём и реализуют свою БД. Вот тут стоит испугаться, а не написать ли свою БД. Правильный ответ нет :) Когда я увидел CouchDB, я вспомнил нашу базу в MS Sql Server, у нас там тоже парочка ключей и здоровенный xml (в начале, потом немного байтовости добавили) документ. Так что идея навязать CouchDB в качестве промежуточного хранилища. Правда, насколько я читал всё отдаётся через http и json'ом, не шибко быстро походу будет (не то что shared memory в .net + sql server ;))), но apache лицензия это гуд и написана она на erlang, так что есть на чем подумать.

Очередная хотелочка это свой dsl. Flow же надо как-то описать, так что надо придумать клёвый dsl или найти такой для графов и приспособить. В своё время думал, не придумал ничёго клёвого. xml не предлагать, это вообще единственно предложение в этом текте, где будут упоминаться эти богомерзкие три буквы :)

WorkFlow Flow

Это прикольное сочетание я услышал от Игоря (к сожалению нет у меня ссылок на блог или соц сеть). Вообщем это уже не совсем относиться к ETL и в большинстве инструментов отсутствует. Но моя маленькая практика показала, что нужен что-то вроде Controller/Scheduler, котрый бы решал когда и что запустить. Конечно же эту штуку буду писать на Erlang, но тут много вопросов, как это сделать. Базовая идея это иметь набор каких-то триггеров, временных, появление файла или ещё какое изменение, которые бы запускали вот такой вот WorkFlow Flow, написанный на том же dsl возможно с какими-нибудь кастомными компонентами, и в конце концов это приводило бы к запуску одного или нескольких DataFlow.

Ах да, чем ещё мне нравиться Erlang, так это стабильность, то бишь концепцией процессов супервизоров. Так как, например на нашем текущем проекте, всегда все хотели, чтобы приложения по минимуму падало/останавливалось от некорректных данных. Т.о. если мы имеем такие супервизеры для процессов в которых запущенны компоненты, то даже исли процесс упадёт с какой-либо непонятной проблемой, супервизор сможет его перезапустить и он продолжит работу над другими документами.

TestFlow

На такие компоненты легко пишутся unit тесты. Но как показывает практика этого не достаточно. Нужны интеграционные тесты, которые прогонят весь Flow. Я тут подумал, что на самом деле, такой интеграционный тест ничем не отличается от unit теста, просто unit побольше. Ну и как другие *unit фреймворки этот наверно должен позволять описать тесты на том языке, который тестируется, т.е. в виде Flow dsl. Выглядит разумно и интересно.

MetaFlow

Это отклики моего прошлого проекта, но идея генерировать Flow из других Flow мне кажется очень клёвой! По сути Flow это текстовый файл, так что даже ничего специального для этого делать и не надо, но я думаю, как бы это упростить, например какой-нибудь удобный template framework именно для Flow dsl.

IDE

Каким бы удобным dsl не был, для него нужна хотя бы подсветка, а лучше key assistance, а что касается ETL то все ещё любят графическое представление. Вот тут будут банальности. Рассматриваю два варианта. Eclipse и Idea. да-да, ребята из JetBrains выдали свою Idea Platform в open source, но я пока не представляю насколько легко будет из неё собрать свой продукт. А вот с Eclipse у меня опыт есть и положительный, так что есть над чем подумать, но так как это хотелки, скорее всего выберу Idea :)

Environment

Да. Очень важный момент. Скажу спасибо ещё раз Андрею, потому что он постоянно вбивает в голову одну хорошую идею. Сделал checkout и сразу всё работает. Поэтому подумываю как бы это хорошо сделать. Всякие вспомогательные скрипты на python (а то мы ksh сейчас используем и это тихий ужОс). Удобный native инсталлятор. Это должно касаться как ETL инструмента, так и того что получается в итоге. Т.е. должен быть один инсталяционный пакет, который поставил, запустил ide сделал checkout проекта из системы контроля версий и у тебя всё работает, ну или создал новый проект. Потом когда всё сделал нажал кнопочку или запустил скрипт (для CI) и это всё собрало готовый со всем необходимым инсталятор твоего продукта.

Да, насчёт CI, тоже ещё думаю и склоняюсь к тому, чтобы написать плагин для TeamCity, чтобы запускать например набор Test Flow или прогонять продукт на реальных данных.

И что нас ещё будоражило, так это статистика и информация о текущем положении вещей. Мне нравиться подход CouchDB и так как именно её хочу использовать в качестве промежуточной базы данных, то думаю тоже написать небольшое web приложения с репортоми о проблемах, статистике и пр.

Да, ещё хотел как-то присобачить одно интересное приложение на Erlang - RabittMQ, очередь сообщений, но не придумал куда, может быть между WorkFlow Flow и DataFlow.

Пока всё, может ещё какие хотелки будут появляться с течение времени :)

Вы спросите и для чего столько буковок? Просто как письменное свидетельство данного обещания, чтобы, если как и другие идеи заброшу, стало очень очень стыдно.