‍ آغاز به کار رسمی مدرسه مهندسی داده سپهرام

با افتخار اعلام می‌کنم که وب‌سایت https://sepahram.ir به عنوان اولین مدرسه کاربردی مهندسی داده در ایران راه‌اندازی شد. هدف ما ارائه آموزش‌های عملی و پروژه‌محور در حوزه #مهندسی_داده برای جامعه فارسی‌زبان است.

🔰 شروع فعالیت مدرسه با برگزاری دوره نوین:
✨ مبانی مهندسی داده ✨


در این دوره، مفاهیم پایه و ابزارهای اصلی مهندسی داده به شکلی کاملاً عملی آموزش داده می‌شود، شامل:

🗄 پایگاه داده‌ها و طراحی اولیه با #PostgreSQL

🛠 آشنایی با #Airflow برای مدیریت و زمان‌بندی جریان‌های داده

⚡️ پردازش داده‌های عظیم با #ApacheSpark

🔄 پردازش جریان‌های داده در #Kafka

📊 آشنایی عملیاتی با #ClickHouse برای تحلیل سریع و بلادرنگ داده‌ها

🧊 کار با #ApacheIceberg به عنوان نسل جدید فرمت‌های جدولی و مدیریت داده در مقیاس بزرگ


🎯 برای تضمین یادگیری گام‌به‌گام و مؤثر:

- هر درس شامل چند آزمون کوتاه و مفهومی است.

- برای دریافت گواهینامه پایان دوره، انجام و تحویل یک پروژه عملی و کاربردی الزامی است. جزئیات این پروژه در صفحه دوره ذکر شده است.


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

📌 شناسه پشتیبانی: @sepahram_ir

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

🔗 جزئیات بیشتر و ثبت‌نام:

https://sepahram.ir/courses/intro-to-data-engineering

کانال رسمی سپهرام :

https://t.iss.one/sepahram_school

‍ از CQRS تا یک سامانه حافظه‌محور : داستان بازطراحی Tudum در نتفلیکس

الگوی #CQRS و معماری‌های event-driven ابزارهای قدرتمندی برای مقیاس‌پذیری هستند. اما وقتی تأخیر بین «نوشتن» و «نمایش تغییر» زیاد شود، به‌خصوص برای سناریوهای real-time مثل preview محتوا، همین الگوها می‌توانند به گلوگاه تبدیل شوند.

📌 داستان Tudum (وب‌سایت طرفداران نتفلیکس) دقیقاً ناظر به همین مساله است.

⚡️ معماری اولیه: #CQRS + #Kafka + #Cassandra

نتفلیکس وب‌سایت طرفداران Tudum را در ۲۰۲۱ راه‌اندازی کرد تا محتوای جانبی مرتبط با برنامه‌ها را به کاربران ارائه دهد و ویراستاران بتوانند تغییرات را پیش‌نمایش کنند.

داده‌ها ابتدا از CMS به سرویس ingestion می‌رفت، پردازش و روی #Kafka منتشر می‌شد، سپس در #Cassandra ذخیره و با near cache سریع‌تر به سرویس ساخت صفحات می‌رسید تا صفحات HTML برای کاربران ساخته و نمایش داده شوند. مسیر انتشار و نمایش داده‌ها جدا شد تا مقیاس‌پذیری بهتر شود، اما مشکل تأخیر cache همچنان باقی بود.


⚡️مزایا؟ تفکیک write و read و امکان scale مستقل.

⚠️ مشکل؟ ⏳ تغییرات محتوا در CMS با تأخیر زیاد روی سایت دیده می‌شد.

🔍 دلیل اصلی این تاخیر طبق گزارش نتفلیکس:

🔹کش با یک چرخه‌ی refresh به‌روزرسانی می‌شد.

🔹مثلاً اگر ۶۰ کلید داشتی و هر ثانیه یکی refresh می‌شد، تغییرات حداقل ۶۰ ثانیه بعد قابل مشاهده بود.

🔹با رشد محتوا، این زمان حتی به چند ده ثانیه می‌رسید.

🔹 برای نویسندگان و ویراستاران، این یعنی تجربه‌ی preview عملاً بی‌فایده بود.


🚀 بازطراحی: RAW Hollow به‌جای Kafka و Cassandra

به جای وصله‌پینه روی کش یا افزایش سرعت Kafka، تیم نتفلیکس یک مسیر جدید انتخاب کرد: جایگزینی کل CQRS pipeline با یک دیتابیس in-memory به نام RAW Hollow.

آدرس پروژه : https://hollow.how

ویژگی‌ها:

