‍ یکی از کارهای رایج مهندسین داده، ETL‌ است یعنی داده را از یک منبع ورودی خوانده، آن را پردازش کرده و نهایتا در مقصد ذخیره کنیم. برای این منظور، ابزارهای تجاری و متن‌باز بسیار زیادی وجود دارد که از زمان‌های قدیم که Logstash یک تنه، بار انتقال داده‌ها بین انواع منبع‌ها و مقصدها را به دوش می‌کشید تا الان که شاید بیش از ده‌ها ابزار رایج و تخصصی در این خصوص وجود داشته باشد، این فرآیند به بلوغ بسیار خوبی رسیده است.
اما کتابخانه‌های نرم‌افزاری و بخصوص ابزارهای مهندسی داده باید
- ساده : کار با آنها ساده باشد.
- سبک : کارآیی بالایی داشته، منابع بسیار کمی از سیستم را درگیر کنند.
- سهل‌الوصول: به راحتی قابل نصب و پیکربندی باشد.
باشند (می‌توانیم به آنها ۳سین بگوییم!!).
Vector.dev‌ یکی از این ابزارهای مطابق با قانون ۳سین است اما بیشتر برای کاربردهای انتقال و جمع‌آوری لاگ‌ و متریک‌ها مناسب است و برای ETL‌ های رایج، به کار نمی‌‌رود.
https://github.com/vectordotdev/vector
Benthos‌ دقیقا معادل و مشابه Vector.dev و مطابق با قانون ۳سین در حوزه ETL است.
- با زبان Go‌ نوشته شده است و بسیار سبک و کارآ است.
- نصب و راه‌اندازی آن همانطور که در تصویر مشخص است، بسیار راحت و آسان است.
- کار با آن ساده است (هر چند برای بخش پردازش داده‌ها، زمان کمی را برای آشنایی با زبان مخصوص آن باید کنار بگذارید)
- به راحتی امکان خواندن از صف‌هایی مانند کافکا و سوکت‌ها را فراهم می‌کند.
- مجموعه بسیار غنی از منبع‌ها، مقصدها و پردازشگرهای از قبل نوشته شده دارد.
اگر قصد طراحی و پیاده‌سازی خطوط انتقال داده را دارید و پردازش‌هایی که بر روی داده‌های دریافتی انجام می‌دهید، ساده و سرراست (مثل فیلتر کردن برخی ورودی‌ها، استخراج و تغییر شکل چند آیتم و ...) است، حتما Benthos را به عنوان یکی از اصلی‌ترین گزینه‌های خود در نظر بگیرید.
آدرس گیت‌هاب پروژه: https://github.com/benthosdev/benthos
آدرس رسمی سایت: https://www.benthos.dev
گروه تخصصی پرسش‌وپاسخ‌های مهندسی داده : https://t.iss.one/bigdata_ir_discussions

https://nikamooz.com/online-dataengineering-course/?utm_source=linkedin&utm_medium=course-online-lecturer-dataengineering&utm_campaign=online-course

لینک ثبت نام مقدماتی

ما در ترب از PostgreSQL (برای راحتی در نوشتن از این جا به بعد «پستگرس» نوشته خواهد شد) به عنوان پایگاه‌داده‌ی اصلی استفاده می‌کنیم. با توجه به اتمام دوره‌ی پشتیبانی از نسخه‌ی ۱۱ در آبان ماه ۱۴۰۲، تصمیم به به‌روزرسانی این پایگاه‌داده به نسخه‌ی ۱۶ گرفتیم. این به‌روزرسانی نه تنها برای اطمینان از دریافت آخرین به‌روزرسانی‌های امنیتی و رفع باگ‌ها ضروری بود، بلکه به ما اجازه می‌داد تا از ویژگی‌ها و بهبودهای کارایی که در نسخه‌های جدیدتر اضافه شده، بهره‌مند شویم. فرآیند ارتقا نیازمند برنامه‌ریزی دقیق و انجام تست‌های گسترده بود تا اطمینان حاصل کنیم که تغییرات هیچ تأثیر منفی روی سرویس‌های حیاتی ما نخواهند داشت. در این پست قصد داریم در مورد فرآیندی که برای به‌روزرسانی طی کردیم و تجربه‌ها و مشکلاتی که پیش آمد بنویسیم.
https://techblog.torob.com/postgresql-upgrade-from-11-to-16-torob-experience-v62efb53gn6h

