مرحبًا حبر! التسجيل في دورة تدريبية جديدة مفتوح الآن في OTUS . وتحسبًا لبدء الدورة، نواصل مشاركة المواد المفيدة معكم.
إدارة البيانات
تعد إدارة البيانات القوية أحد المبادئ الأساسية لهندسة تويتر. أثناء قيامنا بتطبيق BigQuery في نظامنا الأساسي، فإننا نركز على اكتشاف البيانات والتحكم في الوصول والأمان والخصوصية.
لاكتشاف البيانات وإدارتها، قمنا بتوسيع طبقة الوصول إلى البيانات الخاصة بنا إلى ) لتوفير أدوات لكل من البيانات المحلية وبيانات Google Cloud، مما يوفر واجهة واحدة وواجهة برمجة التطبيقات لمستخدمينا. مثل جوجل يتجه نحو التوفر العام، وسوف ندرجه في مشاريعنا لتزويد المستخدمين بميزات مثل البحث في الأعمدة.
يعمل BigQuery على تسهيل مشاركة البيانات والوصول إليها، ولكننا كنا بحاجة إلى بعض التحكم في ذلك لمنع تسرب البيانات. ومن بين الأدوات الأخرى، اخترنا وظيفتين:
- : ميزة تجريبية لمنع المستخدمين من مشاركة مجموعات بيانات BigQuery مع مستخدمين خارج Twitter.
- : عنصر تحكم يمنع تسرب البيانات ويتطلب من المستخدمين الوصول إلى BigQuery من نطاقات عناوين IP المعروفة.
لقد قمنا بتنفيذ متطلبات المصادقة والترخيص والتدقيق (AAA) للأمان على النحو التالي:
- المصادقة: استخدمنا حسابات مستخدمي Google Cloud Platform للطلبات المخصصة وحسابات الخدمة لطلبات الإنتاج.
- التفويض: طلبنا أن يكون لكل مجموعة بيانات حساب خدمة مالك ومجموعة قراء.
- التدقيق: قمنا بتصدير سجلات BigQuery stackdriver، التي تحتوي على معلومات تفصيلية عن تنفيذ الاستعلام، إلى مجموعة بيانات BigQuery لتسهيل التحليل.
لضمان التعامل مع البيانات الشخصية لمستخدمي تويتر بشكل صحيح، يجب علينا تسجيل جميع مجموعات بيانات BigQuery، والتعليق على البيانات الشخصية، والحفاظ على التخزين المناسب، وحذف (كشط) البيانات التي تم حذفها من قبل المستخدمين.
نظرنا إلى جوجل ، والذي يستخدم التعلم الآلي لتصنيف البيانات الحساسة وتحريرها، ولكنه قرر لصالح إضافة تعليقات توضيحية يدويًا إلى مجموعة البيانات نظرًا لدقتها. نحن نخطط لاستخدام واجهة برمجة التطبيقات لمنع فقدان البيانات لزيادة التعليقات التوضيحية المخصصة.
في Twitter، أنشأنا أربع فئات خصوصية لمجموعات البيانات في BigQuery، وهي مدرجة هنا بترتيب تنازلي من حيث الحساسية:
- يتم توفير مجموعات البيانات شديدة الحساسية حسب الحاجة بناءً على مبدأ الامتياز الأقل. تحتوي كل مجموعة بيانات على مجموعة منفصلة من القراء، وسنقوم بتتبع الاستخدام حسب الحسابات الفردية.
- لا تحتوي مجموعات البيانات ذات الحساسية المتوسطة (الأسماء المستعارة ذات الاتجاه الواحد باستخدام التجزئة المملحة) على معلومات تعريف شخصية (PII) ويمكن لمجموعة أكبر من الموظفين الوصول إليها. يعد هذا توازنًا جيدًا بين مخاوف الخصوصية وفائدة البيانات. يتيح ذلك للموظفين تنفيذ مهام التحليل، مثل حساب عدد المستخدمين الذين استخدموا إحدى الميزات، دون معرفة من هم المستخدمون الحقيقيون.
- مجموعات بيانات منخفضة الحساسية تحتوي على جميع معلومات تعريف المستخدم. يعد هذا أسلوبًا جيدًا من منظور الخصوصية، ولكن لا يمكن استخدامه للتحليل على مستوى المستخدم.
- مجموعات البيانات العامة (الصادرة خارج تويتر) متاحة لجميع موظفي تويتر.
أما بالنسبة للتسجيل، فقد استخدمنا المهام المجدولة لتعداد مجموعات بيانات BigQuery وتسجيلها في طبقة الوصول إلى البيانات ()، مستودع البيانات الوصفية لتويتر. سيقوم المستخدمون بتعليق مجموعات البيانات بمعلومات الخصوصية وتحديد فترة الاحتفاظ أيضًا. أما بالنسبة للتنظيف، فنقوم بتقييم الأداء والتكلفة بخيارين: 1. تنظيف مجموعات البيانات في GCS باستخدام أدوات مثل Scalding وتحميلها في BigQuery؛ 2. استخدام عبارات BigQuery DML. من المحتمل أن نستخدم مزيجًا من كلتا الطريقتين لتلبية متطلبات المجموعات والبيانات المختلفة.
وظائف النظام
نظرًا لأن BigQuery عبارة عن خدمة مُدارة، لم تكن هناك حاجة لإشراك فريق SRE التابع لـ Twitter في إدارة الأنظمة أو الواجبات المكتبية. كان من السهل توفير المزيد من السعة لكل من التخزين والحوسبة. يمكننا تغيير حجز الفتحة عن طريق إنشاء تذكرة بدعم Google. لقد حددنا المجالات التي يمكن تحسينها، مثل تخصيص فتحات الخدمة الذاتية وتحسينات لوحة المعلومات للمراقبة، وأرسلنا هذه الطلبات إلى Google.
تكلفة
أظهر تحليلنا الأولي أن تكاليف الاستعلام لـ BigQuery وPresto كانت على نفس المستوى. اشترينا فتحات ل السعر ليكون له تكلفة شهرية مستقرة بدلا من الدفع لكل تيرابايت من البيانات المعالجة. واستند هذا القرار أيضًا إلى تعليقات المستخدمين الذين لم يرغبوا في التفكير في التكاليف قبل تقديم كل طلب.
أدى تخزين البيانات في BigQuery إلى تكاليف بالإضافة إلى تكاليف GCS. تتطلب أدوات مثل Scalding مجموعات بيانات في GCS، وللوصول إلى BigQuery كان علينا تحميل مجموعات البيانات نفسها في تنسيق BigQuery . نحن نعمل على إنشاء اتصال Scalding بمجموعات بيانات BigQuery مما يلغي الحاجة إلى تخزين مجموعات البيانات في كل من GCS وBigQuery.
بالنسبة للحالات النادرة التي تتطلب استعلامات غير متكررة تصل إلى عشرات البيتابايت، قررنا أن تخزين مجموعات البيانات في BigQuery لم يكن فعالاً من حيث التكلفة واستخدمنا Presto للوصول مباشرة إلى مجموعات البيانات في GCS. للقيام بذلك، نحن ننظر إلى مصادر البيانات الخارجية لـ BigQuery.
الخطوات التالية
لقد شهدنا اهتمامًا كبيرًا بـ BigQuery منذ إصدار ألفا. نحن نضيف المزيد من مجموعات البيانات والمزيد من الأوامر إلى BigQuery. نقوم بتطوير موصلات لأدوات تحليل البيانات مثل Scalding للقراءة والكتابة في مساحة تخزين BigQuery. نحن نبحث عن أدوات مثل Looker وApache Zeppelin لإنشاء تقارير وملاحظات جودة المؤسسة باستخدام مجموعات بيانات BigQuery.
لقد كان تعاوننا مع Google مثمرًا للغاية، ويسعدنا مواصلة هذه الشراكة وتطويرها. لقد عملنا مع Google لتنفيذ ما لدينا لإرسال الاستفسارات مباشرة إلى Google. وقد تم بالفعل تنفيذ بعضها، مثل محمل BigQuery Parquet، بواسطة Google.
فيما يلي بعض طلبات الميزات ذات الأولوية العالية التي نقدمها لـ Google:
- أدوات لاستقبال البيانات بسهولة ودعم تنسيق LZO-Thrift.
- تجزئة كل ساعة
- تحسينات التحكم في الوصول مثل الأذونات على مستوى الجدول والصف والعمود.
- الاستعلام الشامل مع تكامل Hive Metastore ودعم تنسيق LZO-Thrift.
- تحسين تكامل كتالوج البيانات في واجهة مستخدم BigQuery
- الخدمة الذاتية لتخصيص الفتحات ومراقبتها.
اختتام
يعد إضفاء الطابع الديمقراطي على تحليلات البيانات والتصور والتعلم الآلي بطريقة آمنة أولوية قصوى لفريق Data Platform. لقد حددنا Google BigQuery وData Studio كأدوات يمكن أن تساعد في تحقيق هذا الهدف، وأصدرنا BigQuery Alpha على مستوى الشركة في العام الماضي.
لقد وجدنا أن الاستعلامات في BigQuery بسيطة وفعالة. لقد استخدمنا أدوات Google لاستيعاب البيانات وتحويلها لخطوط الأنابيب البسيطة، ولكن بالنسبة لخطوط الأنابيب المعقدة، كان علينا إنشاء إطار عمل Airflow الخاص بنا. في مجال إدارة البيانات، تلبي خدمات BigQuery للمصادقة والترخيص والتدقيق احتياجاتنا. لإدارة البيانات الوصفية والحفاظ على الخصوصية، كنا بحاجة إلى المزيد من المرونة وكان علينا بناء أنظمتنا الخاصة. كانت BigQuery، باعتبارها خدمة مُدارة، سهلة الاستخدام. وكانت تكاليف الاستعلام مشابهة للأدوات الموجودة. يؤدي تخزين البيانات في BigQuery إلى تكبد تكاليف بالإضافة إلى تكاليف GCS.
بشكل عام، يعمل BigQuery بشكل جيد لتحليل SQL العام. نحن نشهد اهتمامًا كبيرًا بـ BigQuery، ونحن نعمل على ترحيل المزيد من مجموعات البيانات، وجلب المزيد من الفرق، وإنشاء المزيد من المسارات باستخدام BigQuery. يستخدم تويتر مجموعة متنوعة من البيانات التي تتطلب مجموعة من الأدوات مثل Scalding وSpark وPresto وDruid. نعتزم مواصلة تعزيز أدوات تحليل البيانات لدينا وتقديم إرشادات واضحة لمستخدمينا حول كيفية الاستخدام الأمثل لعروضنا.
كلمات شكر
أود أن أشكر المؤلفين المشاركين وزملائي في الفريق، Anju Jha وWill Pascucci، على تعاونهم الرائع وعملهم الجاد في هذا المشروع. أود أيضًا أن أشكر المهندسين والمديرين من عدة فرق في Twitter وGoogle الذين ساعدونا، كما أشكر مستخدمي BigQuery على Twitter الذين قدموا تعليقات قيمة.
إذا كنت مهتمًا بالعمل على حل هذه المشكلات، فاطلع على موقعنا في فريق منصة البيانات.
المصدر: www.habr.com