در محل به لطف نسخه‌سازی مبتنی بر مهر زمانی، تلاش دو هفته‌ای به یک تماس API کاهش یافته است.

از اینکه در مورد سفر ما به یک ذخیره‌سازی انتزاعی و با ارزش کلیدی در Pinterest مطالعه کردید متشکریم. می‌خواهم از همه افرادی که در این پروژه مهم و چالش‌برانگیز مشارکت داشتند قدردانی کنم: راجات پراساد، کانگنان لی، ایندی پرنتیس، هارولد کابالیک، مادلین نگوین، جیا ژان، نیل انریکز، رامش کالوری، تیم جونز، گوپال راجپوروهیت، گوئودونگ Han، Prem Thangamani، Lianghong Xu، Alberto Ordonez Pereira، Kevin Lin، همه شرکای ما در SRE، امنیت، و بهره‌وری Eng، و همه مشتریان مهندسی ما در Pinterest که تیم‌هایی از تبلیغات تا homefeed، یادگیری ماشین تا پلتفرم سیگنال را در بر می‌گیرند. هیچ یک از اینها بدون کار تیمی و همکاری همه در اینجا امکان پذیر نخواهد بود.

اگر شما یا هرکسی که می شناسید به مشکلات سیستم های توزیع شده در مقیاس سیاره مانند این علاقه دارید و می خواهید با یک تیم شگفت انگیز کار کنید، فرصت های شغلی برای تیم Key Value Systems را ببینید!

برای کسب اطلاعات بیشتر در مورد مهندسی در Pinterest، بقیه وبلاگ مهندسی ما را بررسی کنید و از سایت Pinterest Labs ما دیدن کنید. برای مشاهده و درخواست فرصت‌های باز، از صفحه مشاغل ما دیدن کنید.

رفع اشکال تحویل آگهی در پینترست

نیشانت روی | مدیر مهندسی، پلت فرم ارائه تبلیغات

صفحه نمایش تلفن با بینش برداشت ها، کل مخاطبان، تعامل و مخاطبان درگیر: https://unsplash.com/photos/hOGKh5qHNAE

مقدمه و پس زمینه

پلت فرم ارائه تبلیغات Pinterest بیش از 2.5 میلیارد دلار هزینه تبلیغات در سال 2021 از هزاران تبلیغ کننده ارائه کرد. تیم عملیات مشتری ما به طور میانگین هر ماه بیش از 600 بلیت از تبلیغ‌کنندگانی دریافت می‌کند که به دنبال درک عملکرد آنها در پلتفرم ما هستند. انجام پروژه انجام پروژه متلب متلب یکی از رایج ترین سوالاتی که دریافت می کنیم این است که چرا یک تبلیغ کننده/کمپین تبلیغاتی خاص به طور کامل از بودجه خود استفاده نمی کند. این سوال به تجزیه و تحلیل عمیق یک سیستم توصیه تبلیغاتی متشکل از 5+ میکروسرویس، 1 میلیون خط کد و بیش از 100 توسعه دهنده فعال نیاز دارد که روزانه بیش از 90 میلیون درخواست را ارائه می دهد. این وبلاگ توضیح می‌دهد که چگونه سیستمی برای پاسخگویی سریع به این سؤالات بدون نیاز به تخصص یا زمینه فنی عمیق ایجاد کردیم. ما سه هدف اصلی داشتیم:

    با کاهش زمان صرف شده برای حل مشکلات آنها، رضایت تبلیغ کنندگان را بهبود بخشید

    تجزیه و تحلیل داده ها را به صورت خودکار انجام دهید و توصیه هایی برای تبلیغ کننده برای بهبود نرخ تحویل ایجاد کنید

    پوشش تمامی اجزای سیستم (نمایه گذاری، بودجه بندی/سرعت گذاری، تولید نامزد، رتبه بندی، قیف تبلیغات، حراج و غیره)

طراحی/چالش ها

پوشش داده ها

