ИНТЕГРАЦИЯ ДАННЫХ

 ETL (Extract, Transform, Load):

 извлечение данных из внешних источников;
 их трансформация и очистка, чтобы они соответствовали потребностям бизнес-модели;
 и загрузка их в хранилище данных.
 Enterprise content management (ECM):
 Управление корпоративным контентом
 Управление цифровыми документами и другими типами контента, а также их хранение,
обработка и доставка в рамках организации.
Управляемая информация (контент) предполагает слабую структурированность: это могут быть
файлы различных форматов, электронные документы с различными наборами полей.
ECM-система — программное обеспечение для управления корпоративным контентом. Часто
ECM-системы считаются особой разновидностью систем управления содержимым. На постсоветском
пространстве понятие ECM-системы зачастую трактуется как сходное с понятием «системы
электронного документооборота» (СЭД).
 Enterprise information integration (EII):
 Интеграция корпоративной информации
 Способность поддерживать единое представление данных и информации для всей организации.
Цель EII - сделать так, чтобы большой набор разнородных источников данных представлялся
пользователю или системе как единый однородный источник данных.
В приложениях EII для виртуализации данных: Процесс интеграции информации, использующий
абстракцию данных для обеспечения унифицированного интерфейса (известного как
унифицированный доступ к данным) для просмотра всех данных в организации, и единого набора
структур и соглашений об именах (известных как единое информационное представление) для
представления этих данных.
 Enterprise application integration (EAI):
 Интеграция корпоративных приложений
 Технологии и приложения, задача которых - вовлечь несколько приложений, используемых в
одной организации, в единый процесс и осуществлять преобразование форматов данных между
ними.
 Еnterprise data replication (EDR):
 Тиражирование корпоративных данных
 EDR начинался как репликация базы данных, когда он включал перемещение набора данных из
одной базы данных в другую базу данных того же типа.
Современные инструменты EDR, напротив, работают с несколькими источниками данных и
типами баз данных в гетерогенной среде. Данные могут реплицироваться в режиме реального
времени, время от времени или на регулярной основе. Инструмент EDR может копировать данные из
одной системы в другую для взаимной репликации. Данные могут быть доступны как в виде таблиц,
так и в виде XML-каналов, что может сделать данные доступными для целей реального времени.
Методы интеграции данных:
1. Консолидация
2. Федерализация
3. Распространение
4. Гибридные методы
 1. Консолидация данных
Данные собираются из нескольких первичных систем и интегрируются в одно постоянное место
хранения. Такое место хранения может быть использовано для подготовки отчетности и проведения
анализа, как в случае Хранилища данных, или как источник данных для других приложений.
При использовании этого метода обычно существует некоторая задержка между моментом
обновления информации в первичных системах и временем, когда данные изменения появляются в
конечном месте хранения. В зависимости от потребностей бизнеса такое отставание может оставлять
несколько секунд, часов или много дней.
Термин "режим, приближенный к реальному времени" часто используется для описания конечных
данных, обновление которых отстает от источника на несколько секунд, минут или часов. Данные, не
отстающие от источника, считаются данными в режиме реального времени, но это трудно достижимо
при использовании метода консолидации данных.
Конечные места хранения данных, содержащие данные с большими временами отставания
(например, более одного дня), создаются с помощью пакетных приложений интеграции данных,
которые извлекают данные из первичных систем с определенными, заранее заданными интервалами.
Такой подход использует запросы к данным, которые получают периодические "мгновенные
снимки" первичных данных. Хотя подобные запросы получают текущие данные, они не отражают
тех изменений, которые произошли между двумя последовательными запросами. А за это время
данные могли обновляться несколько раз.
2. Федерализация данных
Обеспечивает единую виртуальную картину одного или нескольких первичных файлов данных.
Если бизнес-приложение генерирует запрос к этой виртуальной картине, то процессор
федерализации данных извлекает данные из соответствующих первичных складов данных,
интегрирует их таким образом, чтобы они отвечали виртуальной картине и требованиям запроса, и
отправляет результаты бизнес-приложению, от которого пришел запрос.
По определению, процесс федерализации данных всегда заключается в извлечении данных из
первичных систем на основании внешних требований. Все необходимые преобразования данных
осуществляются при их извлечении из первичных файлов. Один из ключевых элементов
федеративной системы - это метаданные, которые используются процессором федерализации данных
для доступа к первичным данным.
Обеспечивает доступ к текущим данным и избавляет от необходимости консолидировать
первичные данные в новом складе данных. Однако не очень хорошо подходит для извлечения и
согласования больших массивов данных или для тех приложений, где существуют серьезные
проблемы с качеством данных в первичных системах.
 3. Распространение данных
Приложения распространения данных осуществляют копирование данных из одного места в
другое. Обычно работают в оперативном режиме и производят перемещение данных к местам
назначения, т.е. зависят от определенных событий. Обновления в первичной системе могут
передаваться в конечную систему синхронно или асинхронно. Синхронная передача требует, чтобы
обновления в обеих системах происходили во время одной и той же физической транзакции.
Большинство технологий синхронного распространения данных поддерживают двусторонний
обмен данными между первичными и конечными системами. Независимо от используемого типа
синхронизации, метод распространения гарантирует доставку данных в систему назначения. Такая
гарантия - это ключевой отличительный признак распространения данных. Может быть
использовано для перемещения данных в режиме реального времени или близком к нему.
Гарантированная доставка данных и двустороннее распространение данных. Может использоваться
для уравновешивания рабочей нагрузки, создания резервных копий и восстановления данных, в том
числе в случае чрезвычайных ситуаций.
ПУТЬ САМУРАЯ К БОЛЬШИМ ДАННЫМ
За последнее десятилетие количество генерируемых данных резко возросло. По некоторым
оценкам каждую секунду генерируется более 30 тысяч гигабайт данных! Скорость создания данных
только увеличивается. Этот поразительный рост затронул бизнес. В результате традиционные
системы баз данных (реляционные базы данных)
 были доведены до предела
 не удалось масштабировать в прежних условиях до уровня больших данных
Чтобы решить проблемы, связанные с большими данными, появилось новое поколение
технологий, объединенных термином NoSQL. Эти системы могут масштабироваться до значительно
больших наборов данных; требуют принципиально нового набора методик. Многие из этих систем
больших данных были разработаны компанией Google, в том числе:
 Распределенные файловые системы
 Платформа вычислений MapReduce
 Распределённый менеджер блокировок (Distributed Locking Manager)
Еще одним пионером была компания Amazon, которая создала распределенное хранилище ключей
и значений под названием Dynamo. Сообщество открытого исходного кода ответило Hadoop, HBase,
MongoDB, Cassandra, RabbitMQ. Эта новая парадигма больших данных получила название Lambda
Architecture.
Масштабирование традиционной базы данных.
Рассмотрим простое приложение веб-аналитики:
 отслеживает просмотры страниц для любого URL-адреса, для которого клиент разрешит
отслеживание
 должно быть в состоянии сказать, какие 100 лучших URL-адресов по количеству просмотров
страниц
 веб-страница клиента пингует сервер приложения своим URL-адресом при каждом просмотре
страницы
Традиционная реляционная схема:

Какие проблемы возникают по мере развития приложения?

 Масштабирование с помощью очереди
 Огромный успех: трафик вашего приложения растет с огромной скоростью.
 Вы начинаете получать много сообщений по email от вашей системы мониторинга: «Timeout
error on inserting to the database.» («Ошибка тайм-аута добавления в базу данных»).
Проблема очевидна: Время ожидания запросов на запись в базу данных для увеличения
количества просмотров страниц быстро истекает из-за высокой нагрузки.
Вам нужно быстро что-то сделать, чтобы решить проблему – группировать множество
приращение данных в одном запросе.
 Масштабирование за счёт сегментирования базы данных (шардинг)
 приложение продолжает набирать популярность
 работник не может успевать за записью
Вы пытаетесь добавить больше рабочих станций (workers) для распараллеливания обновлений. Не
помогает; база данных явно является узким местом.
 лучший подход — горизонтальное (по строкам) разбиение или сегментирование:
 использовать несколько серверов баз данных
 разнести таблицу по всем серверам
 каждый сервер будет иметь подмножество данных для таблицы
 блок данных для каждого ключа: взять хэш ключа, изменяемого в зависимости от блока
данных.
Вы пишете сценарий для сопоставления всех строк в базе данных и разбиваете данные на четыре
шарда. Запуск занимает некоторое время. Вы должны выключить рабочую станцию. В противном
случае вы потеряете добавления в базу данных во время перехода
Весь код приложения должен знать, как найти сегмент (шард) для каждого ключа.
 Сделать обертку (библиотеку) вокруг кода обработки базы данных, который считывает
количество шардов из конфигурационного файла
 Повторно развернуть весь код приложения
Запрос 100 лучших URL-адресов придется изменить: получить 100 самых популярных URL-
адресов из каждого сегмента и объединить их для получения 100 самых популярных URL-адресов по
всему миру.
Поскольку приложение становится все более популярным необходимо разбить базу данных на
большее количество сегментов.
 С каждым разом появляется больше забот:
 Много дополнительной работы для координации шардов;
 Пересегментирование (решардинг) с помощью одного скрипта слишком медленное;
 Необходимо выполнять всю перенастройку параллельно и одновременно управлять многими
активными рабочими сценариями.
Предположим, Вы забыли обновить код приложения с новым количеством шардов
 многие добавления были записаны не в те шарды
 придется написать скрипт, чтобы переместить то, что было не на своем месте
Начинаются проблемы с отказоустойчивостью
Предположим диск на одном и серверов базы данных выходит из строя. Соответствующая часть
данных недоступна, пока этот сервер не работает. Приходится выполнять несколько операций, чтобы
решить эту проблему:
 обновить систему очередей/рабочих процессов, чтобы поместить приращения для недоступных
сегментов в отдельную «очередь ожидания»;
 использовать возможности репликации базы данных для добавления добавочного (ведомого,
slave устройства к каждому сегменту).
В итоге первые дни вы тратили свое время на создание новых функций для клиентов. Теперь вы
тратите все свое время на решение проблем чтения и записи данных.
Проблемы исправления ошибок базы данных
Вы случайно допустили в рабочей среде ошибку, которая увеличивает число просмотров страниц
на два за каждый URL-адрес. Ошибка не была замечена до 24 часов работы: в результате данные
искажены. Еженедельные резервные копии не помогают: нет способа узнать, какие данные были
реально искажены. В итоге несмотря на попытки сделать систему масштабируемой и устойчивой к
сбоям оборудования, система оказалась не устойчива к ошибкам человека.
Что пошло не так?
 Одна из проблем заключается в том, что традиционная база данных не изначально не
рассчитана распределенную природу: не может помочь справиться с шардами, репликацией и
распределенными запросами
 Также такая система не рассчитана на человеческие ошибки: если система становится все более
и более сложной, вероятность ошибок возрастает
Переход к технологиям больших данных.
Чем помогут технологии Big Data?
 Методы работы с большими данными помогут решать эти проблемы масштабируемости и
сложности.
 Базы данных в вычислительных системах для больших данных изначально рассчитаны работать
распределено
 Такие вещи, как сегментирование и репликация, выполняются за вас, вы просто добавите узлы,
и системы автоматически перебалансируются
Приходиться для этого сделать данные неизменяемыми
 Хранить информацию о просмотрах страниц по строкам
 Можно при этом случайно записать в строки неверные данные, но, по крайней мере, верные
данные не будут потеряны
NoSQL не панацея:
 Может обрабатывать очень большие объемы данных, но с серьезными компромиссами: Hadoop
может распараллеливать крупномасштабные пакетные вычисления, но вычисления имеют
большую задержку
 Базы данных NoSQL достигают своей масштабируемости, предлагая вам гораздо более
ограниченную модель данных: они должны разумно использоваться в сочетании друг с другом
Первые принципы.
Что делает система данных?
Отвечает на вопросы, основанные на информации, полученной в прошлом до настоящего времени,
например: Как зовут этого человека? Сколько друзей у этого человека? Каков мой текущий баланс?
Не все составляющие информации одинаковы: Некоторая информация получена из других частей
информации, например:
 Баланс банковского счета выводится из истории транзакций.
 Список друзей формируется из всех случаев, когда пользователь добавлял и удалял друзей.
Данные: информация, которая не получена ни из чего
Запрос = функция (все данные)
Требуемые свойства систем больших данных.
 Надежность и отказоустойчивость
 Чтение и обновление с малой задержкой
 Масштабируемость
 Обобщение
 Расширяемость
 Специальные запросы
 Минимальное обслуживание
 Отладка
ИНТЕРНЕТ ВЕЩЕЙ

Это сеть устройств, средств перемещения и домашней техники, содержащих электронику,

программные приложения, сенсоры, сеть, что делает возможным: связь, взаимодействие и обмен
данными.
Уровни (интернет вещей).
 Серверное или облачное хранение данных
 Серверная или облачная обработка данных
 Интернет
 Локальная сеть
 Локальное хранение данных
 Локальная обработка данных
 Сенсоры, датчики, контроллеры
Сенсоры (интернет вещей).
 Измеряют величины
 Отправляют цифровые последовательности
 Потребляют мало энергии
 Просты в управлении
Локальное хранение и обработка данных (интернет вещей).
 Получение данных от сенсоров
 Обработка данных (сигнала)
 Отправка обработанных данных
 Хранение данных
Локальная сеть и интернет (интернет вещей).
 Сбор и передача данных от сенсоров
 Поддержка протоколов передачи

Сервер loT Gateway или облако (интернет вещей).
 Сбор и хранение данных от сенсоров
 Обработка данных
 Заключения и/или принятие решений
 Управление

Свойства (интернет вещей).
 Эффективная и масштабируемая архитектура взаимодействия.
 Бесконфликтное взаимодействие и однозначная идентификация устройств.
 Возможность временной недоступности «спящих», мобильных и неадресуемых устройств.

Применения (интернет вещей).
 Бизнес: Цепочки поставок, снабжение
 Производство: роботизированное производство, датчики оборудования
 Медицина: переносные и оперативные датчики здоровья
 Продажи: отслеживание активности и действий покупателей
 Безопасность: системы распознавания и контроля доступа
Недостатки (интернет вещей).
 Стандарты: а точнее, их отсутствие. Это затрудняет возможность интеграции предлагаемых на
рынке решений и сдерживает появление новых.
 Автономность: для полноценного функционирования сети необходима автономность вещей.
Датчики должны получать энергию из окружающей среды, а не работать от батареек.
 Конфиденциальность: при объединении или сопоставлении нескольких потоков данных иногда
можно получить более точный цифровой портрет человека.
 Безопасность: умные устройства часто становятся объектом интереса хакеров и
злоумышленников.
 Законодательство: технологии развиваются гораздо быстрее, чем связанное с ними
законодательство и нормативно-правовая среда.
 Развитие IoT ведет к появлению новых юридических, нормативных и гражданско-правовых
проблем, которые не существовали до появления этой концепции.
Близкие технологии (интернет вещей).
 Межмашинное взаимодействие (Machine-to-Machine, M2M)
Общее название технологий, которые позволяют машинам обмениваться информацией друг с
другом, или же передавать её в одностороннем порядке.
Активно используется в системах безопасности и охраны, вендинге, системах здравоохранения,
промышленных телеметрических системах (производство, энергетика, ЖКХ и др.) и системах
позиционирования ГЛОНАСС/GPS.
 Кибер-физическая система (cyber-physical system)
