Bash-скрипт vs. хранимые процедуры vs. Традиционные инструменты ETL vs. Python-скрипт

История оркестрации задач

Оркестратор нужен всем, особенно в том случае, когда стек становится сложнее. Но как насчет cron, простого скипта Python или даже bash? А как насчет хранимых процедур, SSIS? В этой главе мы рассмотрим самые распространенные способы оркестрации данных.

Что выбрать? В основном, инструменты/подходы более высокого уровня, которые Вы используете для оркестрации/планирования любых задач.

Bash –скрипт и Cron

Когда я еще только начинал свою карьеру, мы с коллегами использовали bash-скрипт длиной в 500 строк, который планировал и запускал любую задачу. Он решал многие повторяющиеся задачи за один раз, каждый специалист мог использовать его повторно. Например, данный скрипт обрабатывал параметры или ошибки или загружал данные на FTP-сервер в конце рабочего дня. Это был простой, но достаточно мощный способ оркестрации задач.

Определение

Bash – скрипт - это ранняя версия инструмента оркестрации данных; он абстрагирует все, что не имеет отношения к выполнению конкретной задачи или преобразованию данных. Вы открываете новый файл и сохраняете его с окончанием .sh, добавляете в начало #!/bin/bash (или оболочку по выбору) и все!

Использование bash-скрипта в сочетании с Cron, который до сих пор популярен, - самый простой способ запланировать работу в Unix-системе. Типичное выражение cron example 0 8 * * * используется для планирования ежедневного выполнения задания в 8 утра. Это выражение является частью файла crontab, который определяет расписание для заданий cron.

Разница между Bash и Shell

Shell – скрипт - это скрипт, написанный для оболочки операционной системы. Данный термин может применяться к скриптам, написанным для любой оболочки (например, sh, csh, ksh и т. д.).

Bash – скрипты (Bourne Again SHell) пишутся для оболочки Bash, более функционального преемника оригинальной оболочки Bourne (sh, на которую ссылаются с помощью #!/bin/bash). Bash включает в себя такие оптимизации, как улучшенная работа с переменными и арифметическими операциями, которые не являются стандартными для базовых скрипов оболочки.

В своей работе я использую термины bash и shell-скриптов как взаимозаменяемые понятия.

Пример Bash-скрипта

Давайте рассмотрим достаточно сложный пример того, как выглядит общий bash-скрипт. Так мы сможем лучше понять его суть. Приведенный ниже global_run_script.sh был разработан для планирования и запуска хранимых процедур. Это многоцелевой инструмент, используемый в основном для работы с файлами в среде баз данных.

Упрощенная версия такого скрипта выглядит следующим образом:

#!/bin/bash
 
# Initialize variables
application='DEFAULT_APP'
job_status='OK'
 
# Parse arguments
for arg in "$@"; do
  key=$(echo $arg | cut -d= -f1)
  value=$(echo $arg | cut -d= -f2)
  case $key in
    GRP) ascii_group=$value ;;
    DAT) date=$value ;;
    SYS) system=$value ;;
    SRV) server=$value ;;
    APP) application=$value ;;
  esac
done
 
# Check mandatory parameter (Group)
if [ -z "$ascii_group" ]; then
  echo "Error: Group parameter is missing."
  exit 1
fi
 
# Database Interaction (Simplified)
# Assuming a function `query_database` exists for database interaction
work_date=$(query_database "SELECT TO_CHAR(work_date, 'YYMMDD') FROM system_table;")
if [ $? -ne 0 ]; then
  echo "Database query failed."
  exit 1
fi
date=${date:-$work_date}
 
# Processing ASCII files (Simplified)
echo "Processing started with the following parameters:"
echo " - Group:   $ascii_group"
echo " - Date:    $date"
[ -n "$system" ] && echo " - System:  $system"
[ -n "$server" ] && echo " - Server:  $server"
[ -n "$application" ] && echo " - App:     $application"
 
