افزوده شدن SQL به الاستیک سرچ - https://is.gd/o1OSJg
معرفی و آموزش
, #SQL, #الاستیک_سرچ, #داشبوردهای_مدیریتی
الاستیک سرچ به عنوان یکی از قویترین موتورهای جستجوی متنی، توانسته است رتبه هشتم را در بین بانک‌های اطلاعاتی محبوب دنیا به خود اختصاص دهد. این موتور جستجو که علاوه بر جستجوی متن، امکان مقیاس‌پذیری افقی را هم به صورت درون‌ساخت داراست و حجم بالای داده‌ها را به راحتی مدیریت می‌کند، با افزودن امکاناتی...

‍ معرفی سایت DataNerd.tech؛ مرجعی برای تحلیل مهارت‌ها و حقوق مشاغل داده‌ای

سایت DataNerd.tech به عنوان یک مرجع تحلیلی📊، با هدف کمک به متخصصان داده ایجاد شده است تا بتوانند با آگاهی بیشتر، مسیر شغلی خود را انتخاب کنند.

این پلتفرم با جمع‌آوری روزانه حدود ۶۵۰۰ آگهی شغلی از نتایج جستجوی گوگل و تحلیل آن‌ها از طریق پردازش زبان طبیعی (NLP)، پرطرفدارترین مهارت‌ها و متوسط حقوق هر موقعیت شغلی را ارائه می‌دهد.

آدرس سایت : https://datanerd.tech

در بخش مربوط به مهندسین داده، مهارت‌هایی مانند #SQL، #Python، #AWS، #Azure و #Spark جزو پرجستجوترین مهارت‌ها هستند. این داده‌ها به کاربران کمک می‌کند تا بدانند چه مهارت‌هایی در بازار کار بیشتر مورد توجه قرار دارند و بر چه زمینه‌هایی تمرکز بیشتری داشته باشند. همچنین سایت دارای بخشی برای مشاهده روند تغییرات محبوبیت مهارت‌ها در طول زمان است که تصویری دقیق‌تر از تحولات بازار ارائه می‌دهد. 📈

بر اساس تحلیل‌های ارائه‌شده در DataNerd.tech، پردرآمدترین مشاغل 💵 به ترتیب شامل مهندس نرم‌افزار، مهندس یادگیری ماشین و مهندس داده هستند.

از سوی دیگر، گران‌ترین مهارت‌های 💎 بازار عبارتند از #Scala، #Spark، #Snowflake، #Java و #Python که توجه به آن‌ها می‌تواند در افزایش فرصت‌های شغلی و درآمد تأثیر قابل توجهی داشته باشد.

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


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


#مهندسی_داده #تحلیل_داده #علم_داده #بازار_کار_داده #هوش_مصنوعی #Data_Engineering #Data_Science #Data_Analytics #Machine_Learning #Career_Growth

‍ معرفی DuckLake: ساده‌سازی Lakehouse با قدرت SQL

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

🧠 این همان فلسفه‌ی #Lakehouse است:

ترکیب بهترین ویژگی‌های Data Lake (انعطاف و مقیاس‌پذیری) و Data #Warehouse (ساختارمندی و قابلیت تحلیل)

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

اما : چرا وقتی به هر حال به یک دیتابیس نیاز داریم (برای کاتالوگ)، از ابتدا همه چیز را در SQL مدیریت نکنیم؟

📢 امروز #DuckDB با معرفی #DuckLake، پاسخی جسورانه و منطقی به این سوال داده است.

✅ اما سوال اصلی : DuckLake چیست؟

استاندارد DuckLake یک فرمت Open Table جدید برای معماری Lakehouse است که:

داده‌ها را در قالب‌های باز مانند Parquet در Blob Storage ذخیره می‌کند؛

اما تمام فراداده‌ها (metadata)، snapshotها، schemaها و آمار را در یک پایگاه داده SQL ساده (مثل PostgreSQL یا خود DuckDB) مدیریت می‌کند.

🔍 چرا DuckLake یک تغییر بنیادین است؟

1. سادگی واقعی

برخلاف Iceberg و Delta که برای یک append ساده، باید چندین فایل JSON و Avro ایجاد یا به‌روز کرد، در DuckLake همه چیز فقط چند query ساده SQL است.
نیازی به لایه‌ی اضافه‌ی catalog server یا فایل‌های اضافی نیست. فقط یک دیتابیس و فایل‌های Parquet.

2. مدیریت تراکنش‌پذیر (ACID) واقعی

تغییرات در جدول‌ها، snapshotها و آمار ستون‌ها در یک تراکنش واحد SQL انجام می‌شود. این یعنی:
📌atomic commitها؛
📌پشتیبانی از تغییرات پیچیده و multi-table؛
📌 بدون ترس از ناسازگاری فایل‌ها در blob storage.

3. سازگاری، مقیاس‌پذیری و سرعت
می‌توانید DuckLake را با DuckDB روی لپ‌تاپ اجرا کنید یا با PostgreSQL روی کلاود.
برخلاف ساختارهای فایل‌محور، پردازش‌ها سریع‌تر، قابل کش‌شدن و قابل مشاهده‌اند.
محدود به هیچ vendor خاصی نیستید؛ جابه‌جایی آسان است.

