ارائه در DataEngBytes 2024 سیدنی: ساخت یک Lakehouse داده تراکنش ها در AWS با Apache Iceberg

Summarize this content to 400 words in Persian Lang
من از ارائه در DataEngBytes 2024 در سیدنی لذت بردم، جایی که در مورد موضوع هیجان انگیزی بحث کردم که چشم انداز مدیریت داده را متحول می کند: ساخت یک Lakehouse داده تراکنش بر روی AWS با Apache Iceberg. این پست وبلاگ مطالب کلیدی و بینش های به اشتراک گذاشته شده در طول جلسه را برای کسانی که نتوانستند شرکت کنند و به عنوان یک رکورد از صحبت های من به اشتراک گذاشته شده است.

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

در طول صحبتم، توضیح دادم که یک خانه دریاچه داده:

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

چالش های کلیدی در دریاچه ها و انبارهای داده سنتی:

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

برای حل این چالش‌ها، من مفهوم یک دریاچه داده‌ای را که با Apache Iceberg در AWS ساخته شده است، معرفی کردم که مزایای دریاچه‌ها و انبارها را ترکیب می‌کند.

چرا کوه یخ آپاچی؟

Apache Iceberg یک فرمت جدول باز است که مدیریت داده های تراکنشی در مقیاس بزرگ را در محیط های دریاچه داده امکان پذیر می کند. در اینجا دلیل ایده آل بودن آن برای یک خانه دریاچه است:

تراکنش‌های ACID: Iceberg از انطباق با ACID پشتیبانی می‌کند و امکان به‌روزرسانی، حذف و درج داده‌ها را فراهم می‌کند.
تکامل طرحواره: تغییرات طرحواره را که یک نیاز متداول در محیط های داده پویا است، به خوبی مدیریت می کند.
پارتیشن بندی و عملکرد: پارتیشن بندی خودکار عملکرد پرس و جو را بهینه می کند و حتی برای مجموعه داده های بزرگ کارآمد می کند.
سفر در زمان: عملکرد سفر در زمان Iceberg امکان جستجو در نسخه‌های داده‌های تاریخی را فراهم می‌کند و آن را برای ممیزی، عیب‌یابی و انطباق بسیار ارزشمند می‌کند. مانند Git برای مدیریت کد با نسخه‌سازی و بازگشت به هر commit ID. این ویژگی‌ها Iceberg را به پایه‌ای قوی برای ساختن یک دریاچه‌خانه تجاری تبدیل می‌کند که انعطاف‌پذیری و ثبات را متعادل می‌کند.

چگونه کوه یخ با AWS ادغام می شود:

یکی از محورهای جلسه توضیح نحوه عملکرد Apache Iceberg در اکوسیستم AWS بود. در اینجا یک جمع بندی سریع آمده است:

ذخیره سازی در آمازون S3: جداول Iceberg در Amazon S3 ذخیره می شوند و از ذخیره سازی اشیاء مقیاس پذیر و مقرون به صرفه بهره می برند.
پردازش داده با چسب AWS: چسب AWS به پردازش ETL بدون سرور داده ها در جداول Iceberg اجازه می دهد تا به روز رسانی های دسته ای و بلادرنگ را مدیریت کنید.
پرس و جو با آمازون آتنا: Athena از پرس و جوهای SQL روی جداول Iceberg مستقیماً از S3 پشتیبانی می کند و پرس و جو و تجزیه و تحلیل داده ها را بدون زیرساخت اختصاصی آسان می کند.
حاکمیت با AWS Lake Formation: Lake Formation کنترل دسترسی دقیق را فراهم می کند و امنیت داده ها و حاکمیت را در خانه دریاچه تضمین می کند. این سرویس‌ها با هم یک محیط دریاچه‌خانه قوی در AWS ایجاد می‌کنند و از Iceberg برای ثبات و مقیاس‌پذیری استفاده می‌کنند.

مورد استفاده: Financial Data Lakehouse:

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

تجزیه و تحلیل بلادرنگ با داده های سازگار و سازگار با ACID.
دسترسی به داده های تاریخی از طریق سفر در زمان برای ممیزی و انطباق.
کارایی هزینه با ذخیره داده ها در S3 و استفاده از Athena برای پرس و جوهای درخواستی. این مورد استفاده، پتانسیل lakehouse را برای ساده‌سازی مدیریت داده در صنایعی که هم به عملکرد و هم به حاکمیت داده نیاز دارند، برجسته کرد.

مروری بر معماری:

در جلسه خود، من از طریق یک نمودار معماری که نشان می دهد چگونه یک خانه دریاچه ای در AWS با Iceberg بسازیم قدم زدم:

لایه بلع: داده ها از چندین منبع با استفاده از چسب AWS یا Kinesis وارد S3 می شوند.
لایه ذخیره‌سازی: جداول Iceberg در آمازون S3 با مدیریت ابرداده برای مدیریت پارتیشن‌ها، تکامل طرح‌واره و نسخه‌سازی قرار دارند.
لایه پردازش: کارهای چسب ETL داده ها را پردازش و تبدیل می کند و از دسته ای و جریانی پشتیبانی می کند.
لایه پرس و جو: Athena پرس و جو مبتنی بر SQL از جداول Iceberg را برای تجزیه و تحلیل انعطاف پذیر فعال می کند.
لایه حاکمیت: AWS Lake Formation دسترسی به داده های حساس داخل دریاچه را ایمن و کنترل می کند. این معماری یک رویکرد مقرون‌به‌صرفه و مقیاس‌پذیر را برای ساختن یک خانه دریاچه‌ای تراکنشی نشان می‌دهد که از سازگاری و انعطاف‌پذیری داده‌ها پشتیبانی می‌کند.

درس های آموخته شده:

از کار با Iceberg در AWS، چند درس کلیدی به اشتراک گذاشتم:

استراتژی پارتیشن بندی: پارتیشن بندی کارآمد برای Iceberg برای ارائه عملکرد بالا ضروری است. برنامه ریزی برای الگوهای توزیع داده شما بسیار مهم است.
تکامل طرحواره: اگرچه Iceberg تغییرات طرحواره را به خوبی کنترل می کند، سازگاری با عقب برای جلوگیری از شکستن خطوط لوله داده حیاتی است.
مدیریت هزینه: Lakehouse های داده در S3 مقرون به صرفه هستند، اما نظارت بر کارهای Glue و بهینه سازی جستجوهای Athena به کنترل هزینه ها کمک می کند.
حاکمیت داده: کنترل دسترسی دقیق با Lake Formation امنیت داده ها را تضمین می کند، که به ویژه برای محیط های چند کاربره مهم است.

بهترین روش ها برای ساختن یک خانه دریاچه داده با کوه یخ:

برای پایان دادن به صحبت‌هایم، برخی از بهترین روش‌ها را برای کسانی که در نظر دارند خانه‌ای در دریاچه با Iceberg در AWS بسازند، بیان کردم:

مدل سازی داده ها: جداول Iceberg را با استراتژی پارتیشن بندی قوی برای بهینه سازی عملکرد و کارایی پرس و جو طراحی کنید.
حاکمیت: از سازند دریاچه برای کنترل دسترسی برای اطمینان از دسترسی ایمن به داده ها استفاده کنید.
سفر در زمان برای رعایت مقررات: از ویژگی سفر در زمان Iceberg برای حفظ سوابق تاریخی برای رعایت مقررات استفاده کنید.
بهینه سازی کار چسب: کارهای چسب را برای پردازش به روز رسانی های افزایشی و جلوگیری از هزینه های غیرضروری محاسبه کنید.

در پایان:

ارائه در DataEngBytes 2024 سیدنی یک فرصت فوق العاده برای به اشتراک گذاشتن بینش در مورد ساخت یک خانه دریاچه داده تراکنشی در AWS با Apache Iceberg بود. این معماری یک رویکرد قدرتمند برای مدیریت و تجزیه و تحلیل داده ها با انعطاف پذیری یک دریاچه و سازگاری یک انبار ارائه می دهد و امکانات جدیدی را برای سازمان های داده محور باز می کند.

اگر در حال بررسی یک رویکرد Lakehouse در سازمان خود هستید، من به شدت توصیه می کنم Apache Iceberg و AWS را به عنوان پایه در نظر بگیرید. با ترکیب قابلیت‌های تراکنش Iceberg با مقیاس‌پذیری AWS، می‌توانید یک خانه داده بسازید که با نیازهای داده‌ای در حال تکامل شما سازگار باشد و در عین حال از قابلیت اطمینان و حاکمیت اطمینان حاصل کنید.

امیدوارم این خلاصه مروری روشن از محتوا و بینش سخنرانی من ارائه دهد. اگر سؤالی دارید یا می‌خواهید درباره ساخت خانه‌های داده‌ای اطلاعات بیشتری کسب کنید، برای پست‌های وبلاگ بیشتر در مورد معماری‌های داده پیشرفته با ما تماس بگیرید یا منتظر بمانید!