کوبرنتیز برای نوجوانان

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

در دنیای امروز که با حجم عظیم داده‌ها و افزایش روزافزون سرعت تولید آن‌ها روبرو هستیم، نیازهای جستجو و تحلیل به‌موقع داده‌ها، ما را با چالش‌هایی مواجه می‌سازد که رفع آن‌ها مستلزم دانش عمیق در زمینه زیرساخت‌های پایگاه‌های داده است. تنها با بهره‌گیری از این دانش است که می‌توانیم نقاط ضعف را شناسایی کرده و راهکارهای مناسب را برای پیشبرد اهداف کسب و کار خود اتخاذ نماییم. بدون درک کافی از پشت صحنه مدیریت و پردازش داده‌های حجیم، غلبه بر موانع و دستیابی به عملکرد مطلوب، امری دشوار خواهد بود. کتاب Database Performance at Scale‌ میتواند این دید عمیق و مهندسی را به شما بدهد.
https://www.bigdata.ir/1403/02/%d9%85%d8%b9%d8%b1%d9%81-%da%a9%d8%aa%d8%a7%d8%a8-database-performance-at-scale/

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

در اوایل سال ۲۰۲۳، دیسکورد دیتابیس اصلی خود را از کاساندرا به ScyllaDB‌ منتقل کرد و مدیریت میلیاردهای داده خود را به این دیتابیس که کاملا سازگار با کاساندرا اما با کارآیی بسیار بالاتر است، سپرد.

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

https://discord.com/blog/how-discord-stores-trillions-of-messages
پ.ن: دیسکورد در سال ۲۰۱۷ از مانگو‌دی‌بی به کاساندرا مهاجرت کرد.

پ.ن۲: برای مشاهده سایر شرکت‌هایی که به این دیتابیس مهاجرت کر‌ده‌اند و یا امکانات جدیدی که به این دیتابیس خوش‌آتیه افزوده شده است می‌توانید به فهرست سخنرانیهای

