Modern data stack

Topik ini membedah anatomi modern data stack, yaitu susunan alat yang lazim dipakai untuk membangun pipeline analitik saat ini, lapis demi lapis. Pembahasan bergerak dari sistem sumber sampai serving layer, yakni lapisan penyalur hasil akhir, disertai contoh alat yang umum dijumpai pada tiap lapisan. Setelah membaca, arsitektur pipeline pada tim data mana pun dapat dibaca dan disebutkan nama tiap bagiannya.

Makna modern data stack#

Stack adalah gabungan beberapa perangkat lunak yang dipilih untuk menyelesaikan satu beban kerja tertentu, dan pada pekerjaan analitik data gabungan itu disebut modern data stack. Ciri utamanya ada tiga, yaitu berjalan di atas cloud, memisahkan penyimpanan dari komputasi, dan mengandalkan format terbuka. Cloud adalah infrastruktur komputasi yang disewa dari penyedia layanan. Pemisahan itu berarti data dapat ditampung sebesar apa pun tanpa biaya komputasi ikut membengkak, dan komputasi dapat ditingkatkan tanpa memindahkan data. Susunannya modular, sehingga satu lapisan dapat diganti tanpa membongkar seluruh arsitektur.

Kontrasnya terlihat pada tata lama. Warehouse generasi sebelumnya berjalan pada mesin milik sendiri (on-premise), menyatukan penyimpanan dan komputasi pada satu perangkat keras, serta membutuhkan tim khusus untuk memeliharanya. Menambah kapasitas berarti membeli dan memasang perangkat baru, sehingga pembaruan arsitektur bergerak lambat. Modern data stack menghapus hambatan itu dengan menyewa kapasitas sesuai pemakaian.

Diagram berikut merangkum susunan lima lapisan yang menjadi peta pembahasan, dari sumber data sampai tempat hasilnya dipakai.

Sistem sumber#

Sistem sumber adalah tempat data lahir dan berubah, sehingga lapisan ini selalu menjadi titik awal stack. Contohnya meliputi basis data aplikasi OLTP, yakni basis data yang melayani transaksi harian seperti pencatatan peminjaman buku. Sumber lain mencakup API layanan pihak ketiga, log kejadian (event log) dari aplikasi, dan data pada alat software as a service (SaaS), yakni perangkat lunak yang dipakai melalui langganan daring. Sistem-sistem itu dirancang untuk kelancaran operasional, bukan untuk analisis, sehingga skemanya dapat berubah seiring pengembangan aplikasi dan aksesnya dibatasi.

Insinyur data tidak mengubah isi sistem sumber. Tugasnya mengekstrak data dari sana tanpa mengganggu beban kerja operasionalnya. Ekstraksi yang sopan memperhatikan rate limit, yaitu pembatasan jumlah permintaan yang diperbolehkan sumber dalam satu periode, serta memilih jendela waktu ketika sistem sumber sedang lengang. Dokumentasi tentang tiap sumber, yaitu pemiliknya, jadwal perubahannya, dan kolom kuncinya, menjadi modal utama sebelum konektor disusun. Karakteristik setiap sumber menentukan bentuk ingestion yang cocok untuknya.

Ingestion#

Ingestion adalah proses menyerap data dari sistem sumber menuju sistem analitik. Proses ini berjalan dalam dua mode umum. Mode batch memindahkan data secara periodik, misalnya setiap jam atau setiap malam, sedangkan mode streaming meneruskan kejadian hampir seketika setelah terjadi. Sebagian besar kebutuhan analitik dilayani dengan batch, dan streaming baru bermanfaat ketika keterlambatan beberapa menit benar-benar merugikan. Kedua mode juga dapat dipadukan, misalnya batch untuk data historis dan streaming untuk kejadian harian.

Alat ingestion modern berbasis konektor, yakni modul siap pakai untuk satu jenis sumber tertentu. Konfigurasi sumber dan tujuan cukup ditulis sekali, kemudian alat mengelola penjadwalan, autentikasi, dan pemindahannya. Tantangan sebenarnya berada di luar peralatan, yaitu data sumber yang bertambah tanpa penanda urutan, kolom yang berubah tipe, dan sumber yang mengembalikan data ganda. Karena itu pemilihan kolom penanda perubahan dan pemeriksaan kecil di awal ingestion sangat menolong.

Penyimpanan: warehouse dan lake#

Data yang sudah diserap membutuhkan tempat tinggal yang dirancang untuk analisis. Data warehouse menyimpan data dalam bentuk kolom (columnar), sehingga query agregasi atas jutaan baris berjalan cepat, dan menawarkan antarmuka SQL yang akrab bagi analis. Data lake melengkapinya dengan menyimpan data mentah dalam format aslinya pada penyimpanan murah, menunggu dipakai ketika kebutuhan analisis baru muncul. Keduanya tidak saling menggantikan dan pada banyak arsitektur dipakai bersamaan.

Ciri khas penyimpanan modern adalah pemisahan penyimpanan dan komputasi. Data duduk pada penyimpanan yang murah, sedangkan kapasitas komputasi dapat dinaik-turunkan sesuai pemakaian, sehingga biaya mengikuti pemakaian nyata dan bukan perkiraan puncak. Contoh warehouse terkelola yang umum dijumpai adalah Snowflake, BigQuery, dan Redshift. Pada skala pembelajaran, DuckDB memainkan peran yang sama di dalam komputer sendiri tanpa biaya dan tanpa server.

Transformasi#

