اگر کرون ٹاسک شیڈیولر کی گنجائش سے تجاوز کر جائے تو کیا کریں۔

By /

زیادہ تر ڈویلپرز اپنا آٹومیشن سفر اسی طرح شروع کرتے ہیں۔ ایک اسکرپٹ بنائیں جو مفید کام انجام دے، جیسے API سے ڈیٹا حاصل کرنا، تصاویر کے بیچ کا سائز تبدیل کرنا، یا رپورٹ کو ای میل کرنا، اور پھر اسے ہر صبح چلانے کے لیے شیڈول کریں۔

یہ کرونٹاب میں ایک لائن کا اضافہ کرتا ہے، جس سے آپ کو کنٹرول ملتا ہے۔ جب آپ سوتے ہیں تو آپ کا کمپیوٹر اب خود بخود اسکرپٹس چلائے گا۔

اس لمحے کے لیے اتنا ہی کافی ہے۔ اگر ایسا ہے تو نہیں۔

ہو سکتا ہے کہ آپ کا بیک اپ اسکرپٹ صبح 3 بجے خود بخود فیل ہو جائے اور آپ اسے اس وقت تک محسوس نہ کریں جب تک کہ آپ کو اس دن کے بعد اس کی ضرورت نہ ہو، یا ہو سکتا ہے کہ آپ نے ایک فول پروف اسکرپٹ تیار کیا ہو جو آپ کے ٹرمینل میں آسانی سے چلتا ہے صرف یہ معلوم کرنے کے لیے کہ یہ کرون میں شیڈول ہونے پر ناکام ہو جاتا ہے۔

اگر اس میں سے کوئی واقف لگتا ہے، مبارک ہو. یہ کرون کی سطح سے باہر ہے۔ آپ اکیلے نہیں ہیں۔ اس مضمون کا مقصد ایک بہتر حل کو سمجھنے اور تیار کرنے میں آپ کی مدد کرنا ہے۔

یہ مضمون اس کے بارے میں ہے کہ آگے کیا ہوتا ہے۔ ہم یہ دیکھیں گے کہ کرون ریلوں سے کہاں جاتا ہے، دیکھیں گے کہ ‘ورک فلو آرکیسٹریشن’ کا اصل معنی کیا ہے جرگن کے نیچے، اور پھر ایک حقیقی دنیا کے ورک فلو کو مرحلہ وار بنائیں گے تاکہ تصور قائم رہے۔

آخر میں، آپ کو اپنے پیچیدہ نظام الاوقات کے مسائل کے لیے صحیح ٹولز کا انتخاب کرنے کا اعتماد اور طاقت حاصل ہو جائے گی۔

کرون کیا ہے اور اس کے بارے میں اصل میں کیا اچھا ہے؟

کرون ایک سسٹم بیک گراؤنڈ سروس (ڈیمون) جو طے شدہ کاموں کو چلاتی ہے۔ کرونٹاب (کرون ٹیبل) ایک کنفیگریشن فائل یا کمانڈ یوٹیلیٹی ہے جو کام کے شیڈولنگ کے لیے ٹائم بیسڈ ٹاسک شیڈیولر بنانے اور برقرار رکھنے کے لیے استعمال ہوتی ہے جو 1970 کی دہائی سے یونکس جیسے سسٹمز کے ساتھ بھیجی گئی ہے۔ یہ فی الحال لینکس کی تقسیم کے ساتھ ساتھ میک کے لیے بھی دستیاب ہے۔

کرون کے ساتھ، آپ ایک شیڈول اور کمانڈ بتاتے ہیں، اور اس وقت کمانڈ چلاتے ہیں۔ نظام الاوقات مشہور پانچ فیلڈ نحو کا استعمال کرتے ہیں۔

┌───────────── minute (0–59)
│ ┌───────────── hour (0–23)
│ │ ┌───────────── day of month (1–31)
│ │ │ ┌───────────── month (1–12)
│ │ │ │ ┌───────────── day of week (0–6)
│ │ │ │ │
0  9  *  1 5  /usr/bin/python3 /home/me/daily_report.py

نوٹ: لائن 0 9 * 1 5  /usr/bin/python3 /home/me/daily_report.py اس کا مطلب ہے "ہفتہ کے دن صبح 9 بجے روزانہ_report.py چلائیں”۔ نحو جامع، ہر جگہ اور جو کچھ کرتا ہے اس کے لیے مضبوط ہے۔

اور یہاں اہم حصہ ہے: کرون برا نہیں ہے۔ یہ ایک سسٹم پر ایک واحد، اسٹینڈ، غلطی برداشت کرنے والا کام انجام دینے کے لیے ایک مثالی ٹول ہے۔ لیکن زیادہ پیچیدہ ورک فلو کے لیے، مقصد سے بنائے گئے آرکیسٹریشن ٹولز آپ کو قابل اعتماد اور مرئیت فراہم کر کے اپنے آٹومیشن پر زیادہ سے زیادہ کنٹرول حاصل کرنے میں مدد کر سکتے ہیں۔