# Retrieving ASCII files (Example query)
ascii_files=$(query_database "SELECT file_name FROM ascii_files WHERE group_name = '$ascii_group';")
if [ $? -ne 0 ]; then
  echo "Error retrieving ASCII files."
  exit 1
fi
 
# Process each ASCII file
for file in $ascii_files; do
  echo "Processing file: $file"
  # File processing logic goes here (e.g., compression, moving, SQL execution)
done
 
echo "Processing completed."
 
# Finalization
# Additional cleanup or final steps can be added here

Такая версия скрипта отлично иллюстрирует все его возможности и ограничения.

Ключевые компоненты изучаемого нами скрипта:

Инициализация: проверяет, правильно ли вызван скрипт, и устанавливает переменные env.
Проверка параметров: разбор аргумента и обработка аргументов командной строки для установки различных параметров. Убеждается в том, что указаны все необходимые параметры. В противном случае скрипт фиксирует ошибку и завершает работу.
Взаимодействие с базой данных: подключение к базе данных с помощью sqlplus. Проверяет наличие ошибок и завершает работу при возникновении проблем.
Обработка файлов:

Архивация и предварительная обработка файлов: архивирует старые версии файлов и подготавливает к обработке новые файлы.
Выполнение SQL-команд: генерирует SQL-команды для выполнения для каждого файла, обрабатывает ошибки и при необходимости записывает их в журнал.
Выполнение подпроцессов: выполняет сгенерированные SQL-команды в подпроцессах и ожидает их завершения. Только после этого работа будет продолжена

Повторная проверка: проверяет вывод каждого подпроцесса на наличие ошибок, при необходимости объединяет части разделенных файлов и обрабатывает ошибки дискового пространства.
Распределение файлов: подготавливает файлы для разных хостов и выполняет другой скрипт для рассылки по FTP.
Завершение работы: запуск другого скрипта для завершения задания.

Данный скрипт показывает то, как оркестрация выполнялась в прошлом. Он сочетает в себе планирование, обработку параметров, взаимодействие с базой данных, обработку файлов и обработку ошибок.

Новые инструменты оркестрации, которые мы рассмотрим далее, являются более надежными, многофункциональными и усовершенствованными альтернативными решениями.

История и эволюция

На заре своего существования Unix была оснащена множеством небольших специализированных библиотек. По мере своего развития ей требовались все более и более сложные методы упорядочивания задач в рабочие процессы. Bash-скрипты не были предназначены для этого, но это все, что было доступно на тот момент.

Первая оболочка (Bourne shell sh) и интерфейс командной строки (CLI) появились в 1960-х и начале 1970-х годов. Позже, в 1989 году, Bash (Bourne Again SHell), улучшенная версия Bourne shell, стал основным средством системного администрирования и автоматизации задач. Он был просто в использовании, при этом был беспрецедентно гибким. Элегантность сочетания языка скриптов и утилит командной строки открывала перед специалистами в области данных множество возможностей по планированию важных задач.

До появления оболочки Bash для планирования задач по времени в системах на базе Unix использовался cron. Написанный Кеном Томпсоном, одним из создателей Unix, он был добавлен в 7 версию Unix, выпущенную в 1979 году. Cron произвел революцию в планировании задач, позволив автоматизировать их выполнение в определенное время или через определенные промежутки времени. Это было особенно важно для задач, требующих регулярного выполнения, таких как ночное резервное копирование или ежечасная проверка работоспособности системы.

Изначально Cron использовался как базовый планировщик, выполнявший задачи в заранее установленное время и дату. Однако изменение административных повлияло и на его функционал. Введенные файлы crontab сделали инструмент более гибким, теперь с его помощью можно было создавать сложные конфигурации планирования для функций.

Возможности планирования Cron в сочетании с управлением выполнением bash – скриптов сформировали эффективный механизм оркестрации задач. Эта синергия позволяла cron заниматься планированием, а bash-скрипты - выполнением и управлением задачам.