Информационно-технологическая концепция, подразумевающая интеграцию вычислительных
ресурсов в физические процессы. В такой системе датчики, оборудование и информационные
системы соединены на протяжении всей цепочки.
Эти системы взаимодействуют друг с другом с помощью стандартных интернет-протоколов для
прогнозирования, самонастройки и адаптации к изменениям.

ПРОМЫШЛЕННЫЙ ИНТЕРНЕТ ВЕЩЕЙ
Совокупность технологий обеспечивающая в целом в системе информационные процессы:
 Сбор информации
 Передачу информации
 Хранение информации
 Интеллектуальная обработка информации
 Выработка управляющих воздействий по результатам обработки информации
Ступени loT
1. Подключение устройств
 Устройства
 Подключение устройств
 Обеспечение поддержки подключения
 Встроенная аналитика, Edge Computing
2. Считывание данных с устройств
 Проведение удаленных измерений (телеметрия) с датчиков
 Сбор данных
 Метки данных
 Хранение данных
3. Коммуникации
 Обеспечение доступа
 Передача данных
 Сети
 Облако
4. Анализ данных
 Большие данные
 Анализ данных
 Краевые вычисления (Edge Computing)
 Искусственный интеллект
 Когнитивные вычисления
5. Оценка данных системой
 Аализ данных для последующих действий
 Обработка данных и API (интерфейс прикладного программирования)
 Actionable Intelligence (интеллектуальные решения/действия)
6. Оценка данных человеком
 «Умные» приложения
 Системы бизнес-аналитики
 Отчетность
Цикл управления на основе данных.
 Планирование
 Рефлексия
 Сбор данных
 Анализ данных
 Принятие решений по изменению методологии
Преимущества.
 Отслеживание состояния объектов и процессов в реальном времени
 Интерактивная и прозрачная информация
 Предотвращение сбоев почти в реальном времени
 Уменьшение человеческого фактора
 Оптимизация расходов ресурсов
Использование моделей.
 Сбор данных
 Предварительная обработка данных (препроцессинг)
 Выделение признаков
 Построение модели, валидация модели
 Использование модели
Варианты использования моделей.
 Детектирование аномалий
 Детектирование разладок
 Прогнозирование редких событий
 Прогнозирование характеристик и параметров процессов и объектов
Уровни.
 Умные машины (собирают данные, взаимодействуют, «думают», действуют)
 Отдельные прикладные информационные системы
 Объединяющая система (объединяет отдельные информационные системы)
 Промышленный интернет-вещей использует объединяющую систему
Слои.
 Краевой слой: контрольный домен — контроллеры, сенсоры, проверочные устройства,
приложение и шлюз
 Слой платформ: операционный домен — управление, мониторинг, прогнозы, API, портал;
информационный домен - сервисы и платформы данных и аналитики
 Слой предприятия: домен приложений — логика, правила, API, портал; бизнес-домен -
бизнес-приложения
Два типа анализа.
 Пакетный анализ (исторический) — анализ исторических данных, построение модели за
период
 Потоковый анализ (текущий) — анализ потока данных,оперативная корректировка модели и
реагирование на особенности данных
Типы анализа данных.
 Базовый анализ
 Анализ проблем в данных (пропуск данных, аномалии в данных, некорректные данные)
 Оперативный анализ
 Анализ исторических данных
АРХИТЕКТУРА СИСТЕМ БОЛЬШИХ ДАННЫХ
Проблема полностью инкрементной архитектуры классической базы данных.

 Операционная сложность:
 необходимость выполнения
оперативного уплотнения
 это является интенсивной
операцией
 может привести к полному отказу
кластера.

 Чрезвычайная сложность достижения окончательной согласованности: невозможно

одновременно обеспечить высокую доступность и согласованность при наличии сетевых
разделов (перегородок).
 Устойчивость к человеческим факторам: (не)решается без полного переосмысления
архитектуры
 Полностью инкрементное решение по сравнению с решением с лямбда-архитектурой
Пример: простой запрос. Два вида данных. Просмотры страниц: содержат идентификатор
пользователя, URL-адрес и отметку времени. Эквиваленты: которые содержат два идентификатора
пользователя: указывает, что два идентификатора пользователя относятся к одному и тому же лицу.
Цель: вычислить количество уникальных посетителей URL-адреса за определенный период времени.
Должен быть в курсе всех данных и отвечать с минимальной задержкой (эквиваленты усложняют
реализацию этого запроса): Long UniquesOverTime(String url, int startHour, int endHour). Вариант:
полностью поменять архитектуру системы
Особенности архитектуры для обработки больших данных.
Архитектура для обработки больших данных должна позволять принимать, обрабатывать и
анализировать данные, которые являются слишком объемными или слишком сложными для
традиционных систем баз данных. Время, когда организации начинают использовать большие
данные, зависит от возможностей пользователей и их средств: для некоторых это могут быть сотни
гигабайт данных, а для других — сотни терабайт. Часто термин «Большие данные» связан со
значением, которое можно извлечь из наборов данных с помощью расширенной аналитики, а не
исключительно с размером данных. Хотя в этих случаях они обычно достаточно большие.
Типы рабочей нагрузки систем больших данных.
 пакетная обработка источников неактивных больших данных;
 обработка больших данных в динамике в режиме реального времени;
 интерактивное изучение больших данных;
 прогнозная аналитика и машинное обучение.
Типовые сценарии использования систем больших данных.
 хранение и обработка данных в объемах, слишком больших для традиционной базы данных;
 преобразование неструктурированных данных для анализа и создания отчетов;
 запись, обработка и анализ непривязанных потоков данных в режиме реального времени или с
низкой задержкой.
Лямбда-архитектура.
При работе с очень большими наборами данных выполнение типа запросов, необходимых
клиентам, может занять много времени. Эти запросы нельзя выполнить в режиме реального времени.
Они часто требуют алгоритмов, например, MapReduce, которые работают параллельно по всему
набору данных. Результаты затем сохраняются отдельно от необработанных данных и используются
для выполнения запросов. Недостатком этого подхода является то, что появляется задержка. Если
обработка занимает несколько часов, запрос может возвращать результаты, которые были
актуальными несколько часов назад. В идеале вам следует получить некоторые результаты в режиме
реального времени (возможно, с некоторой потерей точности) и объединить их с результатами
пакетной аналитики.
Лямбда-архитектура, впервые предложенная Натаном Марцом (Nathan Marz), устраняет эту
проблему путем создания двух путей для потока данных. Все данные, поступающие в систему,
проходят через эти два пути:
 На пакетном уровне (холодный путь) все входящие данные хранятся в необработанном виде и
выполняется их пакетная обработка. Результаты этой обработки сохраняются в пакетном
представлении. Пакетный уровень (Batch Layer) предоставляет результаты для уровня
обслуживания, который индексирует пакетное представление для эффективного выполнения
запросов.
 На уровне ускорения (критический путь) данные анализируются в режиме реального времени.
Этот уровень обеспечивает минимальную задержку, хотя и за счет точности. Уровень
ускорения (Speed Layer) обновляет уровень обслуживания, отправляя добавочные обновления
(с учетом последних данных).
Лямбда-архитектура: критический и холодный путь.
Данные, которые поступают в критический путь, ограничены требованиями к задержке,
наложенными уровнем ускорения, чтобы их можно было обработать как можно быстрее. Часто в
этом случае следует обеспечить компромисс: некоторая потеря точности в пользу получения готовых
данных как можно быстрее. Например, рассмотрите сценарий Интернета вещей, где большое
количество датчиков температуры отправляют данные телеметрии. Уровень ускорения можно
использовать для обработки скользящего временного окна входных данных.
На данные, которые поступают в холодный путь, с другой стороны, не распространяются те же
требования к низкой задержке. Это обеспечивает высокую точность вычисления больших наборов
данных, однако занимает много времени.
В результате критический и холодный пути объединяются в клиентском приложении: аналитики.
Если клиент должен отображать результаты своевременно, но потенциально с менее точными
данными в режиме реального времени, он будет получать результаты из критического пути. В
противном случае он будет выбирать результаты из холодного пути, чтобы отображать более точные
данные, однако не так своевременно. Другими словами, критический путь содержит данные за
относительно небольшой промежуток времени, после которого результаты можно обновить более
точными данными из критического пути.
Лямбда-архитектура: холодный путь.
Необработанные данные, которые хранятся на пакетном уровне, являются неизменяемыми.
Входящие данные всегда добавляются к имеющимся. Предыдущие данные никогда не
перезаписываются. Любые изменения значения определенных данных хранятся в виде новой записи
о событии с меткой времени. Это позволяет в любой момент времени выполнить повторное
вычисление в журнале собранных данных. Возможность повторного вычисления пакетных
представлений из исходных необработанных данных очень важна, так как это позволяет создавать
новые представления по мере развития системы.
Каппа-архитектура.
Недостатком лямбда-архитектуры является ее сложность. Логика обработки применяется в двух
различных местах, в холодном и критическом путях, с использованием различных структур. Это
приводит к дублированию логики вычислений и усложняет управление архитектурой для обоих
путей. Каппа-архитектура была предложена Джеем Крепсом (Jay Kreps) в качестве альтернативы
лямбда-архитектуре. Она имеет такие же основные цели, что и лямбда-архитектура, но при этом есть
важное различие: все данные проходят через один путь с использованием системы обработки
потоковых данных.
Имеется некоторое сходство с пакетным уровнем лямбда-архитектуры. Оно заключается в том,
что данные являются неизменяемыми. Кроме того, собираются все данные, а не только их
подмножество. Данные принимаются как поток событий в распределенном и отказоустойчивом
едином журнале. Эти события упорядочиваются, и текущее состояние события изменяется только
при добавлении нового события. Аналогично уровню ускорения лямбда-архитектуры вся обработка
событий выполняется во входном потоке и сохраняется как представление в режиме реального
времени. Если необходимо повторно вычислить весь набор данных (аналогично тому, что
происходит на пакетном уровне в лямбда-архитектуре), просто воспроизведите поток. Чтобы
завершить вычисление вовремя, обычно используется параллелизм.
Интернет вещей.
С практической точки зрения Интернет вещей представляет все устройства, подключенные к
Интернету. Сюда входят персональные компьютеры, мобильный телефон, умные часы, умный
термостат, умный холодильник, подключенный автомобиль, импланты для кардиомониторинга и все
остальные устройства, которые подключены к Интернету и отправляют или получают данные.
Количество подключенных устройств растет каждый день, как и объем собираемых с них данных.
Часто эти данные собираются в среды с большим количеством ограничений, а иногда и с высокой
задержкой..
В других случаях данные отправляются из сред с малой задержкой тысячами или миллионами
устройств, требуя возможности быстро принимать данные и обрабатывать их соответствующим
образом. Таким образом, чтобы работать с этими ограничениями и уникальными требованиями,
требуется продуманное планирование. Управляемые событиями архитектуры это один из
подходящих вариантов при работе с решениями Интернета вещей.
Облачный и полевой шлюз.
 Облачный шлюз (Cloud Gateway) принимает события от устройств на границе облака,
используя надежную службу сообщений с низкой задержкой. Устройства могут отправлять
события в облачный шлюз напрямую или через полевой шлюз.
 Полевой шлюз (Field Gateway) — это специальное устройство или программа, обычно
размещаемые рядом с устройствами, которые получают события и пересылают их в облачный
шлюз. Полевой шлюз может выполнять некоторую предварительную обработку событий,
собираемых с устройств, например, фильтрацию, статистическую обработку или
преобразование протоколов.
Обработчик потока (stream processing).
Полученные события проходят через один или несколько обработчиков потока, которые передают
данные в другие системы (например, хранилище данных) или выполняют аналитическую или другую
обработку. Примеры типичных процессов обработки:
 Сохранение данных о событиях в "холодное" хранилище для архивации или пакетной
аналитики.
 Аналитика критического пути, то есть анализ потока событий почти в режиме реального
времени для обнаружения аномалий, выявления закономерностей в скользящих диапазонах
времени или создания оповещений при выполнении определенных условий в потоке.
 Обработка специальных типов сообщений, не относящихся к телеметрии, например
уведомлений и тревожных сигналов.
 Машинное обучение.
Другие компоненты Интернета вещей.
Компоненты системы Интернета вещей, не связанные напрямую с потоковой передачей событий
(включены в схему для полноты представления):
 Реестр устройств (device registry) — это база данных о подготовленных устройствах, которая
содержит идентификаторы устройств и некоторые метаданные, например расположение.
 API подготовки (provisioning API) — это общий внешний интерфейс для подготовки и
регистрации новых устройств.
 В некоторых решениях Интернета вещей допускается отправка управляющих сообщений
(command and control messages) на устройства.
СОСТАВЛЯЮЩИЕ АРХИТЕКТУР СИСТЕМ БОЛЬШИХ ДАННЫХ

 Источники данных (Data sources)

Все решения для обработки больших данных начинаются с одного или нескольких источников
данных. Примеры источников данных:
 Хранилища данных приложений, например реляционные базы данных.
 Статические файлы, которые создаются приложениями, например файлы журнала веб-
сервера.
 Источники данных с передачей в режиме реального времени, например устройства Интернета
вещей.
 Хранилище данных (Data storage)
Данные для пакетной обработки обычно хранятся в распределенном хранилище файлов, где могут
содержаться значительные объемы больших файлов в различных форматах. Этот тип хранилища
часто называют озером данных. В системах Microsoft такое хранилище можно реализовать с
помощью Azure Data Lake Store или контейнеров больших двоичных объектов в службе хранилища
Azure.
 Пакетная обработка (Batch processing)
Так как наборы данных очень велики, часто в решении обрабатываются длительные пакетные
задания. Для них выполняется фильтрация, статистическая обработка и другие процессы подготовки
данных к анализу. Обычно в эти задания входит чтение исходных файлов, их обработка и запись
выходных данных в новые файлы.
Варианты компании Microsoft: выполнение заданий U-SQL в Azure Data Lake Analytics,
использование пользовательских заданий Hive, Pig или Map/Reduce в кластере HDInsight Hadoop и
применение программ Java, Scala или Python в кластере HDInsight Spark.
 Прием сообщений в реальном времени (Real-time message ingestion)
Если решение содержит источники в режиме реального времени, в архитектуре должен быть
предусмотрен способ сбора и сохранения сообщений в режиме реального времени для потоковой
обработки. Это может быть простое хранилище данных с папкой, в которую входящие сообщения
помещаются для обработки. Но для приема сообщений многим решениям требуется хранилище,
которое можно использовать в качестве буфера. Такое хранилище должно поддерживать обработку с
горизонтальным масштабированием, надежную доставку и другую семантику очереди сообщений.
Эта часть архитектуры потоковой передачи часто называется потоковой буферизацией.
Варианты Microsoft: Центры событий Azure, Центр Интернета вещей и Kafka.
 Потоковая обработка (Stream processing)
Сохранив сообщения, поступающие в режиме реального времени, система выполняет для них
фильтрацию, статистическую обработку и другие процессы подготовки данных к анализу. Затем
обработанные потоковые данные записываются в выходной приемник.
Решения от Microsoft: Azure Stream Analytics предоставляет управляемую службу потоковой
обработки на основе постоянного выполнения запросов SQL для непривязанных потоков. Кроме
того, для потоковой передачи можно использовать технологии Apache с открытым кодом, например
Storm и Spark Streaming в кластере HDInsight.
 Хранилище аналитических данных (Analytical datastore)
