نگاهی به قالب‌های جدید ذخیره داده‌ها (به صورت خام)
آیا پادشاهی parquet در حوزه قالب های خام ذخیره داده‌ها در معرض خطر قرار گرفته است؟

با گسترش مفاهیمی مانند LakeHouse ها و استانداردهایی مانند IceBerg و تسهیل امکان اجرای کوئری بر روی فایل‌های داده پردازش نشده (خام )، قالب ذخیره Parquet و تا حدودی هم ORC به یک de facto استاندارد در این حوزه تبدیل شده است و در چند سال اخیر، رشد استفاده از آنها را شاهد بوده‌ایم.
با این وجود به نظر می‌رسد در مرحله گذار از این قالب‌های کلاسیک ذخیره ستونی داده‌ها به قالب‌های ذخیره داده‌های خام با ضریب فشردگی بالاتر و بهینگی بسیار بیشتر در پردازش و پیمایش هستیم .
تعدادی ازین قالب‌های جدید ذخیره داده‌ها به صورت خام (بدون نیاز به دیتابیس برای ذخیره این اطلاعات) در مقاله زیر معرفی و بررسی شده‌اند.

“Make Apache Parquet 10-100x Faster 🚀” That’s one of the motivations! There is no denying in the fact that the #Parquet file format has been instrumental…

https://www.linkedin.com/posts/dipankar-mazumdar_parquet-bigdata-dataengineering-activity-7253095572268613632-Wk2r

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

در نظر بگیرید :
– سامانه‌های ذخیره سازی مانند s3 بسیار رایج شده‌اند و هزینه استفاده از آنها هم بسیار کاهش یافته است.‌
– کتابخانه‌های پردازش داده، بسیار حرفه‌ای تر و موثرتر شده‌اند (مثلا polars در مقابل pandas)
– استانداردهایی برای ساختاردهی به فایل‌های خام ایجاد شده‌اند که حتی امکان اجرای تراکنش‌های ACID را هم روی داده‌های خام فراهم می‌کنند(Apache Iceberg)
– کاتالوگ‌هایی مانند Polaris ، مسأله سطح دسترسی و مسایل امنیتی مرتبط با این فایلهای خام را برطرف کرده‌اند.
– ابزارهای دم‌دستی مانند DuckDB برای کار با این استانداردها، ارتقا یافته‌اند …
– خیلی از منابع داده‌ای ما زیر یک ترابایت هستند.(پست اخیر علیرضا صادقی را در این زمینه از دست ندهید)
https://lnkd.in/d7W467Fb
به چه نتیجه‌ای می‌رسید ؟ آیا ظهور بازیگران جدید و رواج این قالب‌های حرفه‌ای ذخیره داده‌ها در دنیای مهندسی داده که هم سرعت پردازش دیتا را تضمین خواهند کرد و هم نیاز به استفاده از دیتابیس را برای بسیاری از داده‌های غیرحیاتی سامانه‌ها، از بین خواهند برد، دور از انتظار نخواهد بود؟

نکات اصلی مقاله فوق :

Now, in the past year or so, there has been a huge effort in bringing other file formats.

✅ Some of these formats take inspiration from Parquet at some level but are targeted towards specific workloads (say unstructured data – machine learning)

✅ Formats like BTRBlocks uses a set of lightweight encoding schemes, achieving fast & efficient decompression & high compression ratios (GitHub Address).

✅ Lance by LanceDB use cases’ are more targeted towards ML (multi modal). Claims 100x faster than Parquet. (check out this blog post)

✅ Nimble by Meta is a new columnar file format for large datasets. It is meant to be a replacement for file formats such as Parquet, ORC. Suited for ML use cases (feature store).

✅ Vortex is another one that claims to provide faster random access reads (100-200x faster) and scans (2-10x faster), while preserving approximately the same compression ratio and write throughput as Parquet with ZSTD. (Vortex’s default compression strategy is based on the BtrBlocks paper.)

‍ معرفی JuicsFS: راهکار مدرن برای ذخیره‌سازی توزیع‌شده داده

