[BDD 2025 - Artificial Intelligence] Building a Data Architecture for Sub-Second Analysis

Ridha Ginanjar | Pengen Manfaatin Data
Building a Data
Architecture
for Sub-Second
Analysis

Education:
Ridha Ginanjar
Work Experiences:
● Associate Lead Curriculum
Developer @ Dicoding
Indonesia
● Sunan Gunung Djati
University, Bachelor of
Engineering
Ridha Ginanjar

Ini Cerita dari Kami…
https://www.dicoding.com/impact
Kami ingin menganalisis,
tapi query-nya terlalu lama.

“Arsitektur data adalah proses paling fundamental untuk
membuat hasil analisis lebih baik, bahkan untuk kebutuhan proyek
AI sekalipun.”
Mengapa Arsitektur Data?

AI/ML Project Analytics Project

Dalam dunia data, sub-second analysis menggambarkan seberapa
rendah latency data yang dimiliki, sehingga dapat diproses dan
langsung siap digunakan oleh pengguna.
Tujuan: Analisis Cepat!

Query analisis berasal langsung dari berbagai sumber data
yang dimiliki oleh perusahaan
Tantangan: The Data Chaos

Bagaimana cara mengatasinya?
Salah satunya adalah…
Data Architecture

Urgensi High-Performance Analytics
Arsitektur data yang tepat bukan hanya soal memenuhi
kebutuhan operasional, tapi juga pondasi yang bisa mendorong
kecepatan dan kualitas analisis.
Arsitektur data untuk analisis, harus mampu memberikan dua
hal:
● Pengalaman pengguna (stakeholders) yang sederhana dan
intuitif.
● Performa query yang cepat agar organisasi dapat
mengambil keputusan dengan lebih gesit.

Ada perbedaan antara data untuk Transaksi dan juga data untuk Analisis.
Mari Mulai dari Dasar..

OLTP dan OLAP
Memahami sistem data yang eﬁsien harus memastikan kita paham perbedaan antara basis data OLTP dan
OLAP.
● Dibuat untuk memproses transaksi cepat dalam
jumlah besar.
● Menjaga integritas data dan mendukung banyak
pengguna pada waktu yang sama.
● Cocok untuk pekerjaan rutin harian seperti input
data, update informasi, atau pencatatan transaksi.
● Fokus pada analisis data, penggabungan informasi,
dan query ad-hoc.
● Mampu mengolah dataset besar dengan struktur
yang kompleks.
● Jadi fondasi utama untuk data warehouse dan BI
(Business Intelligence).

OLTP: Transactional Database
Data transaksional hampir selalu
diimplementasikan menggunakan struktur yang
sangat ternormalisasi (highly normalized).
Model ini sering disebut sebagai model
Entity-Relationship (ER) atau Third Normal Form
(3NF)

Transactional Database: Trade-off for
Analysis
Struktur 3NF membagi data menjadi banyak entitas
diskrit.
● Query menjadi lebih lama karena banyak entitas
diskrit.
● Stakeholder sulit memahami data yang
ternormalisasi.

— Kata Si Bro
“Normalize for transactions,
Denormalize for analytics.”

Kimball Architecture
Model arsitektur data ini pertama kali
diperkenalkan oleh Ralph Kimball.
Ada beberapa layer yang perlu diperhatikan.
● Transactional Source
● ETL Systems
● Data Warehouse
● Presentation Area/Reporting Layer

The Key: ETL System (1)
Extract, Transform, dan Load (ETL)
memindahkan dan membersihkan data agar siap
untuk dianalisis.

The Key: Dimensional Modelling (2)
Kimball merekomendasikan bahwa data yang
dapat di-query harus berupa dimensional ketika
sampai pada Presentation Area.

Dimensional Modelling
Teknik perancangan yang digunakan untuk “menata” data dalam data warehouse. Terdiri dari dua jenis:
Fact tables dan Dimension Table.
● Fact tables mencatat kejadian bisnis yang
bisa diukur.
● Dimension tables memberi informasi
pendukung yang memberi konteks pada
tabel fakta (Who, What, Where, When,
How).
* Dikenal juga sebagai star-schema

Tentang: Fact Tables
Fact table adalah pusat dari model data yang bertugas untuk
mencatat metrik yang dihasilkan dalam setiap kejadian bisnis atau
transaksi yang terjadi.
Tabel ini dideﬁnisikan berdasarkan tingkat “Granularity-nya”,
yakni seberapa detail level data yang kita putuskan untuk
disimpan.