Философия Unix

Конвейеры Unix (Unix Pipes) - это эффективный способ решения задач с помощью различных библиотек Unix, передающий результат в следующий поток, позволяющий легко соединять различные шаги благодаря стандартизированному формату данных (разделение строк с помощью \n). Их можно сравнить с bash-скриптами, где мы согласно философии Unix используем самый оптимальный инструмент для каждой задачи и объединяем их вместе. Это базовые инструменты оркестрации задач, которые дожили до наших дней.

Ключевые концепты

Bash-скрипты известны своей многогранностью, поэтому выделить несколько основных концепций довольно сложно.

Однако стоит выделить их непревзойденную гибкость, позволяющую комбинировать различные команды и инструменты Unix для создания эффективных конвейеров обработки данных и рабочих процессов. Такая гибкость особенно важна при создании сложных задач по автоматизации процессов.

Во-вторых, очень важна обработка параметров, позволяющая bash- скриптам адаптироваться к различным входным параметрам и делающая их очень удобными для различных сценариев в соответствии с философией Unix.

Cron также расширяет возможности сценариев Unix благодаря своей главной функции - планированию на основе времени.

Синтаксис cron обеспечивает надежный и гибкий способ определения паттернов планирования. Другим важным аспектом cron является его способность управлять операциями на уровне всей системы, а также на уровне пользователя.

Наконец, cron известен своими минимальными накладными расходами, которые практически не нагружают системные ресурсы, обеспечивая при этом выполнение задач в соответствии с планом, что делает его надежным и эффективным планировщиком.

Хранимые процедуры

Хранимые процедуры - это еще один способ оркестрации задач, которые выполняются в базе данных. Каждая база данных имеет свой язык программирования.

Например, PL/SQL или T-SQL - популярные языки программирования, используемые для создания хранимых процедур.

Определение

Хранимая процедура - это часть кода, которая выполняется исключительно в базе данных. Вы можете выполнять команды SQL, но сверху добавлен еще один код, необходимый для работы с SQL и окружениями.