انتخاب یک راهکار مقیاس‌پذیر و کارآ برای ذخیره توزیع شده فایل‌ها در بسیاری از معماری‌های امروزی سیستم‌های اطلاعاتی یک تصمیم مهم در ایجاد یک زیرساخت ذخیره سازی مطمئن و قابل اتکاست .
برای سال‌ها این نقش را HDFS‌ هدوپ برای سازمان‌ها ایفا می‌کرد که البته برای نیازمندی‌های مدرن طراحی نشده بود و بیشتر ابزار ذخیره سازی هدوپ در عصر نخستین فناوری‌های مرتبط با کلان‌داده بود.
با محبوبیت S3 آمازون، گزینه متن‌باز آن یعنی Mino هم در چند سال اخیر بسیار رایج شده است و به یک De Facto استاندارد برای ایجاد یک زیرساخت ذخیره فایل توزیع شده تبدیل شده است که راه‌اندازی و کار با آن هم بسیار ساده است.
اما اگر سیستمی دارید که بخشی ازفایلهای آن در کلاد (S3، Google Cloud Storage، Azure Blob) و بخشی دیگر در سرورهای محلی و بخشی در سرورهای تخصصی استوریج مانند سرویس‌های S3 که امروزه اکثر شرکت‌های ایرانی هم ارائه می‌دهند، قرار گرفته است و به یک واسط استاندارد و یکپارچه برای دسترسی به تمام این استوریج‌ها نیاز دارید، JuiceFS برای شما طراحی شده است.

💡 مزایای کلیدی JuicsFS

• سازگاری کامل با POSIX: امکان استفاده مانند یک سیستم فایل معمولی
• پشتیبانی از انواع ذخیره‌سازی ابری
• عملکرد بالا: بهره‌گیری از کش محلی برای بهبود سرعت خواندن و نوشتن (واینکه با زبان Go نوشته شده است)
• قابلیت اطمینان و مقیاس‌پذیری: امکان گسترش آسان با رشد حجم داده‌ها
آدرس گیت‌هاب پروژه : https://github.com/juicedata/juicefs
سایت اصلی JuicFS
https://juicefs.com/en

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

این فایل سیستم در نسخه رایگان از Distributed Data Cache استفاده نمی کنه همچنین عدم پشتیبانی از ACL و کربروس و Apache Ranger یعینی عدم پشتیبانی از کلیه راه کارهای امنیت . در سازمان های بزرگ این این موارد نباشه اصلا توصیه نمیشه ولی شاید برای سازمان هایی که بخوان امنیت را در لایه application کنترل کنن شاید مفید باشه

»

#DataEngineering #BigData #Cloud #OpenSource #DistributedSystems

‍ 🚀 آیا Apache Spark در حال نابودی است؟ بیایید با هم صحبت کنیم!

در دنیای مهندسی داده، هر چند وقت یک‌بار یک ابزار جدید ظاهر می‌شود و ادعا می‌کند که بهتر، سریع‌تر و کارآمدتر از گزینه‌های قبلی است. این روزها برخی معتقدند که Apache Spark دیگر گزینه‌ی مناسبی برای پردازش داده‌های حجیم نیست و باید جای خود را به فناوری‌های جدید بدهد. اما آیا واقعاً این‌طور است؟ بیاییدمقاله ای که در مارس 2025 در مدیوم با عنوان «Is Apache Spark Really Dying? Let’s Talk» منتشر شده است را با هم مرور کنیم

https://medium.com/@afroinfotech/is-apache-spark-really-dying-lets-talk-9b104b20b5e9

⚡️ چرا برخی به دنبال جایگزین Spark هستند؟
🔴 مشکلات عملکردی: سربار JVM و مدیریت حافظه باعث کاهش کارایی در برخی پردازش‌ها می‌شود.
🔴 ضعف در یادگیری ماشین و تحلیل سریع: Spark MLlib در برابر TensorFlow و PyTorch حرفی برای گفتن ندارد. همچنین، برای کوئری‌های سریع و سبک، ابزارهایی مثل DuckDB و Polars گزینه‌های بهتری هستند.
🔴 پیچیدگی در تنظیمات، راه‌اندازی و دیباگینگ: پیام‌های خطای نامفهوم و نیاز به تنظیمات دقیق برای بهینه‌سازی عملکرد.

