سلام، هابر! ثبت نام برای جریان دوره جدید در حال حاضر در OTUS باز است . در آستانه شروع دوره، به صورت سنتی ترجمه مطالب جالبی را برای شما آماده کرده ایم.
هر روز بیش از صد میلیون نفر از توییتر بازدید می کنند تا بدانند در جهان چه می گذرد و درباره آن بحث کنند. هر توییت و هر اقدام کاربر دیگر رویدادی را ایجاد می کند که برای تجزیه و تحلیل داده های داخلی توییتر در دسترس است. صدها کارمند این داده ها را تجزیه و تحلیل و تجسم می کنند و بهبود تجربه آنها اولویت اصلی تیم پلتفرم داده توییتر است.
ما معتقدیم که کاربران با طیف گسترده ای از مهارت های فنی باید بتوانند داده ها را کشف کنند و به ابزارهای تجزیه و تحلیل و تجسم مبتنی بر SQL دسترسی داشته باشند. این به یک گروه کاملاً جدید از کاربران فنی کمتر، از جمله تحلیلگران داده و مدیران محصول، اجازه می‌دهد تا بینش‌هایی را از داده‌ها استخراج کنند و به آنها اجازه می‌دهد تا توانایی‌های توییتر را بهتر درک کنند و از آن استفاده کنند. این روشی است که ما تجزیه و تحلیل داده ها را در توییتر دموکراتیک می کنیم.
همانطور که ابزارها و قابلیت های تجزیه و تحلیل داده های داخلی ما بهبود یافته است، ما شاهد بهبود توییتر بوده ایم. با این حال، هنوز جای پیشرفت وجود دارد. ابزارهای فعلی مانند Scalding به تجربه برنامه نویسی نیاز دارند. ابزارهای تجزیه و تحلیل مبتنی بر SQL مانند Presto و Vertica دارای مشکلات عملکرد در مقیاس هستند. ما همچنین با مشکل توزیع داده ها در چندین سیستم بدون دسترسی مداوم به آن مواجه هستیم.
پارسال اعلام کردیم ، که در آن بخش هایی از خود را منتقل می کنیم در Google Cloud Platform (GCP). ما به این نتیجه رسیدیم که ابزارهای Google Cloud می تواند در ابتکارات ما برای دموکراسی سازی تجزیه و تحلیل، تجسم و یادگیری ماشینی در توییتر به ما کمک کند:
- : انبار داده سازمانی با موتور SQL ، که به سرعت، سادگی و مقابله با آن مشهور است .
- ابزار تجسم داده های بزرگ با ویژگی های همکاری مشابه Google Docs.
در این مقاله، با تجربه ما در مورد این ابزارها آشنا خواهید شد: کارهایی که انجام دادیم، آنچه یاد گرفتیم و در آینده چه خواهیم کرد. اکنون بر روی تجزیه و تحلیل دسته ای و تعاملی تمرکز خواهیم کرد. در مقاله بعدی به تجزیه و تحلیل بلادرنگ خواهیم پرداخت.
تاریخچه فروشگاه های داده توییتر
قبل از ورود به BigQuery، ارزش آن را دارد که به طور خلاصه تاریخچه انبار داده توییتر را بازگو کنیم. در سال 2011، تجزیه و تحلیل داده های توییتر در Vertica و Hadoop انجام شد. ما از Pig برای ایجاد مشاغل MapReduce Hadoop استفاده کردیم. در سال 2012، Pig را با Scalding جایگزین کردیم که دارای API Scala با مزایایی مانند توانایی ایجاد خطوط لوله پیچیده و سهولت آزمایش بود. با این حال، برای بسیاری از تحلیلگران داده و مدیران محصول که کار با SQL راحت‌تر بودند، منحنی یادگیری نسبتاً شیب‌داری بود. در حدود سال 2016، ما شروع به استفاده از Presto به عنوان یک رابط SQL برای داده های Hadoop کردیم. Spark یک رابط پایتون را ارائه می دهد که آن را به انتخاب خوبی برای علم داده ها و یادگیری ماشین تبدیل می کند.
از سال 2018، ما از ابزارهای زیر برای تجزیه و تحلیل و تجسم داده ها استفاده کرده ایم:
- سوختن برای نوار نقاله های تولید
- Scalding و Spark برای تجزیه و تحلیل داده هاک و یادگیری ماشین
- Vertica و Presto برای تجزیه و تحلیل SQL موقت و تعاملی
- Druid برای دسترسی کم تعاملی، اکتشافی و تاخیر کم به معیارهای سری زمانی
- Tableau، Zeppelin و Pivot برای تجسم داده ها
ما متوجه شدیم که در حالی که این ابزارها قابلیت‌های بسیار قدرتمندی را ارائه می‌دهند، ما در ارائه این قابلیت‌ها برای مخاطبان گسترده‌تر در توییتر با مشکل مواجه بودیم. با گسترش پلت فرم خود با Google Cloud، بر ساده کردن ابزارهای تجزیه و تحلیل خود برای تمام توییتر تمرکز می کنیم.
انبار داده BigQuery گوگل
چندین تیم در توییتر قبلاً BigQuery را در برخی از خطوط لوله تولید خود گنجانده اند. با استفاده از تخصص آنها، ما شروع به ارزیابی قابلیت های BigQuery برای همه موارد استفاده از توییتر کردیم. هدف ما ارائه BigQuery به کل شرکت و استانداردسازی و پشتیبانی آن در مجموعه ابزار Data Platform بود. این به دلایل زیادی دشوار بود. ما نیاز به توسعه زیرساختی برای جذب قابل اعتماد حجم زیادی از داده ها، پشتیبانی از مدیریت داده در سطح شرکت، اطمینان از کنترل های دسترسی مناسب و اطمینان از حفظ حریم خصوصی مشتریان داشتیم. همچنین باید سیستم هایی برای تخصیص منابع، نظارت و بازپرداخت هزینه ایجاد می کردیم تا تیم ها بتوانند به طور موثر از BigQuery استفاده کنند.
در نوامبر 2018، نسخه آلفای BigQuery و Data Studio را در سراسر شرکت منتشر کردیم. ما به کارمندان توییتر برخی از پرکاربردترین صفحات گسترده خود را با داده های شخصی پاک شده ارائه کرده ایم. BigQuery توسط بیش از 250 کاربر از تیم های مختلف از جمله مهندسی، مالی و بازاریابی استفاده شده است. اخیراً، آنها حدود 8 هزار درخواست را اجرا می کردند، حدود 100 PB در ماه پردازش می کردند، بدون احتساب درخواست های برنامه ریزی شده. پس از دریافت بازخورد بسیار مثبت، تصمیم گرفتیم به جلو حرکت کنیم و BigQuery را به عنوان منبع اصلی برای تعامل با داده ها در توییتر ارائه دهیم.
در اینجا یک نمودار سطح بالا از معماری انبار داده Google BigQuery ما آمده است.
با استفاده از ابزار داخلی Cloud Replicator، داده‌ها را از خوشه‌های Hadoop در محل به Google Cloud Storage (GCS) کپی می‌کنیم. سپس از Apache Airflow برای ایجاد خطوط لوله ای استفاده می کنیم که از "» برای بارگیری داده ها از GCS در BigQuery. ما از Presto برای پرس و جو از مجموعه داده های Parquet یا Thrift-LZO در GCS استفاده می کنیم. BQ Blaster یک ابزار Scalding داخلی برای بارگذاری مجموعه داده های HDFS Vertica و Thrift-LZO در BigQuery است.
در بخش‌های بعدی، رویکرد و تخصص خود را در زمینه‌های سهولت استفاده، عملکرد، مدیریت داده، سلامت سیستم و هزینه مورد بحث قرار می‌دهیم.
سهولت استفاده
ما دریافتیم که شروع کار با BigQuery برای کاربران آسان است زیرا نیازی به نصب نرم افزار ندارد و کاربران می توانند از طریق یک رابط وب بصری به آن دسترسی داشته باشند. با این حال، کاربران باید با برخی از ویژگی ها و مفاهیم GCP، از جمله منابعی مانند پروژه ها، مجموعه داده ها و جداول آشنا شوند. ما مواد آموزشی و آموزش هایی را برای کمک به کاربران در شروع کار توسعه داده ایم. با درک اولیه به دست آمده، کاربران پیمایش مجموعه داده‌ها، مشاهده طرحواره و داده‌های جدول، اجرای پرس‌وجوهای ساده و تجسم نتایج در 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 ثانیه بود. ما همچنین آموختیم که عملکرد به شدت به استفاده از اسلات ما در پروژه ها و وظایف مختلف بستگی دارد. ما مجبور بودیم به وضوح ذخایر تولید و اسلات موقت خود را مشخص کنیم تا عملکرد را برای موارد استفاده تولید و تجزیه و تحلیل آنلاین حفظ کنیم. این امر بر طراحی ما برای رزرو اسلات و سلسله مراتب پروژه تأثیر زیادی گذاشت.
ما در مورد مدیریت داده ها، عملکرد و هزینه سیستم ها در روزهای آینده در قسمت دوم ترجمه صحبت خواهیم کرد، اما اکنون از همه دعوت می کنیم تا ، که در طی آن می توانید جزئیات دوره را بیاموزید و همچنین سؤالاتی را از متخصص ما - Egor Mateshuk (مهندس ارشد داده ، MaximaTelecom) بپرسید.
بیشتر بخوانید:
منبع: www.habr.com