بلک ادخال کے لیے اوپن سورس ڈیٹا لیک کیسے بنایا جائے۔

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

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

اس آرٹیکل میں، ہم نے اوپن سورس ڈیٹا لیک اسٹیک پر ایک بیچ ادخال کی تہہ قائم کی ہے جہاں ہم تمام اجزاء کے مالک ہیں۔

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

آخر میں آپ کے پاس ہوگا:

ایک ورکنگ سنگل نوڈ ڈیٹا لیک جو RustFS (آبجیکٹ اسٹوریج)، اپاچی آئس برگ (ٹیبلولر) اور پروجیکٹ نیسی (کیٹلاگ) پر بنی ہے، جو ڈوکر (کنفیگریشن) پر چل رہی ہے۔
Apache Airflow کے ساتھ مربوط ایک بیچ پائپ لائن جو PySpark جابز چلاتی ہے جو ورژن شدہ اور تقسیم شدہ آئس برگ ٹیبلز بناتی ہے۔
حقیقی دنیا کے ادخال کے نمونے، ریڈیس کے ذریعے ایئر فلو سے ڈیکپل ایک بیرونی ویب سکریپر، اور آبجیکٹ اسٹوریج میں خام ڈیٹا لکھنے کے لیے ہلکا پھلکا سگنل ٹیبل۔
یہاں ایک نظر ہے کہ یہ اسٹیک کیا ہے اور کیا نہیں، اور ہم اسے پروڈکشن میں ڈالنے کے لیے کیا شامل کر سکتے ہیں۔

دائرہ کار پر ایک لفظ: یہ ELT (ڈیٹا حاصل کرنا) کا احاطہ کرتا ہے۔ تبدیلی (dbt، Spark SQL) اور تجزیات (Trino، Superset) قدرتی اگلی پرتیں ہیں، لیکن اس مضمون کے دائرہ کار سے باہر ہیں۔ جو تم یہاں بناتے ہو وہ بنیاد ہے جس پر وہ بیٹھیں گے۔

ہم کیا احاطہ کریں گے:

انٹیک کے مسائل

استعمال کے معاملات کے ذریعے اسٹیک/حل کی ساخت کو سمجھنا آسان ہے۔ اعلیٰ سطح کا مقصد رجحان کے تجزیہ کے لیے بیرونی مارکیٹ APIs سے مالیاتی ڈیٹا اکٹھا کرنا ہے۔ ہم خاص طور پر مزید تجزیہ کے لیے اس ڈیٹا کے جمع کرنے کو گودام میں ترتیب دینے پر توجہ مرکوز کرتے ہیں۔

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

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

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

اسٹیک

مورچا FS: S3-مطابق آبجیکٹ اسٹور جو زنگ میں لکھا ہوا ہے۔
پروجیکٹ نیسی: اپاچی آئس برگ ٹیبلز کے لیے لین دین کی فہرست
اپاچی چنگاری: تقسیم شدہ کمپیوٹنگ انجن
اپاچی ایئر فلو: کاموں کا شیڈول اور کوآرڈینیٹ کریں۔
jupyter نوٹ بک (اختیاری): آئس برگ ٹیبلز پر ایڈہاک اسپارک کے سوالات اس دستاویز میں شامل نہیں ہیں۔
سکریپلڈیز: ویب کرالر کی ٹاسک قطار
سکریپ میٹل ورکر: ویب کرالر اور جمع کرنے والے کارکن

اس سیٹ اپ کا تجربہ 4-core x86/AMD CPU، 16GB RAM، 60GB ڈسک GCP VM چلانے والے Debian GNU/Linux 11 (Bullsey) پر کیا گیا۔ آپ کو کمپوز v2 کے ساتھ ڈوکر کی ضرورت ہوگی۔ سیٹ اپ کو اسی طرح کے لینکس ماحول میں ملتے جلتے یا بہتر تصریحات کے ساتھ کام کرنا چاہیے۔

سسٹم کا جائزہ

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

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

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

فوری آغاز

سب سے پہلے، اس منصوبے کو شروع کریں.

# Clone the repository
git clone https://github.com/ps-mir/data-platform

# Create the shared Docker network
docker network create data-platform

# Create host directories, set permissions, and download Spark JARs
chmod +x init.sh && ./init.sh

سروس کو درج ذیل ترتیب میں شروع کریں (شٹ ڈاؤن الٹ ترتیب میں ہے):

مورچا FS

cd rustfs && docker compose up -d

چار بجے

cd nessie && docker compose up -d

شعلہ – پہلے رن پر تعمیر کی ضرورت ہے۔

cd spark && docker compose build && docker compose up -d

سکریپ لیڈیز

cd scrapredis && docker compose up -d

ہوا کا کرنٹ – پہلے رن پر تعمیر کی ضرورت ہے۔

cd airflow-docker && docker compose build && docker compose up -d

Nessie ایک بار چلنے کے بعد Nessie نام کی جگہ بناتا ہے۔

curl -X POST http://localhost:19120/iceberg/v1/main/namespaces 
  -H "Content-Type: application/json" 
  -d '{"namespace": ["default"]}'

curl -X POST http://localhost:19120/iceberg/v1/main/namespaces 
  -H "Content-Type: application/json" 
  -d '{"namespace": ["scraper"]}'

سکریپ ورکر براہ راست میزبان پر چلتا ہے (ڈاکرائزڈ نہیں)۔ ازگر کی ضرورت ہے >=3.14۔

cd scrapworker
pip install -e .
CONFIG_PATH=./config/config.local.yaml RUSTFS_ACCESS_KEY=rustfsadmin RUSTFS_SECRET_KEY=rustfsadmin python -m scrapworker

