Hadoop *

ETL-компонента хранилища данных часто оказывается в тени самого хранилища и ей уделяется меньше внимания, чем главной базе данных или фронт-компоненте, BI, формировании отчётов. При этом с точки зрения механики наполнения хранилища данными, ETL играет ключевую роль и требует не меньше внимания администраторов, чем остальные компоненты. Меня зовут Александр, сейчас я администрирую ETL в Ростелекоме, и в данной статье я постараюсь немного поделиться тем, с чем приходится сталкиваться администратору одной известнейшей ETL-системы в крупном хранилище данных компании Ростелеком.

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

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

Я попросил ведущего в России тренера по разработке и администрированию продуктов Informatica Алексея Ананьева рассказать о функции pushdown-оптимизации в Informatica Big Data Management (BDM). Когда-то учились работать с продуктами Informatica? Скорее всего именно Алексей рассказывал вам азы PowerCenter и объяснял, как строить маппинги.

Алексей Ананьев, руководитель направления по обучению DIS Group

Что такое pushdown?

Многие из вас уже знакомы с Informatica Big Data Management (BDM). Продукт умеет интегрировать большие данные из разных источников, перемещать их между разными системами, обеспечивает к ним лёгкий доступ, позволяет профилировать их и многое другое.
В умелых руках BDM способен творить чудеса: задачи будут выполняться быстро и с минимальными вычислительными ресурсами.

Тоже так хотите? Научитесь использовать функцию pushdown в BDM для распределения вычислительной нагрузки между разными платформами. Технология pushdown позволяет превратить маппинг в скрипт и выбрать среду, в которой этот скрипт запустится. Возможность такого выбора позволяет комбинировать сильные стороны разных платформ и достигать их максимальной производительности.

Для настройки среды исполнения скрипта нужно выбрать тип pushdown. Скрипт может быть полностью запущен на Hadoop или частично распределен между источником и приемником. Есть 4 возможных типа pushdown. Маппинг можно не превращать в скрипт (native). Маппинг можно исполнить максимально на источнике (source) или полностью на источнике (full). Также маппинг можно превратить в скрипт Hadoop (none).

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

Адреса для определенности российские, и главное — зачастую написаны криво, то есть с ошибками, неоднозначностями и прочими прелестями. И находятся эти адреса в базе данных Hive, на кластере Hadoop.


Ну казалось бы — берем Google Maps Geocoding API (или, если вы сторонник импортозамещения, то Yandex Maps API), и работаем. Но тут нас, как впрочем и c обратным геокодированием, ждет небольшая засада.

В моем предыдущем проекте перед нами встала задача провести обратное геокодирование для множества пар географических координат. Обратное геокодирование — это процедура, которая паре широта-долгота ставит в соответствие адрес или название объекта на карте, к которому принадлежит или близка заданная координатами точка. То есть, берем координаты, скажем такие: @55.7602485,37.6170409, и получаем результат либо «Россия, Центральный федеральный округ, Москва, Театральная площадь, дом такой-то», либо например «Большой театр».

Если на входе адрес или название, а на выходе координаты, то эта операция — прямое геокодирование, об этом мы, надеюсь, поговорим позже.

В качестве исходных данных у нас на входе было примерно 100 или 200 тысяч точек, которые лежали в кластере Hadoop в виде таблицы Hive. Это чтобы был понятен масштаб задачи.

В качестве инструмента обработки в конце концов был выбран Spark, хотя в процессе мы попробовали как MapReduce, так и Apache Crunch. Но это отдельная история, возможно заслуживающая своего поста.

Мы – Big Data в МТС и это наш первый пост. Сегодня расскажем о том, какие технологии позволяют нам хранить и обрабатывать большие данные так, чтобы всегда хватало ресурсов для аналитики, и затраты на закупки железа не уходили в заоблачные дали.

О создании центра Big Data в МТС задумались в 2014 году: появилась необходимость масштабирования классического аналитического хранилища и BI-отчетности над ним. На тот момент движок для обработки данных и BI были SASовские – так сложилось исторически. И хотя потребности бизнеса в хранилище были закрыты, со временем функционал BI и ad-hoc-аналитики поверх аналитического хранилища разросся настолько, что нужно было решать вопрос увеличения производительности, учитывая, что с годами количество пользователей увеличилось в десятки раз и продолжало расти.

В результате конкурса в МТС появилась MPP-система Teradata, покрывающая потребности телекома на тот момент. Это стало толчком к тому, чтобы попробовать что-то более популярное и open source’вое.



На фото — команда Big Data МТС в новом офисе «Декарт» в Москве

В начале 2018 года у нас активно пошел процесс цифровизации производства и процессов в компании. В секторе нефтехимии это не просто модный тренд, а новый эволюционный шаг в сторону повышения эффективности и конкурентоспособности. Учитывая специфику бизнеса, который и без всякой цифровизации показывает неплохие экономические результаты, перед «цифровизаторами» стоит непростая задача: всё-таки менять устоявшиеся процессы в компании — довольно кропотливая работа.