با سلام و احترام

جهت تولید یک محصول هوش مصنوعی به یک نفر "Data Engineer" با مشخصات زیر نیازمندیم.

مدرک تحصیلی: حداقل کارشناسی ارشد (فارغ التحصیلان دانشگاه های سراسری در اولویت هستند)

تخصص و تجارب کاری مورد نیاز:
- تجربه کار با APIهای توییتر و ابزارهای مشابه.
- آشنایی با زبان‌های برنامه‌نویسی نظیر Python برای جمع‌آوری و پردازش داده.
- تجربه کار با سیستم‌های مدیریت دیتابیس نظیر PostgreSQL، MongoDB، و یا سایر دیتابیس‌های مقیاس‌پذیر.
- تجربه کار با سیستم‌های استریم داده نظیر Kafka و Kafka Connect.
- توانایی ساخت و مدیریت شبکه‌های اجتماعی و تعاملات کاربران.
- تجربه کار با سیستم‌های مقیاس‌پذیر و مدیریت حجم بالای داده.
- آشنایی با ابزارهای بصری‌سازی داده و ارائه گزارش‌های تحلیلی.

نوع همکاری:
- حضوری (پاره وقت)
-  پروژه ای
(اولویت با جذب نیروی پاره وقت می باشد)

لطفا در صورت علاقه رزومه خود را به آیدی زیر در تلگرام ارسال نمایید.
@Semantasoft

در دنیای پر سرعت و داده‌محور امروز، مدیریت کارآمد منابع سیستمی در پایگاه‌های داده نقشی حیاتی در عملکرد و پاسخگویی برنامه‌های کاربردی ایفا می‌کند. PostgreSQL، به عنوان یکی از قدرتمندترین و محبوب‌ترین سیستم‌های مدیریت پایگاه داده رابطه‌ای متن‌باز، نیازمند توجه ویژه به بهینه‌سازی منابع، به خصوص مدیریت حافظه است.
https://yun.ir/74ed4a

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

یکی از امکانات خوبی که به پستگرس ۱۷ اضافه شده است، امکان گرفتن بکاپ های افزایشی یا incremental بکاپ است.
در این نسخه، شما با همان دستور pg_basebackup رایج پستگرس، یک بکاپ کامل از دیتابیس میگیرید ، سپس در مقاطع زمانی منظم مجددا همین دستور pg_basebackup را با پارامتر incremental و تعیین مکان پوشه بکاپ فول قبلی، اجرا میکنید تا یک بکاپ سریع و افزایشی ایجاد کنید که تنها تغییرات اخیر دیتابیس، در آن ذخیره خواهند شد و بنابراین بسیار سریع بوده، بار زیادی به دیتابیس تحمیل نمی‌کند.
سپس از دستور جدید pg_combinebackup استفاده میکنید که این دو را به یک بکاپ فول جدید تبدیل کنید تا در بکاپ افزایشی بعدی، این بکاپ فول جدید مبنای محاسبه تغییرات قرار گیرد.به همین سادگی ....
یک مثال خلاصه اما کامل راجع به این موضوع در آدرس زیر می‌توانید مشاهده کنید :
Read “Mastering Incremental Backups in PostgreSQL 17: A Step-by-Step“ by Umair Hassan on Medium: https://medium.com/@umairhassan27/mastering-incremental-backups-in-postgresql-17-a-step-by-step-89096167b31b
#پستگرس #postgres17

نگاهی به قالب‌های جدید ذخیره داده‌ها (به صورت خام)
آیا پادشاهی 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.)

اندر احوالات ما مهندسین داده ...

گفت احوالت چطور است؟
گفتمش عالی است
مثل حال گل
حال گل در چنگ چنگیز مغول
- قیصر امین‌پور-