آپ کو سکریپ ورکر کو فعال کرنے سے پہلے اسے چلانا چاہیے۔ scraper_pipeline_v1 ہوا کے بہاؤ سے۔ اس کے بغیر، پائپ لائن کام کو اٹھائے گی اور بغیر کسی کارکن کے اسے غیر معینہ مدت تک روکنے کے لیے قطار میں دھکیل دے گی۔ wait_for_completion.

Trino بھی قائم ہے، لیکن Nessie کے ساتھ انضمام کا ابھی تک تجربہ نہیں کیا گیا ہے۔

پائپ لائن پر عملدرآمد

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

چاروں پائپ لائنیں بھری ہوئی ہیں لیکن بطور ڈیفالٹ موقوف ہیں۔ ٹرگر کرنے سے پہلے ایئر فلو UI میں ہر ایک کو بند کریں۔

آئیے ہر پائپ لائن کو دیکھیں۔

Spark_static_data_v1_skeleton: ہیلو ڈی اے جی

یہ اسپارک کے بغیر ایک کم سے کم ڈی اے جی ہے اور ایک ازگر کا کام ہے جو پیغام پرنٹ کرتا ہے۔ اگر یہ سبز ہو جاتا ہے، تو ایئر فلو کا شیڈولر اور کارکن صحت مند ہیں۔ [2026-04-09 22:00:01] INFO - Task operator:

Spark_static_data_v2_submit: Spark جمع کروائیں۔

یہ PySpark جابز کو بذریعہ جمع کرتا ہے: SparkSubmitOperator آئس برگ ٹیبل میں ایک جامد ڈیٹا سیٹ بنائیں۔ کوئی تقسیم نہیں ہے، اور ہر بار جب یہ چلتا ہے تو پچھلے مواد کو اوور رائٹ کر دیا جاتا ہے۔

نیسی کیٹلاگ میں یہ اس طرح ظاہر ہوتا ہے:

Type: ICEBERG_TABLE
Metadata Location:s3://warehouse/default/static_data_e7e43123-95a7-44d2-b6d5-67c9c7aa4321/metadata/00000-08a5a2db-6f12-4f21-b2a9-de3d9123fbd3.metadata.json

Spark_partitioned_data_v1: Spark تقسیم کیا گیا۔

یہ وقت کی بنیاد پر تقسیم کے ساتھ مرحلہ 2 کو بڑھاتا ہے۔ تقسیم کی قیمت طے شدہ سلاٹ وقت سے اخذ کی گئی ہے، لہذا ہر عمل کو اس کی اپنی تقسیم کی قیمت پر لکھا جاتا ہے۔ (ds, hr, min) پچھلے تقسیم کو چھوئے بغیر تقسیم۔

RustFS میں فائل پاتھ کی مثال: warehouse/default/static_data_partitioned_b172c66f-722b-44f3-bbee-069355753ff6/data/ds=2026-03-28/hr=23/min=15/00000-4-7a196a47-2ac0-4023-af68-ca10487fccb2-0-00001.parquet

scraper_pipeline_v1: کھرچنے والی پائپ لائن

یہ پورا مجموعہ بہاؤ ہے۔ ایئر فلو کام کو سکریپریڈس کی طرف دھکیلتا ہے، اسکریپ ورکر بائننس API کو کال کرتا ہے اور خام نتائج RustFS کو لکھتا ہے، اور پھر ایئر فلو سگنل کی قطار کو Nessie کیٹلاگ میں شائع کرتا ہے۔

ہر رن کو ملتا ہے: https://api.binance.com/api/v3/trades?symbol=BTCUSDT&limit=10

ترتیب

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

پروڈکشن کی تعیناتیوں کے لیے HA کنفیگریشن، جاری والیوم مینجمنٹ، اور ہر جزو کے لیے حفاظتی سختی کی ضرورت ہوتی ہے۔
تصویر کو ایک مخصوص ورژن میں بند کر دیا گیا ہے تاکہ کھینچنے پر اسے خاموشی سے ٹوٹنے سے روکا جا سکے۔
تمام کنٹینرز ایک مشترکہ بیرونی ڈوکر نیٹ ورک کا اشتراک کرتے ہیں: data-platformیہ خدمات کو کنٹینر کے نام کو میزبان نام کے طور پر استعمال کرتے ہوئے بات چیت کرنے کی اجازت دیتا ہے۔
نہیں init.sh اسکرپٹ ڈیٹا فولڈر میں ضروری مقامی ڈائریکٹریز بناتا ہے اور ڈوکر نیٹ ورک بھی بناتا ہے۔

مورچا FS

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

MinIO خود میزبان S3-مطابقت رکھنے والے اسٹوریج کے لیے ایک فطری انتخاب تھا، لیکن یہ ایک زیادہ پابندی والے لائسنس میں چلا گیا ہے۔ RustFS ایک اوپن سورس متبادل ہے جو Rust میں لکھا گیا ہے اور مقامی ڈسکوں کے ذریعے تعاون یافتہ ہے۔

لکھنے پر، Spark S3FileIO کے ذریعے Parquet فائلوں کو براہ راست RustFS پر دھکیلتا ہے۔ Nessie ایک ساتھ ٹیبل میٹا ڈیٹا کا ارتکاب کرتا ہے، لہذا ڈیٹا اور کیٹلاگ کی حالت ایک ساتھ شامل ہیں یا بالکل نہیں۔ یہ اپاچی آئس برگ کی بنیادی ضمانت ہے۔ یعنی، یہ ڈیٹا فائلوں اور میٹا ڈیٹا دونوں کے لیے ایک جوہری عہد ہے۔

