Alat dan Tech Stack Data Scientist: Panduan Build Jujur 2026

Biarkan saya mendeskripsikan stack yang sebagian besar tim data science sebenarnya miliki, bahkan yang didukung oleh perusahaan ARR delapan digit.

Sebuah Jupyter notebook di laptop seseorang. File CSV di S3 dengan nama seperti customers_FINAL_v3_use_this.csv. Sebuah model.pkl yang seseorang emailkan ke software engineer backend via Slack tiga kuartal lalu. Dashboard Looker yang tidak dipercaya siapa pun karena join-nya terus berubah secara diam-diam. Halaman Confluence berjudul "ML Architecture" yang terakhir diedit sehari sebelum kepala data sebelumnya mengundurkan diri.

Jika ini adalah stack Anda, Anda tidak tertinggal. Sebagian besar tim ada di sini. Pertanyaan jujurnya bukan apakah pengaturan Anda memalukan. Ini apakah Anda tetap di sini, atau apakah Anda melakukan pekerjaan membosankan untuk keluar.

Panduan ini untuk Data Scientist IC (bukan VP, bukan tim platform) yang perlu membangun stack dari awal atau mengaudit kekacauan tambal sulam yang mereka warisi. Kami akan membahas 6 lapisan inti, menyebutkan default open-source, menyebutkan upgrade berbayar, dan mengatakan dengan jelas kapan masing-masing layak. Jika Anda ingin merekrut untuk peran ini dengan benar, template JD Data Scientist adalah pasangannya.

Mengapa ini penting sekarang

Model dalam notebook tidak menghasilkan uang. Jarak antara "saya melatih model dengan AUC 0,87" dan "bisnis menggunakan prediksi ini setiap hari untuk membuat keputusan" adalah sekitar 80% tooling dan 20% ilmu pengetahuan. Tidak ada yang suka mendengar itu, terutama DS yang menghabiskan tiga tahun dalam program PhD statistik, tetapi itu benar.

Data Scientist yang bisa membangun stack penuh dari warehouse hingga pemantauan adalah yang mendapat promosi, mendapat headcount, mendapat anggaran, dan berhenti diperlakukan seperti cost center yang menjalankan SQL. Yang tidak bisa adalah yang terus merilis notebook dan bertanya-tanya mengapa gelombang PHK berikutnya ada nama mereka.

Anda tidak harus menyukai MLOps. Anda harus paham tentangnya.

The Core 6: apa yang sebenarnya dibutuhkan setiap stack ML

Enam lapisan. Harga nyata. Kapan masing-masing layak.

Mari kita bahas masing-masing, karena tabel adalah lembar contekan, bukan argumen.

Lapisan warehouse / data

Snowflake, BigQuery, atau Databricks SQL. Pilih yang sudah dibayar tim data engineering Anda. Jika tidak ada tim data engineering dan Anda memilih dari awal, BigQuery adalah yang termurah untuk dimulai (bayar per kueri sebesar $6,25/TB yang dipindai, tidak ada biaya warehouse idle) dan Snowflake adalah yang termudah untuk dibagikan dengan analis non-teknis.

Kesalahan yang saya lihat setiap minggu: tim DS mencoba "menghemat uang" dengan melatih model langsung dari Parquet mentah di S3, tanpa lapisan warehouse, setiap pekerjaan membaca ulang 200GB dan menulis ulang skema di pandas. Itu bukan menghemat uang. Itu membakar jam DS, yang biayanya sepuluh kali lebih mahal dari kredit warehouse yang Anda hindari. Beli warehouse-nya. Gunakan dbt untuk mentransformasi di dalamnya. Latih dari tabel yang telah dikurasi.

Notebook / IDE

Jupyter gratis, lokal, cocok untuk pekerjaan solo. Untuk tim tiga orang atau lebih, notebook kolaboratif (Hex di $40-$80/pengguna/bulan, Deepnote sedikit lebih murah) layak dibayar karena mereka menempatkan SQL, Python, dan artefak yang dapat dipublikasikan dalam satu kanvas. Pemangku kepentingan bisa membaca dokumen Hex; mereka tidak bisa membaca analysis_v7_final.ipynb Anda.

Databricks Notebooks dibundel dengan komputasi Databricks. Jika Anda sudah membayar untuk komputasinya, notebook-nya baik-baik saja. Jika tidak, Anda membayar harga platform Databricks untuk apa yang pada dasarnya adalah Jupyter yang dihosting, dan matematika itu tidak berjalan.

Opsi yang diremehkan: VS Code plus ekstensi Jupyter. Gratis, cepat, memiliki git nyata, debugger, dan ekstensi. Sebagian besar Data Scientist senior yang saya hormati menggunakannya untuk pekerjaan serius dan menyimpan notebook yang dihosting untuk eksplorasi dan berbagi dengan pemangku kepentingan.

