Data warehouse — OLAP, star schema আর ETL

১ · OLTP আর OLAP — একই ডেটা, দুই ধরনের কাজ

এতদিন যে ডেটাবেস দেখেছেন, তার কাজ প্রতিদিনের লেনদেন: একটি অর্ডার ঢোকানো, একটি স্টক কমানো, একজন গ্রাহকের ঠিকানা দেখা। এই ধরনের কাজের নাম OLTP (online transaction processing). প্রতিটি কোয়েরি অল্প কয়েকটি সারি ছোঁয়, primary key বা index ধরে, আর মিলিসেকেন্ডে শেষ হয়। কিন্তু দোকানের মালিক মাসের শেষে জানতে চান: “গত ছয় মাসে কোন শহরে কোন শ্রেণির বিক্রি সবচেয়ে বেড়েছে?” এই প্রশ্ন কয়েকটি সারি নয়, প্রায় সব সারি পড়ে আর যোগ করে। এই কাজের নাম OLAP (online analytical processing).

এই পর্বের লাইভ SQL চলে দোকানের ডেটাবেসে (db-shop): customers (customer_id, name, city, phone, joined_on — ৮ জন), categories (category_id, name — ৪টি শ্রেণি), products (product_id, name, category_id, price, stock — ১০টি পণ্য), orders (order_id, customer_id, order_date, status — ১০টি অর্ডার, ২০২৫-এর সেপ্টেম্বর আর অক্টোবরে; status হলো pending, shipped, delivered বা cancelled) আর order_items (order_id, product_id, quantity, unit_price — ১৬টি লাইন; unit_price বিক্রির মুহূর্তের দাম)। এটিই আমাদের “চালু সিস্টেম”; এর থেকে আমরা একটি ছোট warehouse বানাব। প্রতিবার চালালে ডেটাবেস নতুন করে তৈরি হয়, আর একটি এডিটরের স্টেটমেন্টগুলো একটি সংযোগে পরপর চলে — কোনোটিতে ত্রুটি হলে সেখানেই থামে।

২ · আলাদা warehouse কেন — আর Inmon বনাম Kimball

চালু ডেটাবেসের একটি read replica-তেই তো রিপোর্ট চালানো যায় (পর্ব ৫২)? ছোট দোকানে প্রায়ই সেটাই যথেষ্ট। কিন্তু প্রতিষ্ঠান বড় হলে তিনটি কারণে আলাদা warehouse লাগে:

Bill Inmon-এর একটি পরিচিত সংজ্ঞায় warehouse হলো subject-oriented, integrated, time-variant, non-volatile ডেটার সংগ্রহ, যা ব্যবস্থাপনার সিদ্ধান্তে সাহায্য করে — অর্থাৎ বিষয় ধরে সাজানো (বিক্রি, গ্রাহক), বহু উৎস মিলিয়ে একরূপ, সময়ের সাথে ইতিহাসসহ, আর একবার বসানো ডেটা সাধারণত বদলানো হয় না। এই লক্ষ্যে পৌঁছানোর দুটি বিখ্যাত পথ আছে:

দুই পদ্ধতিই আজও ব্যবহৃত, আর বাস্তবে অনেক দল মিশিয়ে চলে: কাঁচা ডেটা একটি সংহত স্তরে, আর বিশ্লেষকের সামনে star schema. Data Vault-এর মতো তৃতীয় পদ্ধতিও আছে। “কোনটি সঠিক” — এই প্রশ্নের চেয়ে জরুরি হলো, আপনার দলের আকার আর ডেটার উৎস কোন পথে মানায় (প্রশ্ন ০১)।

৩ · Dimensional modeling — আগে grain, তারপর fact আর dimension