پروڈکشن یا کلاؤڈ کی تعیناتیوں کے لیے، ایک منظم آبجیکٹ اسٹوریج سروس جیسے AWS S3، Google Cloud Storage، یا Azure Blob Storage ایک قدرتی اگلا مرحلہ ہے۔ بڑے پیمانے پر خود میزبان متبادل میں SeaweedFS، Ceph/RGW، اور گیراج شامل ہیں۔

حوالہ:

بالٹی بنائیں: کوئی راستہ نہیں rustfs-init سائڈ کار استعمال کریں۔ amazon/aws-cli RustFS کے ہیلتھ چیک پاس کرنے اور جنریٹ کرنے کے بعد چلتا ہے: s3://warehouse خود بخود بالٹیاں۔ آپ دستی طور پر بالٹیاں نہیں بناتے ہیں۔
اتھارٹی: RustFS ایک کنٹینر کے اندر uid=10001 کے ساتھ چلتا ہے۔ میزبان ڈائریکٹری (data/rustfs/data اور data/rustfs/applogsکنٹینر شروع ہونے سے پہلے اس uid کی ملکیت ہونی چاہیے۔ ورنہ یہ خود بخود ناکام ہو جائے گا۔ init.sh اس سے نمٹنے sudo chown -R 10001:10001.
تصویر کا تعین: کمپوز فائل کو درج ذیل جگہ پر پن کیا گیا ہے: rustfs/rustfs:1.0.0-alpha.85-glibc. اپ گریڈ کرنے سے پہلے، یقینی بنائیں کہ uid تبدیل نہیں ہوئی ہے۔ docker run --rm --entrypoint id rustfs/rustfs:. اگر ایسا ہے تو اسے دوبارہ چلائیں۔ init.sh متبادل طور پر، آپ اسے دستی طور پر دوبارہ کاون کر سکتے ہیں۔
سپارک لکھتے ہیں: Spark S3FileIO کے ذریعے ڈیٹا فائلوں کو براہ راست RustFS پر لکھتا ہے۔ Nessie صرف کیٹلاگ میٹا ڈیٹا کا انتظام کرتا ہے اور ڈیٹا کو پراکسی نہیں کرتا ہے۔ دونوں کمٹ ٹائم پر بات چیت کرتے ہیں، وقت نہیں لکھتے۔

چار بجے

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

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

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

Spark Nessie’s Iceberg REST اینڈ پوائنٹ کے ذریعے ٹیبل میٹا ڈیٹا پڑھتا اور لکھتا ہے۔ کیٹلاگ حالت پوسٹگریس پر برقرار ہے اور اس وجہ سے کنٹینر کے دوبارہ شروع ہونے پر برقرار ہے۔

نام کی جگہ بوٹسٹریپ

Hive Metastore کے برعکس، Nessie خود بخود نام کی جگہیں نہیں بناتا ہے۔ RustFS پر ڈیٹا پہلے سے لکھے جانے کے بعد ایک غیر موجود نام کی جگہ پر ٹیبل لکھنے کی کوششیں ناکام ہو جائیں گی، اور یتیم فائلیں بغیر کیٹلاگ کے اندراجات کے رہ جائیں گی۔ نام کی جگہیں ساختی میٹا ڈیٹا ہیں اور ان کا تعلق ایک بار کے بوٹسٹریپ مرحلے سے ہے، پائپ لائن سے نہیں۔

نیسی آئس برگ کیٹلاگ میٹا ڈیٹا کا انتظام کرتی ہے۔ s3://warehouse/. آئس برگ ٹیبل ڈیٹا نام کی جگہ سے اخذ کردہ راستوں کے نیچے واقع ہے۔ مثال کے طور پر: s3://warehouse/default/ کے لیے default نام کی جگہ۔

S3 سندی ترتیب کے مسائل

Nessie کی S3 سندی فیلڈ سادہ تاروں کو قبول نہیں کرتی ہے (ممکنہ طور پر سیکورٹی وجوہات کی بناء پر)۔ آپ کو درج ذیل فارمیٹ میں ایک خفیہ URI کی ضرورت ہوگی۔ urn:nessie-secret:quarkus: مقامی اسناد کے لیے بھی یہی ہے۔

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

nessie.catalog.service.s3.default-options.access-key: "urn:nessie-secret:quarkus:nessie.catalog.secrets.access-key"
nessie.catalog.secrets.access-key.name: rustfsadmin
nessie.catalog.secrets.access-key.secret: rustfsadmin

چار بجے ہیلتھ چیک اپ

RustFS سیٹنگز میں ترمیم ہونے کے بعد، Nessie’s health check URL (http://localhost:9090/q/health) کو درج ذیل جواب واپس کرنا چاہیے:

{
    "status": "UP",
    "checks": [
        {
            "name": "MongoDB connection health check",
            "status": "UP"
        },
        {
            "name": "Warehouses Object Stores",
            "status": "UP",
            "data": {
                "warehouse.warehouse.status": "UP"
            }
        },
        {
            "name": "Database connections health check",
            "status": "UP",
            "data": {
                "": "UP"
            }
        }
    ]
}

یہاں تک کہ اگر یہ اسٹیک MongoDB استعمال نہیں کر رہا ہے تو، MongoDB کنکشن اسٹیٹس چیک جواب میں ظاہر ہوگا۔ Quarkus بلٹ ان پروبس جو اسٹور کی قسم سے قطع نظر خود بخود رجسٹرڈ ہوتی ہیں۔ JDBC کے کنفیگر ہونے کے بعد، MongoDB منسلک نہیں ہوتا ہے اور UP رپورٹ صرف پلیس ہولڈر کا جواب ہے۔

کیٹلاگ اختتامی نقطہ اور انتظام

نیسی نے دو الگ الگ APIs کو بے نقاب کیا۔ Iceberg REST کیٹلاگ یہاں واقع ہے: /iceberg. یہ وہی ہے جو اسپارک اور ٹرینو سے جڑے ہوئے ہیں۔ Nessie Management API یہاں واقع ہے: /api/v2یہ برانچ آپریشنز، کمٹ ہسٹری، اور ٹیبل انسپیکشن کے لیے ہے۔ وہ قابل تبادلہ نہیں ہیں۔

# Iceberg REST API
http://localhost:19120/iceberg/v1/main/namespaces
http://localhost:19120/iceberg/v1/config

# Nessie management API
http://localhost:19120/api/v2/config

حوالہ:

path-style-access: true غیر AWS S3 اینڈ پوائنٹس کے لیے درکار ہے۔ region یہ ایک ڈمی قدر ہے جس کی اندرونی طور پر AWS SDK کو ضرورت ہے۔
رسٹ ایف ایس کے ساتھ تنازعات سے بچنے کے لیے نیسی کی اندرونی بندرگاہ 9000 کو میزبان پر 9090 میں دوبارہ بنایا گیا ہے، جس میں 9000 اور 9001 شامل ہیں۔

ترسیل کا راستہ

چونکہ Nessie ایک سٹیٹ لیس REST سروس ہے، یہ انٹر نوڈ کوآرڈینیشن کے بغیر ریڈ اسکیلنگ انجام دینے کے لیے LB کا استعمال کر سکتی ہے۔ استحکام مکمل طور پر بیک اینڈ اسٹوریج سے آتا ہے۔

شعلہ

Apache Spark، ایک تقسیم شدہ کمپیوٹنگ انجن، طویل عرصے سے چلنے والے کاموں کے لیے ایک قابل اعتماد اور قابل اعتماد انتخاب ہے۔ موجودہ سیٹ اپ ایئر فلو کے ذریعے جمع کرائی گئی PySpark جابز چلاتا ہے، Nessie REST کیٹلاگ کے ذریعے Iceberg ٹیبل پڑھتا اور لکھتا ہے، اور S3FileIO کا استعمال کرتے ہوئے ڈیٹا فائلوں کو براہ راست RustFS پر لکھتا ہے۔ چنگاری اسٹینڈ اسٹون موڈ میں ایک ہی ماسٹر اور ورکر کے ساتھ چلتی ہے جس کے ساتھ ترتیب دیا گیا ہے: spark-defaults.conf.

دو JAR درکار ہیں اور درج ذیل جگہوں پر رکھے جائیں: data/spark/jars/ شروع کرنے سے پہلے:

iceberg-spark-runtime-3.5_2.12: اسپارک کے لیے آئس برگ انٹیگریشن: SparkCatalog، DataFrameWriterV2، SQL ایکسٹینشنز، اور تمام ٹیبلولر منطق۔
iceberg-aws-bundle: AWS SDK v2 اور Iceberg سے S3FileIO ڈیٹا فائلوں کو RustFS پر لکھنے کے لیے ایک اسٹوریج ٹرانسپورٹ لیئر ہے۔ اسپارک بیس امیج صرف Hadoop AWS (SDK v1) فراہم کرتی ہے۔ یہ بنڈل S3FileIO کے لیے درکار SDK v2 کلاسز فراہم کرتا ہے۔

Spark اپنی مرضی کے مطابق Dockerfile کا استعمال کرتے ہوئے Python 3.12 کو انسٹال کرتا ہے۔ پہلے استعمال سے پہلے تصویر بنائیں۔

cd spark
docker compose build
docker compose up -d

PySpark جابز ایئر فلو سیکشن میں شامل ہیں، جہاں ہم پائپ لائن کے حصے کے طور پر ہر DAG اور اس کے Spark اسکرپٹ کو دیکھتے ہیں۔

اسپارک جاب جمع کرانے سے پہلے جو آئس برگ ٹیبل بناتا ہے، نیسی میں ٹارگٹ نیم اسپیس کا ہونا ضروری ہے۔ Nessie، Hive Metastore کے برعکس، خود بخود نام کی جگہیں نہیں بناتا ہے۔ RustFS پر ڈیٹا پہلے سے لکھے جانے کے بعد گمشدہ نام کی جگہ پر لکھنے کی کوششیں ناکام ہو جائیں گی، اور یتیم فائلیں بغیر کیٹلاگ کے اندراجات کے رہ جائیں گی۔

نسل default اپنی پائپ لائن چلانے سے پہلے ایک بار نام کی جگہ استعمال کریں۔

# Nessie should be up and running at this point
curl -X POST http://localhost:19120/iceberg/v1/main/namespaces 
  -H "Content-Type: application/json" 
  -d '{"namespace": ["default"]}'
{
  "namespace" : [ "default" ],
  "properties" : { }
}

چیک کریں:

curl http://localhost:19120/iceberg/v1/main/namespaces

کیٹلاگ کی مماثلت: پورے استفسار کے انجن میں ٹیبل غائب ہے۔

اگر اسپارک میں بنایا گیا ٹیبل Trino میں ظاہر نہیں ہوتا ہے، تو ممکنہ طور پر کیٹلاگ کی مماثلت اس کی وجہ ہے۔ چنگاری پر مشتمل ہے: NessieCatalog Iceberg REST کیٹلاگ کا استعمال کرتے ہوئے Trino اور Trino الگ الگ میٹا ڈیٹا کے نظارے کو برقرار رکھتے ہیں اور ٹیبل کی حالت کا اشتراک نہیں کرتے ہیں۔ دونوں انجنوں کو ایک ہی کیٹلاگ اینڈ پوائنٹ کی طرف اشارہ کرنا چاہیے۔ http://nessie:19120/iceberg.

حوالہ:

کارکن کی یادداشت: کارکن پر مشتمل ہے: SPARK_WORKER_MEMORY: 8g. Spark کا ڈیفالٹ 1g ہے، جو رجسٹر کرنے کے لیے کافی ہے، لیکن قطار کے بغیر کام چلانے کے لیے کافی نہیں ہے۔ دستیاب میزبان میموری کی بنیاد پر اسے ایڈجسٹ کریں۔
ریموٹ دستخط: remote-signing-enabled: false Nessie کا REST کیٹلاگ IAM/STS کے ذریعے اسناد فروخت کرنے کی حمایت کرتا ہے، لیکن اس میں یہ انضمام نہیں ہے، اس لیے درخواست کی ناکامی کو روکنے کے لیے ریموٹ سائننگ کو واضح طور پر غیر فعال کر دیا گیا ہے۔
کنفیگریشن تبدیلیاں مکمل ری اسٹارٹ کی ضرورت ہے۔ جب کنٹینر شروع ہوتا ہے تو ڈوکر فائل لیول بائنڈنگ کیشے انوڈز کو ماؤنٹ کرتا ہے۔ ترمیم کریں spark-defaults.conf اس کا اثر اس وقت تک نہیں ہوگا جب تک اسپارک اور ایئر فلو ورکرز دوبارہ شروع نہیں ہوجاتے۔ کلائنٹ موڈ میں، ایئر فلو ورکرز اسپارک ڈرائیور ہیں (وہ عمل جو جاب جمع کرواتے وقت کنفیگریشن پڑھتے ہیں) اور اس لیے دوبارہ شروع کرنے کی ضرورت ہوتی ہے۔
Jupyter نوٹ بک: PySpark کے ساتھ ایک Jupyter مثال آئس برگ ٹیبلز کے خلاف ایڈہاک سوالات کے اسٹیک میں شامل ہے۔ چونکہ آپ ایک ہی اسپارک کلسٹر اور نیسی کیٹلاگ سے جڑے ہوئے ہیں، آپ پائپ لائن کے ذریعہ بنائے گئے کسی بھی ٹیبل سے فوری طور پر استفسار کرسکتے ہیں۔

انتباہ: اسپارک ورکرز اور ایئر فلو ورکرز (ڈرائیور) کو ایک ہی Python مائنر ورژن چلانا چاہیے۔ PySpark اسے رن ٹائم پر نافذ کرتا ہے اور اگر کانٹا لگ جاتا ہے تو فوراً ناکام ہوجاتا ہے۔ اس اسٹیک کے لیے اسپارک امیج Python 3.12 کو انسٹال کرنے کے لیے اپنی مرضی کے مطابق Dockerfile کا استعمال کرتی ہے، جو Airflow کی بنیادی تصویر سے مماثل ہے۔ اگر آپ دونوں میں سے کسی ایک کو اپ گریڈ کرتے ہیں، تو یقینی بنائیں کہ ورژن سیدھ میں رہیں۔

اپاچی ایئر فلو

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

سرکاری دستاویزات سے ایئر فلو کے اجزاء ڈی اے جی پروسیسر ایئر فلو فن تعمیر سے زیادہ ملتے جلتے ہیں۔

اہم پہلو:

ڈی اے جی پروسیسر مسلسل ڈی اے جی فائلوں کو پارس کرتا ہے اور انہیں میٹا ڈیٹا ڈیٹا بیس میں سیریلائز کرتا ہے۔
شیڈیولر یہاں سے پڑھتا ہے، ڈی اے جی پر عمل درآمد کی آخری تاریخ کا پتہ لگاتا ہے، ایک ٹاسک مثال بناتا ہے، اور اسے ریڈیس قطار کے ذریعے CeleryExecutor کی طرف دھکیلتا ہے۔
اجوائن کے کارکنان کاموں کو منتخب اور انجام دیتے ہیں۔ کے لیے SparkSubmitOperatorکارکن عمل اسپارک ڈرائیور بن جاتے ہیں اور اسپارک کلسٹر میں ملازمتیں جمع کراتے ہیں۔
ایگزیکیوٹر اسپارک ورکرز پر چلتا ہے، پارکیٹ فائلیں براہ راست RustFS کو لکھتا ہے، اور Nessie کو ٹیبل میٹا ڈیٹا بھیجتا ہے۔ ایئر فلو آپریشن کے نتائج کو واپس میٹا ڈیٹا DB پر لکھتا ہے۔

ایئر فلو جاوا 17 اور اضافی فراہم کنندگان کو انسٹال کرنے کے لیے اپنی مرضی کے مطابق ڈاکر فائل کا استعمال کرتا ہے۔ پہلے استعمال سے پہلے تصویر بنائیں۔

cd airflow-docker
docker compose build
docker compose up -d

پائپ لائن

ہمیں اس کے اندر ایک پائپ لائن بنانے کی ضرورت ہے۔ airflow-docker/dags یہ ڈی اے جی پروسیسر کے لیے پائپ لائن ڈی اے جی کو میٹا ڈیٹا ڈی بی میں لوڈ کرنے کا فولڈر ہے۔ مختلف پیچیدگی کی چار پائپ لائن مثالیں فراہم کی گئی ہیں۔

step1_hello_dag.py: ایک واحد ٹاسک DAG جس میں کوئی انحصار نہیں ہے اور ایک Python فنکشن جو پیغام پرنٹ کرتا ہے۔
step2_spark_submit.py: SparkSubmitOperator کے ذریعے PySpark جاب جمع کروائیں۔ یہ جاب نیسی کیٹلاگ کے ذریعے ایک آئس برگ ٹیبل پر ایک جامد ڈیٹا سیٹ لکھتا ہے۔
step3_spark_partitioned.py: وقت کی بنیاد پر تقسیم کے ساتھ مرحلہ 2 کو بڑھاتا ہے۔ مخصوص سلاٹ ٹائم PySpark اسکرپٹ میں گزر جاتا ہے۔
- وقت پر مبنی تقسیم کی قدریں اس سے اخذ کی گئی ہیں: data_interval_start کمزوری کے لیے (بیک فل، دوبارہ چلائیں)۔
scraper_pipeline: اصل جمع کرنے کی پائپ لائن۔ بیرونی ٹاسک ایگزیکیوٹرز کے ساتھ کوآرڈینیٹ کریں۔ scrapworker ریڈیس قطار کے ذریعے scrapredis.
- دونوں scrapredis اور scrapworker اس پائپ لائن کو کام کرنے کے لیے چلنا چاہیے۔

تعیناتی موڈ اور ڈرائیور کی ترتیب

آغاز SparkSubmitOperator کنفیگریشن استعمال کی گئی۔ deploy_mode="cluster"ڈرائیور کو اسپارک کلسٹر پر چلائیں، جمع کرانے کے نظام پر نہیں۔ یہ سخت خرابی کے ساتھ اسپارک اسٹینڈ الون کلسٹرز پر فوری طور پر ناکام ہو جائے گا۔

Cluster deploy mode is currently not supported for python applications on standalone clusters.

Python کے لیے کلسٹر وضع صرف YARN اور Kubernetes کے لیے دستیاب ہے۔ یہاں اصلاحات ہیں: deploy_mode="client"لیکن اس سے مسئلہ بدل جاتا ہے۔ کلائنٹ موڈ میں، ڈرائیور ایئر فلو ورکر کنٹینر میں چلتا ہے۔ اس کا مطلب ہے کہ کارکنوں کو ہر اس چیز کی ضرورت ہے جو اسپارک کنٹینر میں ہے۔

مجموعی طور پر، ایئر فلو کارکن کو تین تبدیلیوں کی ضرورت ہے:

یہاں آئس برگ اور نیسی جار ہیں: /opt/spark/user-jars/
spark-defaults.conf کیٹلاگ، ایکسٹینشن، اور JAR کنفیگریشن پر مشتمل ہے۔
SPARK_CONF_DIR=/opt/spark/confاس کے بغیر، آپ پائپ کے ساتھ نصب PySpark استعمال کر سکتے ہیں۔ spark-submit یہ خود کار طریقے سے نصب conf فائلوں کو نظر انداز کرتا ہے اور بغیر کسی کیٹلاگ کی ترتیب کے چلتا ہے۔

طے یہ تھا کہ تینوں کو شامل کیا جائے۔ x-airflow-common کو airflow-docker/docker-compose.yaml لہذا، تمام ایئر فلو خدمات اسے وراثت میں ملتی ہیں۔

environment:
  SPARK_CONF_DIR: /opt/spark/conf

volumes:
  - ../data/spark/jars:/opt/spark/user-jars:ro
  - ../spark/spark-defaults.conf:/opt/spark/conf/spark-defaults.conf:ro

تقسیم کی قدر NULL کے طور پر لکھی گئی ہے۔

جب تیسری پائپ لائن (اسپارک پارٹیشنڈ) کو پہلی بار چلایا گیا تو، ڈیٹا رسٹ ایف ایس میں صحیح طریقے سے پہنچا، لیکن آئس برگ پارٹیشن میٹا ڈیٹا سے استفسار کرنے سے درج ذیل نتائج برآمد ہوئے:

+------------------+----------+
|         partition|file_count|
+------------------+----------+
|{NULL, NULL, NULL}|         2|
+------------------+----------+

اصل اسکرپٹ میں Spark’s DataSource V1 API استعمال کیا گیا تھا۔

df.write.format("iceberg").mode("overwrite").saveAsTable(table)

اسکرپٹ میں اسپارک کے V1 ڈیٹا فریم رائٹ API کا استعمال کیا گیا ہے، جو الگ تھلگ جدول کے حوالہ جات کو لوڈ کرتا ہے اور ایک فارمیٹ ("آئس برگ”) استعمال کرتا ہے جو آئس برگ کے کیٹلاگ لکھنے کے راستے کو نظرانداز کرتا ہے۔ نتیجے کے طور پر، آئس برگ نے ڈیٹا فائلوں کو ذخیرہ کرنے کا عہد کیا لیکن مینی فیسٹ میٹا ڈیٹا میں NULL پارٹیشن ویلیو لکھا۔

حل آئس برگ کے مقامی DataFrameWriterV2 API میں ہے۔

df.writeTo(table).overwritePartitions()

یہ آئس برگ کے پہلے سے طے شدہ تحریری راستے سے گزرتا ہے، اصل کالم اقدار (ds, hr, min) پر تقسیم کی تبدیلی کا جائزہ لیتا ہے اور انہیں مینی فیسٹ میں صحیح طریقے سے رجسٹر کرتا ہے۔ overwritePartitions() ڈیٹا فریم میں صرف پارٹیشنز کو اوور رائٹ کیا جاتا ہے۔ اسی مقررہ وقت کے ساتھ اسے دوبارہ چلانے سے وہی قدریں پیدا ہوں گی اور جوہری طور پر اس پارٹیشن کو بدل دیں گے، باقی تمام پارٹیشنز برقرار رہیں گے۔

موجودہ NULL پارٹیشن مینی فیسٹ اندراجات کو بعد میں آنے والی V2 تحریروں کے ذریعے سابقہ طور پر تبدیل نہیں کیا جائے گا۔ نئی جدولوں کے لیے جن میں صرف خراب ڈیٹا ہوتا ہے، DROP TABLE اور دوبارہ لکھنا آسان ترین بازیافت کے طریقے ہیں۔

سکریپ لیڈیز

Scrapredis ایک وقف شدہ Redis مثال ہے جو Airflow اور Scrapworker کے درمیان کام کی قطار کے طور پر بیٹھتی ہے۔ یہ Airflow کے اندرونی Redis سے الگ ہے، جو صرف CeleryExecutor کے کاموں کو بھیجنے کے لیے موجود ہے۔ ڈیکپلنگ کا مطلب یہ ہے کہ آپ ایئر فلو کے اندرونی حصوں کو چھوئے بغیر کرالر کے کام کی قطار کو منظم، پیمانے یا تبدیل کر سکتے ہیں۔

پیٹرن سکریچنگ سے باہر عام کرتا ہے. کوئی بھی بیرونی عمل جس کے لیے اس کے اپنے لائف سائیکل، ریسورس پروفائل، یا ریٹ محدود کرنے کی ضرورت ہوتی ہے اسی طرح سے منسلک کیا جا سکتا ہے۔ یعنی، ایئر فلو کام کو آگے بڑھاتا ہے، ایک بیرونی کارکن اسے پاپ کرتا ہے، اور نتائج کے لیے ایئر فلو پول کرتا ہے۔

کھرچنے والی پائپ لائن مندرجہ ذیل راؤنڈ ٹرپ کی پیروی کرتی ہے:

ہوا کا بہاؤ ملازمت کے پے لوڈ کو ایک قطار میں دھکیلتا ہے۔

QUEUE_KEY = "scrapworker:jobs"
client.lpush(QUEUE_KEY, json.dumps(payload))

سکریپ ورکر قطار کو روکتا ہے اور اگلے کام کو پاپ کرتا ہے۔

while True:
    _, payload = client.blpop(redis_cfg["queue_key"])

جب کرال مکمل ہو جاتا ہے، سکریپ ورکر نتائج لکھتا ہے اور s3_path Redis پر واپس جائیں:

client.set(status_key, json.dumps({"status": "finished", "worker_id": worker_id, "s3_path": job["s3_path"]}), ex=TERMINAL_TTL)

کہ wait_for_completion اس کی حیثیت کی کلید کے لیے آپریشن کو پول کریں۔ اگر کامیاب ہو، publish_nessie_signal اٹھاؤ s3_path نیسی کو سگنل لائن لکھیں۔

سکریپ دھاتی کارکن

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

آبجیکٹ اسٹوریج (RustFS) پر مواد ڈاؤن لوڈ اور لکھنے کے لیے ذمہ دار ہے۔ Nessie کیٹلاگ اپ ڈیٹس کو الگ کیا جاتا ہے اور ایک علیحدہ ایئر فلو پائپ لائن جاب میں رکھا جاتا ہے۔

فکسڈ سگنل ٹیبل

اسکریپ شدہ ڈیٹا کو براہ راست آئس برگ کالموں میں لکھنے کے بجائے، سکریپ ورکر RastFS کو خام JSON لکھتا ہے۔ اس کے بعد پائپ لائن نیسی کے زیر انتظام آئس برگ ٹیبل پر ایک ہلکے وزن کے سگنل کی قطار شائع کرتی ہے۔

سگنلنگ اسکیما طے شدہ اور کم سے کم ہے (run_id، endpoint، s3_path، ds، hr، min، published_at)۔ اس سے کوئی فرق نہیں پڑتا ہے کہ آپ کیا کھرچتے ہیں، یہ کبھی نہیں بدلتا۔

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

Scrapworker  →  raw files in RustFS  +  signal row in Iceberg (from Pipeline)
Airflow job  →  reads raw via s3_path, applies schema, writes structured Iceberg table

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

کیوں سگنل پبلش کرنا ایک الگ ایئر فلو ٹاسک ہے۔

سکریپ ورکر RustFS لکھتا اور ترتیب دیتا ہے۔ status: finished ریڈیس میں s3_path. ایک الگ ایئر فلو ٹاسک اس حالت کو پڑھتا ہے اور نیسی کو سگنل لائن پوسٹ کرتا ہے۔ دونوں تحریروں کو جان بوجھ کر الگ کیا گیا تھا۔

اگر Scrapworker RustFS کو لکھنے کے فوراً بعد نیسی کو شائع کرتا ہے، تو دونوں تحریریں ناکامی کے موڈ کا اشتراک کرتی ہیں۔ اگر Nessie کامیاب RustFS لکھنے کے بعد ناکام ہو جاتا ہے، تو آپ کا ڈیٹا بغیر کسی سگنل کے پھنسا ہوا ہے اور نہ ہی صاف بحالی کا راستہ۔ واحد آپشن دوبارہ کرال کرنا ہے، جس میں بے حسی کا فقدان ہے۔

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

حوالہ:

خام سکریپ فائلوں کو براہ راست لکھا جاتا ہے: s3://warehouse/raw/بالکل نیسی کے قابو سے باہر۔ آئس برگ کی تہہ میں کوئی بھی چیز اس راستے تک نہیں پہنچتی۔
سکریپ آپریٹر سگنل ٹیبل ایک مخصوص علاقے میں واقع ہے۔ scraper نام کی جگہ۔ سکریپ ورکر پہلی بار چلنے سے پہلے اسے ایک بار بنائیں۔

curl -X POST http://localhost:19120/iceberg/v1/main/namespaces 
  -H "Content-Type: application/json" 
  -d '{"namespace": ["scraper"]}'

آگے کا راستہ

ہم نے یہاں جو اسٹیک بنایا ہے وہ کام کرنے والی ادخال کی پرت ہے۔ یہ ایک ایسی بنیاد فراہم کرتا ہے جس پر آپ اپنے ڈیٹا کو قابل اعتماد طریقے سے رکھ سکتے ہیں، اسے ورژن والے کیٹلاگ میں ٹریک کر سکتے ہیں، اور اس پر تعمیر کر سکتے ہیں۔ یہاں دو سمتوں پر غور کرنے کے قابل ہے۔

خصوصیت کی توسیع

یہ اسٹیک میں پہلے سے موجود فعالیت کو بہتر بناتا ہے، نئے اجزاء کو شامل کیے بغیر اسٹیک کو مزید طاقتور بناتا ہے۔

انٹیک وشوسنییتا: سکریپ ورکر فی الحال ترتیب دے کر غلطیوں کو سنبھالتا ہے: status: failed ریڈیس کو پوری پائپ لائن کو دوبارہ متحرک کرنے کے لیے ایئر فلو کی ضرورت ہوتی ہے۔ بیک آف کا استعمال کرتے ہوئے کلائنٹ سائیڈ ریٹ کو محدود کرنے اور فی اینڈ پوائنٹ دوبارہ کوشش کرنے والی منطق کو شامل کرنے سے کرال آپریشنز کی خود کو ٹھیک کرنے کی صلاحیتوں میں بہتری آتی ہے، جس سے صفحہ کی ناکامی کو ایئر فلو کو بالکل بھی نظر آنے کے بغیر آزادانہ طور پر دوبارہ آزمایا جا سکتا ہے۔

ترتیب کی توثیق: اختتامی نقطہ اسکیما کو غلط کنفیگر کیا گیا۔ config.yaml وہ رن ٹائم میں خاموشی سے ناکام ہو جاتے ہیں اور اکثر رینگتے ہوئے گہرائی میں گر جاتے ہیں۔ کوئی راستہ نہیں validate_config() اسے سٹارٹ اپ پر کال کرنے سے کوئی بھی غائب مطلوبہ فیلڈ پکڑ سکتا ہے، جیسے: offset_param یا response_map اس سے پہلے کہ کام چل جائے۔ یہ مزید اہم ہو جاتا ہے کیونکہ مزید اختتامی نکات شامل کیے جاتے ہیں۔

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

پرت شامل کریں۔

یہ ایک نئی خصوصیت ہے جو ہماری کلیکشن فاؤنڈیشن پر بنتی ہے۔

تہوں کو تبدیل کریں: خام آئس برگ ٹیبل جو ادخال کی پرت کے ذریعہ تخلیق کیا گیا ہے وہ تبدیلی کے مرحلے کا ان پٹ ہے۔ ڈی بی ٹی یا اسپارک ایس کیو ایل خام سے پڑھ سکتے ہیں، اسکیما کا اطلاق کرسکتے ہیں، قسم کی کٹائی کرسکتے ہیں، اور الگ الگ نام کی جگہ پر ساختی میزیں لکھ سکتے ہیں۔ یہ ELT کا L ہے اور انٹیک کے مستحکم ہونے کے بعد قدرتی اگلا مرحلہ ہے۔

ہرمینیٹکس: Trino پہلے سے ہی اسٹیک میں ہے اور جزوی طور پر مربوط ہے۔ Nessie سے مکمل طور پر منسلک تمام آئس برگ ٹیبلز پر SQL سوالات کو قابل بناتا ہے۔ سب سے اوپر ایک سپر سیٹ شامل کرنے سے ادخال کی پائپ لائن میں کسی تبدیلی کی ضرورت کے بغیر تصور کی ایک پرت ملتی ہے۔

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

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

ہم کیا احاطہ کریں گے:

انٹیک کے مسائل

اسٹیک

سسٹم کا جائزہ

فوری آغاز

پائپ لائن پر عملدرآمد

Spark_static_data_v1_skeleton: ہیلو ڈی اے جی

Spark_static_data_v2_submit: Spark جمع کروائیں۔

Spark_partitioned_data_v1: Spark تقسیم کیا گیا۔

scraper_pipeline_v1: کھرچنے والی پائپ لائن

ترتیب

مورچا FS

حوالہ:

چار بجے

نام کی جگہ بوٹسٹریپ

S3 سندی ترتیب کے مسائل

چار بجے ہیلتھ چیک اپ

کیٹلاگ اختتامی نقطہ اور انتظام

حوالہ:

ترسیل کا راستہ

شعلہ

کیٹلاگ کی مماثلت: پورے استفسار کے انجن میں ٹیبل غائب ہے۔

حوالہ:

اپاچی ایئر فلو

پائپ لائن

تعیناتی موڈ اور ڈرائیور کی ترتیب

تقسیم کی قدر NULL کے طور پر لکھی گئی ہے۔

سکریپ لیڈیز

سکریپ دھاتی کارکن

فکسڈ سگنل ٹیبل

کیوں سگنل پبلش کرنا ایک الگ ایئر فلو ٹاسک ہے۔

حوالہ:

آگے کا راستہ

خصوصیت کی توسیع

پرت شامل کریں۔

Related Posts