ساخت و آموزش مدل های ML با استفاده از معماری مش داده در AWS: قسمت 1

سازمان‌ها در صنایع مختلف از هوش مصنوعی (AI) و یادگیری ماشینی (ML) برای حل چالش‌های تجاری خاص صنعت خود استفاده می‌کنند. به عنوان مثال، در صنعت خدمات مالی، می‌توانید از هوش مصنوعی و ML برای حل چالش‌های مربوط به کشف تقلب، پیش‌بینی ریسک اعتباری، بازاریابی مستقیم و بسیاری موارد دیگر استفاده کنید.

شرکت‌های بزرگ گاهی اوقات یک مرکز تعالی (CoE) راه‌اندازی می‌کنند تا نیازهای خطوط مختلف کسب‌وکار (LoBs) را با تحلیل‌های نوآورانه و پروژه‌های ML برطرف کنند.

برای تولید مدل های ML با کیفیت بالا و عملکرد در مقیاس، آنها باید موارد زیر را انجام دهند:

• یک راه آسان برای دسترسی به داده های مربوط به تجزیه و تحلیل آنها و ML CoE ارائه دهید
• ایجاد مسئولیت پذیری در ارائه دهندگان داده از LoB های فردی برای به اشتراک گذاشتن دارایی های داده ای که قابل کشف، قابل درک، قابل تعامل و قابل اعتماد هستند.

این می تواند زمان چرخه طولانی برای تبدیل موارد استفاده ML از آزمایش به تولید را کاهش دهد و ارزش تجاری در سراسر سازمان ایجاد کند.

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

در این مجموعه دو قسمتی، ما راهنمایی هایی در مورد اینکه چگونه سازمان ها می توانند با استفاده از الگوی طراحی مش داده در AWS یک معماری مدرن داده بسازند و یک تجزیه و تحلیل و ML CoE را قادر می سازد تا مدل های ML را با داده ها در چندین LoB بسازد و آموزش دهد، ارائه می دهیم. ما از نمونه ای از یک سازمان خدمات مالی برای تنظیم زمینه و مورد استفاده برای این مجموعه استفاده می کنیم.

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

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

نمای کلی مش داده ها

بنیانگذار الگوی مش دیتا، زمک دهقانی در کتاب خود داده مش ارزش مبتنی بر داده را در مقیاس ارائه می کند، چهار اصل را برای هدف شبکه داده تعریف کرد:

• مالکیت دامنه توزیع شده - برای پیگیری تغییر سازمانی از مالکیت متمرکز داده‌ها توسط متخصصانی که فناوری‌های پلتفرم داده را اجرا می‌کنند به مدل مالکیت داده غیرمتمرکز، بازگرداندن مالکیت و مسئولیت‌پذیری داده‌ها به LoB‌هایی که داده‌ها در آنجا تولید می‌شوند (دامنه‌های همسو با منبع) یا مصرف می‌شوند. دامنه های همسو با مصرف).
• داده ها به عنوان یک محصول - برای بالا بردن پاسخگویی به اشتراک گذاری دارایی های داده ای نظارت شده، با کیفیت بالا، قابل همکاری و ایمن. بنابراین، تولیدکنندگان داده از LoB های مختلف مسئول ایجاد داده ها به شکل مصرفی درست در منبع هستند.
• تجزیه و تحلیل سلف سرویس - ساده کردن تجربه کاربران داده از تجزیه و تحلیل و ML به طوری که آنها بتوانند محصولات داده را با ابزارهای دلخواه خود کشف، دسترسی و استفاده کنند. علاوه بر این، برای ساده کردن تجربه ارائه دهندگان داده LoB برای ساخت، استقرار و نگهداری محصولات داده از طریق دستور العمل ها و اجزا و قالب های قابل استفاده مجدد.
• حاکمیت محاسباتی فدرال – هماهنگ سازی و خودکارسازی تصمیم گیری درگیر در مدیریت و کنترل دسترسی به داده ها در سطح صاحبان داده ها از LoB های مختلف، که همچنان با سیاست های قانونی، انطباق و امنیتی سازمان گسترده تر است که در نهایت از طریق اجرا می شود. مش

AWS چشم انداز خود را برای ایجاد شبکه داده در بالای AWS در پست های مختلف معرفی کرد:

• ابتدا، ما بر بخش سازمانی مرتبط با مالکیت دامنه توزیع شده و داده ها به عنوان اصول محصول تمرکز کردیم. نویسندگان چشم انداز همراستایی چندین LOB در سراسر سازمان را به سمت یک استراتژی محصول داده توصیف کردند که دامنه های همسو با مصرف را با ابزارهایی برای یافتن و به دست آوردن داده های مورد نیازشان فراهم می کند، در حالی که کنترل لازم در مورد استفاده از آن داده ها را با معرفی مسئولیت پذیری تضمین می کند. دامنه های همسو با منبع برای ارائه محصولات داده آماده برای استفاده درست در منبع. برای اطلاعات بیشتر مراجعه کنید چگونه JPMorgan Chase یک معماری مش داده ایجاد کرد تا ارزش قابل توجهی برای ارتقای پلت فرم داده سازمانی خود ایجاد کند.
• سپس بر بخش فنی مرتبط با ساخت محصولات داده، تجزیه و تحلیل سلف سرویس و اصول حاکمیت محاسباتی فدرال تمرکز کردیم. نویسندگان خدمات اصلی AWS را تشریح کردند که دامنه‌های همسو با منبع را برای ایجاد و اشتراک‌گذاری محصولات داده، طیف گسترده‌ای از خدمات که می‌توانند دامنه‌های همسو با مصرف‌کننده را قادر می‌سازند تا محصولات داده را به روش‌های مختلف بر اساس ابزارهای ترجیحی خود و موارد استفاده مصرف کنند، توصیف کردند. در حال کار روی، و در نهایت خدمات AWS هستند که با اعمال سیاست های دسترسی به داده ها، رویه به اشتراک گذاری داده ها را کنترل می کنند. برای اطلاعات بیشتر مراجعه کنید یک معماری مش داده با استفاده از AWS Lake Formation و AWS Glue طراحی کنید.
• ما همچنین راه حلی برای کشف خودکار داده ها و کنترل دسترسی از طریق یک رابط کاربری متمرکز داده مش نشان دادیم. برای جزئیات بیشتر مراجعه کنید یک گردش کار اشتراک گذاری داده با AWS Lake Formation برای مش داده های خود بسازید.

مورد استفاده از خدمات مالی

به طور معمول، سازمان‌های خدمات مالی بزرگ دارای چندین LoB هستند، مانند بانکداری مصرف‌کننده، بانکداری سرمایه‌گذاری، و مدیریت دارایی، و همچنین یک یا چند تیم تحلیلی و ML CoE. هر LoB خدمات مختلفی را ارائه می دهد:

• LoB بانکداری مصرف کننده خدمات مختلفی از جمله اعتبار و وام مسکن، مدیریت پول نقد، راه حل های پرداخت، محصولات سپرده و سرمایه گذاری و غیره را به مصرف کنندگان و مشاغل ارائه می دهد.
• بانک تجاری یا سرمایه گذاری LoB راه حل های مالی جامعی مانند وام دادن، ریسک ورشکستگی و پرداخت های عمده فروشی به مشتریان، از جمله مشاغل کوچک، شرکت های متوسط ​​و شرکت های بزرگ ارائه می دهد.
• مدیریت دارایی LoB محصولات بازنشستگی و خدمات سرمایه گذاری را در تمامی طبقات دارایی ارائه می دهد

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

تصویر زیر برخی از LoBها و نمونه هایی از محصولات داده را نشان می دهد که آنها می توانند به اشتراک بگذارند. همچنین به مصرف‌کنندگان محصولات داده‌ای مانند تجزیه و تحلیل و ML CoE نشان می‌دهد که مدل‌های ML را می‌سازند که می‌توانند در برنامه‌های کاربردی رو به مشتری برای افزایش بیشتر تجربه مشتری نهایی مستقر شوند.

با پیروی از مفهوم شبکه داده های اجتماعی و فنی، با جنبه اجتماعی با مجموعه ای از مراحل سازمانی مانند موارد زیر شروع می کنیم:

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

سپس به جنبه فنی می رویم که شامل سناریوی انتها به انتها تعریف شده در نمودار قبلی است:

1. توانمندسازی LoB بانکداری مصرف کننده با ابزارهایی برای ساختن یک محصول داده پروفایل اعتبار مصرف کننده آماده استفاده.
2. به LoB بانکداری مصرف کننده اجازه دهید تا محصولات داده را در لایه حاکمیت مرکزی به اشتراک بگذارد.
3. تعاریف جهانی و فدرالی از سیاست‌های دسترسی به داده را تعبیه کنید که باید هنگام دسترسی به محصول داده پروفایل اعتبار مصرف‌کننده از طریق حاکمیت داده مرکزی اعمال شوند.
4. به تجزیه و تحلیل و ML CoE اجازه دهید محصول داده را از طریق لایه حاکمیت مرکزی کشف کرده و به آن دسترسی داشته باشد.
5. تجزیه و تحلیل و ML CoE را با ابزارهایی برای استفاده از محصول داده برای ساخت و آموزش مدل پیش‌بینی ریسک اعتباری توانمند کنید. ما مراحل نهایی (6 و 7 در نمودار قبل) را در این مجموعه پوشش نمی‌دهیم. با این حال، برای نشان دادن ارزش تجاری که چنین مدل ML می تواند در یک سناریوی انتها به انتها برای سازمان بیاورد، موارد زیر را نشان می دهیم:
6. این مدل می‌تواند بعداً به سیستم‌های رو به رو مشتری مانند پورتال وب بانکداری مصرف‌کننده یا برنامه تلفن همراه بازگردد.
7. این می تواند به طور خاص در برنامه وام برای ارزیابی مشخصات ریسک درخواست های اعتبار و وام مسکن استفاده شود.

در ادامه، نیازهای فنی هر یک از اجزا را شرح می دهیم.

فرو رفتن عمیق در نیازهای فنی

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

مصرف کننده داده: Analytics و ML CoE

مصرف کنندگان داده مانند دانشمندان داده از تجزیه و تحلیل و ML CoE باید بتوانند کارهای زیر را انجام دهند:

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

تولید کننده داده: مالکیت دامنه

تولیدکنندگان داده، مانند تیم‌های دامنه از LoB‌های مختلف در سازمان خدمات مالی، باید مجموعه‌های داده انتخاب‌شده را ثبت و به اشتراک بگذارند که شامل موارد زیر است:

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

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

حاکمیت داده: قابلیت کشف، دسترسی و قابلیت حسابرسی

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

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

بررسی اجمالی راه حل

نمودار زیر معماری سطح بالای راه حل پیشنهادی را نشان می دهد.

ما مصرف داده توسط تجزیه و تحلیل و ML CoE را با آمازون آتنا و آمازون SageMaker in بخش 2 از این سری

در این پست، ما بر فرآیند ورود داده به شبکه داده تمرکز می کنیم و توضیح می دهیم که چگونه یک LoB فردی مانند تیم داده دامنه بانکی مصرف کننده می تواند از ابزارهای AWS مانند استفاده کند. چسب AWS و AWS Glue Data Brew برای تهیه، نظارت و ارتقای کیفیت محصولات داده خود، و سپس ثبت آن محصولات داده در حساب حاکمیت داده مرکزی از طریق سازند دریاچه AWS.

LoB بانکداری مصرف کننده (تولیدکننده داده)

یکی از اصول اصلی داده مش مفهوم داده به عنوان یک محصول است. بسیار مهم است که تیم داده های حوزه بانکی مصرف کننده روی تهیه محصولات داده ای که برای استفاده مصرف کنندگان داده آماده هستند، کار کنند. این را می توان با استفاده از ابزارهای استخراج، تبدیل و بارگذاری (ETL) AWS مانند AWS Glue برای پردازش داده های خام جمع آوری شده روی سرویس ذخیره سازی ساده آمازون (Amazon S3)، یا به طور متناوب به فروشگاه های داده عملیاتی که در آن داده ها تولید می شود متصل شوید. همچنین می توانید استفاده کنید DataBrew، که یک ابزار آماده سازی داده های بصری بدون کد است که تمیز کردن و عادی سازی داده ها را آسان می کند.

به عنوان مثال، در حین آماده‌سازی محصول داده‌های نمایه اعتبار مصرف‌کننده، تیم داده‌های دامنه بانکی مصرف‌کننده می‌تواند یک تنظیم ساده برای ترجمه نام ویژگی داده‌های خام بازیابی شده از مجموعه داده منبع باز از آلمانی به انگلیسی انجام دهد. داده های اعتباری آلمان Statlog، که از 20 ویژگی و 1,000 ردیف تشکیل شده است.

حاکمیت داده ها

سرویس اصلی AWS برای فعال کردن مدیریت شبکه داده Lake Formation است. Lake Formation توانایی اعمال حاکمیت داده در هر دامنه داده و در سراسر دامنه را ارائه می دهد تا اطمینان حاصل شود که داده ها به راحتی قابل کشف و ایمن هستند. این یک مدل امنیتی فدرال را ارائه می دهد که می تواند به صورت مرکزی مدیریت شود، با بهترین شیوه ها برای کشف داده ها، امنیت و انطباق، در حالی که امکان چابکی بالا را در هر دامنه فراهم می کند.

