وبلاگ اختصاصی

Basics of data architecture to help data scientists better understand architectural diagrams

مهندسی

مبانی معماری داده برای کمک به دانشمندان داده در درک بهتر نمودارهای معماری

در تاریخ: 1 می 2022

اشتراک:

مبانی معماری داده برای کمک به دانشمندان داده در درک بهتر نمودارهای معماری
قبل از اینکه وانمود کنید که نموداری را که همکار باهوشتان به شما نشان می دهد را درک می کنید.

معرفی
در شرکتی که از داده‌ها برای بدست آوردن ارزش تجاری استفاده می‌کند، اگرچه ممکن است همیشه با مهارت‌های علم داده‌تان قدردانی نکنید، اما همیشه زمانی که زیرساخت داده را به خوبی مدیریت می‌کنید، هستید. همه می‌خواهند داده‌ها در یک مکان قابل دسترس ذخیره شوند، به خوبی تمیز شوند و مرتباً به‌روزرسانی شوند.
با حمایت از این خواسته های محجوب اما ثابت، دستمزد یک معمار داده به همان اندازه یا حتی بالاتر از یک دانشمند داده است. در واقع، بر اساس تحقیقات حقوق و دستمزد انجام شده توسط PayScale (https://www.payscale.com/research/US/Country=United_States/Salary) نشان می دهد که میانگین حقوق معمار داده در ایالات متحده 121816 دلار است، در حالی که حقوق دانشمند داده 96089 دلار است. .
نه اینکه بگوییم همه دانشمندان داده باید شغل خود را تغییر دهند، یادگیری حداقل اصول معماری داده برای ما مزایای زیادی خواهد داشت. در واقع، یک چارچوب ساده (اما معنی دار) وجود دارد که به شما در درک انواع معماری داده های دنیای واقعی کمک می کند.
فهرست مطالب

سه جزء در معماری داده: دریاچه داده -> انبار داده -> دیتا مارت

ابزارهای مورد استفاده در هر جزء

مطالعه موردی – ایجاد فید داده‌های زمان‌بندی‌شده و خودکار از BigQuery (انبار داده) به Google Sheets (Data Mart)

سه جزء در مبانی معماری داده: دریاچه داده -> انبار داده -> دیتا مارت ( مبانی معماری داده )

«دریاچه داده»، «انبار داده» و «دیتا مارت» اجزای معمولی در معماری پلتفرم داده هستند. به این ترتیب، داده های تولید شده در کسب و کار پردازش شده و تنظیم می شود تا مفهوم داده دیگری ایجاد کند.

سه مؤلفه مسئولیت سه عملکرد مختلف را به عهده می گیرند:
مبانی معماری داده
دریاچه داده: یک نسخه اصلی از داده های تولید شده در تجارت را در خود نگه می دارد. پردازش داده ها از نسخه اصلی باید در صورت وجود حداقل باشد. در غیر این صورت در صورتی که برخی از پردازش داده ها در نهایت اشتباه باشد، رفع خطا به صورت گذشته امکان پذیر نخواهد بود.
انبار داده: داده های پردازش شده و ساختار یافته توسط یک مدل داده مدیریت شده را نگهداری می کند که منعکس کننده جهت کلی (نه خاص) استفاده نهایی از داده ها است. در بسیاری از موارد، داده ها در قالب جدول هستند.
Data Mart: یک مجموعه داده فرعی و/یا جمع‌آوری شده را برای استفاده از یک عملکرد تجاری خاص نگهداری می‌کند، به عنوان مثال. واحد تجاری خاص یا منطقه جغرافیایی خاص. یک مثال معمولی زمانی است که خلاصه KPIها را برای یک خط تجاری خاص و به دنبال تجسم در ابزار BI آماده می کنیم. مخصوصاً تهیه این نوع کامپوننت مجزا و مستقل بعد از انبار زمانی که کاربر بخواهد دیتا مارت به طور منظم و مکرر به روز شود، ارزشمند است. برعکس، در مواردی که کاربر بخواهد مجموعه ای از داده ها را برای تجزیه و تحلیل موقت فقط یک بار انجام دهد، می توان از این بخش صرفنظر کرد.

برای مثال‌های دنیای واقعی بیشتر فراتر از این توصیف ساده، از جستجوی «معماری داده» برای یافتن نمودارهای معماری داده‌های زیادی لذت ببرید.

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

مهندسان داده و دانشمندان داده چگونه با این سه جزء کار می کنند؟ ( مبانی معماری داده )

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

مجری ذیصلاح | مهندس مجری اراک و تهران

فرمت ها و مکان های فیزیکی بزارهای مورد استفاده در هر جزء ( مبانی معماری داده )

مبانی معماری داده
اکنون، مفهوم سه جزء پلتفرم داده را درک کردیم. سپس، مردم از چه ابزاری استفاده می کنند؟ بر اساس این «راهنمای پلتفرم داده» (به زبان ژاپنی)، در اینجا چند ایده وجود دارد:
دریاچه داده/انبار
گزینه های زیر برای دریاچه داده و انبار داده وجود دارد.

ابزارهای ETL

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

موتور گردش کار

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

ابزارهای Data mart/BI

ابزارهای زیر را می توان به عنوان راه حل های دیتا مارت و/یا BI استفاده کرد. انتخاب بستگی به زمینه کسب و کار دارد، شرکت شما با چه ابزارهایی آشناست (مثلاً آیا شما شخص Tableau هستید یا شخص Power BI؟)، اندازه داده های انبوه (مثلاً اگر اندازه داده کوچک است، چرا اصول اولیه وجود ندارد؟ راه‌حل‌هایی مانند Excel یا Google Sheets به هدف می‌رسند؟)، از چه راه‌حلی برای انبار داده استفاده می‌کنید (مثلاً اگر انبار داده شما در BigQuery است، Google DataStudio می‌تواند راه‌حل آسانی باشد زیرا دارای پیوند طبیعی در حلقه Google است) و غیره.

مطالعه موردی – ایجاد فید داده‌های زمان‌بندی‌شده و خودکار از BigQuery (انبار داده) به Google Sheets (Data Mart)
هنگامی که اندازه داده ها در حدود یا کمتر از ده ها مگابایت باقی می ماند و هیچ وابستگی به سایر مجموعه داده های بزرگ وجود ندارد، خوب است که به ابزارهای مبتنی بر صفحه گسترده برای ذخیره، پردازش و تجسم داده ها پایبند باشید زیرا هزینه کمتری دارد و برای همه افراد. می تواند از آن استفاده کند.
هنگامی که داده ها بزرگتر می شوند و شروع به وابستگی داده به سایر جداول داده می کنند، مفید است که از ذخیره سازی ابری به عنوان یک انبار داده یک مرحله ای شروع کنید. (زمانی که داده‌ها حتی به ده‌ها ترابایت بزرگ‌تر می‌شوند، استفاده از راه‌حل‌های داخلی برای کارایی هزینه و مدیریت منطقی به نظر می‌رسد.)
در این فصل، موردی را نشان خواهم داد که داده ها در Google BigQuery به عنوان یک انبار داده ذخیره می شوند. داده های BigQuery در زمان واقعی یا در یک فرکانس کوتاه پردازش و ذخیره می شوند. کاربر نهایی همچنان می‌خواهد KPIهای روزانه را در یک صفحه‌گسترده به صورت کاملاً تجمیع‌شده ببیند. این بدان معناست که داده‌های مارت می‌تواند کوچک باشد و حتی با راه‌حل صفحه‌گسترده هم مناسب باشد. به جای اکسل، بیایید از Google Sheets در اینجا استفاده کنیم زیرا می تواند در همان محیطی باشد که منبع داده در BigQuery است. اوه، به هر حال، هر روز به اجرای پرس و جو به صورت دستی فکر نکنید. سعی کنید راه حلی پیدا کنید تا همه چیز به طور خودکار بدون هیچ اقدامی از طرف شما اجرا شود.

مبانی معماری داده
داده های مورد استفاده در این مطالعه موردی
در این مطالعه موردی، من قصد دارم از داده‌های جدول نمونه استفاده کنم که دارای سوابق مسافران تاکسی نیویورک در هر سفر است، از جمله فیلدهای داده زیر:
شناسه خودرو
شناسه راننده
تاریخ سواری
تعداد مسافران
مقدار کرایه
و غیره.
داده های نمونه در BigQuery به عنوان یک انبار داده ذخیره می شود.
آیا Google Sheets می‌تواند داده‌ها را از جداول BigQuery جمع‌آوری کند؟
از نظر فنی بله، اما در حال حاضر این فقط از طریق کاربرگ‌نگار متصل در دسترس است و به حساب G Suite Enterprise، Enterprise for Education، یا G Suite Enterprise Essentials نیاز دارید.

صفحات متصل به کاربر اجازه می دهد تا داده های جدول BigQuery را تقریباً به گونه ای دستکاری کند که گویی آن ها را در صفحه گسترده پخش می کند. نمایش GIF را در این صفحه در پست وبلاگ “BenCollins” ببینید.

مثالی از استفاده از Google Sheets متصل به BigQuery از طریق صفحات متصل (گرفته شده توسط نویسنده)
ورق‌های متصل همچنین امکان زمان‌بندی و به‌روزرسانی خودکار ورق‌ها را فراهم می‌کند، که به عنوان یک دیتا مار یک تقاضای طبیعی است.
اگرچه خود را به عنوان یک گزینه عالی نشان می دهد، یک مشکل احتمالی این است که داشتن حساب G Suite چندان رایج نیست.
برای جزئیات بیشتر در مورد تنظیمات، این پست وبلاگ را از “BenCollins” ببینید.
برای انتقال داده ها از BigQuery به Google Sheets چه کاری می توانیم انجام دهیم؟
برای استخراج داده‌ها از BigQuery و فشار دادن آن به Google Sheets، BigQuery به تنهایی کافی نیست و ما به کمک عملکرد سرور برای فراخوانی API برای ارسال یک درخواست به BigQuery، دریافت داده‌ها و ارسال آن به Google Sheets نیاز داریم.

عملکرد سرور می تواند روی یک ماشین سرور، خارجی یا داخلی GCP باشد (مثلاً «موتور محاسباتی» در GCP؛ یا نمونه «EC2» در AWS). اجرای کد را می توان با استفاده از unix-cron job برنامه ریزی کرد. اما یک نقطه ضعف در اینجا این است که به کار تعمیر و نگهداری و هزینه برای نمونه نیاز دارد و برای اجرای یک برنامه کوچک بسیار زیاد است.
«Google Cloud Functions» یک راه حل به اصطلاح «بدون سرور» برای اجرای کد بدون راه‌اندازی دستگاه سرور است. قرار دادن کد در توابع Cloud و تنظیم یک رویداد ماشه (به عنوان مثال زمان‌بندی زمان‌بندی‌شده در این مورد

y، اما همچنین می تواند درخواست HTML برخی از کاربران اینترنت باشد)، GCP به طور خودکار اجرای کد را مدیریت می کند.
تنظیمات در مطالعه موردی من
دو مرحله در پیکربندی مطالعه موردی من با استفاده از داده‌های تاکسی نیویورک وجود دارد.
مرحله 1: تنظیم زمان‌بندی – Cloud Scheduler و Pub/Sub را تنظیم کنید تا یک Cloud Function را راه‌اندازی کنند.
در اینجا، “Pub/Sub” یک سرویس پیام رسانی است که توسط Cloud Functions مشترک می شود و اجرای آن را هر روز در زمان مشخصی آغاز می کند. “Cloud Scheduler” عملکردی برای راه اندازی چیزی با فرکانس تعریف شده توسط کاربر بر اساس فرمت یونیکس-cron است. با ترکیب این دو، می‌توانیم پیام‌های معمولی ایجاد کنیم تا توسط Cloud Function مشترک شوند. این دستورالعمل رسمی در مورد نحوه انجام آن را ببینید. در اینجا اسکرین شات هایی از راه اندازی GCP من آمده است.

راه اندازی در Cloud Scheduler

راه اندازی در Pub/Sub

مرحله 2: کد را تنظیم کنید — کدی را در Cloud Functions برای درخواست جدول BigQuery آماده کنید و آن را به Google Sheets فشار دهید.
مرحله بعدی راه اندازی Cloud Functions است. در Cloud Functions، شما تعریف می کنید: 1) محرک چیست (در این مطالعه موردی، “cron-topic” ارسال شده از Pub/Sub، مرتبط با Cloud Scheduler که هر 6 صبح صبح ماشه را می کشد) و 2) کد شما می خواهید زمانی که ماشه شناسایی شد اجرا شود.
این دستورالعمل رسمی را برای جزئیات بیشتر ببینید، و در اینجا تصاویری از تنظیمات من وجود دارد.

