Big Data *

За последние пол месяца произошло 3 ИТ-события, лежащие в плоскости Big Data, Cloud Computing и на их симбиозе. По странному стечению обстоятельств эти события остались без должного внимания как со стороны хабросообщества, так и со стороны немногочисленных профессиональных сетевых сообществ в LinkedIn и Facebook.

События, о которых идет речь — конференция «Strata + Hadoop World», релиз стабильной версии Hadoop 2.2.0 и облачного сервиса Windows Azure HDInsight. О косвенной и прямой взаимосвязи этих событий речь и пойдет ниже.

Вы слышали про Google Flu? С помощью анализа поисковых запросов, Google строит график динамики «заболеваемости» во времени. Мы решили проверить данные Google, сравнив их с количеством упоминаний различных простудных симптомов в соцмедиа в России: когда и где зафиксированы вспышки эпидемий, кто чаще всего болеет и на что жалуется? Ответы под катом.

Как и в прошлом году, выступил на HighLoad++. На этот раз мой доклад шел в секции «Базы данных», я рассказывал о том, какие системы хранения рационально использовать для задач многомерного анализа больших данных. Слайдов на сайте организаторов пока нет, как только появятся — я добавлю ссылку. Вкратце, презентация была построена так:

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

Вертика была представлена как один из вариантов, но про нее я рассказывал подробнее всего, показывая, как и за счет каких архитектурных решений она хорошо подходит под аналитические задачи и обгоняет всех конкурентов.

Исследования общественного мнения в соцмедиа имеют право на жизнь только в том случае, когда анализируются не только тексты сообщений, но и социально-демографические характеристики их авторов. Неправильно было бы учитывать высказывания петербуржцев при исследовании проблем жителей Чукотки, нельзя учитывать мнения пользователей старше 45 для получения инсайтов о молодежном продукте или мнения пользователей младше 18 лет для прогнозирования результатов выборов. Мы уже публиковали информацию о распределении активных авторов по регионам России, а сегодня поделимся нашими новыми данными: под катом – первые результаты исследования о возрасте активных авторов социальных медиа.

Как бы ни гремели скандалы про PRISM, про персональные данные и их утечки, социальные сети так и манят поведать о себе всё: какие котята нравятся, с кем ты дружишь и почему с утра такой не выспавшийся.
Целая энциклопедия о поведении большинства интернет-активной публики лежит совсем рядом, и мне всегда хотелось её пощупать. С одной стороны, эти данные лежат вроде бы в открытом доступе, но просто взять и проанализировать их не так легко — всё слишком неструктурировано и разрозненно. К тому же, насколько я знаю, пригодных для машинного анализа наборов данных о соцсетях практически не существует. А для России — так и подавно.
Выбора не оставалось, и пришлось, зловеще хохоча по ночам, писать простеньких пауков для соцсетей ВКонтакте, Одноклассники, МойМир и русского сегмента Фейсбук, которые за несколько месяцев неспешно собрали более или менее статистически-корректный семпл данных. Собиралась только та информация, которую люди сами о себе рассказали. А рассказали они много.

О том, что удалось выудить из таких данных, и пойдет рассказ.

Непрерывный рост данных и увеличение скорости их генерации порождают проблему их обработки и хранения. Неудивительно, что тема «больших данных» (Big Data) является одной из самых обсуждаемых в современном ИТ-сообществе.

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

Одним из самых известных и обсуждаемых проектов в области распределенных вычислений является Hadoop — разрабатываемый фондом Apache Software Foundation свободно распространяемый набор из утилит, библиотек и фреймворк для разработки и выполнения программ распределенных вычислений.

Мы уже давно используем Hadoop для решения собственных практических задач. Результаты нашей работы в этой области стоят того, чтобы рассказать о них широкой публике. Эта статья — первая в цикле о Hadoop. Сегодня мы расскажем об истории и структуре проекта Hadoop, а также покажем на примере дистрибутива Hadoop Cloudera, как осуществляется развертывание и настройка кластера.

Осторожно, под катом много трафика.

Запасаем впрок