اکثر داده‌های موجود برای اشکال‌زدایی در سطح درخواست بودند و به‌شدت برای کاهش هزینه‌ها نمونه‌گیری شدند، که به این معنی بود که ما داده‌های کافی برای درک رفتار سیستم برای همه تبلیغ‌کنندگان نداریم. ما به پوشش گسترده ای برای همه تبلیغ کنندگان نیاز داشتیم، با شمارش در تمام مراحل سیستم توصیه تبلیغات، بدون متحمل شدن هزینه های هنگفت ثبت و ذخیره سازی.

راه حل: خط لوله داده جمع آوری شده در Druid

پس از تحقیق در مورد گزینه های خود، به دلایل زیر استفاده از Druid را به عنوان راه حل ذخیره سازی خود انتخاب کردیم:

    نرخ بالای جذب در زمان واقعی از طریق کافکا: هر درخواست تبلیغات ممکن است شامل هزاران نامزد باشد، و ما باید داده‌های همه این شناسه‌ها را ثبت کنیم. ما قبلاً به طور گسترده از کافکا برای ورود به سیستم استفاده می کردیم، بنابراین توانستیم بسیاری از زیرساخت های خود را با Druid دوباره استفاده کنیم. با استفاده از کافکا با Druid، خط لوله ما داده ها را به صورت بلادرنگ برای اشکال زدایی با حداکثر چند دقیقه تاخیر در دسترس قرار می دهد.

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

    تأخیر کم و هزینه ذخیره سازی: Druid به ما امکان می دهد تا در زمان واقعی تعداد دفعات شناسه را مشاهده کنیم. همچنین، Druid از تجمع در زمان مصرف پشتیبانی می کند، که اندازه داده های ذخیره شده را به حداقل می رساند.

در اینجا نمونه ای از طرح ورود به سیستم و یک پاسخ Druid آمده است:

طرحواره گزارش (نمونه) { TimestampMs CampaignID AdvertiserID TrimmedStage … } Druid Response (نمونه) // برای CampaignID = 1234 { تعداد کل: 500000، // تعداد کل موارد ثبت شده در محدوده زمانی idCounts: 20000 تعداد کل / با تعداد کل / این CampaignID در محدوده زمانی نتایج: [ { “stage”: “ad_relevance_stage”, “TrimmedCount”: 1500, }, { “stage”: “ad_budget_checker_stage”, “TrimmedCount” : 550, },… ] }

با این داده ها، اکنون می توانیم به سوالاتی مانند:

    یک کمپین بیشتر در چه مرحله ای از بین می رود؟

    میانگین نرخ برش برای هر مرحله چقدر است؟

    نرخ برش یا نرخ درج کمپین در طول روز چگونه تغییر کرده است؟

با پاسخ دادن به این سؤالات، می‌توانیم به سرعت بفهمیم که آیا ارائه ضعیف تبلیغات ناشی از یک اشکال در سیستم است (به عنوان مثال، تغییر کد به یک مرحله خاص) یا پیکربندی بد کمپین (به عنوان مثال، پیشنهاد قیمت یا بودجه بسیار کم).

میکروسرویس ها

سیستم تحویل آگهی ما از چندین سیستم مختلف تشکیل شده است که هر کدام وظایف خاص خود را دارند (تولید نامزد، اصلاح، امتیازدهی، مدیریت پیشنهاد/بودجه، نمایه سازی، فیلتر ایمنی محتوا و غیره). دلیل اصلی عملکرد ضعیف کمپین ممکن است در هر یک از این سیستم‌ها باشد که متعلق به چندین تیم مختلف در Pinterest است و تریاژ و حل مشکلات تحویل را به چالش می‌کشد.

راه حل: UI واحد اشکال زدایی

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

    کدام مراحل بالاترین نرخ تریم را داشتند؟

    آیا فیلترینگ بیش از حد محتوا وجود داشت؟

    آیا کمپین در شاخص فعال نبود؟

    آیا تغییراتی در بودجه ایجاد شد؟

    آیا تبلیغ کننده تغییراتی در تنظیمات کمپین خود ایجاد کرده است؟

