راهنمای توسعه دهنده برای معماری داده بدون سر

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

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

ما به دلیل شباهت آن به یک سرور بدون هد، آن را معماری داده بدون هد می نامیم، جایی که باید از مانیتور و صفحه کلید خود برای ورود به سیستم استفاده کنید. اگر می خواهید داده های خود را در یک داده بدون هد پردازش یا پرس و جو کنید. معماری، شما باید «سر» پردازش یا پرس و جو خود را بیاورید و آن را به داده ها وصل کنید – به عنوان مثال، Trino، Presto، Apache Flink، یا Apache Spark.  

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

ابتدا، بیایید نگاهی به جریان در معماری داده بدون هد بیاندازیم. 

جریان‌هایی برای معماری داده بدون سر

Apache Kafka، یک پلت‌فرم جریانی مبتنی بر رویداد توزیع‌شده منبع باز، از روز اول یک مدل داده بدون هد داشته است. کافکا API، لایه ذخیره‌سازی داده، کنترل‌های دسترسی و ابرداده‌های اساسی در مورد خوشه را فراهم می‌کند. یک تولیدکننده در مورد یک موضوع می نویسد و سپس یک یا چند مصرف کننده می توانند داده های آن موضوع را با سرعت خود بخوانند. 

تهیه کننده به عنوان یک رئیس کاملا مستقل عمل می کند. ممکن است در برو نوشته شده باشد، < a href="http://Python%20https://www.infoworld.com/article/3204016/what-is-python-powerful-intuitive-programming.html">Pythدر، جاوا، Rust یا زبان C (و بیشتر)، و همچنین می تواند از چارچوب های پردازش جریانی محبوب مانند Kafka Streams یا Apache Flink استفاده کند. در همین حال، مصرف کنندگان شما به طور مشابه مستقل هستند. شاید یکی از مصرف کنندگان شما یک نمونه Kafka Connect باشد، در حالی که دیگری Python باشد، و سومی با C نوشته شده باشد. 

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

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

جدول برای معماری داده بدون سر

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

امروزه، ما به قالب‌های منبع باز محبوب مانند Apache Parquet تکیه می‌کنیم تا تعاریف تمیزی از داده‌های اساسی ارائه کنیم. اما تعریف جدول مستقل از فایل‌های زیربنایی باقی می‌ماند، و برای این منظور ما به فناوری محبوب‌تر به نام آپاچی یخ نگاه می‌کنیم. پروژه مدیریت داده منبع باز Iceberg یک مدیر سیستم فایل قوی و قدرتمند برای داده های ستونی (از جمله پارکت) است و چندین مؤلفه کلیدی برای فعال کردن جداول در معماری داده بدون هد فراهم می کند.

اجزای اصلی Apache Iceberg:

1. اولین جزء ذخیره سازی و بهینه سازی جدول است. Iceberg تمام داده ها را برای ساخت جداول ذخیره می کند، معمولاً با استفاده از فضای ذخیره سازی ابری در دسترس مانند Amazon S3. Iceberg ذخیره و نگهداری داده ها را مدیریت می کند، از جمله بهینه سازی هایی مانند فشرده سازی فایل و نسخه سازی. 
2. کاتالوگ کوه یخ، که حاوی ابرداده ها، طرحواره ها و اطلاعات جدول است، مانند جدول هایی که دارید و کجا آن ها هستند. شما جداول خود را در کاتالوگ Iceberg خود اعلام می کنید، به طوری که می توانید موتورهای پردازش و جستجوی خود را برای دسترسی به داده های اساسی وصل کنید.
3. معاملات. Iceberg از تراکنش‌ها و خواندن و نوشتن همزمان پشتیبانی می‌کند تا چندین هد بتوانند کارهای سنگین را بدون تأثیر بر یکدیگر انجام دهند.
4. کوه یخ قابلیت سفر در زمان را فراهم می کند. شما می توانید پرس و جوها را در یک زمان خاص در برابر یک جدول اجرا کنید، که Iceberg را برای ممیزی، رفع اشکال و تست رگرسیون بسیار مفید می کند. 
5. Iceberg یک لایه داده مرکزی قابل اتصال را فراهم می کند. می‌توانید گزینه‌های منبع باز خود مانند Flink، Trino، Presto، Hive، Spark، و DuckDB یا گزینه‌های محبوب SaaS مانند BigQuery، Redshift، Snowflake و Databricks را وصل کنید. 

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