🔥 اما چرا Spark همچنان محبوب است؟
🟢 قدرت در پردازش‌های ETL حجیم، مناسب برای پردازش ترابایت‌ها و پتابایت‌های داده.
🟢 مقیاس‌پذیری بالا و پردازش توزیع‌شده، مناسب برای خوشه‌های بزرگ داده‌ای.
🟢 یکپارچگی عالی با ابزارهای داده‌ای مثل Delta Lake، Apache Iceberg و Hudi و سرویس‌های ابری AWS، Azure و GCP.
🟢 پذیرش گسترده در صنعت و جامعه‌ی متخصصان بزرگ، یافتن مهندسان Spark بسیار آسان‌تر از فناوری‌های جدیدی مانند Ray یا Polars است.

🤔 آیا وقت آن رسیده که Spark را کنار بگذاریم؟
✅ اگر پردازش‌های سنگین و توزیع‌شده دارید، Spark همچنان یکی از بهترین گزینه‌هاست.
⚡️ اما اگر به سرعت بالاتر روی یک سیستم واحد، پردازش یادگیری ماشین یا تحلیل بلادرنگ نیاز دارید، ابزارهایی مثل Flink، Polars، Ray و DuckDB انتخاب‌های بهتری هستند.

🔮 آینده‌ی Spark: نابودی یا تکامل؟
واقعیت این است که اسپارک به پایان راه نرسیده هر چند آن چیرگی چندسال پیش خود را در اکوسیستم داده ندارد و ابزارهای متنوع و سبک‌تری برای پردازش داده‌ها امروزه در دسترس ما قراردارند اما اسپارک علاوه بر بلوغ مناسب برای پروژه‌های پردازش داده حجیم، امروزه در حال سازگار کردن خودش با دنیای جدید داده است! 🚀💡

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

به عنوان مثال، اخیراً دیپ‌سیک که یک موج جدید در دنیای مدل‌های زبانی ایجاد کرده، به جای استفاده از Spark از ترکیب DuckDB، یک سیستم فایل جدید و Ray استفاده کرده است. این ترکیب که توسط یک تیم چندنفره توسعه یافته، موفق شده است ۱۰۰ ترابایت داده را در کمتر از ۳۰ دقیقه با استفاده از ۵۰ نود محاسباتی پردازش کند—یک رکورد شگفت‌انگیز!

همچنین، مقاله‌ی چند ماه پیش علیرضا صادقی با عنوان The Rise of Single-Node Processing: Challenging the Distributed-First Mindset به همین موضوع اشاره دارد که برای بیش از ۹۰٪ کاربردهای امروزی، گزینه‌های بسیار بهینه‌تری از ابزارهای کلاسیک پردازش داده مانند Spark وجود دارد.

🔍 نتیجه: تکنولوژی‌هایی مانند Spark همچنان جایگاه خود را دارند، اما مهندسین داده باید فراتر از ابزارهای سنتی فکر کنند و به دنبال راهکارهایی باشند که هم سریع‌تر، هم ساده‌تر و هم کم‌هزینه‌تر باشند.

#ApacheSpark #BigData #مهندسی_داده #ETL #پردازش_داده #یادگیری_ماشین #SingleNodeProcessing

‍ ده سال با مهندسی داده (BigData.ir) 🎉
ده سال پیش، وقتی تصمیم گرفتم وب‌سایتی برای موضوعی بسازم که آن روزها حتی ترجمه‌اش به فارسی ناشناخته بود – «بیگ دیتا» – نه فکرش را می‌کردم که این مسیر تا امروز ادامه پیدا کند و نه می‌دانستم که روزی «مهندسی داده» به یکی از تخصص‌های کلیدی دنیای فناوری تبدیل خواهد شد.

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

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

امیدوارم در این سال‌ها تونسته باشم نقشی – هرچند کوچک – در رشد جامعه تخصصی داده در ایران داشته باشم.
و اگر دوست داشتید، این هم لینک نوشته‌ام در سایت شخصی خودم درباره راه‌اندازی سایت، دقیقاً ده سال پیش:
🔗 وب‌سایت کلان‌داده (بیگ دیتا) راه‌اندازی شد

به امید ادامه‌ی این مسیر... 🙏
#BigData #مهندسی_داده #DataEngineering # تولید_محتوا #علم_داده #ده_سالگی

‍ چرا دریافت نتایج کوئری گاهی اینقدر طول می‌کشد؟ ✨

با پیشرفت روزافزون فناوری دیتابیس‌ها، ضروری است که روش‌ها و پروتکل‌های انتقال داده نیز به‌روزرسانی شوند تا بتوان از تمامی ظرفیت و توان پردازشی این سیستم‌ها به‌طور مؤثر بهره‌برداری کرد.