اسکرین شات از UI Debugger Delivery که خلاصه هزینه کمپین و برگه‌ها را برای جزئیات بیشتر در مورد بخش‌های مختلف سیستم تحویل آگهی (بازیابی، بودجه‌بندی و غیره) نشان می‌دهد.

شکل 1: رابط کاربری یکپارچه اشکال زدایی با برگه ها برای هر سیستم در فرآیند تحویل تبلیغات

نمودار نمونه ای که تعداد کمپین معین را در هر مرحله از قیف تبلیغاتی نشان می دهد

شکل 2: تعداد بریده شده توسط گوزن

ویرایش به تصویر قبلی که چندین سیستم را برای انتخاب نشان می داد.

شکل 2: حالت ایده آل یک رابط کلیدی-مقدار واحد است که پیچیدگی را هم برای مشتریان و هم برای صاحبان پلت فرم کاهش می دهد. وقتی بتوانیم منابع خود را به عنوان یک شرکت تجمیع کنیم و در یک پلتفرم واحد سرمایه گذاری کنیم، می توانیم سریعتر حرکت کنیم و بهتر بسازیم.

انتقال از چهار سیستم به سیستم ایده آل بالا به دو مرحله تقسیم شد: مرحله اول، هدف قرار دادن داده های فقط خواندنی، و دوم، هدف قرار دادن داده های خواندن-نوشتن.  طراحی لوگو طراحان لوگو هر مرحله نیازمند استراتژی مهاجرت منحصر به فرد خود بود تا کمترین اختلال را برای مشتریان ایجاد کند.

فاز 1: انتقال داده فقط خواندنی (کاملاً بدون درز)

مرحله فقط خواندنی ابتدا به این دلیل بود که ساده‌تر بود (اطلاعات غیرقابل تغییر آسان‌تر از دریافت نوشته‌های زنده داده‌های قابل تغییر است) و به این دلیل که اکثر مشتریان را هدف قرار می‌داد (حدود 70 درصد از Terrapin استفاده می‌کردند). از آنجایی که Terrapin بسیار پرکار بود و در پایگاه کد ما مستقر بود، اگر همه API های خود را برای دسترسی به KVStore مهاجرت کنند، زمان و تلاش زیادی را با ارزش افزایشی بسیار کمی می طلبید.

ما تصمیم گرفتیم در عوض اکثر مشتریان Terrapin را به طور یکپارچه مهاجرت کنیم: برای کاربرانی که با Terrapin API تماس می‌گیرند هیچ تغییری لازم نیست، اما بدون اطلاع تماس‌گیرندگان، سرویس Terrapin API با یک کتابخانه KVStore API تعبیه‌شده برای بازیابی داده‌ها از Rockstore افزوده شد. و از آنجایی که Terrapin یک سیستم بارگذاری دسته‌ای است، ما همچنین یک کلاس پایه مرکزی پیدا کردیم و گردش‌های کاری را تغییر مسیر دادیم تا داده‌ها را به جای Terrapin در Rockstore دوبار بارگذاری کنیم (و سپس در نهایت Terrapin را قطع کردیم).

نموداری که زیربخشی از نمودار قبلی را نشان می‌دهد که چهار سیستم ارزش کلیدی را نشان می‌دهد. در این نمودار، روی مشتریانی که با Rockstore و Terrapin API تماس می‌گیرند بزرگنمایی می‌کنیم و نشان می‌دهیم که با معرفی لایه‌ای بین Terrapin API و Terrapin leaf Storage که مشتریان را هدایت می‌کند تا به جای ذخیره برگ Rockstore تماس بگیرند، می‌توانیم بدون نیاز به مشتریان به انتقال داده دست یابیم. هر اقدامی

