Big Data *

В данном примере мы разберем создание и выполнение типового задания MapReduce в облачной реализации Hadoop от Microsoft, которая носит название HDInsight.
В предыдущем примере мы создали 3-узловой кластер Hadoop и загрузили абстрактный журнал слабоструктурированного формата, который сейчас предстоит обработать. Журнал представляет собой в общем случае большой (в нашем конкретном примере маленький, но на принципиальную демонстрацию идеи это не влияет) текстовый файл, содержащий строки с признаками TRACE, DEBUG, INFO, WARN, ERROR, FATAL. Наша элементарная задача будет состоять в том, чтобы подсчитать количество строк с каждым признаком, т.е. сколько раз возникала ситуация WARN, сколько ERROR и т.д.

Хабражителям, интересующимся «большими данными», наверное, не имеет смысла рассказывать о проекте Apache Hadoop. В последнее время этот фреймворк стал особенным популярным и часто упоминаемым на Хабре – так, совсем недавно специалисты Mail.ru рассказали о миграции своей поисковой машины на Hadoop.
А как сделать хорошую программную систему еще лучше? Например, добавить в нее аппаратные компоненты. Именно таким путем пошла компания Intel, выпустив Intel Distribution for Apache Hadoop – «локализацию» Hadoop под платформу Intel Xeon, снабженную многими полезными функциями для облегчения ее управления и эксплуатации.

Интеллектуализация видеонаблюдения на транспорте – одно из самых перспективных направлений отрасли ввиду масштабного строительства общественной инфраструктуры. Так, только в Москве планируется переоснастить 188 существующие станции метро, построить 64 новые подземные станции, 31 наземную станцию на Малом кольце железной дороги и 5 линий скоростного трамвая с оплатной проезда на станции. Каждая подземная станция будет содержать не менее 50 камер, на которых будет работать ситуационная и биометрическая видеоаналитика, оптимизированная для мест массового скопления людей.



Важно, что внедрение технических средств интеллектуального видеонаблюдения является обязательным на уровне федерального закона о транспортной безопасности, распоряжений Правительства РФ об утверждении Комплексной программы обеспечения безопасности населения на транспорте и приказов Минтраса об утверждении требований по обеспечению транспортной безопасности категорированных объектов (подробнее о нормативной базе на транспорте).

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

В статье рассмотрены способы аппаратного построения высокопроизводительных вычислительных комплексов. Одно из интересных применений – криптография. Например, благодаря современным технологиям, любому стал доступен взлом MD5 или WPA. Если постараться (информацию быстро выпиливают), в Интернете можно найти способ взлома алгоритма A5/2, используемого в GSM. Другое применение – инженерные, финансовые, медицинские расчеты, биткойнмайнинг.

Недавно нам удалось пообщаться с великим Монти — Майклом Видениусом, автором оригинальной версии открытой СУБД MySQL, который в настоящее время работает над ее ответвлением, MariaDB. (Кстати, обе эти базы поддерживаются в Jelastic.)

Как известно, мир производит и обрабатывает все больше данных (так называемый феномен «Big Data»). Общепринято мнение, что данных теперь так много, что обрабатывать их с помощью традиционных баз данных и программных методов трудно или невозможно. Это вызвало волну нереляционных баз данных (NoSQL), в которых упор делается на высокую масштабируемость. Эксперт в области баз данных, Монти, поделился с нами своими мыслями о текущем и будущем состоянии SQL, NoSQL и Big Data. Некоторые его ответы были несколько неожиданными, так что мы с радостью приводим здесь русский перевод расшифровки нашей беседы:

В пятницу BitTorrent анонсировал старт публичной беты SoShare, сервиса, который переплюнет сервисы, подобные YouSendIt, DropBox и другим, разрешая передавать до 1TB. Компания позиционирует сервис для использования людьми креативных профессий — дизайнерам, фотографами, музыкантами и так далее — теми, кто работает с большими объёмами данных, но испытывает сложности с пересылкой их друг другу из-за ограничений почтовых служб и сервисов синхронизации и пересылки.

Данная серия посвящена анализу данных для поиска закономерностей. В качестве примера используется одна из обучающих задач сообщества спортивного анализа данных Kaggle. Хотя размеры данных для задачи не большие, методы обработки, которые будут рассматриваться вполне применимы для больших объемов данных.
После выполнения Часть 1 и Части 2 сформировались две таблицы, содержащие преобразованные данные.
titanik_test_3 и titanik_train_3.

Каждые полчаса появляется новая статья с кричащим лозунгом Большие данные — «новая нефть»!. Просто находка для маркетинговых текстов. Большие Данные = Большая Нефть = Профит. Откуда взялось данное утверждение? Давайте выйдем за рамки штампа и копнем чуть глубже:
Одним из первых его употребил Майкл Палмер[1] еще в 2006 году:

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

Такое понимание трендового «Большие данные — новая нефть!» ближе к реальности чем к маркетингу. И совсем не отменяет высказывания Дизраели:
«Существуют три вида лжи: Есть ложь, наглая ложь и статистика».
Данная статья является продолжением топика Data Mining: Первичная обработка данных при помощи СУБД. Часть 1
Продолжим добычу!