Dimensional modeling-এ টেবিল দুই রকম। Fact টেবিল-এর প্রতিটি সারি একটি মাপা ঘটনা — একটি বিক্রি, একটি পেমেন্ট, একটি ট্রেনের টিকিট — আর তাতে থাকে সংখ্যা, যাদের বলে measure (পরিমাণ, টাকা)। Dimension টেবিল ঘটনার প্রেক্ষাপট দেয়: কখন (তারিখ), কে (গ্রাহক), কী (পণ্য), কোথায় (শাখা, শহর)। রিপোর্টের ভাষায়, dimension দিয়ে “অনুযায়ী” ভাগ করেন (“শহর অনুযায়ী”), আর measure যোগ করেন।

Kimball-এর চার ধাপের নকশা-পদ্ধতি: ১) ব্যবসার প্রক্রিয়া বাছুন; ২) grain ঘোষণা করুন — fact-এর এক সারি ঠিক কী; ৩) dimension বাছুন; ৪) measure বাছুন। ক্রমটি গুরুত্বপূর্ণ: grain আগে না ঠিক করলে কোন dimension বসবে আর কোন সংখ্যা যোগ করা নিরাপদ, কিছুই ঠিক হয় না। মিশ্র grain-এর টেবিল — কিছু সারি অর্ডার, কিছু সারি অর্ডার-লাইন — যোগফল চুপচাপ দ্বিগুণ করে। নিচের stepper-এ db-shop-এর বিক্রির জন্য তিনটি grain যাচাই করুন:

৪ · Star schema আর snowflake schema — db-shop থেকে লাইভ বানানো

Star schema-এ মাঝে fact টেবিল, চারপাশে dimension — প্রতিটি dimension fact থেকে ঠিক এক ধাপ দূরে। dimension ইচ্ছে করে denormalized: পণ্যের dimension-এ শ্রেণির নাম সরাসরি একটি কলাম (পর্ব ৩৮)। dimension আবার normalized করে ভাঙলে — পণ্য থেকে শ্রেণি, তারিখ থেকে মাস আলাদা টেবিলে — নকশার নাম snowflake schema:

কোনটি ভালো? Kimball-ধারা সাধারণত star পছন্দ করে: কোয়েরি সহজ, BI টুল সহজে বোঝে, আর dimension fact-এর তুলনায় এত ছোট যে কপি করা নামের জায়গা প্রায় নগণ্য। snowflake কাজে আসে যখন একটি dimension বিশাল আর তার একটি অংশ বারবার বদলায়, বা একই উপ-টেবিল বহু dimension ভাগ করে। এবার db-shop থেকে আসল star বানানো যাক। CREATE TABLE AS SELECT একটি SELECT-এর ফল থেকে সরাসরি টেবিল বানায় — ছোট ETL-এর জন্য যথেষ্ট:

CREATE TABLE dim_product AS
SELECT p.product_id AS product_key, p.name AS product_name, c.name AS category
FROM products p JOIN categories c ON c.category_id = p.category_id;
CREATE TABLE dim_customer AS
SELECT customer_id AS customer_key, name, COALESCE(city, 'Unknown') AS city
FROM customers;
CREATE TABLE fact_sales AS                    -- grain: একটি অর্ডার-লাইন
SELECT i.order_id,
       CAST(strftime('%Y%m%d', o.order_date) AS INTEGER) AS date_key,
       o.customer_id AS customer_key, i.product_id AS product_key,
       i.quantity, i.quantity * i.unit_price AS amount
FROM orders o JOIN order_items i ON i.order_id = o.order_id
WHERE o.status <> 'cancelled';
SELECT COUNT(*) AS lines, COUNT(DISTINCT order_id) AS orders, SUM(amount) AS revenue
FROM fact_sales;

Date dimension — recursive CTE দিয়ে প্রতিটি দিনের একটি সারি

“শুক্র-শনিবারে বিক্রি কেমন?”, “ঈদের সপ্তাহে কত?” — এমন প্রশ্নে প্রতিবার তারিখ-ফাংশন লেখার বদলে warehouse-এ একটি date dimension থাকে: প্রতিটি দিনের একটি সারি, সাথে মাস, ত্রৈমাসিক, সাপ্তাহিক ছুটি কি না, সরকারি ছুটি কি না। দিনগুলো বানানো যায় পর্ব ২৫-এর recursive CTE দিয়ে। বাংলাদেশে সাপ্তাহিক ছুটি সাধারণত শুক্র আর শনিবার; SQLite-এর strftime('%w')-এ রবিবার 0, তাই শুক্র 5, শনি 6:

CREATE TABLE dim_date AS
WITH RECURSIVE d(day) AS (
  SELECT '2025-09-01'
  UNION ALL
  SELECT DATE(day, '+1 day') FROM d WHERE day < '2025-10-31'
)
SELECT CAST(strftime('%Y%m%d', day) AS INTEGER) AS date_key,
       day AS full_date,
       strftime('%Y-%m', day) AS month,
       CASE WHEN strftime('%w', day) IN ('5', '6') THEN 1 ELSE 0 END AS is_weekend
FROM d;
SELECT COUNT(*) AS days, MIN(full_date) AS first_day, MAX(full_date) AS last_day,
       SUM(is_weekend) AS weekend_days
FROM dim_date;
SELECT * FROM dim_date WHERE full_date BETWEEN '2025-09-04' AND '2025-09-07';

৫ · ব্যবসার প্রশ্নের উত্তর — GROUP BY, ROLLUP আর window

এখন থেকে প্রতিটি এডিটরে উপরের তিনটি dimension আর fact_sales আগে থেকেই বানানো থাকে (নমুনা ডেটার বাক্সে দেখতে পাবেন)। প্রথম প্রশ্ন: মাস × শ্রেণি অনুযায়ী বিক্রি। star schema-র প্রতিটি রিপোর্ট একই আকারের — fact থেকে দরকারি dimension-এ এক ধাপের JOIN, তারপর GROUP BY (পর্ব ১৮):

SELECT d.month, p.category,
       SUM(f.quantity) AS units, SUM(f.amount) AS revenue
FROM fact_sales f
JOIN dim_date d    ON d.date_key = f.date_key
JOIN dim_product p ON p.product_key = f.product_key
GROUP BY d.month, p.category
ORDER BY d.month, revenue DESC;

রিপোর্টে প্রায়ই প্রতি মাসের উপ-মোট আর সর্বমোট লাগে। PostgreSQL, SQL Server আর Oracle-এ GROUP BY ROLLUP (month, category) একবারে (month, category), (month) আর () — তিন স্তরের ফল দেয় (ROLLUP, পর্ব ১৮)। MySQL-এ লেখা হয় GROUP BY month, category WITH ROLLUP. SQLite-এ ROLLUP নেই, তাই একই ফল তিনটি GROUP BY-এর UNION ALL দিয়ে:

WITH s AS (
  SELECT d.month, p.category, f.amount
  FROM fact_sales f
  JOIN dim_date d    ON d.date_key = f.date_key
  JOIN dim_product p ON p.product_key = f.product_key
), r AS (
  SELECT month, category, SUM(amount) AS revenue FROM s GROUP BY month, category
  UNION ALL
  SELECT month, NULL, SUM(amount) FROM s GROUP BY month
  UNION ALL
  SELECT NULL, NULL, SUM(amount) FROM s
)
SELECT * FROM r
ORDER BY month IS NULL, month, category IS NULL, category;

দ্বিতীয় প্রশ্ন: প্রতিটি শহরের সেরা গ্রাহক, আর মোট বিক্রিতে প্রত্যেকের ভাগ। এখানে লাগে পর্ব ২৬-এর window function — GROUP BY-এর পর প্রতিটি দলের সারি না হারিয়ে র‍্যাংক আর শতাংশ:

WITH spent AS (
  SELECT c.city, c.name, SUM(f.amount) AS total
  FROM fact_sales f
  JOIN dim_customer c ON c.customer_key = f.customer_key
  GROUP BY c.city, c.name
)
SELECT city, name, total,
       RANK() OVER (PARTITION BY city ORDER BY total DESC) AS rank_in_city,
       ROUND(100.0 * total / SUM(total) OVER (), 1) AS pct_of_all
