Hadoop *

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

На деле переносить проект с многокомпонентной системой обработки данных, масштаба Петабайта, из локальной среды в облачную — это сплошные “но”. Для миграции есть много продуктов: Hadoop, Hive, Yarn, Spark, Kafka, Zookeeper, Jupyter, Zeppelin. Учитывая принципиальное различие среды, в этом многообразии легко потеряться и наделать ошибок.

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

Наверное, ни для кого не секрет, что прошлый год для Apache Hadoop стал годом больших перемен. В прошлом году произошло слияние Cloudera и Hortonworks (по сути, поглощение второго), а Mapr, в виду серьезных финансовых проблем, был продан Hewlett Packard. И если несколькими годами ранее, в случае on-premises инсталляций, выбор чаще приходилось делать между Cloudera и Hortonworks, то сегодня, увы, этого выбора у нас не осталось. Сюрпризом стал еще и тот факт, что Cloudera с февраля этого года объявила о прекращении выпуска бинарных сборок своего дистрибутива в публичный репозиторий, и теперь они доступны лишь по платной подписке. Конечно, возможность загрузки последних версий CDH и HDP, выпущенных до конца 2019-го года, все еще есть, и поддержка по ним предполагается в течение одного-двух лет. Но что же делать дальше? Для тех, кто ранее платил за подписку, ничего не изменилось. А для тех, кто не хочет переходить на платную версию дистрибутива, но при этом хочет иметь возможность получать свежие версии компонентов кластера, а также патчи и прочие обновления, мы и подготовили эту статью. В ней мы рассмотрим возможные варианты выхода из сложившейся ситуации.

Статья больше обзорная. В ней не будет сравнения дистрибутивов и подробного их разбора, а также не будет рецептов по их установке и настройке. А что же будет? Мы вкратце расскажем про такой дистрибутив как Arenadata Hadoop, который по праву заслужил наше внимание ввиду своей доступности, что на сегодня большая редкость. А затем поговорим про Vanilla Hadoop, в основном про то, как его можно “приготовить” с помощью Apache Bigtop. Готовы? Тогда добро пожаловать под кат.

Предлагаю ознакомиться с расшифровкой лекции "Hadoop. ZooKeeper" из серии "Методы распределенной обработки больших объемов данных в Hadoop"

Что такое ZooKeeper, его место в экосистеме Hadoop. Неправда о распределённых вычислениях. Схема стандартной распределённой системы. Сложность координации распределённых систем. Типичные проблемы координации. Принципы, заложенные в дизайн ZooKeeper. Модель данных ZooKeeper. Флаги znode. Сессии. Клиентский API. Примитивы (configuration, group membership, simple locks, leader election, locking без herd effect). Архитектура ZooKeeper. ZooKeeper DB. ZAB. Обработчик запросов.

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

Это даже не шутка, похоже, что именно эта картинка наиболее точно отражает суть этих БД, и в конце будет понятно почему:



Согласно DB-Engines Ranking, две самых популярных NoSQL колоночных базы — это Cassandra (далее CS) и HBase (HB).



Волею судеб наша команда управления загрузки данных в Сбербанке уже давно и плотно работает с HB. За это время мы достаточно хорошо изучили её сильные и слабые стороны и научились её готовить. Однако наличие альтернативы в виде CS все время заставляло немного терзать себя сомнениями: а правильный ли выбор мы сделали? Тем более, что результаты сравнения, выполненного DataStax, говорили, что CS легко побеждает HB практически с разгромным счетом. С другой стороны, DataStax — заинтересованное лицо, и верить на слово тут не стоит. Также смущало достаточно малое количество информации об условиях тестирования, поэтому мы решили выяснить самостоятельно, кто же является королем BigData NoSql, и полученные результаты оказались весьма интересны.

Известное об известном: spark работает с “датафреймами” (dataframes), которые являются алгоритмами трансформации. Алгоритм запускается в самый последний момент для того, чтобы "дать больше места" оптимизации и за счет оптимизации максимально эффективно его выполнить.

Под катом мы разберем — как можно разложить многостраничный SQL запрос на атомы (без потери эффективности) и как можно за счет этого существенно уменьшить время выполнения ETL конвейера.

Для того, чтобы получить качественный production код, недостаточно просто обеспечить максимальное покрытие тестами. Несомненно, для того, чтобы добиться высоких результатов, основной код проекта и тесты обязаны работать в идеально сплоченном тандеме. Поэтому уделять внимания тестам нужно столько же, сколько и основному коду. Написание хорошего теста – залог того, что он отловит регрессию в production. Чтобы показать важность того, что баги в тестах ничем не хуже, чем в production, рассмотрим очередной разбор предупреждений статического анализатора PVS-Studio. Цель: Apache Hadoop.

Перевод статьи подготовлен специально для студентов курса «Data Engineer».

---

Читать первую часть

Никому не нужна Big Data

Когда вы услышите «Никому не нужна Big Data», посмотрите на резюме докладчика. Африканский телекоммуникационный оператор, переживающий удивительные уровни роста, не собирается обращаться к новоиспеченному JavaScript веб-разработчику и спрашивать его, может ли они помочь в разработке своей платформы данных и оптимизации расчетов биллинга. Вы можете найти множество внутренних веб-приложений в штаб-квартире авиакомпании, но когда дело доходит до анализа петабайт телеметрии самолетов для профилактического обслуживания, в этом проекте может не оказаться ни одного PHP разработчика.