Объем данных, генерируемый и собираемый современными научно-исследовательским центрами, финансовыми институтами, социальными сетями, уже привычно измеряется петабайтами. Так в дата-центрах Facebook хранится уже более 15 млрд. изображений, нью-йоркская фондовая биржа NYSE создает и реплицирует ежедневно около 1 Тб данных, Большой адронный коллайдер получает около 1 Пб данных в секунду.

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

Платформа Hadoop, которая, в принципе, успешно решает проблему Big Data для полу- и неструктурированных данных, в своем «чистом» виде предъявляет значительные требования как к квалификации администраторов Hadoop-кластера, так и к первоначальным финансовым затратам на аппаратное обеспечение такого кластера.

В такой ситуации симбиоз облачных технологий и платформы Hadoop все чаще представляется как крайне перспективный способ решения проблемы «Больших данных», имеющий крайне невысокий уровень входа (квалификация + затраты на запуск).

О чем статья

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

С этой точки зрения, очень интересным будет ресурс Kaggle[1], который превращает исследование данных в спорт. Там проводят соревнования по анализу данных. Некоторые соревнования — с обучающими материалами и предназначены для начинающих. Вот именно обучению анализу данных, на примере решения одной из обучающих задач, и будет посвящён цикл статей. Первая статья будет о подготовке данных и использованию СУБД для этой цели. Собственно, о том, как и с чего начать. Предполагается что читатель понимает SQL.

Проектируете ли вы систему для анализа Big Data или просто пытаетесь собирать и обрабатывать данные своих мобильных приложений, вам никак не обойтись без качественных инструментов для аналитики. Хорошей новостью является то, что в данный момент множество компаний выпускают на рынок инструменты, учитывающие потребности разработчиков и соответствующие их навыкам.

Необходимость в анализе больших объемов информации быстро выходит за рамки исключительно коммерческого использования.
Big Data оказывает серьезное влияние на решения, принимаемые людьми, начиная с выборов президента и заканчивая покупкой чашечки кофе. Сфера анализа больших объемов информации стала настолько прибыльной, что инвесторы из штата Массачусетс торопятся найти очередную будущую многомиллиардную компанию, чтобы успеть инвестировать в нее сейчас.
На сегодняшний день коммерческое использование Big Data в основном существует в виде контекстной рекламы – стоит только вспомнить пророческий в этом плане сервис Google ads.

Технологии Big Data сегодня очень популярны, о чем говорит хотя бы то, что на текущий момент это наиболее часто встречающийся термин в IT-публикациях. Достаточно посмотреть на статистику таких известных поисковых систем, как Google или Yandex по словосочетанию «Big Data», и становится понятным, что так называемые «Большие Данные» действительно сейчас можно назвать одним из самых востребованных и интересных направлений развития информационных технологий.

Так в чем же секрет популярности этих технологий и что означает термин «Big Data»?

Если ты ИТшник, то нельзя просто так взять и выйти на работу 2-го января: пересмотреть 3-ий сезон битвы экстрасенсов или запись программы «Гордон» на НТВ (дело умственных способностей вкуса).
Нельзя потому, что у других сотрудников обязательно будут для тебя подарки: у секретарши закончился кофе, у МП — закончились дедлайны, а у администратора баз данных — амнезия память.
Оказалось, что инженеры из команды Hadoop тоже любят побаловать друг друга новогодними сюрпризами.

2008

2 января. Упуская подробное описание эмоционально-психологического состояния лиц, участвующих в описанных ниже событиях, сразу перейду к факту: поставлен таск MAPREDUCE-279 «Map-Reduce 2.0». Оставив шутки про число, обращу внимание, что до 1-ой стабильной версии Hadoop остается чуть менее 4 лет.

За это время проект Hadoop пройдет эволюцию из маленького инновационного снежка, запущенного в 2005, в большой снежный com ком, надвигающийся на ИТ, в 2012.
Ниже мы предпримем попытку разобраться, какое же значение январский таск MAPREDUCE-279 играл (и, уверен, еще сыграет в 2013) в эволюции платформы Hadoop.

Приветствуем, уважаемые Хабравчане. Последнее время на Хабре стало мелькать название компании Teradata в тех или иных вопросах. И, увидев возможный интерес, мы решили рассказать немного о том, что же такое СУБД Teradata, от первого лица. Мы планируем подготовить небольшую серию статей о самых интересных, на наш взгляд, технических особенностях СУБД и работы с ней. Если у вас есть опыт работы с Teradata или в вашей компании используется наша платформа и у вас есть вопросы – подкидывайте их, и мы либо ответим на них в комментариях, либо подготовим соответствующую полноценную статью. А начнем с небольшого обзора. Для знакомства, так сказать.

Обработка данных in-memory является довольно широко обсуждаемой темой в последнее время. Многие компании, которые в прошлом не стали бы рассматривать использование in-memory технологий из-за высокой стоимости, сейчас перестраивают архитектуру своих информационных систем, чтобы использовать преимущества быстрой транзакционной обработки данных, предлагаемых данными решениями. Это является следствием стремительного падения стоимости оперативной памяти (RAM), в результате чего становится возможным хранение всего набора операционных данных в памяти, увеличивая скорость их обработки более чем в 1000 раз. In-Memory Compute Grid и In-Memory Data Grid продукты предоставляют необходимые инструменты для построения таких решений.

