بعد از اتمام دوره بیگ‌دیتای همکاران سیستم، یکی از دانشجویان این دوره به من پیام داد که اگر بخواهم یک کار عملی توی حوزه مهندسی داده انجام بدم که مفاهیم اصلی مورد نیاز را به صورت عملی کار کنم، چه پروژه ای پیشنهاد می‌دهید.
پیشنهاد من ایجاد یک خط پردازش داده بود که داده‌های یک وب سایت تجاری به کمک CDC و Debezium از پستگرس دریافت و وارد کافکا شود. در مرحله بعد هم این داده‌ها به صورت خودکار توسط کلیک‌هوس دریافت شده و در جداول تحلیلی متناظر در Clickhouse‌ ذخیره شده و نهایتا با ابزارهای گرافیکی نمایش داده شود.
برای تولید داده‌ها هم از ایرفلو در بازه‌های زمانی کوتاه برای شبیه سازی یک وب‌سایت خرید و فروش محصول، استفاده شود.
خروجی ای که آقا بهنام یزدان‌پناهی @behnamyzp عزیز آماده کرد خیلی فراتر از انتظارم بود.
کل پروژه که روند فوق در آن پیاده سازی شده و نتایج در گرافانا نمایش داده شده است به همراه توضیحات لازم برای اجرای آن در آدرس زیر قرار گرفته است :‌
https://github.com/behnamyazdan/ecommerce_realtime_data_pipeline/
برای دوستانی که علاقه‌مند به حوزه مهندسی داده و مباحث زیرساختی هستند، یک نقطه شروع بسیار عالی است و برای دوستانی که با پستگرس کار می‌کنند می‌توانند از ایده انتقال داده‌ها به کلیک هوس و اجرای کوئری‌های تحلیلی بر روی آن استفاده کنند.
هر چند بهتر است ساختار طراحی شده برای کلیک هوس تغییر کند به گونه‌ای که به جای تمامی جداول بخش خرید و فروش، چند جدول اصلی اما بزرگ (با حذف نرمال‌سازی که در دیتابیس‌های تحلیلی کاملا روال است)‌ داشته باشیم و با ابزارهایی مانند dbt، با اجرای کوئری‌هایی در بازه‌های زمانی کوتاه، این جداول تحلیلی از روی جداول پایه دریافت شده از کافکا، پرشده و جداول پایه، با تنظیم مقدار TTL‌ مناسب، به صورت خودکار حذف شوند.
ضمن تشکر مجدد از آقا بهنام عزیز ، این پست را با کسب اجازه از ایشان در اینجا منتشر میکنم. باشد که برای علاقه‌مندان، مفید باشد.
لینک توضیحات خود بهنام عزیز در لینکدین :
https://www.linkedin.com/posts/behnam-yazdanpanahi_ecommerceabrdataabrpipeline-cdc-kafka-activity-7172687833793445888-USBb
#مهندسی_داده #clickhouse #airflow #cdc #postgresql #Debezium #پستگرس #خطوط_پردازش_داده

‍ آیا ترتیب ستون‌ها در کارآیی دیتابیس، موثر است ؟
اگر شما هم فکر می‌کنید که ترتیب ستون‌ها تاثیری در اجرای کوئری ها ندارد، مقاله زیر که به بررسی این موضوع در پستگرس پرداخت است را از دست ندهید .
https://demirhuseyinn-94.medium.com/the-surprising-power-of-humble-column-ordering-in-postgresql-ce7c7d587a27
خلاصه مقاله این است که فیلد‌های با طول متغیر و فیلدهای Nullable بهتر است به انتهای لیست منتقل شوند و فیلدهای مشابه کنار هم قرار گیرند.
CREATE TABLE user_order_default (
is_shipped BOOLEAN NOT NULL DEFAULT false,
user_id BIGINT NOT NULL,
order_total NUMERIC NOT NULL,
order_dt TIMESTAMPTZ NOT NULL,
order_type SMALLINT NOT NULL,
ship_dt TIMESTAMPTZ,
item_ct INT NOT NULL,
ship_cost NUMERIC,
receive_dt TIMESTAMPTZ,
tracking_cd TEXT,
id BIGSERIAL PRIMARY KEY NOT NULL
);