Во многих решениях для обработки больших данных данные подготавливаются к анализу. Затем
обработанные данные структурируются в соответствии с форматом запросов для средств аналитики.
Хранилище аналитических данных, используемое для обработки таких запросов, может быть
реляционной базой данных типа Kimball, как можно увидеть в большинстве традиционных решений
бизнес-аналитики (BI). Кроме того, данные можно представить с помощью технологии NoSQL с
низкой задержкой, такой как HBase или интерактивная база данных Hive, которая предоставляет
абстракцию метаданных для файлов данных в распределенном хранилище.
Решения от Microsoft.
 Azure Synapse Analytics — это управляемая служба для хранения больших объемов данных в
облаке.
 HDInsight поддерживает Interactive Hive, Hbase и Spark SQL, которые также можно
использовать, чтобы предоставлять данные для анализа.
 Анализ и создание отчетов (Analytics and Reporting)
Большинство решений по обработке больших данных предназначены для анализа и составления
отчетов, что позволяет получить важную информацию.
Решения от Microsoft:
 Чтобы расширить возможности анализа данных, можно включить в архитектуру слой
моделирования, например модель таблицы или многомерного куба OLAP в Azure Analysis
Services.
 Также можно включить поддержку самостоятельной бизнес-аналитики с использованием
технологий моделирования и визуализации в Microsoft Power BI или Microsoft Excel.
Анализ и создание отчетов также может выполняться путем интерактивного изучения данных
специалистами по их анализу и обработке. Для таких сценариев многие службы Azure поддерживают
функции аналитического блокнота, например Jupyter, который позволяет пользователям применять
свои навыки работы с Python или R. Для крупномасштабного изучения данных можно использовать
Microsoft R Server (отдельно или со Spark).
 Оркестрация (Orchestration)
Большинство решений для обработки больших данных состоят из повторяющихся рабочих
процессов, во время которых преобразуются исходные данные, данные перемещаются между
несколькими источниками и приемниками, обработанные данные загружаются в хранилища
аналитических данных либо же результаты передаются непосредственно в отчет или на панель
мониторинга.
Решения от Microsoft. Фабрика данных Azure, Apache Oozie и Sqoop.
ФОРМАТЫ ИНТЕРФЕЙСОВ СООБЩЕНИЙ
API.
API (Application Programing Interface — «программный интерфейс приложения») — интерфейс,
позволяющий различным программным компонентам взаимодействовать друг с другом. Некоторые
варианты:
 Интеграция в среду программирования.
 Web-API (Web-службы). В специальном назначении, например Google Maps, Яндекс Карты: с
помощью API можно применить услугу указания местоположения на карте через интерфейс,
предоставляемый системной.
 API операционной системы это интерфейс, посредством которого приложения получают
доступ к услугам ОС. Примером является Windows API, в котором для каждой службы ОС
есть доступная приложениям процедура.
Клиент-сервер.
Вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены
между поставщиками услуг, называемыми серверами, и заказчиками услуг, называемыми клиентами.
Фактически клиент и сервер — это программное обеспечение. Обычно эти программы
расположены на разных вычислительных машинах и взаимодействуют между собой через
вычислительную сеть посредством сетевых протоколов, но они могут быть расположены также и на
одной машине.
REST.
REST (сокращение от англ. Representational State Transfer — «передача состояния представления»)
— архитектурный стиль взаимодействия компонентов распределённого приложения в сети. В сети
Интернет вызов удалённой процедуры может представлять собой обычный HTTP-запрос (обычно
«GET» или «POST»; такой запрос называют «REST-запрос»), а необходимые данные передаются в
качестве параметров запроса. Свойства: производительность, масштабируемость.
Свойства архитектуры, основанной на REST.
 Производительность — взаимодействие компонентов системы может являться
доминирующим фактором производительности и эффективности сети с точки зрения
пользователя.
 Масштабируемость для обеспечения большого числа компонентов и взаимодействий
компонентов.
Рой Филдинг — один из главных авторов спецификации протокола HTTP, описывает влияние
архитектуры REST на масштабируемость следующим образом:
 Простота унифицированного интерфейса;
 Открытость компонентов к возможным изменениям для удовлетворения изменяющихся
потребностей (даже при работающем приложении);
 Прозрачность связей между компонентами системы для сервисных служб;
 Переносимость компонентов системы путем перемещения программного кода вместе с
данными;
 Надёжность, выражающаяся в устойчивости к отказам на уровне системы при наличии
отказов отдельных компонентов, соединений или данных.
REST – требования.
 Модель клиент-сервер
 Отсутствие состояния - в период между запросами клиента никакая информация о состоянии
клиента на сервере не хранится
 Кэширование (в установленных случаях вместо реального ответа сервиса предоставляется
предыдущая информация из кэша)
 Единообразие (унифицирование) интерфейса (базовое требование REST, включает
однозначность команд и данных)
 Слои – может быть несколько слоев сервисов (один включает другой), нет информации с
каким слоем идет взаимодействие
 Код по требованию (необязательное ограничение) - может позволить расширить
функциональность клиента за счёт загрузки кода с сервера в виде апплетов или скриптов.
Restful.
Веб-службы RESTful поддерживают полное разделение клиента и сервера. Они упрощают и
разделяют различные компоненты веб-сервера, чтобы каждая часть могла развиваться независимо.
Изменения платформы или технологии в серверном приложении не влияют на клиентское
приложение. Возможность разделения функций приложения на уровни еще больше повышает
гибкость. Например, разработчики могут вносить изменения в уровень базы данных, не переписывая
логику приложения.
Запросы RESTful (пример с HTTP).
 Уникальный идентификатор ресурса (у каждого ресурса уникальный идентификатор
ресурса - универсального указателя ресурсов (URL).
 Метод: GET, POST, PUT, DELETE
 Заголовки HTTP
 Данные
 Параметры, например:
 Параметры пути, которые определяют детали URL.
 Параметры запроса, которые запрашивают дополнительную информацию о ресурсе.
 Параметры cookie, которые быстро аутентифицируют клиентов.
Ответы RESTful (пример с HTTP).
 Строка состояния (в стартовой строке HTTP) - трехзначный код состояния, который
сообщает об успешном или неудачном выполнении запроса. Например, коды 2XX указывают
на успешное выполнение, а коды 4XX и 5XX — на ошибки. Коды 3XX указывают на
перенаправление URL.
 Заголовки
 Текст сообщения (например в формате XML или JSON)
 Ответ также содержит заголовки или метаданные об ответе. Они дают более подробный
контекст ответа и включают такую информацию, как название сервера, кодировка, дата и тип
контента.
XML (eXtensible Markup Language).
Рекомендован Консорциумом Всемирной паутины (W3C). Спецификация XML описывает XML-
документы и частично описывает поведение XML-процессоров (программ, читающих XML-
документы и обеспечивающих доступ к их содержимому).
XML разрабатывался как язык с простым формальным синтаксисом, удобный для создания и
обработки документов как программами, так и человеком, с акцентом на использование в Интернете.
Язык называется расширяемым, поскольку он не фиксирует разметку, используемую в
документах: разработчик волен создать разметку в соответствии с потребностями к конкретной
области, будучи ограниченным лишь синтаксическими правилами языка. Используется в SOAP
(всегда) и REST-запросах (реже);
XML и HTML.
 В формате HTML
 Теги определяются в спецификации языка (т.е. используются готовые)
 Теги определяют оформление данных — расположение заголовков, начало абзаца и т. д.
 Ошибки в коде могут быть некритичны (интерпретатор их просто пропускает)
 Для задания формата вывода используются каскадные таблицы стилей (CSS)
 В формате XML
 Теги не определены в спецификации языка (т.е. мы сами оперативно задаем теги)
 Теги определяют структуру и смысл данных — то, чем они являются.
 Ошибки в коде критичны (данные могут быть не определены корректно)
 Для задания формата вывода используются CSS и XSLT (Extensible Stylesheet Language
Transformations) – предполагает фильтрацию данных
JSON (JavaScript Object Notation).
Текстовый формат обмена данными. За счёт своей лаконичности по сравнению с XML формат
JSON может быть более подходящим для сериализации (перевода структуры данных в битовую
последовательность) сложных структур. Представляет собой (в закодированном виде) одну из двух
структур:
 Набор пар «ключ: значение». Ключом может быть только строка, значением — любая форма
(повторяющиеся имена ключей допустимы, но не рекомендуются стандартом).
 Упорядоченный набор значений.
SOAP (Simple Object Access Protocol).
Простой протокол доступа к объектам— протокол обмена структурированными сообщениями в
распределённой вычислительной среде. Альтернатива RESTful (REST для веб-служб).
Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC,
Remote Procedure Call). Сейчас протокол используется для обмена произвольными сообщениями в
формате XML, а не только для вызова процедур. SOAP является расширением протокола XML-RPC.
SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и
др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые
должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP. SOAP является
одним из стандартов, на которых базируются технологии веб-служб.
Структура SOAP.
 Envelope — корневой элемент, который определяет сообщение и пространство имен,
использованное в документе.
 Header — содержит атрибуты сообщения, например: информация о безопасности или о
сетевой маршрутизации.
 Body — содержит сообщение, которым обмениваются приложения.
 Fault — необязательный элемент, который предоставляет информацию об ошибках, которые
произошли при обработке сообщений.
MIDDLEWARE
Технологии Middleware.
 Вызов удалённых процедур (Remote Procedure Call — RPC)
 Сервисы обработки сообщений (MOM — message-oriented middleware)
 Монитор обработки транзакций TPM (Transaction processing Monitor)
Вызов удалённых процедур (Remote Procedure Call — RPC).
Идея состоит в расширении хорошо известного и понятного механизма передачи управления и
данных внутри программы, выполняющейся на одной машине, на передачу управления и данных
через сеть. Средства удалённого вызова процедур предназначены для облегчения организации
распределённых вычислений и создания распределенных клиент-серверных информационных
систем.
Наибольшая эффективность использования RPC достигается в тех приложениях, в которых
существует интерактивная связь между удалёнными компонентами с небольшим временем ответов и
относительно малым количеством передаваемых данных. Такие приложения называются RPC-
ориентированными.
Вызов удалённых процедур: свойства.
 Симметричность, то есть одна из взаимодействующих сторон является инициатором;
 Синхронность, то есть выполнение вызывающей процедуры приостанавливается с момента
выдачи запроса и возобновляется только после возврата из вызываемой процедуры.
Вызов удалённых процедур: особенности.
 Вызывающая и вызываемая процедуры выполняются на разных машинах, имеют разные
адресные пространства и форматы. Это создает проблемы при передаче параметров и
результатов, особенно если машины находятся под управлением различных операционных
систем или имеют различную архитектуру
 Неоднородность языков программирования и операционных сред. Структуры данных и
структуры вызова процедур, поддерживаемые в каком-либо одном языке программирования,
могут не поддерживаться в других языках.
 В отличие от локального вызова удалённый вызов процедур обязательно использует
транспортный уровень сетевой архитектуры (например, TCP), однако это остается скрытым от
разработчика.
 В реализации RPC участвуют как минимум два процесса — по одному в каждой машине.
 В случае, если один из них аварийно завершится, оставшийся процесс должен корректно
обработать ситуацию.
Сервисы обработки сообщений (MOM — message-oriented middleware).
Они как правило асинхронные. Взаимодействие между клиентом и сервером основано на обмене
сообщениями.
Сообщения — это текстовые блоки, состоящие из управляющих команд и передаваемых данных.
Сервисы обработки сообщений: подписка/публикация (publish&subscribe).
Одно приложение публикует информацию в сети, а другие подписываются на эту публикацию для
получения необходимых данных. Взаимодействующие таким способом приложения полностью
независимы друг от друга, что представляет возможности динамической реконфигурации всей
распределенной системы.
Сервисы обработки сообщений: варианты.
 надежная доставка сообщений (reliable message delivery)
 гарантированная доставка сообщений (guaranteed message delivery)
 застрахованная доставка сообщений (assured message delivery)
Монитор обработки транзакций TPM (Transaction processing Monitor).
Первоначально основной задачей мониторов обработки транзакций (ТР-мониторов) в среде
клиент-сервер было сокращение числа соединений клиентских систем с БД.
При непосредственном обращении клиента к серверу базы данных для каждого клиента
устанавливается соединение с СУБД, которое порождает запуск отдельного процесса в рамках ОС.
ТР-мониторы брали на себя роль концентратора таких соединений, становясь посредником между
клиентом и сервером базы данных. Постепенно, с развитием трёхзвенной архитектуры клиент-сервер
функции ТР-мониторов расширились, и они превратились в платформу для транзакционных
приложений в распределённой среде с множеством БД под различными СУБД.
ТР-мониторы представляют одну из самых сложных и многофункциональных технологий в мире
промежуточного ПО. Основное их назначение – автоматизированная поддержка приложений,
оформленных в виде последовательности транзакций.
Каждая транзакция – законченный блок обращений к ресурсу (как правило, базе данных) и
некоторых действий над ним.
TPM: четыре условия/
 Атомарность
Операции транзакции образуют неразделимый, атомарный блок с определённым началом и
концом. Этот блок либо выполняется от начала до конца, либо не выполняется вообще. Если в
процессе выполнения транзакции произошёл сбой, происходит откат (возврат) к исходному
состоянию.
 Согласованность
По завершении транзакции все задействованные ресурсы находятся в согласованном состоянии
 Изолированность
Одновременный доступ транзакций различных приложений к разделяемым ресурсам
координируется таким образом, чтобы эти транзакции не влияли друг на друга
 Долговременность
Долговременность – все изменения данных (ресурсов), осуществлённые в процессе выполнения
транзакции, не могут быть потеряны.
RABBITMQ
RabbitMQ — программный брокер сообщений на основе стандарта AMQP — тиражируемое
связующее программное обеспечение, ориентированное на обработку сообщений.
AMQP (Advanced Message Queuing Protocol).
Открытый протокол для передачи сообщений между компонентами системы.
Отдельные подсистемы (или независимые приложения) могут обмениваться произвольным
образом сообщениями через AMQP-брокер, который осуществляет маршрутизацию, возможно
гарантирует доставку, распределение потоков данных, подписку на нужные типы сообщений.
 AMQP основан на трёх понятиях.
 Сообщение (message) — единица передаваемых данных, основная его часть (содержание)
никак не интерпретируется сервером, к сообщению могут быть присоединены
структурированные заголовки.
 Точка обмена (exchange) — в неё отправляются сообщения. Точка обмена распределяет
сообщения в одну или несколько очередей. При этом в точке обмена сообщения не
хранятся. Есть три типа точки обмена:
 fanout — сообщение передаётся во все прицепленные к ней очереди;
 direct — сообщение передаётся в очередь с именем, совпадающим с ключом маршрутизации
(routing key) (ключ маршрутизации указывается при отправке сообщения);
 topic — нечто среднее между fanout и direct, сообщение передаётся в очереди, для которых
совпадает маска на ключ маршрутизации, например, app.notification.sms.# — в очередь будут
доставлены все сообщения, отправленные с ключами, начинающимися с app.notification.sms.
 Очередь (queue) — здесь хранятся сообщения до тех пор, пока не будут забраны клиентом.
Клиент всегда забирает сообщения из одной или нескольких очередей.
Основные понятия RabbitMQ.
 Producer (поставщик) ‒ программа, отправляющая сообщения.
 Consumer (подписчик) ‒ программа, принимающая сообщения. Обычно подписчик находится
в состоянии ожидания сообщений.
 Queue (очередь) ‒ имя «почтового ящика». Существует внутри RabbitMQ. Хотя сообщения
