Big Data *

В свете текущих выходных, важно не забывать, что алкоголь и общение, вместе составляют не всегда хорошую комбинацию, даже у звезд. Тем не менее, многие из нас повторяют этот опыт снова и снова. И этот опыт дал американским ученым (Nabil Hossain с приятелями из University of Rochester) интересную идею. В итоге, американские ученые разработали нейронную сеть, способную распознавать в Twitter посты написанные в состоянии алкогольного опьянения. Кроме того, полученная математическая модель может определять, где авторы «пьяных» постов находились в момент их написания.
Об этом сообщает MIT Technology Review.

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

У нас вполне стандартный процесс работы с данными. Исходные данные в максимально сыром виде регулярно подгружаются в единое хранилище, в нашем случае в BigQuery. Из одних источников (наш собственный продакшн) данные приходят каждый час, из других (обычно сторонние источники) данные идут ежедневно.

В последствии данные обрабатываются до состояния пригодного к употреблению разнообразными пользователями. Это могут быть внутренние дашборды; отчёты партнёрам; результаты, которые идут в продакшн и влияют на поведение продукта. Эти операции могут быть довольно сложными и включать несколько источников данных. Но по большей части мы с этим справляется внутри BigQuery с помощью SQL+UDF. Результаты сохраняются в отдельные таблицы там же.

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

• изменение котировок
• действия пользователей в онлайн-игре
• отображала агрегированную информацию из соцсетей в различных проекциях

и т.д. Если вы так не умеете, то смузи уже не нальют.

Сфера деятельности нашей компании распространяется далеко за пределы игровой разработки. Параллельно с ней мы ведем десятки внутренних проектов, и Data Driven Realtime Rule Engine (DDRRE) – один из наиболее амбициозных.

Data Driven Realtime Rule Engine – специальная система, которая при помощи анализа больших массивов данных в режиме реального времени позволяет персонифицировать взаимодействие с игроком через рекомендации, поступающие пользователю исходя из контекста его последнего игрового опыта.

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

Архитектура DDRRE

17 октября прошла ежегодная брутальная конференция Highload Dev Conf.
Участниками стали более 300 суровых разработчиков, которым интересны высоконагруженные проекты и BigData.

Задача № 1 для ритейлера — понять, кто конкретно совершает покупки в магазине, изучить поведение покупателей, выделить типичные модели, и с помощью этих знаний влиять на количество и качество покупок.

Решение возможно, используя такие подходы:

• анализ данных из программ лояльности и другие формы изучения персон и поведения покупателей;
• анализ данных о покупках и транзакциях.

Перефразируя второй подход — какие товары покупатель положил в свою корзину?

В нашей компании мы регулярно пробуем и анализируем новые интересные технологии в области хранения и управления большими данными. В апреле с нами связались представители компании Snowflake Computing и предложили попробовать их продукт Snowflake Elastic Data Warehouse — облачное хранилище данных. Они работают над созданием эластичной системы, которая могла бы легко расширяться по мере необходимости — при увеличении объема данных, нагрузки и прочих неприятностях.

Обычно СУБД работают в условиях, когда объем доступных ресурсов ограничен имеющимся оборудованием. Чтобы добавить ресурсов, надо добавить или заменить сервера. В облаке же ресурсы доступны в тот момент, когда они понадобились, и их можно вернуть, если они больше не нужны. Архитектура Snowflake позволяет воспользоваться всеми преимуществами облака: хранилище данных может мгновенно расширяться и сжиматься, не прерывая выполняющиеся запросы.

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

Пара примеров:

• «Удобный хостинг»: Предустановка панели управления и дозаказ лицензий на лету
• Как работает API нашего IaaS-провайдера
• Как мы разработали свой DNS-менеджер

Сегодня мы решили продолжить краткий разбор заметки команды инженеров Twitter о создании файловой системы для работы с кластерами Hadoop.

Авторы статьи: Данила Перепечин DanilaPerepechin, Дмитрий Чеклов dcheklov.