فرض کنید به عنوان یک تحلیلگر داده، با استفاده از درایور ODBC به ClickHouse متصل شده‌اید و دستوری برای بازیابی ۱۰ هزار رکورد خاص اجرا کرده‌اید. دستور را ارسال می‌کنید و منتظر نتایج می‌مانید، اما متوجه می‌شوید که زمان دریافت نتایج به طرز معناداری بیشتر از زمانی است که همان دستور را مستقیماً در خط فرمان ClickHouse اجرا کرده‌اید. 😕 این تفاوت زمانی از کجا می‌آید و چرا برای کاربرانی مثل شما که با داده‌های بزرگ کار می‌کنید، مهم است؟

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

🚀 فرمت Arrow: استانداردی برای پردازش سریع داده‌های تحلیلی
سال‌هاست که Apache Arrow به عنوان یک فرمت درون حافظه برای کار با داده‌های ستونی، به یک استاندارد رایج برای پردازش سریع و بهینه داده‌های تحلیلی تبدیل شده است. Arrow با طراحی خاص خود، سربار ناشی از تبدیل داده‌ها بین فرمت‌های مختلف را حذف می‌کند و امکان پردازش موازی را فراهم می‌آورد. این یعنی شما می‌توانید داده‌های بزرگ را با سرعت بیشتری تحلیل کنید. 📊 این فرمت با ابزارهای محبوبی مثل Pandas، Apache Spark و Dask سازگار است و به همین دلیل، برای جامعه داده به یک انتخاب ایده‌آل تبدیل شده است.

حالا تصور کنید اگر بتوانید همین سرعت و کارایی را مستقیماً در ارتباط با دیتابیس‌ داشته باشید. ADBC دقیقا با همین هدف و توسط پروژه محبوب Arrow توسعه داده شد.

🌟 کتابخانه ADBC: راهکاری مدرن برای ارتباط سریع با دیتابیس‌ها
اینجاست که ADBC (Arrow Database Connectivity) وارد می‌شود! ADBC یک رابط برنامه‌نویسی کاربردی (API) مدرن است که به شما اجازه می‌دهد داده‌ها را به صورت مستقیم و در فرمت ستونی از دیتابیس‌هایی مثل ClickHouse یا حتی پستگرس دریافت کنید. با ADBC، دیگر نیازی به تبدیل‌های وقت‌گیر به فرمت ردیفی نیست—داده‌ها با همان ساختار ستونی که برای تحلیل بهینه است، به اپلیکیشن شما منتقل می‌شوند. 🚄

🎯 مزایای ADBC برای تحلیلگران و مهندسین داده
- سرعت بیشتر: حذف تبدیل‌های ردیفی، زمان دریافت داده‌ها را به شدت کاهش می‌دهد.
- پشتیبانی از استریمینگ: داده‌ها به صورت پیوسته و بدون وقفه منتقل می‌شوند.
- انعطاف‌پذیری: با دیتابیس‌های مختلف، از ClickHouse تا PostgreSQL، کار می‌کند.
- اکوسیستم کامل: یک API یکپارچه با ابزارهایی مثل Flight SQL که کار توسعه و کاربرد آنرا ساده‌تر می‌کنند.

برای پروژه‌های تحلیلی که زمان و دقت در آن‌ها حرف اول را می‌زند، تفاوت سرعت ناشی از به کار گیری ADBC برای اتصال به دیتابیس‌ها می‌تواند بهره‌وری شما را متحول کند. 📈
نکته مهم دیگری که باید اشاره شود این است که حتی برای دیتابیس‌های کلاسیک، اگر قصد دریافت حجم زیاد دیتا برای پردازش با ابزارهایی مانند پانداز یا polars را دارید، باز هم ADBC بهینه‌تر است. مثال موجود در شکل این پست هم در همین راستاست.

#DataEngineering #Database #ADBC #ApacheArrow #BigData #PerformanceOptimization #DuckDB #PostgreSQL


منبع : https://arrow.apache.org/blog/2025/02/28/data-wants-to-be-free/

چرا مایکروسافت برای Clarity, دیتابیس تحلیلی کلیک‌هوس را برگزید؟