یک پست و یک دنیا حرف .
آنچه در عکس فوق می‌بینید این است که بسیاری از منابع داده‌‌ای ما زیر یک ترابایت هستند(بالای نود درصد) و برای بسیاری از این‌ها نیاز به ابزارهای پیچیده پردازش و ذخیره کلان داده نداریم .‌

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

‌ این‌که کجا به ابزارهای پیچیده و گاها سنگین دنیای کلان‌داده، «نه» بگوییم ....

برای خواندن مقاله مفید و تحلیل منطقی و ظاهراً درست آقای علیرضا صادقی که عکس فوق هم از ایشان وام گرفته شده است به لینک زیر مراجعه کنید:
https://lnkd.in/dw2KAyQu

اخیرا که درگیر انتقال داده‌ها از پستگرس به YugaByteDB (یک نسخه مقیاس‌پذیر و منطبق بر پستگرس) بودیم، ابزار ساده اما بسیار مفیدی را پیدا کردم با نام pgsync که برای جابجایی جداول بین این دو دیتابیس کمک زیادی به ما کرد.
هر چند جای بهبود زیادی دارد -مثلا روابط و وابستگی بین جداول را تشخیص نمی‌دهد و اینکار را باید خودمان به صورت دستی در فایل تنظیمات آن وارد کنیم- اما کار با آن ساده و نتیجه کار کاملا رضایت بخش است .
هم می تواند اسکیما را بررسی کرده و جداول مقصد را بسازد و هم امکان انتقال داده ها در دسته های ده هزارتایی را دارد و هم می‌توان جداولی که باید ابتدا منتقل شوند را گروه‌بندی کرده و در فایل تنظیمات آن یعنی .pgsync.yml وارد کرد و به صورت گروه به گروه،‌ عملیات انتقال را انجام داد.
https://github.com/ankane/pgsync
#postgres #postgresql #yugabytedb #db_migration

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

در جستجوی ابزاری که بتواند به مانگو/پستگرس/ردیس/الستیک سرچ متصل شده، اجازه نوشتن کوئری لازم برای لود داده‌ها و طراحی فرم‌ها و یا جداولی برای نمایش و ویرایش و حتی ایجاد یک Workflow به ما بدهد به BudiBase رسیدیم که تا اینجا برای ما مشکل گشا بوده است.

https://budibase.com

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

اگر مباحث تخصصی مهندسی داده را به صورت جدی دنبال میکنید این لیست مخازن مفید این حوزه را از دست ندهید .
yun.ir/fv7165

در چند ماه گذشته از کافکا کلا سوئیچ کرده ام به ردپاندا بابت مسایلی مثل بهینه‌تر بودن مصرف منابع و طراحی مدرن‌تر یک سامانه پیام رسان مبتنی بر پروتکل کافکا با امکانات کامل و یکپارچه.
حتی قصد داشتم خلاصه ای از مشاهدات آقای Wu را در کنفرانس ۲۰۲۴ کافکا و داده های جریانی در اینجا به اشتراک بگذارم با این محوریت که کافکا به نقطه حساسی رسیده است و اگر نتواند تغییرات مورد انتظار بازار را برآورده کند، بازار را به رقبا واگذار خواهد کرد و خریدن شرکت‌هایی مثل WarpStream توسط کانفلوئنت که هزینه نگهداری یک کلاستر کافکا را بسیار کاهش می‌دهد، باز هم به تنهایی به کافکا کمک نخواهد کرد :
https://medium.com/@yingjunwu/kafka-has-reached-a-turning-point-649bd18b967f
اگر در حوزه مهندسی داده فعالیت میکنید توصیه میکنم مقاله فوق را با دقت مطالعه کنید. .
اما مهم‌تر ازین مسائل پایه در انتخاب یک ابزار مانند مصرف منابع و سادگی کار با آن و یکپارچه بودن ابزار و اکوسیستم، دید و ویژن شرکت ردپاندا برایم جذاب بود .
دیدی که باعث شد چند ماه پیش، پروژه Benthos را خریده و به RedPanda Connect اضافه کند. یک پروژه عالی، سبک و حرفه ای برای کارهای ETL .
اخیرا هم دیدم ردپاندا، نوع جدیدی از تاپیک‌ها برای کار مستقیم با Apache Iceberg ایجاد کند، به این ویژن و توجه به نیازهای نوین بازار، باور بیشتری دارم.‌
توصیه میکنم اگر با کافکا کار میکنید، ردپاندا را هم حتما تست کنید (نیاز به تغییر خاصی در کدها ندارید و دقیقا از دید برنامه و ابزار،مثل یک کلاستر کافکا عمل میکند).
مقاله زیر را هم که راجع به افزوده شدن این نوع جدید از تاپیک ها و ذخیره مستقیم پیام‌ها در آپاچی آیس‌برگ است را هم حتما نگاهی بیندازید ....
Read “Apache Iceberg Topics: Stream directly into your data lake“ by Redpanda Data on Medium: https://redpanda-data.medium.com/apache-iceberg-topics-stream-directly-into-your-data-lake-0250a8dfdd76