چار دیواروں کو آپ کرون سے ٹکرائیں گے۔

کرون کے ساتھ مسائل اس وقت شروع ہوتے ہیں جب آٹومیشن ایک واحد، آزاد کام نہیں ہوتا ہے۔ جیسے جیسے اسکرپٹ بڑھتا ہے، یہ ایک زیادہ پیچیدہ نظام بناتا ہے جس میں اسی ترتیب میں وہی چار رکاوٹیں لاگو ہوتی ہیں۔

دیوار 1: قدموں کے درمیان انحصار

آپ کا صبح کا معمول ایک اسکرپٹ سے بڑھ کر تین ہو جاتا ہے۔ تین اسکرپٹ کے ساتھ ETL منظر نامے پر غور کریں:

  1. extract.py API سے کل کے آرڈر حاصل کریں۔

  2. conversion.py اپنا ڈیٹا صاف کریں اور ٹوٹل کا حساب لگائیں۔

  3. load.py نتائج کو تجزیہ ڈیٹا بیس میں ریکارڈ کرتا ہے۔

ہر قدم پچھلے مرحلے پر منحصر ہے۔ واضح کرون نقطہ نظر وقت پر اندازہ لگانا ہے۔

0 2 * * *  python extract.py
0 3 * * *  python transform.py
0 4 * * *  python load.py

اب میں امید کر رہا ہوں کہ نکالنے کا عمل ایک گھنٹے کے اندر مکمل ہو جائے گا تاکہ میں اسے اپنے تبادلوں کے کام کے لیے استعمال کر سکوں۔ دن میں، API سست ہے، اقتباسات میں 70 منٹ لگتے ہیں، تبدیلیاں باسی یا گمشدہ ڈیٹا پر چلتی ہیں، اور خاموشی سے کوڑا کرکٹ پیدا کرتی ہے۔ کرون میں "A کے کامیاب ہونے کے بعد ہی B پر عمل درآمد” کا کوئی تصور نہیں ہے۔ میں صرف دیوار کی گھڑی کا وقت جانتا ہوں۔

وال 2: ہینڈلنگ میں ناکامی اور دوبارہ کوشش

نیٹ ورک بلپ۔ API ایک 503 اسٹیٹس کوڈ واپس کرتا ہے (سروس دستیاب نہیں ہے)۔ ڈیٹا بیس منقطع ہو جاتا ہے۔ مضبوط آپریشنز کو ناکامی کا پتہ لگانا اور دوبارہ کوشش کرنی چاہیے۔ ایسی خدمت کو خراب کرنے کی ضرورت نہیں ہے جو جدوجہد کر رہی ہو کیونکہ یہ شاید تین یا زیادہ کوششوں کے درمیان تاخیر کو بڑھاتی ہے۔

اگر آپ کرون استعمال کرتے ہیں تو، دوبارہ کوشش کرنے کی منطق مسئلہ ہے۔ بس اسے ہاتھ سے کسی بھی اسکرپٹ میں شامل کریں۔ بلاکس کو آزمائیں/خارج کریں، سلیپ کالز، کاؤنٹرز، اور فلیگ فائلیں اگلے کرونٹک کو یہ جاننے کی اجازت دیتی ہیں کہ آیا پچھلا اسکرپٹ مکمل ہو گیا ہے۔ اسے درجنوں آپریشنز پر ضرب دیں، اور آپ ایک چھوٹا، چھوٹی چھوٹی اور غیر دستاویزی آرکیسٹریشن انجن لکھتے ہیں۔

وال 3: مرئیت

اپنے آپ سے پوچھیں: کیا کل رات کام چلا؟ کون سا کامیاب رہا؟ ہر ایک نے کتنا وقت لیا؟ کیا یہ نچوڑ کے مرحلے میں سست روی ہے یا بوجھ کے مرحلے میں سست روی؟

اگر آپ کرون استعمال کرتے ہیں تو ایماندارانہ جواب یہ ہے کہ "اگر آپ کو کچھ لاگ فائلیں اسکرپٹ کے ذریعہ لکھی گئی ہیں تو شاید آپ کو پڑھنے کی ضرورت ہوگی۔” پہلا کام خود کرون جاب لاگ فائل کو تلاش کرنا ہے۔

یہ تلاش کرنا پیچیدہ ہوسکتا ہے۔ اگر لاگنگ فعال ہے تو، کرون کے لاگز ایک سسٹم پر /var/log/syslog اور دوسرے پر /var/log/cron میں واقع ہوسکتے ہیں۔ دریں اثنا، آپ کی اسکرپٹ کا آؤٹ پٹ صرف اس صورت میں موجود ہے جب آپ واضح طور پر stdout اور stderr کو ری ڈائریکٹ کریں۔ نتیجے کے طور پر، آپ کو یہ دیکھنے کے لیے سسٹم لاگ کو تلاش کرنے کی ضرورت ہوگی کہ آیا کام چل گیا، اور پھر ایک علیحدہ آؤٹ پٹ فائل تلاش کریں جو متعلقہ پرنٹ اسٹیٹمنٹ کو حاصل کرے۔

