مقدمه

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

در عصر حاضر، اتصالات داده می‌توانند ارزش تجاری قابل توجهی ایجاد کنند. برای درک روابط بین کاربران در شبکه‌های اجتماعی آنلاین، روابط بین کاربران و محصولات در تجارت الکترونیک، یا درک روابط اعتباری در شبکه‌های مالی، توانایی درک و تحلیل حجم زیادی از داده‌های با ارتباطات بالا برای کسب‌وکارها به اهمیت افزوده می‌شود.

با افزایش حجم داده‌های مشتری، تیم GrabDefence باید به طور مداوم قابلیت تشخیص تقلب در دستگاه‌های تلفن همراه را برای شناسایی پیشروی حضور کاربران تقلبی یا مخرب ارتقا دهد. حتی تراکنش‌های مالی ساده بین کاربران باید برای چرخه‌های تراکنش و پول‌شویی نظارت شود. برای پیشگیری از شناسایی همچین سناریوهایی، ما به یک پلتفرم خدمات گرافی برای کمک در کشف اتصالات داده نیاز داریم.

زمینه

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

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

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

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

خدمات گراف با پایگاه داده‌های گراف، پلتفرم‌های به عنوان یک سرویس (PaaS) هستند که پیاده‌سازی زیرساخت فناوری گراف را در بر می‌گیرند و به کشف رابطه‌های انجمنی داده با تکنولوژی‌های گراف کمک می‌کنند.

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

همانطور که در شکل 1 نشان داده شده است، سیستم را می‌توان به چهار لایه تقسیم کرد:

چگونگی کار آن

فایل‌های CSV ذخیره شده در Amazon S3 توسط ابزارهای استخراج، تبدیل و بارگذاری (ETL) پردازش می‌شوند تا داده‌های گراف تولید شوند. سپس این داده‌ها توسط یک خوشه پایگاه داده Amazon Neptune مدیریت می‌شوند که تنها از طریق سرویس گراف قابل دسترسی برای کاربران است. سرویس گراف درخواست‌های کاربر را به تعاملات ناهمزمان با خوشه Neptune تبدیل می‌کند که نتایج را به کاربران برمی‌گرداند.

هنگامی که کاربران وظایف بارگذاری داده را راه‌اندازی می‌کنند، سرویس گراف اطلاعات موجودیت و ویژگی را با فایل CSV در S3 و طرح را در DynamoDB همگام می‌کند. اگر هیچ تضادی وجود نداشته باشد، داده‌ها فقط در Neptune وارد می‌شوند.

مورد استفاده در تشخیص تقلب

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

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

ویژگی تزریق داده

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

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

برای کسب اطلاعات بیشتر درباره GrabDefence یا برای صحبت با کارشناسان ما در مدیریت تقلب، با ما تماس بگیرید به آدرس This email address is being protected from spambots. You need JavaScript enabled to view it..

به تیم ما بپیوندید

مجموعه‌ی اپلیکیشن‌های Grabیک پلتفرم سوپراپ برتر در جنوب‌شرق آسیا است که خدمات روزمره ای را که برای مصرف‌کنندگان اهمیت دارند، فراهم می‌کند. بیشتر از یک اپلیکیشن سفر با تاکسی و سرویس تحویل غذا، مجموعه‌ی اپلیکیشن‌های Grab بیشتر از اینها خدمات درخواستی را در منطقه ارائه می‌دهد، از جمله حمل و نقل، غذا، سرویس تحویل بسته و خرید مواد غذایی، پرداخت‌های تلفن همراه و خدمات مالی در ۴۲۸ شهر در هشت کشور.

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

برای دستیابی به هدف خود در تبدیل شدن به سوپر اپ برتر در جنوب شرق آسیا، ما به طور مداوم نیاز به توازن سرعت توسعه با حفظ کیفیت بالای اپ داریم. همانند اکثر شرکت های فناوری، ما با چرخه ایجاد نرم افزار سنتی (SDLC) شروع کردیم اما همانطور که اپ ما تکامل یافت، به زودی چالش هایی مانند باگ های ویژگی بالا و مشکلات تولید متوجه شدیم.

در این مقاله، ما به صورت عمیق تر به سفر بهبود کیفیت خود که در سال 2019 آغاز شد، چالش هایی که در طول راه مواجه شدیم و وضعیتمان در سال 2022 را بررسی می کنیم.