شکل 3: با معرفی یک لایه مسیریابی بین APIهای Terrapin و ذخیره‌سازی برگ Terrapin، می‌توانیم به انتقال داده دست یابیم و سیستم ذخیره‌سازی پرهزینه و کم‌پایدار Terrapin را برای تأثیر فوری کسب‌وکار حذف کنیم، بدون اینکه از مشتریان بخواهیم اقدامی انجام دهند. مبادله در اینجا بدهی فناوری و لایه غیرمستقیم است: ما اکنون از مشتریان می‌خواهیم که استفاده خود از Terrapin API را پاک کنند تا مستقیماً KVStore API را فراخوانی کنند.

از آنجایی که Rockstore نسبت به Terrapin عملکرد و مقرون به صرفه‌تر بود، کاربران شاهد کاهش 30 تا 90 درصدی تاخیر بودند. هنگامی که زیرساخت ذخیره سازی Terrapin را از کار انداختیم، شرکت همچنین شاهد صرفه جویی سالانه 7 میلیون دلاری بود، همه بدون نیاز کاربران به برداشتن انگشت (به استثنای چند مورد). معاوضه این است که ما اکنون مقداری بدهی فنی داریم تا اطمینان حاصل کنیم که کاربران با حذف APIهای Terrapin منسوخ شده و روی KVStore API کد خود را پاک می کنند تا دیگر لایه ای غیرمستقیم نداشته باشیم.

فاز 2: انتقال داده خواندن و نوشتن (تا حدی بدون درز)

سمت خواندن و نوشتن تصویر متفاوتی ارائه کرد: کمتر از 200 مورد استفاده برای مقابله وجود داشت، و تعداد سایت‌های تماس کمتر افراطی بود، اما ایجاد برابری ویژگی‌ها برای یک سیستم خواندن-نوشتن در مقابل فقط خواندن شامل توسعه‌های جدی بود. . Rockstore برای اینکه بتواند با UserMetaStore (در اصل HBase) همتراز باشد، به یک قالب جدید با ستون گسترده، حالت‌های سازگاری بیشتر، پشتیبانی از عکس فوری آفلاین و تضمین‌های دوام بالاتر نیاز داشت.

در حالی که تیم برای توسعه این ویژگی‌ها وقت گذاشت، ما تصمیم گرفتیم "گلوله را گاز بگیریم" و از همه کاربران بخواهیم از همان ابتدا از UserMetaStore's API به KVStore API مهاجرت کنند. مزیت انجام این کار این است که یک حرکت کم خطر و کم تلاش است. به لطف قدرت انتزاع، ما یک پروکسی معکوس را پیاده سازی کردیم به طوری که مشتریانی که به KVStore API حرکت می کنند در واقع هنوز UserMetaStore زیر سرپوش را فراخوانی می کنند. ( طراحی سایت سفارش طراحی سایت ) با ایجاد این تغییر کوچک در حال حاضر، مشتریان قراردادی ماندگار می‌خریدند که برای آینده قابل پیش‌بینی مجدداً به چنین تغییراتی نیاز نخواهد داشت.

نموداری که Rockstore و UserMetastore را در کنار یکدیگر نشان می‌دهد که هر دو توسط لایه KVStore API در بالا انتزاع شده‌اند. به مشتریان نشان داده می‌شود که از تماس مستقیم UMS API به تماس با KVStore API، که می‌تواند درخواست‌ها را به UMS و Rockstore پراکسی کند، حرکت می‌کند و امکان مهاجرت زیر سر خود را فراهم می‌کند.

شکل 4: به جای اتخاذ همان رویکردی که با Terrapin در شکل 3 انجام دادیم، تصمیم گرفتیم که از مشتریان بخواهیم API های خود را از قبل منتقل کنند، برای یکسان سازی سیستم های ذخیره سازی خواندن-نوشتن منطقی تر است. هنگامی که مشتریان به لایه انتزاعی KVStore API ما رفتند، ما آزاد بودیم که داده‌های آنها را از UserMetaStore به Rockstore منتقل کنیم.