#مهندسی_داده #redpanda #kafka

‍ 🎉 آموزش ویدئویی جدید: راه‌اندازی انجین‌های توزیعی و تکرارشده در ClickHouse برای داده‌های تاکسی‌های نیویورک 🚖

وب سایت مهندسی داده که از بدو تاسیس خود در سال ۹۳ مبنای کار خود را گسترش مهارت‌ها و بینش‌های مهندسی در حوزه داده قرار داده است، به تازگی بخش آموزش‌ها و کارگاه‌های ویدئویی خود را راه اندازی کرده است که شاید بتواند تجربیات زیسته متخصصین این حوزه را به دوستان علاقه‌مند منتقل کند.

آدرس کانال یوتیوب مهندسی داده :

https://www.youtube.com/@irbigdata

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

📌 مشاهده ویدئو در یوتیوب:

https://www.youtube.com/watch?v=mgg4rSCCrGI

📌 آدرس ریپوزیتوری گیت‌هاب:

https://github.com/IrBigDataWorkShops/clickhouse_distributed

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

موضوعات پوشش‌ داده‌ شده:
۱. تنظیم انجین توزیعی با ۳ نود --> ۳ شارد و ۱ رپلیکا
۲. تنظیم جدول‌های توزیعی و تکرارشده با ۴ نود --> ۲ شارد و ۲ رپلیکا


🔹 ویژگی‌های کلیدی این آموزش :
- اجرای کوئری‌های توزیعی موازی
- تکرارپذیری برای تحمل خطا
- مدیریت متادیتا بدون نیاز به Zookeeper

برای علاقه‌مندان به یادگیری ClickHouse و کلان‌داده‌ها، توصیه می‌کنیم اگر با بخش توزیع‌شدگی و تکرار داده‌ها در این دیتابیس کار نکرده‌اید، این ویدئو را از دست ندهید!

آدرس کانال مهندسی داده در تلگرام : https://t.iss.one/bigdata_ir

گروه تخصصی مهندسی داده : https://t.iss.one/bigdata_ir_discuss

#clickhouse #distributed_engine #clickhouse_cluster

‍ معرفی 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

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


By : Alireza Sadeghi

What tools & technologies should aspiring data engineers pick to learn in 2025!?

https://www.pracdata.io/p/open-source-data-engineering-landscape-2025
Navigating and deciding what to learn in such a vast ecosystem of tools and services can feel overwhelming.

Here is my recommendation for a 𝙛𝙪𝙡𝙡-𝙨𝙩𝙖𝙘𝙠 𝙙𝙖𝙩𝙖 𝙚𝙣𝙜𝙞𝙣𝙚𝙚𝙧:

🌟 First and foremost, focus on 𝗺𝗮𝘀𝘁𝗲𝗿𝗶𝗻𝗴 𝘁𝗵𝗲 𝗳𝘂𝗻𝗱𝗮𝗺𝗲𝗻𝘁𝗮𝗹𝘀, as emphasised by other experts, while also striving to become expert in core technologies.

