ہیلو، حبر! ایک نئے کورس کے سلسلے کے لیے اندراج ابھی OTUS پر کھلا ہے۔ . کورس کے آغاز کی توقع میں، ہم آپ کے ساتھ مفید مواد کا اشتراک جاری رکھیں گے۔
ڈیٹا مینجمنٹ
مضبوط ڈیٹا گورننس ٹویٹر انجینئرنگ کا بنیادی اصول ہے۔ جیسا کہ ہم اپنے پلیٹ فارم میں BigQuery کو نافذ کرتے ہیں، ہم ڈیٹا کی دریافت، رسائی کنٹرول، سیکیورٹی اور رازداری پر توجہ مرکوز کرتے ہیں۔
ڈیٹا کو دریافت کرنے اور اس کا نظم کرنے کے لیے، ہم نے اپنی ڈیٹا تک رسائی کی تہہ کو بڑھا دیا ہے۔ ) آن پریمیسس اور گوگل کلاؤڈ ڈیٹا دونوں کے لیے ٹولز فراہم کرنے کے لیے، ہمارے صارفین کے لیے ایک ہی انٹرفیس اور API فراہم کرنا۔ بطور گوگل عام دستیابی کی طرف بڑھ رہا ہے، ہم صارفین کو کالم تلاش جیسی خصوصیات فراہم کرنے کے لیے اسے اپنے پروجیکٹس میں شامل کریں گے۔
BigQuery ڈیٹا کا اشتراک اور اس تک رسائی کو آسان بناتا ہے، لیکن ہمیں ڈیٹا کے اخراج کو روکنے کے لیے اس پر کچھ کنٹرول رکھنے کی ضرورت ہے۔ دوسرے ٹولز میں، ہم نے دو فنکشنز کا انتخاب کیا:
- : صارفین کو ٹویٹر سے باہر کے صارفین کے ساتھ BigQuery ڈیٹاسیٹس کا اشتراک کرنے سے روکنے کے لیے بیٹا فیچر۔
- : ایک ایسا کنٹرول جو ڈیٹا کے اخراج کو روکتا ہے اور صارفین کو معلوم IP ایڈریس رینجز سے BigQuery تک رسائی کی ضرورت ہوتی ہے۔
ہم نے سیکورٹی کے لیے تصدیق، اجازت، اور آڈیٹنگ (AAA) کے تقاضوں کو مندرجہ ذیل طور پر لاگو کیا ہے:
- توثیق: ہم نے ایڈہاک درخواستوں کے لیے GCP صارف اکاؤنٹس اور پیداوار کی درخواستوں کے لیے سروس اکاؤنٹس کا استعمال کیا۔
- اجازت: ہمیں ہر ڈیٹاسیٹ کا مالک سروس اکاؤنٹ اور ریڈر گروپ کی ضرورت ہے۔
- آڈیٹنگ: ہم نے آسانی سے تجزیہ کرنے کے لیے BigQuery اسٹیک ڈرایور لاگز برآمد کیے، جن میں استفسار کی تفصیلی معلومات شامل تھیں۔
اس بات کو یقینی بنانے کے لیے کہ ٹویٹر کے صارفین کے ذاتی ڈیٹا کو صحیح طریقے سے ہینڈل کیا جائے، ہمیں تمام BigQuery ڈیٹا سیٹس کو رجسٹر کرنا، ذاتی ڈیٹا کی تشریح کرنا، مناسب اسٹوریج کو برقرار رکھنا، اور صارفین کے ذریعے حذف کیے گئے ڈیٹا کو حذف کرنا (اسکریپ) کرنا چاہیے۔
ہم نے گوگل کو دیکھا ، جو حساس ڈیٹا کی درجہ بندی اور ترمیم کرنے کے لیے مشین لرننگ کا استعمال کرتا ہے، لیکن درستگی کی وجہ سے ڈیٹاسیٹ کو دستی طور پر تشریح کرنے کے حق میں فیصلہ کیا۔ ہم اپنی مرضی کے مطابق تشریح کو بڑھانے کے لیے ڈیٹا کے نقصان سے بچاؤ کا API استعمال کرنے کا ارادہ رکھتے ہیں۔
Twitter پر، ہم نے BigQuery میں ڈیٹا سیٹس کے لیے رازداری کے چار زمرے بنائے ہیں، جو یہاں حساسیت کے نزولی ترتیب میں درج ہیں:
- انتہائی حساس ڈیٹا سیٹ کم از کم استحقاق کے اصول کی بنیاد پر ضرورت کے مطابق دستیاب کرائے جاتے ہیں۔ ہر ڈیٹا سیٹ میں قارئین کا ایک الگ گروپ ہوتا ہے، اور ہم انفرادی اکاؤنٹس کے ذریعے استعمال کو ٹریک کریں گے۔
- درمیانے درجے کی حساسیت والے ڈیٹا سیٹس (ایک طرفہ تخلص جو نمکین ہیشنگ کا استعمال کرتے ہوئے) میں ذاتی طور پر قابل شناخت معلومات (PII) شامل نہیں ہیں اور یہ ملازمین کے ایک بڑے گروپ کے لیے قابل رسائی ہیں۔ یہ رازداری کے خدشات اور ڈیٹا افادیت کے درمیان ایک اچھا توازن ہے۔ یہ ملازمین کو تجزیہ کے کام انجام دینے کی اجازت دیتا ہے، جیسے کہ حقیقی صارفین کون ہیں یہ جانے بغیر، فیچر استعمال کرنے والے صارفین کی تعداد کا حساب لگانا۔
- تمام صارف کی شناخت کرنے والی معلومات کے ساتھ کم حساسیت والے ڈیٹا سیٹس۔ رازداری کے نقطہ نظر سے یہ ایک اچھا طریقہ ہے، لیکن صارف کی سطح کے تجزیہ کے لیے استعمال نہیں کیا جا سکتا۔
- عوامی ڈیٹا سیٹس (Twitter کے باہر جاری کیے گئے) Twitter کے تمام ملازمین کے لیے دستیاب ہیں۔
جہاں تک لاگنگ کا تعلق ہے، ہم نے BigQuery ڈیٹاسیٹس کو شمار کرنے اور انہیں ڈیٹا ایکسیس لیئر ()، ٹویٹر میٹا ڈیٹا ریپوزٹری۔ صارفین رازداری کی معلومات کے ساتھ ڈیٹاسیٹس کی تشریح کریں گے اور برقرار رکھنے کی مدت بھی بیان کریں گے۔ جہاں تک صفائی کا تعلق ہے، ہم دو اختیارات کی کارکردگی اور لاگت کا جائزہ لیتے ہیں: 1. GCS میں ڈیٹا سیٹس کو اسکیلڈنگ جیسے ٹولز کا استعمال کرتے ہوئے صاف کرنا اور انہیں BigQuery میں لوڈ کرنا؛ 2. BigQuery DML بیانات کا استعمال۔ ہم ممکنہ طور پر مختلف گروپوں اور ڈیٹا کی ضروریات کو پورا کرنے کے لیے دونوں طریقوں کا مجموعہ استعمال کریں گے۔
سسٹم کی فعالیت
چونکہ BigQuery ایک منظم سروس ہے، اس لیے ٹویٹر کی SRE ٹیم کو سسٹم مینجمنٹ یا ڈیسک ڈیوٹی میں شامل کرنے کی ضرورت نہیں تھی۔ اسٹوریج اور کمپیوٹنگ دونوں کے لیے زیادہ صلاحیت فراہم کرنا آسان تھا۔ ہم گوگل سپورٹ کے ساتھ ٹکٹ بنا کر سلاٹ ریزرویشن کو تبدیل کر سکتے ہیں۔ ہم نے ان شعبوں کی نشاندہی کی جن میں بہتری لائی جا سکتی ہے، جیسے سیلف سروس سلاٹ مختص کرنا اور نگرانی کے لیے ڈیش بورڈ میں بہتری، اور وہ درخواستیں Google کو جمع کرائیں۔
قیمت
ہمارے ابتدائی تجزیے سے پتہ چلتا ہے کہ BigQuery اور Presto کے لیے استفسار کے اخراجات ایک ہی سطح پر تھے۔ کے لیے ہم نے سلاٹ خریدے۔ ادائیگی کے بجائے مستحکم ماہانہ لاگت کے لیے قیمت پروسیسڈ ڈیٹا کے فی ٹی بی۔ یہ فیصلہ ان صارفین کے تاثرات پر بھی مبنی تھا جو ہر درخواست کرنے سے پہلے لاگت کے بارے میں نہیں سوچنا چاہتے تھے۔
BigQuery میں ڈیٹا اسٹور کرنے سے GCS اخراجات کے علاوہ لاگت آتی ہے۔ Scalding جیسے ٹولز کے لیے GCS میں ڈیٹا سیٹس کی ضرورت ہوتی ہے، اور BigQuery تک رسائی حاصل کرنے کے لیے ہمیں وہی ڈیٹاسیٹس BigQuery فارمیٹ میں لوڈ کرنے پڑتے ہیں۔ . ہم BigQuery ڈیٹاسیٹس کے لیے ایک Scalding کنکشن پر کام کر رہے ہیں جو GCS اور BigQuery دونوں میں ڈیٹا سیٹس کو اسٹور کرنے کی ضرورت کو ختم کر دے گا۔
غیر معمولی معاملات کے لیے جن میں دسیوں پیٹا بائٹس کے نایاب سوالات کی ضرورت ہوتی ہے، ہم نے فیصلہ کیا کہ BigQuery میں ڈیٹا سیٹس کو اسٹور کرنا لاگت کے قابل نہیں تھا اور GCS میں ڈیٹا سیٹس تک براہ راست رسائی کے لیے Presto کا استعمال کیا۔ ایسا کرنے کے لیے، ہم BigQuery کے بیرونی ڈیٹا کے ذرائع کو دیکھ رہے ہیں۔
اگلے مراحل
الفا ریلیز کے بعد سے ہم نے BigQuery میں کافی دلچسپی دیکھی ہے۔ ہم BigQuery میں مزید ڈیٹا سیٹس اور مزید کمانڈز شامل کر رہے ہیں۔ ہم BigQuery اسٹوریج کو پڑھنے اور لکھنے کے لیے Scalding جیسے ڈیٹا اینالیٹکس ٹولز کے لیے کنیکٹر تیار کرتے ہیں۔ ہم BigQuery ڈیٹا سیٹس کا استعمال کرتے ہوئے انٹرپرائز کوالٹی رپورٹس اور نوٹس بنانے کے لیے Looker اور Apache Zeppelin جیسے ٹولز کو دیکھ رہے ہیں۔
Google کے ساتھ ہمارا تعاون بہت نتیجہ خیز رہا ہے اور ہمیں اس شراکت کو جاری رکھنے اور ترقی دینے پر خوشی ہے۔ ہم نے گوگل کے ساتھ مل کر کام کیا۔ براہ راست گوگل کو سوالات بھیجنے کے لیے۔ ان میں سے کچھ، جیسے BigQuery Parquet لوڈر، پہلے ہی گوگل کے ذریعے لاگو کیا جا چکا ہے۔
گوگل کے لیے ہماری کچھ اعلی ترجیحی خصوصیت کی درخواستیں یہ ہیں:
- LZO-Thrift فارمیٹ کے لیے آسان ڈیٹا ریسیپشن اور سپورٹ کے لیے ٹولز۔
- فی گھنٹہ کی تقسیم
- رسائی کنٹرول میں بہتری جیسے کہ ٹیبل-، قطار-، اور کالم کی سطح کی اجازتیں۔
- بگ سوال Hive Metastore کے انضمام اور LZO-Thrift فارمیٹ کے لیے تعاون کے ساتھ۔
- BigQuery یوزر انٹرفیس میں ڈیٹا کیٹلاگ کا بہتر انضمام
- سلاٹ مختص اور نگرانی کے لیے سیلف سروس۔
حاصل يہ ہوا
ڈیٹا اینالیٹکس، ویژولائزیشن، اور مشین لرننگ کو محفوظ طریقے سے ڈیموکریٹائز کرنا ڈیٹا پلیٹ فارم ٹیم کے لیے اولین ترجیح ہے۔ ہم نے Google BigQuery اور Data Studio کو ایسے ٹولز کے طور پر شناخت کیا جو اس مقصد کو حاصل کرنے میں مدد کر سکتے ہیں، اور BigQuery Alpha کو گزشتہ سال کمپنی بھر میں جاری کیا۔
ہم نے BigQuery میں سوالات کو سادہ اور موثر پایا۔ ہم نے سادہ پائپ لائنوں کے لیے ڈیٹا کو داخل کرنے اور تبدیل کرنے کے لیے گوگل ٹولز کا استعمال کیا، لیکن پیچیدہ پائپ لائنوں کے لیے ہمیں اپنا ایئر فلو فریم ورک بنانا تھا۔ ڈیٹا مینجمنٹ کی جگہ میں، توثیق، اجازت اور آڈیٹنگ کے لیے BigQuery کی خدمات ہماری ضروریات کو پورا کرتی ہیں۔ میٹا ڈیٹا کو منظم کرنے اور رازداری کو برقرار رکھنے کے لیے، ہمیں مزید لچک کی ضرورت تھی اور ہمیں اپنے نظام خود بنانے تھے۔ BigQuery، ایک منظم سروس ہونے کی وجہ سے، استعمال کرنا آسان تھا۔ استفسار کے اخراجات موجودہ ٹولز کی طرح تھے۔ BigQuery میں ڈیٹا اسٹور کرنے سے GCS لاگت کے علاوہ لاگت آتی ہے۔
مجموعی طور پر، BigQuery عمومی SQL تجزیہ کے لیے اچھا کام کرتا ہے۔ ہم BigQuery میں بہت زیادہ دلچسپی دیکھ رہے ہیں، اور ہم مزید ڈیٹا سیٹس کو منتقل کرنے، مزید ٹیمیں لانے اور BigQuery کے ساتھ مزید پائپ لائنیں بنانے کے لیے کام کر رہے ہیں۔ ٹویٹر مختلف قسم کے ڈیٹا کا استعمال کرتا ہے جس کے لیے ٹولز جیسے Scalding، Spark، Presto، اور Druid کی ضرورت ہوگی۔ ہم اپنے ڈیٹا اینالیٹکس ٹولز کو مضبوط کرنا جاری رکھنے کا ارادہ رکھتے ہیں اور اپنے صارفین کو اپنی پیشکشوں کو بہترین طریقے سے استعمال کرنے کے بارے میں واضح رہنمائی فراہم کرتے ہیں۔
شکریہ کے الفاظ
میں اپنے شریک مصنفین اور ٹیم کے ساتھیوں، انجو جھا اور ول پاسوکی کا شکریہ ادا کرنا چاہوں گا، ان کے اس پروجیکٹ پر زبردست تعاون اور محنت کے لیے۔ میں ٹویٹر اور گوگل کی متعدد ٹیموں کے انجینئرز اور مینیجرز کا بھی شکریہ ادا کرنا چاہوں گا جنہوں نے ہماری مدد کی اور Twitter پر BigQuery صارفین جنہوں نے قیمتی آراء فراہم کیں۔
اگر آپ ان مسائل پر کام کرنے میں دلچسپی رکھتے ہیں، تو ہمارا چیک کریں۔ ڈیٹا پلیٹ فارم ٹیم میں۔
ماخذ: www.habr.com