‍این پست ترجمه‌ای است از پست رسمی تیم ClickHouse درباره انتخاب این پایگاه داده قدرتمند توسط مایکروسافت.
پست اصلی :
https://www.linkedin.com/posts/clickhouseinc_when-microsoft-made-clarity-free-for-everyone-activity-7325580280390451200-fV_M

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

برای چنین زیرساختی، انتخاب موتور تحلیلی بسیار مهم بود.
مایکروسافت پس از ارزیابی گزینه‌هایی مانند Elasticsearch و Apache Spark، در نهایت با تحقیقاتی گسترده و تست‌های متعدد، ClickHouse را برگزید.

چرا ClickHouse؟

در اکتبر ۲۰۲۰، Clarity با ClickHouse در قلب خود راه‌اندازی شد. این تصمیم حاصل هفته‌ها آزمایش، بررسی‌های عمیق، سنجش هزینه‌ها و عملکردها، و انتخابی مبتنی بر داده بود.

دلایل اصلی:

📥 عملکرد بارگذاری (Ingestion): موتور MergeTree در ClickHouse، نرخ ورودی بسیار بالایی را پشتیبانی می‌کند که کاملاً با نیاز بار عظیم Clarity هم‌خوانی دارد.
⚡ عملکرد کوئری: پرس‌وجو روی میلیاردها ردیف در کسری از ثانیه، با کارایی فوق‌العاده. این عملکرد سریع، نیاز به منابع پردازشی بیشتر را حذف و هزینه‌ها را کاهش می‌دهد.
💾 بهره‌وری در ذخیره‌سازی: ساختار ستونی و فشرده‌سازی پیشرفته، موجب صرفه‌جویی چشم‌گیر در فضای دیسک می‌شود. امکان تعریف دیسک‌های گرم و سرد نیز برای کاهش بیشتر هزینه‌ها فراهم است.
📈 مقیاس‌پذیری افقی: ClickHouse به‌صورت master-master توزیع شده و از replication پشتیبانی می‌کند. این یعنی مقیاس‌پذیری روان و آسان هنگام افزایش ترافیک.
🤝 جامعه‌ی متن‌باز و فعال: انتشار منظم نسخه‌ها، پاسخ‌گویی سریع در GitHub و تلگرام، و پشتیبانی قدرتمند. جالب‌تر اینکه تیم مایکروسافت نیز به پروژه کمک کرده و نام خود را در جدول system.contributors ثبت کرده‌اند!

و در نهایت، همان‌طور که در گزارش رسمی مایکروسافت آمده است:

> Compared to our POC system, ClickHouse outperformed Elastic Search and Spark in every aspect. Heat map generation became an instantaneous task to do, and it was even orders of magnitude cheaper to run. This is the reason why many products have migrated from Elastic Search to ClickHouse, experiencing significant enhancements in their services as a result.

آدرس مقاله اصلی مایکروسافت :
https://clarity-blogs-hbh0gkgebxgwfkgd.westus2-01.azurewebsites.net/why-microsoft-clarity-chose-clickhouse/

#ClickHouse #Microsoft #Clarity #داده_های_انبوه #تحلیل_داده #پایگاه_داده #BigData #DataEngineering #ElasticSearch #Spark #CloudArchitecture #OpenSource #مقیاس‌پذیری #StorageOptimization #DatabasePerformance #DistributedSystems

عاشقان دیتا لیک‌هوس، این ریپو گنج واقعی مهندسی داده است! 💻

اگر در حوزه دیتا لیک‌هوس فعالیت می‌کنید یا تازه به این دنیای پرهیجان و آینده‌دار مهندسی داده علاقه‌مند شدید، مخزن کد awesome-lakehouse-guide یه منبع بی‌نظیره که نباید از دستش بدید! 🌟

اینجا یه مجموعه کامل و به‌روز برای تسلط بر فرمت‌های جدولی باز (Apache Hudi، Apache Iceberg، Delta Lake) و معماری لیک‌هوس پیدا می‌کنید:

🔍 مقالات تحقیقاتی: از BtrBlocks و Apache Arrow تا AWS Glue و Apache Flink، با تحلیل‌های عمیق درباره بهینه‌سازی ذخیره‌سازی، عملکرد کوئری‌ها و قابلیت‌های ACID.

