تفاوت‌های بنیادین: انبار داده، دریاچه داده و خانه دریاچه داده برای تحلیل و هوش مصنوعی

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

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

انبارها بر اساس اصلی به نام «طرح‌واره هنگام نوشتن» (Schema-on-write) کار می‌کنند. قبل از اینکه حتی یک بایت داده ذخیره شود، مهندسان داده باید ساختار دقیق آن را تعریف کنند. اگر ستون جدیدی مورد نیاز باشد، کل طرح‌واره باید به‌روزرسانی شود. این امر فرآیند ورود داده را کند، سخت و کار فشرده می‌کند و نیازمند تیم‌های اختصاصی برای نگهداری خط لوله است.[3][4]

با این حال، شواهد مربوط به عملکرد انبار داده همچنان غیرقابل انکار است. از آنجا که داده‌ها از قبل ساختاریافته، پاکسازی شده و به شدت بهینه‌سازی شده‌اند، داشبوردهای هوش تجاری (BI) می‌توانند میلیون‌ها ردیف را در میلی‌ثانیه‌ها جستجو کنند. انبار داده انطباق ACID (تجزیه‌ناپذیری، سازگاری، ایزوله‌سازی، پایداری) را تضمین می‌کند، به این معنی که اگر سیستمی در میانه یک تراکنش دچار مشکل شود، داده‌ها هرگز خراب نمی‌شوند.[1][3]

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

این محدودیت منجر به تولد دریاچه داده شد. دریاچه‌ها که بر روی فضای ذخیره‌سازی ابری ارزان‌قیمت (مانند آمازون S3 یا گوگل کلود استوریج) ساخته شده‌اند، بر اساس «طرح‌واره هنگام خواندن» (Schema-on-read) عمل می‌کنند. شما داده‌های خام را دقیقاً همانطور که تولید می‌شوند به داخل دریاچه می‌ریزید و تنها زمانی نگران ساختاربندی آن می‌شوید که یک دانشمند داده واقعاً نیاز به جستجوی آن داشته باشد.[2][3]

شواهد اقتصادی برای دریاچه‌های داده قانع‌کننده است. ذخیره یک ترابایت داده در یک سطل ابری خام، کسری از هزینه ذخیره آن در یک انبار داده اختصاصی را در بر دارد. این امر به شرکت‌ها اجازه داد تا مجموعه‌های داده عظیمی را «احتیاطاً» ذخیره کنند، شاید برای الگوریتم‌های آینده مفید باشند.[4]

اما انعطاف‌پذیری دریاچه داده در عین حال نقطه ضعف کشنده آن نیز هست. بدون حاکمیت سختگیرانه، دریاچه‌ها به سرعت به «باتلاق‌های داده» تبدیل می‌شوند. دانشمندان داده بخش اعظم وقت خود را صرف تلاش برای یافتن، پاکسازی و تأیید داده‌های مورد نیاز خود می‌کنند، نه اینکه واقعاً مدل بسازند.[3]

علاوه بر این، دریاچه‌های سنتی فاقد تراکنش‌های ACID هستند. اگر دو کاربر همزمان تلاش کنند در یک فایل بنویسند، یا اگر یک خط لوله در نیمه راه به‌روزرسانی شکست بخورد، داده‌ها خراب می‌شوند. شما نمی‌توانید با اطمینان یک گزارش مالی را از یک دریاچه داده خام اجرا کنید.[1][3]

این ما را به خانه دریاچه داده (Lakehouse) می‌رساند. این اصطلاح که توسط شرکت دیتابریکس ابداع و به شدت تبلیغ شده است، ادعا می‌کند که بهترین‌های هر دو دنیا را ارائه می‌دهد: ذخیره‌سازی ارزان و مقیاس‌پذیر یک دریاچه، همراه با تراکنش‌های ACID و حاکمیت یک انبار داده.[1][2]

مکانیسم پشت خانه دریاچه داده جادو نیست؛ بلکه یک لایه فراداده است. فرمت‌های متن‌باز مانند دلتا لیک، آپاچی آیسبرگ و آپاچی هودی در بالای دریاچه داده خام قرار می‌گیرند. این لایه‌ها به عنوان یک دفتر کل پیچیده عمل می‌کنند و دقیقاً ردیابی می‌کنند که کدام فایل‌ها به کدام جدول تعلق دارند و هر تغییری را در یک گزارش تراکنش ثبت می‌کنند.[1][2]

این قابلیت واقعی است. خانه‌های دریاچه داده با موفقیت انطباق ACID را به فضای ذخیره‌سازی ابری ارزان می‌آورند و به دانشمندان داده اجازه می‌دهند حجم کاری پیچیده یادگیری ماشین را مستقیماً روی همان داده‌هایی اجرا کنند که تحلیلگران تجاری برای داشبوردهای BI استفاده می‌کنند، و نیاز به کپی کردن داده‌ها بین دریاچه و انبار داده را از بین می‌برند.[1][5]

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

تحلیل ما از محدودیت‌های معماری نشان می‌دهد که برای جستجوهای بسیار ساختاریافته و تکراری—مانند یک داشبورد فروش روزانه—یک انبار داده خالص همچنان از نظر تأخیر و کارایی پردازشی بهتر از خانه دریاچه داده عمل می‌کند. خانه دریاچه داده بهای پردازشی را به دلیل انعطاف‌پذیری خود تحمیل می‌کند.[5]

در نهایت، شواهد نشان می‌دهد که «تفاوت بنیادین» در حال کم شدن است. انبارهای داده ابری در حال افزودن پشتیبانی از داده‌های بدون ساختار هستند، در حالی که دریاچه‌ها از طریق آیسبرگ و دلتا لیک، حاکمیت شبیه به انبار داده را اتخاذ می‌کنند. خانه دریاچه داده کمتر یک فناوری جدید متمایز است و بیشتر همگرایی اجتناب‌ناپذیر این دو الگو محسوب می‌شود.[1][4]