Здравствуйте.
Data management platform (DMP) — это наша любимая тема во всей истории про онлайн рекламу. RTB is all about the data.
В продолжение цикла рассказов о технологическом стеке Targetix (SSP, DSP), сегодня я опишу один из инструментов, входящих
в DMP — Keyword Builder.

Недавно завершился курс Scalable Machine Learning по Apache Spark, рассказывающий о применении библиотеки MLlib для машинного обучения. Курс состоял из видеолекций и практических заданий. Лабораторные работы необходимо было выполнять на PySpark, а поскольку по работе мне чаще приходится сталкиваться со scala, я решил перерешать основные лабы на этом языке, а заодно и лучше усвоить материал. Больших отличий конечно же нет, в основном, это то, что PySpark активно использует NumPy, а в версии со scala используется Breeze.

Первые два практических занятия охватывали изучение основных операций линейной алгебры в NumPy и знакомство с apache spark соответственно. Собственно машинное обучение началось с третьей лабораторной работы, она и разобрана ниже.

Всем привет!
В первой статье мы рассказали о нашей инфраструктуре в целом. Теперь пришло время сосредоточиться на конкретных продуктах. В этой статье речь пойдёт о DSP. Как многие знают, DSP (Demand Side Platform) — автоматизированная система покупки рекламы. Требования к системе жёсткие: она должна держать высокую нагрузку (тысячи запросов в секунду), быстро отвечать (до 50 мс, а то и меньше) и, самое главное, выбирать максимально подходящие объявления. Чаще всего такие проекты разрабатываются под Linux, мы же смогли создать по-настоящему высокопроизводительный сервис под Windows Server. Как этого добиться, и как это удалось нам? Об этом я и расскажу.

В статье "Применение Теории вероятностей в IT" автор (преподаватель теории вероятностей в ВУЗе) пишет:

из года в год я сталкиваюсь с таким явлением, что студенты не понимают, зачем и почему им учить эту дисциплину.

Это действительно важная проблема. Владелец компании минималистичных видео-уроков Common Craft и заодно автор книги "Искусство объяснять" пишет, что человеку очень важно сначала ответить себе на вопрос «зачем?», и только тогда он заинтересуется ответом на вопрос «как?» (наверное, поэтому ему заказывали создание роликов в стиле Common Craft и Google, и Dropbox, и Twitter).

Поэтому я решил разобраться в теории вероятностей: накупил разных книжек типа "Удовольствие от икс", да потом ещё нанял двух репетиторов по Skype.

В итоге всё стало проясняться, и было решено поделиться своими инсайдами с широкой аудиторией.

Самый красивый пример, из тех, что я нашёл — это болты в чае. В советские времена был ГОСТ на максимальное содержание болтов\гаек в чае, которые попадали туда при уборке урожая: «массовая доля металломагнитной примеси» не должна была превышать 5-7 грамм на тонну. Для этого проверяли выборку и по ней делали заключение по всей партии чая.

И от этого примера можно переходить к более глобальному примеру применения статистического анализа — к японскому экономическому чуду.

В общем, всё это упоминается в тизере вебинара:

Авторы – Баков Рустам, Дмитриева Людмила, Кульнев Дмитрий, Медведев Юрий

Привет, Хабр-сообщество!

В данной статье мы не будем рассказывать, что такое SAP HANA, об этом и так много говорят и пишут, а сразу покажем, как можно «поиграть» с системой и создать простое приложение из серии «Hello World!» с применением среды разработки Eclipse.

Вначале настроим среду разработки Eclipse с необходимыми плагинами. Плагины для работы с SAP HANA существуют для двух версий Eclipse – Luna и Kepler. Если у вас не установлен Eclipse, то скачать его можно по ссылкам:
Luna — www.eclipse.org/luna
Kepler — www.eclipse.org/kepler
В нашем примере мы будем показывать все шаги настройки на примере Eclipse Luna.

