Слайды моего доклада: "Практика миграции реляционных баз данных в экосистему Hadoop"
В докладе я доказываю, что возможен полный отказ от реляционных баз данных в пользу экосистемы Hadoop. В мире (к сожалению не в России) эта тема уже перекраивает рынок, уже наносится удар по традиционным базам данных.
Скоро ожидаются скринкасты.
Если вы начинаете проект миграции - задавайте мне вопросы - я с удовольствием на них отвечу.
Приглашайте меня в качестве консультанта и архитектора - я помогу собрать команду, обосновать инвестиции и запустить проект.
2. На сколько данные должны быть
"большими", чтобы оправдать
использование экосистемы Hadoop?
3. На сколько данные должны быть
"большими", чтобы оправдать
использование экосистемы Hadoop?
4. На сколько данные должны быть
"большими", чтобы оправдать
использование экосистемы Hadoop?
Что же мне сделать чтобы продлить
жизнь нашей базы данных
еще хотя бы на полгода?
5. Если же у вас все хорошо и вы уверены
Что БД не будет тормозить еще года 3
JUST RELAX…
7. •Реляционная модель была создана
в 70х годах
•3я нормальная форма
•Построковое хранение
Что не так с реляционными БД?
8. •умеют работать только
со структурированными данными
•имеют плоскую структуру
Что не так с реляционными БД?
9. Чтобы сохранить в реляционной БД 2 разные бизнес-сущности нам
потребуется как минимум 2 таблицы
Чтобы данные из этих 2х таблиц объединить:
• loop join
• merge join
• hash join
10. Плюс реляционной модели - простота
• не надо думать о типах контейнеров, в которых хранятся
данные
• о ключах распределения
• о сложной многомерной структуре таблиц
11. • необходимость выбора единственно правильного индекса и партиций
• резкая деградация производительности по мере роста количества данных
• сложности масштабирования
• не видно другие данные, которые не были загружены непосредственно в БД
• сложность ETL - например, приходится парсить многомерный JSON-файл и
разворачивать его в реляционную модель
Проблемы реляционной модели
12. Исключением является
• с версии 9.4 появился полноценный
json тип данных – jsonb
• документо-ориентированное
хранилище HSTORE
• cпасибо Олегу Бартунову
и Александру Короткову за это
14. Требования бизнеса
к современным системам обработки данных
• Shared nothing – распределённая вычислительная архитектура
• MPP (Massive Parallel Processing) – параллельная обработка
данных на многих вычислительных узлах
• Различные типы контейнеров с данными, а так же просто
файлы, видны друг другу и доступны для прямых запросов,
операций объединения и трансформации
15. Требования бизнеса
к современным системам обработки данных
• Одинаково эффективная работа как со структурированными
так и с неструктурированными данными
• Выполнение сложных вычислений на лету
• Снижение сложности модели БД и ETL-процесса
16. Требования бизнеса
к современным системам обработки данных
• Автошардинг
• Кроссплатформенность
• Неограниченное линейное масштабирование
• Повышенная отказоустойчивость
17. Смотря на эти требования можно предположить,
что разработать такую платформу достаточно сложно
22. За счет чего в экосистеме Hadoop
удалось удовлетворить все те требования,
которые мы сформировали немного ранее?
23. • вычислительный узел в экосистеме
Hadoop это независимый полноценный
компьютер
• на каждом вычислительном узле
расположена своя уникальная часть
данных
• задача Map запускается на том узле, где
лежат входные данные, т.е. вычисления
перемещаются к данным
24. • Данные равномерно распределяются по
узлам кластера
• Редьюсеры запускаются на наиболее
свободных вычислительных нодах
• Мастер-нода не перегружена
метаданными и не является единой
точкой отказа
• Промежуточные данные map-reduce
джоба больше не приземляются на диск,
а кешируются в памяти
28. Описание контейнеров
• Текстовые файлы и документы (csv, json, pdf etc.)
• SequenceFile - список ключ-значение (например ключ:
название файла, значение: содержимое файла)
• MapFile - сортированный по ключу список ключ-значение
29. Описание контейнеров
• Avro - многомерное row-oriented хранилище, таблицы
которого описываются json-схемой
• ORCFile - многомерное column-oriented хранилище с
поддержкой требований ACID
• HFile - контейнер с данными NoSQL базы данных HBase
32. HIVE и загрузка csv-файлов
2. Загрузим csv в таблицу
3. Парсим csv-файл на лету
33. HIVE и загрузка json-файла в контейнер AVRO
1. Конвертируем json во внутренный формат AVRO
2. В HIVE создаем таблицу
3. ... и загружаем в нее наш json
36. Структура данных HBase
• таблица - пространство имен, объединяющее множество строк
• строка (row) - контейнер, состоящий из набора произвольного
количества версионированных пар ключ-значение и ключа
строки (row key)
• regions - объединяет строки по ключу строки и физически
разделяет по разным файлам Hfile
37. Структура данных HBase
• Column - ключ в паре ключ-значение
• Column Family - физически разделяет один или несколько
столбцов по разным файлам HFile
• Value - значение в паре ключ-значение
• Timestamp - время в паре ключ-значение, определяющее
версию значения. По-умолчанию отображается значение с
самой свежей версией
43. Требования ACID и ограничения целостности
• в HIVE 0.14 добавлена поддержка требований ACID для
контейнера ORCFile
• Yahoo разрабатывает Omid для HBASE
• Facebook разрабатывает HydraBase для HBASE
45. Нужно совсем немного
• ETL - Talend либо Python, PIG, Sqoop
• Подсистема хранения - файлы as-is и контейнеры
MapFile, Avro, HBASE
• Запросы - Hive
46. Почему пилот не стартует?
• недостаточная осведомленность менеджеров
• будет ли профит от Hadoop
• взлетит ли вообще что-нибудь?
• а не потратим ли мы впустую деньги на новую
необкатанную технологию?
47. Мифы о команде
• 1 человек сможет
во всем разобраться
• нам обязательно
нужен JAVA-разработчик