Transformasi mengubah data mentah menjadi tabel yang siap dipakai, dan pada stack modern tahap ini berjalan di dalam warehouse. Pola yang berlaku disebut ELT (extract, load, transform), yakni data dimuat lebih dahulu, kemudian ditransformasi dengan SQL di tempat penyimpanannya. Data tidak perlu keluar dari warehouse, sehingga kecepatan SQL dan kapasitas komputasinya terpakai penuh. Transformasi biasanya berlapis, dimulai dari lapisan staging yang membersihkan ringan, sampai tabel siap analisis yang sudah tergabung dan teragregasi. Pemisahan lapisan ini menjaga data mentah tetap utuh, sehingga kesalahan transformasi dapat diperiksa dan diulang dari nol.

Contoh berikut memperlihatkan satu putaran transformasi kecil dengan DuckDB. Tabel nilai_mentah meniru hasil ingestion yang masih mentah, kemudian SQL merangkumnya menjadi tabel rata_per_kelas yang siap dipakai laporan.

import duckdb

con = duckdb.connect()

# tabel mentah meniru hasil ingestion dari sistem sumber
con.execute("""
    CREATE TABLE nilai_mentah AS
    SELECT * FROM (VALUES
        (1, 'A', 78),
        (2, 'A', 85),
        (3, 'B', 90),
        (4, 'B', 70),
        (5, 'B', 82)
    ) AS t(id_siswa, kelas, nilai)
""")

# transformasi menjadi tabel siap analisis
con.execute("""
    CREATE TABLE rata_per_kelas AS
    SELECT kelas,
           COUNT(*) AS jumlah_siswa,
           ROUND(AVG(nilai), 2) AS rata_nilai
    FROM nilai_mentah
    GROUP BY kelas
""")

con.sql("SELECT * FROM rata_per_kelas ORDER BY kelas").show()

┌─────────┬──────────────┬────────────┐
│  kelas  │ jumlah_siswa │ rata_nilai │
│ varchar │    int64     │   double   │
├─────────┼──────────────┼────────────┤
│ A       │            2 │       81.5 │
│ B       │            3 │      80.67 │
└─────────┴──────────────┴────────────┘

Tabel rata_per_kelas adalah contoh tabel siap analisis. Perhatikan bahwa seluruh perubahan terjadi di dalam DuckDB melalui SQL, tanpa memindahkan data ke pustaka lain. Pola yang sama berlaku pada warehouse skala besar, hanya saja biayanya tercatat per pemakaian.

Serving layer#

Serving layer adalah lapisan yang menyalurkan hasil olahan kepada konsumennya, dan lapisan ini menjadi ujung dari seluruh stack. Bentuknya beragam, mulai dari dashboard dan laporan pada alat BI (business intelligence), yakni perangkat lunak visualisasi data untuk pengambilan keputusan. Bentuk lain mencakup API analitik yang menghidupi aplikasi dan tabel yang dibaca model pembelajaran mesin. Konsumen tersebut mencakup manusia yang membaca laporan dan program yang mengambil angka secara otomatis. Pada titik ini kualitas kerja seluruh lapisan diuji, karena kesalahan yang lolos dari hulu akan tampak di sini.

Persoalan klasik pada lapisan ini adalah definisi metrik yang berbeda-beda antarlaporan, karena pengertian seperti pengguna aktif atau pesanan selesai mudah berbeda antarpenyaji. Solusinya adalah menyajikan tabel termodel yang sama kepada semua alat penyaji, bukan menyalin definisi ke setiap dashboard. Prinsip satu sumber kebenaran (single source of truth) menjaga dua laporan yang membahas angka yang sama agar tidak berbeda isinya.

Contoh alat per lapisan#

Tabel berikut menghimpun contoh alat yang umum dijumpai pada tiap lapisan. Daftar ini bersifat ilustratif, bukan rekomendasi, dan nama alatnya berganti lebih cepat daripada pola lapisannya. Yang bertahan justru peran setiap lapisan, sehingga memahami perannya lebih menguntungkan daripada menghafal nama.

Tidak semua lapisan harus menggunakan alat berbeda. DuckDB dan SQL murni dapat mengisi lapisan penyimpanan dan transformasi untuk proyek pembelajaran, sedangkan Kafka baru diperlukan ketika streaming sungguhan menjadi kebutuhan. Mulailah dari yang paling sederhana, lalu tambahkan lapisan hanya ketika masalahnya muncul. Apabila satu alat mengisi dua lapisan sekaligus, tetap jaga batas keduanya agar pemisahan tanggung jawab tidak hilang.

Ringkasan#

• Modern data stack tersusun modular dari sistem sumber, ingestion, penyimpanan, transformasi, dan serving layer.
• Pemisahan penyimpanan dan komputasi membuat kapasitas tiap lapisan dapat diskalakan secara terpisah.
• Pada pola ELT, transformasi berjalan di dalam warehouse dengan SQL, biasanya dari lapisan staging menuju tabel siap analisis.
• Definisi metrik dipusatkan pada tabel termodel yang sama agar seluruh laporan konsisten.

Referensi#

• Fundamentals of Data Engineering — O’Reilly — Buku Reis dan Housley yang memetakan tiap lapisan arsitektur data beserta alternatif teknologinya.
• dbt explained — dbt Labs — Artikel resmi dbt yang menjelaskan posisi transformasi SQL di dalam warehouse.
• What is dbt? — dbt Developer Hub — Dokumentasi resmi dbt yang memperkenalkan konsep model dan alur transformasinya.