Игорь Артамонов

Нашел интересный прототип фреймворка для распределенных вычислений: Swarm-DPL

Основная идея в том что код выполняется как можно ближе к данным, и даже больше, он постоянно мигрирует между разными машинами, старясь быть ближе к ним, без остановки основного вычислительного алгоритма. В общем это continuations с переносом состояния между нодами. Это в пику подходу map-reduce когда у нас именно данные гоняются между нодами. Код все таки меньше места занимает, должно быть быстрее, это не гигабайты данных по сети гонять.

Рекомендую посмотреть презентацию:

Swarm: Distributed Computation in the Cloud from Ian Clarke on Vimeo.

Реализовано на Scala, хотя думаю что никто не мешает реализовать идею на другом языке, и тем более уж под JVM. Автор, правда, утверждает обратное, но причина в том что в Scala все уже есть для этого, уже сейчас, и для прототипа как раз подходит. Ну и насколько я понимаю подобную оптимизацию можно реализовать в GridGain и сейчас, указав ноды для MR, но тут идея более интересная.

Встретил хороший отчет PriceWaterhouseCoopers по поводу Semantic Web, где идет речь о способах хранения и обработки корпоративных данных. Заинтересовало именно то что там идет речь не только о semantic web как таковом, но о внутреннем использовании этих технологий, для хранения и обработки данные.

Все о том что для сложноструктурированных данных классический подход (со всеми нормальными формами) не всегда работает. Т.е. иногда создать отдельную таблицу в БД под каждый тип сущности и установить связи просто не реально, ну например сколько их будет в случае большого магазина, например Озона? С десяток категорий с совершенно разными товарами, где общих полей мало, лишь поля цены, названия и пр. В общем в любом случае приходится придумывать что-то универсальное. Так вот, чтобы не изобретать свой велосипед, можно посмотреть в сторону технологий Semantic Web.

Что есть полезного:

• RDF – чрезвычайно простой и универсальный формат, а именно структурированеи в виде графа (и RDF это не XML)
• OWL – язык для структуризации, описания предметной области, в том числе вывода неявной информации, зависимостей, связей и пр.
• SPARQL – язык запросов к rdf данным

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

PS а отчет советую прочитать

Меня, если честно, всегда смущал тот факт что Oracle пихают во все задачи, куда только можно, бытует мнение что «БД это Оракл». Я лично не думаю что это прям такая «серебряная пуля». MySQL занимает те же позиции немного на другом фронте. Да, Oracle в частности, MySQL, и реляционные БД в общем, это отличный инструмент, но для случая когда у нас реально востребована эта реляционность.

Но ведь Оракл используют независимо от того нужна ли нам реляционность, просто по привычке, и потому что «все так делают«. Я за все свое время редко встречал нормализованные структуры, и даже больше, часто встречал таблицы БД с колонками вида col_1, col_2, col_N и пр. нарушениями всех форм, когда также разрезали таблицы на отдельные, в том числе отдельные инстансы БД. Встречал также когда в Oracle складывали черт знает что, когда использовали как хранилище лога операций, десятки гигабайт логов, ну и т.д. И никакого серьезного положительного эффекта от реляционных возможностей во всех этих случаях не было.

Не знаю может это мне так всегда везло и в других проекта все всегда «красиво», не нарушается ни одной из «нормальных форм» и пр, но у меня опыт вот такой.

Под реляционностью в данном случае я подразумеваю не только то что данных хранятся в виде таблице (с заранее четко оговоренным списком атрибутов). Я имею ввиду все что вертится вокруг этого: нормальные формы, внешние ключи, связи и ограничения, acid, собственно реляционная алгебра и все прочее предназначенное для облегчения хранения и соблюдения целостности структурированных данных.

В общем я не сторонник использования реляционной БД всегда и везде, на любой чих. Это хорошая технология, спасающая в огромном множестве случаев, но RDBMS это совсем не серебряная пуля.

Поэтому хотел бы обратить внимание на другой тип баз, на колоночные БД.
Читать далее »»

GridGain – платформа для реализации cloud вычислений. На мой взгляд очень серьезная платформа, вполне стабильная (если это имеет значение то версия, например, уже 2.1.0) имеет открытый код, на java, интегрируется с огромным количеством внешний систем. В отличие от пока академического Apache Hadoop здесь уже все более практично. А разобраться и запустить можно за пару часов, в отличии от…

Самый известный, наверное, подход к cloud вычислениям это mapreduce, и он прекрасно здесь организован. А так как этот mapreduce не всем понятен, да и не всегда нужен полностью, то здесь помимо него предлагается своя реализация java.lang.concurency.ExecutorService который разбрасывает переданные вычисления по кластеру.
Читать далее »»

Допустим у нас стоит задача: нужно собирать неструктурированные html данные и извлекать из них структуру, или, точнее, информацию, т.е. система Text Mining/Information Extraction.