🔰کل dataset در حافظه‌ی هر process ذخیره می‌شود → latency بسیار پایین.

🔰پشتیبانی از strong read-after-write consistency → تغییرات بلافاصله قابل مشاهده‌اند.

🔰فشرده‌سازی Hollow حجم داده را تا ۲۵٪ نسخه‌ی اصلی کاهش می‌دهد → کل داده جا می‌شود.

🔰معماری ساده‌تر: حذف Kafka، Cassandra و cache → کمتر شدن لایه‌ها = کمتر شدن delay.

📊 نتایج برای Tudum

✨تأخیر در نمایش تغییرات: از چند ده ثانیه → به چند ثانیه.

✨زمان ساخت صفحه: از ~۱.۴s → به ~۰.۴s.

✨تجربه‌ی preview برای نویسندگان روان شد.

✨معماری تمیزتر و بدون گره‌های زائد.



💬 واکنش‌ها در Hacker News و Reddit

انتشار این تجربه بحث‌های زیادی ایجاد کرد:

🎯بعضی گفتند مشکل صرفاً cache invalidation بود و می‌شد ساده‌تر حل کرد.

🎯عده‌ای این تغییر را over-engineering دانستند برای سایتی شبیه یک بلاگ.

🎯گروهی دیگر تأکید داشتند که با مقیاس و نیاز به personalization نتفلیکس، این تصمیم منطقی است.

🎯برخی هم انتقاد کردند که مسئله‌ی کوچک به شکل یک چالش بزرگ بیان شده است.

🔑 جمع‌بندی:

پیچیدگی تکنیکی همیشه کارآمد نیست؛ Tudum نشان داد که حذف لایه‌های اضافی و نگهداری داده‌ها در حافظه می‌تواند تجربه‌ی کاربری سریع‌تر و واقعی‌تری فراهم کند. انتخاب معماری همواره یک trade-off بین سرعت و سازگاری است، و در این مورد نتفلیکس سرعت را در اولویت گذاشت.

مدرسه مهندسی داده سپهرام : @sepahram_school

مقاله اصلی : https://www.infoq.com/news/2025/08/netflix-tudum-cqrs-raw-hollow

‍ فیلم آموزش عملی Kafka در یوتیوب – از نصب تا اجرای اولین Producer و Consumer

دوستانی که تاکنون با کافکا کار نکرده‌اند و می‌خواهند به صورت سریع و کاربردی با آن آشنا شوند، این دوره و به ویژه جلسات چهارم و پنجم برای شماست!

در جلسه چهارم 🕑، ما با مفاهیم اصلی #Kafka آشنا شدیم و یاد گرفتیم چگونه آن را به صورت لوکال و بدون Docker نصب و راه‌اندازی کنیم 🖥.

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

✨ مفاهیم اصلی Kafka

⚡️بروکرها، تاپیک‌ها و پارتیشن‌ها

⚡️پرودیوسرها و کانسیومرها

⚡️عملکرد #Kafka در پیام‌رسانی با توان بالا و توزیع‌شده

💻 تمرین‌های عملی با خط فرمان

⚡️راه‌اندازی بروکر Kafka به صورت محلی

⚡️ایجاد تاپیک‌ها، ارسال پیام با پرودیوسر و دریافت آن با کانسیومر

⚡️مشاهده مسیر پیام‌ها و رفتار توزیع آن‌ها در پارتیشن‌ها

🐍 تمرین‌های عملی با پایتون

⚡️نوشتن اسکریپت‌های ساده پرودیوسر و کانسیومر

⚡️درک توزیع پیام‌ها و گروه‌های کانسیومر

⚡️مشاهده حفظ ترتیب پیام‌ها در هر پارتیشن


✅ دستاوردهای کلیدی

🔰توانایی راه‌اندازی Kafka به صورت لوکال

🔰تجربه عملی در ارسال و دریافت پیام‌ها

🔰درک پارتیشن‌ها و گروه‌های کانسیومر

🔰پایه‌ای محکم برای ساخت pipelineهای داده real-time و مقیاس‌پذیر


در جلسه دوم 🕑، نصب و راه‌اندازی Kafka با Docker و کار با انواع UI موجود در بازار آموزش داده شد. همچنین Redpanda به عنوان یک جایگزین Kafka معرفی شد. تمرین‌های عملی شامل:

🔰خواندن خودکار فایل‌ها و ارسال آن‌ها به Kafka با Redpanda Connect

🔰راه‌اندازی یک پایپ‌لاین CDC ساده برای انتقال داده‌های درج شده و آپدیت شده در Postgres به Kafka


