Будь-яка операція з великими даними потребує великих обчислювальних потужностей. Звичайне переміщення даних з бази на Hadoop може тривати тижні або коштувати, як крило літака. Не хочете чекати та витрачатися? Збалансуйте навантаження на різні платформи. Один із способів – pushdown-оптимізація.
Я попросив провідного в Росії тренера з розробки та адміністрування продуктів Informatica Олексія Ананьєва розповісти про функцію pushdown-оптимізації в Informatica Big Data Management (BDM). Колись навчалися працювати з продуктами Informatica? Швидше за все, саме Олексій розповідав вам ази PowerCenter і пояснював, як будувати мапінги.
Олексій Ананьєв, керівник напряму з навчання DIS Group
Що таке pushdown?
Багато хто з вас уже знайомий з Informatica Big Data Management (BDM). Продукт вміє інтегрувати великі дані з різних джерел, переміщати їх між різними системами, забезпечує до них легкий доступ, дозволяє профільувати їх та багато іншого.
В умілих руках BDM здатний творити дива: завдання виконуватимуться швидко та з мінімальними обчислювальними ресурсами.
Теж так хочете? Навчіться використовувати функцію pushdown у BDM для розподілу обчислювального навантаження між різними платформами. Технологія pushdown дозволяє перетворити мапінг на скрипт і вибрати середовище, в якому цей скрипт запуститися. Можливість такого вибору дозволяє комбінувати сильні сторони різних платформ і досягати їхньої максимальної продуктивності.
Для налаштування середовища виконання скрипта необхідно вибрати тип pushdown. Скрипт може бути повністю запущений на Hadoop або частково розподілений між джерелом та приймачем. Є 4 можливі типи pushdown. Мапінг можна не перетворювати на скрипт (native). Мапінг можна виконати максимально на джерелі (source) або повністю (full). Також мапінг можна перетворити на скрипт Hadoop (none).
Pushdown-оптимізація
Перераховані 4 типи можна по-різному поєднувати – оптимізувати pushdown під конкретні потреби системи. Наприклад, найчастіше доцільно витягти дані з бази даних, застосовуючи її власні можливості. А перетворити дані – силами Hadoop, щоби саму базу не перевантажувати.
Давайте розглянемо випадок, коли джерело і приймач перебувають у БД, а платформу виконання перетворень можна вибрати: залежно від налаштувань це буде Informatica, сервер БД чи Hadoop. Такий приклад дозволить найточніше зрозуміти технічну сторону роботи цього механізму. Звичайно, в реальному житті така ситуація не виникає, але для демонстрації функціоналу вона підходить найкращим чином.
Візьмемо мапінг для читання двох таблиць у єдиній базі даних Oracle. А результати читання нехай записуються до таблиці у цій самій базі. Схема мапінгу буде така:
У вигляді мапінгу на Informatica BDM 10.2.1 це виглядає таким чином:
Тип pushdown – native
Якщо ми виберемо тип pushdown native, то мапінг буде виконано на сервері Informatica. Дані буде прочитано з сервера Oracle, перенесено на сервер Informatica, трансформовано там і передано до Hadoop. Іншими словами, ми отримаємо нормальний ETL-процес.
Тип pushdown - source
При виборі типу source ми отримуємо можливість розподілити процес між сервером бази даних (БД) і Hadoop. При виконанні процесу з цим налаштуванням в базу полетять запити на вибір даних із таблиць. А решта виконуватиметься у вигляді кроків на Hadoop.
Схема виконання виглядатиме так:
Нижче – приклад налаштування середовища виконання.
У цьому випадку мапінг виконуватиметься у два кроки. У його налаштуваннях ми побачимо, що він перетворився на скрипт, який буде відправлено на джерело. Причому об'єднання таблиць та перетворення даних виконається у вигляді перевизначеного запиту на джерелі.
На малюнку нижче ми бачимо оптимізований мапінг на BDM, а на джерелі – перевизначений запит.
Роль Hadoop у цій конфігурації зведеться до управління потоком даних – диригування ними. Результат запиту буде направлений до Hadoop. Після завершення читання файл із Hadoop буде записаний до приймача.
Тип pushdown – full
При виборі full мапінг повністю перетворитися на запит на БД. А результат запиту буде направлено на Hadoop. Схема такого процесу представлена нижче.
Приклад налаштування наведено нижче.
В результаті ми отримаємо оптимізований мапінг, схожий на попередній. Різниця лише тому, що вся логіка переноситися на приймач як перевизначення його вставки. Приклад оптимізованого мапінгу представлений нижче.
Тут, як і в попередньому випадку, Hadoop виконує роль диригента. Але тут читання джерела проводитися повністю, а далі на рівні приймача виконується логіка обробки даних.
Тип pushdown – null
Ну і останній варіант - тип pushdown, в рамках якого наш мапінг перетвориться на скрипт на Hadoop.
Оптимізований мапінг тепер виглядатиме так:
Тут дані із файлів-джерел спочатку будуть прочитані на Hadoop. Потім його засобами ці два файли будуть об'єднані. Після цього дані будуть перетворені та вивантажені у БД.
Розуміючи принципи pushdown-оптимізації, можна дуже ефективно організувати багато процесів роботи з великими даними. Так, нещодавно одна велика компанія всього за кілька тижнів вивантажила зі сховища в Hadoop великі дані, які до цього збирала кілька років.
Джерело: habr.com