FROM spent
ORDER BY total DESC;

৬ · OLAP অপারেশন আর measure-এর তিন জাত

বিশ্লেষক ডেটাকে একটি cube হিসেবে ভাবেন: প্রতিটি dimension একটি অক্ষ, প্রতিটি ঘরে একটি measure. আমাদের cube-এর তিন অক্ষ মাস, শ্রেণি আর শহর; ঘরে বিক্রির টাকা। এর ওপর পাঁচটি প্রচলিত অপারেশন — প্রতিটি আসলে একটি GROUP BY বা WHERE-এর বদল:

SELECT p.category,
       SUM(CASE WHEN d.month = '2025-09' THEN f.amount ELSE 0 END) AS sep_2025,
       SUM(CASE WHEN d.month = '2025-10' THEN f.amount ELSE 0 END) AS oct_2025
FROM fact_sales f
JOIN dim_date d     ON d.date_key = f.date_key
JOIN dim_product p  ON p.product_key = f.product_key
JOIN dim_customer c ON c.customer_key = f.customer_key
WHERE c.city IN ('Dhaka', 'Chattogram')                 -- dice
  AND p.category IN ('Electronics', 'Grocery')
GROUP BY p.category
ORDER BY p.category;

সব সংখ্যা যোগ করা যায় না — additive, semi-additive আর non-additive

Roll-up মানে যোগ। কিন্তু যোগ সব measure-এ অর্থবহ নয়:

একটি উদাহরণে non-additive-এর ফাঁদ: সেপ্টেম্বরে আলাদা ক্রেতা ৪ জন, অক্টোবরে ৪ জন — দুই মাসে কি ৮ জন? না; Rahim আর Karima দুই মাসেই কিনেছেন, তাই আসলে ৬ জন। COUNT(DISTINCT) দিনের বা মাসের স্তরে জমিয়ে রাখলে ওপরের স্তরে যোগ করা যায় না। যে fact টেবিলে প্রতিদিন প্রতিটি অ্যাকাউন্টের ব্যালান্সের একটি সারি থাকে, তাকে বলে periodic snapshot fact — আমাদের fact_sales-এর মতো প্রতিটি ঘটনার একটি সারি (transaction fact) থেকে তার grain আলাদা।

৭ · Slowly changing dimension — গ্রাহক শহর বদলালে ইতিহাসের কী হয়

Rahim Uddin ২০২৫-এর ৫ অক্টোবর Dhaka থেকে Chattogram-এ চলে গেলেন। চালু সিস্টেমে customers.city সোজা UPDATE হবে — সেটিই ঠিক, কারণ কুরিয়ারকে নতুন ঠিকানা লাগবে। কিন্তু warehouse-এ প্রশ্ন ওঠে: সেপ্টেম্বরের “ঢাকার বিক্রি”-তে Rahim-এর কেনাকাটা থাকবে, না Chattogram-এ সরে যাবে? যে dimension-এর মান মাঝে মাঝে বদলায়, তার নাম slowly changing dimension (SCD), আর বদল রাখার তিনটি প্রচলিত নিয়ম:

• Type 1 — মুছে লেখা: dim_customer-এর city সোজা বদলান। সহজ, কিন্তু ইতিহাস হারায়: Rahim-এর সব পুরোনো বিক্রি এখন Chattogram-এর। নামের বানান ঠিক করার মতো ভুল-সংশোধনে এটিই ঠিক।
• Type 2 — নতুন সারি: পুরোনো সারি বন্ধ করুন (valid_to, is_current = 0), নতুন surrogate key-সহ নতুন সারি যোগ করুন। পুরোনো fact পুরোনো সারির key ধরে থাকে, তাই ইতিহাস অটুট।
• Type 3 — আগের মানের কলাম: city-র পাশে previous_city. শুধু একটি আগের মান রাখা যায়; “পুরোনো আর নতুন অঞ্চল-ভাগে পাশাপাশি তুলনা”-র মতো নির্দিষ্ট কাজে।