🎥 لینک آموزش در یوتیوب – کانال مدرسه مهندسی داده سپهرام:
https://www.youtube.com/watch?v=hLT0xOEmNQ8


📚 لیست سایر دوره‌های مدرسه مهندسی داده سپهرام:
https://sepahram.ir/courses/


💡 اگر قصد یادگیری مهندسی داده را دارید:

- هم اکنون می‌توانید سرفصل‌های دوره را مرور کنید

- برای دریافت کد تخفیف ثبت نام، به آی‌دی @sepahram_ir در تلگرام پیام بدهید

‍ کافکا 4.1 و قابلیت جدید Share Groups: نزدیک شدن Kafka به یک صف توزیع شده واقعی

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

🎯 راهکار Kafka 4.1 با KIP-932

در نسخه ۴.۱ و با معرفی KIP-932، یک لایه مدیریتی جدید اضافه شد که پیام‌ها را از پارتیشن‌ها دریافت می‌کند و سپس آن‌ها را به کانسیومرهای اشتراکی تحویل می‌دهد. این لایه، مدیریت کامیت‌ها و تخصیص پیام‌ها را خودش انجام می‌دهد و به Kafka اجازه می‌دهد بدون تغییر معماری اصلی، رفتاری مشابه صف‌های توزیع‌شده واقعی ارائه دهد. قبلا مدیریت دریافت پیام‌ها با خود کانسیومرها بود و هر کانسیومر هنگام جوین شدن به یک گروه مصرف کننده و بعد از عملیات Rebalance، پارتیشن‌هایی که به او اختصاص داده شده بود را دریافت می‌کرد و مستقیما به لیدر آن پارتیشن‌ها پیام می فرستاد. الان پیام ها از این لایه جدید دریافت می‌شوند.

🟢نحوه کار Share Groups

🔰معرفی Share Group Coordinator در بروکرها

🔰مدیریت و پیگیری وضعیت پردازش پیام‌ها برای هر کانسیومر

🔰تخصیص پیام‌ها به کانسیومرها به‌صورت اشتراکی

🔰مدیریت acknowledgment پیام‌ها به‌صورت فردی


🟠ویژگی‌های اصلی Share Groups

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

🔰تایید acknowledgment فردی → پردازش دقیق‌تر و مدیریت خطاها

🔰پردازش موازی → افزایش کارایی و throughput سیستم


❓ وضعیت فعلی در Python

تا نسخه ۴.۱، کلاینت‌های Python مانند confluent-kafka و kafka-python از Share Groups پشتیبانی نمی‌کنند.

در حال حاضر فقط کلاینت Java از این ویژگی بهره‌مند است و انتظار می‌رود در آینده به سایر کلاینت‌ها اضافه شود.


🚀 سایر بهبودهای نسخه ۴.۱ برای توسعه‌دهندگان

✨ ارتقای مکانیزم Kafka Streams (KIP-1071) → پروتکل rebalance جدید برای کاهش زمان بازتخصیص و رفتار پیش‌بینی‌پذیرتر وظایف

✨ امنیت بهتر با JWT (KIP-1139) → پشتیبانی از jwt_bearer برای احراز هویت امن بدون credential ثابت

✨ بهبود متریک‌ها و مانیتورینگ (KIP-877 & KIP-1109) → استانداردسازی متریک‌ها، اضافه شدن تگ‌های مفید و اصلاح نام تاپیک‌ها

✨ امکان Shutdown نرم‌تر کانسیومرها (KIP-1092) → جلوگیری از ریبالانس غیرضروری هنگام توقف کانسیومرها

✨ رفع deadlock در send callbackها (KIP-1118) → بهبود ثبات تولیدکننده پیام

✨ مدیریت شفاف‌تر تراکنش‌ها (KIP-1050) → دسته‌بندی بهتر خطاها و مدیریت هوشمندتر تراکنش‌ها


💡 نسخه ۴.۱ Kafka با این تغییرات، تجربه کار با پردازش موازی، صف‌گونه و Event-Driven را بهبود داده و ابزارهای توسعه‌دهنده را برای مدیریت امنیت، متریک‌ها و rebalance ساده‌تر و قابل اعتمادتر کرده است.

✅ پی‌نوشت: دوره کافکا از مدرسه مهندسی داده سپهرام Sepahram Data Eng. School در حال برگزاری است و این مباحث را با جزییات بیشتر در آن بررسی می کنیم . https://sepahram.ir/courses/apachekafka-redpanda/

✅کانال تلگرام سپهرام : https://t.iss.one/sepahram_school