🏗 یک نگاه به معماری DuckLake:

📁 داده‌ها → Parquet روی S3 یا هر blob store

📚 فراداده → SQL Tables روی DuckDB/PostgreSQL/...

🔁 عملیات → فقط SQL transactions ساده با DuckDB

🧠 چرا مهم است؟

در حالی که بسیاری از معماری‌های داده در مسیر «Lakehouse» پیچیدگی‌های جدیدی اضافه می‌کنند، DuckLake مسیر را به عقب برمی‌گرداند و از یک حقیقت ساده دفاع می‌کند:

وقتی که به هر حال از یک دیتابیس استفاده می‌کنیم، چرا بقیه‌ی بخش‌ها را هم در همان قالب SQL مدیریت نکنیم؟

📌 نتیجه‌گیری

استاندارد DuckLake نه فقط یک فرمت جدید، بلکه بازاندیشی دوباره‌ای است در طراحی Lakehouse — مبتنی بر اصل «سادگی، مقیاس‌پذیری، سرعت». اگر به دنبال آینده‌ای پایدارتر، قابل نگهداری‌تر و بدون vendor lock-in برای lakehouse هستید، DuckLake را جدی بگیرید.

📎 مطالعه‌ی کامل مقاله: https://duckdb.org/2025/05/27/ducklake.html

#DuckDB #DuckLake #DataEngineering #Lakehouse #OpenFormats #SQL #Parquet #PostgreSQL

شروعی حرفه‌ای برای ورود به دنیای مهندسی داده – رایگان و بین‌المللی🎓

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

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

👨‍🏫 برگزارکننده: Zach Wilson

مؤسس DataExpert.io و از شناخته‌شده‌ترین چهره‌های حوزه داده با بیش از ۱ میلیون دنبال‌کننده در شبکه‌های اجتماعی.

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


🏫 درباره بوت‌کمپ:

بوت‌کمپ ۶ هفته‌ای "Community Edition" با هدف توانمندسازی علاقه‌مندان به مهندسی داده، به صورت رایگان و با تمرکز بر مهارت‌های کاربردی برگزار می‌شود.

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


🧠 سرفصل‌های آموزشی:

📚 مدل‌سازی داده‌های بعدی و واقعی – طراحی ساختارهای تحلیلی پیشرفته

📚 پردازش داده‌های کلان با سرعت بالا - Apache Spark و PySpark

📚 ساخت پایپ‌لاین‌های بلادرنگ و مدیریت جریان داده - Apache Flink و Kafka

📚 الگوهای تحلیلی و طراحی شاخص‌های کلیدی عملکرد (KPI)

📚 کیفیت داده و مستندسازی حرفه‌ای مانند Airbnb

📚 مصورسازی داده با Tableau و ارائه اثرگذار یافته‌ها

📚نگهداری و بهبود پایپ‌لاین‌های داده‌ای در محیط واقعی


🎯 چرا این بوت‌کمپ ارزشمند است؟

🔹 نگاه عملیاتی و واقعی به مسائل مهندسی داده

🔹 طراحی شده توسط تیمی با تجربه بین‌المللی و پروژه‌های کلان

🔹 یادگیری مبتنی بر سناریوهای واقعی شغلی

🔹 مناسب برای افرادی که به‌دنبال مهاجرت شغلی، ارتقای جایگاه کاری یا ورود به بازارهای جهانی هستند

🔹 امکان تعامل با جامعه جهانی مهندسان داده در Discord

🔹 دریافت مدرک پایان دوره به‌صورت رسمی


📥 مراحل ثبت‌نام:

ثبت‌نام رایگان در سایت: learn.dataexpert.io

دریافت هندبوک و تمرین‌ها: https://github.com/DataExpert-io/data-engineer-handbook

عضویت در کامیونیتی و گروه پشتیبانی در دیسکورد: لینک عضویت

ارسال تمرین‌های هفتگی – برای حفظ نظم و یادگیری تدریجی

📌 تا امروز بیش از ۵۰ هزار نفر از سراسر دنیا ثبت‌نام کرده‌اند

🎯 زک ویلسون پیش‌بینی کرده تنها حدود ۵۰۰ نفر به پایان مسیر و دریافت گواهی می‌رسند

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

جزو ۱٪ افراد مصمم باش!

#بوتکمپ_داده #مهندسی_داده #DataEngineering #ApacheSpark #Flink #Kafka #SQL #Python #DataQuality #Tableau #آموزش_کاربردی #مدرک_بین‌المللی #ZackWilson #DataExpert #دوره_رایگان #DataCareer

‍ از استانداردسازی تا ساده‌سازی: آینده‌ی 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

‍ چرا بسیاری از تیم‌ها ORM را کنار می‌گذارند و سراغ SQL خام می‌روند؟

