ایجاد یک ماژول که مسیرهای قابل سرویس دهی جدید را کشف می کند

این سند نحوه گسترش سرویس TensorFlow را برای نظارت بر سیستم‌های ذخیره‌سازی مختلف برای کشف مدل‌ها یا داده‌های جدید (نسخه‌های) برای ارائه توضیح می‌دهد. به طور خاص، نحوه ایجاد و استفاده از یک ماژول را پوشش می دهد که مسیر سیستم ذخیره سازی را برای ظاهر مسیرهای فرعی جدید نظارت می کند، جایی که هر مسیر فرعی نشان دهنده یک نسخه قابل سرویس دهی جدید برای بارگیری است. این نوع ماژول Source<StoragePath> نامیده می شود، زیرا اشیایی از نوع StoragePath (تایپ شده به string ) را منتشر می کند. می توان آن را با یک SourceAdapter که یک Loader قابل سرویس را از مسیر مشخصی که منبع کشف می کند ایجاد می کند.

ابتدا یک نکته در مورد کلیات

استفاده از مسیرها به عنوان دسته برای داده های قابل سرویس دهی مورد نیاز نیست. این صرفاً یک راه را برای وارد کردن قابل استفاده به سیستم نشان می دهد. حتی اگر محیط شما داده های قابل سرویس دهی را در مسیرها کپسوله نکند، این سند شما را با انتزاعات کلیدی آشنا می کند. شما این امکان را دارید که ماژول های Source<T> و SourceAdapter<T1, T2> را برای انواعی که مناسب محیط شما هستند ایجاد کنید (مثلاً RPC یا پیام های pub/sub، رکوردهای پایگاه داده)، یا به سادگی یک Source<std::unique_ptr<Loader>> که مستقیماً لودرهای قابل سرویس دهی را منتشر می کند.

البته، هر نوع داده‌ای که منبع شما منتشر می‌کند (اعم از مسیرهای POSIX، مسیرهای Google Cloud Storage یا دسته‌های RPC)، باید ماژول(های) همراهی وجود داشته باشد که بتواند بر اساس آن سرویس‌ها را بارگیری کند. چنین ماژول هایی SourceAdapters نامیده می شوند. ایجاد یک سفارشی در سند Custom Servable توضیح داده شده است. سرویس TensorFlow همراه با یکی برای نمونه سازی جلسات TensorFlow بر اساس مسیرهای موجود در سیستم های فایلی است که TensorFlow پشتیبانی می کند. می توان با گسترش انتزاع RandomAccessFile ( tensorflow/core/public/env.h )، پشتیبانی از سیستم های فایل اضافی را به TensorFlow اضافه کرد.

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

ایجاد منبع شما

ما یک پیاده سازی مرجع از یک Source<StoragePath> داریم که FileSystemStoragePathSource نام دارد (در sources/storage_path/file_system_storage_path_source* ). FileSystemStoragePathSource یک مسیر سیستم فایل خاص را نظارت می کند، زیرشاخه های عددی را تماشا می کند و آخرین آنها را به عنوان نسخه ای که می خواهد بارگیری کند گزارش می دهد. این سند به جنبه های برجسته FileSystemStoragePathSource می پردازد. ممکن است برای شما راحت باشد که یک کپی از FileSystemStoragePathSource تهیه کنید و سپس آن را مطابق با نیاز خود تغییر دهید.

ابتدا، FileSystemStoragePathSource Source<StoragePath> API را پیاده سازی می کند، که تخصصی از Source<T> API با T محدود به StoragePath است. API متشکل از یک متد SetAspiredVersionsCallback() است که بسته‌ای را فراهم می‌کند که منبع می‌تواند برای ارتباط برقرار کند که می‌خواهد مجموعه خاصی از نسخه‌های قابل سرویس بارگذاری شود.