CREATE TABLE user_order_tweaked (
id BIGSERIAL PRIMARY KEY NOT NULL,
user_id BIGINT NOT NULL,
order_dt TIMESTAMPTZ NOT NULL,
ship_dt TIMESTAMPTZ,
receive_dt TIMESTAMPTZ,
item_ct INT NOT NULL,
order_type SMALLINT NOT NULL,
is_shipped BOOLEAN NOT NULL DEFAULT false,
order_total NUMERIC NOT NULL,
ship_cost NUMERIC,
tracking_cd TEXT
);

‍‍‍SELECT pg_relation_size('user_order_default') AS size_bytes,
pg_size_pretty(pg_relation_size('user_order_default')) AS size_pretty;

SELECT pg_relation_size('user_order_tweaked') AS size_bytes,
pg_size_pretty(pg_relation_size('user_order_tweaked')) AS size_pretty;



size_bytes | size_pretty
------------+-------------
141246464 | 135 MB
(1 row)

size_bytes | size_pretty
------------+-------------
117030912 | 112 MB

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

#postgresql #column_ordering #postgresql_performance

‍ پستگرس که «در لطافت طبعش خلاف نیست»، به قول سعدی علیه الرحمه «در باغ لاله روید و در شوره زار خس». مفسرین بر این باورند که منظور شیخ این بوده است که این دیتابیس، گاهی اوقات بسیار عالی و خوب عمل می‌کند و برای بسیاری از کاربردهای امروزی که نیاز به کوئری‌های پیچیده روی حجم عظیم دیتای ورودی داریم، ما را با چالش‌های جدی مواجه می‌کند.
در وبینار زیر، به این پرسش اساسی پاسخ می‌دهیم که اگر با پستگرس در مواجهه با داده‌های زیاد به چالش برخوردیم،‌ چه کنیم و اصلا آیا پستگرس برای خیلی از نیازمندیهای امروز می‌تواند گزینه مناسبی باشد یا نه ؟ مروری بر راه‌حل‌های کلاسیک این مساله و راه‌حل‌هایی که در چند سال اخیر پیش روی ما قرار گرفته است می‌پردازیم.
دیتابیس‌هایی مبتنی بر پستگرس مانند ParadeDB، دیتابیس‌هایی با پروتکل پستگرس مانند CockroachDB و RisingWave‌ و افزونه‌هایی مانند Hydra را بررسی می کنیم.
اگر در حال استفاده از پستگرس هستید و نگرانی‌هایی راجع به آن در مواجهه با نیازمندیهای جدید دارید،‌ شاید این وبینار که به صورت عملی برگزار خواهد شد، برای شما مفید باشد.
https://anisa.co.ir/fa/news/2-uncategorised/298-workshop-23.html
#پستگرس #Postgres #PostgreSQL

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

- قصد راه‌اندازی 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

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

‍ چرا دریافت نتایج کوئری گاهی اینقدر طول می‌کشد؟ ✨

با پیشرفت روزافزون فناوری دیتابیس‌ها، ضروری است که روش‌ها و پروتکل‌های انتقال داده نیز به‌روزرسانی شوند تا بتوان از تمامی ظرفیت و توان پردازشی این سیستم‌ها به‌طور مؤثر بهره‌برداری کرد.

فرض کنید به عنوان یک تحلیلگر داده، با استفاده از درایور ODBC به ClickHouse متصل شده‌اید و دستوری برای بازیابی ۱۰ هزار رکورد خاص اجرا کرده‌اید. دستور را ارسال می‌کنید و منتظر نتایج می‌مانید، اما متوجه می‌شوید که زمان دریافت نتایج به طرز معناداری بیشتر از زمانی است که همان دستور را مستقیماً در خط فرمان ClickHouse اجرا کرده‌اید. 😕 این تفاوت زمانی از کجا می‌آید و چرا برای کاربرانی مثل شما که با داده‌های بزرگ کار می‌کنید، مهم است؟