جب کوئی کام ناکام ہو جاتا ہے، تو آپ کو یہ دیکھنے کے لیے کہ کون سا ٹائم اسٹیمپ آخری رن سے مطابقت رکھتا ہے اور کہاں غلط ہوا، آپ کو ایک سے زیادہ رنز سے جڑے لاگز کی جانچ پڑتال کرنی پڑتی ہے، اور صرف غیر صفر ایگزٹ کوڈز پر انحصار کرتے ہوئے مسئلے کی نشاندہی کرنا اکثر زیادہ مشکل ہوتا ہے۔ کوئی ڈیش بورڈ نہیں ہے، کوئی عمل درآمد کی تاریخ نہیں ہے، اس بات کا کوئی ریکارڈ نہیں ہے کہ کسی کام میں کتنا وقت لگا، اور کچھ غلط ہونے پر کوئی انتباہات نہیں ہیں۔

ناکامی بذریعہ ڈیفالٹ خاموش ہے، جو کہ پس منظر کے کام کی واحد سب سے خطرناک خاصیت ہے۔ جب کسی نے نیچے کی طرف دیکھا کہ نمبر اپ ڈیٹ ہونا بند ہو گئے ہیں، تو انہیں احساس ہوا کہ پائپ لائن ایک ہفتے سے بند ہے۔

وال 4: بیک فل اور دوبارہ کریں۔

آپ کا تجزیاتی ڈیٹا بیس دو ماہ سے رواں ہے جب سے آپ نے بگ دریافت کیا ہے۔ conversion.py ٹوٹل کا حساب غلط لگایا گیا۔ میں نے کوڈ میں ترمیم کی۔ اب آپ کو اپنے ڈیٹا کے اپنے ٹکڑے پر کارروائی کرنے کے لیے ہر روز دو ماہ تک پائپ لائن کو دوبارہ چلانا ہوگا۔

یہ ایک بیکفل ہے اور کرون کا استعمال ایک ڈراؤنا خواب ہے۔ کرون صرف "اب” چلتا ہے۔ "اسے اس طرح چلائیں جیسے یہ 14 مارچ، 15 مارچ تھا، اور پھر…” کا کوئی بلٹ ان تصور نہیں ہے، لہذا آپ ڈیٹ لوپ کے ساتھ ایک اور پھینکنے والا اسکرپٹ لکھیں، دعا کریں کہ یہ غیرمعمولی ہے، اور اس کا خیال رکھیں۔

اس پیٹرن کو دیکھیں جو چاروں دیواروں پر چلتا ہے۔ ہر بار، آپ کسی ایسی چیز کو غلط طریقے سے نافذ کرتے ہیں جسے ٹول کیٹیگری پہلے ہی اچھی طرح سے حل کرتی ہے۔ وہ زمرہ ورک فلو آرکیسٹریشن ہے۔

کیا ورک فلو آرکیسٹریشن آپ کا مسئلہ حل کر سکتا ہے؟

ایک ورک فلو آرکیسٹریٹر ایک ورک فلو کا انتظام کرتا ہے، جو کہ مخصوص رشتوں، محرکات، اور ایرر پروٹوکول کے ساتھ کاموں کا ایک مجموعہ ہے، جس کے ساتھ ساتھ نتائج کو ٹریک کرنے کے لیے مشاہدہ کیا جاتا ہے۔

بہت سے حل دستیاب ہیں، جیسے کہ Airflow، Dagster، Prefect، اور Temporal، لیکن ہم Kestra پر توجہ مرکوز کریں گے، جو ایک اوپن سورس آرکیسٹریٹر ہے۔ کیسٹرا اس لیے نمایاں ہے کیونکہ یہ ڈویلپرز کو ایک ہی اعلانیہ پرت سے ورک فلو کو چلانے، مانیٹر کرنے اور ان کا نظم کرنے کی اجازت دیتا ہے جو کسی بھی پروگرامنگ لینگویج اور انفراسٹرکچر کے ساتھ مطابقت رکھتی ہے، بشمول پبلک، پرائیویٹ، یا یہاں تک کہ ایئر گیپڈ نیٹ ورکس۔

کیسٹرا کاروباروں کو وہ بصیرت اور کنٹرول بھی فراہم کرتا ہے جس کی انہیں تعمیل کو یقینی بنانے کی ضرورت ہوتی ہے۔ 1,600 سے زیادہ کنیکٹرز کے ساتھ، آپ عملی طور پر کوئی بھی ڈیٹا، انفراسٹرکچر، یا AI ورک فلو بنا سکتے ہیں۔

اس ٹیوٹوریل میں، ہم کرون شیڈولر تھیم کو جاری رکھتے ہیں اور ایک سادہ ای ٹی ایل ورک فلو بناتے ہیں جو کرون کی طرح کی شیڈولنگ کا استعمال کرتا ہے جبکہ کرون کی کچھ خامیوں کو دور کرتا ہے، جیسے کہ ایگزیکیوشن آرڈر اور ایرر ہینڈلنگ۔