Иногда в процессе работы бывают нужны данные из веб-сервисов, тем более SOAP соединения сегодня практически стандарт.

ETL-процесс (Extract — Transform — Load) это термин из Business Intelligence и описывает процесс сбора и трансформации данных для создания аналитической базы данных (например хранилища данных).

SOAP протокол обмена данных и веб-сервисы описываемые WSDL — распространенные окна в мир практически всех ERP систем, многих онлайн порталов и финансовых организаций.

Попробую описать пошагово ETL процесс с помощью одного из мощнейших инструментов в классе — MS Integration Services.

Итак, рассмотрим тестовую задачу.

Задача

Необходимо собрать данные о курсах валют по отношению к рублю на каждую дату прошлого года и загрузить их в таблицу для последующего анализа. Центробанк России предоставляет историчекие данные — в виде веб сервисов с неплохим описанием.
Похоже это и есть решение.

ЦОАСУ (англ. GOMA — Goal oriented management automation) — это “Принципы, модели и методологии для анализа, проектирования и интеграции целеориентированных социально-экономических автоматизированных систем управления”. Задача ЦОАСУ — достичь максимально возможного уровня автоматизации; в идеале — полностью заменить людей машинами. Используя принципы ЦОАСУ люди способны создать системы подобные Скайнет или Матрице.

Всё лучшее, зачастую, случается внезапно. Редко когда тщательно спланированная вечеринка может сравниться с внезапным визитом друзей, а блюдо, приготовленное точно по рецепту, с импровизацией мастера. В нашей команде этот феномен тоже имеет место быть: мы не задумывались о «рецептах», когда за пару недель реализовывали Media Monitor, который, как иногда случается в разработке нишевых B2B продуктов, оказался на удивление востребованным.

В продолжение статьи о dCache расскажу о некоторых деталях внутренней реализации.

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

В прошлой статье речь шла о том, как Big Data вообще и продукты LSI в частности позволяют предсказывать погоду, и почему это так важно. С момента выхода той статьи произошло одно интересное событие, подтверждающее важность затронутой темы. Всем известная компания Monsanto, мировой лидер биотехнологии растений приобрела компанию The Climate Corporation из Сан-Франциско за 930 миллионов долларов, последняя как раз занимается анализом «больших данных» связанных с погодой и климатом. По словам СЕО Monsanto: «Climate Corporation фокусируется на том, чтоб предоставить сельскому хозяйству больше возможностей за счет науки обработки данных». Но, разумеется, не одними только прогнозами состояния атмосферы полезны для нас «большие данные», давайте рассмотрим еще пару интересных применений.

Каждый год, в конце осени — начале зимы, мы все с определенной покорностью ожидаем начала неизбежной эпидемии гриппа. Несмотря на относительную «безопасность» этой болезни, часто она способна дать огромные осложнения, а ежегодное число жертв по всему миру по данным ВОЗ составляет от 250 до 500 тысяч человек.

В последнее время было большое количество постов о ЦЕРНе и Большом Адронном Kоллайдере (БАК или LHC). Но не многие знают, что БАК производит ~20 ПБ данных в год. Порядка 50% всех данных хранится в dCache.

dCache является распределённой системой хранения данных, способной работать на обычном железе, с возможностью расширения посредсвом добавления новых узлов. Всё, что нужно для работы на узле, — это JVM (так как всё написано на джаве) и файловая система, где, собственно, и хранятся данные. Типичные инсталляции используют Linux(RHEL/SL/CentOS 6) или Solaris с XFS или ZFS, соответсвенно. В связи с натурой экспериментальных данных dCache не предусматривает изменение хранимых файлов.

dCache разрабатывается с 2000 года и с 2002 года используеться в более чем 80 научных центрах мира, включая Россию. Самые маленькие системы состоят из одного узла в несколько ТБ, самые большие состоят из ~500 узлов с суммарным дисковым пространством в 22 ПБ.

