مرحبًا حبر! التسجيل في دورة تدريبية جديدة مفتوح الآن في OTUS . تحسبًا لبدء الدورة، قمنا تقليديًا بإعداد ترجمة للمواد المثيرة للاهتمام لك.
كل يوم، يزور تويتر أكثر من مائة مليون شخص لمعرفة ما يحدث في العالم ومناقشته. تؤدي كل تغريدة وكل إجراء آخر يقوم به المستخدم إلى إنشاء حدث متاح لتحليل البيانات الداخلية لتويتر. يقوم مئات الموظفين بتحليل هذه البيانات وتصورها، ويعد تحسين تجربتهم أولوية قصوى لفريق Twitter Data Platform.
نحن نؤمن بأن المستخدمين الذين يتمتعون بمجموعة واسعة من المهارات التقنية يجب أن يكونوا قادرين على اكتشاف البيانات والوصول إلى أدوات التحليل والتصور عالية الأداء المستندة إلى SQL. وهذا من شأنه أن يسمح لمجموعة جديدة كاملة من المستخدمين الأقل تقنية، بما في ذلك محللي البيانات ومديري المنتجات، باستخلاص الرؤى من البيانات، مما يسمح لهم بفهم قدرات تويتر واستخدامها بشكل أفضل. هذه هي الطريقة التي نقوم بها بإضفاء الطابع الديمقراطي على تحليلات البيانات على تويتر.
ومع تحسن أدواتنا وقدراتنا على تحليل البيانات الداخلية، فقد شهدنا تحسنًا في تويتر. ومع ذلك، لا يزال هناك مجال للتحسين. الأدوات الحالية مثل Scalding تتطلب خبرة في البرمجة. تواجه أدوات التحليل المستندة إلى SQL، مثل Presto وVertica، مشكلات في الأداء على نطاق واسع. لدينا أيضًا مشكلة توزيع البيانات عبر أنظمة متعددة دون الوصول المستمر إليها.
أعلنا العام الماضي ، والتي ننقل من خلالها أجزاء من أعمالنا على Google Cloud Platform (GCP). لقد خلصنا إلى أن أدوات Google Cloud يمكن أن يساعدنا في مبادراتنا لإضفاء الطابع الديمقراطي على التحليلات والتصورات والتعلم الآلي على تويتر:
- : مستودع بيانات المؤسسة مع محرك SQL والتي تشتهر بالسرعة والبساطة والتأقلم معها .
- أداة تصور البيانات الضخمة مع ميزات التعاون المشابهة لمحرّر مستندات Google.
في هذه المقالة، ستتعرف على تجربتنا مع هذه الأدوات: ما قمنا به، وما تعلمناه وما سنفعله بعد ذلك. سنركز الآن على التحليلات المجمعة والتفاعلية. سنناقش التحليلات في الوقت الحقيقي في المقالة التالية.
تاريخ مخازن بيانات تويتر
قبل الغوص في BigQuery، من المفيد أن نروي بإيجاز تاريخ تخزين بيانات تويتر. في عام 2011، تم إجراء تحليل بيانات تويتر في Vertica وHadoop. استخدمنا Pig لإنشاء وظائف MapReduce Hadoop. في عام 2012، استبدلنا Pig بـ Scalding، الذي كان يحتوي على Scala API مع فوائد مثل القدرة على إنشاء خطوط أنابيب معقدة وسهولة الاختبار. ومع ذلك، بالنسبة للعديد من محللي البيانات ومديري المنتجات الذين كانوا أكثر راحة في العمل مع SQL، كان منحنى التعلم حادًا إلى حد ما. في عام 2016 تقريبًا، بدأنا في استخدام Presto كواجهة SQL لبيانات Hadoop. قدمت Spark واجهة Python، مما يجعلها خيارًا جيدًا لعلوم البيانات المخصصة والتعلم الآلي.
منذ عام 2018، استخدمنا الأدوات التالية لتحليل البيانات وتصورها:
- السمط لناقلات الإنتاج
- Scalding وSpark لتحليل البيانات المخصصة والتعلم الآلي
- Vertica وPresto لتحليل SQL المخصص والتفاعلي
- Druid للوصول التفاعلي والاستكشافي والكمون المنخفض إلى مقاييس السلاسل الزمنية
- Tableau وZeppelin وPivot لتصور البيانات
لقد وجدنا أنه على الرغم من أن هذه الأدوات توفر إمكانات قوية للغاية، إلا أننا واجهنا صعوبة في إتاحة هذه الإمكانات لجمهور أوسع على تويتر. ومن خلال توسيع منصتنا باستخدام Google Cloud، فإننا نركز على تبسيط أدوات التحليل لدينا لجميع تويتر.
مستودع بيانات BigQuery من Google
قامت العديد من الفرق في Twitter بالفعل بدمج BigQuery في بعض خطوط الإنتاج الخاصة بهم. وباستخدام خبراتهم، بدأنا في تقييم إمكانات BigQuery لجميع حالات استخدام تويتر. كان هدفنا هو تقديم BigQuery للشركة بأكملها وتوحيدها ودعمها ضمن مجموعة أدوات Data Platform. وكان هذا صعبا لأسباب عديدة. كنا بحاجة إلى تطوير بنية تحتية لاستيعاب كميات كبيرة من البيانات بشكل موثوق، ودعم إدارة البيانات على مستوى الشركة، وضمان ضوابط الوصول المناسبة، وضمان خصوصية العملاء. كان علينا أيضًا إنشاء أنظمة لتخصيص الموارد والمراقبة ورد المبالغ المدفوعة حتى تتمكن الفرق من استخدام BigQuery بفعالية.
في تشرين الثاني (نوفمبر) 2018، أطلقنا إصدار ألفا على مستوى الشركة من BigQuery وData Studio. لقد قدمنا لموظفي تويتر بعضًا من جداول البيانات الأكثر استخدامًا لدينا والتي تحتوي على البيانات الشخصية التي تم تنظيفها. تم استخدام BigQuery من قبل أكثر من 250 مستخدمًا من مجموعة متنوعة من الفرق بما في ذلك الهندسة والتمويل والتسويق. في الآونة الأخيرة، كانوا يقومون بتشغيل حوالي 8 آلاف طلب، ومعالجة حوالي 100 بيتابايت شهريًا، دون احتساب الطلبات المجدولة. بعد تلقي تعليقات إيجابية للغاية، قررنا المضي قدمًا وتقديم BigQuery كمورد أساسي للتفاعل مع البيانات على Twitter.
فيما يلي رسم تخطيطي عالي المستوى لبنية مستودع بيانات Google BigQuery.
نقوم بنسخ البيانات من مجموعات Hadoop المحلية إلى Google Cloud Storage (GCS) باستخدام أداة Cloud Replicator الداخلية. نستخدم بعد ذلك Apache Airflow لإنشاء خطوط أنابيب تستخدم "» لتحميل البيانات من GCS إلى BigQuery. نحن نستخدم Presto للاستعلام عن مجموعات بيانات Parquet أو Thrift-LZO في GCS. BQ Blaster عبارة عن أداة Scalding داخلية لتحميل مجموعات بيانات HDFS Vertica وThrift-LZO إلى BigQuery.
في الأقسام التالية، نناقش نهجنا وخبرتنا في مجالات سهولة الاستخدام والأداء وإدارة البيانات وسلامة النظام والتكلفة.
سهولة الاستخدام
لقد وجدنا أنه كان من السهل على المستخدمين البدء في استخدام BigQuery لأنه لا يتطلب تثبيت البرنامج ويمكن للمستخدمين الوصول إليه من خلال واجهة ويب بديهية. ومع ذلك، يحتاج المستخدمون إلى التعرف على بعض ميزات ومفاهيم Google Cloud Platform، بما في ذلك الموارد مثل المشاريع ومجموعات البيانات والجداول. لقد قمنا بتطوير مواد تعليمية وبرامج تعليمية لمساعدة المستخدمين على البدء. ومن خلال الفهم الأساسي المكتسب، وجد المستخدمون أنه من السهل التنقل بين مجموعات البيانات وعرض بيانات المخطط والجدول وتشغيل الاستعلامات البسيطة وتصور النتائج في Data Studio.
كان هدفنا من إدخال البيانات في BigQuery هو تمكين التحميل السلس لمجموعات بيانات HDFS أو GCS بنقرة واحدة. اعتبرنا (تتم إدارته بواسطة Airflow) ولكن لم نتمكن من استخدامه بسبب نموذج الأمان الخاص بالمشاركة المقيدة للنطاق (المزيد حول هذا الأمر في قسم إدارة البيانات أدناه). لقد جربنا استخدام خدمة نقل البيانات من Google (DTS) لتنظيم أعباء عمل BigQuery. على الرغم من سرعة إعداد DTS، إلا أنها لم تكن مرنة لبناء خطوط الأنابيب ذات التبعيات. بالنسبة لإصدار ألفا الخاص بنا، قمنا ببناء إطار عمل Apache Airflow الخاص بنا في GCE وقمنا بإعداده للتشغيل في الإنتاج والقدرة على دعم المزيد من مصادر البيانات مثل Vertica.
لتحويل البيانات إلى BigQuery، يقوم المستخدمون بإنشاء مسارات بيانات SQL بسيطة باستخدام الاستعلامات المجدولة. بالنسبة لخطوط الأنابيب المعقدة متعددة المراحل ذات التبعيات، نخطط لاستخدام إما إطار عمل Airflow الخاص بنا أو Cloud Composer جنبًا إلى جنب مع .
أداء
تم تصميم BigQuery لاستعلامات SQL للأغراض العامة التي تعالج كميات كبيرة من البيانات. إنه غير مخصص لزمن الاستجابة المنخفض، أو استعلامات الإنتاجية العالية التي تتطلبها قاعدة بيانات المعاملات، أو لتحليل السلاسل الزمنية ذات زمن الاستجابة المنخفض الذي تم تنفيذه . بالنسبة لاستفسارات التحليلات التفاعلية، يتوقع مستخدمونا أوقات استجابة أقل من دقيقة واحدة. كان علينا تصميم استخدامنا لـ BigQuery لتلبية هذه التوقعات. لتوفير أداء يمكن التنبؤ به لمستخدمينا، قمنا بالاستفادة من وظيفة BigQuery، المتاحة للعملاء على أساس رسوم ثابتة تسمح لأصحاب المشاريع بحجز الحد الأدنى من الفترات لاستفساراتهم. BigQuery هي وحدة من قوة الحوسبة المطلوبة لتنفيذ استعلامات SQL.
لقد قمنا بتحليل أكثر من 800 استعلام يعالج كل منها حوالي 1 تيرابايت من البيانات ووجدنا أن متوسط وقت التنفيذ كان 30 ثانية. لقد تعلمنا أيضًا أن الأداء يعتمد بشكل كبير على استخدام الفتحة الخاصة بنا في المشاريع والمهام المختلفة. كان علينا أن نحدد بوضوح إنتاجنا واحتياطياتنا المخصصة للحفاظ على الأداء لحالات استخدام الإنتاج والتحليل عبر الإنترنت. وقد أثر هذا بشكل كبير على تصميمنا لحجوزات الفتحات والتسلسل الهرمي للمشروع.
سنتحدث عن إدارة البيانات ووظائفها وتكلفة الأنظمة في الأيام القادمة في الجزء الثاني من الترجمة، ولكن الآن ندعو الجميع إلى ، حيث يمكنك معرفة المزيد عن الدورة التدريبية، بالإضافة إلى طرح الأسئلة على خبيرنا - إيجور ماتيشوك (كبير مهندسي البيانات، MaximaTelecom).
اقرأ أكثر:
المصدر: www.habr.com