Type 2-ই সবচেয়ে প্রচলিত, আর এখানেই surrogate key অপরিহার্য: একই customer_id (business key) এখন দুটি সারিতে, তাই সারি চেনাতে আলাদা key লাগে। ধাপে ধাপে দেখুন:

এখন নিজে চালান। এই এডিটরে dim_customer আগে থেকেই type 2 আকারে বানানো: customer_sk (INTEGER PRIMARY KEY, তাই SQLite নিজে বাড়ায়), customer_id, name, city, valid_from (যোগদানের দিন), valid_to ('9999-12-31') আর is_current (1), ৮ জনের ৮টি সারি:

-- 2025-10-05: Rahim (customer_id 1) Dhaka থেকে Chattogram-এ গেলেন
BEGIN;
UPDATE dim_customer SET valid_to = '2025-10-04', is_current = 0
WHERE customer_id = 1 AND is_current = 1;
INSERT INTO dim_customer (customer_id, name, city, valid_from, valid_to, is_current)
VALUES (1, 'Rahim Uddin', 'Chattogram', '2025-10-05', '9999-12-31', 1);
COMMIT;
SELECT customer_sk, customer_id, city, valid_from, valid_to, is_current
FROM dim_customer WHERE customer_id = 1;
SELECT COUNT(*) AS rows_total, SUM(is_current) AS current_rows FROM dim_customer;

এবার fact লোড করার সময় point-in-time join দিয়ে প্রতিটি লাইনের সঠিক customer_sk খোঁজা, আর শহর অনুযায়ী বিক্রি। এই এডিটরে উপরের বদলটি আগেই হয়ে আছে:

CREATE TABLE fact_sales AS
SELECT i.order_id, o.order_date, d.customer_sk,
       i.quantity * i.unit_price AS amount
FROM orders o
JOIN order_items i  ON i.order_id = o.order_id
JOIN dim_customer d ON d.customer_id = o.customer_id
                   AND o.order_date BETWEEN d.valid_from AND d.valid_to
WHERE o.status <> 'cancelled';
SELECT d.city, SUM(f.amount) AS revenue
FROM fact_sales f JOIN dim_customer d ON d.customer_sk = f.customer_sk
GROUP BY d.city ORDER BY revenue DESC;

৮ · ETL, ELT আর incremental load — ডেটা warehouse-এ আসে কীভাবে

পর্ব ৩৮-এ দেখেছেন, যেকোনো কপির দুটি প্রশ্ন: কীভাবে হালনাগাদ থাকবে, আর ভুল হলে কীভাবে ধরব। warehouse পুরোটাই একটি বিশাল কপি, তাই উত্তরটি একটি নিয়মিত pipeline: ETL — Extract (উৎস থেকে তোলা), Transform (পরিষ্কার, মেলানো, key খোঁজা), Load (warehouse-এ বসানো)। পুরোনো ধারায় রূপান্তর হতো আলাদা একটি ETL সার্ভারে। cloud warehouse আসার পর প্রচলিত হয়েছে ELT: কাঁচা ডেটা আগে warehouse-এর একটি স্তরে বসে, তারপর রূপান্তর হয় warehouse-এর ভেতরেই, SQL দিয়ে — কারণ সেখানে গণনার শক্তি সহজে বাড়ানো যায়, আর কাঁচা কপি থাকলে পরে নিয়ম বদলে আবার চালানো যায়।

প্রতিদিন সব ডেটা নতুন করে আনা (full load) ছোট টেবিলে চলে, বড় টেবিলে নয়। Incremental load শুধু নতুন বা বদলানো সারি আনে। সবচেয়ে সরল উপায় watermark: শেষবার কোন সময় পর্যন্ত আনা হয়েছে, একটি ছোট টেবিলে লিখে রাখা। এই এডিটরে fact_sales-এ ৩০ সেপ্টেম্বর পর্যন্ত লোড হয়ে আছে, আর etl_watermark টেবিলে (source, last_loaded) = ('orders', '2025-09-30'):

