چگونه یک پلتفرم داده Lakehouse مقیاس‌پذیر و مقرون‌به‌صرفه بسازیم

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

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

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

چرا تاریخچه محض داده های بزرگ دیگر مفید نیست

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

تا سال 2022 صنعت بالغ شده بود و سؤالات شروع به تغییر کرده بودند. تیم‌ها دیگر نمی‌پرسند چه مقدار داده می‌توانند ذخیره کنند، بلکه می‌پرسند چگونه می‌توانند به آنچه در حال حاضر دارند اعتماد کنند و از آن استفاده کنند. چالش واقعی امروز ظرفیت نیست بلکه حاکمیت است، بلع نیست بلکه تفسیر است.

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

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

لیک‌هاوس به عنوان یک نقطه عطف

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

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

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

چالش‌های ساختاری و حاکمیتی در پذیرش لیک‌هاوس داده

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

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

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

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

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

بهینه‌سازی هزینه به عنوان قانون شماره یک

می‌خواهم با جزئیات بیشتری بر روی بهینه‌سازی هزینه تمرکز کنم، زیرا یکی از مزایای کلیدی معماری لیک‌هاوس است.

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

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

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

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

انتخاب رویکرد معماری مناسب

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

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

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

— لایه نهایی که به عنوان لایه طلا شناخته می‌شود، جایی است که داده های تجمیع‌شده زندگی می‌کنند. داشبوردها و ابزارهای BI مانند Tableau یا Power BI معمولاً به این لایه متصل می‌شوند تا به معیارها و تجسم‌های آماده دسترسی داشته باشند. با این حال، همه چیز نمی‌تواند از قبل محاسبه شود.

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

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

بینش‌هایی از میدان

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

در زیر درس‌هایی که از پیاده‌سازی‌های واقعی آموخته‌ام و آنچه اکنون توصیه می‌کنم آمده است.

1. کوچک شروع کنید، سریع تحویل دهید

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

1. الزامات کسب و کار را زود ترجمه کنید

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

1. فناوری را با قابلیت سازمانی تطبیق دهید

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

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