FileSystemStoragePathSource از نسخه های مورد نظر به روشی بسیار ساده استفاده می کند: سیستم فایل را به صورت دوره ای بازرسی می کند (اصلاً با انجام یک ls )، و اگر یک یا چند مسیر را پیدا کند که شبیه نسخه های قابل سرویس دهی هستند، مشخص می کند که کدام یک آخرین نسخه است و فراخوانی می کند. پاسخ به تماس با لیستی از اندازه یک که فقط آن نسخه را شامل می شود (تحت پیکربندی پیش فرض). بنابراین، در هر زمان، FileSystemStoragePathSource حداکثر یک سرویس‌پذیر را درخواست می‌کند که بارگذاری شود، و اجرای آن از عدم توانایی callback استفاده می‌کند تا خود را بی‌حالت نگه دارد (هیچ ضرری در فراخوانی مجدد تماس با همان آرگومان‌ها وجود ندارد).

FileSystemStoragePathSource دارای یک کارخانه اولیه سازی استاتیک (روش Create() ) است که یک پیام پروتکل پیکربندی می گیرد. پیام پیکربندی شامل جزئیاتی مانند مسیر پایه برای نظارت و فاصله نظارت است. همچنین شامل نام جریان قابل استفاده برای انتشار است. (رویکردهای جایگزین ممکن است نام جریان قابل سرویس‌دهی را از مسیر پایه استخراج کنند تا جریان‌های قابل سرویس دهی متعددی را بر اساس مشاهده سلسله مراتب دایرکتوری عمیق‌تر منتشر کنند؛ این گونه‌ها فراتر از محدوده اجرای مرجع هستند.)

بخش عمده ای از پیاده سازی شامل یک رشته است که به طور دوره ای سیستم فایل را بررسی می کند، همراه با منطقی برای شناسایی و مرتب کردن مسیرهای فرعی عددی که کشف می کند. موضوع در داخل SetAspiredVersionsCallback() راه اندازی می شود (نه در Create() ) زیرا این نقطه ای است که منبع باید "شروع" کند و می داند که درخواست های نسخه مورد نظر را کجا ارسال کند.

استفاده از منبع خود برای بارگیری جلسات TensorFlow

احتمالاً می‌خواهید از ماژول منبع جدید خود در ارتباط با SavedModelBundleSourceAdapter ( servables/tensorflow/saved_model_bundle_source_adapter* ) استفاده کنید، که هر مسیری را که منبع شما منتشر می‌کند به عنوان یک صادرات TensorFlow تفسیر می‌کند و هر مسیر را به یک بارگیری برای یک TensorFlow SavedModelBundle تبدیل می‌کند. احتمالاً آداپتور SavedModelBundle را به AspiredVersionsManager وصل خواهید کرد، که وظیفه بارگیری و سرویس دهی سرورها را بر عهده دارد. یک مثال خوب از زنجیر کردن این سه نوع ماژول به یکدیگر برای به دست آوردن یک کتابخانه سرور فعال در servables/tensorflow/simple_servers.cc یافت می شود. در اینجا مروری از جریان کد اصلی است (با مدیریت خطای بد؛ کد واقعی باید بیشتر مراقب باشد):

ابتدا یک مدیر ایجاد کنید:

std::unique_ptr<AspiredVersionsManager> manager = ...;

سپس، یک آداپتور منبع SavedModelBundle ایجاد کنید و آن را به مدیر وصل کنید:

std::unique_ptr<SavedModelBundleSourceAdapter> bundle_adapter;
SavedModelBundleSourceAdapterConfig config;
// ... populate 'config' with TensorFlow options.
TF_CHECK_OK(SavedModelBundleSourceAdapter::Create(config, &bundle_adapter));
ConnectSourceToTarget(bundle_adapter.get(), manager.get());

در نهایت، منبع مسیر خود را ایجاد کنید و آن را به آداپتور SavedModelBundle متصل کنید:

auto your_source = new YourPathSource(...);
ConnectSourceToTarget(your_source, bundle_adapter.get());

تابع ConnectSourceToTarget() (تعریف شده در core/target.h ) صرفاً SetAspiredVersionsCallback() را برای اتصال یک Source<T> به یک Target<T> فراخوانی می کند ( Target ماژولی است که درخواست های نسخه مورد نظر را دریافت می کند، یعنی یک آداپتور یا مدیر. ).