📝 بلاگ‌های کاربردی: آموزش‌های عملی برای حل چالش‌هایی مثل metadata bloat، بهینه‌سازی با Z-ordering و مدیریت داده‌های نزدیک به real-time.

💻 کد و نوت‌بوک: مثال‌های آماده برای ایجاد جدول‌های Hudi و Iceberg روی Amazon S3، اجرای کلاستریگ و پیاده‌سازی CDC (Change Data Capture).

📣 پست‌های لینکدین: نکات سریع و به‌روز درباره موضوعاتی مثل پردازش برداری و Apache Arrow.

🗂 فعالیت اخیر: به‌روزرسانی‌های دو هفته پیش (تا ۱۵ تیر ۱۴۰۴) شامل README و پست‌های لینکدین، نشون‌دهنده نگهداری فعال این ریپوئه. یه تصویر معماری (lkh_res.png) هم برای درک بهتر لیک‌هوس موجوده!

این ریپو یه نقشه راه کامل برای حرفه‌ای شدن در لیک‌هوسه، چه بخواید تئوری یاد بگیرید، چه دست به کد بشید! 🚀

🔗 مشاهده ریپو : https://github.com/dipankarmazumdar/awesome-lakehouse-guide

#DataEngineering #Lakehouse #BigData #OpenSource #DataLakehouse

‍ از استانداردسازی تا ساده‌سازی: آینده‌ی Iceberg در مهندسی داده

🔍تحلیلی بر دو تحول مهم: DuckLake و مقاله جدید MinIO


احتمالاً توی یک سال گذشته، بارها چشم‌تون به مقالات، ابزارها، یا گفتگوهایی افتاده که حول‌وحوش موضوعی به اسم #Iceberg می‌چرخن — یه استاندارد باز و ساخت‌یافته برای ذخیره داده‌ها به‌صورت خام، اما با قابلیت‌هایی شبیه پایگاه داده:

📌امکان اجرای کوئری‌های تحلیلی مستقیم روی فایل‌های Parquet

📌پشتیبانی از schema evolution و تراکنش‌های ACID

📌و جداسازی کامل ذخیره‌سازی از موتور پردازش

🧊 به‌جرات میشه گفت که #Iceberg یکی از ترندهای داغ این روزهای مهندسی داده‌ست — از Google BigQuery گرفته تا AWS S3، از Dremio تا Snowflake و پروژه Polaris، همگی در حال پشتیبانی مستقیم یا بومی از Iceberg هستن.

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

🔄 اما دو اتفاق باعث شد که احساس کنم : آینده‌ی Iceberg بسیار ساده‌تر و سبک‌تر خواهد بود.

🌟 اولی معرفی DuckLake بود - https://ducklake.select.

در دنیایی که پر بود از سرویس‌های کاتالوگ مختلف (Hive Metastore، Glue، Project Nessie، JDBC Metastore و...)، #DuckLake اومد و گفت:

«همه‌ی اینا رو بذارید کنار! من با یه دیتابیس SQL ساده، همه کارهای مدیریت متادیتا و فایل‌های داده رو انجام می‌دم.»

📦 داده‌ها همون Parquet هستن روی object storage، اما متادیتا داخل یه دیتابیس ساده مثل #DuckDB یا #Postgres ذخیره می‌شن. همه چیز از طریق #SQL مدیریت می‌شه. بدون نیاز به سرویس‌های جانبی، بدون پیچیدگی. دقیقاً شبیه #SQLite برای دیتالیک‌ها.

🔥 و استقبال خوبی هم ازش شده. چون ساده‌تر از Iceberg معمولی راه می‌افته و سربار کمتری داره.

🧠 دومین اتفاق، مقاله‌ای بود که همین چند روز پیش از طرف MinIO منتشر شد.
https://blog.min.io/the-case-for-native-iceberg-catalog-apis-and-unified-governance-in-object-storage

این مقاله به یه نقطه‌ضعف مهم در معماری‌های فعلی دیتالیک اشاره می‌کرد:

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

یعنی ممکنه کاربر به جدول Iceberg مجوز نداشته باشه، ولی هنوز بتونه مستقیم فایل‌های #Parquet رو از #S3 یا #MinIO بخونه! 😬

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

🔮 پیش‌بینی من؟
ما داریم به سمتی می‌ریم که: Iceberg دیگه یه «ابزار حرفه‌ای مخصوص متخصص‌ها» نیست — بلکه تبدیل می‌شه به یک استاندارد ساده، امن، و در دسترس برای همه تیم‌های داده

