Category: Обработка данных

AI, data mining, information retrieval, etc

API к вашим генам

Пару дней назад 23andMe запустили API для разработчиков. На всякий случай напомню, 23andMe занимаются анализом ваших генов — присылают пробирку, вы плюете в нее, отправляете назад и получаете весь ваш генотип, с анализом предрасположенности к некоторым заболеваниям, свою историю и пр.

Я еще шутил, когда знакомый отправлял свою пробирку, что так просто гены не интересны, нужен свой github (genhub?) и вообще. Вот оно, случилось! Внешнее приложение может получить доступ к вашим генам и сделать какой-то свой анализ. (нет, менять ваши гены компьютер пока не может)

Я, конечно, не биолог, и может что-то не понимаю, но ведь это почти революция? Теперь куча мелких стартапов могут заняться анализом вашего генотипа, и простор для фантазии тут безграничен. От банальной рекомендации ресторана (да, на основе ваших генов) или знакомств, до интеграции с вашей больничной картой и точного подбора лекарств.

Какие у вас предложения? Кто там говорил что стартапы скатились к написанию еще одного приложения для фоточек? Вот вам доступ к тому что может изменить мир и вписать ваше имя в историю (и все это не выходя из дома). Пробуйте — https://api.23andme.com/

Data Company на смену Software Company

Тут Forbes пишет что индустрия меняется — софтверные компании уходят на второй план, на первый приходят компании работающие с данными. ПО стало другим, его продают совсем по другому.

Лидеры теперь это не те кто продают коробочку с программой, а те кто предлагают какие-то уникальные данные пользователю, уникальную информацию, возможность с ней работать. Вот например Google — он что предлагает? Поиск по данным. Или Facebook и все остальные социальные сети? «Социальный граф», информацию о твоих друзях, фотографии и пр.

... if you want to make a boatload of money in software, be prepared to spend decades getting big enough to catch the world’s attention. What the data also suggest, however, is that there are far better ways to make money than through software… Like data…. The Age of Software was fun. Welcome to the Age of Data.

Сильно меняется бизнес модель и процессы, появляются бизнесы совсем нового типа. Нужны и новые люди, тут явный тренд на профессионалов в этой сфере, инженеров, аналитиков, пр. Десятки публиций, как например в CIO, заявляют что:

Companies are becoming so data- and application-centric. They need individuals who can come to the table to model and mine in big data environments

Я уж не говорю о волне технологий вокруг, о NoSQL, Hadoop и пр.

Цифровой журнал Zite подстраивается под читателя

Нашел отличного конкурента для Flipboard — цифровой журнал Zite. Хотя сравнивать их не совсем корректно, они сильно отличаются. Но оба далеки от традиционных журналов.

Flipboard не особо подстраивается под читателя. Он, конечно, позволяет подключать свои Twitter, Facebook и RSS, но основной материал все же подобран роботами флипборда. А Zite это уже наверное следующий шаг. Здесь все наоборот, тут указываешь список тем/ключевых слов, и он подбирает свежие материалы по данному направлению. А дальше все это собирается из новостных сайтов, блогов и пр. При этом можно его тюнить, помечая какой материал понравился, какой нет.

Еще они сделали очень важный шаг: при первом входе спрашивают твой twitter или google reader, на основе которых они подготавливают первоначальный набор интересующих тебя тем. Ну и в процессе просмотра показывают рекомендации новых.

Как это все работает я не представляю, но получается очень круто. Вот такая вот клевая штука:

И еще о QWiki

Прислали приглашение на qwiki, про который я писал. Поигрался — забавная штука.

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

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

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

Swarm DPL

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

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

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

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

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

PwC о Semantic Web

Встретил хороший отчет 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 это совсем не серебряная пуля.

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

GridGain

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

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

Хранилище для обработки данных

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

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

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

Map Reduce

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