Kestra مقابل Airflow: هجرة DAGs القديمة إلى نموذج تنسيق قائم على الكود

يتطور مشهد تنسيق البيانات. على الرغم من أن Apache Airflow كان المعيار الفعلي لفترة طويلة لجدولة خطوط أنابيب البيانات المعقدة، إلا أن نموذج DAG الخاص به الذي يركز على Python يمكن أن يُدخل عبئًا معرفيًا كبيرًا وتعقيدًا في إدارة الإصدارات للفرق. ادخل Kestra، أداة تنسيق حديثة وقائمة على الكود تنقل النموذج من المنطق الإلزامي إلى سير عمل إعلانية وقائمة على البيانات. تستكشف هذه المقالة الفروق الرئيسية وتوفر خارطة طريق لهجرة DAGs القديمة الخاصة بـ Airflow إلى بيئة Kestra.

فهم التحول في النموذج

يتطلب Airflow من المستخدمين كتابة كود Python لتعريف DAGs. وعلى الرغم من قوته، فإن هذا يعني أن منطق كيفية تشغيل المهام يتشابك مع ما هي المهام. غالبًا ما تتطلب التغييرات في منطق المهام نشر الكود، ويمكن أن يحدّ الطابع الثابت لـ DAGs من قدرات التفرع الديناميكي دون حلول معقدة.

من ناحية أخرى، يستخدم Kestra YAML لتعريف سير العمل. يسمح هذا الفصل بين الاهتمامات للمستخدمين التجاريين والمهندسين بتعديل منطق خط الأنابيب دون لمس تنفيذات المهام الأساسية. في Kestra، المهام مواطنون من الدرجة الأولى يمكن إعادة استخدامها عبر عدة سير عمل، ويتولى المحرك منطق التنسيق بشكل أصلي. لا يعني هذا النهج "القائم على الكود" كتابة كود منخفض المستوى لكل عقدة؛ بل يعني كتابة إعدادات واضحة وقابلة للصيانة تُترجم مباشرةً إلى تدفق بياناتك.

الفروق التقنية الرئيسية

• لغة التعريف: يستخدم Airflow Python؛ بينما يستخدم Kestra YAML.
• المهام الديناميكية: يتطلب Airflow أنماطًا محددة (مثل DynamicTaskMap) للتوسيع الديناميكي؛ بينما يتعامل Kestra مع المهام الديناميكية بشكل أصلي عبر الحلقات والعرض.
• إدارة الحالة: يحتوي Kestra على إدارة حالة ومعالجة مخرجات مدمجة، مما يقلل الحاجة إلى قواعد بيانات خارجية أو دلاء S3 لنقل البيانات بين المهام.
• التعدد المستأجر: يوفر Kestra دعمًا أصليًا للمساحات الاسم والتعدد المستأجر، مما يسهل إدارة بيئات معزولة لفرق أو مشاريع مختلفة.

هجرة DAG قديم

فكّر في DAG نموذجي لـ Airflow يستخرج البيانات من دلو S3، ويحوّلها باستخدام سكربت Python، ويحمّلها إلى قاعدة بيانات PostgreSQL.

# legacy_dag.py
from airflow import DAG
from airflow.providers.amazon.aws.operators.s3 import S3ToRedshiftOperator
from airflow.operators.python import PythonOperator
from datetime import datetime

def transform_data(**kwargs):
    # Custom logic here
    pass

with DAG(
    's3_to_pg_pipeline',
    start_date=datetime(2023, 1, 1),
    schedule_interval='@daily',
) as dag:
    extract = S3ToRedshiftOperator(
        task_id='extract_s3',
        aws_conn_id='aws_default',
        s3_key='data/file.csv',
        redshift_table='public.staging_data',
    )
    
    transform = PythonOperator(
        task_id='transform_data',
        python_callable=transform_data,
    )
    
    extract >> transform

إليك سير عمل Kestra المكافئ بصيغة YAML:

id: s3_to_pg_pipeline
namespace: com.company.team

tasks:
  - id: extract_s3
    type: io.kestra.plugin.aws.s3.DownloadFile
    url: s3://bucket/data/file.csv
    output:
      - /tmp/file.csv

  - id: transform_data
    type: io.kestra.plugin.shell.exec.ShellTask
    input:
      - /tmp/file.csv
    output:
      - /tmp/transformed.csv

  - id: load_pg
    type: io.kestra.plugin.postgres.Insert
    url: "{{ secrets('POSTGRES_URL') }}"
    input: /tmp/transformed.csv

خطوات هجرة عملية

1. جرد DAGs الخاصة بك: حدد الاعتماديات، والمشغلين المخصصين، والمحفزات الخارجية.
2. تعيين المهام إلى إضافات Kestra: استغل مكتبة الإضافات الواسعة لـ Kestra. إذا كانت هناك مهمة Python مخصصة، فغلّفها في shell بسيط أو إضافة Java/Kotlin إذا كانت هناك حاجة إلى أداء عالٍ.
3. إعادة هيكلة المنطق: انقل المنطق الشرطي من كود Python إلى المهام الشرطية في Kestra (if، switch). هذا يجعل تدفق التحكم مرئيًا في واجهة المستخدم.
4. معالجة تدفق البيانات: استبدل مخازن الحالة الخارجية (مثل Redis أو S3 للبيانات الوسيطة) بآليات المخرجات/المدخلات الأصلية في Kestra.
5. الاختبار بالتوازي: شغّل كلًا من Airflow و Kestra لفترة من الوقت للتأكد من الاتساق.

الخلاصة

الهجرة من Airflow إلى Kestra ليست مجرد تبديل للأدوات؛ بل هي فرصة لتحديث استراتيجية التنسيق الخاصة بك. من خلال تبني نموذج إعلاني قائم على YAML، يمكن للفرق تقليل الكود الزائد، وتحسين الرؤية إلى نسب البيانات، وتمكين تكرارات أسرع. على الرغم من أن الهجرة الأولية تتطلب تخطيطًا دقيقًا، إلا أن الفوائد طويلة المدى في قابلية الصيانة والقابلية للتوسع تجعل Kestra خيارًا مقنعًا للمؤسسات التي تسعى إلى تجاوز قيود DAGs التقليدية القائمة على Python.