اخیرا در مدیوم با تعداد زیادی از مقاله‌ها مواجه می‌شوم که یک پیام مشترک دارند:

🔁 «ما #ORM را کنار گذاشتیم و به #SQL خام مهاجرت کردیم — و دیگر برنمی‌گردیم.»

نکته جالب اینجاست که این تصمیم‌ها معمولاً از سر عشق به SQL گرفته نشده‌اند، بلکه از دل دردسرهای #ORM زاده شده‌اند.

در چند مقاله‌ی اخیر که مطالعه کردم، تیم‌های مختلفی با تکنولوژی‌های مختلف (از #Java + #Postgres گرفته تا #Go + #SQLAlchemy) تجربه‌ی مهاجرت از ORM را به اشتراک گذاشته‌اند — نه فقط برای بهبود سرعت، بلکه برای بازگشت به شفافیت، کنترل و عقلانیت.


⚠️مشکل کجا بود؟ چرا ORM جوابگو نبود؟

اگرچه ORM در شروع پروژه‌ها خیلی مفید است (خصوصاً برای CRUDهای سریع و MVPها)، اما با رشد سیستم، مشکلاتی کم‌کم خود را نشان می‌دهند:

🧨معضل N+1 Query

کوئری‌هایی که ساده به نظر می‌رسند، در باطن ده‌ها یا صدها درخواست اضافه تولید می‌کنند.

🌀 کدهای پیچیده اما غیرشفاف

برای کوئری‌های پیچیده‌تر مثل Window Function، CTE یا Join چندجدولی، باید به انواع annotationها، chainهای مبهم، یا زبان‌های خاص ORM (مثل JPQL) متوسل شد — که در نهایت باز هم می‌رسیم به نوشتن SQL، فقط با دردسر بیشتر.

🔍 ضعف در دیباگ و پروفایلینگ

در ORM، به‌سختی می‌شود فهمید دقیقاً چه کوئری‌ای به دیتابیس رفته. این یعنی دیباگِ کندی‌ها تقریباً کورکورانه است.

💡 ناسازگاری با مدل واقعی داده‌ها

دیتابیس با row و index و join کار می‌کند؛ ORM با کلاس و رابطه شی‌گرایانه. این تطبیق، به‌ویژه در سیستم‌های پیچیده، منجر به کدهایی می‌شود که بیشتر شبیه «جنگیدن با ORM» هستند.


🎯چرا SQL خام یک تفاوت واقعی ایجاد کرد؟

بعد از مهاجرت، همه تیم‌ها روی این دستاوردها تأکید داشتند:

✅ کنترل کامل

می‌دانیم چه کوئری نوشته‌ایم، چه زمانی اجرا می‌شود، و چگونه می‌توان آن را بهینه کرد.

✅ شفافیت

کوئری واضح است، بدون «جادوی مخفی». این یعنی همه تیم — از جونیور تا لید — متوجه می‌شود چه اتفاقی می‌افتد.

✅ هماهنگی بیشتر با منطق دامنه

به‌جای تعریف business logic در repository و annotation، همه‌چیز در لایه‌های مشخص خدماتی و use-case محور قرار می‌گیرد.

✅ استفاده کامل از قدرت دیتابیس

ویژگی‌هایی مثل Window Function، CTE، JSONB و Partial Index که در ORM اغلب یا پشتیبانی نمی‌شوند یا با پیچیدگی زیاد ممکن‌اند، در SQL خام به‌راحتی قابل استفاده‌اند.

📌نگهداری و مقیاس‌پذیری چطور مدیریت شد؟

برای جلوگیری از بی‌نظمی، تیم‌ها:

- کوئری‌ها را در فایل‌های جدا و نسخه‌دار نگه داشتند

- از template و query loaderهای سبک استفاده کردند

- روی هر کوئری تست (یا حداقل EXPLAIN) نوشتند

- قواعد ساده ولی سخت‌گیرانه‌ای برای امنیت (مثل پارامترگذاری) اعمال کردند

در نتیجه، برخلاف تصور اولیه، نگهداشت SQL خام هم قابل مدیریت و حتی لذت‌بخش شد.

💡کی باید ORM را کنار گذاشت؟

تجربه‌ی مشترک تیم‌ها نشان می‌دهد:

✅برای پروژه‌های کوچک، MVPها یا پنل‌های ادمین، ORM عالی است.

✅اما در پروژه‌های داده‌محور، با ترافیک بالا، کوئری‌های پیچیده و نیاز به کنترل عملکرد، ORM به‌جای کمک، تبدیل به مانع می‌شود.


📚 جمع‌بندی

بسیاری از ما با ORMها بزرگ شده‌ایم اما آیا هنوز ORM بهترین ابزار ماست؟ یا فقط آسان‌ترین است؟

در دنیایی که عملکرد، شفافیت و کنترل ارزش بیشتری از سرعت اولیه دارند، شاید وقت آن است که دوباره به SQL خام یا ترکیب آن با ORm فکر کنیم — این بار با بلوغ بیشتر و ابزارهای بهتر.

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

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

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

‍ وقتی 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