Вcе элементы этого процесса, конечно, должны где то хранится. И если конечную информацию можно структурировать, завести с десяток таблиц в БД, настроить связи и складывать туда, то входная информация по определению у нас не структурирована, ну или, как минимум, слабо структурированная. Если делать сложную структуру то из-за специфики нашей задачи нам будет очень сложно отследить целостность данных. К слову о сложности работы с такой структурированностью замечу что я попытался было нарисовать это подход, но не смог сделать чтобы это было внятно, без всего лишнего.

Поэтому нужно придумывать какое то простое и универсальное решения для этой задачи. Одна из них это структура когда у нас для всего выделена одна таблица, в первые колонки которой заливается начальная структура. Далее они обрабатываются нашей программой для структурирования, и результат складывается рядом, в следующие колонки. Причем если результат мы получаем не за один шаг, что чаще и бывает, то в таком случае мы последовательно выполняем все шаги, складывая новые данные правее от текущих.
Читать далее »»

Подход mapreduce сейчас, с ростом объемов вычислений, стал очень популярен, но все упоминания какие то туманные, надо разложить все по полочкам. Начну с того что напомню о такой штуке как «закон Амдала». Он описывает ограничение роста производительности вычислительной системы с увеличением количества вычислителей, т.е. как мы можем ускорить вычисление увеличивая количество компьютеров в кластере. В общем то тут все интуитивно понятно. Читать далее »»

Расскажу немного о том зачем нужна очистка данных и CDI. Сейчас не буду углубляться в CDI, MDM, это потом, и будем считать что данные должны быть чистые, это вполне логично. Вопрос в другом, вот почистили мы наши клиентские базы, положили в некую CDI систему, а на что можно рассчитывать дальше? Т.е. как мы сможем их использовать, помимо того что теперь мы знаем что у нас не мусор в базе/CRM? Какие преимущества мы получим от очистки данных?

Ну, во-первых, благодаря стандартизации упрощается работа всех связанных систем, грязные данные тянули за собой слишком много костылей во внешних системах, что лишь увеличивало степень неопределенности. А вот после очистки данных уже можно найти тысячи положительных эффектов, все зависит от конкретной ситуации. От снижение количества искажений при анализе клиентской базы, до возможности проведения таких BI операций, о которых до этого и речи быть не могло за отсутствием нужных данных. В конце концов мы будем точно знать кто наши клиенты, а не предполагать основываясь на куче неверных данных.
Читать далее »»

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

Поэтому проведем экперимент, сравним алгоритм по умолчанию, и пару считающихся лучшими алгоритмов. Выберем, так сказать, the best of the best среди хэширования Конкретно для меня, это равная вероятность состояний отдельных бит, в 32х битном целом. Т.е. чем ближе вероятность появления «1″ в каждой из позиций к вероятности 1/2 тем лучше.
Читать далее »»

В 2004 году Google рассказал о модели обработки данных которую они использую. Основана она на том что данные обрабатывает пара простых функций Map и Reduce. Первая их которых выделяет множество пар Ключ/Значений из входящих данных (тоже являющихся парами Ключ/Значение), а вторая производит объединение/группировку этих пар, и, опять же, выдает наружу таки пары, чаще всего в меньшем количестве чем пришло на вход. Дополнительным элементом является распределенная файловая система GoogleFS, благодаря которой обрабатываемый файл, и вся промежуточная информация, становится легко доступной с любого компьютера в кластере.

Т.к. вся архитектура обработки состоит из небольших функций, то обработку можно легко распараллелить на кластере. К тому же облегчает разбивка на отдельные куски и восстановление после сбоя. Используя распределенную ФС мы разбиваем данные на небольшие кусочки, с каждым из которых и работает отдельный элемент кластера.

Так же эту идею можно встретить под названием Split/Aggregate. Т.е. суть в том что входные данные (неважно какого размера) разбиваются на отдельные элементы (этап split), к примеру построчно, каждая строка как отдельное значение для обработки. Эти блоки строк раcпределяются по кластеру для обработки, где для каждой строки вызывается функция обработки (map). Результат выполнения опять объединяется (reduce/aggregate) в выходной файл. Если нужно, то данные сохраняются отсортироваными в определенном порядке, к примеру по внешнему ключу.
Читать далее »»

Я практически ничего не писал о том, чем именно я сейчас занимаюсь, но это у меня часто спрашивают, и мало кому понятно, что такое «Очистка данных». Постараюсь это объяснить.
Очистка данных нужна, к примеру, организации, которая анкетирует своих покупателей на предмет того, что и где они покупали. Это может быть по почте, через сайт, еще как-то, источник не важен, но факт что данные могут придти различные.

В общем, расскажу на примере одной недавней задачки. Читать далее »»