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