Задача In-Memory Data Grid (IMDG) — обеспечить сверхвысокую доступность данных посредством хранения их в оперативной памяти в распределённом состоянии. Современные IMDG способны удовлетворить большинство требований к обработке больших массивов данных.

Упрощенно, IMDG — это распределённое хранилище объектов, схожее по интерфейсу с обычной многопоточной хэш-таблицей. Вы храните объекты по ключам. Но, в отличие от традиционных систем, в которых ключи и значения ограничены типами данных «массив байт» и «строка», в IMDG Вы можете использовать любой объект из Вашей бизнес-модели в качестве ключа или значения. Это значительно повышет гибкость, позволяя Вам хранить в Data Grid в точности тот объект, с которым работает Ваша бизнес-логика, без дополнительной сериализации/де-сериализации, которую требуют альтернативные технологии. Это также упрощает использование Вашего Data Grid-а, поскольку в большинстве случаев Вы можете работать с распределённым хранилищем данных как с обычной хэш-таблицей. Возможность работать с объектами из бизнес-модели напрямую — одно из основных отличий IMDG от In-Memory баз данных (IMDB). В последнем случае пользователи всё ещё вынуждены осуществлять объектно-реляционное отображение (Object-To-Relational Mapping), которое, как правило, приводит к значительному снижению производительности.

Вчера было мое выступление на HighLoad++. Тезисы и слайды на сайте организаторов. Конференция организована, кстати, отлично. Но времени на полноценное выступление было мало — 45 минут с вопросами. Тестовый прогон у меня занял 60 минут, после некоторой реорганизации и без вопросов на HL я уложился за 42. Некоторые важные архитектурные моменты пришлось проговаривать быстро и без примеров, от чего, конечно, страдала ясность. Я пытался построить презентацию таким образом, чтобы показать, как мы необходимым образом пришли к Вертике и к текущей архитектуре, и в то же время сделать акцент на важных архитектурных принципах работы с большими данными вообще. Не уверен, что цель была в полной мере достигнута. Мало, мало времени. Но я всегда открыт для вопросов. Вертика, впрочем, вызвала заслуженный интерес, вопросы были по делу.

А сегодня было выступление Криса Бонна из etsy.com, и, удивительное дело, он тоже рассказывал про Вертику.

NewSQL

Начало

Сегодня очень легко наблюдать стремительный рост данных в интернете. Согласно одной оценке, данные, созданные в 2010, составляют приблизительно 1,200 ЭБ (10¹⁸ байт) и вырастут почти к 8,000 ЭБ к 2015 в Интернете, являющимся основным поставщиком данных к потребителю.

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

Пока программисты всего мира устраивают глобальные Holywars на тему: «SQL vs NoSQL», крупные компании, такие как Google и Facebook со своей миллиардной аудиторией всеми силами борются с нехваткой мощностей и предельными работами СУБД. Несмотря на появление новой технологии NoSQL, которая позволяла легко масштабировать данные, она так и не решила вопросы связанные с соответствием операций требованиям ACID (atomicity, consistency, isolation, durability — «атомарность, непротиворечивость, изолированность, долговечность») — стандарта, который гарантирует точность выполнения оперативных транзакций средствами СУБД, даже если работа системы прерывалась. На фоне всего этого компания VoltDB при поддержке нескольких других компаний, начали разрабатывать с чистого листа новый opensource проект под название NewSQL, сочетающий в себе лучшие стороны SQL и NoSQL.

Кузьма Пашков рассказывает о железе ЕМС, о железе вообще, и о том, кто на самом деле принимает решение «какое железо поставить?» о том, что это вопрос религии.



Интервью с инструктором VMware Сергеем Даниленко. Разговор идет о тренде виртуализации, об ИТ-аутсорсинге и др.

---

МУК-Сервис — все виды ИТ ремонта: гарантийный, не гарантийный ремонт, продажа запасных частей, контрактное обслуживание

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

На тот момент у меня был ZX Spectrum (чьих 128 Kb явно не хватало на запуск чего-то похожего на ИИ) и много (думаю лет 10) свободного времени. Благодаря последнему факту, я благополучно дождался эры виртуализации. Можно было снять хоть 10K VPS, установить между ними канал связи и начинать создавать ИИ. Но мне хотелось заниматься программированием, а не администрированием/конфигурацией grid-системы, и я разумно начал ждать, когда вычислительные ресурсы начнут предоставляться как сервис.

Моей радости не было конца, когда появились облачные сервисы. Но радость длилась недолго: стало понятно, что пока прямые коммуникации между отдельными вычислительными инстансами – это фантастика код, который нужно писать самому (то есть с большой вероятностью он работать не будет). Попереживав пару лет по этому поводу, я (мы все) дождался Hadoop, сначала «on-premises», а потом и эластичного «on-demand». Но и там, как оказалось, не всё так эластично гладко