У многих наших клиентов и потенциальных заказчиков установлены те или иные средства отслеживания активности на файловых серверах, SharePoint сайтах, Exchange и даже Active Directory. И всё это вроде даже работает – можно зайти в программу, сгенерировать отчеты, просмотреть статистику и выявить нестандартные шаблоны поведения. Но дьявол кроется в мелочах – проверять такие вещи необходимо регулярно, на постоянной основе, а не когда данные уже окажутся в чужих руках. Как показывает практика, делают это совсем не многие, несмотря на наличие соответствующих технических возможностей.

Но существует достаточно простой выход – автоматизация. Настроить всё один раз, а потом сидеть, попивать чаёк и реагировать только в случае возникновения подозрительных ситуаций – что может быть лучше? О том, что можно и даже нужно автоматизировать и на какие события высылать уведомления, мы и поговорим в рамках данной статьи.

«Чтоб тебе жить в эпоху перемен» — весьма лаконичное и вполне понятное проклятие для человека скажем старше 30 лет. Современный этап развития человечества сделал нас невольными свидетелями уникальной «эпохи перемен». И тут даже играет роль не то что бы масштаб современного научного прогресса, по значимости для цивилизации переход от каменных орудий труда к медным очевидно был куда более знаковым, нежели удвоение вычислительных способностей процессора, которое само по себе будет явно более технологичным. Та огромная, все нарастающая скорость изменений в техническом развитии мира просто обескураживает. Если еще лет сто назад каждый уважаемый себя джентльмен просто обязан был быть в курсе всех «новинок» мира науки и техники, чтоб не выглядеть в глазах своего окружения глупцом и деревенщиной, то сейчас учитывая объемы и скорость порождения этих «новинок» отслеживать их всецело просто невозможно, даже вопрос так не ставится. Инфляция технологий, еще до недавно не мыслимых, и связанных с ними возможностей человека, фактически убили прекрасное направление в литературе – «Техническая фантастика». В ней отпала нужда, будущее стало многократно ближе, чем, когда либо, задуманный рассказ о «чудесной технологии» рискует дойти до читателя позже, нежели что-то подобное уже будет сходить с конвейеров НИИ.

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

На страницах нашего блога мы рассказываем о сотрудничестве с самыми разными компаниями и организациями – от локальных интернет-магазинов до университетов с мировым именем. Увы, большинство подобных кейсов описывают работу с зарубежными партнерами, но иногда попадаются интересные примеры и в России. Сегодня именно такой случай. Герой нашей новой истории – компания CineLAB, которая занимается прокатом киносъемочного оборудования, обработкой пленки, цифровым постпродакшеном, спутниковой доставкой видеоконтента и многими другими интересными задачами в «киношном» мире.

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

Даже самые заядлые скептики уже признают, что технологии SSD обладают рядом неоспоримых преимуществ по сравнению с обычными жесткими дисками и позволяют получить значительно большую производительность операций ввода/вывода (а в некоторых случаях скорости I/O — много не бывает). Вместе с тем, SSD еще не готовы к повсеместному внедрению вместо традиционных жестких дисков по целому ряду причин: начиная с цены и заканчивая надежностью. Что же делать? На выручку приходят гибридные решения, которые сочетают традиционные диски с SSD, позволяя получить (пусть и с определенными оговорками) преимущества обоих решений.

Если не углубляться в детали, то сам принцип работы гибридных систем достаточно прост (а если углубиться — то можно настолько погрузиться, что и не вернешься за год) и одинаков для всех систем, начиная с дисков Seagate Momentus XT и Apple Fusion Drive, заканчивая дорогими и сложными решениями для больших систем хранения данных и дата-центров, о которых сегодня и пойдет речь.

Для основного хранения данных используются традиционные жесткие диски, по необходимости объединенные в RAID, а SSD используется для кэширования самых часто используемых данных, к которым надо обращаться чаще всего. Управление кэшированием системы берут на себя, и чаще всего кэш-раздел в системе вообще недоступен в виде отдельного диска.

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

Говоря о больших системах хранения данных, нельзя не вспомнить про компанию LSI, которая, являясь одним из крупнейших поставщиков для систем хранения данных, не могла остаться в стороне. В портфеле продуктов LSI есть набор решений для ускорения работы дисковых систем, объединенных в семейство Nytro.