چگونه BigQuery گوگل تجزیه و تحلیل داده ها را دموکراتیک کرد. قسمت 2

سلام، هابر! ثبت نام برای جریان دوره جدید در حال حاضر در OTUS باز است مهندس داده. در آستانه شروع دوره، ما همچنان مطالب مفیدی را با شما به اشتراک می گذاریم.

قسمت اول را بخوانید

مدیریت اطلاعات

حکمرانی قوی داده یک اصل اصلی مهندسی توییتر است. همانطور که BigQuery را در پلتفرم خود پیاده سازی می کنیم، روی کشف داده ها، کنترل دسترسی، امنیت و حریم خصوصی تمرکز می کنیم.

برای کشف و مدیریت داده‌ها، لایه دسترسی به داده خود را گسترش داده‌ایم DAL) برای ارائه ابزارهایی برای داده های درون محل و Google Cloud، ارائه یک رابط و API واحد برای کاربرانمان. به عنوان گوگل کاتالوگ داده ها در حال حرکت به سمت دسترسی عمومی است، ما آن را در پروژه های خود قرار می دهیم تا ویژگی هایی مانند جستجوی ستونی را در اختیار کاربران قرار دهیم.

BigQuery اشتراک‌گذاری و دسترسی به داده‌ها را آسان می‌کند، اما ما باید کنترلی روی آن داشته باشیم تا از نفوذ داده‌ها جلوگیری کنیم. در میان ابزارهای دیگر، ما دو تابع را انتخاب کردیم:

• اشتراک گذاری محدود دامنه: ویژگی بتا برای جلوگیری از اشتراک گذاری مجموعه داده های BigQuery با کاربران خارج از توییتر.
• کنترل های سرویس VPC: کنترلی که از استخراج داده ها جلوگیری می کند و کاربران را ملزم به دسترسی به BigQuery از محدوده آدرس IP شناخته شده می کند.

ما الزامات احراز هویت، مجوز و ممیزی (AAA) را برای امنیت به شرح زیر پیاده سازی کرده ایم:

• احراز هویت: ما از حساب های کاربری GCP برای درخواست های موقت و حساب های سرویس برای درخواست های تولید استفاده کردیم.
• مجوز: ما از هر مجموعه داده خواستیم که یک حساب خدمات مالک و یک گروه خواننده داشته باشد.
• حسابرسی: ما گزارش‌های پشته‌درایور BigQuery را که حاوی اطلاعات دقیق اجرای پرس‌وجو بود، به یک مجموعه داده BigQuery برای تجزیه و تحلیل آسان صادر کردیم.

برای اطمینان از اینکه داده‌های شخصی کاربران توییتر به درستی مدیریت می‌شوند، باید همه مجموعه‌های داده BigQuery را ثبت کنیم، داده‌های شخصی را حاشیه‌نویسی کنیم، ذخیره‌سازی مناسب را حفظ کنیم، و داده‌هایی را که توسط کاربران حذف شده‌اند حذف کنیم (خراش دهیم).

ما به گوگل نگاه کردیم Cloud Data Loss Prevention API، که از یادگیری ماشینی برای طبقه بندی و ویرایش داده های حساس استفاده می کند، اما به دلیل دقت، به نفع حاشیه نویسی دستی مجموعه داده تصمیم گرفت. ما قصد داریم از API پیشگیری از از دست دادن داده برای تقویت حاشیه نویسی سفارشی استفاده کنیم.

در توییتر، ما چهار دسته حریم خصوصی برای مجموعه‌های داده در BigQuery ایجاد کرده‌ایم که در اینجا به ترتیب نزولی حساسیت فهرست شده‌اند:

• مجموعه داده‌های بسیار حساس بر اساس نیاز بر اساس اصل حداقل امتیاز در دسترس قرار می‌گیرند. هر مجموعه داده دارای گروهی از خوانندگان جداگانه است، و ما استفاده از حساب‌های فردی را دنبال می‌کنیم.
• مجموعه داده‌های با حساسیت متوسط ​​(نام مستعار یک طرفه با استفاده از هش سالد) حاوی اطلاعات شناسایی شخصی (PII) نیستند و برای گروه بزرگ‌تری از کارمندان قابل دسترسی هستند. این تعادل خوبی بین نگرانی های حفظ حریم خصوصی و ابزار داده است. این به کارمندان اجازه می دهد تا وظایف تجزیه و تحلیل را انجام دهند، مانند محاسبه تعداد کاربرانی که از یک ویژگی استفاده کرده اند، بدون اینکه بدانند کاربران واقعی چه کسانی هستند.
• مجموعه داده هایی با حساسیت کم با تمام اطلاعات شناسایی کاربر. این یک رویکرد خوب از منظر حفظ حریم خصوصی است، اما نمی تواند برای تجزیه و تحلیل در سطح کاربر استفاده شود.
• مجموعه داده های عمومی (که خارج از توییتر منتشر می شوند) برای همه کارمندان توییتر در دسترس است.

در مورد ورود به سیستم، ما از وظایف برنامه ریزی شده برای شمارش مجموعه داده های BigQuery و ثبت آنها در لایه دسترسی به داده استفاده کردیم (DAL)، مخزن ابرداده توییتر. کاربران مجموعه داده ها را با اطلاعات حریم خصوصی حاشیه نویسی می کنند و همچنین یک دوره نگهداری را مشخص می کنند. در مورد تمیز کردن، ما عملکرد و هزینه دو گزینه را ارزیابی می کنیم: 1. تمیز کردن مجموعه داده ها در GCS با استفاده از ابزارهایی مانند Scalding و بارگذاری آنها در BigQuery. 2. استفاده از دستورات DML BigQuery. ما احتمالاً از ترکیبی از هر دو روش برای برآوردن نیازهای گروه ها و داده های مختلف استفاده خواهیم کرد.

عملکرد سیستم

از آنجایی که BigQuery یک سرویس مدیریت شده است، نیازی به مشارکت تیم SRE توییتر در مدیریت سیستم یا وظایف میز نبود. فراهم کردن ظرفیت بیشتر هم برای ذخیره سازی و هم برای محاسبات آسان بود. می‌توانیم با ایجاد یک بلیط با پشتیبانی Google، رزرو اسلات را تغییر دهیم. ما مناطقی را شناسایی کردیم که می‌توان آنها را بهبود بخشید، مانند تخصیص اسلات سلف سرویس و بهبود داشبورد برای نظارت، و آن درخواست‌ها را به Google ارسال کردیم.

هزینه

تجزیه و تحلیل اولیه ما نشان داد که هزینه های پرس و جو برای BigQuery و Presto در یک سطح است. اسلات خریدیم برای درست شد قیمت به جای پرداخت هزینه ماهانه ثابت داشته باشد بر اساس تقاضا به ازای هر TB داده پردازش شده این تصمیم همچنین بر اساس بازخورد کاربرانی بود که نمی‌خواستند قبل از هر درخواست به هزینه‌ها فکر کنند.

ذخیره داده ها در BigQuery علاوه بر هزینه های GCS هزینه هایی را به همراه داشت. ابزارهایی مانند Scalding به مجموعه داده‌ها در GCS نیاز دارند و برای دسترسی به BigQuery باید همان مجموعه داده‌ها را در قالب BigQuery بارگذاری کنیم. خازن. ما در حال کار بر روی یک اتصال Scalding به مجموعه داده‌های BigQuery هستیم که نیاز به ذخیره مجموعه‌های داده در GCS و BigQuery را برطرف می‌کند.

برای موارد نادری که نیاز به پرس‌وجوهای نادر از ده‌ها پتابایت داشت، تصمیم گرفتیم که ذخیره مجموعه‌های داده در BigQuery مقرون‌به‌صرفه نباشد و از Presto برای دسترسی مستقیم به مجموعه‌های داده در GCS استفاده کردیم. برای انجام این کار، ما به منابع داده خارجی BigQuery نگاه می کنیم.

مراحل بعدی