Pelacakan eksperimen

Ini adalah lapisan di mana sebagian besar tim memiliki tiga alat karena tidak ada yang memutuskan. Pilih satu.

MLflow adalah open-source dan dapat di-self-host di VM kecil seharga sekitar $50/bulan. UI pelacakannya baik. Registri model fungsional. Anda akan menghabiskan mungkin satu hari engineering untuk menyiapkannya dan beberapa jam per kuartal untuk memeliharanya.

Weights & Biases memiliki UI paling indah dalam kategorinya, paling mudah dibagikan dengan pemangku kepentingan, dan layak dibayar (antara $20 dan $100 per pengguna per bulan tergantung tier) jika Anda menjalankan lebih dari dua puluh eksperimen seminggu atau jika tim Anda benar-benar menggunakan tooling perbandingan. Jika dua dari Anda menjalankan tiga eksperimen per kuartal, MLflow baik-baik saja dan W&B berlebihan.

Neptune.ai adalah alternatif W&B yang lebih murah dengan sebagian besar fitur yang sama. Layak dilihat jika harga W&B menakutkan Anda.

Apa pun yang Anda pilih, matikan yang lain. Stack pelacakan eksperimen terburuk adalah yang di mana Alice menggunakan W&B, Bob menggunakan MLflow, dan rekrutan baru membuka TensorBoard karena itu yang mereka miliki di pekerjaan terakhir mereka.

Penyimpanan fitur

Feast adalah open-source dan gratis dalam dolar. Tidak gratis dalam jam. Anda harus meng-host Redis (atau online store lain), menyiapkan registri, menulis pekerjaan materialisasi, dan menjaga semuanya berjalan. Untuk tim dua orang dengan tiga model dalam prod, Feast adalah infrastruktur teoritis dan proyek dbt yang terorganisir dengan baik melakukan pekerjaan yang sama dengan sepersepuluh pemeliharaan.

Tecton adalah opsi berbayar enterprise. Harga awalnya enam digit. Ini hanya dapat dibenarkan jika Anda memiliki 50+ model dalam produksi dengan penggunaan ulang fitur nyata lintas tim. Tim dua orang yang membeli Tecton adalah sinyal terkeras dari alokasi modal yang buruk di bidang ini.

Databricks Feature Store dibundel jika Anda sudah menggunakan Databricks. Gunakan jika Anda menggunakannya. Jangan beralih platform untuk mendapatkannya.

Pandangan jujur: sebagian besar tim dengan kurang dari sepuluh model dalam prod belum membutuhkan penyimpanan fitur. Mereka membutuhkan alur fitur yang bersih dalam dbt dan konvensi penamaan. Lewati lapisan penyimpanan fitur sampai rasa sakit menduplikasi fitur di lima pekerjaan pelatihan menjadi lebih keras dari rasa sakit mendirikan Feast.

Penyajian model

Lapisan penyajian adalah tempat sebagian besar stack over-engineered. Empat opsi nyata:

SageMaker adalah AWS-native, kompleks, dan berjalan sekitar $0,05 hingga $2 per jam per endpoint tergantung pada instance. Ini adalah jawaban yang tepat jika Anda sudah menggunakan AWS secara intensif dan memiliki platform engineer untuk mengelola endpoint. Ini adalah jawaban yang salah jika Anda adalah tim DS dua orang dan Anda hanya ingin model di belakang HTTP endpoint.

Vertex AI adalah setara GCP. Harga serupa, kompleksitas serupa, peringatan serupa.

Modal adalah GPU serverless. Anda membayar per detik komputasi. Sangat baik untuk inferensi berlonjak (rekomendasi di situs lalu lintas rendah, pekerjaan penilaian batch, apa pun yang biasanya Anda bayar untuk endpoint idle). Pengalaman developer adalah yang terbaik dalam kategorinya. Ini adalah rekomendasi default saya untuk pengaturan indie dan tim kecil.

BentoML adalah framework open-source. Anda menulis logika inferensi Anda, BentoML mengemasnya, dan Anda mendeploy paket di Kubernetes (atau Modal, atau Lambda, atau di mana pun). Pasangkan dengan Modal dan Anda memiliki stack GPU serverless dengan harga startup.

Kombinasi Modal plus BentoML adalah yang akan saya bangun hari ini jika saya memulai tim DS dari awal tanpa tim platform. SageMaker adalah yang Anda komit ketika Anda memiliki tim platform dan kontrak pengadaan yang sudah mencakup kredit AWS.

Pemantauan & deteksi penyimpangan

Jika Anda memiliki model dalam produksi dan tidak ada pemantauan, Anda tidak memiliki model dalam produksi. Anda memiliki bom waktu yang dinilai oleh AUC.

