Alat dan Tech Stack Data Scientist: Panduan Binaan Jujur 2026

Izinkan saya menggambarkan tumpukan yang kebanyakan pasukan sains data sebenarnya miliki, bahkan yang di belakangnya syarikat dengan ARR lapan digit.

Notebook Jupyter pada laptop seseorang. CSV dalam S3 dengan nama seperti customers_FINAL_v3_use_this.csv. model.pkl yang seseorang e-mel kepada jurutera bahagian belakang dalam Slack tiga suku tahun lalu. Dashboard Looker yang tiada siapa percaya kerana gabungan itu terus berubah secara senyap. Halaman Confluence bertajuk "Seni Bina ML" yang kali terakhir disunting hari sebelum ketua data terdahulu berhenti.

Jika ini adalah tumpukan anda, anda tidak ketinggalan. Kebanyakan pasukan ada di sini. Soalan jujurnya bukan sama ada persediaan anda memalukan. Sama ada anda kekal di sini, atau sama ada anda melakukan kerja membosankan untuk keluar.

Panduan ini adalah untuk Data Scientist IC (bukan VP, bukan pasukan platform) yang perlu sama ada membina tumpukan dari awal atau mengaudit kekacauan yang diwarisi. Kita akan melalui 6 Teras lapisan, menamakan nilai lalai sumber terbuka, menamakan naik taraf berbayar, dan berkata dengan terus terang bila setiap satu berbaloi. Jika anda ingin mengambil pekerja untuk peranan ini dengan betul, templat JD Data Scientist adalah rencana teman.

Mengapa ini penting sekarang

Model dalam notebook tidak menghasilkan wang. Jurang antara "saya melatih model dengan AUC 0.87" dan "perniagaan menggunakan ramalan ini setiap hari untuk membuat keputusan" adalah kira-kira 80% alat dan 20% sains. Tiada siapa suka mendengar itu, terutama DS yang menghabiskan tiga tahun dalam PhD statistik, tetapi ia benar.

Data Scientist yang boleh mendirikan tumpukan penuh dari gudang data ke pemantauan adalah yang dipromosikan, mendapat jumlah pekerja, mendapat belanjawan, dan berhenti dilayan seperti pusat kos yang menjalankan SQL. Yang tidak boleh terus menghantar notebook dan tertanya-tanya mengapa pemecatan seterusnya mempunyai nama mereka.

Anda tidak perlu menyukai MLOps. Anda perlu menguasainya.

6 Teras, apa yang setiap tumpukan ML benar-benar perlukan

Enam lapisan. Harga sebenar. Bila setiap satu berbaloi.

Mari kita lalui setiap satu, kerana jadual itu adalah helaian tipu, bukan hujah.

Gudang data / lapisan data

Snowflake, BigQuery, atau Databricks SQL. Pilih yang sudah dibayar oleh pasukan kejuruteraan data anda. Jika tiada pasukan kejuruteraan data dan anda memilih dari awal, BigQuery adalah yang termurah untuk dimulakan (bayar-setiap-pertanyaan pada $6.25/TB diimbas, tiada kos gudang data terbiar) dan Snowflake adalah yang paling mudah dikongsi dengan penganalisis bukan teknikal.

Kesilapan yang saya lihat setiap minggu: pasukan DS yang cuba "menjimatkan wang" dengan melatih model terus dari Parquet mentah dalam S3, tanpa lapisan gudang data, setiap kerja membaca semula 200GB dan menulis semula skema dalam pandas. Itu bukan menjimatkan wang. Itu membakar jam DS, yang menelan kos sepuluh kali lebih daripada kredit gudang data yang anda elakkan. Beli gudang data. Gunakan dbt untuk mengubah di dalamnya. Latih dari jadual yang dikurasi.

Notebook / IDE