برخی از بزرگترین چالش ها در واقع فنی نبودند. یافتن صاحبان داده‌ها یک تمرین باستان‌شناسی بود و به دلیل اولویت‌های رقابتی، پاسخگویی صدها مالک برای تکمیل بخشی از آنها دشوار بود. انجام پروژه انجام پروژه متلب اما وقتی این کار انجام شد و زمانی که پلتفرم راک استور آماده شد، تیم به طور کامل از حالت انسداد خارج شد تا بدون دخالت مشتری، داده ها را از UserMetaStore به Rockstore پر کند. ما هم نذر کردیم

جسیکا چان | مدیر مهندسی، MySQL و ذخیره‌سازی کلید ارزش

مهندسان از مهاجرت متنفرند. مهندسان از چه چیزی بیشتر از مهاجرت متنفرند؟ انتقال داده ها به خصوص انتقال خدمات آنلاین حیاتی، در مقیاس ترابایت، که اگر بد انجام شود، می تواند سایت را خراب کند، مشتریان را خشمگین کند، یا صدها سرویس داخلی حیاتی را فلج کند.

پس چرا تیم سیستم‌های ارزش کلیدی در پینترست انتقال دو ساله بی‌درنگ تمام داده‌های ارائه‌دهنده کلید-مقدار آنلاین ما به یک سیستم ذخیره‌سازی واحد را آغاز کرد؟ چون هزینه مهاجرت نکردن خیلی زیاد بود. در سال 2019، Pinterest چهار سیستم ارزش کلیدی جداگانه داشت که متعلق به تیم های مختلف با API ها و ویژگی های مختلف بود.( انجام پروژه متلب انجام پروژه های متلب ) این منجر به تلاش‌های توسعه‌ای تکراری، تعداد بالای سربار عملیاتی و تعداد حوادث و سردرگمی در بین مشتریان مهندسی شد.

در یکپارچه سازی تمام موارد استفاده از بیش از 500 مورد ارزش کلیدی Pinterest (بیش از 4PB داده منحصر به فرد با 100Ms QPS) در یک رابط واحد، نه تنها دستاوردهای بزرگی در کاهش پیچیدگی سیستم و کاهش سربار عملیاتی به دست آوردیم، بلکه به 40-90 رسیدیم. درصد بهبود عملکرد با انتقال به کارآمدترین موتور ذخیره‌سازی، و با حرکت به سمت بهینه‌ترین معماری تکرار و نسخه‌سازی، میزان قابل توجهی در هزینه‌های شرکت در سال صرفه‌جویی کردیم.

در این پست وبلاگ، ما سه نوآوری (از میان بسیاری دیگر) را انتخاب کردیم که به ما کمک کرد تا همه این پیروزی ها را بدست آوریم.

اما ابتدا مقداری پیشینه

قبل از این تلاش، پینترست چهار سیستم ذخیره سازی با ارزش کلید داشت:

    Terrapin: ذخیره‌سازی فقط خواندنی، دسته‌ای و با ارزش کلیدی که در Pinterest ساخته شده و در طراحی برنامه‌های فشرده داده مبتنی بر HDFS ارائه شده است.

    Rockstore: یک ذخیره‌سازی با ارزش کلید چند حالته (فقط خواندن، خواندن، نوشتن، پخش-نوشتن) همچنین در Pinterest ساخته شده است، بر اساس چارچوب متن‌باز Rocksplicator، نوشته شده در C++، و با استفاده از RocksDB به عنوان یک موتور ذخیره‌سازی.

    UserMetaStore: یک ذخیره‌سازی با ارزش کلید خواندن و نوشتن با یک API ساده‌شده در بالای HBase

    Rocksandra: یک ذخیره‌سازی خواندنی-نوشتنی با ارزش کلیدی مبتنی بر نسخه‌ای از Cassandra که از RocksDB در زیر کاپوت استفاده می‌کرد.