کیسٹرا پرائمر

کیسٹرا مناسب ورک فلو آرکیسٹریشن حاصل کرنے کے لیے انجینئرنگ کے کام سے پیدا ہوا تھا Python کوڈ لکھ کر۔ Apache Airflow DAG کے لیے موزوں Python کوڈ لکھنے میں انجینئرنگ کا وقت صرف کرنے کے بجائے، Kestra آپ کے ورک فلو کو YAML فائل بننے دیتا ہے۔ صرف بیان کریں کہ سادہ، اعلانیہ نحو کے ساتھ کیا کرنے کی ضرورت ہے۔ فائل کو Git میں محفوظ کریں اور اسے کسی دوسرے کوڈ کی طرح تعینات کریں۔

کوئی مبہم UI منطق یا پوشیدہ اسٹیٹ مینجمنٹ نہیں ہے۔ سادہ متن جس کا آسانی سے جائزہ لیا جا سکتا ہے اور موازنہ کیا جا سکتا ہے۔ ورک فلو جس میں پڑھا ہوا ورک فلو عمل میں لایا جاتا ہے۔

شکل 1 میں YAML فائل کی مثال ایک ایسے منظر نامے کی وضاحت کرتی ہے جہاں آپ NoSQL ڈیٹا کو قابل تجزیہ گودام میں منتقل کرنا چاہتے ہیں۔

id: cassandra-to-bigquery
namespace: company.team

tasks:
  - id: query_cassandra
    type: io.kestra.plugin.cassandra.Query
    session:
      endpoints:
        - hostname: localhost
          port: 9042
      localDatacenter: datacenter1
    cql: |
      SELECT salary_id, work_year, experience_level, employment_type,
      job_title, salary, salary_currency, salary_in_usd, employee_residence,
      remote_ratio, company_location, company_size
      FROM test.salary
    fetchType: STORE

  - id: write_to_csv
    type: io.kestra.plugin.serdes.csv.IonToCsv
    from: "{{ outputs.query_cassandra.uri }}"

  - id: load_bigquery
    type: io.kestra.plugin.gcp.bigquery.Load
    from: "{{ outputs.write_to_csv.uri }}"
    destinationTable: my_project.my_dataset.my_table
    serviceAccount: "{{ secret('GCP_SERVICE_ACCOUNT_JSON') }}"
    projectId: my_project
    format: CSV
    csvOptions:
      fieldDelimiter: ","
      skipLeadingRows: 1

شکل 1: Cassandra سے BigQuery کی مثال

یہاں تک کہ اگر آپ کیسٹرا کے بارے میں زیادہ نہیں جانتے ہیں، YAML فائلیں سادہ اور خود وضاحتی ہیں۔ بعد میں اس پوسٹ میں، ہم ایک بنیادی ETL بہاؤ بنائیں گے اور ID اور Type جیسے فیلڈز کی اہمیت کی وضاحت کریں گے۔ لیکن پہلے، آئیے اپنے مقامی کمپیوٹر پر کیسٹرا کی ایک مثال چلائیں۔

کیسٹرا کو کیسے ترتیب دیا جائے۔

کیسٹرا اپاچی 2.0 لائسنس کے تحت لائسنس یافتہ اوپن سورس پلیٹ فارم کے طور پر اور ایک انٹرپرائز ورژن کے طور پر دستیاب ہے جو اضافی خصوصیات اور پروڈکٹ سپورٹ فراہم کرتا ہے۔ اس ٹیوٹوریل میں، ہم تازہ ترین ورژن کا استعمال کرتے ہوئے کیسٹرا کو مقامی طور پر چلانے کے لیے Docker کا استعمال کریں گے۔

کیسٹرا کو گھمانے کے لیے، درج ذیل ڈوکر کمانڈ کو چلائیں:

docker run --pull=always --rm -it -p 8080:8080 
  --user=root 
  --name kestra 
  -v kestra_data:/app/storage 
  -v kestra_db:/app/data 
  -v /var/run/docker.sock:/var/run/docker.sock 
  -v /tmp:/tmp 
  kestra/kestra:latest server local

دوسرے پلیٹ فارمز جیسے کہ ونڈوز اور لینکس کے لیے، https://kestra.io/get-started دیکھیں۔

کنٹینر لوڈ ہونے کے بعد، http://localhost:8080 پر Kestra UI پر جائیں۔ ویلکم اسکرین آپ سے ایڈمنسٹریٹر بنانے کو کہے گی۔ ایک صارف بنائیں اور ابتدائی اسٹارٹ اپ وزرڈ کو مکمل کریں۔

ایک بار جب آپ کام کر لیں تو، بائیں پینل پر Flows ٹیب پر جائیں اور پھر صفحہ کے اوپری دائیں جانب تخلیق بٹن پر کلک کریں۔ یہ نمونہ ٹیمپلیٹ کا استعمال کرتے ہوئے ایک نیا بہاؤ بناتا ہے، جیسا کہ درج ذیل تصویر میں دکھایا گیا ہے۔