Evidently adalah open-source, dapat dijalankan sebagai library Python atau layanan mandiri. Ini adalah titik awal yang tepat. Anda dapat menghubungkannya ke notebook dan memiliki laporan penyimpangan dasar yang berjalan dalam satu siang.

WhyLabs memiliki tier gratis yang dapat ditingkatkan. Pilihan bagus jika Anda ingin dashboard yang dihosting tanpa anggaran untuk Arize.

Arize adalah opsi berbayar serius, $1 ribu-$10 ribu/bulan untuk volume produksi. Layak dibayar setelah Anda memiliki lebih dari lima model dalam prod atau persyaratan peraturan apa pun (layanan keuangan, kesehatan, apa pun dengan auditor).

Mulai dengan Evidently gratis. Upgrade ketika jumlah model dalam prod atau tekanan kepatuhan membenarkannya. Jangan beli Arize sebelum Anda memiliki model yang membutuhkan pemantauan.

Pertanyaan sumber kebenaran tunggal (di mana sebagian besar stack DS membusuk)

Label sampah masuk, model sampah keluar. Anda sudah tahu ini. Yang mungkin belum Anda internalisasi adalah dari mana sebagian besar sampah label berasal: sistem operasional yang menjadi sumber kebenaran. CRM. Alat tiket. Pengaturan analitik produk yang dikonfigurasi tiga PM berbeda dengan tiga cara berbeda dalam dua reorganisasi.

Jika label "pelanggan churn" Anda berasal dari CRM di mana sales rep A menandai kesepakatan "Closed Lost - No Decision," rep B menandai situasi yang sama "Lost - Competitor," dan rep C hanya menghapus kesepakatan tersebut, tidak ada jumlah pelacakan MLflow yang dapat menyelamatkan Anda. Model churn Anda mempelajari kebersihan data rep Anda yang tidak konsisten, bukan perilaku pelanggan.

Sistem operasional yang bersih sebagai sumber kebenaran tunggal lebih penting dari penyimpanan fitur yang mewah. Ini tidak glamor. Ini tidak membuat Anda mendapat kesempatan berbicara di konferensi. Tetapi Data Scientist yang menghabiskan seminggu memperbaiki definisi tahap pipeline dan memaksakan validasi required-field di CRM merilis model yang lebih baik untuk dua tahun ke depan daripada yang beralih penyimpanan fitur tiga kali.

Rework CRM di $12/pengguna/bulan memberi Anda tahap pipeline yang terstruktur, custom fields dengan validasi, event log yang bisa Anda stream ke warehouse, dan sumber kebenaran tunggal untuk siklus hidup pelanggan yang menjadi andalan model churn dan konversi Anda. Apa pun CRM yang Anda gunakan, prinsipnya berlaku: kualitas data hulu menentukan kualitas model hilir. Perbaiki sebelum Anda menyetel hyperparameter lagi.

Build vs. beli: pohon keputusan yang sebenarnya

Berikut matriksnya. Temukan baris Anda, bangun sesuai. Jangan lewati level.

Jangan lewati level. Dua kesalahan stack paling umum yang saya lihat, secara berurutan:

1. Tim dua orang yang membeli Tecton karena seseorang menonton ceramah konferensi.
2. Tim delapan orang yang masih menjalankan semuanya di laptop seorang pendiri karena "kita belum butuh MLOps."

Keduanya buruk. Yang pertama adalah over-investasi tanpa hasil. Yang kedua adalah under-investasi yang menguras produktivitas dan kredibilitas setiap minggu.

Audit stack 30 hari

Konkret, minggu per minggu. Jalankan ini apakah Anda mewarisi kekacauan atau membangunnya sendiri.

Hari 1-3: Inventarisasi apa yang benar-benar dideploy

Bukan apa yang ada di slide arsitektur. Apa yang benar-benar berjalan. Buka setiap cron, setiap Airflow DAG, setiap endpoint SageMaker, setiap notebook terjadwal. Buat spreadsheet. Kolom: alat, pemilik, biaya bulanan, persentase tim yang menggunakannya, tanggal terakhir disentuh, putuskan-simpan-upgrade.

Anda akan menemukan setidaknya tiga hal yang tidak Anda ketahui keberadaannya.

Hari 4-7: Temukan setiap model dalam prod

Untuk setiap model: siapa pemiliknya, data apa yang dilatihnya, kapan terakhir dilatih ulang, apa metrik performa saat ini, dan apakah ada yang akan memperhatikan jika berhenti berjalan.

Jika tidak ada yang akan memperhatikan, matikan. Jika tidak ada yang memilikinya, itu sekarang masalah Anda untuk ditugaskan.

Hari 8-14: Tambahkan pemantauan ke model yang paling buruk dipantau