Lake Formation یک API برای ساده‌سازی نحوه جذب، ذخیره و مدیریت داده‌ها به همراه امنیت در سطح ردیف برای محافظت از داده‌های شما ارائه می‌دهد. همچنین عملکردهایی مانند کنترل دسترسی دانه بندی، جداول کنترل شده و بهینه سازی ذخیره سازی را ارائه می دهد.

علاوه بر این، Lake Formations ارائه می دهد API اشتراک گذاری داده که می توانید برای به اشتراک گذاری داده ها استفاده کنید در حساب های مختلف. این به مصرف‌کننده تجزیه و تحلیل و ML CoE اجازه می‌دهد تا کوئری‌های Athena را اجرا کند که جداول را در چندین حساب جستجو می‌کند و به آنها می‌پیوندد. برای اطلاعات بیشتر به راهنمای توسعه دهنده AWS Lake Formation.

مدیریت دسترسی به منابع AWS (RAM AWS) راهی امن برای به اشتراک گذاری منابع از طریق فراهم می کند AWS Identity and Access Manager (IAM) نقش ها و کاربران در سراسر حساب های AWS در یک سازمان یا واحدهای سازمانی (OUs) در سازمان های AWS

Lake Formation همراه با RAM AWS یک راه برای مدیریت اشتراک گذاری داده ها و دسترسی به حساب های AWS فراهم می کند. ما از این رویکرد به عنوان کنترل دسترسی مبتنی بر RAM. برای جزئیات بیشتر در مورد این رویکرد، مراجعه کنید یک گردش کار اشتراک گذاری داده با AWS Lake Formation برای مش داده های خود بسازید.

Lake Formation همچنین راه دیگری برای مدیریت اشتراک گذاری داده ها و دسترسی با استفاده از آن ارائه می دهد برچسب های تشکیل دریاچه. ما از این رویکرد به عنوان کنترل دسترسی مبتنی بر برچسب. برای جزئیات بیشتر مراجعه کنید با استفاده از کنترل دسترسی مبتنی بر برچسب AWS Lake Formation یک معماری مدرن داده و الگوی مش داده در مقیاس بسازید..

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

پیش نیازها

برای راه اندازی یک معماری مش داده، حداقل به سه حساب AWS نیاز دارید: یک حساب تولید کننده، یک حساب مرکزی و یک حساب مصرف کننده.

محیط مش داده را مستقر کنید

برای استقرار یک محیط مش داده، می توانید از موارد زیر استفاده کنید مخزن GitHub. این مخزن شامل سه AWS CloudFormation الگوهایی که یک محیط مش داده را مستقر می کنند که شامل هر یک از حساب ها (تولیدکننده، مرکزی و مصرف کننده) است. در هر حساب، می‌توانید الگوی CloudFormation مربوطه آن را اجرا کنید.

حساب مرکزی

در اکانت مرکزی مراحل زیر را انجام دهید:

1. پشته CloudFormation را راه اندازی کنید:
   
2. دو کاربر IAM ایجاد کنید:
   1. DataMeshOwner
   2. ProducerSteward
3. گرانت DataMeshOwner به عنوان مدیر سازند دریاچه
4. یک نقش IAM ایجاد کنید:
   1. LFRegisterLocationServiceRole
5. دو خط مشی IAM ایجاد کنید:
   1. ProducerStewardPolicy
   2. S3DataLakePolicy
6. ایجاد کارت اعتباری پایگاه داده برای ProducerSteward در حساب تولید کننده
7. مجوز مکان داده را با حساب تولید کننده به اشتراک بگذارید.

حساب تولید کننده

در حساب تولید کننده مراحل زیر را انجام دهید:

1. پشته CloudFormation را راه اندازی کنید:
   
2. سطل S3 را ایجاد کنید credit-card، که میز را نگه می دارد credit_card.
3. اجازه دسترسی به سطل S3 برای نقش خدماتی Lake Formation حساب مرکزی.
4. خزنده چسب AWS را ایجاد کنید creditCrawler-<ProducerAccountID>.
5. یک نقش خدمات خزنده AWS Glue ایجاد کنید.
6. مجوزهای مربوط به مکان سطل S3 را اعطا کنید credit-card-<ProducerAccountID>-<aws-region> به نقش خزنده چسب AWS.
7. یک کاربر IAM مباشر تولید کننده ایجاد کنید.