Наша цифровизация началась с создания двух центров и соответствующих им функциональных блоков.

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



И вот как раз главная задача дата-офиса заключается в том, чтобы полноценно внедрить культуру принятия решений, основанных на данных (да, да, data-driven decision), а также в принципе упорядочить всё, что касается работы с данными: аналитика, обработка, хранение и отчетность. Особенность в том, что все наши цифровые инструменты должны будут не только активно использовать собственные данные, то есть те, которые генерируют сами (например, мобильные обходы, или датчики IIoT), но и внешние данные, с четким пониманием, где и зачем их нужно использовать.

Меня зовут Артем Данилов, я руководитель направления «Инфраструктура и технологии» в СИБУРе, в этом посте я расскажу, как и на чем мы строим большую систему обработки и хранения данных для всего СИБУРа. Для начала поговорим только о верхнеуровневой архитектуре и о том, как можно стать частью нашей команды.

В «Ростелекоме» мы используем Hadoop для хранения и обработки данных, загруженных из многочисленных источников с помощью java-приложений. Сейчас мы переехали на новую версию hadoop с Kerberos Authentication. При переезде столкнулись с рядом проблем, в том числе и с использованием YARN API. Работа Hadoop с Kerberos Authentication заслуживает отдельной статьи, а в этой мы поговорим об отладке Hadoop MapReduce.

Сегодня на тематических зарубежных сайтах о Big Data можно встретить упоминание такого относительно нового для экосистемы Hadoop инструмента как Apache NiFi. Это современный open source ETL-инструмент. Распределенная архитектура для быстрой параллельной загрузки и обработки данных, большое количество плагинов для источников и преобразований, версионирование конфигураций – это только часть его преимуществ. При всей своей мощи NiFi остается достаточно простым в использовании.



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

Мне давно хотелось изложить свои впечатления об Apache Spark, и тут как раз попалась на глаза вот эта статья от сотрудника Pivotal Robert Bennett, опубликованная совсем недавно, 26 июня 2018.

Это не будет перевод, а скорее все-таки мои впечатления и комментарии на тему.

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

Добрый день! Меня зовут Данил Липовой, наша команда в Сбертехе начала использовать HBase в качестве хранилища оперативных данных. В ходе его изучения накопился опыт, который захотелось систематизировать и описать (надеемся, что многим будет полезно). Все приведенные ниже эксперименты проводились с версиями HBase 1.2.0-cdh5.14.2 и 2.0.0-cdh6.0.0-beta1.

1. Общая архитектура
2. Запись данных в HBASE
3. Чтение данных из HBASE
4. Кэширование данных
5. Пакетная обработка данных MultiGet/MultiPut
6. Стратегия разбивки таблиц на регионы (спилитинг)
7. Отказоустойчивость, компактификация и локальность данных
8. Настройки и производительность
9. Нагрузочное тестирование
10. Выводы

В нашей компании СберТех (Сбербанк Технологии) на данный момент используется HDFS 2.8.4 так как у него есть ряд преимуществ, таких как экосистема Hadoop, быстрая работа с большими объемами данных, он хорош в аналитике и многое другое. Но в декабре 2017 года Apache Software Foundation выпустила новую версию открытого фреймворка для разработки и выполнения распределённых программ — Hadoop 3.0.0, которая включает в себя ряд существенных улучшений по сравнению с предыдущей основной линией выпуска (hadoop-2.x). Одно из самых важных и интересующих нас обновлений это поддержка кодов избыточности (Erasure Coding). Поэтому была поставлена задача сравнить данные версии между собой.

Компанией СберТех на данную исследовательскую работу было выделено 10 виртуальных машин размером по 40 Гбайт. Так как политика кодирования RS(10,4) требует минимум 14 машин, то протестировать ее не получится.

На одной из машин будет расположен NameNode помимо DataNode. Тестирования будет проводиться при следующих политиках кодирования:

• XOR(2,1)
• RS(3,2)
• RS(6,3)

А также, используя репликацию с фактором репликации равным 3.

Размер блока данных был выбран равным 32 Мб.

Банк — это по определению «кредитно-денежная организация», и от того, насколько успешно эта организация выдает и возвращает кредиты, зависит ее будущее. Чтобы успешно работать с кредитами, нужно понимать финансовое положение заемщиков, в чем помогают факторы кредитного риска (ФКР). Кредитные аналитики выявляют их в огромных массивах банковской информации, обрабатывают эти факторы и прогнозируют дальнейшие изменения. Обычно для этого используется описательная и диагностическая аналитика, но мы решили подключить к работе инструменты машинного обучения. О том, что получилось, читайте в посте.

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