از زمان انتشار آلفا، ما شاهد علاقه زیادی به BigQuery بوده ایم. ما مجموعه داده ها و دستورات بیشتری را به BigQuery اضافه می کنیم. ما برای ابزارهای تجزیه و تحلیل داده‌ها مانند Scalding برای خواندن و نوشتن در فضای ذخیره‌سازی BigQuery رابط‌هایی ایجاد می‌کنیم. ما به دنبال ابزارهایی مانند Looker و Apache Zeppelin برای ایجاد گزارش‌ها و یادداشت‌های کیفیت سازمانی با استفاده از مجموعه داده‌های BigQuery هستیم.

همکاری ما با Google بسیار سازنده بوده است و ما از ادامه و توسعه این همکاری خرسندیم. ما با گوگل کار کردیم تا خودمان را پیاده سازی کنیم ردیاب مشکلات شریکبرای ارسال درخواست ها به طور مستقیم به Google. برخی از آنها مانند بارگذار پارکت BigQuery قبلا توسط گوگل پیاده سازی شده است.

در اینجا برخی از درخواست‌های ویژگی با اولویت بالا برای Google آورده شده است:

• ابزارهایی برای دریافت راحت داده ها و پشتیبانی از قالب LZO-Thrift.
• تقسیم بندی ساعتی
• بهبودهای کنترل دسترسی مانند مجوزهای سطح جدول، ردیف و ستون.
• BigQuery منابع داده های خارجی با ادغام Hive Metastore و پشتیبانی از فرمت LZO-Thrift.
• ادغام کاتالوگ داده ها در رابط کاربری BigQuery بهبود یافته است
• سلف سرویس برای تخصیص و نظارت بر اسلات.

نتیجه

دموکراتیک کردن تجزیه و تحلیل داده، تجسم، و یادگیری ماشینی به روشی امن، اولویت اصلی تیم پلتفرم داده است. ما Google BigQuery و Data Studio را به عنوان ابزارهایی که می توانند به دستیابی به این هدف کمک کنند، شناسایی کردیم و BigQuery Alpha را در سال گذشته در سراسر شرکت منتشر کردیم.

ما پرس و جوها را در BigQuery ساده و کارآمد یافتیم. ما از ابزارهای گوگل برای جذب و تبدیل داده ها برای خطوط لوله ساده استفاده کردیم، اما برای خطوط لوله پیچیده باید چارچوب Airflow خودمان را می ساختیم. در فضای مدیریت داده، خدمات BigQuery برای احراز هویت، مجوز و ممیزی نیازهای ما را برآورده می کند. برای مدیریت ابرداده ها و حفظ حریم خصوصی، به انعطاف بیشتری نیاز داشتیم و مجبور بودیم سیستم های خود را بسازیم. BigQuery، به عنوان یک سرویس مدیریت شده، برای استفاده آسان بود. هزینه های پرس و جو مشابه ابزارهای موجود بود. ذخیره داده ها در BigQuery علاوه بر هزینه های GCS هزینه هایی را نیز به همراه دارد.

به طور کلی، BigQuery برای تجزیه و تحلیل عمومی SQL به خوبی کار می کند. ما شاهد علاقه زیادی به BigQuery هستیم و در تلاشیم تا مجموعه داده های بیشتری را منتقل کنیم، تیم های بیشتری را جذب کنیم و خطوط لوله بیشتری را با BigQuery ایجاد کنیم. توییتر از داده های مختلفی استفاده می کند که به ترکیبی از ابزارهایی مانند Scalding، Spark، Presto و Druid نیاز دارد. ما قصد داریم به تقویت ابزارهای تجزیه و تحلیل داده های خود ادامه دهیم و راهنمایی های روشنی را برای کاربران خود در مورد نحوه بهترین استفاده از پیشنهادات خود ارائه دهیم.

سخنان سپاسگزاری

می‌خواهم از نویسندگان و هم تیمی‌هایم، Anju Jha و Will Pascucci، برای همکاری عالی و کار سختشان در این پروژه تشکر کنم. همچنین می‌خواهم از مهندسان و مدیران چندین تیم در توییتر و گوگل که به ما کمک کردند و از کاربران BigQuery در توییتر که بازخورد ارزشمندی ارائه کردند تشکر کنم.

اگر علاقه مند به کار بر روی این مشکلات هستید، ما را بررسی کنید جای خالی در تیم Data Platform.

کیفیت داده در DWH - ثبات انبار داده

منبع: www.habr.com