проходят через RabbitMQ и приложения, хранятся они только в очередях. Очередь не имеет
ограничений на количество сообщений, она может принять сколь угодно большое их
количество ‒ можно считать ее бесконечным буфером. Любое количество поставщиков может
отправлять сообщения в одну очередь, также любое количество подписчиков может получать
сообщения из одной очереди.
Отправление сообщения.
import pika
connection = pika.BlockingConnection(pika.ConnectionParameters(host='localhost'))
channel = connection.channel()
channel.queue_declare(queue='hello')
channel.basic_publish(exchange='', routing_key='hello', body='Hello World!')
print " [x] Sent 'Hello World!'"
connection.close()
Получение сообщения.
import pika
connection = pika.BlockingConnection(pika.ConnectionParameters(host='localhost'))
channel = connection.channel()
channel.queue_declare(queue='hello')
print ' [*] Waiting for messages. To exit press CTRL+C'
def callback(ch, method, properties, body):
print " [x] Received %r" % (body,)
channel.basic_consume(callback, queue='hello', no_ack=True)
channel.start_consuming()
Exchange (точка доступа).
 Точка доступа выполняет две функции:
 получает сообщения от поставщика;
 отправляет эти сообщения в очередь.
Точка доступа должна определить, что делать с поступившими сообщениями:
 отправить сообщение в конкретную очередь, либо в несколько очередей,
 либо не отправлять никому и удалить его.
Типы точек доступа.
 Direct (прямые) работают по принципу привязки по ключу (очередь сообщений, message
queue). У сообщения есть routing key (ключ маршрутизации), а у очереди — binding key
(связующий ключ). Сообщения доставляются только в ту очередь, с которой полностью
совпадают ключи
 Topic (обратные) проверяют специальные символы между ключом сообщения и шаблоном
(routing pattern), который участвует в привязке очереди.
* (star) — одно слово.
# (hash) от нуля и более слов.
 Headers (заголовочные) для маршрутизации используют атрибуты в заголовках сообщений.
Это удобно, когда имеется много критериев для сортировки сообщений. Условием может быть
наличие всех требуемых заголовков или хотя бы одному из них.
 Fanout (множественные) копируют все сообщения, которые поступают к нему во все очереди,
которые ему доступны (типичная публикация-подписка, publish-subscribe). Отправляют
сообщения во все очереди, которые созданы в этой точке.
Direct -> Fanout.
Eсли в direct exchange создать несколько разных очередей с одинаковым ключом, то они будут
работать по принципу fanout: сообщения, у которых routing key будет совпадать, будут приходить во
все очереди с таким же binding key.
Точка доступа: по умолчанию (default).
Предварительно объявленный прямой обмен без имени, определен пустой строкой «». Сообщение
будет доставлено в очередь с именем, равным ключу маршрутизации сообщения. Каждая очередь
автоматически привязывается к точке доступа по умолчанию с ключом маршрутизации, который
совпадает с именем очереди.
Жизненный цикл.
Поставщик создает сообщение и отправляет его брокеру сообщений. Этот процесс называется
публикацией (publish). Сообщение попадает в точку доступа, в которую его отправили. Дальше
происходит привязка по routing key определенным типом точки доступа способом.
Сообщение попадает в очередь, где остается дожидаться взаимодействия с подписчиком.
Подписчик получает и обрабатывает сообщение из очереди. Этот процесс называется приемом
(consume).
APACHE KAFKA
Apache Kafka — распределённый программный брокер сообщений, проект с открытым исходным
кодом, разрабатываемый в рамках фонда Apache. Распределенный горизонтально масштабируемый
отказоустойчивый журнал коммитов.
Apache Kafka: message-oriented middleware/
MOM - подпрограммное обеспечение, ориентированное на обмен сообщениями в распределённом
окружении. Прежде всего предназначено для реализации отложенного обмена сообщениями.
Основные представители: брокеры сообщений, службы обработки очередей, мониторы транзакций.
Распределенность.
В сегментированном виде система работает сразу на множестве машин, образующих цельный
кластер; поэтому для конечного пользователя они выглядят как единый узел. Распределенность
Kafka заключается в том, что хранение, получение и рассылка сообщений у него организовано на
разных узлах (так называемых «брокерах»). Важнейшие плюсы такого подхода – высокодоступность
и отказоустойчивость.
Горизонтальная масштабируемость.
 Вертикальное масштабирование – на машину навешиваются дополнительные ресурсы.
Недостатки:
 Есть определенные пределы, связанные с возможностями оборудования. Бесконечно
наращиваться нельзя.
 Такая работа обычно связана с простоями, а большие компании не могут позволить себе
простоев.
Решает ровно ту же проблему, просто мы подключаем к делу все больше машин. При добавлении
новой машины никаких простоев не происходит, при этом, количество машин, которые можно
добавить в кластер, ничем не ограничено. Это сложнее организовать, но после определенного порога
горизонтальное масштабирование становится гораздо дешевле вертикального.
Отказоустойчивость.
Для нераспределенных систем характерно наличие так называемой единой точки отказа. Если
единственный сервер вашей базы данных по какой-то причине откажет, работа всей системы
остановиться. Распределенные системы проектируются таким образом, чтобы их конфигурацию
можно было корректировать, подстраиваясь под отказы. Кластер Kafka из пяти узлов остается
работоспособным, даже если два узла откажут (но приходится частично жертвовать
производительностью).
Основные понятия.
 Producer (генератор) – приложение, которое отправляет сообщения (данные) через систему
Kafka.
 Consumer (потребитель) – приложение, которое получает сообщения (данные) через систему
Kafka.
 Broker – Сервер Kafka – брокер.
 Cluster (кластер) - группа компьютеров, распределяющая нагрузку.
 Topic – уникальное имя потока (stream).
 Partitions – части Topic.
 Offset – внутр. id для сообщений в partition в порядке поступления.
 Consumer groups – группа потребителей, образующая единый логический блок.
Глобальная идентификация сообщений.
 Имя topic
 Номер partition
 Offset
Принцип «тупой брокер – умный потребитель».
Kafka не отслеживает, какие записи считываются потребителем и после этого удаляются, а просто
хранит их в течение заданного периода времени (например, суток), либо до тех пор, пока не будет
достигнут некоторый порог.
Потребители сами опрашивают Kafka, не появилось ли у него новых сообщений, и указывают,
какие записи им нужно прочесть. Таким образом, они могут увеличивать или уменьшать смещение,
переходя к нужной записи; при этом события могут переигрываться или повторно обрабатываться.
Долговременное хранение на диске (а не в ОЗУ).
В Kafka есть протокол, объединяющий сообщения в группы. Поэтому при сетевых запросах
сообщения складываются в группы, что позволяет снизить сетевые издержки. Сервер, в свою
очередь, сохраняет партию сообщений в одно действие, после чего потребители могут сразу
выбирать большие линейные последовательности таких сообщений.
Линейные операции считывания и записи на диск происходят быстро. Так как объем блоков
большой — они считываются быстрее многих мелких блоков. Линейные операции сильно
оптимизируются операционной системой путем:
 опережающего чтения (заблаговременно выбираются крупные группы блоков)
 запаздывающей записи (небольшие логические операции записи объединяются в крупные
физические операции записи).
 Современные ОС кэшируют диск в свободной оперативной памяти. Такая техника называется
страничный кэш. Поскольку Kafka сохраняет сообщения в стандартизированном двоичном формате,
который не изменяется на протяжении всей цепочки (генератор->брокер->потребитель), здесь
уместна оптимизация нулевого копирования. В таком случае ОС копирует данные из страничного
кэша прямо на сокет, практически обходя стороной приложение-брокер, относящееся к Kafka.
Репликация данных.
Данные с сегмента реплицируются на множестве брокеров, чтобы данные сохранились, если один
из брокеров откажет. Можно сконфигурировать гарантии, обеспечивающие, что любое сообщение,
которое будет успешно опубликовано, не потеряется. Когда есть возможность изменить
коэффициент репликации, можно частично пожертвовать производительностью ради повышенной
защиты и долговечности данных.
Один из брокеров всегда “владеет” секцией: этот брокер — именно тот, на котором приложения
выполняют операции считывания и записи в секцию. Этот брокер называется «ведущим секции». Он
реплицирует получаемые данные на N других брокеров, так называемых ведомыми. На ведомых
также хранятся данные, и любой из них может быть выбран в качестве ведущего, если актуальный
ведущий откажет.
Zookeeper.
Распределенное хранилище ключей и значений. Оно сильно оптимизировано для считывания, но
записи в нем происходят медленнее. Zookeeper исключительно отказоустойчив (как и должно быть),
поскольку Kafka сильно от него зависит.
Zookeeper: использование.
Чаще всего Zookeeper применяется для хранения метаданных и обработки механизмов
кластеризации (пульс, распределенные операции обновления/конфигурации, т.д.). Клиенты этого
сервиса (брокеры Kafka) могут на него подписываться – и будут получать информацию о любых
изменениях, которые могут произойти. Именно так брокеры узнают, когда ведущий в секции
меняется.
Zookeeper: используется для хранения метаданных.
Смещение групп потребителей в рамках секции (хотя, современные клиенты хранят смещения в
отдельной теме Kafka)
ACL (списки контроля доступа) — используются для ограничения доступа /авторизации
Квоты генераторов и потребителей — максимальные предельные количества сообщений в
секунду. Ведущие кластеры секций и уровень их работоспособности
Потоковая обработка.
Поддерживается возможность временного хранения данных для последующей пакетной
обработки. Одной из особенностей реализации инструмента является применение техники, сходной с
журналами транзакций, используемыми в системах управления базами данных.
KAFKA STREAMS
Клиентская библиотека для разработки потоковых приложений Big Data, которые работают с
данными, хранящимися в топиках Apache Kafka. Предоставляет мощный и гибкий API-интерфейс со
всеми преимуществами платформы Kafka (масштабируемость, надежность, минимальную задержку,
механизмы аналитических запросов), позволяя разработчику писать код в локальном режиме (вне
кластера).
Kafka Streams API, доступный в виде Java-библиотеки, представляет собой самый простой способ
писать критически важные приложения и микросервисы реального времени со всеми
преимуществами кластерной технологии на стороне сервера Kafka.
Базовые понятия.
 Топик (Topic) – неограниченный, постоянно обновляемый набор данных или упорядоченная,
воспроизводимая и отказоустойчивая последовательность неизменяемых записей, каждая из
которых определяется как пара «ключ-значение» (key-value), где ключи и значения — это
обычные массивы байтов (<byte[], byte[]>).
 Поток (Stream) – полная история всех случившихся событий, топик со схемой данных
(schema), где ключи и значения уже не байтовые массивы, а имеют определённые типы.
 Таблица (Table) – агрегация событий на текущий момент, агрегированный поток данных.
Потоковая обработка.
Поток можно рассматривать как таблицу и наоборот.
Приложение потоковой обработки определяет свою вычислительную логику через одну или
несколько топологий процессоров — графов из потоковых процессоров (узлов), которые соединены
потоками (ребрами).
Потоковый процессор представляет собой этап обработки для преобразования данных в потоках
путем однократного приема входной записи и передачи обратно в топик Kafka или внешнюю
систему.
Каждый потоковый раздел представляет собой полностью упорядоченную последовательность
записей данных и сопоставляется с разделом топика Kafka, а запись данных в потоке – с сообщением
в этом топике. Ключи записей данных определяют разделение данных в Kafka и в Kafka Streams,
задавая, как данные направляются в определенные разделы внутри топиков.
Масштабирование за счет разделения задач.
Топология обработчика приложения масштабируется за счет разделения на несколько задач. Kafka
Streams создает фиксированное количество задач на основе разделов входного потока для
приложения, назначая каждой задаче список разделов из входных потоков (топиков Kafka).
Назначение разделов задачам никогда не меняется, поэтому каждая задача представляет собой
фиксированную единицу параллелизма приложения. Затем задачи могут создавать экземпляры своей
собственной топологии обработчика на основе назначенных разделов, поддерживая буфер для
каждого из назначенных разделов и обрабатывая оттуда по одному сообщению. Таким образом, все
потоковые задачи автоматически обрабатываются независимо и параллельно.
Параллельные потоковые задачи.
Максимальный параллелизм приложения ограничен максимальным количеством потоковых задач,
т.е. числом разделов входного топика, откуда считываются данные. Например, если входной топик
имеет 5 разделов, можно запустить до 5 экземпляров приложений, которые будут совместно
обрабатывать данные. В случае запуска большего количества экземпляров приложения, «лишние»
экземпляры будут запускаться, но простаивать, а если один из занятых экземпляров выйдет из строя,
то бездействующий возьмет на себя его работу. Kafka Streams позволяет пользователю настроить
количество потоков, которые библиотека может использовать для распараллеливания обработки в
экземпляре приложения. Каждый поток может независимо выполнять одну или несколько задач со
своей топологией процессора.
Kafka Streams – библиотека приложения потоковой обработки.
Kafka Streams — это не менеджер ресурсов, а библиотека, которая запускается везде, где работает
приложение потоковой обработки.
Несколько экземпляров приложения выполняются на одном узле или распределяются по
нескольким машинам, и задачи могут автоматически распределяться библиотекой для этих
запущенных экземпляров приложения. Назначение разделов задачам никогда не меняется, а в случае
сбоя экземпляра приложения все назначенные ему задачи будут автоматически перезапущены на
других экземплярах, продолжая использовать те же разделы потока.
Kafka Streams: отличительные особенности.
 Высокая производительность, надежность и масштабируемость.
 Одновременная обработка событий с минимальной задержкой в миллисекундах без
использования микро-пакетного подхода.
 Stateful-обработка, включая распределенные соединения и агрегаты.
 Работает с временными окнами с неупорядоченными данными.
 Распределенная обработка и отказоустойчивость с быстрым перезапуском в случае сбоя.
 Возможность повторной обработки, чтобы пересчитать выходные данные при изменении
кода.
 Быстрые развертывания без простоев.
 Наличие декларативного и функционального API высокого уровня в виде удобного DSL
(Domain Specific Language), а также императивного API более низкого уровня абстракции.
 Преимущества использования.
 Барьер входа в эту Big Data технологию довольно низок: разработчик может быстро написать
и запустить небольшую пробную версию на локальной машине.
 Для масштабирования потребуется только запустить дополнительные экземпляры приложения
на нескольких узлах.
 Kafka Streams прозрачно обрабатывает балансировку нагрузки нескольких экземпляров
одного и того же приложения, используя модель параллелизма самой платформы Kafka.
 Простота интеграции в Java-приложения и взаимодействия с любыми DevOps-инструментами
для упаковки, развертывания и эксплуатации программного кода.
 Отсутствие внешних зависимостей от других систем, кроме самой Apache Kafka в качестве
внутреннего уровня обмена сообщениями.
 Использование модели партиционирования Kafka для горизонтального масштабирования
обработки при сохранении строгих гарантий упорядочения смещений в топике.
 Отказоустойчивая поддержка локального состояния, что обеспечивает очень быстрые и
эффективные stateful-операции, в т.ч. оконные соединения и агрегаты.
 Поддержка семантики строго однократной обработки (exactly once) с гарантией, что каждая
запись будет обработана один раз и только один раз, даже в случае сбоя на клиентах Streams
или брокерах Kafka в процессе вычислений.
 Включает необходимые примитивы потоковой обработки, а также высокоуровневый Streams
DSL (Domain Specific Language) и низкоуровневый Processor API.
Недостатки.
 Хотя Kafka Streams предоставляет разработчику мощный и гибкий API, многое скрыто «под
