صدور مجموعه‌داده‌ها از پروژه‌های متعدد به بیگ کوئری

منتشر‌شده در towardsdatascience به تاریخ ۱۹ ژوئن ۲۰۲۱
لینک منبع Export Datastores from multiple projects to BigQuery

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

صادر کردن مرکز ذخیره به بیگ‌کوئری با استفاده از مجموعه داده گوگل

به طور کلی، مشکل را می توان با نمودار زیر بیان کرد:

فرآیند گردش داده می‌تواند در یکی از پروژه‌های منبع یا در یک پروژه جداگانه انجام شود-من فرآیند گردش داده را در یک پروژه جداگانه قرار خواهم داد. نتایج را می توان در بیگ‌کوئری که یا در همان پروژه فرآیند گردش داده قرار دارد یا در پروژه دیگری ذخیره کرد.

تعمیم

بیایید با تعمیم آن شروع کنیم. اول، من فایل config را با دو فیلد جدید گسترش دادم: SourceProjectIDs که چیزی بیشتر از لیست پروژه‌های منبعGCP نیست، و Destination که خروجی مجموعه داده بیگ‌کوئری را تعریف می‌کند.

SourceProjectIDs:
- project-a
- project-b
- project-c
Destination:
ProjectID: dataflow-streaming
Dataset: datastore_dev

گردش داده پایپ‌لاین به صورت زیر تعریف می‌شود:

rows = (
p
| 'projects' >> beam.Create(project_ids)
| 'get all kinds' >> beam.ParDo(GetAllKinds(prefix_of_kinds_to_ignore))
| 'create queries' >> beam.ParDo(CreateQuery(entity_filtering))
| 'read from datastore' >> beam.ParDo(ReadFromDatastore._QueryFn())
| 'convert entities' >> beam.Map(entity_to_json)
)

با یک مرحله اضافی projects ، که PCollection را با لیستی از منبعprojects (از فایل config) تولید می‌کند، گسترش می‌یابد. تغییر کوچکی در مرحله get all kinds لازم بود. GetAllKinds به PTransform تبدیل شد که برای هر پروژه یک لیست از تاپل‌ها ایجاد می‌کند.(project_id, kind_name)

روش process از DoFn تاپل‌ها را مانند هر شی قابل ردیف کردن دیگری می‌پذیرد. با این کار، گام بعدی، create queries، پرسوجوهایی را برای گرفتن سوابق از kind_name خاص که در مرکز داده در project_id زندگی می‌کند، ایجاد می‌کند.

def process(self, project_kind_name, **kwargs):
"""
:param **kwargs:
:param project_kind_name: a tuple with project_id, kind_name
:return: [Query]
"""

project_id, kind_name = project_kind_name

پرس و جوی تولید شده توسط این مرحله از قبل حاوی project_id است بنابراین دیگر نیازی به عبور از شناسه پروژه نیست.

علاوه بر این، طرح اشیاJson که در بیگ‌کوئری ذخیره شده‌اند، در حوزه __key__ دارای ویژگی project است. نام جداول خروجی در بیگ‌کوئری توسط kind_name از پیش تعیین‌شده با project_id ساخته شده‌است.

همه چیز در مورد مجوزها است

کلید راه‌حل ارائه‌شده در سطوح مجوزها قرار می‌گیرد. این شبکه‌ها از دو حساب سرویس (SA) استفاده می‌کنند، یکی در طول ایجاد شغل مورد استفاده قرار می‌گیرد و دیگری توسط نمونه‌های کارگر برای دسترسی به منابع استفاده می‌شود.

ما علاقمند بهSA ای هستیم که توسط کارگر استفاده می‌شود. به طور پیش‌فرض، این حساب خدمات زمانی به طور خودکار ایجاد می‌شود که API موتور محاسباتی برای پروژه شما فعال شود، و دارای یک نام استاندارد باشد.<project-number>-compute@developer.gserviceaccount.com

از این رو ، به پایپ‌لاین گردش داده خود اجازه دهید به مجموعه‌داده‌ها دسترسی پیدا کند که در پروژه دیگری است. بنابراین ، در هر یک از پروژه های منبع ، حساب <project-number>-compute@developer.gserviceaccount.com را با نقش role/datastore.viewer به پروژه اضافه کنید.

همین -پایپ‌لاین طبق انتظار کار می‌کند:

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

امیدوارم از این گزارش لذت برده باشید و بتواند در کار روزانه شما مفید باشد.

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

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