Jupyter adalah percuma, tempatan, sesuai untuk kerja solo. Untuk pasukan tiga atau lebih, notebook kolaboratif (Hex pada $40-$80/pengguna/bulan, Deepnote sedikit lebih murah) menebus nilai mereka kerana mereka meletakkan SQL, Python, dan artifak yang boleh diterbitkan pada satu kanvas. Pihak berkepentingan boleh membaca dokumen Hex; mereka tidak boleh membaca analysis_v7_final.ipynb anda.

Databricks Notebooks dibundel dengan pengiraan Databricks. Jika anda sudah membayar untuk pengiraan, notebook adalah baik. Jika tidak, anda membayar harga platform Databricks untuk apa yang pada dasarnya adalah Jupyter yang dihoskan, dan matematik itu tidak berfungsi.

Pilihan yang kurang dihargai: VS Code ditambah dengan sambungan Jupyter. Percuma, pantas, mempunyai git sebenar, penyahpepijat, dan sambungan. Kebanyakan Data Scientist senior yang saya hormati menggunakannya untuk kerja serius dan menyimpan notebook yang dihoskan untuk penerokaan dan perkongsian pihak berkepentingan.

Penjejakan eksperimen

Ini adalah lapisan di mana kebanyakan pasukan mempunyai tiga alat kerana tiada siapa memutuskan. Pilih satu.

MLflow adalah sumber terbuka dan boleh dihoskan sendiri pada VM kecil seharga kira-kira $50/bulan. UI penjejakan adalah baik. Daftar model adalah berfungsi. Anda akan menghabiskan lebih kurang satu hari kejuruteraan untuk menyediakannya dan beberapa jam setiap suku tahun untuk menyelenggaranya.

Weights & Biases mempunyai UI paling cantik dalam kategori, paling mudah dikongsi dengan pihak berkepentingan, dan berbaloi dibayar (antara $20 dan $100 setiap pengguna setiap bulan bergantung kepada peringkat) jika anda menjalankan lebih dari dua puluh eksperimen seminggu atau jika pasukan anda benar-benar menggunakan alat perbandingan. Jika dua daripada anda menjalankan tiga eksperimen setiap suku tahun, MLflow adalah baik dan W&B adalah berlebihan.

Neptune.ai adalah alternatif W&B yang lebih murah dengan kebanyakan ciri yang sama. Berbaloi dilihat jika harga W&B menakutkan anda.

Apa sahaja yang anda pilih, hapus yang lain. Tumpukan penjejakan eksperimen yang paling buruk adalah yang di mana Alice menggunakan W&B, Bob menggunakan MLflow, dan kakitangan baru membuka TensorBoard kerana itulah yang mereka miliki di tempat kerja terakhir mereka.

Stor ciri

Feast adalah sumber terbuka dan percuma dalam dollar. Ia tidak percuma dalam jam. Anda perlu menhoskan Redis (atau stor dalam talian lain), menyediakan daftar, menulis kerja pematerian, dan memastikan semuanya berjalan. Untuk pasukan dua orang dengan tiga model dalam pengeluaran, Feast adalah infrastruktur teori dan projek dbt yang tersusun dengan baik melakukan kerja yang sama dengan sepersepuluh penyelenggaraan.

Tecton adalah pilihan berbayar perusahaan. Harga permulaannya adalah enam angka. Ia hanya boleh dibenarkan jika anda mempunyai 50+ model dalam pengeluaran dengan penggunaan semula ciri sebenar merentasi pasukan. Pasukan dua orang yang membeli Tecton adalah isyarat paling kuat peruntukan modal yang buruk dalam bidang ini.

Databricks Feature Store dibundel jika anda sudah menggunakan Databricks. Gunakan jika anda menggunakannya. Jangan tukar platform untuk mendapatkannya.

Pandangan jujur: kebanyakan pasukan di bawah sepuluh model dalam pengeluaran belum memerlukan stor ciri. Mereka memerlukan saluran ciri yang bersih dalam dbt dan konvensyen penamaan. Langkau lapisan stor ciri sehingga kesakitan menduplikasi ciri merentasi lima kerja latihan menjadi lebih kuat daripada kesakitan mendirikan Feast.

Penyajian model

