Некоторое время я тестировал Microsoft Azure DataFactory, чтобы сравнить ее функциональность (пока не производительность) с существующим ETL-решением моего клиента — IBM InfSphere DataStage 11 (под YARN, но в данном случае это не важно).
Это сравнение было призвано помочь клиенту решить, использовать ли ADF или DataStage в среднесрочной перспективе для процессов ETL. Я не понимал мотивы клиента по переносу всех ETL-процессов на движок ADF, поэтому пытался найти аргументы для предотвращения этого процесса.
Результаты моего короткого сравнения ниже.
Возможно, оно также будет вам полезно при составлении предложений для клиентов.
Это сравнение не является исчерпывающим, в нем перечислены только аспекты, которые лично я считаю важными для разработки ETL-процессов.
Немного о приоритетах сравнения
Azure DataFactory позиционируется как ETL-инструмент, не требующий написания кода (code-free), и с этой точки зрения я попытался его рассмотреть.Однако все мы знаем, что рано или поздно возникает потребность в расширении функциональности любой платформы обработки данных с помощью ее костыльных расширений — внешних модулей, функций трансформации и т. д. Поэтому я попытался оценить уровень, на котором возникает необходимость реализации самостоятельной реализации.
-писанные модули.
Чем выше этот уровень, тем ниже порог входа для специалистов (нет необходимости требовать привлечения сеньоров), тем гибче платформа и дешевле обойдется разработка простых и средней сложности процедур передачи данных.
Также моей целью было не сравнивать все продукты, входящие в комплект IBM Information Server и все приложения Azure (профилирование данных, управление качеством данных, управление данными и т. д.), я старался сконцентрироваться только на функциональности инструментов ETL. Я также откровенно предвзят: у меня больше опыта работы с DataStage, чем с Azure DataFactory, поэтому я, возможно, что-то упустил в своих выводах.
Предлагаю тогда обсудить спорные вопросы в комментариях.
Кроме того, Azure DataFactory — достаточно молодой продукт и продолжает развиваться.
Возможно, некоторые возможности из предложенного списка будут добавлены позже.
Возможно, но крайне маловероятно, что данная статья этому поспособствует. Но мне бы хотелось иметь в своем арсенале более мощные ETL-инструменты.
Для каждого пункта я постарался выбрать несколько возможных сценариев применения, а также некоторые способы обхода выявленных ограничений, если таковые имеются.
1. Отсутствие возможности манипулировать полями во время выполнения.
Грубо говоря, все метаданные потока должны быть указаны во время разработки.
Мы не сможем динамически выбирать, какие поля какие действия выполнять во время выполнения.
Отсутствие такой возможности сильно ограничивает разработчика при создании общих правил трансформации.
Например, данные, загруженные в Staging или Landing Area, не содержат сложных правил преобразования.
Как правило, при историзации данных необходимо добавить несколько технических полей, таких как дата загрузки, идентификатор источника и, возможно, номер текущей версии строки.
Все остальные поля, содержащие данные, необходимо проталкивать без изменений, независимо от их названий и количества.
В DataStage эта проблема решается с помощью распространения столбцов во время выполнения (RCP), схем данных OSH и этапов импорта/экспорта столбцов (стадий).
Пример: Для всех входящих таблиц создайте два столбца KEY_HASH и DATA_HASH, содержащие MD5-хеш ключевых полей и полей данных соответственно.
Конечно, количество ключевых полей может варьироваться от таблицы к таблице.
Их имена также не детерминированы.
Решение на ДС :
Мы просто извлекаем все столбцы из исходной таблицы, на основе файла схемы этой таблицы (это файлы, содержащие описание метаданных таблицы), на этапе CE_KeyHash генерируем техническое поле TECH_KEY, содержащее все ключевые поля таблицы.
таблицы, на этапе CS_KEY вычисляем хеш этого поля, а на этапе CS_DataHash вычисляем хеш всех полей, кроме технического.
Возможные решения по АПД : Использование функций Azure. Да, это выход. Но мы вернемся к этому позже.
Но это уже выходит за рамки парадигмы без кода.
В некоторых случаях можно импортировать метаданные каждой таблицы с помощью этапа Lookup, на основе него сформировать SQL-запрос, содержащий конкатенацию нужных столбцов и хэш-вычисления.
Но это возможно только в том случае, если источник данных поддерживает SQL, либо необходимо создавать внешние таблицы над файлами в Polybase (как в Hive — внешние таблицы).
Ну или создайте для каждой таблицы отдельный DataFlow или Pipeline. Фактически, это очень востребованная функция ETL. Его серьезно не хватает в АПД.
А без него невозможно создать общие для нескольких источников процедуры передачи данных.
Время разработки увеличивается, а поддержка решений ухудшается.
Использование функций Azure сразу же увеличивает стоимость и усложняет процесс разработки.
Так как теперь разработчику необходимо согласовывать использование функций (которые оплачиваются за каждый вызов) с лицом, ответственным за бюджет проекта.
2. Нет взаимодействия между строками
Это означает, что вы не можете создавать состояния, определяющие способ обработки входящей строки по значению предыдущих полей (это, конечно, важно, когда данные сортируются в каждой секции).Кроме того, невозможно создать несколько исходящих строк для одной входящей строки.
Классический пример: WordCount — подсчет вхождения каждого слова в документе.
Один из способов решить эту проблему с помощью ETL — превратить строку из N слов в N строк, содержащих эти слова и только эти слова.
А дальше — агрегация и подсчет вхождений каждого слова.
Обратите внимание, что количество строк после преобразователя T_ExtractWords больше, чем до него.
Я не смог придумать, как решить эту проблему стандартными средствами ADF. Это не значит, что этого нельзя сделать – вовсе нет. Но опять же, вам придется дополнительно подготовить данные перед подачей их в этот ETL-инструмент. Опять же возникает необходимость привлечения внешних утилит и языков программирования — Java, .
Net, Spark…
3. Нет поддержки XML.
Ну тут все просто — читать и писать XML-файлы стандартными средствами нельзя.Я был немного разочарован, когда не смог найти способ сделать это.
Я подумал, что, вероятно, на меня повлияла неопытность в работе с ADF, поэтому я попытался поискать на форумах и ресурсах Microsoft. Нашел этот вопрос и ответ .
Те.
предлагается использовать LogicApp для преобразования XML в какой-либо другой формат, подходящий для DataFactory, или для программного чтения XML (а как насчет кода без кода?).
LogicApp, конечно, оплачивается отдельно.
Ну ребята, всё-таки 21 век.
Шутки из маршрутки
Сравните с возможностями этапа иерархических файлов DataStage. Тоже не без греха, его нужно настраивать под большой XML, но это целый комбайн, позволяющий производить преобразования непосредственно со структурой XML-файла: объединять данные между тегами, трансформировать структуру без XSLT (но это с ним тоже можно) и выполнять другие операции.
4. Невозможно удалить общие части процессов.
Сформулировать это было сложно, уточню: некоторые разные ETL-процессы могут иметь общие области трансформации.
Итак, вы не можете вынести этот раздел и сохранить его отдельно, создав ссылку на этот раздел в каждом процессе.
Это важная возможность.
Так как это сводит к минимуму процесс поддержки и редактирования процессов.
Если бы была такая возможность, мы могли бы изменить эту общую область только один раз, без необходимости редактировать каждый из процессов.
Это похоже на помещение обычного фрагмента кода в библиотеку.
Вы можете создавать общие контейнеры в DataStage. Я именно об этом и говорю.
Я продемонстрирую на примере.
Вот содержимое контейнера.
Все, что он делает, это проверяет наличие внешних ключей.
Вот его содержимое: 
И вот как мы можем использовать его в одном из процессов (а также и в других процессах).
Нам просто нужно указать некоторые параметры, которые будут определять, какие ключи и из каких таблиц необходимо проверять: 
5. Изоляция пользовательских расширений и потока данных.
Уже в первом пункте нам нужно было использовать любую возможность расширения функционала за счет сторонних инструментов.
Языки программирования или утилиты.
Таким образом, вы не сможете реализовать функцию, которую вы написали в DataFlow. Это возможно только в конвейере.
Те.
все преобразования источников данных (объединения, поиск, преобразования окон и т. д.) можно выполнить в DataFlow, а что-то более сложное можно сделать в Pipeline. Это тоже немного обескураживает. Те.
данные либо нужно поместить в какое-то временное хранилище (BlobStorage или в таблицы базы данных), а затем прочитать, чтобы применить свои собственные преобразования (например, именно так мы и хотели — вычислять хэши полей во время выполнения).
Такое разделение увеличивает количество сущностей в процессах передачи данных.
Или заставляет использовать только конвейер, объединения и другие операции, и в этом случае вам придется выполнять их вручную.
6. Слабые возможности описания метаданных, слабое управление обнуляемыми полями.
Как объяснил нам архитектор Microsoft, под капотом ADF DataFlow находится Spark. Вероятно, поэтому язык описания метаданных достаточно примитивен, т.е.
можно указать типы данных полей, достаточно близкие к типам, с которыми оперирует Spark: строковые, числовые, временные метки.
Вы не можете указать максимальную длину строки или указать флаг обнуления поля.
Это приводит к таким трудностям, как:
- Невозможность работы с файлами с фиксированной длиной полей.
Такие данные часто генерируют устаревшие системы, мейнфреймы, AS400 и т. д. Выход, конечно, есть — использовать ручное разделение полей с помощью подстроки (data, start, len), но поддерживать все это не очень весело.
- Невозможно контролировать появление пустых значений в полях, которые не должны быть пустыми.
Например, вы не можете объявить определенное поле Not Null и автоматически отклонить его, если появится нулевое значение.
Каждое поле придется проверять на нули вручную.
Послесловие
Многие, наверное, подумают, что я пытался сравнить слона и пингвина.Но зачастую компании, принимая решение о миграции в облако, думают, что необходимо заменить все приложения.
Такое решение часто бывает необдуманным и может привести к головной боли консультантов и увеличению затрат на разработку и поддержку решения.
Не говоря уже о торговом замке и прочих приятностях.
Этим небольшим сравнением я попытался убедить руководство моего клиента не делать поспешных выводов при выборе ETL-решения при миграции в облако Azure. Пока статья находилась в черновиках, мы встретились с архитектором облачных решений Microsoft, чтобы он мог подтвердить или опровергнуть мои выводы и уточнить, есть ли в дорожной карте что-то, что могло бы облегчить решение проблем, описанных в главах выше.
.
Все моменты, кроме манипулирования полями во время выполнения, были подтверждены и некоторые объяснены с точки зрения истории развития продуктов.
Что касается распространения столбцов времени выполнения, архитектор взял перерыв, чтобы обсудить это с коллегами, но не вернулся к нам со своими выводами.
Прошло уже два месяца.
Вероятно, полностью реализовать такую схему манипулирования данными пока невозможно.
P.S. Клиент отказался использовать ADF для ETL, теперь рассматривает между Spark и DataStage :-) Теги: #Microsoft Azure #Большие данные #Инжиниринг данных #etl #Datastage #azure datafactory
-
Парменид
19 Oct, 24 -
Как Зарекомендовать Себя В Интернете
19 Oct, 24 -
Система Распределения Агентской Сети
19 Oct, 24 -
Sudo И Другие В .Bashrc
19 Oct, 24 -
Еще Один Сэд Или...?
19 Oct, 24 -
«Кадры», Вып. 5. Посвящается Умпутуну
19 Oct, 24 -
Женщина-Администратор. Что Ты Знаешь О Них?
19 Oct, 24