شکل 2: بہاؤ کا صفحہ نیا بہاؤ ٹیمپلیٹ دکھا رہا ہے۔

کیسٹرا بہاؤ

کیسٹرا بہاؤ کے ذریعے ورک فلو کوآرڈینیشن کی وضاحت کرتا ہے۔ آپ UI کے YAML نحو کا استعمال کرتے ہوئے، UI کے بغیر کوڈ ایڈیٹر کا استعمال کرتے ہوئے، یا API کے ذریعے پروگرام کے ذریعے یہ بہاؤ تشکیل دے سکتے ہیں۔ اس ٹیوٹوریل میں، آپ YAML کا استعمال کرتے ہوئے ایک بہاؤ بناتے ہیں۔

اوپر والی شکل 2 میں، آپ دیکھ سکتے ہیں کہ ہم نے شروع کرنے کے لیے پہلے ہی ایک نمونہ بہاؤ بنا لیا ہے۔

کہ _ID, نام کی جگہ، اور کام کیسٹرا ماحول کے اندر بہاؤ کی نشاندہی کرنے کے لیے تین مطلوبہ فیلڈز استعمال کیے جاتے ہیں اور بہاؤ کو جن اعمال کو انجام دینا چاہیے۔ ہر بہاؤ ایک نام کی جگہ میں ہے۔ نام کی جگہیں فائل سسٹم میں فولڈرز کی طرح ہوتی ہیں اور ان کا استعمال گروپ فلو اور ڈھانچہ فراہم کرنے کے لیے کیا جاتا ہے۔ کسی بہاؤ کے نام کی جگہ کو بننے کے بعد تبدیل نہیں کیا جا سکتا۔

کیسٹرا کا استعمال کیسے کریں۔

مرحلہ 1: آسان کام جو شیڈول کے مطابق چلتے ہیں۔

آئیے فراہم کردہ نمونے کے بہاؤ کو صاف کرکے اور اسے درج ذیل سے تبدیل کرکے شروع کریں:

id: morning_report
namespace: tutorial

tasks:
  - id: say_hello
    type: io.kestra.plugin.core.log.Log
    message: "Good morning — the pipeline ran at {{ execution.startDate }}"

اس مثال میں پیغام کو لاگ کرنے کے لیے مطلوبہ ID، نام کی جگہ، اور ایک ایکشن فیلڈ ہے۔ دکھائے جانے والے پیغام پر عمل درآمد کی تاریخ کی نشاندہی کرنے کے لیے معاہدہ اظہار (بریکٹ {{ }} میں کمانڈ) کا استعمال کیا گیا ہے۔

پیبل ایکسپریشنز کو بہاؤ میں متحرک طور پر قدروں کو سیٹ کرنے کے لیے استعمال کیا جاتا ہے۔ اس مثال میں، عملدرآمد شروع ہونے کی تاریخ ایک سٹرنگ کے اندر داخل کی جاتی ہے۔

اس بہاؤ کو چلانے کے لیے، آپ کو پہلے صفحہ کے اوپری دائیں کونے میں محفوظ بٹن پر کلک کرکے اسے محفوظ کرنا ہوگا۔ محفوظ کرنے کے بعد پلے بٹن پر کلک کریں۔ اس کے بعد آپ کو Run Options صفحہ نظر آئے گا جیسا کہ ذیل میں شکل 3 میں دکھایا گیا ہے۔

فلو ان پٹ ڈائیلاگ باکس چلائیں۔

شکل 3: چلانے کے بہاؤ کے اختیارات

اگر اس ورک فلو میں فائل کے نام یا URLs جیسے ان پٹ ہیں، تو آپ انہیں دستی طور پر یہاں درج کر کے بہاؤ کی جانچ کر سکتے ہیں۔ اگر آپ UI کے بجائے API کے ذریعے اپنا بہاؤ چلانا چاہتے ہیں تو Modal curl کمانڈز بھی فراہم کرتا ہے۔ بہاؤ کو چلانے کے لیے رن بٹن پر کلک کریں۔

فلو ایگزیکیوشن لاگ ڈائیلاگ باکس

شکل 4: فلو ایگزیکیوشن لاگ

بہاؤ آسان تھا اور لاگ فائل میں معلوماتی پیغامات کو لاگ ان کیا جاتا تھا۔ اگر آپ کے بہاؤ میں غلطیاں یا انتباہات ہیں، تو آپ اس صفحہ پر عملدرآمد کے تفصیلی لاگز دیکھ سکتے ہیں۔

اب جب کہ ہم نے اپنا پہلا کام بنا لیا ہے، آئیے اسے کرون ماسک کا استعمال کرتے ہوئے شیڈول کریں۔ اپنے بہاؤ میں درج ذیل کو شامل کرنے کے لیے صفحہ کے اوپری حصے میں ‘بہاؤ میں ترمیم کریں’ بٹن پر کلک کریں:

اگلا، اپنے بہاؤ میں ایک ٹرگر سیکشن شامل کریں۔

triggers:
  - id: every_minute
    type: io.kestra.plugin.core.trigger.Schedule
    cron: "* * * * *"