SELECT COUNT(*) AS lines_before, SUM(amount) AS revenue_before FROM fact_sales;
INSERT INTO fact_sales
SELECT i.order_id, CAST(strftime('%Y%m%d', o.order_date) AS INTEGER),
       o.customer_id, i.product_id, i.quantity, i.quantity * i.unit_price
FROM orders o JOIN order_items i ON i.order_id = o.order_id
WHERE o.status <> 'cancelled'
  AND o.order_date > (SELECT last_loaded FROM etl_watermark WHERE source = 'orders');
UPDATE etl_watermark SET last_loaded = (SELECT MAX(order_date) FROM orders)
WHERE source = 'orders';
SELECT COUNT(*) AS lines_after, SUM(amount) AS revenue_after,
       (SELECT last_loaded FROM etl_watermark) AS watermark
FROM fact_sales;

লোড শেষ হলেই কাজ শেষ নয়। প্রতিটি লোডের পর স্বয়ংক্রিয় data quality check চলে, আর কোনোটি ব্যর্থ হলে রিপোর্ট আটকে সতর্কবার্তা যায়। এই এডিটরে একটি দুর্ঘটনা সাজানো আছে: অর্ডার 1010-এর লাইনটি ভুল করে দুবার লোড হয়েছে (যেন একটি batch দুবার চলেছে):

SELECT 'grain-এ duplicate' AS check_name, COUNT(*) AS problems
FROM (SELECT order_id, product_key FROM fact_sales
      GROUP BY order_id, product_key HAVING COUNT(*) > 1)
UNION ALL
SELECT 'অচেনা product_key', COUNT(*)
FROM fact_sales f LEFT JOIN dim_product p ON p.product_key = f.product_key
WHERE p.product_key IS NULL
UNION ALL
SELECT 'amount শূন্য বা ঋণাত্মক', COUNT(*) FROM fact_sales WHERE amount <= 0
UNION ALL
SELECT 'উৎসের সাথে টাকার পার্থক্য',
       (SELECT SUM(amount) FROM fact_sales)
     - (SELECT SUM(i.quantity * i.unit_price) FROM order_items i
        JOIN orders o ON o.order_id = i.order_id WHERE o.status <> 'cancelled');

৯ · Column store, MPP, cloud warehouse আর lakehouse

বিশ্লেষণের কোয়েরি সাধারণত চওড়া টেবিলের অল্প কয়েকটি কলাম পড়ে, কিন্তু প্রায় সব সারি। পর্ব ৩৯-এর row store-এ একটি page-এ পুরো সারিগুলো পাশাপাশি থাকে, তাই দুটি কলাম পড়তেও পুরো সারি ডিস্ক থেকে আনতে হয়। ধরুন fact-এর প্রতিটি সারি ২০০ বাইট, আর কোয়েরি লাগে ৮ বাইটের দুটি কলাম: row store পড়ে ২০০ বাইট, column store পড়ে ১৬ বাইট — compression-এর আগেই কাজের মাত্র ৮ শতাংশ। column store-এ প্রতিটি কলাম আলাদা ধারায় থাকে, আর একই ধরনের মান পাশাপাশি থাকায় compression খুব ভালো কাজ করে:

• Dictionary encoding: category কলামে মাত্র ৪টি আলাদা মান; প্রতিটি সারিতে পুরো লেখার বদলে একটি ছোট সংখ্যা (৪টি মানে ২ বিটই যথেষ্ট), সাথে একটি অভিধান।
• Run-length encoding: date_key ধরে সাজানো fact-এ একই তারিখ হাজারো বার পরপর — রাখা হয় শুধু (মান, কতবার)।
• Min/max সারাংশ: প্রতিটি খণ্ডের সর্বনিম্ন আর সর্বোচ্চ মান রাখা থাকে; “অক্টোবরের বিক্রি” কোয়েরি যে খণ্ডের পরিসরে অক্টোবর নেই, তা পড়েই না।
• Vectorized execution: একটি একটি সারি না ধরে হাজারখানেক মানের ব্যাচে কাজ — CPU-র cache আর SIMD নির্দেশ ভালোভাবে কাজে লাগে।

