Слайды моего доклада: "Практика миграции реляционных баз данных в экосистему Hadoop" В докладе я доказываю, что возможен полный отказ от реляционных баз данных в пользу экосистемы Hadoop. В мире (к сожалению не в России) эта тема уже перекраивает рынок, уже наносится удар по традиционным базам данных. Скоро ожидаются скринкасты. Если вы начинаете проект миграции - задавайте мне вопросы - я с удовольствием на них отвечу. Приглашайте меня в качестве консультанта и архитектора - я помогу собрать команду, обосновать инвестиции и запустить проект.

1. Практика миграции
реляционных баз данных в экосистему Hadoop
Юрий Петров
@gobigdatainfo
апрель, 2015

2. На сколько данные должны быть
"большими", чтобы оправдать
использование экосистемы Hadoop?

3. На сколько данные должны быть
"большими", чтобы оправдать
использование экосистемы Hadoop?

4. На сколько данные должны быть
"большими", чтобы оправдать
использование экосистемы Hadoop?
Что же мне сделать чтобы продлить
жизнь нашей базы данных
еще хотя бы на полгода?

5. Если же у вас все хорошо и вы уверены
Что БД не будет тормозить еще года 3
JUST RELAX…

6. Что не так с реляционными БД?

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пасибо Олегу Бартунову
и Александру Короткову за это

13. Нереляционный подход
NoSQL, BigData

14. Требования бизнеса
к современным системам обработки данных
• Shared nothing – распределённая вычислительная архитектура
• MPP (Massive Parallel Processing) – параллельная обработка
данных на многих вычислительных узлах
• Различные типы контейнеров с данными, а так же просто
файлы, видны друг другу и доступны для прямых запросов,
операций объединения и трансформации

15. Требования бизнеса
к современным системам обработки данных
• Одинаково эффективная работа как со структурированными
так и с неструктурированными данными
• Выполнение сложных вычислений на лету
• Снижение сложности модели БД и ETL-процесса

16. Требования бизнеса
к современным системам обработки данных
• Автошардинг
• Кроссплатформенность
• Неограниченное линейное масштабирование
• Повышенная отказоустойчивость

17. Смотря на эти требования можно предположить,
что разработать такую платформу достаточно сложно

18. Но решение пришло,
и пришло откуда
не ждали

19. Всему виной взрывной рост данных

20. Дуг Каттинг и Майк Кафарелла в 2005 году
возглавили разработку Hadoop в Yahoo

21. Спасибо,

22. За счет чего в экосистеме Hadoop
удалось удовлетворить все те требования,
которые мы сформировали немного ранее?

23. • вычислительный узел в экосистеме
Hadoop это независимый полноценный
компьютер
• на каждом вычислительном узле
расположена своя уникальная часть
данных
• задача Map запускается на том узле, где
лежат входные данные, т.е. вычисления
перемещаются к данным

24. • Данные равномерно распределяются по
узлам кластера
• Редьюсеры запускаются на наиболее
свободных вычислительных нодах
• Мастер-нода не перегружена
метаданными и не является единой
точкой отказа
• Промежуточные данные map-reduce
джоба больше не приземляются на диск,
а кешируются в памяти

25. Что объединяет всю экосистему Hadoop?

26. Распределенная файловая система HDFS

27. Переходим
к практической
части доклада

28. Описание контейнеров
• Текстовые файлы и документы (csv, json, pdf etc.)
• SequenceFile - список ключ-значение (например ключ:
название файла, значение: содержимое файла)
• MapFile - сортированный по ключу список ключ-значение

29. Описание контейнеров
• Avro - многомерное row-oriented хранилище, таблицы
которого описываются json-схемой
• ORCFile - многомерное column-oriented хранилище с
поддержкой требований ACID
• HFile - контейнер с данными NoSQL базы данных HBase

30. SQL-запросы и HIVE
Спасибо,

31. HIVE и загрузка csv-файлов
1. Создаем таблицу test_data

32. HIVE и загрузка csv-файлов
2. Загрузим csv в таблицу
3. Парсим csv-файл на лету

33. HIVE и загрузка json-файла в контейнер AVRO
1. Конвертируем json во внутренный формат AVRO
2. В HIVE создаем таблицу
3. ... и загружаем в нее наш json

34. Нереляционная (NoSQL) БД HBase

35. Спасибо,

36. Структура данных HBase
• таблица - пространство имен, объединяющее множество строк
• строка (row) - контейнер, состоящий из набора произвольного
количества версионированных пар ключ-значение и ключа
строки (row key)
• regions - объединяет строки по ключу строки и физически
разделяет по разным файлам Hfile

37. Структура данных HBase
• Column - ключ в паре ключ-значение
• Column Family - физически разделяет один или несколько
столбцов по разным файлам HFile
• Value - значение в паре ключ-значение
• Timestamp - время в паре ключ-значение, определяющее
версию значения. По-умолчанию отображается значение с
самой свежей версией

38. Таблица с данными HBASE в виде json-файла

39. Phoenix
быстрый SQL-интерфейс для HBASE

40. Реляционная vs NoSQL модель

41. Реляционная модель

42. NoSQL модель

43. Требования ACID и ограничения целостности
• в HIVE 0.14 добавлена поддержка требований ACID для
контейнера ORCFile
• Yahoo разрабатывает Omid для HBASE
• Facebook разрабатывает HydraBase для HBASE

44. ЗАКЛЮЧЕНИЕ
•минимальный стек технологий
•что сделать, чтобы проект миграции все-же
начался
•состав и компетенции команды

45. Нужно совсем немного
• ETL - Talend либо Python, PIG, Sqoop
• Подсистема хранения - файлы as-is и контейнеры
MapFile, Avro, HBASE
• Запросы - Hive

46. Почему пилот не стартует?
• недостаточная осведомленность менеджеров
• будет ли профит от Hadoop
• взлетит ли вообще что-нибудь?
• а не потратим ли мы впустую деньги на новую
необкатанную технологию?

47. Мифы о команде
• 1 человек сможет
во всем разобраться
• нам обязательно
нужен JAVA-разработчик

48. Состав команды
• Hadoop-евангелист и архитектор (это я )
• Linux-гуру
• ETL developer
• HIVE developer/Data Mining Analyst

49. Юрий Петров
Hadoop-консалтинг, корпоративное обучение
Мои контакты:
SKYPE: petrov.y.v
Email: petrov@gobigdata.info
Facebook: http://facebook.com/gobigdata.info
Linkedin: https://www.linkedin.com/in/petrovgobigdata
Блог: http://gobigdata.info
Спасибо за внимание!