مزایای معماری داده بدون سر 

پس مزایای اصلی معماری داده بدون سر چیست؟

1. دیگر نیازی به کپی کردن داده ها ندارید و در هزینه و زمان صرفه جویی می کنید. برای مثال، کاربران AWS می‌توانند جداول خود را به Athena، Snowflake و Redshift وصل کنند، بدون اینکه داده‌های خود را به جایی منتقل کنند.
2. دیگر لازم نیست چندین نسخه از داده ها را هماهنگ کنید، و مجموعه داده های مشابه و در عین حال متفاوت را حذف کنید، که به نوبه خود منجر به خطوط لوله داده کمتر می شود.
3. شما می توانید هر هدی که برای کار مناسب تر است را انتخاب کنید، مانند Flink برای یکی، اما DuckDB برای دیگری. از آنجایی که داده‌های شما از موتورهای پردازش انتزاع می‌شوند، دیگر با این یا آن پردازنده «گیر» ندارید. شما در هیچ موتور خاصی قفل نشده‌اید، فقط به این دلیل که سال‌ها پیش داده‌ها را در آن بارگیری کرده‌اید.
4. با یک نقطه کنترل دسترسی، می توانید دسترسی در لایه داده را برای همه پردازنده ها کنترل کنید. برای اطمینان از ایمن ماندن داده‌ها، می‌توانید کنترل دقیق‌تری را در مورد اطلاعات خصوصی و مالی انتخاب کنید. 

تفاوت های قابل توجه بین معماری هدلس و دریاچه داده

سه تفاوت اساسی بین معماری داده بدون سر و معماری دریاچه داده وجود دارد. 

1. در معماری داده بدون سر، هر سرویسی می تواند از داده ها استفاده کند. این مهم نیست که تحلیلی، عملیاتی یا جایی در این بین باشد. معماری Headless در مورد آسان کردن دسترسی به داده ها و اتصال به مکان مورد نیاز است و فقط به مجموعه ابزارهای تحلیلی محدود نمی شود.
2. می‌توانید از جداول، جریان‌ها یا هر دو استفاده کنید — این کاملاً به شما بستگی دارد، بر اساس موارد استفاده و نیازهای تجاری شما. 
3. معماری داده بدون سر نیازی به کپی کردن همه داده های خود در یک مکان مرکزی ندارد. مرسوم است که لایه داده خود را از منابع داده مختلف ترکیب کنید و یک لایه داده مدولار بسازید. 

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

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

چگونه یک معماری داده بدون هد بسازیم

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

اتصال دهنده ها (مانند Kafka Connect) معمولاً برای تبدیل جریان داده های شما به جداول Iceberg استفاده می شوند. اما می‌توانید به سرویس‌های مدیریت‌شده نیز تکیه کنید که به‌طور خودکار موضوعات شما را در جدول‌های Iceberg فقط ضمیمه و بدون شکستگی تبدیل می‌کنند. تعمیر کار، بدون خطوط لوله، فقط با استفاده از همان داده های موجود به عنوان یک جریان یا به عنوان یک جدول.

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

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

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

آدام بلمار، کارشناس فنی در گروه استراتژی فناوری در Confluent است.

—

New Tech Forum مکانی را برای رهبران فناوری – از جمله فروشندگان و سایر مشارکت‌کنندگان خارجی – فراهم می‌کند تا فناوری سازمانی نوظهور را در عمق و وسعت بی‌سابقه بررسی و بحث کنند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه پرس و جوها را به doug_dineley@foundryco ارسال کنید. com.