🌊 به‌زودی، ساخت یک دریاچه‌داده قدرتمند، به اندازه راه‌اندازی یک دیتابیس ساده خواهد بود. و Iceberg ستون اصلی این تحول باقی می‌مونه.

#ApacheIceberg #DuckLake #MinIO #DataLakehouse #MetadataGovernance #ObjectStorage #OpenTableFormats #SQL #دیتالیک #مهندسی_داده #Parquet #BigData

‍ شمارش بازدیدها و اکشن‌های کاربر با فناوری‌های مدرن داده

در پست قبلی درباره روش‌های کلاسیک شمارش بازدید محصولات یا تماشای ویدئو صحبت کردم.

https://t.iss.one/bigdata_ir/445

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

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

🎯 هدف ما فقط شمارش نیست!

آنچه امروز اهمیت دارد، ذخیره‌سازی دقیق تمام اکشن‌های کاربر است.

چرا؟

✅برای شخصی‌سازی تجربه کاربری بر اساس رفتار هر فرد

✅برای تحلیل عمیق روی محصولات یا ویدئوها و بهبود تجربه کاربران

پس راهکار ایده‌آل باید هم شمارش و هم ذخیره‌سازی کامل داده‌ها را پوشش دهد.


🛠 سه راهکار مدرن برای شمارش و ذخیره اکشن‌ها

1️⃣ استفاده از Cassandra / ScyllaDB و قابلیت Distributed Counter

🎯برای هر کاربر و هر محصول، یک جدول بازدید ایجاد می‌کنیم

🎯هر اکشن را در هر دو جدول ذخیره می‌کنیم (مدل داده این دیتابیس‌ها بر اساس Query طراحی می‌شود)

🎯شمارش اکشن‌ها با Distributed Counter انجام می‌شود

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

✅مزیت اصلی: مقیاس‌پذیری بالا و سرعت فوق‌العاده


2️⃣ ذخیره خام داده‌ها در قالب Apache Iceberg با AutoMQ

🎯جایگزین Kafka سنتی با AutoMQ

🎯 پیام رسان AutoMQ که دقیقا منطبق بر استاندارد کافکا است، پیام‌ها را مستقیماً در Iceberg ذخیره می‌کند

🎯شمارش با Flink + Redis انجام می‌شود

🎯امکان تحلیل بعدی رفتار کاربران با ابزارهایی مثل ClickHouse یا Spark

✅مزیت اصلی: فشار کمتر روی دیتابیس اصلی و نگهداری داده‌های خام برای تحلیل‌های آینده

3️⃣ استفاده از دیتابیس جریانی RisingWave – سریع، مدرن و چندکاره 🚀

دیتابیس RisingWave یک دیتابیس جریانی (Streaming Database) است که با استاندارد PostgreSQL توسعه یافته و از SQL به‌عنوان زبان اصلی پردازش داده‌های جریانی استفاده می‌کند.

📌 ویژگی‌ها و مزایا:

🎯شمارش و پردازش جریانی با SQL ساده → ایجاد Materialized Viewها برای شمارش بازدیدها و اکشن‌ها در لحظه

🎯ذخیره اکشن‌ها در S3 و Iceberg → امکان نگهداری داده‌های خام برای تحلیل‌های آینده

🎯سرعت بالا به لطف Rust → هسته سیستم با زبان Rust نوشته شده و از مزایای کارایی و مصرف کم منابع بهره می‌برد

🎯پشتیبانی از Sinkهای متنوع → خروجی مستقیم به دیتابیس‌ها، سیستم‌های پیام‌رسان، S3، Kafka و...

🎯پردازش رویدادهای پیچیده → اجرای Queryهای تحلیلی پیشرفته بر روی جریان داده بدون نیاز به ابزار جداگانه

✅ نتیجه؟

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

📌 جمع‌بندی

این سه راهکار نسبت به روش‌های سنتی و حتی رویکرد Kafka + Flink، مدرن‌تر هستند و از فناوری‌های جدید حوزه داده بهره می‌برند.

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

#DataEngineering #StreamingData #RealTimeAnalytics #Kafka #Flink #Iceberg #ClickHouse #RisingWave #ScyllaDB #BigData #UserAnalytics #TechInnovation #RustLang #SQL

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

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

