بعد از اتمام دوره بیگ‌دیتای همکاران سیستم، یکی از دانشجویان این دوره به من پیام داد که اگر بخواهم یک کار عملی توی حوزه مهندسی داده انجام بدم که مفاهیم اصلی مورد نیاز را به صورت عملی کار کنم، چه پروژه ای پیشنهاد می‌دهید.
پیشنهاد من ایجاد یک خط پردازش داده بود که داده‌های یک وب سایت تجاری به کمک 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