وقتی ابزارها از نیاز ما بزرگترند: درسهایی از Kafka و Flinkو هنر انتخاب درست
در دنیایی که هر ثانیه هزاران رویداد در سرویسها، اپلیکیشنها و سیستمهای ما جریان دارد، طبیعی است که به سراغ ابزارهای قدرتمند برویم. ابزارهایی مثل Kafka ، Flink و اسپارک که نامشان با «مقیاس عظیم»، «پردازش بلادرنگ» و «زیرساخت حرفهای» گره خورده است.
اما حقیقتی که کمتر دربارهاش حرف میزنیم این است:
✨ بیشتر ما اصلاً چنین مقیاسی نداریم.
سالهاست تیمهای کوچک و متوسط، با دادههای کم و نیازهای ساده، سراغ ابزارهایی میروند که برای غولهایی مثل اوبر، لینکدین یا نتفلیکس طراحی شدهاند. نتیجه چیست؟
پیچیدگی بیشتر. هزینه بیشتر. زمان بیشتر. و در نهایت، زیرساختی بزرگتر از نیاز واقعی.
دو مقالهای که اخیرا با عنوان «Kafka’s 80% Problem» و «Flink’s 95% Problem» منتشر شدهاند به کمک آمار و ارقام، ما را به توقفی کوتاه و تفکری جدی در این خصوص دعوت میکنند.
بیشتر خوشههای #Kafka زیر ۱ MB/s داده دارند و بیشتر کاربردهای استریم اصلاً نیازی به #Flink یا اسپارک ندارند. برای دو سوم پروژهها، یک API ساده یا یک دیتابیس تحلیلی سبک کاملاً کافی است.
👌 پیام نویسندگان این دو مقاله روشن است: قبل از انتخاب ابزار، نیاز واقعی را بسنج.
گاهی بهجای یک بیگدیتای کامل، تنها چیزی که لازم داریم یک خط پردازش داده ساده است.
چرا باید حواسمان به این انتخابها باشد؟
🔹 زیرا بیشتر تیمها درگیر «نیاز واقعی» نیستند، بلکه درگیر «تصور نیاز» شدهاند.
🔹 بیشتر خوشههای Kafka کمتر از ۱ مگابایت در ثانیه داده دارند.
🔹 بیشتر کاربردهای استریم اصلاً نیازمند پیچیدگی Flink یا اسپارک نیستند.
🔹 وقتی ابزار از نیاز بزرگتر باشد، هزینهها، پیچیدگی، زمان، نیروی انسانی و ریسک عملیاتی بیدلیل بالا میرود. انتخاب اشتباه ابزار، فقط یک مسئله فنی نیست، یک هزینه سازمانی و یک ریسک محصولی است.
بسیاری از تیمها، بدون بررسی دقیق، زیرساختهایی میسازند که برای غولهایی مثل نتفلیکس یا اوبر طراحی شده، نه برای سرویسهای متوسط.
نتیجه؟
⚠️زیرساخت سنگین برای بار سبک
⚠️هزینه مالی بالا
⚠️پیچیدگی عملیاتی غیرضروری
⚠️نیاز به تخصص خاص و دشوار
⚠️سرعت پایینتر توسعه
⚠️ و در نهایت، «مهندسی بیشازحد»
درحالیکه بسیاری از نیازها را میتوان با ابزارهایی بسیار سادهتر حل کرد: یک API، یک دیتابیس تحلیلی سبک، یا حتی یک معماری batch.
دنیای ابزارهای داده و استریمینگ خانهای بزرگ با امکانات فراوان است، اما هر ابزار قدرتمندی مناسب هر کاری نیست.
🔰 مقاله «Kafka’s 80% Problem» به ما میگوید که بسیاری از سازمانها با داده کم، زیرساخت بزرگ میسازند.
🔰 مقاله «Flink’s 95% Problem» هشدار میدهد که اغلب پروژهها نیازی به پیچیدگی فنی فلینک ندارند.
💡 پیام مشترک این دو مقاله روشن و ارزشمند است:
بهجای انتخاب ابزارهای بزرگ، نیاز کوچک خود را دقیق بفهمیم.
گاهی بهترین معماری، سادهترین معماری است، نه چون امکانات کمتری دارد، بلکه چون بیشترین همخوانی را با واقعیت دارد.آیا واقعاً به سیستمهای سنگین و «enterprise-grade» نیاز داریم، یا فقط درگیر مد روز مهندسی شدهایم؟ در معماری داده، هوشمندی در انتخاب ابزار همیشه مهمتر از بزرگی ابزار است.
پس شاید بهتر باشد از خودمان بپرسیم:
آیا واقعاً به سیستمهای سنگین و «enterprise-grade» نیاز داریم، یا فقط درگیر مد روز مهندسی شدهایم؟
در معماری داده، هوشمندی در انتخاب ابزار همیشه مهمتر از بزرگی ابزار است.
گاهی سادگی، بهترین راهحل مهندسی است.
در دنیایی که هر ثانیه هزاران رویداد در سرویسها، اپلیکیشنها و سیستمهای ما جریان دارد، طبیعی است که به سراغ ابزارهای قدرتمند برویم. ابزارهایی مثل Kafka ، Flink و اسپارک که نامشان با «مقیاس عظیم»، «پردازش بلادرنگ» و «زیرساخت حرفهای» گره خورده است.
اما حقیقتی که کمتر دربارهاش حرف میزنیم این است:
✨ بیشتر ما اصلاً چنین مقیاسی نداریم.
سالهاست تیمهای کوچک و متوسط، با دادههای کم و نیازهای ساده، سراغ ابزارهایی میروند که برای غولهایی مثل اوبر، لینکدین یا نتفلیکس طراحی شدهاند. نتیجه چیست؟
پیچیدگی بیشتر. هزینه بیشتر. زمان بیشتر. و در نهایت، زیرساختی بزرگتر از نیاز واقعی.
دو مقالهای که اخیرا با عنوان «Kafka’s 80% Problem» و «Flink’s 95% Problem» منتشر شدهاند به کمک آمار و ارقام، ما را به توقفی کوتاه و تفکری جدی در این خصوص دعوت میکنند.
بیشتر خوشههای #Kafka زیر ۱ MB/s داده دارند و بیشتر کاربردهای استریم اصلاً نیازی به #Flink یا اسپارک ندارند. برای دو سوم پروژهها، یک API ساده یا یک دیتابیس تحلیلی سبک کاملاً کافی است.
👌 پیام نویسندگان این دو مقاله روشن است: قبل از انتخاب ابزار، نیاز واقعی را بسنج.
گاهی بهجای یک بیگدیتای کامل، تنها چیزی که لازم داریم یک خط پردازش داده ساده است.
چرا باید حواسمان به این انتخابها باشد؟
🔹 زیرا بیشتر تیمها درگیر «نیاز واقعی» نیستند، بلکه درگیر «تصور نیاز» شدهاند.
🔹 بیشتر خوشههای Kafka کمتر از ۱ مگابایت در ثانیه داده دارند.
🔹 بیشتر کاربردهای استریم اصلاً نیازمند پیچیدگی Flink یا اسپارک نیستند.
🔹 وقتی ابزار از نیاز بزرگتر باشد، هزینهها، پیچیدگی، زمان، نیروی انسانی و ریسک عملیاتی بیدلیل بالا میرود. انتخاب اشتباه ابزار، فقط یک مسئله فنی نیست، یک هزینه سازمانی و یک ریسک محصولی است.
بسیاری از تیمها، بدون بررسی دقیق، زیرساختهایی میسازند که برای غولهایی مثل نتفلیکس یا اوبر طراحی شده، نه برای سرویسهای متوسط.
نتیجه؟
⚠️زیرساخت سنگین برای بار سبک
⚠️هزینه مالی بالا
⚠️پیچیدگی عملیاتی غیرضروری
⚠️نیاز به تخصص خاص و دشوار
⚠️سرعت پایینتر توسعه
⚠️ و در نهایت، «مهندسی بیشازحد»
درحالیکه بسیاری از نیازها را میتوان با ابزارهایی بسیار سادهتر حل کرد: یک API، یک دیتابیس تحلیلی سبک، یا حتی یک معماری batch.
دنیای ابزارهای داده و استریمینگ خانهای بزرگ با امکانات فراوان است، اما هر ابزار قدرتمندی مناسب هر کاری نیست.
🔰 مقاله «Kafka’s 80% Problem» به ما میگوید که بسیاری از سازمانها با داده کم، زیرساخت بزرگ میسازند.
🔰 مقاله «Flink’s 95% Problem» هشدار میدهد که اغلب پروژهها نیازی به پیچیدگی فنی فلینک ندارند.
💡 پیام مشترک این دو مقاله روشن و ارزشمند است:
بهجای انتخاب ابزارهای بزرگ، نیاز کوچک خود را دقیق بفهمیم.
گاهی بهترین معماری، سادهترین معماری است، نه چون امکانات کمتری دارد، بلکه چون بیشترین همخوانی را با واقعیت دارد.آیا واقعاً به سیستمهای سنگین و «enterprise-grade» نیاز داریم، یا فقط درگیر مد روز مهندسی شدهایم؟ در معماری داده، هوشمندی در انتخاب ابزار همیشه مهمتر از بزرگی ابزار است.
پس شاید بهتر باشد از خودمان بپرسیم:
آیا واقعاً به سیستمهای سنگین و «enterprise-grade» نیاز داریم، یا فقط درگیر مد روز مهندسی شدهایم؟
در معماری داده، هوشمندی در انتخاب ابزار همیشه مهمتر از بزرگی ابزار است.
گاهی سادگی، بهترین راهحل مهندسی است.
👍3
معرفی کتاب «چالشهای اخلاقی علم داده»
امروز در جهانی زندگی میکنیم که دادهها، آرام و بیصدا اما قدرتمند، در تار و پود زندگی ما تنیده شدهاند. از تصمیمهای ساده روزمره تا سیاستگذاریهای کلان، ردّ پای الگوریتمها را همهجا میبینیم؛ الگوریتمهایی که شاید هیچوقت آنها را نشناسیم، اما بهراحتی ما را دستهبندی میکنند، برایمان پیشنهاد میسازند، رفتارمان را پیشبینی میکنند و حتی در موقعیتهای حساس، به جای ما تصمیم میگیرند.
اما سؤال مهم این است:
⚠️ چه کسی به اخلاقِ پشتِ این سیستمها فکر میکند؟
⚠️ آیا توسعهدهندگان، تحلیلگران داده، استارتاپها، سازمانها و دولتها همیشه به پیامدهای انسانی و اجتماعی تصمیمات مبتنی بر داده آگاهاند؟
در جامعه علمی دنیا، سالهاست که اخلاق داده جدی گرفته میشود؛ همانطور که درباره محیطزیست، فلسفه اخلاق، یا اخلاق پژوهشهای انسانی ادبیات عظیمی شکل گرفته، درباره اخلاق علم داده هم پژوهشهای معتبر و چارچوبهای حرفهای ایجاد شده است.
ترجمه کتاب ارزشمند «چالشهای اخلاقی علم داده» نوشته دیوید مارتینز و ترجمهشده به همت محمدجواد جعفری دقیقاً در راستای همین موضوع و برای مخاطب ایرانی تهیه شده است:
کتابی که نهفقط یک نگاه نظری، بلکه راهنمایی عملی برای همه فعالان داده است: از تحلیلگر و مهندس داده تا مدیر محصول، پژوهشگر هوش مصنوعی و قانونگذار.
در ادامه، بر اساس سرفصلهای کتاب، نگاهی به محتوای آن و ارزشهای کلیدیاش میاندازیم.
آنچه در این کتاب میبینیم
🔰فصل اول: مقدمهای بر اخلاق علم داده
این فصل توضیح میدهد که چرا اخلاق باید بخشی جدانشدنی از چرخه توسعه سیستمهای داده باشد. در جهانی که الگوریتمها تصمیمهای مهم را شکل میدهند، رعایت عدالت، پاسخگویی و شفافیت دیگر انتخابی اختیاری نیست.
🔰فصل دوم: اخلاق جمعآوری دادهها
اینجا نویسنده یادآور میشود که جمعآوری داده، پیش از آنکه یک کار فنی باشد، مسئولیتی اخلاقی است. اینکه چه دادهای حق داریم جمع کنیم، چگونه باید حریم خصوصی را رعایت کرد و رضایت کاربر چه معنایی دارد، محور این فصل است.
🔰فصل سوم: اخلاق پردازش دادهها
این فصل نشان میدهد که پردازش نادرست داده، از پاکسازی تا ناشناسسازی، میتواند به نقض حریم خصوصی یا ایجاد سوگیریهای خطرناک منجر شود. کیفیت اخلاقی مدلها از همین مرحلههای اولیه شکل میگیرد.
🔰فصل چهارم: اخلاق مدلسازی
در این فصل به چالشهای اخلاقی هنگام ساخت مدلها میپردازیم: از تبعیض الگوریتمی تا اهمیت مدلهای توضیحپذیر و آگاه از تبعیض. پیام اصلی این است که مدلسازی باید با درک پیامدهای اجتماعی آن همراه باشد.
🔰فصل پنجم: ارزیابی اخلاقی
فصل پایانی تأکید میکند که اخلاق یک فرآیند مستمر است. سیستمهای داده باید دائماً از نظر عدالت، شفافیت و ریسک اخلاقی ارزیابی شوند و این ارزیابی باید بهصورت مسئولانه گزارش شود.
✔️ سخن پایانی
امیدوارم ترجمه و انتشار این کتاب آغازی برای جدیتر شدن بحث اخلاق داده در جامعه علمی و مهندسی ایران باشد. امروز بیش از همیشه به متخصصانی نیاز داریم که کنار توان فنی، نگاه انسانی و اخلاقی هم داشته باشند. برای محمدجواد جعفری مترجم پرتلاش این اثر، و همه دغدغهمندان این حوزه آرزوی موفقیت دارم. جامعه دادهمحور ایران به چنین گامهایی نیازمند است و این مسیر تازه آغاز شده است.
پ.ن: برای خرید و تهیه کتاب به سایت انتشارات جهاد دانشگاهی مراجعه کنید و یا به خود مترجم در لینکدین یا تلگرام @Mjafarisc پیام بدهید.
امروز در جهانی زندگی میکنیم که دادهها، آرام و بیصدا اما قدرتمند، در تار و پود زندگی ما تنیده شدهاند. از تصمیمهای ساده روزمره تا سیاستگذاریهای کلان، ردّ پای الگوریتمها را همهجا میبینیم؛ الگوریتمهایی که شاید هیچوقت آنها را نشناسیم، اما بهراحتی ما را دستهبندی میکنند، برایمان پیشنهاد میسازند، رفتارمان را پیشبینی میکنند و حتی در موقعیتهای حساس، به جای ما تصمیم میگیرند.
اما سؤال مهم این است:
⚠️ چه کسی به اخلاقِ پشتِ این سیستمها فکر میکند؟
⚠️ آیا توسعهدهندگان، تحلیلگران داده، استارتاپها، سازمانها و دولتها همیشه به پیامدهای انسانی و اجتماعی تصمیمات مبتنی بر داده آگاهاند؟
در جامعه علمی دنیا، سالهاست که اخلاق داده جدی گرفته میشود؛ همانطور که درباره محیطزیست، فلسفه اخلاق، یا اخلاق پژوهشهای انسانی ادبیات عظیمی شکل گرفته، درباره اخلاق علم داده هم پژوهشهای معتبر و چارچوبهای حرفهای ایجاد شده است.
ترجمه کتاب ارزشمند «چالشهای اخلاقی علم داده» نوشته دیوید مارتینز و ترجمهشده به همت محمدجواد جعفری دقیقاً در راستای همین موضوع و برای مخاطب ایرانی تهیه شده است:
کتابی که نهفقط یک نگاه نظری، بلکه راهنمایی عملی برای همه فعالان داده است: از تحلیلگر و مهندس داده تا مدیر محصول، پژوهشگر هوش مصنوعی و قانونگذار.
در ادامه، بر اساس سرفصلهای کتاب، نگاهی به محتوای آن و ارزشهای کلیدیاش میاندازیم.
آنچه در این کتاب میبینیم
🔰فصل اول: مقدمهای بر اخلاق علم داده
این فصل توضیح میدهد که چرا اخلاق باید بخشی جدانشدنی از چرخه توسعه سیستمهای داده باشد. در جهانی که الگوریتمها تصمیمهای مهم را شکل میدهند، رعایت عدالت، پاسخگویی و شفافیت دیگر انتخابی اختیاری نیست.
🔰فصل دوم: اخلاق جمعآوری دادهها
اینجا نویسنده یادآور میشود که جمعآوری داده، پیش از آنکه یک کار فنی باشد، مسئولیتی اخلاقی است. اینکه چه دادهای حق داریم جمع کنیم، چگونه باید حریم خصوصی را رعایت کرد و رضایت کاربر چه معنایی دارد، محور این فصل است.
🔰فصل سوم: اخلاق پردازش دادهها
این فصل نشان میدهد که پردازش نادرست داده، از پاکسازی تا ناشناسسازی، میتواند به نقض حریم خصوصی یا ایجاد سوگیریهای خطرناک منجر شود. کیفیت اخلاقی مدلها از همین مرحلههای اولیه شکل میگیرد.
🔰فصل چهارم: اخلاق مدلسازی
در این فصل به چالشهای اخلاقی هنگام ساخت مدلها میپردازیم: از تبعیض الگوریتمی تا اهمیت مدلهای توضیحپذیر و آگاه از تبعیض. پیام اصلی این است که مدلسازی باید با درک پیامدهای اجتماعی آن همراه باشد.
🔰فصل پنجم: ارزیابی اخلاقی
فصل پایانی تأکید میکند که اخلاق یک فرآیند مستمر است. سیستمهای داده باید دائماً از نظر عدالت، شفافیت و ریسک اخلاقی ارزیابی شوند و این ارزیابی باید بهصورت مسئولانه گزارش شود.
✔️ سخن پایانی
امیدوارم ترجمه و انتشار این کتاب آغازی برای جدیتر شدن بحث اخلاق داده در جامعه علمی و مهندسی ایران باشد. امروز بیش از همیشه به متخصصانی نیاز داریم که کنار توان فنی، نگاه انسانی و اخلاقی هم داشته باشند. برای محمدجواد جعفری مترجم پرتلاش این اثر، و همه دغدغهمندان این حوزه آرزوی موفقیت دارم. جامعه دادهمحور ایران به چنین گامهایی نیازمند است و این مسیر تازه آغاز شده است.
پ.ن: برای خرید و تهیه کتاب به سایت انتشارات جهاد دانشگاهی مراجعه کنید و یا به خود مترجم در لینکدین یا تلگرام @Mjafarisc پیام بدهید.
Forwarded from مدرسه مهندسی داده سپهرام
نگاهی به امکانات جدید Airflow 3 و دنیای Data Assets - آغاز عصر Data-Driven Workflows در ایرفلو
✨ در نسخه جدید Airflow 3 یک تحول اساسی رخ داده است:
این یعنی:
✔️ دیگر لازم نیست یک DAG را هر شب رأس یک ساعت مشخص اجرا کنیم؛
✔️ بلکه میتوانیم آن را براساس آماده شدن یک داده، یک خروجی، یا یک رخداد (Asset Event) اجرا کنیم.
✔️این تغییر، نقطهی اتصال دنیای Orchestration کلاسیک با Data Engineering مدرن است.
🔹و اما Data Assets در Airflow یعنی چه؟
از نسخه ۲ مفهومی به نام Asset اضافه شد، اما در Airflow 3 این قابلیت کاملاً بالغ شد و حتی یک بخش اختصاصی در UI برای مشاهده و مدیریت آن وجود دارد.
با Data Assets میتوانیم:
🔰مشخص کنیم یک DAG چه دادهای تولید میکند (Outlets)
🔰تعیین کنیم DAGها چه دادهای مصرف میکنند (Inlets)
🔰اجرای DAGها را وابسته به آماده شدن دادهها کنیم
🔰گردشکارها را بهجای schedule time-based، کاملاً event-based طراحی کنیم
🔰برای Assetها Metadata و Events تولید کنیم و رفتارهای پیشرفته بسازیم
به زبان ساده:
ایرفلو نسخه ۳ جریانهای کاری را "Data-Aware" و حتی "Data-Driven" میکند.
🎯 جلسه پنجم دوره آموزشی ایرفلو - از پارامترها تا Data-Driven Workflows
در جلسه پنجم دوره آموزش Airflow در «مدرسه مهندسی داده سپهرام»، دقیقاً روی همین موضوعات تمرکز کردهایم:
✴️ بخش اول: Parameterized Workflows
⚡️تعریف پارامتر برای DAGها
⚡️اجرای DAG از طریق API رسمی Airflow
⚡️ارسال پارامتر با curl و پایتون
⚡️استفاده از Auth و تولید token
✴️ بخش دوم: Data-Driven Workflows و داراییها
⚡️آشنایی با Assetها و معماری جدید Airflow 3
⚡️ساخت یک پایپلاین مبتنی بر Asset
⚡️استفاده از outlets و inlets در Taskها
⚡️مشاهده و مدیریت Assetها در UI
⚡️رویدادها (Asset Events)، Metadata، وابستگیهای ترکیبی و Aliases
این جلسه عملاً پلی است میان قابلیتهای قدیمی ایرفلو و معماریهای جدید Data-Driven Pipelines.
🎥 مشاهده رایگان جلسه
فیلمها و محتوای کامل جلسه پنجم برای عموم آزاد است و از این لینک میتوانید آنها را مشاهده کنید: کلیک کنید.
اگر با Airflow کار میکنید، این جلسه میتواند نگاه شما را نسبت به طراحی پایپلاینها کاملاً تغییر دهد.
پ.ن : هر چند سامانههای مدیریت جریان داده مثل Dagster در این زمینه بسیار جلوتر از ایرفلو هستند اما اگر در کنار کارهای روزانه زمانبندی شده، نیاز به دگهای داده محور هم دارید، ایرفلو امروزه این امکان را به راحتی در اختیار شما قرار میدهد.
✨ در نسخه جدید Airflow 3 یک تحول اساسی رخ داده است:
ایرفلو از یک ابزار زمانمحور برای اجرای جریانکارها، به یک سیستم دادهمحور (Data-Driven) ارتقا پیدا کرده است.
این یعنی:
✔️ دیگر لازم نیست یک DAG را هر شب رأس یک ساعت مشخص اجرا کنیم؛
✔️ بلکه میتوانیم آن را براساس آماده شدن یک داده، یک خروجی، یا یک رخداد (Asset Event) اجرا کنیم.
✔️این تغییر، نقطهی اتصال دنیای Orchestration کلاسیک با Data Engineering مدرن است.
🔹و اما Data Assets در Airflow یعنی چه؟
از نسخه ۲ مفهومی به نام Asset اضافه شد، اما در Airflow 3 این قابلیت کاملاً بالغ شد و حتی یک بخش اختصاصی در UI برای مشاهده و مدیریت آن وجود دارد.
با Data Assets میتوانیم:
🔰مشخص کنیم یک DAG چه دادهای تولید میکند (Outlets)
🔰تعیین کنیم DAGها چه دادهای مصرف میکنند (Inlets)
🔰اجرای DAGها را وابسته به آماده شدن دادهها کنیم
🔰گردشکارها را بهجای schedule time-based، کاملاً event-based طراحی کنیم
🔰برای Assetها Metadata و Events تولید کنیم و رفتارهای پیشرفته بسازیم
به زبان ساده:
ایرفلو نسخه ۳ جریانهای کاری را "Data-Aware" و حتی "Data-Driven" میکند.
🎯 جلسه پنجم دوره آموزشی ایرفلو - از پارامترها تا Data-Driven Workflows
در جلسه پنجم دوره آموزش Airflow در «مدرسه مهندسی داده سپهرام»، دقیقاً روی همین موضوعات تمرکز کردهایم:
✴️ بخش اول: Parameterized Workflows
⚡️تعریف پارامتر برای DAGها
⚡️اجرای DAG از طریق API رسمی Airflow
⚡️ارسال پارامتر با curl و پایتون
⚡️استفاده از Auth و تولید token
✴️ بخش دوم: Data-Driven Workflows و داراییها
⚡️آشنایی با Assetها و معماری جدید Airflow 3
⚡️ساخت یک پایپلاین مبتنی بر Asset
⚡️استفاده از outlets و inlets در Taskها
⚡️مشاهده و مدیریت Assetها در UI
⚡️رویدادها (Asset Events)، Metadata، وابستگیهای ترکیبی و Aliases
این جلسه عملاً پلی است میان قابلیتهای قدیمی ایرفلو و معماریهای جدید Data-Driven Pipelines.
🎥 مشاهده رایگان جلسه
فیلمها و محتوای کامل جلسه پنجم برای عموم آزاد است و از این لینک میتوانید آنها را مشاهده کنید: کلیک کنید.
اگر با Airflow کار میکنید، این جلسه میتواند نگاه شما را نسبت به طراحی پایپلاینها کاملاً تغییر دهد.
پ.ن : هر چند سامانههای مدیریت جریان داده مثل Dagster در این زمینه بسیار جلوتر از ایرفلو هستند اما اگر در کنار کارهای روزانه زمانبندی شده، نیاز به دگهای داده محور هم دارید، ایرفلو امروزه این امکان را به راحتی در اختیار شما قرار میدهد.
👍2
مهاجرت آرام و بیسروصدای MinIO به دنیای تجاری
تغییرات همیشه با اعلام رسمی شروع نمیشوند. گاهی تنها نشانه، یک کامیت ساده در گیتهاب است؛ تغییری کوچک که آینده یک اکوسیستم بزرگ را دگرگون میکند.
MinIO دقیقاً به همین شکل مسیرش را تغییر داد.
نه بیانیهای منتشر شد، نه توضیحی ارائه شد، تنها یک اصلاح در README:
❗️ کدبیس در حالت «Maintenance-only»
❗️ عدم پذیرش ویژگیها و Pull Requestهای جدید
❗️ بررسی رفع اشکالات امنیتی «بهصورت موردی»
و در کنار آن، دعوتی غیرمستقیم برای حرکت به سمت محصول تجاری:
👉 AIStor
این تصمیم، در عمل نشاندهنده یک کوچ آرام اما قطعی از مدل اوپنسورس به مدل تجاری است. تغییری که شاید بیسروصدا رخ داد، اما تأثیر آن بر زیرساخت بسیاری از سازمانها بسیار جدی خواهد بود.
✴️ پیامدهای این تغییر برای تیمهای فنی
پروژه محبوب MinIO برای سالها یکی از مهمترین انتخابها برای پیادهسازی S3-compatible storage در محیطهای production بود.
اما اکنون، هر تیمی که بر نسخه رایگان و پشتیبانی جامعه حساب کرده بود، در برابر واقعیتی جدید قرار دارد:
⚠️ توسعه متوقف شده است
⚠️ پایداری بلندمدت نامشخص است
⚠️امنیت تحت شرایط «case-by-case» قرار گرفته
بهعبارت دیگر، دوران MinIO بهعنوان یک گزینه پیشفرض، رایگان و قابل اتکا، عملاً پایان یافته است.
مسیر بعدی چیست؟
خوشبختانه امروز اکوسیستم ذخیرهسازی توزیعشده گزینههای قدرتمند و پختهای در اختیار دارد.
و حتی پروژههایی نوظهور که عملکردشان فراتر از حد انتظار است.
گزینههای جدی برای دوران پس از MinIO
🔹 RustFS
جایگزینی بسیار نزدیک، سریع و آیندهدار
در روزهای اخیر رشدی چشمگیر در فعالیت مخزن این پروژه مشاهده شده است. (برای مشاهده فعالیتها کلیک کنید.)
دلایل توجه بالای جامعه کاملاً روشن است:
🔰 سازگاری کامل با MinIO
🔰 اجرا روی همان پورتهای 9000
🔰عملکردی تا دو برابر سریعتر در بنچمارکهای اولیه
🔰کدنوشته شده با Rust؛ یعنی امنیت، سرعت و مصرف منابع بهینه
🔰جامعهای فعال که روند توسعه پرشتابی را نشان میدهد
این گزینه یعنی RustFS شاید تنها گزینهای باشد که مسیر مهاجرت از MinIO را تقریباً بدون تغییر در معماری امکانپذیر میکند.
🔹 SeaweedFS
راهکاری پخته و مناسب برای مقیاسهای بزرگ، با تمرکز بر سرعت، سادگی و توزیع مؤثر داده.
نکته: سال ۹۶ پستی را راجع به انتخاب یک فایلاستوریج که در آن Seaweedfs معرفی شده بود منتشر کردیم
🔹 Garage
انتخابی سبک و ساده برای محیطهای self-hosted و تیمهایی که به سادگی راهاندازی و نگهداری اهمیت میدهند.
🔹 Ceph
راهکاری جاافتاده برای بارهای کاری سنگین، با قابلیتهای گسترده اما پیچیدگی عملیاتی بالاتر.
تغییر مسیر MinIO شاید در ظاهر یک کامیت ساده باشد، اما برای بسیاری از تیمها یک نقطه تصمیمگیری استراتژیک خواهد بود.
اکنون زمان ارزیابی گزینهها و بازنگری در نقشه راه ذخیرهسازی است.
نظر شما برای کامیونیتی فارسی چیست ؟ چه جایگزینی را پیشنهاد میدهید؟
عکس و ایده مقاله از این پست برداشته شده است :
https://www.linkedin.com/posts/purged0_devops-minio-opensource-activity-7402619963125055488-t7VA
تغییرات همیشه با اعلام رسمی شروع نمیشوند. گاهی تنها نشانه، یک کامیت ساده در گیتهاب است؛ تغییری کوچک که آینده یک اکوسیستم بزرگ را دگرگون میکند.
MinIO دقیقاً به همین شکل مسیرش را تغییر داد.
نه بیانیهای منتشر شد، نه توضیحی ارائه شد، تنها یک اصلاح در README:
❗️ کدبیس در حالت «Maintenance-only»
❗️ عدم پذیرش ویژگیها و Pull Requestهای جدید
❗️ بررسی رفع اشکالات امنیتی «بهصورت موردی»
و در کنار آن، دعوتی غیرمستقیم برای حرکت به سمت محصول تجاری:
👉 AIStor
این تصمیم، در عمل نشاندهنده یک کوچ آرام اما قطعی از مدل اوپنسورس به مدل تجاری است. تغییری که شاید بیسروصدا رخ داد، اما تأثیر آن بر زیرساخت بسیاری از سازمانها بسیار جدی خواهد بود.
✴️ پیامدهای این تغییر برای تیمهای فنی
پروژه محبوب MinIO برای سالها یکی از مهمترین انتخابها برای پیادهسازی S3-compatible storage در محیطهای production بود.
اما اکنون، هر تیمی که بر نسخه رایگان و پشتیبانی جامعه حساب کرده بود، در برابر واقعیتی جدید قرار دارد:
⚠️ توسعه متوقف شده است
⚠️ پایداری بلندمدت نامشخص است
⚠️امنیت تحت شرایط «case-by-case» قرار گرفته
بهعبارت دیگر، دوران MinIO بهعنوان یک گزینه پیشفرض، رایگان و قابل اتکا، عملاً پایان یافته است.
مسیر بعدی چیست؟
خوشبختانه امروز اکوسیستم ذخیرهسازی توزیعشده گزینههای قدرتمند و پختهای در اختیار دارد.
و حتی پروژههایی نوظهور که عملکردشان فراتر از حد انتظار است.
گزینههای جدی برای دوران پس از MinIO
🔹 RustFS
جایگزینی بسیار نزدیک، سریع و آیندهدار
در روزهای اخیر رشدی چشمگیر در فعالیت مخزن این پروژه مشاهده شده است. (برای مشاهده فعالیتها کلیک کنید.)
دلایل توجه بالای جامعه کاملاً روشن است:
🔰 سازگاری کامل با MinIO
🔰 اجرا روی همان پورتهای 9000
🔰عملکردی تا دو برابر سریعتر در بنچمارکهای اولیه
🔰کدنوشته شده با Rust؛ یعنی امنیت، سرعت و مصرف منابع بهینه
🔰جامعهای فعال که روند توسعه پرشتابی را نشان میدهد
این گزینه یعنی RustFS شاید تنها گزینهای باشد که مسیر مهاجرت از MinIO را تقریباً بدون تغییر در معماری امکانپذیر میکند.
🔹 SeaweedFS
راهکاری پخته و مناسب برای مقیاسهای بزرگ، با تمرکز بر سرعت، سادگی و توزیع مؤثر داده.
نکته: سال ۹۶ پستی را راجع به انتخاب یک فایلاستوریج که در آن Seaweedfs معرفی شده بود منتشر کردیم
🔹 Garage
انتخابی سبک و ساده برای محیطهای self-hosted و تیمهایی که به سادگی راهاندازی و نگهداری اهمیت میدهند.
🔹 Ceph
راهکاری جاافتاده برای بارهای کاری سنگین، با قابلیتهای گسترده اما پیچیدگی عملیاتی بالاتر.
تغییر مسیر MinIO شاید در ظاهر یک کامیت ساده باشد، اما برای بسیاری از تیمها یک نقطه تصمیمگیری استراتژیک خواهد بود.
اکنون زمان ارزیابی گزینهها و بازنگری در نقشه راه ذخیرهسازی است.
نظر شما برای کامیونیتی فارسی چیست ؟ چه جایگزینی را پیشنهاد میدهید؟
عکس و ایده مقاله از این پست برداشته شده است :
https://www.linkedin.com/posts/purged0_devops-minio-opensource-activity-7402619963125055488-t7VA
❤3👍3😱1
چرا Apache DataFusion در حال تبدیلشدن به «موتور پنهان» پلتفرمهای مدرن داده است؟
در اکوسیستم داده، هر ماه پروژههای کوچک و بزرگ زیادی متولد میشوند؛ اما تنها تعداد کمی از آنها مسیر بلوغ را طی میکنند، جامعهٔ فنی را با خود همراه میسازند و آنقدر ارزشمند میشوند که در معماری سیستمهای مختلف به عنوان یک «مولفه اصلی» دیده شوند.
این استقبال گسترده معمولاً یک پیام دارد: بازار دقیقاً به چنین ابزاری نیاز داشته است.
دیتافیوژن یک Query Engine ماژولار و بسیار سریع است که با Rust نوشته شده و بهطور بومی با Apache Arrow کار میکند. آنرا مشابه با DuckDB در نظر بگیرید که به سادگی اجازه اجرای SQL را روی انواع منابع داده به شما میدهد اما مهمتر از این، نقشی است که امروز در سیستمهای تولیدی و پروژههای جدید بازی میکند:
🔹دیتابیس InfluxDB v3 – بازنویسی کامل بر پایه FDAP (Flight + DataFusion + Arrow + Parquet)
دیتابیس InfluxDB برای نسخه ۳ تصمیم گرفت موتور Query خود را کنار بگذارد و همهچیز را بر اساس DataFusion بسازد.
نتیجه؟
✨ صدبرابر سرعت بیشتر روی کوئریهای با کاردینالیتی بالا
✨ ده برابر افزایش سرعت ingest
✨ ده برابر بهبود فشردهسازی
دیتافیوژن برای آنها تبدیل شد به زیرساختی که هم SQL را انجام میدهد، هم پردازش برداری، هم پردازش real-time روی دادههای در حافظه و فایلهای Parquet.
🔹دیتابیس جریانی RisingWave – استفاده از DataFusion برای Iceberg Compaction
پروژه RisingWave یک دیتابیس استریمی منطبق با استاندارد Postgres است. اما برای حل مشکل فایلهای کوچک در Iceberg، یک انجین فشرده سازی و تجمیع جدید با DataFusion ساخت.
نتایج فوقالعاده بود:
✨ ۵.۵ برابر سریعتر از Spark
✨ بدون سربار JVM
✨ مصرف حافظه بسیار کمتر
🔹 شتابدهندهٔ اسپارک: Apache DataFusion Comet
پروژه Comet که ابتدا در اپل توسعه داده شد، برنامه اجرای کوئریها در Spark را به DataFusion ترجمه میکند و بدون تغییر کد، Spark را ۲.۲ برابر سریعتر اجرا میکند.
رقبای آن مثل Photon یا RAPIDS معمولاً محدود به سختافزار خاص هستند؛ اما Comet روی سختافزار معمولی هم عملکرد چشمگیری ارائه میدهد.
🔹پروژه Ballista – اجرای توزیعشدهٔ DataFusion
بالیستا تلاش میکند نسخهٔ توزیعشدهٔ DataFusion باشد؛ یک موتور پردازش توزیعشده با معماری Arrow-native که ۵ تا ۱۰ برابر مصرف حافظهٔ کمتری نسبت به Spark دارد. دقیقا کاری که شرکت دیپسیک با DuckDB در قالب پروژه smallpond کرد و دنیا را به شگفتی واداشت.
🔹 پروژههایی که پشت صحنه از DataFusion استفاده میکنند
پروژههای GreptimeDB و HoraeDB (تایمسری) / OpenObserve / Cube Store / GlareDB / LakeSoul ParadeDB / Seafowl / Arroyo
و دهها پروژه کوچک و بزرگ دیگر…
🌟 چرا این همه استقبال؟
چون DataFusion عملاً دارد نقش LLVM برای دنیای دیتا را بازی میکند:
🔰 توسعهدهندگان لازم نیست موتور اجرای Query بسازند
🔰 مولفههای SQL، Optimizer، Vectorized Execution و… «از پیش آماده» است
🔰 ترکیب Rust + Arrow ترکیبی است که هم سریع است و هم ایمن
🔰 اجازه میدهد هر تیم فقط روی بخش ارزشافزای پروژه خود تمرکز کند
این همان چیزی است که موج جدیدی از سیستمهای تحلیلگر، دیتابیسها و موتورهای پردازشی را ممکن کرده است.
⚡️ جمعبندی
دیتافیوژن فقط یک Query Engine نیست؛
یک زیرساخت است.
پایهای که نسل بعدی پلتفرمهای داده روی آن ساخته میشود: از دیتابیسهای تایمسری گرفته تا موتورهای استریمینگ، و حتی شتابدهندههای Spark.
اکوسیستم داده به چنین پروژههایی نیاز دارد:
ماژولار، سریع، open-source، استانداردمحور، و قابل ادغام در هر سناریوی مدرن.
در اکوسیستم داده، هر ماه پروژههای کوچک و بزرگ زیادی متولد میشوند؛ اما تنها تعداد کمی از آنها مسیر بلوغ را طی میکنند، جامعهٔ فنی را با خود همراه میسازند و آنقدر ارزشمند میشوند که در معماری سیستمهای مختلف به عنوان یک «مولفه اصلی» دیده شوند.
این استقبال گسترده معمولاً یک پیام دارد: بازار دقیقاً به چنین ابزاری نیاز داشته است.
یکی از این پروژههای ارزشمند و «استخواندار» در بنیاد آپاچی، بدون شک Apache DataFusion است؛ موتوری که این روزها در گوشهوکنار ابزارهای پردازش داده حضور دارد: گاهی در قلب یک دیتابیس، گاهی در نقش شتابدهندهٔ یک Query Engine قدیمی، و گاهی به عنوان یک زیرساخت مخفی که کسی متوجه حضورش نیست.
دیتافیوژن یک Query Engine ماژولار و بسیار سریع است که با Rust نوشته شده و بهطور بومی با Apache Arrow کار میکند. آنرا مشابه با DuckDB در نظر بگیرید که به سادگی اجازه اجرای SQL را روی انواع منابع داده به شما میدهد اما مهمتر از این، نقشی است که امروز در سیستمهای تولیدی و پروژههای جدید بازی میکند:
🔹دیتابیس InfluxDB v3 – بازنویسی کامل بر پایه FDAP (Flight + DataFusion + Arrow + Parquet)
دیتابیس InfluxDB برای نسخه ۳ تصمیم گرفت موتور Query خود را کنار بگذارد و همهچیز را بر اساس DataFusion بسازد.
نتیجه؟
✨ صدبرابر سرعت بیشتر روی کوئریهای با کاردینالیتی بالا
✨ ده برابر افزایش سرعت ingest
✨ ده برابر بهبود فشردهسازی
دیتافیوژن برای آنها تبدیل شد به زیرساختی که هم SQL را انجام میدهد، هم پردازش برداری، هم پردازش real-time روی دادههای در حافظه و فایلهای Parquet.
🔹دیتابیس جریانی RisingWave – استفاده از DataFusion برای Iceberg Compaction
پروژه RisingWave یک دیتابیس استریمی منطبق با استاندارد Postgres است. اما برای حل مشکل فایلهای کوچک در Iceberg، یک انجین فشرده سازی و تجمیع جدید با DataFusion ساخت.
نتایج فوقالعاده بود:
✨ ۵.۵ برابر سریعتر از Spark
✨ بدون سربار JVM
✨ مصرف حافظه بسیار کمتر
🔹 شتابدهندهٔ اسپارک: Apache DataFusion Comet
پروژه Comet که ابتدا در اپل توسعه داده شد، برنامه اجرای کوئریها در Spark را به DataFusion ترجمه میکند و بدون تغییر کد، Spark را ۲.۲ برابر سریعتر اجرا میکند.
رقبای آن مثل Photon یا RAPIDS معمولاً محدود به سختافزار خاص هستند؛ اما Comet روی سختافزار معمولی هم عملکرد چشمگیری ارائه میدهد.
🔹پروژه Ballista – اجرای توزیعشدهٔ DataFusion
بالیستا تلاش میکند نسخهٔ توزیعشدهٔ DataFusion باشد؛ یک موتور پردازش توزیعشده با معماری Arrow-native که ۵ تا ۱۰ برابر مصرف حافظهٔ کمتری نسبت به Spark دارد. دقیقا کاری که شرکت دیپسیک با DuckDB در قالب پروژه smallpond کرد و دنیا را به شگفتی واداشت.
🔹 پروژههایی که پشت صحنه از DataFusion استفاده میکنند
پروژههای GreptimeDB و HoraeDB (تایمسری) / OpenObserve / Cube Store / GlareDB / LakeSoul ParadeDB / Seafowl / Arroyo
و دهها پروژه کوچک و بزرگ دیگر…
🌟 چرا این همه استقبال؟
چون DataFusion عملاً دارد نقش LLVM برای دنیای دیتا را بازی میکند:
🔰 توسعهدهندگان لازم نیست موتور اجرای Query بسازند
🔰 مولفههای SQL، Optimizer، Vectorized Execution و… «از پیش آماده» است
🔰 ترکیب Rust + Arrow ترکیبی است که هم سریع است و هم ایمن
🔰 اجازه میدهد هر تیم فقط روی بخش ارزشافزای پروژه خود تمرکز کند
این همان چیزی است که موج جدیدی از سیستمهای تحلیلگر، دیتابیسها و موتورهای پردازشی را ممکن کرده است.
⚡️ جمعبندی
دیتافیوژن فقط یک Query Engine نیست؛
یک زیرساخت است.
پایهای که نسل بعدی پلتفرمهای داده روی آن ساخته میشود: از دیتابیسهای تایمسری گرفته تا موتورهای استریمینگ، و حتی شتابدهندههای Spark.
اکوسیستم داده به چنین پروژههایی نیاز دارد:
ماژولار، سریع، open-source، استانداردمحور، و قابل ادغام در هر سناریوی مدرن.
👌3❤1
معرفی کتاب «الگوهای طراحی ابری و معماری مایکروسرویس» - ترجمه دانیال خسروی
در دنیای مهندسی نرمافزار، بعضی کتابها فقط «خواندنی» نیستند؛
نقشهراهاند.
کتابهایی که وقتی وارد پروژههای واقعی میشوید، تازه میفهمید چرا باید زودتر آنها را میخواندید.
داستان این کتاب هم همین است.
چند سال پیش، در روزهایی که مباحث معماری ابری و سیستمهای توزیعشده با سرعت سرسامآور در حال تغییر بود، دانیال خسروی، مترجم آشنا برای بسیاری از ما، تصمیم گرفت منبعی بسازد که از جنس تجربه باشد، نه صرفاً ترجمه لغتبهلغت.
او پیشتر با ترجمه کتاب «مصاحبه طراحی سیستمهای نرمافزاری» نشان داده بود که چطور میتوان مفاهیم سنگین طراحی سیستم را قابلفهم و عملیاتی ارائه کرد.
این بار، سراغ دنیایی رفته که زیرساخت نرمافزارهای مدرن روی آن بنا میشود: الگوهای طراحی ابری.
🌩 این کتاب درباره چیست؟
اگر درگیر سیستمهای بزرگ، دادههای حجیم، مقیاسپذیری، یا معماری میکروسرویس هستید، این کتاب دقیقاً همان چیزی است که همیشه دنبالش بودید ولی یکجا پیدا نمیشد.
کتاب سه ستون اصلی معماری ابری را بررسی میکند:
🟦 ۱) مدیریت داده در فضای ابری
جایی که با مفاهیمی مثل Sharding، CQRS، Event Sourcing، Cache-Aside و… یاد میگیریم چطور داده را درست توزیع کنیم و همچنان انسجام حفظ شود.
🟨 ۲) الگوهای طراحی و پیادهسازی
از BFF تا Sidecar، از Gateway Routing تا Strangler Fig، اینها همان الگوهایی هستند که وقتی وارد یک پروژه enterprise واقعی میشوید، تفاوت «سرویس معمولی» و «سرویس قابلاعتماد» را میسازند.
🟩 ۳) الگوهای پیامرسانی
قلب تپنده سیستمهای توزیعشده: Saga، Pub/Sub، Priority Queue، Claim Check، Competing Consumers و دهها الگوی دیگر.
⭐️ چرا این کتاب ارزشمند است؟
چون برای مهندسینی نوشته شده که میخواهند سیستمهایی بسازند که زنده بمانند، رشد کنند و در لحظات بحران، فرو نریزند.
کتابی که از دل تجربه معماریهای واقعی آمده، نه از دل تئوریهای آزمایشگاهی.
و مهمتر از همه:
کاملاً رایگان منتشر شده است.
📥 لینک دانلود
📘 کتاب «الگوهای طراحی ابری و معماری مایکروسرویس»
از ریپازیتوری اصلی قابل دریافت است.
https://github.com/DannyRavi/cloud_software_farsi
دانلود مستقیم : https://github.com/DannyRavi/cloud_software_farsi/releases/download/1.0.4/cloud-microservices.pdf
📗 و اگر به کتاب قبلی مترجم علاقهمندید،
«مصاحبه طراحی سیستمهای نرمافزاری» را نیز میتوانید از این لینک دانلود کنید:
https://uploadb.com/ug7rgpcgrutx
آرزوی موفقیت برای دانیال عزیز و تمام دوستانی که دل در گرو رشد دانش این مرز و بوم دارند.
در دنیای مهندسی نرمافزار، بعضی کتابها فقط «خواندنی» نیستند؛
نقشهراهاند.
کتابهایی که وقتی وارد پروژههای واقعی میشوید، تازه میفهمید چرا باید زودتر آنها را میخواندید.
داستان این کتاب هم همین است.
چند سال پیش، در روزهایی که مباحث معماری ابری و سیستمهای توزیعشده با سرعت سرسامآور در حال تغییر بود، دانیال خسروی، مترجم آشنا برای بسیاری از ما، تصمیم گرفت منبعی بسازد که از جنس تجربه باشد، نه صرفاً ترجمه لغتبهلغت.
او پیشتر با ترجمه کتاب «مصاحبه طراحی سیستمهای نرمافزاری» نشان داده بود که چطور میتوان مفاهیم سنگین طراحی سیستم را قابلفهم و عملیاتی ارائه کرد.
این بار، سراغ دنیایی رفته که زیرساخت نرمافزارهای مدرن روی آن بنا میشود: الگوهای طراحی ابری.
🌩 این کتاب درباره چیست؟
اگر درگیر سیستمهای بزرگ، دادههای حجیم، مقیاسپذیری، یا معماری میکروسرویس هستید، این کتاب دقیقاً همان چیزی است که همیشه دنبالش بودید ولی یکجا پیدا نمیشد.
کتاب سه ستون اصلی معماری ابری را بررسی میکند:
🟦 ۱) مدیریت داده در فضای ابری
جایی که با مفاهیمی مثل Sharding، CQRS، Event Sourcing، Cache-Aside و… یاد میگیریم چطور داده را درست توزیع کنیم و همچنان انسجام حفظ شود.
🟨 ۲) الگوهای طراحی و پیادهسازی
از BFF تا Sidecar، از Gateway Routing تا Strangler Fig، اینها همان الگوهایی هستند که وقتی وارد یک پروژه enterprise واقعی میشوید، تفاوت «سرویس معمولی» و «سرویس قابلاعتماد» را میسازند.
🟩 ۳) الگوهای پیامرسانی
قلب تپنده سیستمهای توزیعشده: Saga، Pub/Sub، Priority Queue، Claim Check، Competing Consumers و دهها الگوی دیگر.
⭐️ چرا این کتاب ارزشمند است؟
چون برای مهندسینی نوشته شده که میخواهند سیستمهایی بسازند که زنده بمانند، رشد کنند و در لحظات بحران، فرو نریزند.
کتابی که از دل تجربه معماریهای واقعی آمده، نه از دل تئوریهای آزمایشگاهی.
و مهمتر از همه:
کاملاً رایگان منتشر شده است.
📥 لینک دانلود
📘 کتاب «الگوهای طراحی ابری و معماری مایکروسرویس»
از ریپازیتوری اصلی قابل دریافت است.
https://github.com/DannyRavi/cloud_software_farsi
دانلود مستقیم : https://github.com/DannyRavi/cloud_software_farsi/releases/download/1.0.4/cloud-microservices.pdf
📗 و اگر به کتاب قبلی مترجم علاقهمندید،
«مصاحبه طراحی سیستمهای نرمافزاری» را نیز میتوانید از این لینک دانلود کنید:
https://uploadb.com/ug7rgpcgrutx
آرزوی موفقیت برای دانیال عزیز و تمام دوستانی که دل در گرو رشد دانش این مرز و بوم دارند.
💯6👍2
Forwarded from مدرسه مهندسی داده سپهرام
مروری بر مبحث ایندکسینگ در PostgreSQL
گاهی وقتها هنگام کار با #PostgreSQL با کوئریهایی مواجه میشویم که بیدلیل کند به نظر میرسند. اولین حدس معمولاً «نبود ایندکس» است؛ اما واقعیت پیچیدهتر از این است. گاهی مشکل از جای دیگری میآید و مثلا باید پارتیشنبندی کنیم یا کوئری های خود را بازنویسی کنیم، اما گاهی هم ایندکس داریم، اما پستگرس تصمیم میگیرد از آن استفاده نکند.
✴️ و درست همینجاست که اهمیت شناخت عمیق ایندکسها و رفتار Query Planner مشخص میشود.
در جدیدترین ویدئوی منتشرشده در کانال یوتیوب مدرسه مهندسی داده سپهرام، تلاش کردهایم این مفاهیم را نه فقط معرفی، بلکه روایت کنیم - از اینکه پستگرس چگونه بدون ایندکس عمل میکند، تا اینکه چطور انتخاب نوع درست ایندکس میتواند تفاوتی معنیدار در عملکرد ایجاد کند.
این بخش، مقدمهای است بر یکی از مهمترین اصول Performance Tuning در #PostgreSQL؛ جایی که انتخاب بین B-Tree، GIN، GiST یا حتی یک Partial/Expression Index میتواند به معنای چند میلیثانیه یا چند ثانیه تفاوت باشد.
🎬 ویدئوی فارسی را از اینجا ببینید:
https://youtu.be/IQThCcn7yRo
🔍 در این ویدئو درباره این موارد صحبت میکنیم:
🔰 آشنایی با Access Methodها و رفتار پستگرس در حالت بدون ایندکس
🔰 ساختار صفحه، Tuple و نقش TID در دسترسی مستقیم
🔰 انواع ایندکسها و کاربرد دقیق هرکدام: B-Tree، Hash، GIN، GiST، BRIN و…
🔰 ایندکسهای پیشرفته: Partial، Expression، Multicolumn، Covered
🔰 نگهداری ایندکسها: REINDEX، CLUSTER، مدیریت bloat
🔰 تحلیل آماری: تشخیص ایندکس بلااستفاده و خطاهای طراحی
این ویدئو بخشی از دوره «Postgres in Action» است.
فهرست کامل دورهها : https://sepahram.ir/cources
گاهی وقتها هنگام کار با #PostgreSQL با کوئریهایی مواجه میشویم که بیدلیل کند به نظر میرسند. اولین حدس معمولاً «نبود ایندکس» است؛ اما واقعیت پیچیدهتر از این است. گاهی مشکل از جای دیگری میآید و مثلا باید پارتیشنبندی کنیم یا کوئری های خود را بازنویسی کنیم، اما گاهی هم ایندکس داریم، اما پستگرس تصمیم میگیرد از آن استفاده نکند.
✴️ و درست همینجاست که اهمیت شناخت عمیق ایندکسها و رفتار Query Planner مشخص میشود.
در جدیدترین ویدئوی منتشرشده در کانال یوتیوب مدرسه مهندسی داده سپهرام، تلاش کردهایم این مفاهیم را نه فقط معرفی، بلکه روایت کنیم - از اینکه پستگرس چگونه بدون ایندکس عمل میکند، تا اینکه چطور انتخاب نوع درست ایندکس میتواند تفاوتی معنیدار در عملکرد ایجاد کند.
این بخش، مقدمهای است بر یکی از مهمترین اصول Performance Tuning در #PostgreSQL؛ جایی که انتخاب بین B-Tree، GIN، GiST یا حتی یک Partial/Expression Index میتواند به معنای چند میلیثانیه یا چند ثانیه تفاوت باشد.
🎬 ویدئوی فارسی را از اینجا ببینید:
https://youtu.be/IQThCcn7yRo
🔍 در این ویدئو درباره این موارد صحبت میکنیم:
🔰 آشنایی با Access Methodها و رفتار پستگرس در حالت بدون ایندکس
🔰 ساختار صفحه، Tuple و نقش TID در دسترسی مستقیم
🔰 انواع ایندکسها و کاربرد دقیق هرکدام: B-Tree، Hash، GIN، GiST، BRIN و…
🔰 ایندکسهای پیشرفته: Partial، Expression، Multicolumn، Covered
🔰 نگهداری ایندکسها: REINDEX، CLUSTER، مدیریت bloat
🔰 تحلیل آماری: تشخیص ایندکس بلااستفاده و خطاهای طراحی
این ویدئو بخشی از دوره «Postgres in Action» است.
فهرست کامل دورهها : https://sepahram.ir/cources
خرید Confluent توسط IBM؛ نقطه عطفی برای آینده #Kafka و مهندسی داده ✨
در پایان سال ۲۰۲۵، #IBM با خرید #Confluent، شرکت اصلی توسعهدهنده #Kafka و خدمات تجاری مرتبط با آن، عملاً مهمترین بازیگر دنیای data streaming را وارد استراتژی کلان خود در #AI و Hybrid Cloud کرد. این اتفاق صرفاً یک معامله تجاری نیست؛ بلکه نقطهٔ عطفی در مسیر تحول Kafka و معماری دادههای جریانی است و نشانهای روشن از تغییر گرایشها در زیرساختهای داده محسوب میشود.
⚡️ اما دقیقاً چه چیزی در راه است؟
شرکتIBM سابقهای طولانی در حوزه هوش مصنوعی دارد؛ از Watson در دهه ۲۰۱۰ تا پلتفرمهای جدید GenAI. با این حال، در نسل جدید هوش مصنوعی، دیگر تنها مدلها تعیینکننده نیستند؛ داده زنده، پیوسته و real-time نقش کلیدی را بازی میکند. این دقیقاً همان جایی است که Confluent ارزش خود را نشان میدهد.
🔍 کانفلوئنت چه چیزی برای IBM به همراه دارد؟
کانفلوئنت طی سالها Kafka را از یک ابزار خام به یک پلتفرم Enterprise-ready تبدیل کرده است؛ با تمرکز بر سادگی عملیات، امنیت، مانیتورینگ، rebalancing هوشمند و Tiered Storage. علاوه بر این، تنوع مدلهای استقرار (On-prem، Hybrid و Cloud) برای IBM که مشتریانش عمدتاً سازمانهای بزرگ هستند، یک مزیت کلیدی محسوب میشود. اکوسیستم غنی Kafka Connectors نیز امکان اتصال ساده به دیتابیسها، SaaSها و سیستمهای سازمانی را فراهم میکند.
✅ چرا این خرید برای اکوسیستم Kafka یک نقطه عطف است؟
کافکا که تا امروز ستون فقرات معماریهای real-time بود، با ورود IBM وارد لایه هوش مصنوعی میشود. نقش آن از یک ابزار استریمینگ و ETL لحظهای فراتر میرود و به بستر تأمین داده و context زنده برای LLMها و Agentها تبدیل میشود.
✨ شرکت IBM قصد دارد Watsonx را از یک AI مبتنی بر دادههای batch به یک سیستم #EventDriven ارتقا دهد؛ سیستمی که مستقیماً به رویدادهای Kafka متصل است. در این مسیر، Kafka به هسته جریان داده در Data Fabric سازمانی و یکی از اجزای اصلی Smart Data Platform IBM بدل میشود.
موج بعدی مهندسی داده: Event-driven AI
«هر مسئله هوش مصنوعی، در اصل یک مسئله داده است.»
در نسل جدید AI، مدلها ثابت نیستند، context دائماً تغییر میکند و ورودی مدلها دیگر فقط prompt نیست؛ بلکه جریان پیوستهای از eventهاست. Kafka بهترین بستر برای چنین workloadهایی است. 🔍
آینده Kafka و Confluent چه خواهد بود؟
کافکا احتمالاً enterpriseتر میشود: امنیت قویتر، ابزارهای مدیریتی پیشرفتهتر، observability بومی و governance سازمانی. از سوی دیگر، Kafka بیش از پیش با سرویسهای هوش مصنوعی عجین خواهد شد و نقش فعالی در pipelineهای AI، Agentها و مدلهای زبانی ایفا میکند. همزمان، رقابت در بازار پلتفرمهای استریمینگ شدیدتر میشود و برخی مشتریان کوچکتر ممکن است به گزینههایی مانند Redpanda، AutoMQ یا Pulsar مهاجرت کنند.
این خرید فقط یک جابهجایی مالی نیست. ✅
برای جامعه مهندسی داده، یک پیام شفاف دارد:
🤖 کافکا وارد عصر جدیدی میشود؛ عصر هوش مصنوعی رویدادمحور.
از این پس مهندسین داده باید خود را برای معماریهای event-driven گستردهتر، جریانهای context برای AI، ترکیب Kafka با Vector DB و LLM، ساخت Agentهای real-time و pipelineهایی آماده کنند که در هر لحظه تصمیمگیری انجام میدهند.
🕸کافکا دیگر صرفاً ابزار استریمینگ نیست؛ در حال تبدیل شدن به سیستم عصبی هوش مصنوعی سازمانی است.
لینک خبر و عکس : https://www.cxtoday.com/contact-center/ibm-acquires-confluent-at-11bn-to-boost-real-time-data-accessibility/
در پایان سال ۲۰۲۵، #IBM با خرید #Confluent، شرکت اصلی توسعهدهنده #Kafka و خدمات تجاری مرتبط با آن، عملاً مهمترین بازیگر دنیای data streaming را وارد استراتژی کلان خود در #AI و Hybrid Cloud کرد. این اتفاق صرفاً یک معامله تجاری نیست؛ بلکه نقطهٔ عطفی در مسیر تحول Kafka و معماری دادههای جریانی است و نشانهای روشن از تغییر گرایشها در زیرساختهای داده محسوب میشود.
⚡️ اما دقیقاً چه چیزی در راه است؟
شرکتIBM سابقهای طولانی در حوزه هوش مصنوعی دارد؛ از Watson در دهه ۲۰۱۰ تا پلتفرمهای جدید GenAI. با این حال، در نسل جدید هوش مصنوعی، دیگر تنها مدلها تعیینکننده نیستند؛ داده زنده، پیوسته و real-time نقش کلیدی را بازی میکند. این دقیقاً همان جایی است که Confluent ارزش خود را نشان میدهد.
🔍 کانفلوئنت چه چیزی برای IBM به همراه دارد؟
کانفلوئنت طی سالها Kafka را از یک ابزار خام به یک پلتفرم Enterprise-ready تبدیل کرده است؛ با تمرکز بر سادگی عملیات، امنیت، مانیتورینگ، rebalancing هوشمند و Tiered Storage. علاوه بر این، تنوع مدلهای استقرار (On-prem، Hybrid و Cloud) برای IBM که مشتریانش عمدتاً سازمانهای بزرگ هستند، یک مزیت کلیدی محسوب میشود. اکوسیستم غنی Kafka Connectors نیز امکان اتصال ساده به دیتابیسها، SaaSها و سیستمهای سازمانی را فراهم میکند.
✅ چرا این خرید برای اکوسیستم Kafka یک نقطه عطف است؟
کافکا که تا امروز ستون فقرات معماریهای real-time بود، با ورود IBM وارد لایه هوش مصنوعی میشود. نقش آن از یک ابزار استریمینگ و ETL لحظهای فراتر میرود و به بستر تأمین داده و context زنده برای LLMها و Agentها تبدیل میشود.
✨ شرکت IBM قصد دارد Watsonx را از یک AI مبتنی بر دادههای batch به یک سیستم #EventDriven ارتقا دهد؛ سیستمی که مستقیماً به رویدادهای Kafka متصل است. در این مسیر، Kafka به هسته جریان داده در Data Fabric سازمانی و یکی از اجزای اصلی Smart Data Platform IBM بدل میشود.
موج بعدی مهندسی داده: Event-driven AI
«هر مسئله هوش مصنوعی، در اصل یک مسئله داده است.»
در نسل جدید AI، مدلها ثابت نیستند، context دائماً تغییر میکند و ورودی مدلها دیگر فقط prompt نیست؛ بلکه جریان پیوستهای از eventهاست. Kafka بهترین بستر برای چنین workloadهایی است. 🔍
آینده Kafka و Confluent چه خواهد بود؟
کافکا احتمالاً enterpriseتر میشود: امنیت قویتر، ابزارهای مدیریتی پیشرفتهتر، observability بومی و governance سازمانی. از سوی دیگر، Kafka بیش از پیش با سرویسهای هوش مصنوعی عجین خواهد شد و نقش فعالی در pipelineهای AI، Agentها و مدلهای زبانی ایفا میکند. همزمان، رقابت در بازار پلتفرمهای استریمینگ شدیدتر میشود و برخی مشتریان کوچکتر ممکن است به گزینههایی مانند Redpanda، AutoMQ یا Pulsar مهاجرت کنند.
این خرید فقط یک جابهجایی مالی نیست. ✅
برای جامعه مهندسی داده، یک پیام شفاف دارد:
🤖 کافکا وارد عصر جدیدی میشود؛ عصر هوش مصنوعی رویدادمحور.
از این پس مهندسین داده باید خود را برای معماریهای event-driven گستردهتر، جریانهای context برای AI، ترکیب Kafka با Vector DB و LLM، ساخت Agentهای real-time و pipelineهایی آماده کنند که در هر لحظه تصمیمگیری انجام میدهند.
🕸کافکا دیگر صرفاً ابزار استریمینگ نیست؛ در حال تبدیل شدن به سیستم عصبی هوش مصنوعی سازمانی است.
لینک خبر و عکس : https://www.cxtoday.com/contact-center/ibm-acquires-confluent-at-11bn-to-boost-real-time-data-accessibility/
👍2❤1👎1
نگاهی به پروژه Apache Fluss و پرچم پردازش جریان که بالاتر از همیشه است
امروزه پروژههای بسیار زیادی در حوزه داده و پردازش جریان شکل میگیرند.اما تشخیص اینکه کدام پروژه واقعاً با نیازهای واقعی بازار همراستا است و کدام صرفاً یک ایدهی جذاب روی کاغذ، همیشه کار سادهای نیست.
برای خود من، اولین باری که با پروژه Apache #Fluss مواجه شدم، یک حس مشخص وجود داشت:
اینکه «بهنظر میرسد دست روی نقطهی درستی گذاشته شده است»؛ اما چرا برای من این پروژه متفاوت و آیندهدار به نظر میرسید ؟
فلینک بهدرستی بهعنوان یکی از ستونهای اصلی پردازش بلادرنگ شناخته میشود؛ پروژهای بالغ و امتحانپسداده که امروز جایگاه خود را در سازمانهای بزرگ و حتی در معماریهای نوظهور مبتنی بر هوش مصنوعی و عاملهای هوشمند تثبیت کرده است.
با این حال، در کنار تمام توانمندیها، یک خلأ بنیادین دارد: آپاچی فلینک ذاتاً یک موتور پردازش جریان است، نه بستری برای نگهداری و پرسوجوی تحلیلی از دادههای گذشته.
🎯 اینجاست که Fluss دقیقاً وارد نقطهی درست مسئله میشود.
پروژه Fluss به چارچوب جریانی Flink، یک لایهی storage با رویکرد Lakehouse اضافه میکند؛ به شکلی که:
✔️ دادههای بسیار اخیر (مثلاً یک ساعت گذشته) در یک لایهی میانی نگهداری میشوند
✔️ این دادهها قابل query گرفتن هستند
✔️ و پس از گذشت زمان مشخص، به لایهی تاریخی منتقل میشوند
به این ترتیب:
⚡️ هم query روی دادههای داغ (hot data) امکانپذیر است
⚡️هم دادههای historical در دسترس باقی میمانند
⚡️و هم فشار ingestion بلادرنگ از روی Lakehouse برداشته میشود
البته واقعا برای من روشن نبود که چنین معماریای در عمل تا چه حد میتواند پایدار و موفق باشد. تا اینکه با آمار و نتایج عملی منتشرشده در دنیای واقعی مواجه شدم.
بر اساس بنچمارک و گزارش عملی منتشرشده :
🔰 نرخ نوشتن (Write Throughput): 2,000,000 پیام در ثانیه
🔰 پردازش در فلینک : 4,000,000 رکورد در ثانیه
🔰مصرف داده از Fluss یا (Log Consumption) : 2,000,000 پیام در ثانیه
🔰تأخیر سرتاسری (End-to-End Latency) : حدود 500 میلیثانیه
🔰معیار Backpressure: : صفر (ZERO)
🔰حجم کل داده پردازششده: 768 میلیون پیام
🔰خروجی نهایی تجمیعشده: حدود 700 هزار رکورد
🔰 پایداری سیستم: بدون هیچ شکست/خطا
این اعداد مهم هستند، نه صرفاً بهخاطر بزرگیشان، بلکه بهخاطر پایداری و تداوم آنها در سناریوی واقعی.
🔥 جمعبندی حرفهای
بهنظر میرسد برای سناریوهایی که:
✔️حجم دادهی جریانی بسیار بالا است
✔️پردازش بلادرنگ حیاتی است
✔️و همزمان نیاز به ذخیرهسازی و query روی دادهها وجود دارد
ترکیب Flink + Fluss میتواند یک معماری مدرن، حرفهای و آیندهنگر باشد؛ معماریای که هم پاسخگوی نیازهای امروز است و هم برای دنیای AI و سیستمهای هوشمند فردا طراحی شده است.
اگر بخواهم صادقانه بگویم، Fluss هنوز در ابتدای مسیر است؛ اما اگر مسیر را درست انتخاب کرده باشد - که شواهد فعلی همین را نشان میدهد - احتمالاً در آیندهی نزدیک اخبار بیشتری از آن خواهیم شنید.
امروزه پروژههای بسیار زیادی در حوزه داده و پردازش جریان شکل میگیرند.اما تشخیص اینکه کدام پروژه واقعاً با نیازهای واقعی بازار همراستا است و کدام صرفاً یک ایدهی جذاب روی کاغذ، همیشه کار سادهای نیست.
برای خود من، اولین باری که با پروژه Apache #Fluss مواجه شدم، یک حس مشخص وجود داشت:
اینکه «بهنظر میرسد دست روی نقطهی درستی گذاشته شده است»؛ اما چرا برای من این پروژه متفاوت و آیندهدار به نظر میرسید ؟
فلینک بهدرستی بهعنوان یکی از ستونهای اصلی پردازش بلادرنگ شناخته میشود؛ پروژهای بالغ و امتحانپسداده که امروز جایگاه خود را در سازمانهای بزرگ و حتی در معماریهای نوظهور مبتنی بر هوش مصنوعی و عاملهای هوشمند تثبیت کرده است.
با این حال، در کنار تمام توانمندیها، یک خلأ بنیادین دارد: آپاچی فلینک ذاتاً یک موتور پردازش جریان است، نه بستری برای نگهداری و پرسوجوی تحلیلی از دادههای گذشته.
✨ هرچند این سیستم قادر است state را با پایداری بالا و تحمل خطا حفظ کند، اما این قابلیت بیشتر در خدمت منطق پردازش است تا تحلیل عمومی دادهها. بهمحض آنکه نیاز به کوئریهای تحلیلی یا دسترسی مستقیم به دادههای تاریخی مطرح میشود، ناگزیر باید به یک دیتابیس یا لایهی ذخیرهسازی جداگانه رجوع کرد. یک چالش اصلی در این معماری : دادههای بسیار تازه دقیقاً در کجا باید قرار بگیرند تا هم بخشی از جریان پردازش باشند و هم بدون واسطه، قابل query و تحلیل؟
🎯 اینجاست که Fluss دقیقاً وارد نقطهی درست مسئله میشود.
پروژه Fluss به چارچوب جریانی Flink، یک لایهی storage با رویکرد Lakehouse اضافه میکند؛ به شکلی که:
✔️ دادههای بسیار اخیر (مثلاً یک ساعت گذشته) در یک لایهی میانی نگهداری میشوند
✔️ این دادهها قابل query گرفتن هستند
✔️ و پس از گذشت زمان مشخص، به لایهی تاریخی منتقل میشوند
به این ترتیب:
⚡️ هم query روی دادههای داغ (hot data) امکانپذیر است
⚡️هم دادههای historical در دسترس باقی میمانند
⚡️و هم فشار ingestion بلادرنگ از روی Lakehouse برداشته میشود
البته واقعا برای من روشن نبود که چنین معماریای در عمل تا چه حد میتواند پایدار و موفق باشد. تا اینکه با آمار و نتایج عملی منتشرشده در دنیای واقعی مواجه شدم.
بر اساس بنچمارک و گزارش عملی منتشرشده :
🔰 نرخ نوشتن (Write Throughput): 2,000,000 پیام در ثانیه
🔰 پردازش در فلینک : 4,000,000 رکورد در ثانیه
🔰مصرف داده از Fluss یا (Log Consumption) : 2,000,000 پیام در ثانیه
🔰تأخیر سرتاسری (End-to-End Latency) : حدود 500 میلیثانیه
🔰معیار Backpressure: : صفر (ZERO)
🔰حجم کل داده پردازششده: 768 میلیون پیام
🔰خروجی نهایی تجمیعشده: حدود 700 هزار رکورد
🔰 پایداری سیستم: بدون هیچ شکست/خطا
این اعداد مهم هستند، نه صرفاً بهخاطر بزرگیشان، بلکه بهخاطر پایداری و تداوم آنها در سناریوی واقعی.
🔥 جمعبندی حرفهای
بهنظر میرسد برای سناریوهایی که:
✔️حجم دادهی جریانی بسیار بالا است
✔️پردازش بلادرنگ حیاتی است
✔️و همزمان نیاز به ذخیرهسازی و query روی دادهها وجود دارد
ترکیب Flink + Fluss میتواند یک معماری مدرن، حرفهای و آیندهنگر باشد؛ معماریای که هم پاسخگوی نیازهای امروز است و هم برای دنیای AI و سیستمهای هوشمند فردا طراحی شده است.
اگر بخواهم صادقانه بگویم، Fluss هنوز در ابتدای مسیر است؛ اما اگر مسیر را درست انتخاب کرده باشد - که شواهد فعلی همین را نشان میدهد - احتمالاً در آیندهی نزدیک اخبار بیشتری از آن خواهیم شنید.
👍3👌1
Forwarded from Shahin Shaterzade
Linkedin
دوباره اومدیم با یک وبینار جذاب و ارزشمند با حضور جناب استاد بنائی.
استاد بنائی از افراد حرفهای و باتجربه در حوزه مهندسی داده…
استاد بنائی از افراد حرفهای و باتجربه در حوزه مهندسی داده…
دوباره اومدیم با یک وبینار جذاب و ارزشمند با حضور جناب استاد بنائی.
استاد بنائی از افراد حرفهای و باتجربه در حوزه مهندسی داده هستند که دیگر نیازی به معرفی ندارند. ایشان سالهاست بهصورت دلسوزانه در این فضا به تولید محتوای حرفهای و آموزش مشغولاند و کولهباری…
استاد بنائی از افراد حرفهای و باتجربه در حوزه مهندسی داده هستند که دیگر نیازی به معرفی ندارند. ایشان سالهاست بهصورت دلسوزانه در این فضا به تولید محتوای حرفهای و آموزش مشغولاند و کولهباری…
👍4👌2
من یه پست جدید نوشتم دربارهی اینکه چطور میشه میلیونها داکیومنت متنی رو deduplicate کرد؛
https://www.linkedin.com/posts/shayan-sadeghi_dataengineering-nlp-bigdata-activity-7408755749146988545-frrg
از روشهای سادهی exact match شروع میکنم و کمکم میرسم به جایی که باید متنهای خیلی شبیه ولی نه دقیقاً یکسان رو تشخیص بدیم.
اگه با اینا درگیر بودی، احتمالاً این مطلب به کارت میاد:
– دیتای متنی حجیم که کلی تکرار توش هست
– محتواهایی که فقط یه کم با هم فرق دارن (پارافریز، خلاصهشده، ادیتشده)
– نیاز به راهحلهایی که هم سریع باشن هم مقیاسپذیر
تو این پست دربارهی اینا حرف زدم:
- روشهای کلاسیک deduplication
- Shingling، MinHash و LSH به زبان قابل فهم
- چالشهای واقعی با دیتاهای بزرگ (تعداد و حجم اسناد)
- چطور به near-duplicate detection برسیم تو دنیای واقعی
لینک مقاله:
https://lnkd.in/gp3VaaMB
https://www.linkedin.com/posts/shayan-sadeghi_dataengineering-nlp-bigdata-activity-7408755749146988545-frrg
از روشهای سادهی exact match شروع میکنم و کمکم میرسم به جایی که باید متنهای خیلی شبیه ولی نه دقیقاً یکسان رو تشخیص بدیم.
اگه با اینا درگیر بودی، احتمالاً این مطلب به کارت میاد:
– دیتای متنی حجیم که کلی تکرار توش هست
– محتواهایی که فقط یه کم با هم فرق دارن (پارافریز، خلاصهشده، ادیتشده)
– نیاز به راهحلهایی که هم سریع باشن هم مقیاسپذیر
تو این پست دربارهی اینا حرف زدم:
- روشهای کلاسیک deduplication
- Shingling، MinHash و LSH به زبان قابل فهم
- چالشهای واقعی با دیتاهای بزرگ (تعداد و حجم اسناد)
- چطور به near-duplicate detection برسیم تو دنیای واقعی
لینک مقاله:
https://lnkd.in/gp3VaaMB
Linkedin
#dataengineering #nlp #bigdata #deduplication #scalability | Shayan Sadeghi
من یه پست جدید نوشتم دربارهی اینکه چطور میشه میلیونها داکیومنت متنی رو deduplicate کرد؛
از روشهای سادهی exact match شروع میکنم و کمکم میرسم به جایی که باید متنهای خیلی شبیه ولی نه دقیقاً یکسان رو تشخیص بدیم.
اگه با اینا درگیر بودی، احتمالاً این…
از روشهای سادهی exact match شروع میکنم و کمکم میرسم به جایی که باید متنهای خیلی شبیه ولی نه دقیقاً یکسان رو تشخیص بدیم.
اگه با اینا درگیر بودی، احتمالاً این…
👍5👌1
⚠️ تله پنهان استریمینگ در ClickHouse
چرا آنالیتیکس بلادرنگ شما ممکن است کاملاً اشتباه باشد؟
استفاده از ClickHouse با سرعت زیادی در حال گسترش است؛ سرعت بالای کوئریها، معماری ستونی و توان پردازش حجم عظیم داده، آن را به گزینهای محبوب برای داشبوردهای Real-Time و سیستمهای تحلیلی مدرن تبدیل کرده است 🚀
اما یک واقعیت نگرانکننده وجود دارد:
من اخیراً یک کارگاه عملی ضبط کردهام که دقیقاً همین مشکل را نشان میدهد؛ مشکلی ظریف که میتواند کل زیرساخت تحلیلی شما را زیر سؤال ببرد.
قبل از دیدن ویدیو، اجازه بدهید اصل ماجرا را ساده و شفاف توضیح بدهم.
🧩 سناریویی که خیلیها از آن استفاده میکنند
در بسیاری از تیمها، پایپلاین استریمینگ ClickHouse به شکلی شبیه این ساخته میشود:
🔹 دریافت داده از Kafka
🔹 ذخیره دادهها در جدول ReplacingMergeTree برای Deduplication
🔹 استفاده از Materialized View برای انتقال داده
🔹 ساخت جداول Aggregation برای آمار و KPIها
روی کاغذ، همهچیز منطقی به نظر میرسد:
Deduplication داریم، Aggregation داریم، همهچیز خودکار است.
اما مشکل دقیقاً همینجاست.
🧠 ریشه مشکل کجاست؟
مسئله از درک نادرست رفتار داخلی ClickHouse شروع میشود.
۱- ReplacingMergeTree در لحظه Insert دادهها را Deduplicate نمیکند
دادههای تکراری بلافاصله وارد جدول میشوند و فقط در آینده، آن هم هنگام Mergeهای پسزمینه، نسخههای قدیمی حذف میشوند.
یعنی برای مدتی (و گاهی طولانی)، داده تکراری واقعاً وجود دارد.
۲ - پردازش Materialized View روی داده خام اجرا میشود، نه داده Deduplicated
Materialized View به محض Insert شدن بلاک داده اجرا میشود؛
نه بعد از Merge و Deduplication.
نتیجه چه میشود؟
🔸 یک رویداد تکراری وارد میشود
🔸 View اجرا میشود
🔸 جدول Aggregation دوباره آپدیت میشود
🔸 بعداً شاید داده اصلی Deduplicate شود
🔸 اما آمار تجمیعی؟ برای همیشه خراب شده
۳- این خرابی برگشتپذیر نیست
وقتی Aggregation اشتباه ثبت شد، ClickHouse بهصورت خودکار نمیتواند آن را اصلاح کند.
🌍 این اتفاق در دنیای واقعی کی میافتد؟
برخلاف تصور رایج، داده تکراری خیلی بیشتر از آنچیزی که فکر میکنیم رخ میدهد:
🔹مشکلات شبکه
🔹 موضوع Rebalance شدن کانسیومرها در Kafka
🔹ریاستارت شدن Consumerها
🔹 رفتار و تنظیمات پیشفرض کافکا - At-least-once delivery
🔹نیاز به Backfill دادههای قدیمی
🔹 اشتباهات انسانی در تست و دیباگ
و ناگهان:
🔻 درآمد بیشتر از واقعیت نمایش داده میشود
🔻 تعداد کاربرها اشتباه است
🔻 نرخ Conversion Rate غلط است
بدترین بخش ماجرا؟
🚨 هیچ خطایی در لاگها نمیبینید. فقط عددهای اشتباه.
🛠 راهحل چیست؟
چند اصل مهم برای طراحی پایپلاین قابل اعتماد:
✅ پیشگیری بهتر از درمان است
تا حد ممکن نگذارید داده تکراری وارد سیستم شود.
✅ فرآیند Deduplication را فقط به ClickHouse نسپارید
مخصوصاً وقتی پای Aggregation بلادرنگ وسط است.
✅ جداول Summary را Idempotent طراحی کنید
طوری که اگر دوباره پردازش شدند، قابل اصلاح باشند.
✅ گزینه FINAL راهحل دائمی نیست
هزینه پردازشی بالایی دارد و برای production مناسب نیست.
✅ برای سیستمهای حیاتی، از Streaming Engine واقعی استفاده کنید
ابزارهایی مثل Flink، RisingWave یا Materialize میتوانند:
قابلیت Exactly-once semantics بدهند
مساله Update و Retract را درست مدیریت کنند
امکان Deduplication واقعی در سطح Stream انجام دهند
در این حالت، ClickHouse میشود لایه Serving نهایی؛ جایی که واقعاً در آن بیرقیب است ⚡️
🏗 معماری ترکیبی؛ بهترینِ هر دو دنیا
الگوی رایج در تیمهای بالغ داده:
Kafka → Streaming Engine → ClickHouse
(پردازش صحیح) (کوئری سریع)
🎯 نتیجه:
- داده درست
- آمار قابل اعتماد
داشبوردهایی که میشود به آنها تصمیمسازی سپرد
🎥 کارگاه عملی
در کارگاه ویدئویی که به این موضوع به کمک ردپاندا و کلیک هوس، به صورت عملی پرداخته شده است، موارد زیر را مشاهده میکنید:
🔹 چگونه یک پایپلاین سالم در ابتدا درست کار میکند
🔹 با ورود داده تکراری چطور آمار بهصورت بیصدا خراب میشود
🔹 چرا کوئریهای FINAL عدد متفاوتی نشان میدهند
🔹 و چگونه میشود معماری را اصلاح کرد
لینک کارگاه آموزشی : ۲۷ دقیقه - کلیک کنید.
آدرس گیت کارگاه : https://github.com/sepahram-school/workshops
🧾 جمعبندی
کلیک ابزار فوقالعادهای است؛ اما اگر رفتار داخلی آن را نشناسیم، خیلی راحت میتواند ما را گمراه کند.
چرا آنالیتیکس بلادرنگ شما ممکن است کاملاً اشتباه باشد؟
استفاده از ClickHouse با سرعت زیادی در حال گسترش است؛ سرعت بالای کوئریها، معماری ستونی و توان پردازش حجم عظیم داده، آن را به گزینهای محبوب برای داشبوردهای Real-Time و سیستمهای تحلیلی مدرن تبدیل کرده است 🚀
اما یک واقعیت نگرانکننده وجود دارد:
❗️ اگر معماری پایپلاین استریمینگ شما درست طراحی نشده باشد، ممکن است دادههایتان بهصورت کاملاً بیسروصدا خراب شوند و داشبوردها عددهای اشتباه نشان بدهند: بدون هیچ خطا یا هشداری.
من اخیراً یک کارگاه عملی ضبط کردهام که دقیقاً همین مشکل را نشان میدهد؛ مشکلی ظریف که میتواند کل زیرساخت تحلیلی شما را زیر سؤال ببرد.
قبل از دیدن ویدیو، اجازه بدهید اصل ماجرا را ساده و شفاف توضیح بدهم.
🧩 سناریویی که خیلیها از آن استفاده میکنند
در بسیاری از تیمها، پایپلاین استریمینگ ClickHouse به شکلی شبیه این ساخته میشود:
🔹 دریافت داده از Kafka
🔹 ذخیره دادهها در جدول ReplacingMergeTree برای Deduplication
🔹 استفاده از Materialized View برای انتقال داده
🔹 ساخت جداول Aggregation برای آمار و KPIها
روی کاغذ، همهچیز منطقی به نظر میرسد:
Deduplication داریم، Aggregation داریم، همهچیز خودکار است.
اما مشکل دقیقاً همینجاست.
🧠 ریشه مشکل کجاست؟
مسئله از درک نادرست رفتار داخلی ClickHouse شروع میشود.
۱- ReplacingMergeTree در لحظه Insert دادهها را Deduplicate نمیکند
دادههای تکراری بلافاصله وارد جدول میشوند و فقط در آینده، آن هم هنگام Mergeهای پسزمینه، نسخههای قدیمی حذف میشوند.
یعنی برای مدتی (و گاهی طولانی)، داده تکراری واقعاً وجود دارد.
۲ - پردازش Materialized View روی داده خام اجرا میشود، نه داده Deduplicated
Materialized View به محض Insert شدن بلاک داده اجرا میشود؛
نه بعد از Merge و Deduplication.
نتیجه چه میشود؟
🔸 یک رویداد تکراری وارد میشود
🔸 View اجرا میشود
🔸 جدول Aggregation دوباره آپدیت میشود
🔸 بعداً شاید داده اصلی Deduplicate شود
🔸 اما آمار تجمیعی؟ برای همیشه خراب شده
۳- این خرابی برگشتپذیر نیست
وقتی Aggregation اشتباه ثبت شد، ClickHouse بهصورت خودکار نمیتواند آن را اصلاح کند.
🌍 این اتفاق در دنیای واقعی کی میافتد؟
برخلاف تصور رایج، داده تکراری خیلی بیشتر از آنچیزی که فکر میکنیم رخ میدهد:
🔹مشکلات شبکه
🔹 موضوع Rebalance شدن کانسیومرها در Kafka
🔹ریاستارت شدن Consumerها
🔹 رفتار و تنظیمات پیشفرض کافکا - At-least-once delivery
🔹نیاز به Backfill دادههای قدیمی
🔹 اشتباهات انسانی در تست و دیباگ
و ناگهان:
🔻 درآمد بیشتر از واقعیت نمایش داده میشود
🔻 تعداد کاربرها اشتباه است
🔻 نرخ Conversion Rate غلط است
بدترین بخش ماجرا؟
🚨 هیچ خطایی در لاگها نمیبینید. فقط عددهای اشتباه.
🛠 راهحل چیست؟
چند اصل مهم برای طراحی پایپلاین قابل اعتماد:
✅ پیشگیری بهتر از درمان است
تا حد ممکن نگذارید داده تکراری وارد سیستم شود.
✅ فرآیند Deduplication را فقط به ClickHouse نسپارید
مخصوصاً وقتی پای Aggregation بلادرنگ وسط است.
✅ جداول Summary را Idempotent طراحی کنید
طوری که اگر دوباره پردازش شدند، قابل اصلاح باشند.
✅ گزینه FINAL راهحل دائمی نیست
هزینه پردازشی بالایی دارد و برای production مناسب نیست.
✅ برای سیستمهای حیاتی، از Streaming Engine واقعی استفاده کنید
ابزارهایی مثل Flink، RisingWave یا Materialize میتوانند:
قابلیت Exactly-once semantics بدهند
مساله Update و Retract را درست مدیریت کنند
امکان Deduplication واقعی در سطح Stream انجام دهند
در این حالت، ClickHouse میشود لایه Serving نهایی؛ جایی که واقعاً در آن بیرقیب است ⚡️
🏗 معماری ترکیبی؛ بهترینِ هر دو دنیا
الگوی رایج در تیمهای بالغ داده:
Kafka → Streaming Engine → ClickHouse
(پردازش صحیح) (کوئری سریع)
🎯 نتیجه:
- داده درست
- آمار قابل اعتماد
داشبوردهایی که میشود به آنها تصمیمسازی سپرد
🎥 کارگاه عملی
در کارگاه ویدئویی که به این موضوع به کمک ردپاندا و کلیک هوس، به صورت عملی پرداخته شده است، موارد زیر را مشاهده میکنید:
🔹 چگونه یک پایپلاین سالم در ابتدا درست کار میکند
🔹 با ورود داده تکراری چطور آمار بهصورت بیصدا خراب میشود
🔹 چرا کوئریهای FINAL عدد متفاوتی نشان میدهند
🔹 و چگونه میشود معماری را اصلاح کرد
لینک کارگاه آموزشی : ۲۷ دقیقه - کلیک کنید.
آدرس گیت کارگاه : https://github.com/sepahram-school/workshops
🧾 جمعبندی
کلیک ابزار فوقالعادهای است؛ اما اگر رفتار داخلی آن را نشناسیم، خیلی راحت میتواند ما را گمراه کند.
❤2👌2👍1
چطور با SQL خطوط پردازش بلادرنگ بسازیم؟ کارگاه عملی RisingWave
پردازش جریان یا کار با دادههای بلادرنگ در حجم بالا، یکی از قدیمیترین چالشهای مهندسی داده است. اما امروزه با گسترش کاربردهای بلادرنگ در صنایع مختلف، نیاز به ابزارهایی که بتوانند پایپلاینهای داده را به سرعت طراحی، به راحتی مانیتور و به منابع مختلف متصل کنند، بیش از پیش حس میشود.
ابزارهایی که اجازه دهند دادهها را غنیسازی کنیم، محاسبات را به مقصدهایی مثل #ClickHouse یا #Lakehouse منتقل کنیم و همه اینها بدون دردسر نگهداشت کدهای پیچیده Spark انجام شود.
💡 در این مسیر، RisingWave به عنوان یک دیتابیس جریانی مبتنی بر SQL و نوشتهشده با Rust ظاهر شد؛ ابزاری که از یک ایده ساده به یک موتور قدرتمند توزیعشده برای پردازش جریانهای داده تبدیل شده است. RisingWave اخیراً امکان ذخیره دادهها در Apache Iceberg را هم فراهم کرده، با پشتیبانی از انواع کاتالوگها مثل LakeKeeper، و مدیریت و نگهداری آنها را که معمولاً کار سنگینی در محیطهای Lakehouse است، خودش انجام میدهد.
در دوره آموزشی کافکا، بعد از بررسی مفاهیم پایه و تجربه با ابزارهایی مثل KSQLDB، به سراغ RisingWave رفتیم تا کار با دادههای واقعی و خطوط پردازش بلادرنگ را به صورت عملی تجربه کنیم.
🎯 در کارگاه عملی این جلسه، مسیر زیر را دنبال کردیم:
🔰 نصب و راهاندازی RisingWave و آمادهسازی محیط پردازش
🔰 دریافت دادههای تراکنشی بلادرنگ با Redpanda
🔰 انجام Join و غنیسازی دادهها با PostgreSQL
🔰 ذخیره خروجی پردازشها در RustFS و ClickHouse با فرمت Parquet
✔️تجربه استفاده از RustFS به جای Minio بسیار خوشایند بود و در Docker Compose کارگاه میتوانید این تنظیمات را مشاهده کنید
🔰اتصال و مدیریت دادهها با DBeaver، PSQL و RisingWave Console
🔰طراحی Materialized Views برای تحلیل بلادرنگ
🔰 بررسی الگوهای پیشرفته مانند Stream-Stream Join
🎥 فیلم کامل کارگاه در یوتیوب: https://youtu.be/P5tQu7cKNbE
💻 کدهای کارگاه در گیتهاب: https://github.com/sepahram-school/workshops
پردازش جریان یا کار با دادههای بلادرنگ در حجم بالا، یکی از قدیمیترین چالشهای مهندسی داده است. اما امروزه با گسترش کاربردهای بلادرنگ در صنایع مختلف، نیاز به ابزارهایی که بتوانند پایپلاینهای داده را به سرعت طراحی، به راحتی مانیتور و به منابع مختلف متصل کنند، بیش از پیش حس میشود.
ابزارهایی که اجازه دهند دادهها را غنیسازی کنیم، محاسبات را به مقصدهایی مثل #ClickHouse یا #Lakehouse منتقل کنیم و همه اینها بدون دردسر نگهداشت کدهای پیچیده Spark انجام شود.
💡 در این مسیر، RisingWave به عنوان یک دیتابیس جریانی مبتنی بر SQL و نوشتهشده با Rust ظاهر شد؛ ابزاری که از یک ایده ساده به یک موتور قدرتمند توزیعشده برای پردازش جریانهای داده تبدیل شده است. RisingWave اخیراً امکان ذخیره دادهها در Apache Iceberg را هم فراهم کرده، با پشتیبانی از انواع کاتالوگها مثل LakeKeeper، و مدیریت و نگهداری آنها را که معمولاً کار سنگینی در محیطهای Lakehouse است، خودش انجام میدهد.
با RisingWave، میتوانیم همان راحتی کار با دیتابیسهای رابطهای را برای دادههای جریانی تجربه کنیم و بدون نوشتن یک خط کد پیچیده، نیازهای رایج پردازش جریان را مدیریت کنیم.
در دوره آموزشی کافکا، بعد از بررسی مفاهیم پایه و تجربه با ابزارهایی مثل KSQLDB، به سراغ RisingWave رفتیم تا کار با دادههای واقعی و خطوط پردازش بلادرنگ را به صورت عملی تجربه کنیم.
🎯 در کارگاه عملی این جلسه، مسیر زیر را دنبال کردیم:
🔰 نصب و راهاندازی RisingWave و آمادهسازی محیط پردازش
🔰 دریافت دادههای تراکنشی بلادرنگ با Redpanda
🔰 انجام Join و غنیسازی دادهها با PostgreSQL
🔰 ذخیره خروجی پردازشها در RustFS و ClickHouse با فرمت Parquet
✔️تجربه استفاده از RustFS به جای Minio بسیار خوشایند بود و در Docker Compose کارگاه میتوانید این تنظیمات را مشاهده کنید
🔰اتصال و مدیریت دادهها با DBeaver، PSQL و RisingWave Console
🔰طراحی Materialized Views برای تحلیل بلادرنگ
🔰 بررسی الگوهای پیشرفته مانند Stream-Stream Join
🎥 فیلم کامل کارگاه در یوتیوب: https://youtu.be/P5tQu7cKNbE
💻 کدهای کارگاه در گیتهاب: https://github.com/sepahram-school/workshops
👍5