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, tekanan yang memunculkan kebutuhannya, dan bagaimana ia melayani tim yang bergantung padanya.
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
Bagaimana peran ini bekerja dengan tim Anda
Engineer bekerja di dalam tim Anda, mengikuti prioritas dan standar Anda. Anda yang mengarahkan pekerjaannya; Talent.ID menangani hubungan kerjanya. Pembagian di bawah ini adalah keseluruhan pengaturannya.
Tetap milik Anda
- Produk
- Prioritas bisnis
- Roadmap
- Arsitektur
- Prioritas sprint
- Standar engineering
- Kolaborasi teknis sehari-hari
Ditangani Talent.ID
- Hubungan kerja
- Payroll
- Benefit karyawan
- Administrasi talenta
- Hubungan karyawan berkelanjutan
Seperti apa ini dalam praktik
Skenario hipotetis, ditulis untuk menunjukkan bagaimana model kerjanya diterapkan. Ini bukan klien Talent.ID dan bukan proyek yang pernah dikerjakan.
- Tantangan
- 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.
- Pendekatan
- 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.
- Yang ditambahkan ke tim
- 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.
Disiplin terkait
Pertanyaan yang sering diajukan
- 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.
Ceritakan kebutuhan tim Anda
Jelaskan kekurangannya â pekerjaannya, stack-nya, cara tim Anda berjalan â dan kami akan menyampaikan apa yang dapat kami dukung. Bila bukan sesuatu yang bisa kami bantu, kami akan mengatakannya.