بہاؤ چلائیں۔ چند منٹوں کے بعد، ایگزیکیوشن ہسٹری چیک کرنے کے لیے بائیں نیویگیشن مینو میں ‘رن’ ٹیب پر کلک کریں۔

عمل درآمد کا صفحہ

شکل 5: فلو ایگزیکیوشن پیج

بہاؤ اب سنگل جاب کرون جاب کی طرح برتاؤ کرتا ہے۔ فلو میں شیڈول ٹرگر کے ساتھ ایک Triggers بلاک ہے جس میں بالکل وہی پانچ فیلڈ نحو ہے جسے کرون فیلڈ پہلے سے جانتا ہے۔ وہ آخری نکتہ اہم ہے۔ جو کچھ آپ نے سیکھا ہے اسے پھینک نہ دیں۔ ہم اسے اس طرح پیک کر رہے ہیں جو آپ کی ضروریات میں تبدیلی کے ساتھ بڑھ سکتا ہے۔

یہاں تک کہ اس سادہ کیسٹرا مثال میں، مجھے کچھ ایسا ملا جو کرون کو نہیں ملتا۔ ہر بار جب یہ ٹاسک چلتا ہے، اسے ٹائم اسٹیمپ، دورانیہ، اور حیثیت کے ساتھ رن کے طور پر لاگ ان کیا جاتا ہے، اور تمام لاگز UI میں دکھائے جاتے ہیں۔ یہ دیوار 3 (مرئیت) ہے اس سے پہلے کہ ہم کوئی دلچسپ کام کر سکیں۔

مرحلہ 2: اصل کام اور انحصار

اب آئیے ایک آسان کام کو تین قدموں کے نچوڑ/ٹرانسفارم/لوڈ میں تبدیل کریں اور آرکیسٹریٹر کو ٹائمنگ آفسیٹ کے بجائے آرڈر کا اطلاق کرنے کو کہیں۔

id: csv_to_parquet
namespace: company.team
description: Download orders CSV, transform it with a Python script, and write the result to a Parquet file.

tasks:
  # Download a public CSV file into Kestra's internal storage
  - id: download_csv
    type: io.kestra.plugin.core.http.Download
    uri: https://huggingface.co/datasets/kestra/datasets/raw/main/csv/orders.csv

  # Transform the CSV with a simple Python script and write it out as Parquet
  - id: transform_to_parquet
    type: io.kestra.plugin.scripts.python.Script
    containerImage: ghcr.io/kestra-io/pydata:latest
    inputFiles:
      input.csv: "{{ outputs.download_csv.uri }}"
    outputFiles:
      - orders.parquet
    script: |
      import pandas as pd

      # Read the downloaded CSV
      df = pd.read_csv("input.csv")

      # --- simple transformation ---
      # Ensure numeric types and add a computed column
      df["total"] = df["quantity"] * df["price"]

      # Keep only orders above a small threshold as an example filter
      df = df[df["total"] > 0]

      print(f"Rows after transform: {len(df)}")

      # Write the result to Parquet
      df.to_parquet("orders.parquet", index=False)

  # Log that the Parquet file was produced
  - id: log_output
    type: io.kestra.plugin.core.log.Log
    message: "Parquet file created: {{ outputs.transform_to_parquet.outputFiles['orders.parquet'] }}"
# Expose the Parquet file as a downloadable flow output.
# FILE-typed flow outputs appear on the execution's Overview tab with a download button.
outputs:
  - id: parquet_file
    type: FILE
    value: "{{ outputs.transform_to_parquet.outputFiles['orders.parquet'] }}"

بہاؤ کو محفوظ کریں اور پھر اسے چلائیں۔

پھانسی کا نتیجہ

شکل 6: پھانسی کا نتیجہ

ابھی دو باتیں ہوئیں۔ سب سے پہلے، ترتیب میں درج کاموں کو ترتیب سے انجام دیا جاتا ہے۔ Transform_to_parquet ڈاؤن لوڈ_csv کے کامیاب ہونے کے بعد ہی شروع ہوتا ہے، اور log_output صرف تبدیلی کے کامیاب ہونے کے بعد شروع ہوتا ہے۔ اگر کوئی خرابی پیش آتی ہے تو، عملدرآمد رک جاتا ہے اور transform_to_parquet کسی بھی باسی ڈیٹا کو نہیں چھوتا ہے۔ کہ دیوار 1 (انحصار) یہ وقت کے بارے میں کسی قیاس کے بغیر غائب ہوگیا۔

دوسرا، بہاؤ کے اندر اظہار کو چیک کریں {{ Outputs.download_csv.uri }}۔ ٹاسکس اس طرح کے تاثرات کو ڈیٹا اور میٹا ڈیٹا کو بعد کے کاموں میں منتقل کرنے کے لیے استعمال کر سکتے ہیں۔ یہ کنکشن اسکرپٹ کی فہرست کو ایک حقیقی پائپ لائن میں بدل دیتے ہیں۔