Хранимые процедуры очень мощны, даже те, на которых вырос я сам (были написаны на PL/SQL (Oracle) и T-SQL (Microsoft).

На этих языках можно писать любые хранимые процедуры, которые обычно представляют собой последовательность шагов по выполнению SQL-запроса. В отличие от объектно-ориентированного программирования, где Вы сами определяете классы, здесь все определено в одном скрипте, который используется в том случае, когда Вы не можете решить задачу с помощью обычного SQL. Они являются оркестраторами баз данных и во многом похожи на bash и cron jobs, хотя и ограничены своей базой данных.

Их главным преимуществом является высокая производительность вследствие того, что они поставляются сразу вместе с базой данных. Поэтому сетевых задержек (почти) нет, плюс язык оптимизирован под работу с конкретной базой данных. PL/SQL или T-SQL SP обрабатываются непосредственно движком базы данных, обеспечивая распараллеливание, транзакции, безопасность операций и т. д.

Простой пример, взятый из официальной доrументации Oracle, где мы настраиваем курсор с помощью SQL, заключается в том, что мы вставляем значения в таблицу на основе определенного условия:

DECLARE
   CURSOR c1 is
      SELECT ename, empno, sal FROM emp
         ORDER BY sal DESC;   -- start with highest paid employee
   my_ename VARCHAR2(10);
   my_empno NUMBER(4);
   my_sal   NUMBER(7,2);
BEGIN
   OPEN c1;
   FOR i IN 1..5 LOOP
      FETCH c1 INTO my_ename, my_empno, my_sal;
      EXIT WHEN c1%NOTFOUND;  /* in case the number requested */
                              /* is more than the total       */
                              /* number of employees          */
      INSERT INTO temp VALUES (my_sal, my_empno, my_ename);
      COMMIT;
   END LOOP;
   CLOSE c1;
END;

История & развитие

Хранимые процедуры являлись основой систем управления базами данных на протяжении десятилетий. Они появились в 1970-1980-е годы благодаря реляционным БД.

Одна из первых реляционных баз данных, System R от IBM, включала в себя возможности, подобные хранимым процедурам. Расцвет SQL, приходящийся на 1980-1990-х годы, и внедрение SQL в качестве стандартного языка баз данных привели к более широкому распространению хранимых процедур.

Постепенно они стали неотъемлемой частью таких баз данных, как Oracle (с PL/SQL, представленным в 1995 году) и Microsoft SQL Server (с T-SQL), а также стали использоваться в процессе оптимизации производительности в 1990-2000-х годах, снижая сетевой трафик и обеспечивая целостность данных при выполнении сложных транзакций.

Сегодня, даже при наличии более универсальных языков программирования, таких как Python и Java, хранимые процедуры по-прежнему востребованы. Они все также используются для решения задач, где требуется тесная интеграция с базой данных, но в случае при необходимости более сложной обработки данных дополняются внешними скриптами и приложениями.

Ключевые концепты

Суть хранимых процедур заключается в последовательном выполнении SQL-запросов и управлении ими. Все процессы выполняются с ориентацией на базу данных, что позволяет использовать ее вычислительные возможности по максимуму и сокращать сетевые задержки.

Хранимые процедуры также преобразуют бизнес-логику в код, который в результате сохраняется в виде таблиц базы данных. Их главным недостатком является то, что код зачастую становится беспорядочным. Хранимые процедуры могут вызывать другие хранимые процедуры, и в итоге Вы получаете знаменитый спагетти-код.

Управление транзакциями - еще одна ключевая концепция, создающая безопасный механизм для обеспечения целостности и непротиворечивости данных, особенно в многопользовательских средах.

Традиционные инструменты ETL

Традиционные инструменты ETL играют ключевую роль в области обработки данных и BI. Эти инструменты предназначены для извлечения данных из различных источников, преобразования их в формат, пригодный для анализа, и загрузки в конечный пункт, например, в хранилище данных. Наиболее известные ETL-инструменты: Informatica, IBM Datastage, Cognos, Microsoft SSIS и Oracle OWB.

Определение

Традиционные инструменты ETL - это приложения, предназначенные для извлечения данных из различных источников, преобразования их в соответствии с операционными потребностями и загрузки в конечную базу данных или хранилище данных для последующего анализа и создания отчетов.

Это предшественники инструментов с графическим интерфейсом, в которых проектирование было оптимизировано за счет создания потока данных с помощью инструментов drag-and-drop.

Инструменты ETL составляют основу хранилищ данных и BI систем, они позволяют организациям консолидировать данные из внутренних систем, таких как CRM, ERP и т. д., производящих критически важные данные, и соединять их воедино для создания отчета.

История & Эволюция

История традиционных инструментов ETL берет свое начало в начале 1998 года, ознаменовавшегося самым настоящим взрывным ростом объема и разнообразия данных. Организациям требовались консолидированные сведения из различных источников данных. Появление таких инструментов ETL, как Data Transformation Services (DTS), OWB, Informatica PowerCenter и SSIS, стало началом движения ETL.

Эти инструменты были ориентированы на пакетную обработку данных и работу с Big Data в ночное время. Позже появились пользовательские интерфейсы, позволяющие управлять ETL с помощью drag-and-drop, проектировать сложные процессы и интегрировать расширенные аналитические функции.

На протяжении 2000-х и 2010-х годов эти инструменты постоянно адаптировались к новым источникам данных, включая облачные хранилища и системы обработки больших данных, предлагая более гибкие и масштабируемые решения.

Ключевые концепты

ETL можно свести к следующим трем этапам:

Извлечение: подключение к различным источникам данных, от традиционных баз данных до облачных хранилищ и API, и извлечение необходимых данных. Этот этап крайне важен для обеспечения точности и полноты данных.
Преобразование: после извлечения данных мы добавляем к ним бизнес-логику. Она может включать в себя очистку, дедупликацию, интеграцию и преобразование. Все это необходимо для получения подходящего формата и высокого качества данных.
Загрузка: заключительный этап - загрузка преобразованных данных в целевую систему, как правило, это DWH, витрина данных или любая другая аналитическая база данных. Этот этап должен быть высокоавтоматизированным и надежным, он призван обеспечить доступность данных для приложений отчетности и аналитики.

Традиционные инструменты ETL по-прежнему остаются главными компонентами современных архитектур данных.

Новая парадигма процесса обработки данных: ELT (Extract, Load, Transform)

ELT представляет собой новейшую методологию интеграции данных, в которой данные сначала извлекаются (E) из исходных систем, затем загружаются (L) в виде необработанных данных в целевую систему, после чего происходит их преобразование (T). Такой подход, выполняемый в целевом хранилище данных, отличается от традиционного метода ETL, при котором данные подвергаются преобразованию до того, как попадают в целевую систему.

Переход от ETL к ELT был вызван требованием снижения стоимости вычислений и хранения данных, а также появлением облачных хранилищ данных, таких как Redshift, BigQuery и Snowflake.

ELT, как правило, используется в средах Data Lake. Airbyte стал эталоном ELT с открытым исходным кодом в 2020 году, в то время как Fivetran, будучи первопроходцем, работает по модели с закрытым исходным кодом.

Python-скрипты

Процессы ETL развиваются. В настоящее время обозначилась явная тенденция к созданию конфигурационных платформ, таких как Apache Airflow, Dagster, или Temporal. Этот сдвиг полностью соответствует требованиям обеспечения быстрого доступа к данным.

Следующей итерацией процессов является Python. Почему именно Python? Почему не JavaScript, Rust или другие языки программирования? Да потому что Python - лидер в области разработки данных, его вполне можно сравнить с английским языком. Кроме того, это один из самых простых языков программирования после SQL.

Нас больше интересует не сам Python, Python- скрипты, предлагающие широкие возможности оркестрации задач в области работы с данными.

Определение

Python-скрипт не нуждается в пояснениях. Как правило, они достаточно просты, но их можно усложнить за счет дополнения полноценных фреймворков, которые будут занимаются только оркестрацией задач.

Ниже приведен пример, где мы читаем JSON-файл, полученный из веб-интерфейса или файла конфигурации, фильтруем некоторые данные в качестве шага обработки данных и экспортируем их в CSV:

import pandas as pd
 
# Define the file paths
input_file = 'data.json'
output_file = 'processed_data.csv'
 
# Read the JSON file directly using Pandas
data = pd.read_json(input_file)
 
# Process the data
# Example: Filtering rows based on a specific condition
processed_data = data[data['column_name'] > some_value]
 
# Write the processed data to a new CSV file
processed_data.to_csv(output_file, index=False)
 
print("Data processing complete. Processed output saved to:", output_file)

Его можно запустить с помощью Python, установленного на сервере с помощью python script.py. Мы же используем Pandas, позволяющие упростить чтение файлов. Приведенный выше пример демонстрирует всю мощь Python с его экосистемой: здесь есть библиотеки, необходимые для решения практически любой задачи, включая машинное обучение.

Сегодня мы можем пользоваться большим спектром фреймворков для оркестрации задач, написанных на Python – это может быть ведение логов, обратное заполнение, общий пользовательский интерфейс и многое другое.

В их основе лежит фреймворк оркестрации, который:

Запускает вычисления в нужное время
Моделирует зависимости вычислений
Отслеживает историю выполнения вычислений.

В общем, инструменты оркестрации задач отлично справляются с определением времени наступления событий, выявлением и устранением ошибок, а также восстановлением корректных состояний.

Теперь давайте рассмотрим типы инструментов оркестрации задач.

Типы инструментов оркестрации задач

Сегодня рынок может предложить нам огромное количество вариантов.

Существует инструменты оркестрации на базе Python, инструменты, предоставляемый как сервис в облаке Вашего провайдера, даже решения без облака. Это может быть решение без кода, например, SSIS.

На рынке представлено достаточно много совершенно бесплатных решений с открытым исходным кодом, такие как cron.

Давайте рассмотрим основные типы таких инструментов:

Оркестрация рабочих процессов: начало процесса оркестрации в Python, планирование задач;

Оркестрация задач с учетом данных: такие инструменты работают с контекстом данных. Вы ставите задачу, а оркестратор определяет, как это сделать. Это делается декларативно. Это похоже на то, что делает SQL, где оптимизатор запросов находит наилучший способ.

Оркестрация YAML: вы можете строить конвейеры обработки данных с интуитивно понятно пользовательским интерфейсом, но при этом не терять декларативный и кодовый подход, поскольку подобные инструменты генерируют «код» (YAML). Это единственный способ использовать no-code решения.

Неявная оркестровка: В последнее время наблюдается тенденция к отказу от DAG. Она основана на независимых очередях сообщений.

История & Эволюция

Краткий обзор истории развития Python:

Python был создан в 1989 году Гвидо ван Россумом как преемник языка ABC. Он был разработан для быстрой разработки конвейеров обработки данных.

Начало 2000-х годов ознаменовалось ростом популярности Python в области инженерии данных, на что в значительной степени повлиял выпуск таких библиотек, как NumPy, SciPy и Pandas. Эти инструменты превратили Python в мощный инструмент анализа, обработки данных и оркестрации задач.

Современные фреймворки оркестрации задач:

Airflow (2015): Apache Airflow, выпущенный в 2015 году компанией Airbnb, стал важной вехой в развитии инструментов оркестрации на базе Python. Это одна из самых мощных платформ, предназначенная для планирования и мониторинга рабочих процессов, использующая Python для создания сложных конвейеров обработки данных.

Temporal (2016): Платформа для оркестрации микросервисов.

Dagster (2018): появился как фреймворк для оркестрации задач с учетом данных, подчеркивающий контекст данных в рабочих процессах.

Kestra (2019): Kestra упростила создание конвейеров обработки данных с помощью декларативных конфигураций YAML.

Mage.ai (2022): Представляет подход к разработке пайплайнов данных в стиле блокнота, удовлетворяя растущий спрос на более доступные и гибкие инструменты оркестрации задач.

И многие другие.

Также я заметил, что инструменты оркестрации задач движутся от управления задачами и рабочими процессами к пониманию и управлению данными как активами. Кроме того, многие из них ориентируются на YAML оркестрацию данных.

Есть одна тенденция, третья, которую я заметил, - это «скрытая» оркестрация, которая уменьшает зависимость от явных определений DAG. В основном она используется в конвейерах потоковых данных. Вместо физического оркестровщика группа DAG автоматически управляет зависимостями и рабочими процессами на основе очередей, что приводит к более динамичным и гибким стратегиям оркестровки.

Будущее инструментов оркестрации

Эволюция Python и его фреймворков в области оркестрации - это постоянная адаптация к меняющимся потребностям дата-инженеров - от простого выполнения скриптов до сложных платформ оркестрации с учетом данных.

Python стал основой современного стека данных. Он делает возможным объединение и повторное использование мощнейших функций для решения широкого спектра задач в экосистеме инженерии данных. Хотя Python, как многие считают, не хватает скорости, это в полной мере компенсируется мощными инструментами сторонних разработчиков (Pandas, NumPy, Polars и т. д.), а также новыми интеграциями, написанными на Rust. Это еще один ключ к тому, чтобы Python выжил в высококонкурентной среде и остался основным языком программирования в области оркестрации задач.

Ключевые концепты

Если простой Python-скрипт обеспечивает гибкость, то фреймворк предоставляет необходимую абстракцию. Абстракции позволяют сосредоточиться на основной бизнес-логике. Вместо того чтобы выяснять, как записывать данные локально на диск или в озеро данных, или как правильно установить зависимости, Вы сосредотачиваетесь на фактическом преобразовании, трансформации и перемещении данных.

Иногда я называю это микросервисами «на стероидах». Почему? Потому что это позволяет Вам писать независимые преобразования на Python, писать то, что Вы хотите (по аналогии с микросервисами), используя все стандартные функции, таких как логирование, зависимости, обратное заполнение, передача данных от задачи к задаче и многое другое.

Кроме того, микросервисы отлично масштабируются, но могли бы быть и лучше в согласовании различных фрагментов кода или приложений. Фреймворк или современный оркестратор решает все вопросы, связанные с повторным использованием и абстракцией. Каждая задача или шаг могут быть как небольшим микросервисом, так и частью более обширного конвейера данных или потока данных.

Главное, чтобы код был написан идемпотентно, с использованием техники функциональной инженерии данных. При этом, в отличие от микросервиса, которому всегда нужно начинать с нуля, конвейер данных может подхватить то, на чем он остановился, или запускать только отдельные части задачи, если это необходимо.

Основополагающие паттерны

В этой главе мы проанализируем закономерности конвергентной эволюции bash-скриптов и cron по сравнению с хранимыми процедурами. Посмотрим на то, как традиционные инструменты ETL и простые скрипты Python понемногу превратились в современные фреймворки.

Мы познакомились с историей развития инструментов оркестрации данных. Давайте вспомним основные вехи:

Bash-скрипты и Cron: простое и удобное планирование выполнения инструкций в любой системе Unix.

Хранимая процедура: Управление SQL в непосредственной близости от базы данных без задержек.

Традиционные инструменты ETL: Удобные для человека интерфейсы для подходов, не требующих много кода.

Скрипты и фреймворки Python: Практически бесконечные возможности для выполнения чего угодно с помощью Python.

Далее мы рассмотрим общие паттерны, связанные с каждым этапом развития рассматриваемых нами инструментов.

Паттерны

Поддержка жизненного цикла инженерии данных с получением, обработкой и аналитикой данных, объединенных в одну абстракцию, скрывающую все сложности от бизнес-пользователей и аналитиков.
Абстракция и возможность повторного использования: более высокие уровни абстракции и возможности повторного использования, будь то инкапсуляция логики потока данных в инструментах ETL, абстрагирование от сложностей планирования задач в bash-скриптах или скриптах Python. В любом случае цель состоит в том, чтобы упростить процесс оркестрации задач и сделать его компоненты многократно используемыми для других проектов.
Интеграция и расширяемость: Bash-скрипты и хранимые процедуры - примеры того, как задачи работы с данными могут быть интегрированы в более крупные системы и автоматизированные процессы. Традиционные ETL-инструменты развивают эту технологию, предлагая коннекторы и адаптеры для различных источников и пунктов назначения данных, что упрощает интеграцию различных систем. Скрипты и фреймворки Python пошли еще дальше, облегчив интеграцию за счет обширных библиотек и API, а также благодаря своей масштабируемости, позволяющей разработчикам настраивать и расширять функционал в соответствии с конкретными требованиями проекта.

Различия

Теперь давайте выделим отличительные особенности подходов и паттернов.

Дата-инженеры всегда были вынуждены выбирать между процедурным/последовательным и объектно-ориентированным подходом. Изначально оркестрация была в основном процедурной или последовательной, сфокусированной на пошаговом выполнении задач (bash-скрипты, хранимые процедуры). Со временем наметилась тенденция к более объектно-ориентированным подходам, особенно в скриптах и фреймворках Python, позволяющих использовать инкапсуляцию, наследование и полиморфизм. Этот сдвиг способствовал созданию более сложных, масштабируемых и удобных в обслуживании кодовых баз.

Аналогичные колебания наблюдаются и между императивной и декларативной оркестрацией задач. В то время как ранние оркестровки должны были работать императивно и фокусироваться на явных шагах, необходимых для выполнения задачи, новые фреймворки в значительной степени используют возможность повторного использования и концентрируются на декларативном подходе, включая YAML, скрывая сложную техническую реализацию от пользователей, благодаря чему они могут сосредоточиться исключительно на бизнес-логике.

Далее, современные инструменты для интеграции используют gRPC, а также быстрый эффективный способ межсервисного взаимодействия. В старых инструментах коммуникация осуществляется исключительно внутри кода и сниппета.

Кроме того, явно обозначился переход от оркестрации, ориентированной на инструменты и даже базы данных, к оркестрации, не зависящей от инструментов, когда Вы определяете зависимости не внутри инструмента, а поверх активов данных/групп. Но при всем при этом Вы устанавливаете триггеры на основе событий, что позволяет создать тонкий слой оркестровки.

Автоматизация хранилищ данных в сравнении с направленным ациклическим графом

Интересный вопрос: Как моделирующая часть инструментов автоматизации хранилищ данных (DWA) (как обсуждалось в предыдущей главе) сопоставляется с DAG?

Один из ответов заключается в том, что если DWA моделируют размерные структуры данных для аналитической обработки, то DAG в оркестраторе моделируют поток задач и их зависимостей в конвейерах данных. Одно из них - это моделирование данных, а другое - часть оркестровки. Две разные области, но схожие намерения. Было бы интересно копнуть глубже.

Таким образом, на сегодняшний момент можно выделить 4 ключевых паттерна инженерии данных: моделирование рабочих процессов, преобразование бизнес-логики, возможность повторного использования, скрытая оркестрация

CE: Stored Procedures

CE: Bash / Cron

CE: Python Script

P: Implicit Orchestration

P: Reusability

P: Business Transformation

P: Data-Flow Modeling (Orchestration)

CE: Traditional ETL Tools

Моделирование потоков данных

Моделирование потоков данных - это модель оркестрации, которая возникла в результате вышеупомянутых конвергентных эволюций. Она представляет собой целостный подход к управлению и оптимизации перемещения и преобразования данных в системах и платформах. Абстрагируясь от сложностей обработки данных, моделирование потоков данных позволяет инженерам разрабатывать масштабируемые и надежные конвейеры обработки данных.

Этот паттерн подчеркивает важность четко определенной модульной архитектуры, в которой каждый компонент ориентирован на выполнение конкретных задач, но при этом легко интегрируется с другими, образуя целостную экосистему обработки данных. Применение данного паттерна на практике обеспечивает быструю адаптацию к постоянно меняющимся источникам данных и их форматам, а также гарантирует соответствие проделанной работы требованиям современных организаций, управляемых данными.

Возможность многократного использования и преобразование бизнес-логики

Подробнее о возможности повторного использования и преобразовании бизнес-логики как паттернах инженерии данных рассказано в предыдущей главе.

Скрытая оркестрация задач

Скрытая оркестрация задач отражает всю гибкость и динамичность инженерии данных. Этот паттерн ориентируется на модель, в которой события вызывают действия, что тесно связано с концепциями Software-Defined Assets и Microservices.

По своей сути скрытая оркестрация - это использование механизмов, управляемых событиями (например, систем pub/sub), в целях автоматизации и управления потоками данных. Данная модель исключает необходимость в физическом оркестровщике за счет использования отзывчивой среды выполнения, срабатывающей на основе событий.

← Предыдущая статья

Введение в паттерны проектирования в инженерии данных (DEDP)

Следующая статья →

Полный вперед или перспективы машинного обучения, искусственного интеллекта и данных на 2024 год