👉 𝗢𝗟𝗔𝗣 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲 𝗦𝘆𝘀𝘁𝗲𝗺𝘀
★ Master SQL and data warehouse data modeling techniques like the Star Schema. From technology perspective, most columnar MPP-based data warehouse technologies operate similarly.

★ If you get extra time master a specialised database in each OLAP category. Focus on how the data modeling is done in each engine:
★ 𝗖𝗹𝗶𝗰𝗸𝗛𝗼𝘂𝘀𝗲 for real-time OLAP
★ 𝗘𝗹𝗮𝘀𝘁𝗶𝗰𝗦𝗲𝗮𝗿𝗰𝗵 for search engines
★ 𝗖𝗮𝘀𝘀𝗮𝗻𝗱𝗿𝗮 for wide-column key-value engines
★ 𝗜𝗻𝗳𝗹𝘂𝘅𝗗𝗕 for time-series data

👉 𝗗𝗮𝘁𝗮 𝗟𝗮𝗸𝗲/𝗟𝗮𝗸𝗲𝗵𝗼𝘂𝘀𝗲
★ Understand the foundational concepts of data modeling on S3-compatible object stores (𝗦𝟯, 𝗠𝗶𝗻𝗜𝗢, etc), including the 𝗠𝗲𝗱𝗮𝗹𝗹𝗶𝗼𝗻 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲, partitioning, 𝗣𝗮𝗿𝗾𝘂𝗲𝘁 serialisation, and indexing options.
★ Familiarise yourself with Open Table Format technologies. 𝗗𝗲𝗹𝘁𝗮 𝗟𝗮𝗸𝗲, 𝗛𝘂𝗱𝗶, and 𝗜𝗰𝗲𝗯𝗲𝗿𝗴 all have the same foundation. Pick one to master.

👉 𝗗𝗮𝘁𝗮 𝗜𝗻𝘁𝗲𝗴𝗿𝗮𝘁𝗶𝗼𝗻
★ Here learning the fundamentals are really more vital. Master various data integration frameworks and paradigms, including ETL vs. ELT, incremental vs Batch, and the trade-offs involved.
★ Study event-driven architectures, log-based CDC, and get hands-on with 𝗞𝗮𝗳𝗸𝗮 𝗖𝗼𝗻𝗻𝗲𝗰𝘁 and 𝗗𝗲𝗯𝗲𝘇𝗶𝘂𝗺 plugins.

👉 𝗦𝘁𝗿𝗲𝗮𝗺 𝗣𝗿𝗼𝗰𝗲𝘀𝘀𝗶𝗻𝗴
★ Master 𝗔𝗽𝗮𝗰𝗵𝗲 𝗞𝗮𝗳𝗸𝗮. Similar products like Redpanda provide similar Kafka-compatible API.
★ Focus on learning 𝗦𝗽𝗮𝗿𝗸 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲𝗱 𝗦𝘁𝗿𝗲𝗮𝗺𝗶𝗻𝗴, and 𝗙𝗹𝗶𝗻𝗸 for real-time and unified processing.
★ Learn the fundamentals of data processing with 𝗣𝘆𝘁𝗵𝗼𝗻 𝗗𝗮𝘁𝗮𝗙𝗿𝗮𝗺𝗲𝘀, as many technologies in this space (like Pandas, Polars, Dask and Ibis) share similar foundations.

👉 𝗪𝗼𝗿𝗸𝗳𝗹𝗼𝘄 𝗢𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻
★ If you aim to work at a big tech company, mastering 𝗔𝗽𝗮𝗰𝗵𝗲 𝗔𝗶𝗿𝗳𝗹𝗼𝘄 for orchestration, and 𝗱𝗯𝘁 for data transformation is essential.

👉 𝗜𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲
★ If you are aiming high, gaining proficiency in 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 and 𝗗𝗼𝗰𝗸𝗲𝗿 for container orchestration is essential.