ScyllaDB Summit 2024 (https://www.scylladb.com/scylladb-summit-2024/presentations/)

نگاهی بیندازید.

#کاساندرا #مهندسی_داده #ScyllaDB

اگر با پستگرس کار می‌کنید و

- قصد راه‌اندازی CDC را بر روی آن دارید، مثلا قصد دارید به ازای هر کاربر جدید یا هر سفارش جدید، یک رخداد جدید به صورت خودکار ایجاد شده و به کافکا ارسال گردد تا در یک پایپ‌لاین پردازش داده، اقدام مناسب برای آن رخداد (مثلا ایجاد یک کدتخفیف سفارشی و ارسال به مشتری)‌ انجام شود.

- یا می‌خواهید یک بکاپ از برخی جداول اصلی خود روی یک یا چند نود پستگرس دیگر ایجاد کنید

- و یا قصد دارید پردازش‌های تحلیلی خود را به جای پستگرس بر روی کلیک‌هوس انجام بدهید و بار پردازش‌های سنگین را از دوش پستگرس بردارید

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

PeerDB: Our infrastructure is designed for real-time streaming from Postgres. If your application is latency-sensitive you can configure refresh intervals as low as a few seconds

PeerDB : https://docs.peerdb.io/quickstart/quickstart


#پستگرس #Postgres #PeerDB #PostgreSQL

‍ یکی از کتاب‌های خوبی که اخیرا توسط دانیال خسروی و جواد جعفری به فارسی ترجمه شده است، کتاب مصاحبه طراحی سیستم‌های نرم‌افزاری است که به بررسی جنبه‌های مختلف طراحی سیستم‌‌های نوین نرم‌افزاری پرداخته است.
هر چند این کتاب برای مهندسین نرم‌افزار و طراحان سیستم‌های نرم افزاری نوشته است اما با توجه به اینکه مباحث مختلفی از توزیع‌پذیری و مقیاس‌پذیری در آن مطرح شده است،‌خواندن آنرا به تمامی علاقه‌مندان حوزه مهندسی داده، توصیه می‌کنیم.
در این کتاب، در هر یک از فصل‌های کتاب، یک سیستم به طور کامل طراحی شده است که در زیر می‌توانید عنوان‌های آنها را مشاهده کنید.
Chapter 1: Scale From Zero To Millions Of Users
Chapter 2: Back-Of-The-Envelope Estimation
Chapter 3: A Framework For System Design Interviews
Chapter 4: Design A Rate Limiter
Chapter 5: Design Consistent Hashing
Chapter 6: Design A Key-Value Store
Chapter 7: Design A Unique Id Generator In Distributed Systems
Chapter 8: Design A Url Shortener
Chapter 9: Design A Web Crawler
Chapter 10: Design A Notification System
Chapter 11: Design A News Feed System
Chapter 12: Design A Chat System
Chapter 13: Design A Search Autocomplete System
Chapter 14: Design Youtube
Chapter 15: Design Google Drive
Chapter 16: The Learning Continues
برای دانلود نسخه الکترونیکی این کتاب، که با اجازه از مترجمین کتاب در اینجا قرار گرفته است، می‌توانید از لینک زیر استفاده کنید :
https://uploadb.com/ug7rgpcgrutx
#طراحی_سیستم_های_مقیاس_پذیر #مهندسی_داده ‌#معرفی_کتاب

‍ فرض کنید شما یک اپلیکیشن موبایل یا یک وب‌سایت تجاری را توسعه داده‌اید و از پایگاه‌های داده‌ای مانند MySQL یا PostgreSQL برای ذخیره اطلاعات اصلی خود استفاده کرده‌اید. اکنون نیاز به یک پنل مدیریت برای کنترل و مدیریت داده‌های ذخیره شده دارید، اما متأسفانه منابع (نیروی انسانی/ زمان/ پول/ ...) کافی برای توسعه یک داشبورد مناسب در اختیار ندارید. چه کنیم در این شرایط بغرنج؟
خوشبختانه، در دنیای امروز، ابزارهایی تحت عنوان "پلتفرم‌های بدون کد" (No-Code Platforms) توسعه یافته‌اند که می‌توانند به شما در این زمینه کمک کنند. این ابزارها به شما امکان می‌دهند تا بدون نیاز به کدنویسی و با اتصال مستقیم به پایگاه داده، در عرض چند ساعت، اپلیکیشن خود را طراحی و پیاده‌سازی کنید.
https://github.com/topics/no-code-platform
در زیر به معرفی خیلی کوتاه چند عدد از این ابزارهای متن‌باز می‌پردازیم :
- NoCoBase : یک سیستم مقیاس‌پذیر و ماژولار برای طراحی برنامه‌های کاربردی که مجموعه‌ای غنی از پلاگین‌ها و افزونه‌ها، آنرا برای بسیاری از کاربردها و نیازمندیهای سازمانی و تجاری، مناسب می‌کند.
https://github.com/nocobase/nocobase
- Budibase‌ : یک سامانه ساده برای توسعه برنامه‌های کاربردی تک‌صفحه‌ای که امکان اتصال به انواع دیتابیس‌ها (PostgreSQL, MySQL, MSSQL, MongoDB, Rest API, Docker, K8s, and more) را دارد.
github.com/Budibase/budibase
- ILLA Builder :این پلتفرم به شما این امکان را می‌دهد که اپلیکیشن‌های تجاری بسازید و ابزارهای داخلی مانند داشبورد، اپلیکیشن‌های CRUD، پنل مدیریت، CRM، CMS و موارد مشابه را به سرعت ایجاد کنید. این پلتفرم از PostgreSQL، MySQL، Supabase، GraphQL، MongoDB، MSSQL، REST API، Hugging Face، Redis و غیره پشتیبانی می‌کند. می‌توانید گردش کارها را با زمان‌بندی یا وب‌هوک به صورت خودکار انجام دهید. این ابزار را می‌توانید نسخه متن‌باز Retool در نظر بگیرید.
https://github.com/illacloud/illa-builder
- NoCoDB‌ : این ابزار که خود را معادل متن‌باز AirTable می‌داند با اتصال به جداول مختلف پایگاه‌های داده‌شما، مدیریت اطلاعات را مانند کار با ابزارهای صفحه گسترده‌ مانند اکسل، ساده و راحت می‌کند بدون اینکه شما را درگیر برنامه‌نویسی کند.
https://github.com/nocodb/nocodb

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

‍ یکی از کارهای رایج مهندسین داده، 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