Pengenalan Dashboard

Posisi Streamlit dan alat BI, serta kapan dashboard bukan jawabannya.

Daftar isi

Dashboard menjadikan metrik yang berulang dapat dilihat kapan pun tanpa menjalankan ulang kode, dan dua jalur teknologinya adalah alat BI yang memetakan data yang sudah tersedia serta aplikasi data berbasis Python seperti Streamlit. Topik ini menempatkan keduanya, membangun prototipe terkecil Streamlit untuk dataset latihan, dan menetapkan tanda kapan dashboard bukan jawabannya. Setelah membacanya, permintaan “buatkan dashboard” dapat dijawab dengan pilihan yang disengaja, bukan dengan aplikasi yang segera dibangun.

Dua jalur dan posisinya#

Alat BI, seperti Metabase, Superset, atau Looker, menghubungkan langsung ke basis data dan membangun grafiknya lewat antarmuka, sehingga cepat untuk metrik yang definisinya sudah mapan. Aplikasi data seperti Streamlit mengubah skrip Python menjadi aplikasi web, sehingga logika pembersihan dan perhitungan yang kompleks ikut terkandung di dalamnya.

KebutuhanPilihan yang cocokAlasannya
Metrik rutin dari gudang dataalat BItanpa kode, akses teratur
Analisis yang butuh logika PythonStreamlitskrip analisis menjadi aplikasi
Laporan sekali kirimdokumen atau notebooktanpa biaya pemeliharaan
Peringatan otomatislapisan alert alat BImemicu tanpa dibuka

Posisi keduanya di atas notebook dan di bawah produk, yaitu keduanya menuntut pemeliharaan, karena basis data berubah, definisi metrik berubah, dan pemakainya membutuhkan keandalan. Prototipe terkecil yang hidup lebih berharga daripada rencana dashboard yang luas, dan prototipe itulah yang dibangun di bagian berikutnya.

Prototipe terkecil dengan Streamlit#

Streamlit menjalankan ulang skrip pada setiap interaksi, sehingga skrip analisis yang sudah ada hampir langsung menjadi aplikasi. Prototipe dataset latihan memuat berkas, membersihkannya dengan kamus pembersihan yang sudah mapan, lalu menampilkan dua grafik beserta pemilih stasiunnya.

python Contoh: aplikasi terkecil Streamlit
# tidak-dijalankan
import pandas as pd
import streamlit as st

st.title("Kualitas udara dua stasiun")

data = pd.read_csv("ukuran_udara.csv", na_values=["kosong", "-999.0"])
data["pm25"] = data["pm25"].astype("float")
data["stasiun"] = data["stasiun"].str.strip().str.title()

pilihan = st.selectbox("Stasiun", sorted(data["stasiun"].unique()))
potongan = data[data["stasiun"] == pilihan]

st.line_chart(potongan.set_index("waktu")["pm25"])
st.metric("Rata-rata PM2.5", f"{potongan['pm25'].mean():.1f}")

Ditandai tidak-dijalankan karena Streamlit menyajikan aplikasi lewat server yang menunggu peramban, sesuatu yang tidak dapat direkam sebagai keluaran terminal. Polanya tetap utuh, yaitu st.title menyusun halaman, st.selectbox membangun kontrol interaksi yang nilainya dipakai ulang pada skrip, dan st.line_chart bersama st.metric menampilkan hasilnya, sementara seluruh logika analisisnya adalah pandas yang sudah dikuasai.

Pemisahan yang disiplin menyertai prototipe ini, yaitu fungsi pembersihan diambil dari skrip analisis yang sama, bukan ditulis ulang di dalam aplikasi, sehingga definisi data bersih hanya ada satu tempat.

Kapan dashboard bukan jawabannya#

Permintaan dashboard sering datang sebelum pertanyaannya, dan tiga tanda menyatakan bahwa ia bukan jawabannya. Pertama, keputusan yang diminta sekali dibuat, sehingga dokumen atau notebook memadai dan biaya pemeliharaannya sia-sia. Kedua, metriknya belum stabil definisinya, karena dashboard yang memetakan metrik yang berubah membuat dua versi kebenaran. Ketiga, pemakainya lebih membutuhkan penjelasan daripada pemantauan, dan itu adalah wilayah laporan serta presentasi.

Biaya yang tersembunyi juga menyertai, yaitu akses keamanan, dokumentasi metrik, penanganan data yang telat, dan orang yang menjawab ketika grafik berhenti berubah. Prototipe yang diumumkan tanpa pemilik pemeliharaan berubah menjadi kekecewaan yang terjadwal.

Jalan tengahnya bertingkat, yaitu mulai dari grafik di notebook, naik ke skrip terjadwal yang mengirim gambar, lalu dashboard apabila pemakaiannya sudah terbukti rutin. Kenaikan yang berjenjang ini membuat biaya mengikuti bukti, dan keputusan berhenti di tingkat mana pun tetap sah.

Kesalahan umum#

Kesalahan pertama adalah membangun dashboard sebelum metriknya disepakati. Grafik yang memetakan definisi sementara harus dibongkar, dan percakapan definisi metrik selalu lebih murah daripada pembangunan ulang.

Kesalahan kedua adalah menduplikasi logika pembersihan di dalam aplikasi. Dua kamus pembersihan yang berjalan berdampingan melahirkan dua kebenaran, sedangkan satu fungsi yang diimpor menjaga dashboard dan laporan berbicara dari data yang sama.

Kesalahan ketiga adalah memperlakukan dashboard sebagai selesai setelah rilis. Basis data berubah dan pemakainya bertanya, sehingga pemilik dan ritme pemeliharaannya dinyatakan sejak prototipe pertama.

Ringkasan#

  • Alat BI untuk metrik mapan di gudang data, Streamlit untuk analisis yang logikanya hidup di Python, dan keduanya menuntut pemeliharaan.
  • Prototipe terkecil Streamlit adalah skrip analisis yang diberi judul, kontrol, dan tampilan, dengan logika pembersihannya diimpor, bukan ditulis ulang.
  • Keputusan sekali kirim, metrik yang belum stabil, dan pemakai yang butuh penjelasan adalah tanda dashboard bukan jawabannya.
  • Kenaikan berjenjang dari notebook ke skrip terjadwal ke dashboard membuat biaya mengikuti bukti pemakaian.

Referensi#