Lapisan penyajian adalah di mana kebanyakan tumpukan terlalu direka bentuk. Empat pilihan sebenar:

SageMaker adalah natif AWS, kompleks, dan berjalan kira-kira $0.05 hingga $2 per jam setiap endpoint bergantung kepada contoh. Ia adalah jawapan yang betul jika anda sudah menggunakan AWS secara meluas dan mempunyai jurutera platform untuk menguruskan endpoint. Ia adalah jawapan yang salah jika anda adalah pasukan DS dua orang dan anda hanya mahukan model di belakang endpoint HTTP.

Vertex AI adalah setara GCP. Harga serupa, kerumitan serupa, amaran serupa.

Modal adalah GPU tanpa pelayan. Anda membayar setiap saat pengiraan. Ia sangat baik untuk inferens kejutan (cadangan pada laman web trafik rendah, kerja pemarkahan kelompok, apa-apa yang sebaliknya anda bayar untuk endpoint yang terbiar). Pengalaman pembangun adalah terbaik dalam kategori. Ia adalah cadangan lalai saya untuk persediaan indie dan pasukan kecil.

BentoML adalah rangka kerja sumber terbuka. Anda menulis logik inferens anda, BentoML membungkus, dan anda menggunakan bungkusan pada Kubernetes (atau Modal, atau Lambda, atau di mana sahaja). Pasangkan dengan Modal dan anda mempunyai tumpukan GPU tanpa pelayan pada harga permulaan.

Kombinasi Modal dan BentoML adalah apa yang akan saya bina hari ini jika saya memulakan pasukan DS dari awal tanpa pasukan platform. SageMaker adalah apa yang anda komit apabila anda mempunyai pasukan platform dan kontrak perolehan yang sudah termasuk kredit AWS.

Pemantauan dan pengesanan hanyutan

Jika anda mempunyai model dalam pengeluaran dan tiada pemantauan, anda tidak mempunyai model dalam pengeluaran. Anda mempunyai bom masa yang diberi skor oleh AUC.

Evidently adalah sumber terbuka, boleh dijalankan sebagai perpustakaan Python atau perkhidmatan berdiri sendiri. Ia adalah titik permulaan yang betul. Anda boleh menyambungkannya ke dalam notebook dan mempunyai laporan hanyutan asas berjalan dalam satu petang.

WhyLabs mempunyai tahap percuma yang naik skala. Pilihan yang kukuh jika anda mahukan dashboard yang dihoskan tanpa belanjawan untuk Arize.

Arize adalah pilihan berbayar serius, $1k-$10k/bulan untuk isipadu pengeluaran. Ia berbaloi dibayar sebaik sahaja anda mempunyai lebih dari lima model dalam pengeluaran atau sebarang keperluan kawal selia (perkhidmatan kewangan, penjagaan kesihatan, apa-apa dengan juruaudit).

Mulakan dengan Evidently percuma. Naik taraf apabila bilangan model dalam pengeluaran atau tekanan pematuhan membenarkannya. Jangan beli Arize sebelum anda mempunyai model yang memerlukan pemantauan.

Soalan sumber kebenaran tunggal (di mana kebanyakan tumpukan DS reput)

Label sampah masuk, model sampah keluar. Anda sudah tahu ini. Apa yang mungkin anda belum hayati adalah dari mana kebanyakan sampah label datang: sistem rekod operasi. CRM. Alat tiket. Persediaan analitik produk yang tiga PM berbeza konfigurasi dengan tiga cara berbeza merentasi dua penstrukturan semula.

Jika label "pelanggan telah berpindah" anda datang dari CRM di mana jurujual A menandai urusan "Ditutup Kalah - Tiada Keputusan," jurujual B menandai situasi yang sama "Kalah - Pesaing," dan jurujual C hanya memadam urusan, tiada jumlah penjejakan MLflow yang akan menyelamatkan anda. Model peralihan pelanggan anda sedang belajar kebersihan data jurujual yang tidak konsisten, bukan tingkah laku pelanggan.