‍ لیک‌هوس در مسیر بلوغ: نگاهی به نسخه جدید #RisingWave و ادغام عمیق آن با #Iceberg

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

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

📌 اینجا همان جایی است که مفهوم #Lakehouse اهمیت خود را نشان می‌دهد: ترکیبی از داده‌های ساخت‌یافته‌ی خام به همراه یک استاندارد سازمان‌دهی مانند #ApacheIceberg که باعث می‌شود داده‌ها در مقیاس وسیع قابل ذخیره‌سازی، مدیریت و تحلیل باشند.

🚀با این حال، فناوری‌هایی چون Iceberg هنوز در مدیریت متادیتا، snapshotها و عملیات نگهداری، چالش‌هایی دارند. در همین نقطه است که نسخه‌ی جدید #RisingWave v2.6 می‌تواند فرآیند به کارگیری و مدیریت لیک‌هوس را تسهیل کند ✨


⚡️ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper = ترکیب برنده!

✅ در این نسخه، RisingWave، به‌عنوان یک پایگاه داده جریانی سازگار با #PostgreSQL، به‌صورت بومی با Iceberg ادغام شده است. داده‌ها به‌صورت لحظه‌ای از #Kafka دریافت، در RisingWave پردازش، و سپس به شکل استاندارد در Lakehouse ذخیره می‌شوند.

✅این ارتباط از طریق #Lakekeeper برقرار می‌شود: یک #REST Catalog استاندارد که رابط رسمی میان RisingWave و Iceberg است.