یکی از بزرگترین چالش‌ها هنگام ادغام در یک سیستم واحد، ارزیابی امکان‌سنجی دستیابی به برابری ویژگی‌ها در همه سیستم‌ها و ادغام آن ویژگی‌ها به خوبی در یک پلتفرم واحد است. چالش دیگر این است که تعیین کنید در کدام سیستم ادغام کنید، و آیا باید با یک سیستم موجود پیش بروید یا چیزی را که قبلاً در Pinterest وجود ندارد، در نظر بگیرید. و آخرین چالش بی اهمیت این است که رهبری و صدها مهندس را متقاعد کنیم که مهاجرت در وهله اول ایده خوبی است.

قبل از این که دست به چنین تعهد بزرگی بزنیم، مجبور بودیم عقب نشینی کنیم. یک گروه کاری چند ماه را به بررسی نیازها و فناوری‌ها، تجزیه و تحلیل معاوضه‌ها و مزایا، و ارائه یک پیشنهاد نهایی اختصاص داد که در نهایت مورد تأیید قرار گرفت. Rockstore که مقرون به صرفه ترین و کارآمدترین، ساده ترین کارکرد و گسترش بود و کمترین هزینه مهاجرت را ارائه می کرد، به عنوان یک سیستم ذخیره سازی برای کنترل همه آنها انتخاب شد.

ما کل پروژه مهاجرت را در این پست شرح نمی دهیم، اما برخی از بهترین بخش ها را برجسته می کنیم.

نوآوری 1: انتزاعات API به ما این امکان را می دهد که داده های مشتری را به طور یکپارچه منتقل کنیم

ما می دانیم که در کد، انتزاعات قوی به رابط های تمیزتر و انعطاف پذیری بیشتر برای ایجاد تغییرات "زیر سرپوش" بدون اختلال منجر می شود. این امر به ویژه در مورد سازمان ها نیز صادق است. در حالی که هر یک از چهار سیستم ذخیره‌سازی انتزاعات API صرفه‌جویی خود را داشتند، این واقعیت که چهار رابط وجود داشت، طراحی لوگو طراحان لوگو و برخی از آنها، مانند Terrapin، هنوز مشتریان را ملزم می‌کرد تا جزئیات داخلی معماری را بدانند تا از آن استفاده کنند (انتزاع نشتی). زندگی را هم برای مشتریان و هم برای صاحبان پلتفرم سخت کرد.

یک نمودار ممکن است برای نشان دادن پیچیدگی حفظ چهار سیستم ذخیره‌سازی جداگانه و ارزش کلیدی مفید باشد. اگر مشتری بودید کدام را انتخاب می کردید؟

نموداری که 4 مجموعه از مشتریان را نشان می دهد که هر مجموعه API هر یک از 4 سیستم ارزش کلیدی را در Pinterest فراخوانی می کند: Rockstore، Terrapin، UMS و Rocksandra. هر سیستمی در سطح بالایی نشان داده می‌شود که دارای معماری‌های زیربنایی متفاوتی است، که نشان می‌دهد حتی تصمیم‌گیری به‌عنوان مشتری در مورد استفاده از کدام یک پیچیده است.

شکل 1: چهار سیستم ارزش کلیدی مجزا در پینترست، هر کدام دارای API های خاص خود، مجموعه ای از ویژگی های منحصر به فرد و معماری های زیربنایی، و درجات مختلف عملکرد و هزینه

ما یک API جدید را معرفی کردیم که به درستی KVStore API نامیده می‌شود، تا رابط صرفه‌جویی یکپارچه جدیدی باشد که بقیه را جذب کند. هنگامی که همه بر روی یک API یکپارچه هستند که با هدف کلی بودن ساخته شده است، تیم پلتفرم می‌تواند انعطاف‌پذیری برای ایجاد تغییرات، حتی تغییر موتورهای ذخیره‌سازی، بدون دخالت مشتریان داشته باشد. این حالت ایده آل است:

نموداری که مجموعه‌ای از کاربران را نشان می‌دهد که یک KVStore API را فراخوانی می‌کنند، که با یک معماری موتور ذخیره‌سازی Key Value مرتبط است. این مقایسه سادگی نسبی را نشان می دهد