👉 𝗔𝗻𝗮𝗹𝘆𝘁𝗶𝗰𝘀 & 𝗩𝗶𝘀𝘂𝗮𝗹𝗶𝘀𝗮𝘁𝗶𝗼𝗻
★ Experiment with 𝗔𝗽𝗮𝗰𝗵𝗲 𝗦𝘂𝗽𝗲𝗿𝘀𝗲𝘁 or 𝗠𝗲𝘁𝗮𝗯𝗮𝘀𝗲 for building dashboards.
★ Learn the fundamental of distributed query processing using 𝗧𝗿𝗶𝗻𝗼 and 𝗦𝗽𝗮𝗿𝗸.
★ For single-node processing, 𝗗𝘂𝗰𝗸𝗗𝗕 is an excellent choice to learn.

https://www.linkedin.com/posts/ramtin-safadoust_podman-containers-devops-activity-7295831613400109056-pvga?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAEPHcQBIu5rXaFgo5F_hVlrlaE66EdlQzQ

چرا باید به جای Docker از Podman استفاده کنیم؟
نویسنده : رامتین صفادوست

اگه با کانتینرها کار می‌کنی، احتمالاً Docker برات آشناست. ولی تا حالا Podman رو امتحان کردی؟ یه موتور کانتینر سبک، امن و بدون نیاز به daemon که کلی مزیت داره، مخصوصاً از نظر امنیت و یکپارچگی با سیستم.

چندتا دلیل که چرا Podman داره محبوب‌تر می‌شه:

✅ بدون نیاز به Root – کانتینرها رو بدون دسترسی root اجرا کن و ریسک امنیتی رو کم کن.

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

✅ سازگار با Docker CLI – اگه از Docker استفاده می‌کردی، راحت می‌تونی مهاجرت کنی (حتی alias docker=podman هم جواب می‌ده!).

✅ دوست‌داشتنی برای Kubernetes – فقط با یه دستور می‌تونی YAML مورد نیاز برای K8s رو بسازی (podman generate kube).

✅ یکپارچه با systemd – اگه می‌خوای کانتینرها رو مثل یه سرویس مدیریت کنی، Podman بهترین گزینه‌ست.

اگه دنبال یه جایگزین امن‌تر و بهینه‌تر برای Docker هستی، حتماً Podman رو امتحان کن.


#Podman #Containers #DevOps #Kubernetes

پ.ن:
نظرات ذیل پست فوق در لینکدین را هم نگاهی بیندازید ...

پستگرس و نیازمندی‌های تحلیلی نوین

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

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

✅ ذخیره‌سازی ستونی: افزونه‌هایی مانند Hydra و pg_analytics امکان ذخیره‌سازی داده‌ها به‌صورت ستونی (Columnar) را فراهم کرده‌اند که یکی از ویژگی‌های کلیدی پایگاه‌های داده تحلیلی مدرن است.

✅ تطابق با Lakehouse و Iceberg: ترکیب PostgreSQL با معماری Lakehouse و ذخیره‌سازی مستقیم داده‌های تحلیلی در قالب Parquet با افزونه‌هایی مانند pg_mooncake، گامی دیگر در مسیر ارتقای آن به یک پایگاه داده تحلیلی جامع است.

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

راجع به Mooncake

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

اما با نصب pg_mooncake، می‌توان این داده‌های حجیم را مستقیماً در PostgreSQL ذخیره کرد، درحالی‌که داده‌ها در عمل در یک استوریج جداگانه، مانند MinIO، ذخیره می‌شوند. این افزونه امکان ذخیره داده‌ها را در قالب‌های Delta Lake (و به‌زودی Iceberg) به‌صورت فایل‌های Parquet فراهم می‌کند.

چگونه کار می‌کند؟

✅ داده‌ها در ظاهر از طریق PostgreSQL درج و کوئری می‌شوند.
✅ اما در پشت‌صحنه، داده‌ها در یک استوریج جداگانه مانند MinIO یا هر سرویس دیگری ذخیره می‌شوند.
✅ امکان ترکیب با ابزارهای پردازش داده‌های حجیم مانند DuckDB، Polars، Pandas و Spark وجود دارد.