مرحلہ 3: دوبارہ کوشش کرکے ناکامی پر قابو پالیں۔

اب ایک ایسے منظر نامے پر غور کریں جہاں download_csv ٹاسک کو نیٹ ورک کا مسئلہ درپیش ہے اور بہاؤ تازہ ترین ڈیٹا ڈاؤن لوڈ کرنے سے قاصر ہے۔ آئیے download_csv آپریشن میں دوبارہ کوشش کا سیکشن شامل کرکے آپریشن کو اعلانیہ طور پر لچکدار بنائیں۔

- id: download_csv
    type: io.kestra.plugin.core.http.Download
    uri: https://huggingface.co/datasets/kestra/datasets/raw/main/csv/orders.csv
    retry:
      type: constant
      maxAttempts: 5
      interval: PT10S

یہ مجموعی طور پر دوبارہ کوشش کی پالیسی ہے۔ اگر ڈاؤن لوڈ ناکام ہوجاتا ہے، کیسٹرا انتظار کرے گا اور 10 سیکنڈ کی تاخیر کے ساتھ 5 بار دوبارہ کوشش کرے گا (PT10S "10 سیکنڈ” کے لیے ISO-8601 ہے)۔ یہاں کوئی کاؤنٹر، سلیپ کالز یا فلیگ فائلیں نہیں ہیں۔ دیوار 2 (ہینڈلنگ میں ناکامی) یہ تین لائنوں کے طور پر عملدرآمد کیا جاتا ہے جو ایک جملے کی طرح پڑھتے ہیں.

اسے جانچنے کے لیے، Orders.csv سے "s” کو حذف کریں اور بہاؤ کو دوبارہ چلائیں۔ آپ پھانسی کو دوبارہ کوششیں دکھاتے ہوئے دیکھ سکتے ہیں۔

دوبارہ کوشش کرنے والا ڈائیلاگ چلائیں۔

شکل 7: پھانسی دوبارہ کوششیں دکھا رہی ہے۔

اگر تمام کوششیں ناکام ہو جاتی ہیں، تو آپ کو مطلع کرنا چاہیں گے۔ آئیے ایک فلو لیول ایرر ہینڈلر شامل کریں جو صرف اس وقت چلتا ہے جب ورک فلو میں کوئی چیز ناکام ہوجاتی ہے۔

errors:
  - id: notify_failure
    type: io.kestra.plugin.notifications.slack.SlackIncomingWebhook
    url: "{{ secret('SLACK_WEBHOOK') }}"
    payload: |
      {"text": "orders_pipeline failed on execution {{ execution.id }}"}

ٹوٹی ہوئی پائپ لائن اب صبح 3 بجے خاموشی سے ناکام ہونے کے بجائے سلیک چینل کو پنگ دیتی ہے۔ راز راز اظہار کے ذریعے بہاؤ کے اندر محفوظ ہیں.

مرحلہ 4: واقعات کے ساتھ ساتھ وقت کو متحرک کرنا

شیڈول صرف ایک قسم کا محرک ہے۔ مان لیں کہ آپ کا آرڈر وقت پر نہیں پہنچتا۔ اس کے بجائے، جب بھی اپ اسٹریم سسٹم چاہتے ہیں فائلیں کلاؤڈ اسٹوریج میں محفوظ ہوجاتی ہیں۔

کرون شیڈول پر پولنگ ("ہر 5 منٹ پر چیک کریں اور اگر کچھ نہیں ہوتا ہے تو چھوڑ دیں”) فضول اور تاخیر کا شکار ہے۔ ایونٹ کے محرکات ایک بہتر ماڈل ہیں۔ اگر کچھ غلط ہو جائے تو ورک فلو چلائیں۔

ایک طے شدہ ٹرگر کو شامل کرنے کے بجائے، جو کہ تصوراتی طور پر اس سے ملتا جلتا ہے جو پچھلی مثال میں شامل کیا گیا تھا، درج ذیل کام کریں:

triggers:
  - id: every_minute
    type: io.kestra.plugin.core.trigger.Schedule
    cron: "* * * * *"

آپ ایسے محرکات شامل کر سکتے ہیں جو آپ کے S3 بالٹی میں نئی ​​اشیاء ظاہر ہونے پر چلتے ہیں۔

triggers:
  - id: new_s3_object
    type: io.kestra.plugin.aws.s3.Trigger
    interval: "PT1M"
    accessKeyId: "{{ secret('AWS_ACCESS_KEY_ID') }}"
    secretKeyId: "{{ secret('AWS_SECRET_KEY_ID') }}"
    region: "eu-central-1"
    bucket: "my-bucket"
    prefix: "incoming/"
    on: CREATE
    action: NONE

متبادل طور پر، آپ کے پاس ایک ایسا ٹرگر ہوسکتا ہے جو ویب ہُک یو آر ایل کو بے نقاب کرتا ہے جسے آپ ایگزیکیوشن شروع کرنے کے لیے پوسٹ کرسکتے ہیں، یا ریئل ٹائم ٹرگر جو اسٹریمنگ سروس کو سنتا ہے، جیسے کافکا قطار۔ ان محرک منظرناموں میں، ورک فلو باڈی ایک جیسی رہتی ہے۔ اب آٹومیشن صرف گھڑی دیکھنے کے بجائے دنیا پر ردعمل ظاہر کر سکتی ہے۔

مرحلہ 5: ماضی کو پُر کریں۔

آخر میں، بگ کی تبدیلی کے منظر نامے پر غور کریں۔ میں نے اپنے حسابات میں ترمیم کی ہے اور پچھلے دو مہینوں سے ہر روز پائپ لائن کو دوبارہ چلانے کی ضرورت ہے۔ یہ کرون میں درد ہوگا۔

آرکیسٹریٹر میں، بیک فلنگ شیڈولڈ ورک فلو کے لیے اعلیٰ ترین سطح کا آپریشن ہے۔ اس کا مطلب ہے کہ اگر آپ تاریخ آغاز اور اختتامی تاریخ کا انتخاب کرتے ہیں، تو اس حد میں ایک مقررہ وقفہ کے لیے ایک رن بنایا جائے گا۔ ہر عمل اس تاریخ کو پہچانتا ہے جس کی وہ نمائندگی کرتا ہے جیسے کہ {{trigger.date }}۔ تبدیلی کا مرحلہ اس تاریخ کو پروسیسنگ کے لیے ڈیٹا کا صحیح حصہ حاصل کرنے کے لیے استعمال کر سکتا ہے۔

Idempotence یہاں علمی نہیں ہے۔ چونکہ بیک فلنگ ان تاریخوں کو دوبارہ عمل میں لاتی ہے جن پر پہلے سے کارروائی ہو چکی ہے، اس لیے ڈیٹا لوڈ کا مرحلہ "داخل یا تبدیل کریں” کے الفاظ کے ساتھ لکھا جانا چاہیے جس کی کلید تاریخ پر ہے۔ لہذا، مثال کے طور پر، اگر آپ 14 مارچ کو دو بار چلاتے ہیں، تو آپ کا ڈیٹا بیس اسی حالت میں رہے گا جیسے آپ نے اسے ایک بار چلایا تھا۔

اس کے لیے ڈیزائننگ اور بیک فلنگ ڈرانے کی بجائے معمول بن جاتی ہے۔ وال 4 (بیک فل) اس پر کارروائی کی جائے گی، لیکن صرف اس صورت میں جب آپ اس پر قائم رہیں گے اور یہ ایک غیرمعمولی آپریشن ہے۔

آگے کہاں جانا ہے۔

ان سب کو اندرونی بنانے کا بہترین طریقہ یہ ہے کہ موجودہ کرون جاب لیں اور اسے ایک مناسب ورک فلو میں دوبارہ بنائیں۔ ایک واحد ٹاسک ورژن کے ساتھ شروع کریں اور یقینی بنائیں کہ یہ چلتا ہے اور عملدرآمد کی تاریخ میں ظاہر ہوتا ہے، پھر دوسرا منحصر کام، دوبارہ کوشش کرنے کی پالیسی، اور ناکامی کی وارننگ شامل کریں۔

ہر قدم کو چار دیواروں میں سے کسی ایک کے ساتھ نقش کیا جاتا ہے، اور آپ اس وقت فرق محسوس کر سکتے ہیں جب کوئی آپریشن پہلی بار ناکام ہو جاتا ہے، خود دوبارہ کوشش کرتا ہے، اور آپ کو بیدار کیے بغیر ٹھیک ہو جاتا ہے۔

آپ کو شروع سے ہر لائن لکھنے کی ضرورت نہیں ہے۔ کیسٹرا درج ذیل لائبریریاں فراہم کرتا ہے۔ بلیو پرنٹ یہ سینکڑوں پہلے سے بنائے گئے، کاپی اور پیسٹ ایبل فلوز ہیں جنہیں آپ kestra.io/blueprints پر براؤز کر سکتے ہیں یا بلیو پرنٹس ٹیب کے تحت اپنی مثال سے براہ راست رسائی حاصل کر سکتے ہیں۔

ہر بلیو پرنٹ ایک مکمل، چلائی جانے والی مثال ہے جس میں اس کی فعالیت کی وضاحت اور اسے کیسے بڑھایا جائے۔ یہ آپ کو اپنے مقصد کے قریبی ورژن کے ساتھ شروع کرنے اور اندازہ لگانے کے بجائے نحو میں ترمیم کرنے کی اجازت دیتا ہے۔

کرون نے دکھایا کہ جب آپ سوتے ہیں تو آپ کا کمپیوٹر چل سکتا ہے۔ آرکیسٹریشن اسے مزید آگے لے جاتا ہے اور اس بات کو یقینی بناتا ہے کہ کام قابل اعتماد، ترتیب اور ضعف کے ساتھ انجام پائے۔ یہ تبدیلی صرف اسکرپٹ لکھنے سے لے کر پورے نظام کو منظم کرنے کے خیال کو بدل دیتی ہے۔

Related Posts

Scroll to Top