راه اندازی در توابع ابری (گرفته شده توسط نویسنده)

ورودی کد در Cloud Functions – در اینجا می‌توانید requires.txt را نیز برای استفاده از کتابخانه‌های قابل نصب در برنامه mail.py خود تنظیم کنید. (گرفته شده توسط نویسنده)
کدی که باید اجرا شود باید در تابعی به نام هر چیزی که دوست دارید محصور شود (در مورد من “nytaxi_pubsub”.) محتوای کد از دو بخش تشکیل شده است: بخش 1 برای اجرای یک پرس و جو در BigQuery برای کاهش جدول اصلی BigQuery به KPI و ذخیره آن را به عنوان یک جدول داده دیگر در BigQuery، و همچنین آن را به فریم داده Pandas تبدیل کنید، و قسمت 2 را برای فشار دادن قاب داده به Sheets.
در اینجا کدهایی هستند که من واقعاً استفاده کردم. مهمتر از همه، احراز هویت BigQuery تا زمانی که در همان پروژه GCP مانند Cloud Function قرار دارد، خودکار است (برای توضیح به این صفحه مراجعه کنید.) با این حال، این مورد در مورد Google Sheets نیست، که حداقل به یک رویه برای اشتراک‌گذاری نیاز دارد. برگه هدف از طریق حساب خدمات. برای جزئیات بیشتر به توضیحات در کتابخانه gspread مراجعه کنید.