دلیل اصلی این کندی، به نحوه عملکرد درایورهای سنتی مانند ODBC برمی‌گردد. ClickHouse یک دیتابیس تحلیلی است که از ذخیره‌سازی ستونی استفاده می‌کند—ساختاری که برای پردازش سریع داده‌های حجیم بهینه شده است. اما درایورهای ODBC برای دیتابیس‌های ردیفی طراحی شده‌اند و مجبورند داده‌های ستونی را به فرمت ردیفی تبدیل کنند. این تبدیل، هم زمان‌بر است و هم منابع زیادی مصرف می‌کند، که نتیجه‌اش کاهش عملکرد و تأخیر در دریافت داده‌هاست. ⏳ برای تحلیلگران داده، مهندسین داده و دانشمندان داده که به سرعت و کارایی وابسته هستند، این یک چالش جدی است.

🚀 فرمت Arrow: استانداردی برای پردازش سریع داده‌های تحلیلی
سال‌هاست که Apache Arrow به عنوان یک فرمت درون حافظه برای کار با داده‌های ستونی، به یک استاندارد رایج برای پردازش سریع و بهینه داده‌های تحلیلی تبدیل شده است. Arrow با طراحی خاص خود، سربار ناشی از تبدیل داده‌ها بین فرمت‌های مختلف را حذف می‌کند و امکان پردازش موازی را فراهم می‌آورد. این یعنی شما می‌توانید داده‌های بزرگ را با سرعت بیشتری تحلیل کنید. 📊 این فرمت با ابزارهای محبوبی مثل Pandas، Apache Spark و Dask سازگار است و به همین دلیل، برای جامعه داده به یک انتخاب ایده‌آل تبدیل شده است.

حالا تصور کنید اگر بتوانید همین سرعت و کارایی را مستقیماً در ارتباط با دیتابیس‌ داشته باشید. ADBC دقیقا با همین هدف و توسط پروژه محبوب Arrow توسعه داده شد.

🌟 کتابخانه ADBC: راهکاری مدرن برای ارتباط سریع با دیتابیس‌ها
اینجاست که ADBC (Arrow Database Connectivity) وارد می‌شود! ADBC یک رابط برنامه‌نویسی کاربردی (API) مدرن است که به شما اجازه می‌دهد داده‌ها را به صورت مستقیم و در فرمت ستونی از دیتابیس‌هایی مثل ClickHouse یا حتی پستگرس دریافت کنید. با ADBC، دیگر نیازی به تبدیل‌های وقت‌گیر به فرمت ردیفی نیست—داده‌ها با همان ساختار ستونی که برای تحلیل بهینه است، به اپلیکیشن شما منتقل می‌شوند. 🚄

🎯 مزایای ADBC برای تحلیلگران و مهندسین داده
- سرعت بیشتر: حذف تبدیل‌های ردیفی، زمان دریافت داده‌ها را به شدت کاهش می‌دهد.
- پشتیبانی از استریمینگ: داده‌ها به صورت پیوسته و بدون وقفه منتقل می‌شوند.
- انعطاف‌پذیری: با دیتابیس‌های مختلف، از ClickHouse تا PostgreSQL، کار می‌کند.
- اکوسیستم کامل: یک API یکپارچه با ابزارهایی مثل Flight SQL که کار توسعه و کاربرد آنرا ساده‌تر می‌کنند.

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

#DataEngineering #Database #ADBC #ApacheArrow #BigData #PerformanceOptimization #DuckDB #PostgreSQL


منبع : https://arrow.apache.org/blog/2025/02/28/data-wants-to-be-free/