দাম আছে: একটি সারি ঢোকাতে বা বদলাতে বহু কলাম-ধারায় লিখতে হয়, তাই column store একটি একটি সারির OLTP কাজে দুর্বল, বড় ব্যাচের লোডে ভালো। এজন্যই চালু সিস্টেম row store, warehouse column store.

ডেটা এক যন্ত্রে না ধরলে MPP: টেবিলের সারি অনেক সার্ভারে ভাগ করা (পর্ব ৫৪-এর partitioning), প্রতিটি সার্ভার নিজের অংশে GROUP BY চালিয়ে আংশিক যোগফল বানায়, তারপর আংশিক ফলগুলো জোড়া লাগে। এখানে measure-এর জাত আবার কাজে আসে: SUM-এর SUM সঠিক; AVG-এর জন্য প্রতিটি অংশ (sum, count) পাঠায়, গড়ের গড় নয়; COUNT(DISTINCT) সবচেয়ে কঠিন — নির্ভুল উত্তরে মানগুলো এক জায়গায় আনতে হয়, তাই অনেক সিস্টেমে আনুমানিক ফাংশন (যেমন HyperLogLog-ভিত্তিক) থাকে।

কোনটি “সেরা”, তার সর্বজনীন উত্তর নেই — খরচের মডেল, দলের দক্ষতা আর ডেটার আকার অনুযায়ী বদলায়, আর এই বাজার দ্রুত বদলাচ্ছে। শেষ ধাপে মানুষ ডেটা দেখেন BI টুল দিয়ে — Microsoft Power BI, বা open source Metabase আর Apache Superset — যারা warehouse-এ SQL পাঠিয়ে চার্ট আর dashboard বানায়। আর ELT-এর রূপান্তর-ধাপ আজকাল প্রায়ই লেখা হয় dbt-এ: প্রতিটি ধাপ একটি SELECT ফাইল, টুলটি নির্ভরতার ক্রমে চালায়, আর “এই কলাম unique”, “এই key dim-এ আছে” — অংশ ৮-এর পরীক্ষাগুলো ঘোষণা করে লেখা যায়। এই কাজের নতুন নাম analytics engineering: সফটওয়্যারের মতো version control, code review আর test — কিন্তু SQL-এ।

১০ · AI-এর যুগে warehouse আর বিশ্লেষণের SQL

“গত মাসের শহরভিত্তিক বিক্রি দাও” — AI সেকেন্ডে কোয়েরি লেখে, আর সেটি চলেও। কিন্তু বিশ্লেষণের ভুল ত্রুটি-বার্তা দেয় না, শুধু একটি ভুল সংখ্যা দেয়, যা একটি সভায় সিদ্ধান্ত হয়ে যায়। সাধারণ ভুলগুলো:

AI-এর লেখা বিশ্লেষণের কোয়েরি রিপোর্টে বসানোর আগে — চেকলিস্ট

• fact-এর grain জানি, আর কোয়েরির প্রতিটি JOIN সেই grain বদলায় কি না দেখেছি
• কোয়েরির মোট টাকা fact টেবিলের সরাসরি SUM-এর সাথে মিলিয়েছি
• type 2 dimension-এ surrogate key বা সময়ের শর্ত দিয়ে JOIN হয়েছে
• শতাংশ, গড় আর আলাদা-সংখ্যা লব-হর থেকে হিসাব হয়েছে; ব্যালান্স সময় ধরে যোগ হয়নি
• NULL, 'Unknown', শূন্য-বিক্রির দল আর বাতিল অর্ডারের নিয়ম নমুনা ডেটায় হাতে যাচাই করেছি
• বড় টেবিলে EXPLAIN দেখে নিশ্চিত হয়েছি যে partition বা min/max সারাংশ কাজে লাগছে, পুরো টেবিল পড়ছে না