Tipe-tipe Fact Tables
Transaction Fact Tables
Mencatat setiap transaksi pada tingkat detail
paling rendah untuk analisis yang ﬂeksibel
dan menyeluruh.
Contohnya: Penjualan Individu
Periodic Snapshot Fact Tables
Merangkum aktivitas dalam periode
waktu tertentu untuk melihat kinerja
atau kondisi secara berkala.
Contoh: Pelaporan Barang Bulanan
Factless Fact Tables
Mencatat kejadian tanpa nilai numerik untuk
menunjukkan apa yang terjadi maupun tidak
terjadi.
Contoh: Riwayat panggilan Customer Service
Accumulating Snapshot Fact Tables
Melacak progres proses yang memiliki
tahapan tetap, dengan satu baris yang
diperbarui sepanjang siklus proses.
Contoh: Riwayat pemesanan (dari
order sampai delivered)
Aggregate Fact Tables
Menyimpan ringkasan data yang
sudah diakumulasi untuk
mempercepat proses query dan
analisis.

Tentang: Dimension
Tables
Di sisi lain, dimension table adalah jenis table yang
bertujuan untuk memberikan konteks terhadap data
numerik pada fact tables.
Biasanya akan banyak digunakan untuk ﬁltering,
grouping, drilling down, dan sebagainya.

Tipe-Tipe Dimension Table
Conformed Dimension
Dimensi yang digunakan bersama oleh beberapa fact
table sehingga analisis tetap konsisten di berbagai proses
bisnis.
Role-Playing Dimension
Dimensi table yang sama, tetapi digunakan dalam peran
berbeda di dalam fact table yang sama/berbeda.
Junk Dimension
Dimensi yang menyimpan berbagai atribut kecil
seperti ﬂag atau indikator yang jumlah nilainya sedikit
dan tidak cocok dimasukkan ke dimensi lain.
Slowly Changing Dimension (SCD)
Dimensi yang atributnya bisa berubah seiring waktu
sehingga perlu strategi khusus untuk mengelolanya.

Kenapa SCD Harus
Diperhatikan?
Data pipeline harus memproduksi hasil yang sama.
Walaupun:
- Kapanpun dijalankan
- Berapa kali dijalankan
- Berapa lama dijalankan

Type 3 (Add column)
Setiap perubahan akan tersimpan ke dalam kolom baru.
Slowly Changing Dimension (SCD)
Type 0 (Tidak ada perubahan)
Jenis atribut yang tidak berubah sama sekali seiring
berjalannya waktu.
Misalnya: Tanggal Ulang Tahun
Type 1 (Overwrite)
Jika suatu atribut berubah, catatan/record tersebut akan
diubah atau ditimpa (overwrite).
Type 2 (Add row)
Setiap perubahan akan tersimpan ke dalam baris baru,
alih-alih dihapus atau ditimpa.

Contoh SCD Type 2
Melacak perubahan yang terjadi pada
performa suatu pemain di NBA.

Meningkatkan Performa Query
Membuat proses pengambilan data menjadi lebih cepat.
Menyederhanakan Struktur Data
Menyajikan data dalam bentuk yang sederhana dan mudah
dipahami, bahkan oleh pengguna non-teknis.
Pelaporan yang Konsisten
Memastikan semua laporan dalam organisasi menggunakan
data yang sama dan konsisten.
Optimal untuk OLAP & BI Tools
Mendukung penuh aktivitas Online Analytical Processing
(OLAP).
Kalau disimpulkan..
Ini tujuan dimensional modelling

Mari lihat Contohnya…
Entity-Relationship Diagram (ERD)

Mari lihat Contohnya…
Star Schema

Data Modelling Dapat Diterapkan Dengan Cara Berikut..
Relational Database Management Systems
(RDBMS)
Data Warehouse

Fondasinya adalah data model
Data model mendeﬁnisikan struktur dan perlakuan
terhadap data dalam sistem.
Key lesson!
Pelajari teknik, setelah itu tools-nya
Pada akhirnya tools dilahirkan dengan tujuan menggapai
teknik tertentu.

Komponen Diagram Modern Stack (Rekomendasi) Legacy / Traditional Stack
Ingestion (ETL) Airbyte, Fivetran (ELT) SSIS, Informatica, Talend
Transformation dbt (Data Build Tool) Stored Procedures (PL/SQL)
Orchestration Apache Airflow, Prefect Control-M, Cron, Windows Task Scheduler
Storage (DW) Snowflake, BigQuery, Redshift Oracle DB, SQL Server On-Prem
Front End (BI) Tableau, Looker, Power BI Cloud Crystal Reports, Excel, SSRS

Thank You
ridhoginanjar
Ridha Ginanjar
Get in touch
ridhaginanjar7@gmail.com

[BDD 2025 - Artificial Intelligence] Building a Data Architecture for Sub-Second Analysis

More Related Content

Similar to [BDD 2025 - Artificial Intelligence] Building a Data Architecture for Sub-Second Analysis

More from Wintari Yasmin

Recently uploaded

[BDD 2025 - Artificial Intelligence] Building a Data Architecture for Sub-Second Analysis