Data engineer
Data engineer memastikan data benar-benar sampai: tepat waktu, dalam bentuk yang dijanjikan, dan dengan catatan asal-usulnya. Pelaporan, pemodelan, dan fitur produk berbasis data mewarisi apa pun yang dihasilkan lapisan ini, termasuk kesalahannya. Panduan ini membahas cakupan disiplinnya dan apa yang membedakan kandidat yang pernah mengoperasikan sebuah platform dari kandidat yang pipeline-nya memang belum pernah salah.
Apa yang dikerjakan seorang data engineer?
Data engineer membangun dan mengoperasikan sistem yang membawa data dari tempat data itu dibuat ke tempat data itu dipakai. Cakupannya meliputi ingestion dari aplikasi, layanan pihak ketiga, dan event stream; transformasi menjadi model data yang bisa diandalkan analis dan sistem hilir; penjadwalan dan pengelolaan dependensi; kesepakatan tentang struktur dan makna data antara tim yang memproduksi dan tim yang mengonsumsinya; pemeriksaan kualitas otomatis; lineage yang memungkinkan setiap angka ditelusuri kembali ke sumbernya; serta keputusan storage dan compute yang menentukan berapa biaya operasional platform setiap bulan. Ukuran keberhasilannya bukan data tersedia di suatu tempat, melainkan data itu benar, tepat waktu, dan bisa dijelaskan.
Kegagalan di lapisan ini biasanya senyap. Job yang crash justru mendekati hasil yang baik, karena ada orang yang diberi tahu. Kasus yang mahal adalah job yang selesai normal tetapi menulis baris yang salah: kolom yang diganti namanya di hulu, asumsi timezone yang berubah, file yang terkirim dua kali, atau record terlambat yang mendarat di partisi yang keliru. Tidak satu pun memunculkan error, dan apakah semuanya tertangkap sepenuhnya bergantung pada pemeriksaan yang dirancang sejak awal, bukan yang ditambahkan setelah seorang eksekutif merasa ada angka yang janggal.
Sebagian besar kesulitannya justru berada di batas antarorganisasi. Tim yang memproduksi data jarang tahu siapa yang mengonsumsinya, sehingga refactor rutin di sebuah aplikasi merusak laporan di divisi yang jaraknya tiga departemen. Jawaban yang bertahan lama berbentuk kesepakatan, bukan tooling: data contract yang eksplisit tentang struktur dan makna, validasi di sisi produsen data, perubahan yang bersifat aditif sebagai default, dan jalur deprecation dengan pemberitahuan â semuanya menuntut ada orang yang bersedia membicarakannya sebelum perubahan dirilis.
Biaya kini menjadi bidang desain, bukan lagi urusan belakangan. Pemisahan storage dari compute membuat skala besar terjangkau oleh tim yang sebelumnya tidak mampu, dan sekaligus membuat pengeluaran besar mungkin terjadi tanpa disadari. Partitioning, clustering, ukuran file, compaction, pilihan antara incremental dan full rebuild, serta pola query yang benar-benar dijalankan analis, semuanya menggeser tagihan berlipat-lipat â dan tidak satu pun tampak dari hasil akhirnya.
Kapan tim membutuhkan kapabilitas ini
Pekerjaan data biasanya diserap oleh engineer aplikasi dan analis sampai jahitannya mulai terlihat. Berikut situasi ketika pengaturan itu berhenti masuk akal secara ekonomi.
Laporan saling bertentangan
Dua dashboard memberi jawaban berbeda untuk metrik dan bulan yang sama, karena definisinya diimplementasikan terpisah di masing-masing tool, oleh orang berbeda, pada waktu berbeda. Setiap rapat kemudian menghabiskan sepuluh menit pertamanya untuk memperdebatkan angka siapa yang benar.
Pipeline rusak setiap kali layanan hulu berubah
Sebuah field diganti namanya atau tipenya berubah, tidak ada yang memberi peringatan, dan kegagalannya baru ketahuan saat sebuah grafik tampil kosong. Tanpa kesepakatan di batas antartim, ini berulang tanpa henti dan perbaikannya selalu bersifat retrospektif.
Analis menghabiskan sebagian besar pekannya menyiapkan data
Orang-orang terampil membersihkan, menggabungkan, dan menghapus duplikat secara manual sebelum bisa memulai analisis yang menjadi alasan mereka dipekerjakan â dan masing-masing melakukannya dengan cara yang sedikit berbeda, yang justru menjadi sumber laporan yang saling bertentangan tadi.
Tagihan platform tumbuh lebih cepat daripada bisnisnya
Belanja compute naik tanpa diikuti kenaikan yang sepadan pada apa yang dihasilkan platform. Mendiagnosisnya berarti memeriksa pola query, tata letak tabel, pilihan materialisasi, dan full rebuild yang sebenarnya bisa incremental â bukan bernegosiasi dengan vendor.
Kebutuhan freshness bergeser dari harian menjadi hitungan menit
Sebuah use case operasional kini menuntut data yang tidak bisa dipenuhi batch semalam. Streaming membawa serta delivery semantics, kedatangan yang tidak berurutan, windowing dan watermark, serta beban operasional yang rutin diremehkan tim sebelum mereka berkomitmen padanya.
Tidak ada yang bisa menjelaskan asal sebuah angka
Auditor, regulator, atau pelanggan menanyakan bagaimana sebuah angka diturunkan, dan jawaban jujurnya adalah serangkaian transformasi yang tidak pernah didokumentasikan siapa pun. Lineage menjadi mendesak justru ketika ia paling sulit direkonstruksi.
Kapabilitas inti
Ingestion
Ekstraksi batch, change data capture dari database operasional, konsumsi event, dan konektor pihak ketiga â berikut bagian yang tidak menarik: replay, backfill, rate limit, dan vendor yang hasil ekspornya sesekali tidak lengkap.
Transformasi dan pemodelan
Membentuk data mentah menjadi tabel yang bisa dipahami orang: model dimensional di tempat yang memang terbantu, denormalisasi yang disengaja di tempat yang tidak, logika incremental yang aman dijalankan ulang, dan test yang hidup bersama modelnya, bukan di sebelahnya.
Orchestration
Graf dependensi, kebijakan retry, semantik backfill, kesadaran partisi, dan komitmen freshness â supaya sumber yang terlambat hanya menurunkan kualitas satu dataset, bukan merambat ke seluruh jadwal sesudahnya.
Data contract dan schema evolution
Menyepakati apa yang dijamin produsen data, memvalidasinya di tempat data diproduksi, memberi versi alih-alih mengubah di tempat, serta memberi konsumen pemberitahuan dan jalur migrasi sebelum apa pun ditarik.
Pemeriksaan kualitas
Pemeriksaan freshness, volume baris, keunikan, integritas referensial, dan distribusi, ditempatkan agar masalah tertangkap sebelum sampai ke konsumen, dengan alerting yang dikalibrasi supaya orang masih menanggapinya setelah sebulan berjalan.
Lineage dan observability
Provenance sampai tingkat kolom, analisis dampak sebelum perubahan dilakukan alih-alih setelah ada yang rusak, dan kemampuan menjawab dari mana sebuah angka berasal tanpa membaca setiap transformasi satu per satu.
Arsitektur storage
Memilih antara warehouse, lakehouse, dan operational store, menentukan open table format, serta menetapkan partitioning, ukuran file, dan compaction dengan tepat â keputusan yang diam-diam menentukan kecepatan query sekaligus pengeluaran bulanan.
Streaming
Windowing, watermark, kedatangan yang terlambat dan tidak berurutan, jaminan pengiriman, pengelolaan state, dan pertimbangan untuk mengenali kapan sebuah stream tidak sepadan dengan beban operasionalnya bagi keputusan yang ia dukung.
Rekayasa biaya
Mengetahui workload mana yang mendominasi tagihan, menyesuaikan ukuran compute dengan pekerjaannya, memilih materialisasi alih-alih komputasi ulang jika memang menguntungkan, menerapkan tiering storage, dan mengukur belanja per dataset alih-alih sebagai satu angka bulanan.
Tata kelola dan akses
Mengklasifikasikan data pribadi, melakukan masking dan tokenisasi, menerapkan kontrol akses di tingkat baris dan kolom, memberlakukan retensi, dan memastikan field sensitif tidak muncul kembali di tabel turunan yang tidak diklasifikasikan siapa pun.
Ekosistem teknologi
Berikut teknologi yang umum dipakai dalam data engineering. Daftar ini menggambarkan lanskap disiplinnya secara umum sebagaimana dipraktikkan di pasar, bukan klaim tentang perangkat yang dikuasai engineer mana pun. Produk di bidang ini berganti jauh lebih sering daripada pola kegagalannya berubah, sehingga cara berpikir tentang kebenaran data, idempotency, dan biaya lebih andal berpindah antarstack dibanding nama produk mana pun dalam daftar ini.
Bahasa pemrograman
- Python
- SQL
- Scala
- Java
Ingestion dan streaming
- Apache Kafka
- Debezium
- Apache Flink
- Airbyte
- Fivetran
- Amazon Kinesis
Pemrosesan dan transformasi
- Apache Spark
- dbt
- Apache Beam
- Polars
- DuckDB
Orchestration
- Apache Airflow
- Dagster
- Prefect
- Temporal
Warehouse dan query engine
- Snowflake
- BigQuery
- Databricks
- Amazon Redshift
- ClickHouse
- PostgreSQL
Table format dan storage
- Apache Iceberg
- Delta Lake
- Apache Hudi
- Apache Parquet
- Amazon S3
Kualitas dan cataloguing
- Great Expectations
- Soda
- dbt tests
- OpenMetadata
- DataHub
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Produk
- Prioritas bisnis
- Roadmap
- Arsitektur
- Prioritas sprint
- Standar engineering
- Kolaborasi teknis sehari-hari
Talent.ID handles
- Hubungan kerja
- Payroll
- Benefit karyawan
- Administrasi talenta
- Hubungan karyawan berkelanjutan
Yang perlu dicari saat menilai kandidat
Kandidat di bidang ini biasanya dinilai dari keakraban dengan tool, dan itu sumbu yang keliru. Produknya berganti setiap beberapa tahun sementara pola kegagalannya persis sama, dan area yang paling informatif adalah area yang baru muncul setelah sebuah platform berjalan cukup lama untuk pernah salah setidaknya sekali.
Cara memperlakukan kegagalan senyap
Tanyakan bagaimana mereka akan mengetahui bahwa sebuah job yang sukses ternyata menulis data yang salah. Engineer yang pernah mengalaminya merancang deteksi sejak awal dan bisa menyebut pemeriksaan yang spesifik; yang belum akan menjelaskan pemantauan status job, dan itu memantau hal yang keliru.
- Membedakan job yang gagal dari dataset yang salah tanpa perlu dipancing
- Merekonsiliasi total terhadap sistem sumber alih-alih mempercayai proses load
- Bisa menceritakan angka salah yang sampai ke laporan dan bagaimana akhirnya tertangkap
- Menempatkan pemeriksaan di titik yang melindungi konsumen, bukan hanya di ujung
Perubahan schema dan batas antartim
Tanyakan apa yang terjadi ketika tim produsen data mengubah sebuah field. Jawabannya memperlihatkan apakah mereka melihat ini sebagai masalah engineering yang ditangani di hilir atau sebagai kesepakatan yang dinegosiasikan di hulu â dan hanya yang kedua yang bertahan melewati segelintir sumber data.
- Pernah menegosiasikan data contract dengan tim yang memproduksi data
- Menjadikan perubahan aditif sebagai default dan breaking change sebagai peristiwa tersendiri
- Tahu konsumen mana bergantung pada kolom mana sebelum mengubahnya
- Memberi pemberitahuan dan jendela migrasi alih-alih mengumumkan keputusan yang sudah terjadi
Idempotency dan pemulihan
Tanyakan apa yang terjadi bila sebuah job berjalan dua kali, atau ketika data kemarin harus dibangun ulang setelah ada koreksi di sumber. Ini pembeda teknis paling andal dalam disiplin ini dan justru jarang ditanyakan secara langsung.
- Merancang agar menjalankan ulang satu periode menghasilkan hasil yang sama
- Bisa melakukan backfill satu rentang tanpa menduplikasi atau kehilangan baris
- Menangani record yang tiba setelah partisinya selesai diproses
- Berpikir dalam partisi dan watermark, bukan dalam tabel utuh
Pertimbangan dalam pemodelan
Tanyakan bagaimana mereka menentukan bentuk sebuah tabel. Kandidat kuat memodelkan untuk pertanyaan yang benar-benar diajukan orang dan bisa membenarkan sebuah denormalisasi; yang lebih lemah menerapkan satu metodologi secara seragam dan menghasilkan sesuatu yang elegan tetapi tidak di-query siapa pun.
- Mendefinisikan sebuah metrik bisnis hanya di satu tempat
- Bisa menjelaskan penyimpangan yang disengaja dari bentuk normal
- Memisahkan data mentah dari output kurasi dengan batas yang jelas
- Mengenali kapan lapisan pemodelan penuh melebihi kebutuhan masalahnya
Kejujuran soal freshness
Tanyakan kapan mereka pernah menolak penggunaan streaming. Real-time sering diminta dan lebih jarang benar-benar dibutuhkan, dan engineer yang menanyakan keputusan mana yang bergantung pada freshness akan menghemat banyak beban operasional bagi sebuah tim.
- Berangkat dari keputusan yang didukung data, bukan dari teknologinya
- Pernah merekomendasikan batch ketika pemrosesan kontinu yang diharapkan
- Bisa menjelaskan jaminan pengiriman secara presisi, bukan lewat slogan
- Memperhitungkan biaya menjalankan sistem streaming pada pukul tiga pagi
Kesadaran biaya
Tanyakan komponen terbesar pada tagihan platform terakhir mereka dan apa yang mereka lakukan terhadapnya. Engineer yang pernah memegang anggaran menjawab spesifik; yang belum menganggap belanja sebagai urusan orang lain, dan begitulah sebuah platform diam-diam menjadi pos terbesar kedua dalam anggaran engineering.
- Tahu workload mana yang mendominasi belanja dan mengapa
- Mengubah partitioning, tata letak file, atau materialisasi berdasarkan bukti
- Mengatribusikan biaya ke masing-masing dataset alih-alih ke satu total
- Menalar storage dan compute secara terpisah
Bekerja dengan konsumen data
Engineer yang paling berdampak berbicara dengan analis dan tim produk yang memakai hasil kerjanya. Tanyakan apa yang mereka dokumentasikan tentang sebuah dataset dan untuk siapa mereka menulisnya â jawabannya memisahkan pola pikir melayani dari pola pikir sekadar menyerahkan hasil.
- Mendokumentasikan makna sebuah kolom, bukan hanya tipenya
- Tahu pertanyaan apa yang ingin dijawab oleh dataset terpentingnya
- Mengumumkan perubahan kepada konsumen sebelum melakukannya
- Pernah memensiunkan sebuah dataset secara sengaja alih-alih membiarkannya membusuk
Pertanyaan wawancara yang layak diajukan
Pertanyaan ini disediakan untuk proses wawancara Anda sendiri, untuk dipakai sesuai kebutuhan. Andalah yang menilai setiap kandidat dan memutuskan; pertanyaan di sini dipilih karena sulit dijawab dengan baik tanpa pernah mengoperasikan platform yang benar-benar diandalkan orang.
Sebuah job semalam selesai dengan status sukses tetapi menulis data yang salah. Bagaimana Anda akan mengetahuinya?
What a strong answer shows
Masalah paling inti dalam disiplin ini. Jawaban kuat menguraikan pemeriksaan yang dirancang sejak awal â rekonsiliasi terhadap sumber, pemantauan distribusi dan volume, constraint keunikan â bukan rencana menyelidiki setelah ada yang mengeluh.
Tim hulu mengganti nama sebuah field tanpa memberi tahu siapa pun. Apa yang seharusnya terjadi, dan apa yang Anda lakukan sekarang?
What a strong answer shows
Apakah mereka berpikir dalam kesepakatan atau dalam tambal-sulam. Penanganan langsungnya sederhana; bagian menariknya adalah apa yang mereka usulkan agar perubahan berikutnya diumumkan, bukan ditemukan sendiri.
Jelaskan bagaimana Anda membuat sebuah pipeline aman dijalankan dua kali.
What a strong answer shows
Idempotency dalam praktik. Cari partition key yang deterministik, semantik replace alih-alih append, deduplikasi berdasarkan identifier yang stabil, serta kesadaran tentang efek samping mana yang tidak bisa dibatalkan oleh run ulang.
Dua tim melaporkan angka pendapatan berbeda untuk bulan yang sama. Jelaskan cara Anda menyelesaikannya.
What a strong answer shows
Metode dalam situasi ambigu. Harapkan mereka membandingkan definisi sebelum membandingkan angka, menelusuri kedua angka ke sumbernya, menemukan titik logika mulai berbeda, lalu mengusulkan satu definisi bertuan alih-alih rekonsiliasi sekali jalan.
Kapan Anda pernah menolak penggunaan streaming, dan apa yang Anda usulkan sebagai gantinya?
What a strong answer shows
Pertimbangan terhadap kompleksitas. Kandidat kuat berangkat dari latensi yang benar-benar dituntut keputusannya dan tidak canggung mengatakan bahwa batch tiap jam sudah memenuhinya dengan biaya operasional jauh lebih kecil.
Tagihan warehouse berlipat dua dalam tiga bulan. Jelaskan alur investigasinya.
What a strong answer shows
Kefasihan soal biaya. Cari atribusi di tingkat query, full rebuild baru yang menggantikan proses incremental, menjamurnya file kecil, scan tanpa partisi, atau job terjadwal yang ditambahkan seseorang dan tidak pernah ditinjau.
Bagaimana Anda menangani record yang tiba terlambat atau tidak berurutan?
What a strong answer shows
Apakah waktu dimodelkan secara eksplisit. Harapkan pembedaan antara event time dan processing time, batas keterlambatan yang dinyatakan, dan keputusan tentang apa yang terjadi pada record yang tiba melewati batas itu.
Apa yang Anda tuliskan tentang sebuah dataset, dan siapa pembacanya?
What a strong answer shows
Orientasi melayani. Jawaban terkuat mencakup makna, granularitas, komitmen freshness, catatan keterbatasan yang diketahui, dan kepemilikan â ditulis untuk analis yang akan memakainya dalam waktu singkat, bukan untuk engineer berikutnya.
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- Pelaporan di sebuah organisasi menjadi tidak dapat diandalkan. Definisi metrik yang sama berbeda antartool, pipeline gagal setiap kali sebuah layanan produsen data di-refactor, analis lebih banyak merekonsiliasi ekstrak daripada menganalisisnya, dan belanja platform naik tanpa ada yang bisa mengatribusikannya ke workload tertentu.
- Approach
- Tambahan kapasitas engineering bekerja di dalam praktik yang sudah dimiliki tim â tata letak repositori mereka, konvensi orchestration mereka, proses review mereka, dan arah platform yang telah mereka pilih. Keputusan tentang roadmap, arsitektur, dan urutan backlog tetap berada di tim internal; kapasitas tambahan mengerjakan pekerjaan data contract, kualitas, dan pemodelan dalam ritme sprint yang sama.
- What this adds to the team
- Tim memperluas apa yang bisa mereka kerjakan tanpa melepaskan kendali atas platform maupun prioritasnya. Dataset mana yang penting, dan standar apa yang harus dipenuhinya, tetap menjadi keputusan orang-orang yang memegang tanggung jawab atas hasilnya.
Related disciplines
Frequently asked questions
- Apa bedanya data engineer dan data scientist?
- Data engineer bertanggung jawab agar data tiba dengan benar, tepat waktu, dan dengan maknanya terdokumentasi. Data scientist bertanggung jawab atas arti data itu: merumuskan pertanyaannya, merancang analisisnya, memisahkan efek yang nyata dari kebetulan, dan melaporkan hasilnya lengkap dengan ketidakpastiannya. Yang pertama membangun jalannya; yang kedua menentukan hendak ke mana dan apakah perjalanan itu benar-benar mendukung kesimpulannya. Tim yang hanya menambahkan yang kedua sering mendapati bahwa yang mereka beli adalah pembersihan data yang mahal.
- Apa bedanya data engineer dan analytics engineer?
- Analytics engineer sebagian besar bekerja di dalam warehouse, mengubah data yang sudah dimuat menjadi tabel yang termodelkan, teruji, dan terdokumentasi dengan baik, serta memegang definisi metrik bersama analis yang memakainya. Data engineer memegang permukaan yang lebih luas: ingestion, streaming, infrastruktur orchestration, data contract dengan tim produsen data, arsitektur storage, dan biaya. Keduanya bertemu di lapisan transformasi, dan di organisasi yang lebih kecil satu orang mengerjakan keduanya â yang tidak masalah sampai sisi ingestion benar-benar menuntut perhatian.
- Apakah kami membutuhkan data engineer atau tooling yang lebih baik?
- Tooling memang membantu untuk konektor, orchestration, dan pemeriksaan kualitas, dan tidak ada alasan membangun semua itu sendiri. Namun tooling tidak menyelesaikan apa arti sebuah metrik, tidak menegosiasikan data contract dengan tim yang terus mengubah schema, tidak memutuskan apa yang harus dilakukan terhadap koreksi yang datang terlambat, dan tidak menyadari bahwa sebuah tabel tanpa pemilik telah menyuplai laporan direksi selama setahun. Itulah masalah yang berulang, dan sifatnya organisasional sama besarnya dengan teknis.
- Seberapa banyak software engineering yang dituntut peran ini?
- Lebih banyak daripada yang biasanya diperkirakan. Pipeline adalah sistem produksi: ia butuh version control, test, code review, continuous integration, pemisahan environment, pengelolaan dependensi, dan kemampuan merilis perubahan dengan aman. Tim yang diisi orang-orang yang mahir menulis SQL tetapi belum pernah bekerja dalam proses engineering yang disiplin akan menumpuk aset yang tidak terpelihara lebih cepat daripada dugaan mereka.
- Apakah kapabilitas ini dibutuhkan sebelum mengerjakan apa pun dengan machine learning?
- Hampir selalu. Model mewarisi setiap cacat pada data yang melatihnya, dan penyebab paling umum program pemodelan mandek bukanlah pemodelannya melainkan ketiadaan input yang andal, terdokumentasi, dan benar-benar dipahami. Sebuah tim bisa membuat prototipe tanpa platform, tetapi tidak bisa beroperasi dengan andal di atas ekstrak yang dirakit seseorang secara manual setiap pekan.
- Pada titik mana sebuah tim membutuhkan data engineer kedua?
- Biasanya begitu platform tersebut punya konsumen yang akan merasakan bila terjadi gangguan, yang membuat satu engineer sekaligus menjadi bottleneck dan risiko on-call yang memegang pengetahuan yang tidak dimiliki orang lain. Kebutuhan itu juga muncul ketika ingestion dan transformasi sedang dikembangkan secara aktif pada saat bersamaan, karena keduanya punya ritme kerja berbeda dan satu orang yang berpindah-pindah di antaranya tidak mengerjakan keduanya dengan baik.
- Bagaimana data engineer bekerja dengan tim engineering yang sudah ada?
- Dalam skema penambahan kapasitas tim engineering, tim Andalah yang mengarahkan pekerjaannya: konvensi Anda, proses review Anda, roadmap Anda, dan urutan backlog Anda yang menentukan apa yang dibangun dan kapan, dan percakapan teknis hariannya berlangsung dengan tim Anda sendiri. Talent.ID menangani hubungan kerja, payroll, dan benefit karyawan, beserta administrasi talenta dan hubungan karyawan yang berkelanjutan.
Tell us what your team needs
Describe the gap â the work, the stack, the way your team runs â and we will tell you what we can support. If it is not something we can help with, we will say so.