капотом», что затрудняет ювелирную оптимизацию приложений.
 Отсутствие автоматизированных средств рефакторинга кода увеличивает нагрузку на
разработчика;
 Автоматическая генерация внутренних хранилищ для состояний приложения в топиках Kafka,
что может привести к увеличению объема обрабатываемых данных, обеспечивая
отказоустойчивость приложений.
MAPREDUCE (ОБЗОР ТЕХНОЛОГИИ)
MapReduce – это модель распределённых вычислений от компании Google, используемая в
технологиях Big Data для параллельных вычислений над очень большими (до нескольких петабайт)
наборами данных в компьютерных кластерах, и фреймворк для вычисления распределенных задач на
узлах (node) кластера.
 map (отображение) принимает на вход список значений и некую функцию, которую затем
применяет к каждому элементу списка и возвращает новый список;
 reduce (свёртка) — преобразует список к единственному атомарному значению при помощи
заданной функции, которой на каждой итерации передаются новый элемент списка и
промежуточный результат.
Три шага.
 Map – предварительная обработка входных данных в виде большого список значений. При
этом главный узел кластера (master node) получает этот список, делит его на части и передает
рабочим узлам (worker node). Далее каждый рабочий узел применяет функцию Map к
локальным данным и записывает результат в формате «ключ-значение» во временное
хранилище.
 Shuffle, когда рабочие узлы перераспределяют данные на основе ключей, ранее созданных
функцией Map, таким образом, чтобы все данные одного ключа лежали на одном рабочем
узле.
 Reduce – параллельная обработка каждым рабочим узлом каждой группы данных по порядку
следования ключей и «склейка» результатов на master node. Главный узел получает
промежуточные ответы от рабочих узлов и передаёт их на свободные узлы для выполнения
 следующего шага. Получившийся после прохождения всех необходимых шагов результат –
это и есть решение исходной задачи.
Пример: процесс, подсчитывающий, сколько раз различные слова встречаются в наборе
документов.
В следующем коде на Map-шаге каждый документ разбивается на слова, и возвращаются пары, где
ключом является само слово, а значением — «1». Если в документе одно и то же слово встречается
несколько раз, то в результате предварительной обработки этого документа будет столько же этих
пар, сколько раз встретилось это слово.
Сформированные пары отправляются на дальнейшую обработку, система группирует их по ключу
(в данном случае — ключом является само слово) и распределяет по множеству процессоров.
Наборы объектов с одинаковым ключом в группе попадают на вход функции reduce, которая
перерабатывает поток данных, сокращая его объёмы. В данном примере функция reduce просто
складывает вхождения данного слова по всему потоку, и результат — только одна сумма —
отправляется дальше в виде выходных данных.
Map Reduce
// Функция, используемая рабочими нодами // Функция, используемая рабочими нодами
на Map-шаге на Reduce-шаге
// для обработки пар ключ-значение из // для обработки пар ключ-значение,
входного потока полученных на Map-шаге
void map(String name, String document): void reduce(Iterator partialCounts):
// Входные данные: // Входные данные:
// name - название документа // partialCounts - список
// document - содержимое документа группированных промежуточных
for each word w in document: результатов. Количество записей в
EmitIntermediate(w, "1"); partialCounts и есть
// требуемое значение
int result = 0;
for each v in partialCounts:
result += parseInt(v);
Emit(AsString(result));
Преимущества.
 Возможность распределенного выполнения операций предварительной обработки (map) и
свертки (reduce) большого объема данных. При этом функции map работают независимо друг
от друга и могут выполняться параллельно на разных узлах кластера. Отметим, что на
практике количество одновременно исполняемых функций map ограничивается источником
входных данных и числом используемых процессоров. Аналогичным образом множество
узлов производят свертку (reduce) после того, как каждый из них обработал все результаты
функции map с одним конкретным значением ключа.
 Быстрота обработки больших объёмов данных за счет распределения операций по
вышеописанному принципу. В частности, всего за пару часов MapReduce может
отсортировать целый петабайт данных.
 Отказоустойчивость и оперативное восстановления после сбоев: при отказе рабочего узла,
производящего операцию map или reduce, его работа автоматически передается другому
рабочему узлу в случае доступности входных данных для проводимой операции.
Недостатки.
 Предел масштабируемости кластера Apache Hadoop: не более 4K вычислительных узлов и
около 40K параллельных заданий.
 Сильная связанность фреймворка распределенных вычислений и клиентских библиотек,
реализующих распределенный алгоритм.
 Наличие единичных точек отказа и невозможность использования в средах с высокими
требованиями к надежности.
 Проблемы версионной совместимости: необходимость единовременного обновления всех
вычислительных узлов кластера при обновлении платформы Hadoop (установке новой версии
или пакета обновлений).
MapReduce 2.0.
Эти ограничения были устранены в новой версии MapReduce 2.0, выпущенной в 2012 году, за счет
изменений в менеджере ресурсов (ResourceManager) и планировщике-координаторе приложений
ApplicationMaster, а также появления YARN (Yet Another Resource Negotiator).
Этот программный фреймворк выполнения распределенных приложений предоставляет
компоненты и API для разработки распределенных приложений различных типов, обеспечивая
распределение ресурсов в ответ на запросы от выполняемых приложений и ответственность за
отслеживанием статуса их выполнения. В частности, ответственность по управлению ресурсами
кластера лежит на ResourceManager, а по планированию/координации жизненного цикла приложений
– на ApplicationMaster. При этом каждый вычислительный узел разделен на произвольное количество
контейнеров Container, содержащих предопределенное количество ресурсов: CPU, RAM и т.д., за
которыми наблюдает менеджер узла (NodeManager).
Недостатки, которые не удалось устранить MapReduce 2.0 (обусловленные архитектурой).
 Недостаточно высокая производительность – классическая технология, в частности,
реализованная в ядре Apache Hadoop, обрабатывает данные ациклично в пакетном режиме.
При этом функции Reduce не запустятся до завершения всех процессов Map. Все операции
проходят по циклу чтение-запись с жесткого диска, что влечет задержки (latency) в обработке
информации.
 Ограниченность применения – продолжая вышеотмеченный недостаток, высокие задержки
распределенных вычислений, приемлемые в пакетном режиме обработки, не позволяют
использовать классический MapReduce для потоковой обработки в режиме реального времени,
повторяющихся запросов и итеративных алгоритмов на одном и том же датасете, как в задачах
машинного обучения (Machine Learning).
Для решения этой проблемы ограниченности применения, свойственной Apache Hadoop, были
созданы другие Big Data фреймворки, в частности, Apache Spark и Flink.
В отличие от классического обработчика ядра Apache Hadoop c двухуровневой концепцией
MapReduce на базе дискового хранилища, Spark использует специализированные примитивы для
рекуррентной обработки в оперативной памяти. Благодаря этому многие задачи вычисляются
значительно быстрее. Например, многократный доступ к загруженным в память пользовательским
данным позволяет эффективно работать с алгоритмами Machine Learning.
Другие реализации.
 Greenplum — коммерческая реализация с поддержкой языков Python, Perl, SQL и пр.
 GridGain — бесплатная реализация с открытым исходным кодом на языке Java.
 Phoenix — реализация на языке С с использованием разделяемой памяти.
 MapReduce реализована в графических процессорах NVIDIA с использованием CUDA.
 Qt Concurrent — упрощённая версия фреймворка, реализованная на C++, для распределения
задачи между несколькими ядрами одного компьютера.
 CouchDB использует MapReduce для определения представлений поверх распределённых
документов.
 Skynet — реализация с открытым исходным кодом на языке Ruby.
 Disco — реализация от компании Nokia, ядро которой написано на языке Erlang, а приложения
можно разрабатывать на Python.
 Hive framework — надстройка с открытым исходным кодом от Facebook, позволяющая
комбинировать подход MapReduce и доступ к данным на SQL-подобном языке.
 Qizmt — реализация с открытым исходным кодом от MySpace, написанная на C#.
 DryadLINQ — реализация от Microsoft Research на основе PLINQ и Dryad.
HADOOP, SPARK, FLINK
Список фреймворков.
 Hadoop
 Apache Spark
 Storm
 Samza
 Flink
Hadoop.
Проект фонда Apache Software Foundation, свободно распространяемый набор утилит, библиотек и
фреймворк для разработки и выполнения распределённых программ, работающих на кластерах из
сотен и тысяч узлов.
Разработан на Java в рамках вычислительной парадигмы MapReduce, согласно которой
приложение разделяется на большое количество одинаковых элементарных заданий, выполнимых на
узлах кластера и естественным образом сводимых в конечный результат.
Считается одной из основополагающих технологий «больших данных». Вокруг Hadoop
образовалась целая экосистема из связанных проектов и технологий, многие из которых развивались
изначально в рамках проекта, а впоследствии стали самостоятельными.
Компоненты:
 Hadoop Common (связующее программное обеспечение): набор инфраструктурных
программных библиотек и утилит, используемых для других модулей и родственных проектов
 HDFS: распределённая файловая система
 YARN: система для планирования заданий и управления кластером
 Hadoop MapReduce: платформа программирования и выполнения распределённых MapReduce-
вычислений).
Ранее в Hadoop входил целый ряд других проектов, ставших самостоятельными в рамках системы
проектов Apache Software Foundation
Hadoop MapReduce.
Apache MapReduce компонент Hadoop для обработки данных, проводит вычисления в два этапа:
 Map, когда главный узел кластера (master) распределяет задачи по рабочим узлам (node)
 Reduce, когда данные сворачиваются и передаются обратно на главный узел, формируя
окончательный результат вычислений.
Пока все процессы этапа Map не закончатся, процессы Reduce не начнутся. При этом все операции
проходят по циклу чтение-запись с жесткого диска. Это обусловливает задержки в обработке
информации. Таким образом, технология Hadoop MapReduce хорошо подходит для задач
распределенных вычислений в пакетном режиме, но из-за задержек (latency) не может
использоваться для потоковой обработки в режиме реального времени
Apache Spark.
Фреймворк с открытым исходным кодом для реализации распределённой обработки
неструктурированных и слабоструктурированных данных, входящий в экосистему проектов Hadoop.
Компоненты:
 Ядро (Core)
 SQL – инструмент для аналитической обработки данных с помощью SQL-запросов;
 Streaming – надстройка для обработки потоковых данных, о которой подробно мы
рассказывали здесь и здесь;
 MLlib – набор библиотек машинного обучения;
 GraphX – модуль распределённой обработки графов.
Hadoop и Apache Spark: различия.
Классический обработчик из ядра Hadoop реализует двухуровневую концепцию MapReduce с
хранением промежуточных данных на накопителях.
Spark работает в парадигме резидентных вычислений (in-memory computing) — обрабатывает
данные в оперативной памяти, благодаря чему позволяет получать значительный выигрыш в
скорости работы для некоторых классов задач, (в частности, возможность многократного доступа к
загруженным в память пользовательским данным подходит для алгоритмов машинного обучения).
 Hadoop MapReduce Apache Spark
Быстрый  На два порядка быстрее
Подходит для пакетной обработки (когда  Подходит для обработки потока данных
передается готовый пакет данных) в реальном времени
Хранит данные на дисках  Хранит данные в памяти
Написан на Java  Написан на Scala (позже добавлена часть
кода на Java)
Spark: среда работы и поддержка система хранения и языков программирования.
Spark может работать как в среде кластера Hadoop под управлением YARN, так и без компонентов
ядра Hadoop, например, на базе системы управления кластером Mesos.
Spark поддерживает несколько популярных распределённых систем хранения данных (HDFS,
OpenStack Swift, Cassandra, Amazon S3) и языков программирования (Java, Scala, Python, R),
предоставляя для них API-интерфейсы.
Spark: микропакетный подход.
Spark Streaming, в отличие от, например, Apache Storm, Flink или Samza, не обрабатывает потоки
Big Data целиком. Вместо этого реализуется микропакетный подход (micro-batch), когда поток
данных разбивается на небольшие пакеты временных интервалов. Абстракция Spark для потока
называется DStream (discretized stream, дискретизированный поток) и представляет собой микро-
пакет, содержащий несколько отказоустойчивых распределенных датасетов, RDD (resilient distributed
dataset).
Spark: использование.
Благодаря наличию разнопрофильных инструментов для аналитической обработки данных «на
лету» (SQL, Streaming, MLLib, GraphX), Spark активно используется в системах интернета вещей
(Internet of Things, IoT) на стороне IoT-платформ, а также в различных бизнес-приложениях, в т.ч. на
базе методов Machine Learning. Однако, если временная задержка обработки данных (latency) – это
критичный фактор, Apache Spark не подойдет и стоит рассмотреть альтернативу в виде клиентской
библиотеки Kafka Streams или фреймворков Storm, Flink, Samza.
Apache Flink.
Распределенная отказоустойчивая платформа обработки информации с открытым исходным
кодом, используемая в высоконагруженных Big Data приложениях для анализа данных, хранящихся в
кластерах Hadoop. Разработан в 2010 году в Техническом университете Берлина в качестве
альтернативы Hadoop MapReduce для распределенных вычислений больших наборов данных.
Использует подход ориентированного графа, устраняя необходимость в отображении и сокращения.
Подобно Apache Spark, Flink имеет готовые коннекторы с Apache Kafka, Amazon Kinesis, HDFS,
Cassandra, Google Cloud Platform и др., а также интегрируется со всеми основными системами
управления кластерами: Hadoop YARN, Apache Mesos и Kubernetes. Кроме того, может
использоваться в качестве основы автономного кластера. Входные данные каждого потока берутся с
одного или нескольких источников, например, из очереди сообщений Apache Kafka, СУБД HBase
или файловой системы Hadoop HDFS, отправляясь в один или несколько приемников (очередь
сообщений, файловую систему или базу данных).
В потоке может быть выполнено произвольное число преобразований. Эти потоки могут быть
организованы как ориентированный ациклический граф, позволяющий приложению распределять и
объединять потоки данных. Помимо потоковой обработки Big Data в рамках DataStream API, Flink
также позволяет работать с пакетами данных с помощью мощного DataSet API.
При развертывании приложения Flink автоматически идентифицирует требуемые ресурсы на
основе настроенного параллелизма приложения и запрашивает их из системы управления кластером.
В случае сбоя Flink заменяет контейнер, запрашивая новые ресурсы. Отправка и управление
приложением происходит через REST. Это облегчает интеграцию Flink в различных средах. Подобно
другому популярному фреймворку потоковой обработки Big Data, Apache Spark, Flink содержит
оптимизатор и библиотеки для машинного обучения, аналитических графиков и реляционной
обработки данных.
Преимущества Flink.
 Высокая производительность — приложения могут распараллеливаться в тысячи задач,
которые распределяются и выполняются в кластере одновременно, используя практически
неограниченное количество процессоров, основной памяти, дискового и сетевого ввода-
вывода.
 Кроме того, Flink легко поддерживает очень большое состояние приложения. Его
асинхронный и инкрементный контрольный алгоритм обеспечивает минимальное влияние на
задержки обработки, гарантируя точную согласованность состояния за один раз.
 Низкое время задержки, достигаемое, в т.ч. за счет собственной подсистемы управления
памятью и ее эффективного использования – приложения Flink оптимизированы для
локального доступа. Состояние задачи (stateful) сохраняется в локально памяти или, если его
размер превышает доступную память, на жестком диске.
 Веб-интерфейс, который отображает граф обработки данных и позволяет посмотреть, сколько