Перевод статьи подготовлен специально для студентов курса «Data Engineer».

---

После того, как и Cloudera, и MapR несколько недель назад объявили о том, что их бизнес переживает трудные времена, я увидел поток постов в социальных сетях с темой «Hadoop мертв». Эти посты не являются чем-то новым, но в секторе, где технические специалисты редко производят качественный материал для социальных сетей, эти возгласы становятся все громче и громче. Я бы хотел рассмотреть некоторые из аргументов, касающихся состояния Hadoop.

Множество иностранных авторов сходятся к тому, что эпоха Big Data подошла к концу. И в данном случае под термином Big Data понимаются технологии, основанные на Hadoop. Многие авторы, даже могут с уверенностью назвать дату, когда Big Data оставила этот мир и эта дата — 05.06.2019.

Что же произошло в этот знаменательный день?

В этот день, компания MAPR обещала приостановить свою работу, если не сможет найти средства для дальнейшего функционирования. Позднее, в августе 2019 года MAPR был приобретен компанией HP. Но возвращаясь к июню нельзя не отметить, трагичность этого периода для рынка Big Data. В этом месяце произошел обвал биржевых котировок акций компании CLOUDERA – ведущего игрока на обозначенном рынке, которая произвела слияние с хронически неприбыльным HORTOWORKS в январе этого же года. Обвал был весьма существенен и составил 43%, в конечном итоге капитализация CLOUDERA снизилась с 4,1 до 1,4 миллиарда долларов.

Невозможно не сказать, что слухи о надувании пузыря в сфере технологий, базирующихся на Hadoop, ходили еще с декабря 2014 года, но он мужественно продержался еще почти пять лет. Слухи эти основывались на отказе Google, компании в которой зародилась технология Hadoop, от своего изобретения. Но технология, прижилась, на время перехода компаний к облачным средствам обработки и бурного развития искусственного интеллекта. Поэтому, оборачиваясь назад, можно с уверенностью сказать, что кончина была ожидаемой.

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

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

Привет всем, немного информации "из под капота" дата инженерного цеха Альфастрахования — что будоражит наши технические умы.

Apache Spark — замечательный инструмент, позволяющий просто и очень быстро обрабатывать большие объемы данных на достаточно скромных вычислительных ресурсах (я имею в виду кластерную обработку).

Традиционно, в процессе ad hoc обработки данных используется jupyter notebook. В комбинации со Spark-ом это позволяет нам манипулировать долго живущими дата фреймами (распределением ресурсов занимается Spark, дата фреймы "живут" где-то в кластере, время их жизни ограничено временем жизни Spark контекста).

После переноса обработки данных в Apache Airflow время жизни дата фреймов сильно сокращается — Spark контекст "живет" в пределах одного оператора Airflow. Как это обойти, зачем обходить и при чем здесь Livy — читайте под катом.

Всем привет! Публикуем перевод статьи, подготовленный для студентов новой группы курса «Data Engineer». Если интересно узнать, как построить эффективную и масштабируемую систему обработки данных с минимальными затратами, посмотрите запись мастер-класса Егора Матешука!

Несколько недель назад я написал о Hadoop статью, где осветил различные его
части и разобрался в том, какую роль он играет в области data engineering. В этой статье я
дам краткое описание различных файловых форматов в Hadoop. Это быстрая и легкая
тема. Если вы пытаетесь понять, как работает Hadoop и какое место он занимает в работе
Data Engineer, ознакомьтесь с моей статье о Hadoop здесь.

В Hadoop входят продукты, которые могут работать с файлами разных форматов. Я неоднократно искал, читал и думал над тем — какой же формат лучше. Относительно случайно столкнувшись с форматом ORC, заинтересовался, почитал (и даже чуть покодил) и вот что понял — сравнивать форматы как таковые некорректно. Точнее, их обычно сравнивают, на мой взгляд, некорректным образом. Собственно, статья об этом, а также о формате Apache ORC (в техническом плане) и предоставляемых им возможностях.

Начну с вопроса: каким может быть размер реляционной таблицы (в байтах и очень примерно), состоящей из 10 тысяч строк (по два целых поля в строке)? Обычно здесь ставят кат, а ответ помещают под катом — я отвечу здесь: 628 байт. А детали и историю перенесу под кат.

Привет, Хабр!

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

Как данные попадают в банк, и как команда аналитиков следит за этим процессом, разберём в данной статье.

Недавно посматривая реестр отечественного ПО, нашёл российскую сборку Hadoop, чему был изрядно удивлён.
Причём, регистрация прошла аж в 2017 году. (ссылка для интересующихся) и с тех пор на хабре ни строчки об этом.
Итак, встречайте — Arenadata Hadoop (ADH)!

Первые впечатления:
Перешёл на сайт и… Последний раз такую комбинацию озадаченности и недоумения испытал в 2014, когда встретил в магазине белорусских устриц.

Судите сами:
вот сайт Arenadata

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. Но это отдельная история, возможно заслуживающая своего поста.