وقتی که مجله زیبایی و درمانی آذر و ت در سال 2012 راه اندازی شد، ما از Agile SDLC (شکل 1) در همه تیم ها و ویژگی ها استفاده می کردیم. این بدان معنا بود که هر ویژگی جدید از طریق تمام فرآیند عبور می کرد و تنها پس از آنکه تیم ضمانت کیفیت (QA) آن را تست کرد و بر آن امضا کرد، در بسترهای توزیع اپ (PlayStore یا AppStore) منتشر می شد.

با گذر زمان، ما متوجه شدیم که تست ویژگی ها طول می کشد، با گزارش بیشتر باگ ها و مناطق تأثیر نیاز به تست داشت. این مورد برای تست ریگرسیون هم صحیح بود زیرا مهندسین QA باید هر ویژگی را در اپ آزمایش کنند قبل از یک نسخه جدید. با وجود تلاش های بیشترین تلاش تیم QA ما، هنوز هم مشکلات تولید عمده و بحرانی زیادی درباره اپ ما گزارش شده است - بیشترین تعداد آنها در سال 2019 (شکل 2) بودند.

این افزایش نسخه ها در مشکلات تولید و باگ های ویژگی مستقیماً روی تجربه کاربران ما در اپ تأثیر می گذارد. برای بطور مستقیم به مشکلات تولید بالا و فرآیند تست کند، ما استراتژی تست خود را تغییر دادیم و تست چپ به راست را به روز کردیم.

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

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

مهندسین نرم افزار تست پذیرش انجام می دهند تعریف گرفتن(DoR) و تعریف کردن(DoD) به استراتژی تست تعادل داده شده تست تعادل داده شده

یکی از جنبه های کلیدی تست چپ به راست این است که تیم ها در مراحل اولیه SDLC بر روی یک استاندارد کیفیت توافق کنند. برای اینکار، ما شروع به وارد کردن تعریف گرفتن (DoR) و تعریف کردن (DoD) در وظایف خود کردیم.

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

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

شامل DoRها و DoDها بهبودهای قابل توجهی در سرعت تحویل و کیفیت ایجاد کرده است. یکی از اولین تیم هایی که این کار را انجام دادند، بهبودهای قابل ملاحظه ای در سرعت تحویل و کیفیت اپ خود مشاهده کردند - همیشه بیش از 90 درصد از تعهدات وظیفه را انجام می دادند، بدهی فنی را حداقل کردند و زمان های تست دستی را کاهش دادند.

استراتژی تست تعادل داده شده

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

تست کامپوننت رابط کاربری

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

تست انتها به انتها (E2E)

تست های E2E مهم هستند زیرا تجربه کاربر را از ابتدا تا انتها شبیه سازی می کنند تا مطمئن شوند سیستم به اندازه انتظار کار می کند. ما از سال 2015 شروع به بررسی چارچوب های تست E2E کردیم تا تست های خودکار برای سرویس های حیاتی مانند ورود و رزرو سفر انجام دهیم.

مقدمه

تیم پلتفرم جریان داده در زمان واقعی Coban، اکوسیستمی را پیرامون Kafka در حوزه های عمودی خدمات مشتری شرکت Grab ایجاد کرده است. به همراه پایداری و عملکرد، یکی از اولویت های ما همچنین کارایی هزینه است.

در این مقاله توضیح می دهیم که تیم Coban چگونه با فعال کردن توانایی مصرف کنندگان Kafka برای بازیافت از نسخه های نزدیکتر، هزینه سالانه Grab را برای جریان داده به طور چشمگیری کاهش داده است.

بیانیه مسئله

پلتفرم مجله زیبایی و درمانی آذروت در حد اصلی بر روی ابر AWS میزبانی می شود و در یک منطقه قرار دارد که سه منطقه قابلیت اطمینان (AZ) را در بر می گیرد. زمانی که به جریان داده می رسد، هر دو کارگزار Kafka و مشتریان Kafka در این سه AZ اجرا می شوند.

شکل 1 نشان می دهد که طراحی اولیه پلتفرم جریان داده ما چگونه است. برای اطمینان از در دسترس بودن بالا و انعطاف پذیری، هر بخش Kafka را برای داشتن سه نسخه یکسان تنظیم کرده ایم. همچنین کلاسترهای Kafka خود را رک-آگاه (یعنی 1 رک = 1 AZ) تنظیم کرده ایم تا سه نسخه در سه AZ متفاوت قرار داشته باشند.