import os
	import google.auth
	from google.cloud import bigquery
	from google.cloud import bigquery_storage_v1beta1
	import datetime
	import gspread
	import urllib.request
	from oauth2client.service_account import ServiceAccountCredentials

	def nytaxi_pubsub(event, context):


	# 1st. Part – Run query upon data warehouse BigQuery table, create data mart BigQuery table, and create pandas data frame with the same contents.


	today = datetime.date.today().strftime(‘%Y%m%d’)

	# Explicitly create a credentials object. This allows you to use the same
	# credentials for both the BigQuery and BigQuery Storage clients, avoiding
	# unnecessary API calls to fetch duplicate authentication tokens.
	credentials, project_id = google.auth.default(
	scopes=[“https://www.googleapis.com/auth/cloud-platform”]
	)

	# Instantiate bigquery client and bigquery_storage client for the project.
	client = bigquery.Client(project=project_id)
	bqstorageclient = bigquery_storage_v1beta1.BigQueryStorageClient()

	# Define query to run.
	query = f”””
	SELECT
	{today} AS date
	, passenger_count
	, COUNT(*) AS ride_count
	, SUM(passenger_count) AS total_passenger_count
	, SUM(fare_amount) AS total_fare_amount
	, SUM(tip_amount) AS total_tip_amount
	, SUM(total_amount) AS total_amount
	FROM < Original NY taxi data table in BigQuery >
	–WHERE ride_month = {today}
	GROUP BY passenger_count
	ORDER BY passenger_count
	“””

	# Define BigQuery destination table.
	destination_dataset = ‘DataMart_NYTaxi_per_customer’
	destination_table = f”{project_id}.{destination_dataset}.DataMart_NYTaxi_per_customer_{today}”

	## Delete if there’s already a table as the target table.
	client.delete_table(destination_table, not_found_ok=True)

	# Run query upon data warehouse BigQuery table, create data mart BigQuery table, and create pandas data frame with the same contents.
	query_job = client.query(query, job_config=bigquery.QueryJobConfig(destination=destination_table))
	res_df = query_job.result().to_dataframe(bqstorage_client=bqstorageclient)



	# 2nd. Part – Load the data frame to Google Sheets

	# Instantiate Sheets service account client – Beforehand, create service account json and save it somewhere in GCP Storage.
	if not os.path.isfile(‘/tmp/service_account.json’):
	urllib.request.urlretrieve(“< Path to .json with service account credentials stored in GCP Storage>”,”/tmp/service_account.json”)

	client = gspread.service_account(filename=’/tmp/service_account.json’)

	sheet = client.open(“DataMart_NYTaxi_per_customer”).sheet1

	# Only when the Google Sheets file is new.
	# sheet.update([res_df.columns.values.tolist()] + res_df.values.tolist())

	# When Google Sheets file already has some input.
	sheet.insert_rows(res_df.values.tolist(),2)

main.py (کدگذاری شده توسط نویسنده)

google-auth==1.20.1
	google-cloud-bigquery==1.27.2
	google-cloud-bigquery-storage==1.0.0
	oauth2client==4.1.3
	pandas==0.25.3
	pandas-gbq==0.13.2
	gspread==3.6.0
	urllib3==1.24.3

requires.txt (کدگذاری شده توسط نویسنده)

مبانی معماری داده
به‌روزرسانی خودکار داده‌ها پس از یک سفر طولانی تنظیم.
این برگه هر روز صبح به‌طور خودکار به‌روزرسانی می‌شود، و از آنجایی که انبار داده‌ها داده‌های جدید را از طریق ETL از دریاچه داده دریافت می‌کند، ما می‌توانیم به راحتی هر روز صبح، KPI تاکسی‌های نیویورک را دنبال کنیم.
یادداشت پایانی
در یک شرکت بزرگ که مهندسان داده و/یا معماران داده را همراه با دانشمندان داده استخدام می‌کند، نقش اصلی دانشمندان داده لزوماً آماده کردن زیرساخت داده و قرار دادن آن نیست، اما دانستن حداقل به‌دست آوردن اصل معماری داده سودمند خواهد بود. خوب درک کنیم که در کارهای روزانه در کجا ایستاده ایم.
Data Lake -> Data Warehouse -> Data Mart یک چارچوب پلت فرم معمولی برای پردازش داده ها از مبدا تا مورد استفاده است. تفکیک فرآیند به سه جزء سیستم مزایای زیادی برای نگهداری و هدفمندی دارد.
گزینه های زیادی در انتخاب ابزار وجود دارد. آنها باید عاقلانه در برابر محیط داده (اندازه، نوع، و غیره) و هدف کسب و کار انتخاب شوند.
در نهایت در این پست، من یک مطالعه موردی را مورد بحث قرار دادم که در آن ما یک داده mart با اندازه کوچک را در Google Sheets آماده کردیم، و داده‌ها را از BigQuery به عنوان انبار داده بیرون کشیدیم. با استفاده از Cloud Scheduler و Pub/Sub، به روز رسانی به صورت خودکار ساخته شد.
منابع