در این ویدئو خواهید دید:

ـ نصب ClickHouse روی ویندوز با استفاده از WSL

ـ راه‌اندازی سرور و اتصال اولیه

ـ کار با محیط clickhouse-client

ـ ایجاد دیتابیس و جداول اولیه برای شروع کار



📺 مشاهده ویدئوی جلسه اول:

👉 https://www.youtube.com/watch?v=gGpSbMpfAiM

برای دیدن بخش دوم و ادامه ویدئوهای آموزشی به آدرس زیر مراجعه کنید:

👉 https://sepahram.ir/courses/clickhouse-201/

#ClickHouse #DataEngineering #BigData #Analytics #OLAP #HandsOn


کانال تلگرام سپهرام : @sepahram_school

‍ وقتی SQL هم حلقه For دارد! نگاهی به Lateral Join در PostgreSQL

اگر در حوزه نرم‌افزار، تحلیل داده یا دیتابیس کار می‌کنید، احتمالاً با انواع JOIN‌های معمول در SQL مثل INNER JOIN و LEFT JOIN آشنا هستید.

اما یکی از جوین‌هایی که کمتر درباره‌اش صحبت می‌شود و در عین حال بسیار مفید و کاربردی محسوب می‌شود، LATERAL JOIN است.

بیایید با یک مثال شروع کنیم 👇

فرض کنید یک جدول از محصولات دارید و می‌خواهید برای هر محصول، آمارهایی مثل:

🔰 مجموع کل فروش،

🔰حجم فروش،

🔰تعداد مشتریان منحصربه‌فرد،

🔰و میانگین فروش

در سه ماه گذشته را به‌دست آورید (به تفکیک ماه).

اگر بخواهید این کار را با زبان‌هایی مثل Python یا JavaScript انجام دهید، معمولاً یک حلقه (for) روی تمام محصولات اجرا می‌کنید و درون آن، برای هر محصول، محاسبات آماری مربوط به فروش را انجام می‌دهید.

در واقع، یک حلقه بیرونی برای محصولات و یک حلقه داخلی برای فروش‌های هر محصول دارید. در SQL هم می‌توان دقیقاً همین رفتار را شبیه‌سازی کرد: با استفاده از LATERAL JOIN.

اینجاست که Lateral مثل یک پل ارتباطی عمل می‌کند:

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

به همین دلیل معمولاً از CROSS JOIN LATERAL استفاده می‌کنیم، چون شرط اتصال درون زیرکوئری و با WHERE تعریف می‌شود و در اینجا Inner Join معنا نخواهد داشت.

💫 نتیجه این رهیافت

می‌توانید به‌سادگی کوئری‌هایی بنویسید که مثلاً:

🌟 «ده محصول پرفروش هر کتگوری» را پیدا کند،

🌟یا برای هر مشتری، آخرین تراکنش ثبت‌شده‌اش را نمایش دهد،

🌟یا حتی تحلیل‌های زمانی و Top-N را مستقیماً داخل SQL انجام دهد: بدون نیاز به کدهای پیچیده و توابع پنجره‌ای


🎥 برای آشنایی دقیق‌تر با این مفهوم، یک ویدئوی آموزشی حدود ۴۰ دقیقه‌ای آماده کرده‌ام که در آن، با مثال‌های واقعی و کاربردی نحوه‌ی استفاده از LATERAL JOIN را گام‌به‌گام توضیح داده‌ام.

🔗 لینک مشاهده ویدئو در یوتیوب:

👉 https://youtu.be/vVc2EewTSQU


💡 در این ویدئو یاد موارد زیر را به صورت عملی مرور می‌کنیم:

✅ایده‌ی اصلی و کاربرد LATERAL JOIN

✅تفاوت آن با جوین‌های معمول

✅نوشتن کوئری‌های Top-N per Group

✅تحلیل داده‌های واقعی (مشتریان، فروش، زمان)

✅و نکات مهم برای بهینه‌سازی عملکرد کوئری


📚 این ویدئو بخشی از دوره‌ی PostgreSQL Practical Course در مدرسه مهندسی داده سپهرام است.

👉 https://sepahram.ir/courses


#PostgreSQL #SQL #DataEngineering #Database #LateralJoin #Sepahram #BigData #PostgresTutorial #Analytics