данных каждой подзадачи обработал конкретный worker. Благодаря этому можно определить,
какой участок кода работает с задержкой, т.е. какой процент данных не успел обработаться и
где.
 Отказоустойчивость – Flink гарантирует согласованность состояния приложений в случае
сбоев, периодически и асинхронно проверяя локальное состояние на необходимость
перемещения в долговечное хранилище.
 Гибкая работа с потоковыми данными – поддержка временных и неисправных событий,
непрерывная потоковая модель передачи с обратным воздействием, реализация концепции
«окон» для избирательной обработки данных в определенном временном промежутке
(подробно механизм временных окон Apache Kafka Streams).
 Два режима работы с данными в одной среде – потоковая передача и пакетная обработка.
 Специализированная поддержка итерационных вычислений (машинное обучение, анализ
графов).
Недостатки Flink.
 Даже при наличии отказоустойчивого хранилища состояний для приложений (stateful),
которое поддерживает механизм контрольных точек (checkpoints), из него нельзя
восстановиться при изменении кода.
 Многие библиотеки Flink до сих пор находятся в бета-режиме, что затрудняет его
использование в крупных Big Data проектах корпоративного сектора, где требуется высокая
надежность.
HDFS
HDFS (Hadoop Distributed File System) – распределенная файловая система Hadoop для хранения
файлов больших размеров с возможностью потокового доступа к информации, поблочно
распределённой по узлам вычислительного кластера, который может состоять из произвольного
аппаратного обеспечения.
HDFS, как и любая файловая система – это иерархия каталогов с вложенными в них
подкаталогами и файлами.
HDFS может использоваться не только для запуска MapReduce-заданий, но и как распределённая
файловая система общего назначения, обеспечивая работу распределённых СУБД (HBase) и
масштабируемых систем машинного обучения (Apache Mahout).
Hadoop <--> HDFS.
HDFS – неотъемлемая часть Hadoop, проекта верхнего уровня Apache Software Foundation, и
основа инфраструктуры больших данных (Big Data). Поддерживает работу и с другими
распределёнными файловыми системами, в частности, Amazon S3 и CloudStore.
Компоненты кластера HDFS.
 NameNode — управляющий узел, узел имен или сервер имен.Отдельный, единственный в
кластере, сервер с программным кодом для управления пространством имен файловой
системы, хранящий дерево файлов, а также мета-данные файлов и каталогов. NameNode –
обязательный компонент кластера HDFS, который отвечает за открытие и закрытие файлов,
создание и удаление каталогов, управление доступом со стороны внешних клиентов и
 соответствие между файлами и блоками, дублированными (реплицированными) на узлах
данных. Сервер имён раскрывает для всех желающих расположение блоков данных на
машинах кластера.
 Secondary NameNode — вторичный узел имен. отдельный сервер, единственный в кластере,
который копирует образ HDFS и лог транзакций операций с файловыми блоками во
временную папку, применяет изменения, накопленные в логе транзакций к образу HDFS, а
также записывает его на узел NameNode и очищает лог транзакций. Secondary NameNode
необходим для быстрого ручного восстанавления NameNode в случае его выхода из строя.
 DataNode, Node — узел или сервер данных. Один их множества серверов кластера с
программным кодом, отвечающим за файловые операции и работу с блоками данных.
Обязательный компонент кластера HDFS, который отвечает за:запись и чтение данных,
выполнение команд от узла NameNode по созданию, удалению и репликации блоков, а
также периодическую отправку сообщения о состоянии (heartbeats) и обработку запросов
на чтение и запись, поступающих от клиентов файловой системы HDFS. Стоит отметить,
что данные проходят с остальных узлов кластера к клиенту мимо узла NameNode.
 Client – пользователь или приложение, взаимодействующий через специальный интерфейс
(API – Application Programming Interface) с распределенной файловой системой. При
наличии достаточных прав, клиенту разрешены следующие операции с файлами и
каталогами: создание, удаление, чтение, запись, переименование и перемещение. Создавая
файл, клиент может явно указать размер блока файла (по умолчанию 64 Мб) и количество
создаваемых реплик (по умолчанию значение равно 3-ем).
HDFS: особенности хранения.
 Высокая надежность хранения данных и скорость вычислений (репликации блоков по узлам
данных).
 Большой размер блока по сравнению с другими файловыми системами (>64MB), поскольку
HDFS предназначена для хранения большого количества огромных (>10GB) файлов.
 Ориентация на недорогие и, поэтому не самые надежные сервера – отказоустойчивость всего
кластера обеспечивается за счет репликации данных.
 Зеркалирование и репликация осуществляются на уровне кластера, а не на уровне узлов
данных.
 Репликация происходит в асинхронном режиме – информация распределяется по нескольким
серверам прямо во время загрузки, поэтому выход из строя отдельных узлов данных не
повлечет за собой полную пропажу данных (HDFS оптимизирована для потоковых
считываний файлов, поэтому применять ее для нерегулярных и произвольных считываний
нецелесообразно).
 Клиенты могут считывать и писать файлы HDFS напрямую через программный интерфейс
Java;
 Файлы пишутся однократно, что исключает внесение в них любых произвольных изменений:
принцип WORM (Write-once and read-many, один раз записать – много раз прочитать)
полностью освобождает систему от блокировок типа «запись-чтение». Запись в файл в одно
время доступен только одному процессу, что исключает конфликты множественной записи.
 HDFS оптимизирована под потоковую передачу данных: сжатие данных и рациональное
использование дискового пространства позволило снизить нагрузку на каналы передачи
данных, которые чаще всего являются узким местом в распределенных средах.
 Самодиагностика — каждый узел данных через определенные интервалы времени отправляет
диагностические сообщения узлу имен, который записывает логи операций над файлами в
специальный журнал; все метаданные сервера имен хранятся в оперативной памяти.
Недостатки HDFS.
 Сервер имен является центральной точкой всего кластера и его отказ повлечет сбой системы
целиком.
 Отсутствие полноценной репликации Secondary NameNode.
 Отсутствие возможности дописывать или оставить открытым для записи файлы в HDFS, за
счет чего в классическом дистрибутиве Apache Hadoop невозможно обновлять блоки уже
записанных данных.
 Отсутствие поддержки реляционных моделей данных.
 Отсутствие инструментов для поддержки ссылочной целостности данных, что не гарантирует
