هنگام توسعه ویژگی‌های جدید برای اپلیکیشن‌های هوش مصنوعی و یادگیری ماشین (ML/AI) بلادرنگ، درک الگوهای مبتنی بر زمان در داده‌های شما بسیار مهم است. زیرا می‌تواند بینش‌های ارزشمندی را آشکار کند. با این حال، بیان Query های موقت می‌تواند چالش‌هایی ایجاد کند. توانایی آنالیز رفتار کاربران خود را در طول زمان، انجام اتصالات موقت دقیق و بررسی الگوهای فعالیت بین رویدادهای مختلف را تصور کنید – همه این‌ها در حالی اتفاق می‌افتند که بتوانید مدیریت زمان را به طور بصری و بدون درز زمان حفظ کنید. این‌جاست که Timeline ها، به عنوان یک انتزاع سطح بالا برای کار با داده‌های موقت، می‌توانند ارزشمند باشند.
در این مقاله، ما به طور عمیقی دنیای Timeline ها را بررسی می‌کنیم. ما نشان خواهیم داد که چگونه آن‌ها بیان Query های موقت را در مورد رویدادها، و مهمتر از همه بین رویدادها، آسان و شهودی می‌کنند. Timeline ها داده‌های مبتنی بر رویداد را بر اساس زمان و موجودیت (entity) سازماندهی می‌کنند و امکان استدلال در مورد زمینه (context) موجود پیرامون رویدادها را فراهم می‌کنند. Query های موقت بیانگر که از Timeline ها استفاده می‌کنند، چندین مزیت دارند:
شهودی بودن
از آن‌جایی که Timeline ها بر اساس زمان مرتب می‌شوند، طبیعی است که Query ها نیز به همین ترتیب عمل کنند. با گذشت زمان، رویدادهای اضافی – ورودی – رخ می‌دهند و در خروجی Query منعکس می‌شوند. این طرز تفکر در مورد محاسبات – به عنوان پیشرفت در طول زمان – شهودی است، زیرا با نحوه مشاهده ما مطابقت دارد.
اعلامگر بودن
عملیات‌های موقت – مانند windowing و shifting – هنگام کار با Timeline ها به وضح اعلام می‌شوند. زیرا زمان بخشی از آن انتزاع است.
قابل Compose بودن
هر عملیات Timeline ها را می‌گیرد و Timeline ها را تولید می‌کند، به این معنی که عملیات می‌تواند در صورت لزوم زنجیره‌ای شود تا نتایج مورد نظر را حاصل کند.
در زیر، ما چهار مثال واقعی که مزایای خطوط موقت را نشان می‌دهند، تشریح می‌کنیم. ما با یک Query ساده برای تجمیع (aggregation) شروع می‌کنیم و به تدریج به پنجره‌های موقت پیچیده‌تر، پنجره‌های وابسته به داده و اتصالات موقتی صحیح می‌پردازیم. در پایان، شما باید درک عمیقی از این‌که Timeline ها چگونه نوشتن Query های موقت مانند SQL را ساده می‌کنند، و چگونه به ما قدرت می‌دهند تا پرسش‌های چالش‌برانگیزتر را پاسخ دهیم، داشته باشید.
جمع هزینه‌ها: تجمیع جمع‌بندی شده (Cumulative Aggregation)
Timeline ها از هر کاری که می‌توانید در SQL انجام دهید، پشتیبانی می‌کنند، و به طور شهودی برای کار در طول زمان گسترش می‌یابند. قبل از بررسی برخی قابلیت‌های جدید برای Query های موقت پیچیده، بیایید به چیز ساده‌ای نگاه کنیم: یک تجمیع (aggregation). نوشتن Query های ساده آسان است. در واقع، چون Timeline ها بر اساس زمان مرتب شده و بر اساس موجودیت (entity) گروه‌بندی می‌شوند، می‌توانند از SQL هم ساده‌تر باشند!
این پرسش را در نظر بگیرید که هر کاربر چقدر هزینه کرده است؟ موقت که به این موضوع فکر می‌کنید، طبیعی است که خریدها را به ترتیب پردازش کنید و مبلغی را که هر کاربر در طول زمان خرج کرده است، به‌روزرسانی کنید. نتیجه، یک مجموع تجمیعی (Cumulative Aggregation) است که یک جدول موقت پیوسته ایجاد می‌کند.
Query مربوطه در زیر را ببینید که به دو روش معادل نوشته شده است. اولی بر مبلغی که برای خریدها اعمال می‌شود، تأکید می‌کند. و دومی بر زنجیره عملیاتی که ما تشکیل داده‌ایم: «خریدها را بگیرید، سپس جمع مبلغ را اعلام کنید». از این‌جا به بعد، ما از دومی استفاده خواهیم کرد. زیرا با روشی که ما در مورد پردازش جدول‌های موقت انتخاب کرده‌ایم، مطابقت بیشتری دارد.
sum(Purchases.amount)
#OR
Purchases.amount | sum()
نوشتن Query های موقت ساده با جدول، موقت به آسانی SQL بود. پردازش رویدادها به ترتیب، روشی آسان برای انجام دادن عملیات‌ها در طول زمان بود. البته، تجمیع بر همه رویدادها، تنها یکی از راه‌هایی است که ممکن است بخواهیم با آن چیزها را جمع‌بندی کنیم. در مثال بعدی، نحوه گسترش این Query ها را با استفاده از پنجره‌های موقت برای تمرکز بر رویدادهای اخیر خواهیم دید.
هزینه ماهانه: پنجره بندی موقت (Temporal Windowing)
هنگام فکر کردن به Query های موقت، بسیار طبیعی است که سؤالاتی در مورد گذشته‌ی نزدیک بپرسید: از ابتدای سال یا در 30 روز گذشته. شهود پردازش رویدادها به ترتیب نشان می‌دهد که پاسخ به این سؤال: «هر کاربر در این ماه چقدر هزینه کرده است»، فقط به تنظیم مجدد مقدار (value) در شروع هر ماه نیاز دارد. و این شهود، دقیقاً نحوه عملکرد این نوع پنجره‌های موقت است که با Timeline ها کار می‌کنند.
Query موقت در زیر نشان داده شده است. این به وضوح هدفی را که در بالا بیان کردیم نشان می‌دهد – خریدها را بگیرید و آن‌ها را از ابتدای هر ماه، تجمیع کنید.
Purchases.amount
| sum(window=since(monthly()))
از آن‌جایی که زمان اصولاً بخشی از هر جدول موقت است، هر تجمیعی می‌تواند در پنجره‌های موقت کار کند. در مثال بعدی، خواهیم دید که کار با Query های پیچیده‌تر، از جمع تجمیع با پنجره‌های پیچیده‌تر، چقدر آسان است.
بازدید صفحات بین خریدها
همه پنجره‌ها از نظر زمانی تعریف نمی‌شوند. اغلب استفاده از رویدادها برای تعیین پنجره‌های مورد استفاده، برای تجمیع مفید است. علاوه بر این، با این که همه نمونه‌ها تا کنون بر روی یک نوع رویداد (خرید) تمرکز کرده‌اند، بررسی الگوهای فعالیت بین رویدادهای مختلف برای شناسایی روابط علی و معلولی حیاتی است.
در این مثال، ما از Timeline ها استفاده خواهیم کرد تا با استفاده از پنجره‌های تعریف شده و چندین نوع رویداد، Query ها را به طور آشکار بیان کنیم. همچنین یک جدول موقت میانی را به نقاط خاصی فیلتر می‌کنیم تا مقادیر استفاده شده در مراحل بعدی، هنگام Compose کردن پرس و جو را کنترل کنیم.
سؤالی که ما به آن پاسخ خواهیم داد این است که: «متوسط تعداد بازدید از صفحه بین هر خرید برای هر کاربر چقدر است؟» ابتدا بازدیدهای صفحه را از آخرین خرید محاسبه می‌کنیم. در زمان هر خرید مشاهده می‌کنیم و سپس میانگین می‌گیریم.
پنجره تعریف شده با داده
اولین کاری که انجام می‌دهیم این است که تعداد بازدیدهای صفحه را از زمان آخرین خرید محاسبه کنیم. در مثال قبلی، ما از ابتدای ماه پنجره‌سازی کردیم. اما هیچ چیز خاصی در مورد Timeline مشخصی که شروع یک ماه را تعریف می‌کند، وجود ندارد. ما می‌توانیم با هر Timeline دیگری، پنجره‌سازی کنیم.
PageViews
| count(window=since(is_valid(Purchases)))
علاوه بر پنجره‌های تعریف شده از داده، نحوه کار با چندین نوع رویداد را می‌بینیم. از آن‌جا که هر Timeline بر اساس زمان مرتب شده و بر اساس موجودیت (entity) گروه‌بندی می‌شود، هر Timeline را می‌توان بر اساس زمان ردیف‌بندی کرد و به صورت خودکار به موجودیت وصل کرد.
مشاهده در زمان‌های خاص
مرحله قبل، بازدیدهای صفحه را از آخرین خرید به ما داد. اما این یک جدول موقت پیوسته بود که در هر نمایش صفحه، تا خرید بعدی افزایش می‌یافت. ما به دنبال یک جدول موقت مجزا با یک مقدار واحد در زمان هر خرید هستیم که نمایانگر بازدیدهای صفحه از خرید قبلی است. برای انجام این کار، از عملیات when استفاده می‌کنیم که امکان مشاهده – و در صورت نیاز interpolating – یک Timeline را در نقاط زمانی خاص فراهم می‌کند.
عملیات when را می‌توان در هر جایی از یک Query موقت استفاده کرد. این عملیات به شما اجازه می‌دهد تا نقاطی را که در خروجی وجود دارند، فیلتر کنید، یا به تجمیع‌های بعدی منتقل کنید.
تجمیع تو در تو (Nested Aggregation)
با دستیابی به تعداد بازدیدهای صفحه بین خریدهای محاسبه شده، اکنون می‌توانیم میانگین این مقدار را محاسبه کنیم. تنها کاری که باید انجام دهیم این است که از میانگین تجمیع استفاده کنیم.
کنار هم گذاشتن
Query کامل در زیر نشان داده شده است. می‌بنیم که مراحل آن با مراحل منطقی که در بالا صحبت کردیم، مطابقت دارند. اگرچه منطق آن به طور معقولی پیچیده بود، Query آن نسبتاً ساده است و ایده ما را برای آن‌چه می‌خواهیم محاسبه کنیم، دربر می‌گیرد. ممکن است پرسش‌های سختی هم پیش بیاید.
PageViews
| count(window=since(is_valid(Purchases)))
| when(is_valid(Purchases))
| mean()
این نوع Query را می‌توان برای تجزیه و تحلیل الگوهای مختلف در فعالیت بازدید صفحه تعمیم داد. شاید ما فقط بخواهیم بازدیدهای صفحاتی را که بیشترین بازدید را دارند، نگاه کنیم، نه همه موارد. به این دلیل که باور داریم کاربران بیشتر روی این موارد تمرکز می‌کنند. شاید هم بخواهیم به جای تمام خریدها، از خریدهای یک مورد مشابه استفاده کنیم.
این Query راه‌هایی را نشان می‌دهد که Timeline ها امکان بیان Query های موقت پیچیده را فراهم می‌کند:
- Ordering به پنجره‌ها امکان می‌دهد تا با delimiter هایشان – در زمان شروع و پایان – به جای محاسبه یک window ID ، از هر مقدار برای گروه‌بندی، تعریف شوند.
- Ordering همچنین امکان استفاده از چندین Timeline را در یک عبارت یکسان فراهم می‌کند. در این مورد، تعداد بازدید صفحات و خریدها مطرح هستند.
- Continuity اجازه می‌دهد تا مقادیر در زمان‌های دلخواه interpolate شوند و با استفاده از عملیات when فیلتر شوند.
- Composability نتیجه هر عملیات را قادر می‌سازد تا با عملیات بعدی برای بیان پرسش‌های موقت استفاده شوند. این اجازه می‌دهد تا پرسش‌های پیچیده به عنوان دنباله‌ای از عملیات ساده بیان شوند.
این قابلیت‌ها امکان شناسایی الگوهای علت و معلولی را فراهم می‌کند. ممکن است خرید درلحظه کنونی باعث شود که بعدا ً هم خرید کنم، اما رویدادهای دگیر اغلب ارتباط قوی‌تری با هم دارند. به عنوان مثال، تمام شدن نوار چسب باعث خرید دوباره آن می‌شود. یا برنامه‌ریزی برای یک سفر باعث خرید وسایل کمپینگ خوهد شد. توانایی مشاهده فعالیت (بازدید از صفحه) در یک پنجره تعریف شده توسط رویدادهای دیگر (خریدها) برای درک رابطه بین آن رویدادها مهم است.
حداقل امتیاز از نظرات (Minimum Review Score)
پیشتر، دیدیم که چگونه Timeline ها اجازه کار با چندین نوع رویداد مرتبط با یک موجودیت را می‌دهند. اما اغلب لازم است با موجودیت‌های چندگانه نیز کار کنید. به عنوان مثال، استفاده از اطلاعات مربوط به کل جمعیت به منظور عادی‌سازی مقادیر برای هر کاربر. مثال آخر ما نحوه کار با چندین موجودیت و انجام یک اتصال موقت را نشان می‌دهد.
آخرین پرسشی که به آن پاسخ خواهیم داد این است که «حداقل میانگین امتیاز بررسی محصول در زمان هر خرید چقدر است؟» برای انجام این کار، ابتدا با نظرات و بررسی‌های هر محصول کار می‌کنیم تا میانگین امتیاز را محاسبه کنیم. سپس آن را به هر خرید با میانگین امتیاز نظرات، پیوند می‌دهیم.
تغییر موجودیت‌ها
برای شروع، می‌خواهیم میانگین امتیاز بررسی محصول را برای هر مورد محاسبه کنیم. از آن‌جایی که این نظرات اکنون بر اساس کاربران گروه‌بندی می‌شوند، باید با استفاده از Key Operation، آن‌ها را بر اساس آیتم گروه‌بندی کنیم. وقتی این کار را انجام دادیم، می‌توانیم از میانگین تجمیعی که قبلاً دیدیم، استفاده کنیم.
جستجو بین موجودیت‌ها
برای هر خرید (گروه‌بندی شده توسط کاربر) می‌خواهیم میانگین امتیاز بررسی مورد مربوطه را جستجو کنیم. برای این کار باید از عملیات جستجو (Lookup) استفاده کنیم.
کنار هم گذاشتن
با کنار هم قرار دادن همه این موارد، ما از جستجو با یک تجمیع حداقلی برای تعیین حداقل میانگین امتیاز اقلام خریداری‌شده توسط هر کاربر، استفاده می‌کنیم.
Reviews.score
| with_key(Reviews.item)
| mean()
| lookup(Purchases.item)
| min()
الگوی گروه‌بندی مجدد به یک موجودیت دیگر، انجام تجمیع و جستجوی مقدار (یا بازگشت به موجودیت‌های اصلی) در تسک‌های پردازش داده رایج هستند. در این مورد، مقدار به دست آمده جستجو شد و مستقیماً مورد استفاده قرار گرفت. در موارد دیگر، این برای عادی‌سازی (normalization) مفید است. در کارهایی چون ارتباط دادن مقدار هر کاربر به مقادیر متوسط در شهر او.
مرتب‌سازی (Ordering) و گروه‌بندی به Timeline ها اجازه می‌دهد تا عملیات بین موجودیت‌های مختلف را به وضوح بیان کنند. نتیجه جستجو از یک point-in-time است که جستجو در آن انجام شده بود. این یک اتصال « as-of» صحیح و موقتی را فراهم می‌کند.
انجام یک اتصال در زمان صحیح برای محاسبه مثال‌های آموزشی از گذشته که با مقادیر ویژگی‌های مورد استفاده در هنگام اعمال مدل قابل مقایسه هستند، حیاتی است. به طور مشابه، این تضمین می‌کند که هر داشبورد، visualization یا آنالیزی که روی نتایج Query انجام می‌شود، در واقع صحیح هستند. این بعث می‌شود به جای استفاده از اطلاعاتی که در آن زمان در دسترس نیستند، به مقادیر گذشته نگاه کنید.
نتیجه‌گیری
ما قدرت Timeline ها را به عنوان یک انتزاع سطح بالا برای مدیریت داده‌های موقت نشان دادیم. ما از طریق عملیات شهودی (intuitive)، اعلامی (declarative) و ترکیبی (composable) نشان دادیم که چگونه Timeline ها بیان Query های موقت را در رویدادها و در میان رویدادها ممکن می‌سازند. ما همچنین با مثال‌هایی از تجمیع‌های ساده تا Query های پیچیده مانند پنجره‌های وابسته به داده و اتصال‌های موقتی، نشان دادیم که چگونه عملیات‌های Timeline را می‌توان زنجیره‌ای نموده و نتایج مورد نظر را تولید کرد. قدرت Timeline ها در توانایی آن‌ها برای بیان آسان پرسش‌های موقت ساده و گسترش شهودی به پرسش‌های موقت پیچیده است.
از مجموع هزینه‌ها تا حداقل امتیاز نظرات، چهار مثال گویا را بررسی کردیم که قابلیت‌های Timeline را در Querying موقت برجسته می‌کند. ما تجمیع جمع‌بندی شده (Cumulative Aggregation) و پنجره‌بندی موقت را بررسی کردیم و دیدیم که چگونه پنجره‌سازی بر اساس داده، توانایی بیان پرسش‌های موقت پیچیده را ارائه می‌دهد. ما همچنین نشان دادیم که چگونه Timeline ها، مدیریت موجودیت‌های چندگانه و اتصالات موقت را تسهیل می‌کنند. این مثال‌ها نشان می‌دهند که با Timeline ها، شما یک ابزار قدرتمند برای شناسایی الگوهای علت و معلولی و محاسبه نمونه‌های آموزشی دارید که در هنگام اعمال یک مدل، معتبر هستند.
Leave feedback about this