MarkLogic является сервером приложений и любая программа написанная на XQuery для него может получить доступ не только к объектам хранящимся в самой базе данных, но и к файлам находящимся непосредственно на файловой системе.
API предоставляющий доступ к файловой системе в MarkLogic Server не так уж и богат, но имеющихся средств вполне достаточно чтобы зачитывать данные с файловой системы напрямую из XQuery кода и выполнять сохранения файлов на неё.

Еще немного о том как MarkLogic Server хранит данные.

Привет коллеги.
Хочу поделиться своим опытом использования HBase, а именно рассказать про bulk loading. Это еще один метод загрузки данных. Он принципиально отличается от обычного подхода (записи в таблицу через клиента). Есть мнение, что с помощью bulk load можно очень быстро загружать огромные массивы данных. Именно в этом я решил разобраться.

Рассматривая разные технологии хранения данных и решения, предлагаемые компанией LSI, мы немного подзабыли о практически-прикладном смысле этого всего. Зачем нужны все возрастающие скорости и емкости дисков? Одно из первых, приходящих в голову применений — это, конечно, Big Data или Большие данные. Чем же эти Большие данные отличаются от просто больших, чтоб заслужить написание с большой буквы? Обычно это называют «правило трех V».

MarkLogic Server – это документо-ориентированная native XML база данных. Как и в любой документо-ориентированной DB в MarkLogic Server данные можно представить как файлово-фолдерную структуру. Кстати, при доступе к хранилищу через WebDAV данные именно так и представляются. Помимо собственно XML в MarkLogic Server можно хранить и любые бинарные данные в виде файлов.

Внутренне представление XML данных в MarkLogic Server довольно сложное и будет рассмотрено позже. Сейчас же стоит сказать о том, что поместить в MarkLogic Server можно только well formed XML так как хранится он не в виде простого текста, а как объект данных типа XML. Кодировкой внутреннего представления XML данных является Unicode, что избавляет от множества проблем с разными языками. Все Entity в XML данных разворачиваются в цифровые еntity. Если в документе используются только они, то это не доставит никаких проблем, в противном случае MarkLogic Server должен «знать» о всех используемых entity.

Всем привет!

Давно хотел написать статью. Я сам мало люблю длинные тексты с небольшим количеством полезной информации, поэтому постараюсь сделать этот максимально насыщенным.

Обобщенная тема – эффективная упаковка данных, сериализация и десериализация объектов.
Основная цель – поделиться своими размышлениями по этому поводу и обсудить структуру данных DSV.

Проблема:
Известные мне на текущий момент (2013-09-19 18:09:56) механизмы бинарной сериализации обладают недостаточной гибкостью или избыточность занимаемого пространства. Например:
QString s1(“123”); -> 4 байта размера данных = 0x00000003, 3 байта полезных данных = “123”, эффективность = 3/7;
U32 val1(123); -> 4 байта данных (0x0000007B), 1 байт из которых является значимым = 123 (0x7B), эффективность = 1/4.

Меня спросили: «Сколько у вас опыта с большими данными и Hadoop?» Я ответил, что часто использую Hadoop, но редко — с объёмами данных больше нескольких ТБ. Я новичок в больших данных — понимаю идеи, писал код, но не в серьёзных масштабах.

Следующий вопрос был: «Можете ли вы сделать простую группировку и сумму в Hadoop?» Разумеется, могу, и я попросил пример формата данных.

Они вручили мне флэш-диск со всеми 600 МБ данных (да, это были именно все данные, а не выборка). Не понимаю, почему, но им не понравилось моё решение, в котором был pandas.read_csv и не было Hadoop.

— Мы получаем больше миллиона твитов в день, и наш сервер просто не успевает их обрабатывать. Поэтому мы хотим установить на кластер Hadoop и распределить обработку.

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

— А что вы собираетесь делать с уже обработанными данными?
— Скорее всего, мы будем складывать их в MySQL, как делали это раньше, или даже удалять.
— Тогда вам определённо не нужен Hadoop.

Мой бывший коллега был далеко не первым, кто говорил про распределённые вычисления на Hadoop. И каждый раз я видел полное непонимание того, зачем была придумана и разработана эта платформа.