Pilih model dengan dampak bisnis tertinggi dan pemantauan terburuk. Tambahkan Evidently ke dalamnya minggu ini. Tidak harus cantik. Laporan penyimpangan mingguan yang dikirimkan ke channel sudah cukup untuk memulai.

Hari 15-21: Konsolidasikan pelacakan eksperimen

Pilih satu alat. Migrasikan eksperimen aktif. Beritahu tim untuk berhenti menggunakan yang lain. Arsipkan sisanya. Ini akan lebih sulit secara politis dari yang terdengar karena orang yang menyiapkan alat yang Anda matikan akan menganggapnya sebagai serangan pribadi. Lakukan saja.

Hari 22-30: Dokumentasikan stack dalam satu README

Satu README di repo tim. Diagram arsitektur (kotak dan panah, bukan karya seni Visio). Tujuan, pemilik, dan login setiap alat. Prosedur on-call untuk setiap model dalam prod. Rekrutan DS berikutnya harus bisa membaca ini dalam satu jam dan mengetahui apa yang mereka warisi.

Setelah 30 hari, Anda bisa menjawab dalam satu napas: setiap model dalam prod, siapa pemiliknya, kapan terakhir dilatih ulang, seperti apa penyimpangan saat ini, dan satu alat yang akan Anda potong besok. Jika Anda tidak bisa menjawab itu, audit belum selesai.

Kesalahan umum

Yang paling sering terjadi, kurang lebih berurutan:

• Membeli alat sebelum memiliki model dalam prod. "Kita membutuhkan penyimpanan fitur." Apakah Anda? Apakah Anda memiliki fitur? Apakah Anda memiliki model yang menggunakannya? Jangan beli infrastruktur untuk masa depan yang belum Anda bangun.
• Self-hosting MLflow tanpa menganggarkan waktu pemeliharaan. Gratis dalam dolar. Tidak gratis dalam jam. Seseorang harus menjaga VM tetap di-patch, database di-backup, dan autentikasi berjalan. Jika orang itu adalah Anda dan Anda juga harus merilis model, matematikanya mungkin mendukung opsi yang dikelola.
• Membiarkan setiap DS memilih alatnya sendiri. "Kami menggunakan apa pun yang mereka gunakan di pekerjaan terakhir mereka" adalah cara Anda berakhir dengan tiga pelacak eksperimen, dua penyimpanan fitur, dan dokumen onboarding 40 halaman.
• Membangun "platform" sebelum memiliki tiga model yang membenarkannya. Perangkap tim-platform-dari-satu-orang. Jangan generalisasi sampai Anda memiliki hal-hal spesifik untuk digeneralisasi.
• Mengabaikan lapisan CRM dan data operasional karena "bukan ML." Ini adalah lapisan yang menentukan apakah label Anda nyata. Ini adalah fondasi ML, bukan tetangga ML.

Template yang layak dibangun

Empat artefak untuk disimpan di repo tim Anda:

1. Spreadsheet audit stack. Alat, biaya bulanan, pemilik, persentase tim yang menggunakannya, tanggal terakhir disentuh, keputusan putuskan-simpan-upgrade.
2. Inventaris "apa yang sebenarnya dalam prod". Model, pemilik, sumber data pelatihan, terakhir dilatih ulang, status pemantauan, dampak bisnis, prosedur on-call.
3. Matriks keputusan build-vs-beli. Tabel dari artikel ini, disesuaikan untuk stack spesifik tim Anda.
4. Struktur repo stack minimum viable. Contoh kerja MLflow plus BentoML plus Evidently yang terhubung bersama, sehingga rekrutan DS berikutnya bisa men-clone dan merilis model dalam minggu pertama mereka.

Intinya

Bagian tersulit dari stack ML bukan ML-nya. Ini adalah lapisan hulu yang membosankan (label bersih, event bersih, satu sumber kebenaran) dan lapisan hilir yang membosankan (pemantauan yang benar-benar Anda lihat). Bagian tengah (model mana, penyimpanan fitur mana, framework penyajian mana) mendapat paling banyak perhatian dan paling sedikit penting.

Alat penting. Disiplin stack lebih penting. DS yang menjalankan audit 30 hari, mematikan dua alat yang redundan, dan menulis README lebih berharga dari yang membandingkan lima library gradient boosting.

Jika Anda merekrut untuk peran ini, template JD Data Scientist menjelaskan tanggung jawab dan standarnya. Jika Anda sudah dalam peran dan stack Anda terlihat seperti paragraf pembuka panduan ini, mulailah auditnya hari Senin.

Pelajari Lebih Lanjut

• Sehari dalam Kehidupan Data Scientist
• 30/60/90 Hari Pertama Anda sebagai Data Scientist Baru
• Memindahkan Model ke Produksi Tanpa Memecahkannya
• Metrik DS: Model yang Dirilis, Dampak Bisnis, Penurunan Kualitas
• Template JD Data Scientist