مشکل این طراحی این است که ترافیک شبکه تقاطع AZ شگفت زده ای را ایجاد می کند. این به این دلیل است که به طور پیش فرض، مشتریان Kafka فقط با رهبری بخش ارتباط برقرار می کنند که احتمالاً در AZ متفاوتی قرار دارد.

این یک نگرانی است زیرا ما برای ترافیک تقاطع AZ براساس مدل قیمت گذاری ترافیک شبکه AWS هزینه می پردازیم. با این طرح، ترافیک تقاطع AZ ما نصف هزینه کل پلتفرم Kafka ما را تشکیل می داد.

ترافیک تقاطع AZ Kafka برای این طراحی را می توان به سه بخش تقسیم کرد که در شکل 1 نشان داده شده است:

تولید (مرحله 1): به طور معمول، یک سرویس تکی داده ها را به یک موضوع Kafka داده می کند. ترافیک تقاطع AZ رخ می دهد زمانی که تولید کننده در همان AZ با رهبری بخش که داده ها را تولید می کند مستقر نیست. هزینه ترافیک تقاطع AZ بسیار کم است زیرا داده ها حداکثر یک بار (بدون سعی مجدد) به AZ دیگر منتقل می شوند.تکثیر (مرحله 2): داده های دریافت شده از رهبری بخش به دو پیروند بخش که در دو AZ دیگر مستقر هستند تکثیر می شوند. هزینه این کار نسبتاً کم است زیرا داده ها فقط دو بار به AZ دیگر منتقل می شوند.مصرف (مرحله 3): بیشتر ترافیک تقاطع AZ در اینجا رخ می دهد زیرا برای یک موضوع Kafka تعداد زیادی مصرف کننده وجود دارد. مشابه تولید کنندگان، مصرف کنندگان هزینه ترافیک تقاطع AZ را پرداخت می کنند زمانی که در همان AZ با رهبری بخش مستقر نیستند. با این حال، در سمت مصرف کننده، ترافیک تقاطع AZ ممکن است به تعداد مصرف کنندگان وقوع کند (میانگیناً دو سوم تعداد مصرف کننده ها). راه حلی که در این مقاله توضیح داده شده است، به این جزئیات خاص ترافیک تقاطع AZ در طراحی اولیه پاسخ می دهد.

راه حل

Kafka 2.3 امکان مصرف کنندگان برای بازیافت از نسخه های بخش را معرفی کرده است. این امکان راهی را برای طراحی هزینه مؤثرتر باز می کند.

مرحله 3 شکل 2 نشان می دهد که مصرف کنندگان اکنون می توانند داده ها را از نسخه نزدیک خود مصرف کنند. برای پیاده سازی این ویژگی، نیاز به آگاهی از رک (1 رک = 1 AZ) و پیکربندی های اضافی در کارگزارها و مصرف کنندگان Kafka است. در بخش های زیر این موضوع را توضیح خواهیم داد.

سفر Coban

ارتقای Kafka

سفر ما با ارتقای کلاسترهای قدیمی Kafka آغاز شد. ما تصمیم گرفتیم آنها را به طور مستقیم به نسخه 3.1 ارتقا دهیم ، بهره بردن از رفع اشکالات و بهینه سازی ها نسبت به نسخه 2.3. این حرکت ایمن به عنوان یک حرکت است، زیرا نسخه 3.1 به مدت تقریباً یک سال پایدار تلقی می شد و ما هزینه عملیاتی اضافی برای این ارتقا را پیش بینی نکردیم.

برای انجام یک ارتقای آنلاین بدون اختلال در کاربران خود، فرآیند را به سه مرحله تقسیم کردیم.