حساب مصرف کننده

در حساب مصرف کننده مراحل زیر را انجام دهید:

1. پشته CloudFormation را راه اندازی کنید:
   
2. سطل S3 را ایجاد کنید <AWS Account ID>-<aws-region>-athena-logs.
3. گروه کاری آتنا را ایجاد کنید consumer-workgroup.
4. کاربر IAM را ایجاد کنید ConsumerAdmin.

یک پایگاه داده اضافه کنید و حساب مصرف کننده را در آن مشترک کنید

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

ثبت محصول داده

معماری زیر مراحل دقیق نحوه عملکرد تیم LoB بانکی مصرف کننده را که به عنوان تولیدکننده داده عمل می کند، می تواند محصولات داده خود را در حساب حاکمیت داده مرکزی (محصولات داده داخلی در شبکه داده سازمان) ثبت کند.

مراحل کلی برای ثبت محصول داده به شرح زیر است:

1. یک پایگاه داده هدف برای محصول داده در حساب حاکمیت مرکزی ایجاد کنید. به عنوان مثال، الگوی CloudFormation از حساب مرکزی قبلاً پایگاه داده هدف را ایجاد می کند credit-card.
2. پایگاه داده هدف ایجاد شده را با مبدا در حساب تولید کننده به اشتراک بگذارید.
3. یک پیوند منبع از پایگاه داده مشترک در حساب تولید کننده ایجاد کنید. در اسکرین شات زیر، در کنسول Lake Formation در اکانت سازنده می بینیم که rl_credit-card لینک منبع است credit-card پایگاه داده.
   
4. پر کردن جداول (با داده های تنظیم شده در حساب تولید کننده) در داخل پایگاه داده پیوند منبع (rl_credit-card) با استفاده از خزنده چسب AWS در حساب تولید کننده.
   

جدول ایجاد شده به طور خودکار در حساب حاکمیت مرکزی ظاهر می شود. تصویر زیر نمونه ای از جدول موجود در Lake Formation را در حساب مرکزی نشان می دهد. این پس از انجام مراحل قبلی برای پر کردن پایگاه داده پیوند منبع است rl_credit-card در حساب تولید کننده

نتیجه

در قسمت اول این مجموعه، اهداف سازمان‌های خدمات مالی برای دستیابی به چابکی بیشتر برای تیم‌های تحلیلی و ML خود و کاهش زمان از داده‌ها به بینش را مورد بحث قرار دادیم. ما همچنین بر ساخت یک معماری مش داده در AWS متمرکز شدیم، جایی که خدمات AWS با کاربری آسان، مقیاس‌پذیر و مقرون به صرفه مانند AWS Glue، DataBrew و Lake Formation را معرفی کرده‌ایم. تیم های تولید کننده داده می توانند از این خدمات برای ساخت و به اشتراک گذاری محصولات داده ای با کیفیت بالا، قابل همکاری و ایمن استفاده کنند که برای مقاصد تحلیلی برای مصرف کنندگان مختلف داده آماده استفاده هستند.

In بخش 2، ما روی تیم های تجزیه و تحلیل و ML CoE تمرکز می کنیم که از محصولات داده به اشتراک گذاشته شده توسط LoB بانکداری مصرف کننده استفاده می کنند تا یک مدل پیش بینی ریسک اعتباری با استفاده از خدمات AWS مانند Athena و SageMaker ایجاد کنند.

---

درباره نویسندگان

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

حسن پوناوالا حسن معمار ارشد راه حل های تخصصی AI/ML در AWS است، به مشتریان کمک می کند تا برنامه های یادگیری ماشین را در تولید در AWS طراحی و استقرار دهند. او بیش از 12 سال تجربه کاری به عنوان دانشمند داده، متخصص یادگیری ماشین و توسعه دهنده نرم افزار دارد. حسن در اوقات فراغت خود عاشق گشت و گذار در طبیعت و گذراندن وقت با دوستان و خانواده است.

بنوا دو پاتول یک معمار راه حل های تخصصی AI/ML در AWS است. او با ارائه راهنمایی و کمک فنی به مشتریان کمک می کند تا راه حل های مرتبط با AI/ML با استفاده از AWS ایجاد کنند. در اوقات فراغتش دوست دارد پیانو بزند و با دوستان وقت بگذراند.