مشاهده محل ذخیره‌سازی داده‌ها
برای یافتن مسیر دقیق فایل‌های مرتبط با جداول Mooncake، می‌توانید از کوئری زیر استفاده کنید:

SELECT * FROM mooncake.columnstore_tables;

خروجی این دستور مسیر دایرکتوری‌ای را نشان می‌دهد که داده‌ها به‌صورت Delta Lake (و در آینده Iceberg) در آن ذخیره شده‌اند و مستقیماً می‌توان آن‌ها را با Pandas، DuckDB، Polars یا Spark کوئری گرفت.

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

این پست آقای صادقی را هم در همین راستا می توانید مطالعه کنید.
https://www.linkedin.com/feed/update/urn:li:activity:7296864653039591424/

🚀 تبدیل PostgreSQL به یک دیتابیس HTAP با یک راهکار ساده و موثر!

🔍 این مطلب صرفاً برای اشاره به یک موج جدید در حوزه دیتابیس‌ها نوشته شده است—ایده‌ای که نشان می‌دهد می‌توان با ترکیب ابزارهای حرفه‌ای متن‌باز، سیستم‌هایی با توانایی بالا ساخت، بدون نیاز به توسعه یک موتور پایگاه داده از صفر!

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

✅ ذخیره‌سازی داده‌ها به‌صورت ستونی: داده‌های PostgreSQL را در قالب ستونی ذخیره کنم تا برای اجرای کوئری‌های پیچیده و سنگین تحلیلی بهینه شود. چه گزینه‌ای بهتر از Parquet؟

✅ مدیریت و سازماندهی داده‌ها: وقتی حجم داده‌ها زیاد شود و تعداد فایل‌های Parquet بالا برود، چطور آن‌ها را مدیریت کنم؟ اینجاست که Open Table Format‌هایی مثل Apache Iceberg به کمک می‌آیند، چون دقیقاً برای همین منظور طراحی شده‌اند.

✅ انتقال داده از PostgreSQL به این ساختار: سریع‌ترین روش بدون نیاز به یک ETL پیچیده چیست؟ می‌توانیم یک Read Replica از PostgreSQL بسازیم که خودش تغییرات را ارسال کند و این تغییرات را مستقیماً در قالب Parquet و با استاندارد Iceberg ذخیره کنیم.

✅ اجرای سریع کوئری‌ها: حالا چطور روی این داده‌ها کوئری اجرا کنم؟ یکی از بهترین گزینه‌هایی که در سال‌های اخیر بلوغ بالایی پیدا کرده و از Iceberg و Parquet پشتیبانی می‌کند، DuckDB است! بنابراین می‌توانیم مستقیماً روی Iceberg کوئری بزنیم و نتایج را سریع دریافت کنیم.

✅ ایجاد یک واسط SQL سازگار با PostgreSQL: برای اجرای کوئری‌ها توسط کاربران، نیاز به یک لایه تبدیل SQL داریم که درخواست‌های PostgreSQL را به گرامر DuckDB تبدیل کند. خوشبختانه، گرامر DuckDB تا حد زیادی با استاندارد SQL سازگار است، بنابراین این مرحله هم به سادگی قابل انجام است.

🎯 نتیجه؟ به همین راحتی، PostgreSQL را به یک HTAP (دیتابیس ترکیبی تحلیلی/تراکنشی) تبدیل کردیم!

💡 اما این پایان ماجرا نیست!
دیتابیسی به نام BemiDB دقیقاً بر اساس همین معماری در حال توسعه است. این پروژه هنوز در ابتدای مسیر قرار دارد و در حال حاضر انتقال داده‌ها به‌صورت آفلاین انجام می‌شود. اما این تنها یک شروع است و مسیر رشد و تکامل آن می‌تواند بسیار هیجان‌انگیز باشد!
Bemi

🔥 و نکته‌ی هیجان‌انگیز؟
تست‌های اولیه روی دیتاست استاندارد TPC-H نشان داده که در برخی پرس‌وجوها، سرعت اجرای کوئری‌ها تا ۲۰۰۰ برابر سریع‌تر از PostgreSQL شده است! 😯🚀