Sistem rekod operasi yang bersih lebih penting daripada stor ciri yang mewah. Ia tidak glamor. Ia tidak memberi anda ceramah di persidangan. Tetapi Data Scientist yang menghabiskan seminggu membaiki definisi peringkat saluran dan memaksa pengesahan medan yang diperlukan dalam CRM menghantar model yang lebih baik untuk dua tahun akan datang berbanding yang menukar stor ciri tiga kali.

Rework CRM pada $12/pengguna/bulan memberi anda peringkat saluran berstruktur, medan tersuai dengan pengesahan, log peristiwa yang boleh anda alirkan ke gudang data anda, dan sumber kebenaran tunggal untuk kitaran hayat pelanggan yang bergantung kepada model peralihan pelanggan dan penukaran anda. Apa pun CRM yang anda gunakan, prinsipnya tetap sama: kualiti data hulu menentukan kualiti model hilir. Perbaiki sebelum anda menala hiperparameter lain.

Bina berbanding beli, pokok keputusan sebenar

Inilah matriks. Cari baris anda, bina dengan sewajarnya. Jangan melangkau tahap.

Jangan melangkau tahap. Dua kesilapan tumpukan yang paling biasa saya lihat, mengikut urutan:

1. Pasukan dua orang yang membeli Tecton kerana seseorang menonton ceramah persidangan.
2. Pasukan lapan orang yang masih menjalankan segalanya pada laptop seorang pengasas kerana "kita belum memerlukan MLOps."

Kedua-duanya buruk. Yang pertama adalah pelaburan berlebihan tanpa hasil. Yang kedua adalah pelaburan kurang yang mengurangkan produktiviti dan kredibiliti setiap minggu.

Audit tumpukan 30 hari

Konkrit, minggu demi minggu. Jalankan ini sama ada anda telah mewarisi kekacauan atau membinanya sendiri.

Hari 1-3: Inventori apa yang sebenarnya digunakan

Bukan apa yang ada dalam slaid seni bina. Apa yang sebenarnya berjalan. Buka setiap cron, setiap DAG Airflow, setiap endpoint SageMaker, setiap notebook mengikut jadual. Buat hamparan. Lajur: alat, pemilik, kos bulanan, peratusan pasukan yang menggunakannya, tarikh terakhir disentuh, bunuh-kekal-naik taraf.

Anda akan menemui sekurang-kurangnya tiga perkara yang tidak anda tahu wujud.

Hari 4-7: Cari setiap model dalam pengeluaran

Untuk setiap model: siapa yang memilikinya, data apa yang dilatih, bila terakhir dilatih semula, apakah metrik prestasi semasa, dan sama ada ada siapa yang akan perasan jika ia berhenti berjalan.

Jika tiada siapa akan perasan, hapusnya. Jika tiada siapa yang memilikinya, itu kini masalah anda untuk diberikan.

Hari 8-14: Tambah pemantauan pada model yang paling kurang dipantau

Pilih model dengan impak perniagaan tertinggi dan pemantauan paling lemah. Tambah Evidently padanya minggu ini. Tidak perlu cantik. Laporan hanyutan mingguan yang dihantarkan ke saluran sudah cukup untuk memulakan.

Hari 15-21: Konsolidasi penjejakan eksperimen

Pilih satu alat. Pindahkan eksperimen aktif. Beritahu pasukan untuk berhenti menggunakan yang lain. Arkibkan selebihnya. Ini akan lebih sukar dari segi politik daripada yang kedengaran kerana orang yang menyediakan alat yang anda hapus akan mengambil hati. Lakukan juga.

Hari 22-30: Dokumentasi tumpukan dalam satu README

README tunggal dalam repo pasukan. Gambar rajah seni bina (kotak dan anak panah, bukan karya agung Visio). Tujuan, pemilik, dan log masuk setiap alat. Prosedur siap sedia untuk setiap model dalam pengeluaran. Pengambilan DS seterusnya sepatutnya boleh membaca ini dalam satu jam dan tahu apa yang mereka warisi.