идентичность реплик (HDFS перекладывает проверку целостности данных на клиентов: при
создании файла клиент рассчитывает контрольные суммы каждые 512 байт, которые в
последующем сохраняются на сервере имен; при считывании файла клиент обращается к
данным и контрольным суммам, в случае их несоответствия происходит обращение к другой
реплике.
Группы команд HDFS
 Список файлов
 Чтение/запись файлов
 Загрузка/выгрузка файлов
 Управление файлами
 Владение и проверка
 Файловая система
 Администрирование
HDFS: КОМАНДНАЯ СТРОКА
Общие команды HDFS.

Общий формат команд и универсальный идентификатор ресурса (URI, Uniform Resource

Identifier).
Общий формат команд:
$hdfs dfs -<command> -<option> <URI>
Например: $hdfs dfs –ls / (вывод содержимого корневого каталога)
Локальный URI (scheme, authority, HDFS path)
hdfs://localhost:8020/user/home
scheme: hdfs
authority: localhost:8020
HDFS path: /user/home
Пример применения ссылок в команде hdfs dfs -ls (список содержимого директории).
 Пример применения локальной ссылки:
$hdfs dfs -ls file:///to/path/file3
 Пример применения HDFS ссылки:
$hdfs dfs -ls hdfs://localhost/to/path/dir
fs.default.name=hdfs://localhost
$hdfs dfs -ls /to/path/dir
 Группы команд HDFS.
 Список файлов
 Чтение/запись файлов
 Загрузка/выгрузка файлов
 Управление файлами
 Владение и проверка
 Файловая система
 Администрирование
Некоторые команды в стиле Unix (Linux).
 chmod
 chown
 count
 test
Чтобы узнать о команде: $hdfs dfs –help или $hdfs dfs -help <command>
Примеры применения команд.
 Команда help:
Вывод списка команд: $ hdfs dfs –help
Показать информацию по команде: $ hdfs dfs -help <command_name>
 Команда ls – листинг директории и статистика файлов
hdfs dfs -ls /user/cloudera/wordcount/output
 Команда mkdir – создать директорию
$hdfs dfs –mkdir /data/new_path
 Команда чтения файлов: cat – вывод источника в stdout
Весь файл: $hdfs dfs -cat /dir/file.txt
Получить первые 100 строк из файла: $hdfs dfs -cat /dir/file.txt | head -n 100 (перенаправление через
pipe)
 Команда чтения с разархивацией: text (аналог cat)
$hdfs dfs -cat /dir/file.gz – непонятный текст
$hdfs dfs -text /dir/file.gz – понятный текст
 Команда чтения файлов в shell tail – выводит последние строчки файла
$hdfs dfs -cat /dir/file.txt | tail – плохо
$hdfs dfs -tail /dir/file.txt – хорошо
Копирование и перемещение данных.
 cp – скопировать файлы из одного места в другое (годится только для небольших файлов)
$hdfs dfs -cp /dir/file1 /otherDir/file2
 distcp – копирует большие файлы или много файлов
$hdfs distcp /dir/file1 /otherDir/file2
 mv – перемещение файла из одного места в другое
$hdfs dfs -mv /dir/file1 /dir2 put (copyFromLocal)
 копирование локального файла в HDFS
$hdfs dfs -put localfile /dir/file get (copyToLocal)
 копирование файла из HDFS в локальную FS
$hdfs dfs -get /dir/file localfile
Удаление, статистика и другие.
 rm – удалить файл (в корзину):
$hdfs dfs -rm /dir/file rm -r
 удалить рекурсивно директорию:
$hdfs dfs -rm -r /dir
 du – размер файла или директории в байтах
$hdfs dfs -du /dir/ du -h
 размер файла или директории в удобно-читаемом формате
 $hdfs dfs -du –h /dir/ 65M /dir
Права в HDFS.
 Ограничения на уровне файла/директории
 Сходство с моделью прав в POSIX:
Read (r), Write (w) и Execute (x)
Разделяется на пользователя, группу и всех остальных
 Права пользователя определяются исходя из прав той ОС, где он запускает клиентское
приложение
$ hadoop fs -ls /user/cloudera/wordcount/output
Found 3 items
-rw-r--r-- 3 cloudera cloudera 0 2014-03-15 11:56 /user/cloudera/wordcount/output/_SUCCESS
drwxr-xr-x - cloudera cloudera 0 2014-03-15 11:56 /user/cloudera/wordcount/output/_logs –
rw-r--r-- 3 cloudera cloudera 31 2014-03-15 11:56 /user/cloudera/wordcount/output/part-00000
Команда fsck.
Проверка неконсистентности файловой системы
Показывает проблемы:
 Отсутствующие блоки
 Недореплицированные блоки
Не устраняет проблем, только информация: Namenode попытается автоматически исправить
проблемы
$ hdfs fsck <path>
$ hdfs fsck /
Команда DFSAdmin.
Команды для администрирования HDFS –
$hdfs dfsadmin -<command>
Например:
$hdfs dfsadmin –report
report – отображает статистику по HDFS
safemode – включение безопасного режима для проведения административных работ – Upgrade,
backup и т.д.
Балансер HDFS.
Блоки в HDFS могут быть неравномерно распределены по всем Datanode’ам кластера
Балансер – это утилита, которая автоматически анализирует расположение блоков в HDFS и
старается его сбалансировать
$ hdfs balancer
YARN
YARN -> Apache Hadoop YARN.
Не путать с Yarn (система упаковки программного обеспечения, разработанная Facebook для
среды выполнения JavaScript Node.js).
Будучи впервые выпущен в 2013 году под лицензией Apache 2.0, YARN является одним из
основных модулей ядра экосистемы Hadoop, отвечая за планирование заданий и управление
распределенными приложениями.
YARN решает проблемы 1-ой версии технологии распределенных вычислений – MapReduce,
предоставляя компоненты и API для разработки Big Data приложений, обеспечивая распределение
ресурсов в ответ на запросы и отслеживания статусы выполнения заданий. Поэтому очень часто этот
фреймворк называют Apache Hadoop YARN или MapReduce 2.0, хотя он используется не только в
классическом Hadoop MapReduce.
YARN = MapReduce 2.0.
Система планирования заданий и управления кластером (Yet Another Resource Negotiator). Также
систему называют MapReduce 2.0: набор системных программ (демонов), обеспечивающих
совместное использование, масштабирование и надежность работы распределенных приложений.
 YARN является интерфейсом между аппаратными ресурсами кластера и приложениями,
использующих его мощности для вычислений и аналитики больших данных.
YARN -> Apache Hadoop YARN.
Благодаря более общей модели, чем в классическом Hadoop MapReduce, YARN позволяет
запускать в кластере Apache Hadoop не только MapReduce-задания, но и любые распределенные
приложения.
В частности, в Apache Spark именно YARN обеспечивает распределённому приложению доступ к
кластеру через свой диспетчер ресурсов – один из главных модулей YARN, которые мы рассмотрим
далее.
YARN: компоненты.
 ResourceManager (RM) — менеджер ресурсов, который отвечает за распределение ресурсов,
необходимых для работы распределенных приложений, и наблюдение за узлами кластера, где
эти приложения выполняются. ResourceManager включает планировщик ресурсов (Scheduler)
и диспетчер приложений (ApplicationsManager, AsM). ApplicationsManager отвечает за прием
задач и запуск экземпляров мастера приложений (ApplicationMaster), мониторингов узлов
(контейнеров), на которых происходит выполнение распределенных заданий, и предоставляет
сервис для перезапуска контейнера ApplicationMaster в случае сбоя. Планировщик менеджера
ресурсов (Scheduler) является не ведет мониторинг и не отслеживает статус выполнения
распределенного приложений, а также не дает гарантий перезапуска неудачных задач при
аппаратных или программных отказах.
 ApplicationMaster (AM) — мастер приложений, ответственный за планирование его
жизненного цикла, координацию и отслеживание статуса выполнения, включая динамическое
масштабирование потребления ресурсов, управление потоком выполнения, обработку ошибок
и искажений вычислений, выполнение локальных оптимизаций. Каждое приложение имеет
свой экземпляр ApplicationMaster. ApplicationMaster выполняет произвольный
пользовательский код и может быть написан на любом языке программирования благодаря
расширяемым протоколам связи с менеджером ресурсов и менеджером узлов.
 NodeManager (NM) — менеджер узла – агент, запущенный на узле кластера, который отвечает
за отслеживание используемых вычислительных ресурсов (CPU, RAM и пр.), управление
логами и отправку отчетов об использовании ресурсов планировщику. NodeManager управляет
абстрактными контейнерами – ресурсами узла, доступными для конкретного приложения.
 Контейнер (Container) — набор физических ресурсов (ЦП, память, диск, сеть) в одном
вычислительном узле кластера.
Протоколы взаимодействия компонентов.
 ClientRMProtocol – протокол взаимодействия клиента с ResourceManager для запуска,
завершения и проверки статуса приложений;
 AMRMProtocol – протокол, который использует мастер приложения для регистрации или ее
регистрации в менеджере ресурсов, а также для запроса ресурсов у планировщика;
 ContainerManager— протокол взаимодействия мастера приложения с диспетчером узлов для
запуска или остановки и получения данных о необходимости обновления контейнеров под
управлением NodeManager.
Работа YARN.
ResourceManager и диспетчер узла образуют структуру вычисления данных, где менеджер
ресурсов распределяет ресурсы между всеми приложениями в системе, а NodeManager на каждом
узле отвечает за контейнеры, отслеживая использование ресурсов и сообщая об этом планировщику.
Планировщик распределяет ресурсы между запущенными приложениями в виде контейнера с учетом
их требований и известных ограничений емкости, очередей и пр.
YARN: разделяет функции управления ресурсами и планирования/мониторинга заданий на
отдельные демоны, имея глобальный диспетчер ресурсов и мастер приложения для каждого
отдельного задания или их конвейера в виде направленного ациклического графа (DAG, Directed
Acyclic Graph).
Последовательность работ 1: от клиента до контейнера.
 Клиентское приложение отправляет запрос в кластер;
Менеджер ресурсов выделяет необходимые ресурсы для контейнера и запускает ApplicationMaster
для обслуживания этого приложения:
 ApplicationMaster отправляет запрос менеджеру узла NodeManager, включая контекст запуска
контейнера Container Launch Context (CLC);
 ApplicationMaster выделяет контейнеры для приложения в каждом узле и контролирует их
работу до завершения работы приложения;
Последовательность работ 2: мастер приложения + контейнеры в кластере.
Для запуска контейнера менеджер узла копирует в локальное хранилище все необходимые
зависимости (данные, исполняемые файлы, архивы); по завершении задачи мастер приложения
отменяет выделенный контейнер в диспетчере ресурсов, завершая жизненный цикл распределенного
задания. Клиент может отслеживать состояние распределенного приложения, обращаясь к
менеджеру ресурсов или сразу к мастеру приложения. При необходимости клиент может
самостоятельно завершить работу приложения. 
Являясь контейнером, работающим в кластере, мастер приложения должен быть
отказоустойчивым. Хотя YARN и поддерживает восстановление при сбоях, но большая часть
нагрузки по обеспечению отказоустойчивости все равно лежит на мастере приложения.
APACHE STORM
Список фреймворков.
 Hadoop
 Apache Spark
 Storm
 Samza
 Flink
Apache Storm.
Среда вычислений с распределенной потоковой обработкой, написанная преимущественно на
языке программирования Clojure.
Первоначально созданный Натаном Марцем и командой BackType, исходный код проекта был
открыт после того, как его приобрел Twitter. Первоначальный выпуск состоялся 17 сентября 2011 г.
Storm стал проектом верхнего уровня Apache в сентябре 2014 г. В целом общая структура топологии
похожа на задание MapReduce, с основным отличием в том, что данные обрабатываются в реальном
времени, а не отдельными пакетами. Кроме того, топологии Storm работают бесконечно, пока не
будут уничтожены, в то время как задание DAG MapReduce должно в конечном итоге завершиться.
Кластер Apache Storm, работающий по принципу master-slave, состоит из следующих
компонентов:
 Ведущий узел (master) с запущенной системной службой (демоном) Nimbus, который
назначает задачи машинам и отслеживает их производительность.
 Рабочие узлы (worker nodes), на каждом из которых запущен демон Supervisor (супервизор),
который назначает задачи (task) другим рабочим узлам и управляет ими по необходимости.
Storm самостоятельно не отслеживает состояние кластера, поэтому для связи Nimbus с
супервизорами и управления кластером используется служба ZooKeeper.
Топология вычислений реального времени: ориентированный ациклический граф (DAG,
Directed Acyclic Graph).
Узлами (вершинами) графа являются обработчики 2-х типов:
 спаут (spout), который генерирует кортежи (tuple) – потоки данных в виде неизменяемых
наборов пар ключ-значение;
 болт (bolt), который выполняет преобразование потока (подсчет, фильтрация, map, reduce и
пр.) и передает данные другим болтам для последующей обработки.
Apache Storm: кортежи потоков (конвейеров кортежей).
Поток представляет собой неограниченный конвейер кортежей, а Spout является источником
потоков, который преобразует данные в кортеж потоков и отправляет их на обработку в Bolt. В итоге
топология действует как конвейер преобразования данных.
 На поверхностном уровне общая структура топологии аналогична задаче MapReduce в Apache
Hadoop, однако в Storm данные обрабатываются в режиме реального времени, а не в отдельных
пакетах. Также, в отличие от классического Hadoop, топологии Storm работают неопределенно долго
(пока не будут уничтожены), а DAG-задача MapReduce имеет ограниченный срок существования.
Apache Storm: преимущества.
 Интеграция с любыми системами управления очередью и брокерами сообщений (Kestrel,
RabbitMQ, Kafka, JMS, Amazon Kinesis), а также с базами данных.
 Масштабируемость – вычислительные топологии Storm изначально параллельны и
предназначены для кластерной работы с технологиями Big Data. Различные части топологии
можно масштабировать по отдельности, изменяя их параллелизм и регулируя параллельность
запуска на лету.
 Вычислительная мощность – благодаря распределенному параллелизму может обрабатывать
очень большое количество сообщений с очень низкой задержкой.
 Отказоустойчивость — когда фоновые задачи перестают работать, Storm автоматически
перезапустит их на этом же узле кластера или на другом, в случае его сбоя. Фреймворк
самостоятельно обрабатывает параллелелизм, разделение данных и повтор действий в случае
ошибок.
 Гарантия обработки данных – обеспечивает обработку каждого кортежа данных за счет
семантики минимум однократной доставки (at least once) или в точности однократной
доставки (exactly once) с использованием высокоуровневого API-интерфейса Trident.
 Поддержка множества языков программирования — использует Apache Thrift – язык описания
интерфейсов, который используется для определения и создания служб под разные языки
программирования, а также является фреймворком к удалённому вызову процедур. Благодаря
этому можно создавать программные топологии на любом языке программирования: Java,
Scala, Python, C#, Ruby и др.
 Наличие собственной RPC-подсистемы – за счет инструмента распределенного удаленного
вызова процедур позволяет выполнять кластерные вычисления по требованию, когда клиент
синхронно ожидает результат.
 Низкая задержка (latency) – обеспечивает обработку потоковых данных в реальном времени с
задержкой менее 1 секунды, показывая лучшие результаты по сравнению с Apache Spark.
 Простота развертывания и поддержки – обладает стандартным набором конфигураций для
развертывания кластера, а при работе с вычислительным облаком Amazon Elastic Compute
Cloud (Amazon EC2), проект со Storm можно подготовить, настроить и установить с нуля
нажатием одной кнопки.
Apache Storm: недостатки.
 Отсутствие возможностей гибкой обработки событий в различных периодах, например,
временные и сеансовые окна, как в Apache Kafka Streams и Flink.
 Не поддерживает управление состоянием приложений (stateful).
 Поддержка минимум однократной доставки сообщений (at least once).
Последние 2 проблемы решаются с помощью высокоуровневого API-интерфейса Trident.
APACHE SAMZA
Список фреймворков.
 Hadoop
 Apache Spark
 Storm
 Samza
 Flink
Apache Samza.
Apache Samza (Самза) – это асинхронная вычислительная Big Data среда с открытым исходным
кодом для распределенных потоковых вычислений практически в реальном времени. Разработана
Apache Software Foundation на Scala и Java. Оба решения созданы одними и теми же разработчиками,
которые внедрили Samza в LinkedIn, а затем основали компанию Confluent, где и была написана
Kafka Streams.Позволяет пользователям создавать приложения с отслеживанием состояния, которые
обрабатывают данные в режиме реального времени из нескольких источников, включая Apache
Kafka.
Samza обеспечивает отказоустойчивость, изоляцию и обработку с отслеживанием состояния. В
отличие от пакетных систем, таких как Apache Hadoop или Apache Spark, он обеспечивает
непрерывные вычисления и вывод, что приводит к времени отклика менее секунды.
Apache Samza (сравнение с Kafka Streams).
По аналогии с Apache Kafka Streams, Samza считывает данных из входных потоков (Input Stream),
ассоциированных с топиками Kafka, и записывает их в логи изменений (Changelog Stream) и
выходные потоки (Output Stream), также ассоциированные с соответствующими топиками. Обе
технологии тесно связаны с Kafka – они получают оттуда необработанные данные, производят
вычисления и затем возвращают обработанные данные обратно.
Низкая задержка обработки данных (low latency) характерна для обоих решений.
Общие концептуальные понятия – примитивом потоковой обработки является сообщение
(message), обращение к данным ведется по разделам топика (partition).
Вывод: Apache Samza – это своего рода более масштабная версия Kafka Streams. Однако, Kafka
Streams – это библиотека, предназначенная, в первую очередь, для микросервисов, работающих с
кластером Kafka, тогда как Samza является полноценной распределенной средой потоковых
вычислений под управлением YARN.
Apache Samza (сравнение с Storm).
Оба используют похожую модель параллелизма, разделяя работу на независимые задачи, которые
могут выполняться параллельно. При этом распределение ресурсов не зависит от количества задач:
небольшая работа может хранить все задачи в одном процессе на одном компьютере, а большая
работа может распределить задачи по многим процессам на многих машинах.
Однако, Storm использует один поток на задачу по умолчанию, тогда как Samza использует
однопоточные процессы (контейнеры).
Контейнер Samza может содержать несколько задач, но есть только один поток, который вызывает
каждую из задач по очереди. Это означает, что каждый контейнер сопоставлен ровно с одним ядром
центрального процессора, что значительно упрощает модель распределения ресурсов и уменьшает
помехи от других задач, выполняемых на той же машине.
Преимущество многопоточной модели Storm в том, что она лучше использует избыточную
емкость на простаивающей машине за счет менее предсказуемой модели ресурсов.
Apache Samza: преимущества.
 Интеграция с несколькими источниками данных – можно создавать потоковые приложения,
которые обрабатывают данные в режиме реального времени из нескольких источников,
включая Apache Kafka.
 Наличие Beam-совместимого API-интерфейса, который позволяет переносить конвейеры
обработки данных между Samza, Spark или Flink, а также обрабатывать данные на других, не
только Java-подобных, языках программирования, включая Python.
 Низкая задержка обработки данных (latency) — в отличие от пакетных Big Data систем
(Apache Hadoop или Spark), Samza обеспечивает непрерывные вычисления и вывод, что
приводит к времени отклика менее 1 секунды.
 Реализация stateful-приложений — с сохранением состояния во встроенном хранилище пар
ключ-значение.
 Встроенная Big Data система управления ресурсами кластера – YARN.
 Отказоустойчивость, масштабируемость и высокая производительность за счет свойств Kafka.
Apache Samza: недостатки.
 Привязанность к Kafka и Yarn (если эти инструменты не используются в конвейере потоковой
обработки, придется самостоятельно настраивать интеграцию с другими средствами).
 Обеспечение семантики минимум однократной доставки сообщений (at least once). Другие
популярные фреймворки поддерживают строго однократную доставку (exactly once), которая
позволяет избежать дублирования и пропусков сообщений.
 Отсутствие возможностей гибкой потоковой обработки, например, временных и сеансовых
окон, как в Kafka Streams.
ТЕХНОЛОГИИ БАЗ ДАННЫХ
Реляционные базы данных.
Реляционные базы данных состоят из взаимосвязанных по ключевым атрибутам таблиц.

Реляционные базы данных: режим согласованности или целостности, ACID (atomicity,

consistency, isolation, durability).
 Атомарность определяет элементы, образующие полную транзакцию.
 Согласованность определяет правила поддержания целостности данных после транзакций.
 Благодаря изоляции эффекты транзакций являются невидимыми для других транзакций,
чтобы не возникало конфликтов между ними.
 Устойчивость означает постоянство изменений данных после каждой зафиксированной
транзакции.
SQL (Structured Query Language — «язык структурированных запросов»).
Декларативный язык программирования, применяемый для создания, модификации и управления
данными в реляционной базе данных, управляемой соответствующей системой управления базами
данных. Является, прежде всего, информационно-логическим языком, предназначенным для
описания, изменения и извлечения данных, хранимых в реляционных базах данных.
Диалекты: PL/SQL (Oracle Database), PSQL (Interbase, Firebird), SQL PL (DB2), Transact-SQL
(Microsoft SQL Server, Adaptive Server Enterprise), PL/pgSQL (PostgreSQL).
Изначально SQL был основным способом работы пользователя с базой данных и позволял
выполнять следующий набор операций:
 создание в базе данных новой таблицы;
 добавление в таблицу новых записей;
 изменение записей;
 удаление записей;
 выборка записей из одной или нескольких таблиц (по условию);
 изменение структур таблиц.
Со временем SQL усложнился — обогатился новыми конструкциями, обеспечил возможность
описания и управления новыми хранимыми объектами (например, индексы, представления, триггеры
и хранимые процедуры) — и стал приобретать черты, свойственные языкам программирования.
Структура типового запроса SQL.
SELECT ('столбцы или * для выбора всех столбцов; обязательно')
FROM ('таблица; обязательно')
WHERE ('условие/фильтрация, например, city = 'Moscow'; необязательно')
GROUP BY ('столбец, по которому хотим сгруппировать данные; необязательно')
HAVING ('условие/фильтрация на уровне сгруппированных данных; необязательно')
 ORDER BY ('столбец, по которому хотим отсортировать вывод; необязательно')
Транзакция.
Транзакция в базе данных – это один или несколько операторов SQL, выполненных в виде
последовательности операций, представляющих собой единую логическую задачу. Транзакция
представляет собой неделимое действие, то есть она должна быть выполнена как единое целое и либо
должна быть записана в базу данных целиком, либо не должен быть записан ни один из ее
компонентов.
В терминологии реляционных баз данных транзакция завершается либо действием COMMIT
(подтверждаем все внесенные изменения), либо ROLLBACK (отменяем операцию и возвращаемся к
предыдущему состоянию). Каждая транзакция рассматривается как внутренне связный, надежный и
независимый от других транзакций элемент.
NoSQL.
Подход к реализации масштабируемого хранилища (базы) информации с гибкой моделью данных,
отличающийся от классических реляционных СУБД.
В нереляционных базах проблемы масштабируемости (scalability) и доступности (availability),
важные для Big Data, решаются за счёт атомарности (atomicity) и согласованности данных
(consistency). Термин NoSQL обозначает «не только SQL» (Not Only SQL), характеризуя ответвление
от традиционного подхода к проектированию баз данных.
NoSQL: типы.
 Ключ-значение (Key-value) – наиболее простой вариант хранилища данных, использующий
ключ для доступа к значению в рамках большой хэш-таблицы.
 Документно-ориентированное хранилище, в котором данные, представленные парами ключ-
значение, сжимаются в виде полуструктурированного документа из тегированных элементов,
подобно JSON, XML, BSON и другим подобным форматам.
 Колоночное хранилище, которое хранит информацию в виде разреженной матрицы, строки и
столбцы которой используются как ключи. В мире Big Data к колоночным хранилищам
относятся базы типа «семейство столбцов» (Column Family).
 Графовое хранилище представляют собой сетевую базу, которая использует узлы и рёбра для
отображения и хранения данных. Поскольку рёбра графа являются хранимыми, его обход не
требует дополнительных вычислений (как соединение в SQL). При этом для нахождения
начальной вершины обхода необходимы индексы.
Ключ-значение (Key-value).
Применяются для хранения изображений, создания специализированных файловых систем, в
качестве кэшей для объектов, а также в масштабируемых Big Data системах, включая игровые и
рекламные приложения, а также проекты интернета вещей (Internet of Things, IoT), в т.ч.
индустриального (Industrial IoT, IIoT).
Наиболее известными представителями нереляционных СУБД типа key-value считаются Oracle
NoSQL Database, Berkeley DB, MemcacheDB, Redis, Riak, Amazon DynamoDB, которые
поддерживают высокую разделяемость, обеспечивая беспрецедентное горизонтальное
масштабирование, недостижимое при использовании других типов БД.
Колоночное хранилище.
В мире Big Data к колоночным хранилищам относятся базы типа «семейство столбцов» (Column
Family). В таких системах сами значения хранятся в столбцах (колонках), представленных в
отдельных файлах.
Благодаря такой модели данных можно хранить большое количество атрибутов в сжатом виде, что
ускоряет выполнение запросов к базе, особенно операции поиска и агрегации данных.
Наличие временных меток (timestamp) позволяет использовать такие СУБД для организации
счётчиков, регистрации и обработки событий, связанных со временем: системы биржевой аналитики,
IoT/IIoT-приложения, систему управления содержимым и т.д. Самой известной колоночной базой
данных является Google Big Table, а также основанные на ней Apache HBase и Cassandra. Также к
этому типу относятся менее популярные ScyllaDB, Apache Accumulo и Hypertable.
Преимущества NoSQL.
 Линейная масштабируемость – добавление новых узлов в кластер увеличивает общую
производительность системы.
 Гибкость, позволяющая оперировать полуструктирированные данные, реализуя, в. т.ч.
полнотекстовый поиск по базе.
 Возможность работать с разными представлениями информации без схемы данных.
 Высокая доступность за счет репликации данных и других механизмов отказоустойчивости, в
частности, шаринга – автоматического разделения данных по разным узлам сети. Это
увеличивает скорость обработки данных и пропускную способность приложения.
 Производительность за счет оптимизации для конкретных видов моделей данных
(документной, графовой, колоночной или «ключ-значение») и шаблонов доступа.
 Широкие функциональные возможности – собственные SQL-подобные языки запросов,
RESTful-интерфейсы, API и сложные типы данных, например, map, list и struct, позволяющие
обрабатывать сразу множество значений.
Недостатки NoSQL.
 Ограниченная емкость встроенного языка запросов. Например, HBase предоставляет всего 4
функции работы с данными (Put, Get, Scan, Delete), в Cassandra отсутствуют операции Insert и
Join, несмотря на наличие SQL-подобного языка запросов.
 Сложности в поддержке всех ACID-требований к транзакциям (атомарность, согласованость,
изоляция, долговечность).
 Сильная привязка приложения к конкретной СУБД из-за специфики внутреннего языка
запросов и гибкой модели данных, ориентированной на конкретный случай.
 Недостаток специалистов по NoSQL-базам по сравнению с реляционными аналогами.

HBase (No-SQL like System)

HBase — это распределенная система хранения на основе столбцов, которая отличается высокой
надежностью, производительностью и масштабируемостью.
HBase подходит для хранения данных больших таблиц (которые содержат миллиарды строк и
миллионы столбцов) и позволяет в режиме реального времени получить доступ к данным.
HBase использует HDFS в качестве системы хранения файлов, чтобы обеспечить распределенную
систему баз данных, ориентированную на столбцы, которая позволяет считывать и записывать
данные о времени. HBase использует ZooKeeper в качестве службы обеспечения совместной работы.
Модель данных HBase по типу ключ-значение – <table, RowKey, Column Family, Column,
timestamp> -> Value.
Данные организованы в таблицы, проиндексированные первичным ключом (RowKey). Для
каждого первичного ключа может храниться неограниченный набор атрибутов (колонок).
Колонки организованны в группы колонок (Column Family). Обычно в одну группу объединяют
колонки с одинаковым шаблоном использования и хранения. Список и названия групп колонок
фиксирован и имеет четкую схему. На уровне группы колонок задаются такие параметры как time to
live (TTL) и максимальное количество хранимых версий. Для каждого атрибута может храниться
несколько различных версий. Разные версии имеют разный штамп времени (timestamp, ts).
Записи физически хранятся в порядке, отсортированном по первичному ключу. При этом
информация из разных колонок хранится отдельно, благодаря чему можно считывать данные только
из нужного семейства колонок, таким образом, ускоряя операцию чтения.
Атрибуты, принадлежащие одной группе колонок и соответствующие одному ключу, физически
хранятся как отсортированный список. Любой атрибут может отсутствовать или присутствовать для
каждого ключа. Отсутствие атрибута не влечет никаких накладных расходов на хранение пустых
значений.
Если разница между меткой времени (timestamp) для определенной версии и текущим временем
больше TTL, такая запись помечается к удалению. Аналогично, если количество версий для
определённого атрибута превысило максимальное количество версий.
Принципы работы.
 HBase обеспечивает случайный доступ в реальном времени к данным в Hadoop в сочетании с
удобством пакетной обработки. Благодаря этому можно работать с очень большими таблицами, что
позволяет эффективно хранить многостраничные или разреженные данных.
Поскольку HBase является распределенной СУБД, она может работать на десятках и сотнях
физических серверов, обеспечивая бесперебойную работу даже при выходе из строя некоторых
узлов. Распределение данных по разным физическим машинам кластера обеспечивается механизмом
регионирования – автоматической горизонтальной группировки табличных строк.
Регион.
Диапазон записей, соответствующих определенному диапазону подряд идущих первичных
ключей. Каждый регион содержит следующие параметры:
 Persistent Storage— основное хранилище данных в Hbase. Данные физически хранятся на
HDFS, в специальном формате HFile, отсортированные по значению первичного ключа
(RowKey). Одной паре (регион, column family) соответствует как минимум один HFIle.
 MemStore— буфер на запись, специально выделенная область памяти для накопления
данных перед записью, поскольку обновлять каждую запись в отсортированном HFile
довольно дорого. Как только MemStore наполнится до некоторого критического значения,
создается очередной HFile, куда будут записаны новые данные.
 BlockCache— кэш на чтение, позволяющий существенно экономить время на часто
читаемых данных.
 Write Ahead Log (WAL) – специальный файл для логирования всех операций с данными,
чтобы их можно было восстановить в случае сбоя.
Регионирование.
Изначально таблица состоит из одного региона, который разбивается на новые по мере роста
(после превышения конкретно заданного порогового размера). Когда таблица становится слишком
большой для одного сервера, она обслуживается кластером, на каждом узле которого размещается
подмножество регионов таблицы.
Таким образом, регионирование обеспечивает распределение нагрузки на таблицу. Совокупность
отсортированных регионов, доступных по сети, образует общее содержимое распределенной
таблицы.
Compaction.
Поскольку данные по одному региону могут храниться в нескольких HFile, для ускорения работы
HBase периодически объединяет их, выполняя одну из 2-х операций под названием compaction:
 Minor Compaction, который запускается автоматически и выполняется в фоновом режиме.
Имеет низкий приоритет по сравнению с другими операциями.
 Major Compaction, запускаемый вручную или в случае наступления определенных условий
(триггеров), например, срабатывание по таймеру. Имеет высокий приоритет и может
существенно замедлить работу кластера. Эту операцию рекомендуется выполнять при
невысокой нагрузке на кластер. Во время выполнения Major Compaction также происходит
физическое удаление данных, ранее помеченных соответствующей меткой tombstone.
Только 4 основные действия, которые отличаются от классических SQL-запросов.
 Put – добавить новую или обновить существующую запись. Временной штамп (timestamp)
этой записи может быть задан вручную или установлен автоматически как текущее время.
put ’<table name>’,’row1’,’<colfamily:colname>’,’<value>’
 Get – получить данные по определенному первичному ключу (RowKey). Можно указать
Column Family, откуда будет считана информация и количество версий, которые требуется
прочитать.
get ’<table name>’,’row1’
 Scan – поочередное чтение записей, начиная с указанной. Можно указать запись, до которой
следует читать или количество записей, которые необходимо считать. Также в параметрах
операции отмечается Column Family, откуда будет производиться чтение и максимальное
количество версий для каждой записи.
scan ‘<table name>’
  Delete – пометить определенную версию к удалению. Физического удаления при этом не
произойдет, оно будет отложено до следующего Major Compaction, о котором мы рассказали
выше.
delete ‘<table name>’, ‘<row>’, ‘<column name >’, ‘<time stamp>’
Сравнение с классической базой данных.
Классическая реляционная HBase
Фиксированная структура данных, Распределенное хранилище и ориентация
ориентация на строки. на столбцы.
Предопределенная структура данных. Динамическое расширение столбцов.
Нагрузка на ввод-вывод и дорогостоящее Поддерживает обычное коммерческое
расширение. оборудование, снижая стоимость
расширения

Хранение данных по строкам и по столбцам.

По строкам (классическая) По столбцам (HBase)
Данные хранятся по строкам в базовой Данные хранятся по столбцам в базовой
файловой системе. Как правило, файловой системе.
фиксированная суммарное пространство Преимущества: данные можно читать или
выделяется для каждой строки. вычислять по столбцам.
Преимущества: данные можно добавлять, Недостатки: при чтении строки может
изменять или читать построчно. потребоваться несколько операций ввода-
Недостатки: при запросе данных в столбце вывода.
получаются некоторые ненужные данные.

Сценарии использования.
 Массивные данные (ТБ и ПБ)
 Функция атомарности, согласованности, изоляции, долговечности (ACID) поддерживаемых
традиционными реляционными базами данных, не требуется.
 Высокая пропускная способность.
 Эффективное случайное чтение массивных данных.
 Высокая масштабируемость.
 Одновременная обработка структурированных и неструктурированных данных.
Архитектурные компоненты для распределенной работы с данными.
 Region Server - обслуживает один или несколько регионов. Region Server включает memstore
для кэширования часто используемых строк в памяти.
 Master Server – главный узел в кластере, управляющий распределением регионов по
региональным серверам, включая ведение их реестра, управление запусками регулярных
задач и других организационных действий.
 Вычислительная модель MapReduce может использоваться для загрузки большого объема
данных, при этом на этапе Reduce выполняется загрузка данных в таблицу – локальная
запись данных на соответствующем Region Server.
Apache ZooKeeper.
Отвечает за координацию работ между сервисами HBase отвечает служба, предназначенная для
управления конфигурациями и синхронизации сервисов. Серверы ZooKeeper и HMaster
предоставляют клиентам информацию о топологии кластера. Клиенты подключаются к ним и
загружают список регионов, содержащихся в региональных серверах, и диапазонах ключей,
размещенных в регионах.
Методы высокой доступности данных и отказоустойчивости.
 Развертывание на нескольких экземплярах HMaster и ZooKeeper;
 Распределение данных по многим узлам гарантирует, что сбой одного из них не приведет к
потере доступности данных;
  Формат HFile, хранящий данные непосредственно в HDFS, можно читать и записывать с
помощью многих инструментов Apache стека Big Data (например, Hive, Pig, MapReduce,
Tez), что позволяет практически в режиме реального времени анализировать данные, не
копируя их в другие хранилища.
Apache Hive (SQL-Like Interface)
SQL-интерфейс доступа к данным для платформы Apache Hadoop.
Hive позволяет выполнять запросы, агрегировать и анализировать данные используя SQL
синтаксис.
Для данных в файловой системе HDFS используется схема доступа на чтение, позволяющая
обращаться с данными, как с обыкновенной таблицей или реляционной СУБД. Запросы HiveQL
(аналог SQL) транслируются в Java-код заданий MapReduce.
Hive.
Hive — это инструмент хранилища данных и управления распределенными данными, работающий
на Hadoop и поддерживающий PB-уровень запросов (до петабайтов).
Hive предоставляет следующие функции:
 Гибкий ETL (извлечение/преобразование/загрузка).
 Поддержка вычислительных возможностей, таких как MapReduce, Tez и Spark.
 Прямой доступ к файлам HDFS и HBase.
 Простота использования и программирования
Движок, позволяющий транслировать SQLlike запросы (HiveQL) в серии Map-Reduce job-ов. Язык
запросов похож на SQL92. Есть JDBC – коннектор, можно использовать с существующим кодом.
Информация хранится в обычных файлах (на HDFS или S3) (Text file, Sequence file, RDFiles,
Parquet)
Мета-информация хранится в классической БД (по умолчанию Apache Derby, но может быть
MySQL, Postgres или Oracle)
Компоненты.
UI Пользовательский интерфейс - позволяет выполнять запросы и команды в Hive:
 Hive Web UI
 Командная строка Hive CLI или Beeline
 Hive HD Insight (на сервере Windows)
 Apache Zeppelin или HUE server
MetaStore – хранилище метаданных.
Hive хранит схему таблиц Hive в хранилище метаданных Hive. Хранит метаданные для таблиц
Hive — схему на чтение (schema-on-read) , расположение, информацию о столбцах в таблице, типы
данных, ACL и т.д.
Metastore используется для хранения всей информации о таблицах и разделах, находящихся в
хранилище. По умолчанию хранилище метаданных запускается в том же процессе, что и служба
Hive, а хранилищем метаданных по умолчанию является база данных DerBy.
 Hive QL Process Engine (процессор HiveQL)
Вместо написания программ MapReduce на Java мы можем написать запрос на HiveQL для
дальнейшей компиляции и исполнения задания MapReduce
 Execution Engine (Механизм выполнения)
Составной частью процесса HiveQL Engine и MapReduce является механизм выполнения Hive.
Механизм выполнения обрабатывает запрос и генерирует план задач MapReduce.
 HDFS или HBASE
Распределенная файловая система Hadoop или HBASE — это методы хранения данных в файловой
системе.
 SerDe:
Serializer, Deserializer дает инструкции Hive по обработке записи.
HiveQL.
 Запросы Hive создаются на языке запросов HiveQL, который основан на языке SQL, но не имеет
полной поддержки стандарта SQL-92. Однако, этот язык позволяет программистам использовать их
собственные запросы, когда неудобно или неэффективно использовать возможности HiveQL.
HiveQL может быть расширен с помощью пользовательских скалярных функций (UDF), агрегаций
(UDAF кодов) и табличных функций (UDTF).
Data Definition Language (DDL, используется для создания и изменения таблиц и других
объектов в базе данных).

Используется для создания таблицы

CREATE
или базы данных
Используется для отображения базы
SHOW
данных, таблицы, свойств и т.д.
Используется для внесения изменений в
ALTER
существующую таблицу
DESCRIBE Описывает столбцы таблицы
Используется для усечения и удаления
TRUNCATE строк таблицы без возможности
восстановления
Удаляет данные таблицы
DELETE
с возможностью восстановления
Типовое применение Hive/
 Анализ интересов
 Анализ поведения пользователей
 Демонстрация разделов
 Статический анализа данных
 Анализ журнала
 Анализ текста
Преимущества Hive.
 Высокая надежность и устойчивость
 HiveServer в кластерном режиме
 Двойное Meta-Store
 Повторные запрос через определенное время
 SQL-подобный код запросов
 SQL-подобный синтаксис
 Большое количество встроенных функций
 Масштабируемость
 Формат хранения, определяемый пользователем
 Определяемые пользователем функции
 Множество интерфейсов (Beeline, JDBC, Thrift, Python, ODBC)
Недостатки Hive.
 Высокая задержка (по умолчанию Map-Reduce с соответствующей задержкой)
 Не поддерживается материализация
 Не поддерживаются материализованные представления (объекты базы данных, содержащие
результат выполнения запроса)
 Обновление данных, вставка и удаление не может быть выполнено с просмотром данных.
 Неприменимо к OLTP (не поддерживается добавление, обновление и удаление данных на
уровне столбца).