📌 به نظر میرسد که ترکیب ابزارهای متن‌باز قدرتمند می‌تواند راهکارهایی نوآورانه برای چالش‌های دنیای دیتابیس ایجاد کند!


آدرس پروژه BemiDB :
https://github.com/BemiHQ/BemiDB

‍ در دنیای مهندسی داده که سرعت و کارایی اهمیت زیادی دارد، استفاده از ابزارهای نوین مدیریت پکیج‌ها و محیط‌های مجازی بسیار حیاتی است. uv به عنوان یک مدیر پکیج پایتون سریع و بهینه، مزایای قابل توجهی نسبت به روش‌های سنتی مانند pip و virtualenv ارائه می‌دهد.

ویژگی‌های کلیدی uv 🚀

⚖️ جایگزین بدون دردسر – کاملاً سازگار با pip، pip-tools، virtualenv و دیگر ابزارهای مدیریت پکیج.

⚡️ سرعت خیره‌کننده – بین ۱۰ تا ۱۰۰ برابر سریع‌تر از pip، pip-compile و pip-sync.

💾 بهینه در مصرف فضا – با استفاده از کش جهانی، وابستگی‌های تکراری را حذف کرده و فضای دیسک را ذخیره می‌کند.

🐍 نصب آسان و منعطف – قابل نصب از طریق curl، pip یا pipx بدون نیاز به Rust یا حتی نصب بودن Python.

🧪 تست‌شده در مقیاس بالا – عملکرد uv با ۱۰,۰۰۰ پکیج برتر PyPI بررسی و تأیید شده است.

🖥 سازگاری با تمام پلتفرم‌ها – کاملاً قابل اجرا روی macOS، Linux و Windows.

🔩 مدیریت پیشرفته وابستگی‌ها – امکان کنترل نسخه‌های وابستگی، حل تداخل‌ها و استفاده از استراتژی‌های مختلف نصب.

⁉️ خطاهای شفاف و قابل فهم – بهترین سیستم مدیریت خطا برای رفع سریع مشکلات توسعه‌دهندگان.

🤝 پشتیبانی از قابلیت‌های مدرن پایتون – نصب‌های قابل ویرایش، وابستگی‌های Git، URLهای مستقیم، مدیریت وابستگی‌های محلی و موارد دیگر.

🚀 ابزار همه‌کاره – ترکیبی از امکانات pip، pipx، poetry، pyenv، twine و ابزارهای دیگر در یک راهکار واحد.

🛠 مدیریت پیشرفته پروژه و اسکریپت‌ها – امکان اجرای اسکریپت‌ها، مدیریت نسخه‌های پایتون و کار با متادیتای وابستگی‌ها.

🗂 لاک‌فایل عمومی و پایدار – یکپارچه‌سازی وابستگی‌ها در پروژه‌های مختلف و تسهیل مدیریت نسخه‌ها.

🏢 پشتیبانی از ورک‌اسپیس‌ها – مناسب برای پروژه‌های مقیاس‌پذیر و چندبخشی، مشابه Cargo-style.


نمونه‌هایی از استفاده uv:

# نصب یک پکیج در محیط مجازی:

uv pip install pandas

# ایجاد یک محیط مجازی جدید:

uv venv .venv

# همگام‌سازی پکیج‌ها با فایل pyproject.toml:

uv pip sync

اگر به دنبال سرعت، کارایی و مدیریت بهتر وابستگی‌ها در پروژه‌های مهندسی داده هستید، uv گزینه‌ای ایده‌آل برای جایگزینی روش‌های سنتی است. 💡🔥

منابعی برای مطالعه بیشتر :

- https://www.kdnuggets.com/new-python-package-manager
- https://www.saaspegasus.com/guides/uv-deep-dive/
- https://codemaker2016.medium.com/introducing-uv-next-gen-python-package-manager-b78ad39c95d7

- https://docs.astral.sh/uv/getting-started/first-steps/

عکس پست از منبع اول و بخش لاتین از منبع سوم برداشته شده است.