Selepas 30 hari, anda boleh menjawab dalam satu nafas: setiap model dalam pengeluaran, siapa yang memilikinya, bila terakhir dilatih semula, seperti apa hanyutan semasa, dan satu alat yang akan anda potong esok. Jika anda tidak boleh menjawab itu, audit belum selesai.

Perangkap biasa

Terbaik yang sering berlaku, dalam urutan lebih kurang yang saya lihat:

• Membeli alat sebelum mempunyai model dalam pengeluaran. "Kita memerlukan stor ciri." Adakah? Adakah anda mempunyai ciri? Adakah anda mempunyai model yang menggunakannya? Jangan beli infrastruktur untuk masa depan yang belum anda bina.
• Menhoskan sendiri MLflow tanpa memperuntukkan masa penyelenggaraan. Ia percuma dalam dollar. Ia tidak percuma dalam jam. Seseorang perlu memastikan VM ditambal, pangkalan data disandarkan, dan pengesahan berfungsi. Jika orang itu adalah anda dan anda juga perlu menghantar model, matematik mungkin memihak kepada pilihan yang diuruskan.
• Membiarkan setiap DS memilih alat mereka sendiri. "Kita menggunakan apa yang mereka gunakan di tempat kerja terakhir mereka" adalah cara anda berakhir dengan tiga penjejak eksperimen, dua stor ciri, dan dokumen onboarding 40 halaman.
• Membina "platform" sebelum anda mempunyai tiga model yang membenarkannya. Perangkap pasukan-platform-seorang diri. Jangan generalisasikan sehingga anda mempunyai perkara khusus untuk digeneralisasikan.
• Mengabaikan CRM dan lapisan data operasi kerana ia "bukan ML." Ia adalah lapisan yang menentukan sama ada label anda adalah nyata. Ia adalah asas ML, bukan jiran ML.

Templat yang berbaloi dibina

Empat artifak untuk disimpan dalam repo pasukan:

1. Hamparan audit tumpukan. Alat, kos bulanan, pemilik, peratusan pasukan yang menggunakannya, tarikh terakhir disentuh, keputusan bunuh-kekal-naik taraf.
2. Inventori "apa yang sebenarnya dalam pengeluaran." Model, pemilik, sumber data latihan, terakhir dilatih semula, status pemantauan, impak perniagaan, prosedur siap sedia.
3. Matriks keputusan bina-berbanding-beli. Jadual dari artikel ini, disesuaikan untuk tumpukan khusus pasukan anda.
4. Struktur repo tumpukan minimum-boleh-digunakan. Contoh berfungsi MLflow ditambah BentoML ditambah Evidently yang disambungkan bersama, supaya pengambilan DS seterusnya boleh klon dan menghantar model dalam minggu pertama mereka.

Kesimpulan

Bahagian paling sukar tumpukan ML bukan ML-nya. Ia adalah lapisan hulu yang membosankan (label bersih, peristiwa bersih, satu sumber kebenaran tunggal) dan lapisan hilir yang membosankan (pemantauan yang anda benar-benar periksa). Pertengahan (model mana, stor ciri mana, rangka kerja penyajian mana) mendapat perhatian paling banyak dan paling kurang penting.

Alat penting. Disiplin tumpukan lebih penting. DS yang menjalankan audit 30 hari, menghapus dua alat yang berlebihan, dan menulis README adalah lebih berharga daripada yang membandingkan lima perpustakaan gradient boosting.

Jika anda mengambil pekerja untuk peranan ini, templat JD Data Scientist menerangkan tanggungjawab dan bar. Jika anda sudah dalam peranan dan tumpukan anda kelihatan seperti perenggan pembukaan panduan ini, mulakan audit pada hari Isnin.

Ketahui Lebih Lanjut

• Sehari dalam Kehidupan Data Scientist
• 30/60/90 Hari Pertama Anda sebagai Data Scientist Baru
• Memindahkan Model ke Pengeluaran Tanpa Merosakkannya
• Metrik DS: Model yang Dihantar, Impak Perniagaan, Kemerosotan
• Templat JD Data Scientist