✅ کتابخانه Lakekeeper علاوه بر مدیریت متادیتا و کنترل دسترسی‌ها (با پشتیبانی از #OpenFGA)، امکان راه‌اندازی و تنظیم #Lakehouse را به‌دلخواه شما فراهم می‌کند؛ مثلاً با استفاده از #MinIO یا هر فایل‌سیستم دیگر.

✅ سپس RisingWave با تنظیمات شما و در «لیک‌هوس شما» شروع به درج داده‌ها می‌کند.

✅ داده‌های غیرجریانی سازمان نیز می‌توانند با ابزارهایی مانند #ApacheSpark یا #PyIceberg به این بستر منتقل شوند تا یک Lakehouse کامل شکل گیرد: جایی که RisingWave بخش داده‌های جریانی را مدیریت می‌کند.

این ترکیب، از نظر فنی استاندارد و از نظر معماری، منعطف و آینده‌نگر است.

همچنین، عملیات نگهداشت و بهینه‌سازی داده‌ها مستقیماً در خود RisingWave انجام می‌شود، و بار سنگین مدیریت #Lakehouse از دوش تیم‌های داده برداشته می‌شود. 💪

🧠 ویژگی‌های کلیدی نسخه‌ی RisingWave ۲.۶

🔰 پشتیبانی از داده‌های برداری (Vector) برای جست‌وجوی شباهت

🔰حالت جدید Copy-on-Write برای snapshotهای تمیزتر در Iceberg

🔰دستور VACUUM FULL برای پاک‌سازی و فشرده‌سازی داده‌ها

🔰سازگاری کامل با #Lakekeeper REST Catalog

🔰تنوع sinkهای جدید برای #Snowflake، #Redshift، #Elasticsearch

🔰حالت Memory-Only برای پردازش‌های فوق‌سریع


🎥 به‌زودی ویدیویی منتشر می‌کنم که در آن ساخت یک #Lakehouse عملی با

#MinIO + #Lakekeeper + #Spark + #Trino + #StarRocks

را گام‌به‌گام بررسی می‌کنیم. 🚀

به باور من، مسیر آینده‌ی زیرساخت‌های داده به‌سمتی پیش می‌رود که #Lakehouse بستر اصلی ذخیره و تحلیل داده‌ها شود،

و ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper یکی از گزینه‌های خوب سازمانی برای شروع این مسیر است. 🌟

‍ وقتی Kafka ساده‌تر، سریع‌تر و سبک‌تر می‌شود: آشنایی با Redpanda در دوره تخصصی کافکا 🎥

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

در این ویدیو که به‌صورت کارگاهی و کاملاً عملی برگزار شده است، مراحل زیر را گام‌به‌گام انجام می‌دهیم 👇

🔹 راه‌اندازی یک کلاستر تک‌نودی از Redpanda به همراه Redpanda Console

🔹 اجرای دو رابط کاربری معروف دنیای Kafka یعنی AKHQ و Kafka-UI (Kafbat) و بررسی سازگاری کامل آن‌ها با Redpanda

🔹 کار با ابزار خط فرمان rpk برای مدیریت کلاستر و پیکربندی‌ها

🔹 ساخت یک پایپ‌لاین واقعی با Redpanda Connect و زبان Bloblang برای پردازش فایل‌های CSV

🔹 و در نهایت، اجرای PostgreSQL CDC با استفاده از Kafka Connect + Debezium برای همگام‌سازی بلادرنگ داده‌ها

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

📺 ویدیو کامل این کارگاه را می‌توانید از طریق لینک زیر در یوتیوب مشاهده کنید:

👉 🔗 https://youtu.be/nu_L4OSRUZc

🎓 این ویدیو بخشی از دوره آموزش تخصصی Kafka از مدرسه مهندسی داده سپهرام (Sepahram) است.

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

🌐 https://sepahram.ir/courses/

📢 کانال رسمی سپهرام در تلگرام:

📬 https://t.iss.one/sepahram_school

🔖 #Kafka #Redpanda #StreamingData #DataEngineering #Debezium #PostgreSQL #KafkaConnect #RealTimeData #Sepahram #مدرسه_مهندسی_داده #کافکا #داده_جاری #مهندسی_داده

‍ از Kafka تا Iceberg در کمتر از یک دقیقه؛ تجربه عملی AutoMQ
در مدرسه مهندسی داده سپهرام، همیشه تلاش کرده‌ایم جدیدترین فناوری‌های حوزه داده را به‌صورت کاربردی و قابل استفاده در پروژه‌های واقعی ارائه کنیم. در ویدئویی که اخیراً در کانال یوتیوب مدرسه منتشر شده است، به‌صورت کاملاً عملی کار با AutoMQ، جایگزین نوآورانه و cloud-first برای #Kafka و همچنین ذخیره‌سازی مستقیم داده‌های Kafka در Apache Iceberg و کوئری‌گیری آن با #DuckDB را بررسی کرده‌ایم.
این جلسه بخشی از رویکرد ما برای آموزش معماری‌های مدرن داده مانند Lakehouse، Zero-ETL و استریم‌پردازی ابری است.

🔰 اما AutoMQ‌ دقیقا چیست ؟
کتابخانه AutoMQ یک کافکای بازنویسی شده است که مستقیماً بر پایه کدهای Kafka توسعه یافته و تنها لایه ذخیره‌سازی آن بازطراحی شده است. در این معماری، پیام‌ها به جای ذخیره روی دیسک هر بروکر، در یک فضای ذخیره‌سازی خارجی مانند S3 یا MinIO قرار می‌گیرند. این تغییر مهم باعث می‌شود بتوان بروکرهای بدون دیسک داشت، مقیاس‌پذیری را بسیار ساده‌تر کرد و عملیات نگه‌داری را کاهش داد. علاوه بر این، AutoMQ در مدیریت خودکار مقیاس‌پذیری هنگام افزایش حجم داده، عملکردی به‌مراتب بهتر از Kafka سنتی ارائه می‌دهد و همین موضوع آن را به یک گزینه مناسب برای تیم‌های دواپس و محیط‌های با بار سنگین داده تبدیل کرده است

در این ویدئو، مباحث زیر به‌صورت مرحله‌به‌مرحله و عملی ارائه شده است:
✔️آشنایی با معماری AutoMQ و تفاوت آن با Kafka سنتی
✔️راه‌اندازی کامل AutoMQ، MinIO، Iceberg، Schema Registry و DuckDB با Docker Compose
✔️معرفی و تشریح قابلیت AutoMQ Table Topic
✔️ارسال داده Avro از طریق یک Producer پایتونی
✔️ذخیره‌سازی خودکار داده‌ها از Kafka در جداول Iceberg بدون Kafka Connect و بدون Flink/Spark
✔️بررسی قابلیت Zero-ETL در سناریوی واقعی
✔️یکپارچگی Schema Registry و انتقال خودکار اسکیمـا به Iceberg
✔️مشاهده داده‌های ذخیره‌شده در Iceberg و اجرای کوئری‌های تحلیلی با DuckDB
✔️بررسی قابلیت Time Travel، تکامل اسکیمـا (Schema Evolution) و Partitioning
✔️نکات مهم برای استقرار AutoMQ در محیط Production و تنظیمات پیشنهادی

برای مشاهده این آموزش کاربردی می‌توانید ویدئو را در کانال یوتیوب مدرسه مشاهده کنید:
🎥 پیوند ویدئو:
https://lnkd.in/d4ZHK4n8
#Kafka #ApacheIceberg #AutoMQ #DataEngineering #DataPipeline #ZeroETL #DuckDB #Lakehouse