Belajar Data Architect - AI-Ready Data Architecture

#Pendahuluan

Setelah di episode 20 kita membangun lineage dan audit, sekarang kita menghadapi arah baru yang mengubah peran arsitek: AI-Ready Data Architecture. Di 2026, organisasi tidak lagi bertanya "apakah kita perlu AI?" — mereka bertanya "apakah data kita siap untuk AI?". Dan jawabannya hampir selalu ditentukan oleh arsitektur data.

Mengapa episode ini penting? Karena AI mengubah pola konsumsi data secara fundamental: model machine learning butuh fitur yang konsisten antara training dan inference, sementara LLM dan RAG butuh data tidak terstruktur yang bisa dicari secara vektor. Keduanya adalah beban kerja baru yang tidak dilayani warehouse tradisional — dan arsiteklah yang merancang jalannya.

#Mengapa Data AI Berbeda dari Data BI

BI dan AI mengonsumsi data secara berbeda:

Masalah klasik yang harus dicegah arsitek: model dilatih dengan data yang berbeda dari data yang dilihat saat inference — karena training memakai batch offline, sementara inference memakai data real-time yang transformasinya beda. Ini disebut training-serving skew, dan feature store ada untuk menyelesaikannya.

#Feature Store

Feature store adalah lapisan yang menyediakan fitur (kolom yang dihitung dari data mentah) secara konsisten untuk training dan inference. Dua fungsi utama:

1. Offline store: penyimpanan historis fitur untuk training.
2. Online store: penyimpanan low-latency untuk inference real-time.

data mentah → transformasi (dbt/Spark) → feature definitions
                                          ├→ offline store (training)
                                          └→ online store (inference, low latency)

Konsistensi terjamin karena definisi fitur ditulis sekali dan dijalankan oleh mekanisme yang sama untuk kedua store. Contoh tool: Feast, Tecton, atau fitur bawaan Databricks/Snowflake.

Contoh definisi fitur (konsep Feast)

# feature: total orders 30 hari per customer
Feature(
    name="orders_30d",
    owner="tim-data",
    source="SELECT customer_id, SUM(amount) AS orders_30d
            FROM gold.fact_orders
            WHERE order_date >= DATE_SUB(CURRENT_DATE(), 30)
            GROUP BY customer_id",
    entities=["customer"],
    online=True,
)

#Vector Database dan Data untuk LLM/RAG

LLM tidak "mengingat" data perusahaan. RAG (Retrieval-Augmented Generation) menjembataninya: dokumen perusahaan dipecah, di-embedding, disimpan di vector database, dan saat user bertanya, dokumen relevan diambil dan disertakan ke LLM sebagai konteks.

Poin arsitektural yang harus dipahami:

• Embedding pipeline adalah pipeline data baru: chunking, embedding, indexing, update. Ia butuh lineage dan quality check sama seperti pipeline biasa (episode 6, 9).
• Vector DB (milvus, qdrant, pgvector, opensearch) punya data lifecycle sendiri: sumber dokumen berubah → embedding harus di-update → versi dokumen dipertahankan.
• Data governance berlaku (episode 8): jangan sampai dokumen internal masuk ke RAG tanpa kontrol akses — LLM yang menjawab dengan dokumen rahasia adalah kebocoran data yang elegan.

#Arsitektur Data untuk AI: Gambaran Utuh

DATA SOURCES (structured + unstructured)
   → lakehouse (bronze/silver/gold)  → gold tables (BI & feature source)
   → feature store (offline + online) → model ML → serving
   → embedding pipeline → vector DB → RAG/LLM
   → semantic layer (episode 11) → konsistensi metrik lintas AI & BI

Prinsip desain:

1. Data AI berasal dari lapisan yang sama (gold/lakehouse) — bukan silo terpisah. Kalau BI dan AI memakai sumber berbeda, definisi data pun beda.
2. Feature definitions sebagai kode — di-version, di-review, ber-lineage (episode 20).
3. Kualitas dan observability melekat — data rusak yang masuk ke training akan menghasilkan model yang rusak, dan jauh lebih sulit dideteksi daripada dashboard yang salah.
4. Governance mencakup data untuk AI — termasuk AI Act (episode 19): dokumentasi sumber training data.

#Praktik: Merancang Arsitektur untuk AI

#Step 1: Inventarisasi Beban AI

- ML tradisional (prediksi churn, forecast) → butuh feature store
- LLM chat internal (tanya dokumen) → butuh embedding pipeline + vector DB
- AI agent yang akses database → butuh access control + audit (episode 18)

#Step 2: Tentukan Sumber Kebenaran

Pastikan semua fitur dan embedding dihitung dari sumber yang sama (gold layer) — tidak ada definisi ganda untuk AI.

#Step 3: Pilih Tooling

Pilih feature store, vector DB, dan embedding pipeline yang sesuai ekosistem yang sudah ada (Databricks/Snowflake punya fitur bawaan; Feast untuk stack open).

#Step 4: Tetapkan SLO AI Data

Kualitas data untuk AI diukur seperti BI: freshness fitur, akurasi embedding, keberadaan lineage sumber training. Masukkan ke SLO data yang sudah ada (episode 9).

#Penutup

Inti yang harus dibawa pulang:

• AI butuh feature store (konsistensi training-serving) dan vector DB (untuk LLM/RAG).
• Data AI harus berasal dari lapisan yang sama dengan BI — bukan silo terpisah.
• Embedding pipeline adalah pipeline data yang butuh lineage, kualitas, dan lifecycle.
• Access control berlaku juga untuk RAG — jangan sampai LLM membocorkan data internal.
• Arsitektur AI-ready = sumber tunggal + definisi fitur sebagai kode + SLO AI data.

Di episode 22 selanjutnya kita akan membahas Vector & Unstructured Data — vector database, embedding pipeline, dan knowledge graph untuk data yang selama ini di luar jangkauan warehouse. Sampai jumpa di episode 22!