Big Data *

Исследования общественного мнения в соцмедиа имеют право на жизнь только в том случае, когда анализируются не только тексты сообщений, но и социально-демографические характеристики их авторов. Неправильно было бы учитывать высказывания петербуржцев при исследовании проблем жителей Чукотки, нельзя учитывать мнения пользователей старше 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. И каждый раз я видел полное непонимание того, зачем была придумана и разработана эта платформа.

Вчера я первый раз написал статью на хабр, не зная местных тонкостей.

Исправляюсь! Теперь понятным языком и с юмором!

Чёрная пятница оказалась воистину чёрной для aмериканского интернет-универмага Kohl's. Все сервера накрылись медным тазом именно в день рождественских распродаж. Привычные 20% годового дохода, добываемые в этот день, обернулись смешным пустяком, а все потому что Боливар не вынес такой нагрузки.

Традиционная архитектура Tomcat + WebLogic + БД облажалась по полной программе! Напрасно бегали по этажам сисадмины, суетились в панике ведущие программисты, а архитекторы выдирали остатки волос… Горлышко бутылки оказалось слишком узким для того, чтобы в него могли протиснуться все потенциальные клиенты и недостаточно эластичным, чтобы за короткое время его можно было успеть расширить. Бутылку разорвало нахрен. И долго еще кровоточили раны, нанесённые ее осколками…

Эдварда Сноудена не существует и о нем говорят только в России. «Сноуден — предатель, враг и изменник», — считают жители США. «Сноуден — международный герой и пример для подражания», — говорят… ну где-то наверняка говорят, думали мы. Когда мы приступали к работе над новой задачей, нам казалось, что тема Эдварда Сноудена заинтриговала весь мир. Поэтому задача, поставленная нашими партнерами из фонда «Vox Populi», специализирующегося на исследованиях общественного мнения в социальных медиа, казалась нам довольно простой: оценить интерес населения к ситуации по Сноудену в мире, и в России и США в частности. Но мониторинг соцмедиа для социологических исследований — сущность новая, а потому вдвойне интересная: во-первых, никогда не знаешь, какой именно результат получишь; во-вторых, восхищаешься возможностями социовселенной, созданной человечеством. Результат и в этот раз получился несколько бОльшим и довольно неожиданным: мы проанализировали многоязычный поток сообщений из 230 (!) стран мира. О том, как мы разделяли по языкам и геолоцировали это царство Вавилонское — под катом.