В мире энтерпрайза наступило пресыщение фронтовыми системами, шинами данных и прочими классическими системами, которые внедряли все кому не лень последние 10-15 лет. Но есть один сегмент, который до недавнего времени был в статусе «все хотят, но никто не знает, что это». И это Big Data. Красиво звучит, продвигается топовыми западными компаниями – как не стать лакомым кусочком?



Но пока большинство только смотрит и приценивается, некоторые компании начали активно внедрять решения на базе этого технологического стека в свой IT ландшафт. Важную роль в этом сыграло появление коммерческих дистрибутивов Apache Hadoop, разработчики которых обеспечивают своим клиентам техническую поддержку. Ощутив необходимость в подобном решении, один из наших клиентов принял решение об организации распределенного хранилища данных в концепции Data Lake на базе Apache Hadoop.

В рамках проекта интеграции GridGain и хранилища на базе Hadoop (HDFS + HBASE) мы столкнулись с задачей получения и обработки существенного объема данных, примерно до 80 Тб в день. Это необходимо для построения витрин и для восстановления удаленных в GridGain данных после их выгрузки в наше долговременное хранилище. В общем виде, можно сказать, что мы передаём данные между двумя распределёнными системами обработки данных при помощи распределённой системы передачи данных. Соответственно, мы хотим рассказать о тех проблемах, с которыми столкнулась наша команда при реализации данной задачи и как они были решены.

Так как инструментом интеграции является кафка (весьма подробно о ней описано в статье Михаила Голованова), естественным и легким решением тут выглядит использование SparkStreaming. Легким, потому что не нужно особо беспокоиться о падениях, переподключениях, коммитах и т.д. Spark известен, как быстрая альтернатива классическому MapReduce, благодаря многочисленным оптимизациям. Нужно лишь настроиться на топик, обработать батч и сохранить в файл, что и было реализовано. Однако в ходе разработки и тестирования была замечена нестабильность работы модуля приема данных. Для того чтобы исключить влияние потенциальных ошибок в коде, был произведен следующий эксперимент. Был выпилен весь функционал обработки сообщений и оставлено только прямое сохранение сразу в avro:

Добрый день! Меня зовут Алексей Булавин, я представляю центр компетенций Сбертеха по Big Data. Представители бизнеса, владельцы продуктов и аналитики часто задают мне вопросы по одной и той же теме — матчинг. Что это такое? Зачем и как его делать? Особенно популярен вопрос «Почему он может не получиться?» В этой статье я постараюсь на них ответить.

Кейсы практического применения Больших данных
в компаниях финансового сектора

Зачем эта статья?

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

Диапазон рассмотренных кейсов ограничивается примерами, представленными в открытом доступе на сайте компании Cloudera.

Что такое «Большие данные»

Есть в технических кругах шутка, что «Большие данные» это данные, для обработки которых недостаточно Excel 2010 на мощном ноутбуке. То есть если для решения задачи вам надо оперировать 1 миллионом строк на листе и более или 16 тысяч столбцов и более, то поздравляем, ваша данные относятся к разряду «Больших».

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

Все мы любим посмеяться над дремучим legacy на Java, которое якобы живёт в банках. После прочтения этой статьи у вас появится понимание другой грани этой истории. Оказывается, конкретно в Сбербанк-Технологиях есть целые большие отделы, занимающиеся прорывными технологиями и направлениями, включая Big Data и Machine Learning. Более того, скоро мы можем оказаться в мире, где Machine Learning встроен чуть ли не в каждую кофеварку. К добру или к худу, но Internet of Things, следящий за нами тысячью глаз из каждого банкомата, — куда более актуальное прочтение этой старой шутки.

Как вы, наверное, заметили, я пишу на Хабре про виртуальные машины, внутренности OpenJDK, JVM и другую системную разработку. Почему эта статья — о банковском софте? Потому что это актуально как никогда. Вот представьте, вы такой весь в белом, дважды Data Scientist и четырежды важный гуру JIT-компиляции. Что дальше? Кому всё это может быть нужно прямо здесь и сейчас? Часто слышу рассуждения на тему: «Вот сейчас ты ковыряешься в своей любимой Java, а завтра никто тебя на работу не возьмёт». Это очень забавное и опасное заблуждение. Благодаря таким товарищам, о которых пойдёт речь в этой статье, работа у нас будет всегда.

Конечно, на слово мне никто верить не должен, поэтому специально для Хабра я сорвался на самолёт в Москву, чтобы пообщаться с начальником отдела разработки спецпроектов в Сбербанк-Технологиях. Вадим Сурпин потратил на меня чуть больше часа, а в этом интервью будут только самые важные мысли из нашего разговора. Кроме того, удалось уговорить Вадима подать заявку на участие в нашей конференции JBreak. Более того, Вадим — первый человек, который показался мне достойным инвайта на Хабр: vadsu (инвайт был честно заработан статьей про хакинг ChromeDriver).