مرحله 1: ارتقای Zookeeper. تمام نسخه های Kafka توسط جامعه با یک نسخه خاص از Zookeeper تست می شوند. برای اطمینان از پایداری، ما همین فرآیند را دنبال کردیم. Zookeeper ارتقا یافته به طور سازگاری به عقب با نسخه قبلی Kafka که هنوز در این مرحله از عملیات استفاده می شود.مرحله 2: راه اندازی ارتقای Kafka به نسخه 3.1 با یک نسخه پروتکل بین کارگزارها واضح و سازگار بازگشت (inter.broker.protocol.version). در طول این ارتقا تدریجی، کلاستر Kafka به طور موقت از کارگزارهای با نسخه های متفاوت Kafka تشکیل شده است ، اما می توانند با یکدیگر ارتباط برقرار کنند زیرا به طور صریح تنظیم شده اند تا از همان نسخه پروتکل بین کارگزارها استفاده کنند. در این مرحله، ما همچنین Cruise Control را به یک نسخه سازگار ارتقا دادیم و Kafka را تنظیم کردیم تا پرونده updatedcruise-control-metrics-reporterJAR را در زمان راه اندازی وارد کند.مرحله 3: ارتقای نسخه پروتکل بین کارگزارها. این آخرین مرحله باعث می شود تا تمام کارگزارها از جدیدترین نسخه پروتکل بین کارگزارها استفاده کنند. در طول ارتقای تدریجی این تغییر، کارگزارهای با نسخه پروتکل جدید همچنان می توانند با کارگزارهای با نسخه پروتکل قدیمی ارتباط برقرار کنند.

پیکربندی

فعال کردن توانایی مصرف کنندگان Kafka برای بازیافت از نسخه نزدیکتر نیازمند تغییرات پیکربندی در هر دو کارگزاره ها و مصرف کنندگان Kafka است. همچنین آنها باید از AZ خود آگاه شوند که با استفاده از رک-آگاهی Kafka امکان پذیر است (1 رک = 1 AZ).

کارگزاران

در پیکربندی کارگزارهای Kafka ما ، ما قبلاًbroker.rackرا برای توزیع نسخه های در AZ های مختلف برای ایجاد انعطاف پذیری تعیین کرده بودیم. نقشه کاری Ansible ما برای Kafka به طور خودکار آن را با شناسه AZ که در زمان استقرار از منابع متادیتای نمونه EC2 به طور پویا دریافت می شود ، تنظیم می کند.

- نام: دریافت شناسه منطقه در دسترسی
  uri:
    url: http://169.254.169.254/latest/meta-data/placement/availability-zone-id
    method: GET
    return_content: yes
  register: ec2_instance_az_id

توجه کنید که ما از شناسه AZ های AWS (به شکل az1 ، az2 ، az3) به جای نام های معمول AZ های AWS (به شکل 1a ، 1b ، 1c) استفاده می کنیم زیرا نگاشت آنها در سراسر حساب های AWS یکپارچه نیست.

علاوه بر این، پارامتر جدید replica.selector.classرا با مقدارorg.apache.kafka.common.replica.RackAwareReplicaSelectorبر روی سمت سرور فعال کرده ایم تا این ویژگی جدید فعال شود.

مصرف کنندگان

در سمت مصرف کننده Kafka، اصولاً بر روی کتابخانه داخلی Golang شرکت Coban برای Kafka که نحوه استفاده تیم های سرویس در تمام عمودهای مجله زیبایی و درمانی آذروت را تسهیل می کند، تکیه می کنیم. ما SDK را برای پشتیبانی از بازیابی از نزدیکترین نسخه به روز کرده ایم.

کاربران ما فقط باید یک متغیر محیطی را برای فعال سازی این ویژگی جدید صادر کنند. سپس SDK بر روی آن اطلاعات رک میزبان مربوطه را به طور پویا از متادیتای میزبان در هنگام راه اندازی بازیابی و تنظیم می کند. بسته به زمان استقرار کارگزارهای Kafka همین کار را انجام می دهند.

همچنین ما همین منطق را برای مصرف کنندگان غیر-SDK خود، به ویژه Flinkpipelines و Kafka Connectconnectors پیاده سازی کرده ایم.

تأثیر

ما از اواخر سال بزودی شروع به فعال سازی بازیابی از نسخه نزدیکتر بر روی مصرف کنندگان Kafka کردیم و از آن زمان به بعد این ویژگی به طور تدریجی بر روی مصرف کنندگان Kafka بیشتر و بیشتر پیاده سازی شده است.

شکل 3 نشان می دهد که تأثیر نسبی این تغییر بر روی ترافیک تقاطع AZ ما است، همانطور که توسط AWS Cost Explorer گزارش شده است. AWS هزینه ترافیک تقاطع AZ را در هر دو سر انتقال داده ها تحمل می کند، بنابراین دو سری داده ها وجود دارد. در سمت کارگزارهای Kafka، ترافیک تقاطع AZ کمتری وجود دارد