Dari agile hingga abstraksi, memikirkan data dengan cara yang berpikir tentang perangkat lunak dapat menghemat banyak kesedihan.
Pertama, ada beberapa perbedaan utama antara rekayasa data dan rekayasa perangkat lunak.
Pada saat yang sama, mereka cukup mirip sehingga banyak praktik terbaik yang muncul dalam rekayasa perangkat lunak dapat sangat berguna untuk rekayasa data selama dibingkai dengan benar.
Artikel ini memperkenalkan beberapa praktik terbaik rekayasa perangkat lunak dan menjelaskan bagaimana praktik tersebut dapat membantu Anda membuat dan memelihara alur data yang lebih baik. Kami fokus secara khusus pada jaringan pipa karena mereka difokuskan di muara sungai, tetapi prinsip-prinsip ini juga berlaku untuk seluruh tumpukan data.
Diskusinya kasar. Saya sendiri bukan seorang insinyur perangkat lunak, jadi saya rasa Anda tidak perlu seperti itu untuk mendapatkan nilai strategis dan kepemimpinan dari prinsip-prinsip ini.
Rekayasa Perangkat Lunak dan Rekayasa Data: Persamaan dan Perbedaan
Produk data dan produk perangkat lunak berbeda, begitu pula para pemangku kepentingannya.
Membangun produk perangkat lunak biasanya membutuhkan kolaborasi antara tim yang sangat teknis. Produk ini dapat dikirim secara komersial, seringkali ke berbagai kelompok pengguna. Misalnya, bank membuat aplikasi seluler untuk pelanggan.
Sebaliknya, produk data cenderung ada dalam batas-batas perusahaan. Pemangku kepentingan dan pemangku kepentingan berkisar dari insinyur yang sangat teknis hingga profesional non-teknis yang membutuhkan data untuk melakukan pekerjaan mereka. Misalnya, bank yang sama dapat membuat produk data keuangan dan demografis tentang pelanggannya untuk membantu keamanan, penjualan, dan strategi.
Jika Anda membaca ini, Anda nongkrong di ruang data, jadi saya mungkin tidak perlu repot dengan perbedaan ini. Saya telah melihat secara langsung bagaimana data dapat diperlakukan dengan sangat berbeda dari perangkat lunak, terutama dari perspektif bisnis.
Namun, praktik penting rekayasa data dan rekayasa perangkat lunak pada dasarnya sama. Kami menulis, memelihara, dan menyebarkan kode untuk memecahkan masalah yang dapat diulang. Untuk alasan ini, ada beberapa praktik terbaik rekayasa perangkat lunak berharga yang dapat diterjemahkan ke dalam praktik terbaik rekayasa data. Banyak tren data terbaru, seperti DataMeshing dan DataOps, menerapkan praktik rekayasa perangkat lunak dengan cara baru untuk memberikan hasil yang unggul.
Sejarah Rekayasa Perangkat Lunak dan Rekayasa Data
Untuk memahami mengapa praktik terbaik ini disediakan oleh perangkat lunak dan baru saja diterapkan pada data Anda, Anda perlu memeriksa riwayat.
Bidang rekayasa perangkat lunak pertama kali diakui pada 1960-an. Pada saat itu, gagasan bahwa tindakan menciptakan perangkat lunak adalah bentuk rekayasa adalah konsep yang provokatif. Bahkan, istilah “rekayasa perangkat lunak” sengaja dipilih untuk memberi orang jeda dan mendorong praktisi untuk menerapkan prinsip-prinsip ilmiah pada pekerjaan mereka. Dalam beberapa dekade berikutnya, insinyur perangkat lunak menguji dan menyempurnakan prinsip-prinsip ilmu terapan dan teknik mesin.
Kemudian, pada 1990-an, industri tertinggal di belakang meningkatnya permintaan perangkat lunak, memicu apa yang kemudian dikenal sebagai “krisis pengembangan aplikasi.” Krisis ini mendorong insinyur perangkat lunak untuk mengadopsi pengembangan tangkas dan praktik terkait. Ini berarti memprioritaskan dan mengulangi siklus hidup yang cepat, dan menempatkan nilai pada sistem manusia di belakang perangkat lunak.
Di sisi lain, rekayasa data seperti yang kita kenal ini adalah bidang yang relatif muda. Memang, data telah ada untuk sebagian besar sejarah manusia, dan basis data relasional dibuat pada 1970-an. Namun, hingga tahun 2000-an, basis data berada di bawah yurisdiksi sekelompok kecil manajer, biasanya TI. Infrastruktur data sebagai sumber daya di seluruh perusahaan dengan banyak komponen adalah perkembangan yang relatif baru (belum lagi yang masih berubah dengan cepat). Gelar “insinyur data” lahir pada 2010-an.
Singkatnya, insinyur perangkat lunak telah melakukan pekerjaan yang secara luas mirip dengan apa yang mereka lakukan saat ini, setidaknya selama sekitar 60 tahun. Sementara itu, mereka telah memecahkan banyak tikungan. Dalam dunia rekayasa data, Anda dapat memanfaatkannya.
Tanpa basa-basi lagi, berikut adalah beberapa praktik terbaik rekayasa perangkat lunak yang dapat (dan harus) Anda terapkan ke alur data Anda.
1 – Siapkan siklus hidup (pendek)
Siklus hidup produk (perangkat lunak atau data) adalah proses siklus yang mencakup perencanaan, pembuatan, pendokumentasian, pengujian, penyebaran, dan pemeliharaan.
Pengembangan perangkat lunak yang tangkas menambahkan sentuhan pada hal ini dengan mempersingkat siklus hidup pengembangan untuk memenuhi permintaan sambil terus mengulangi dan meningkatkan produk.
Demikian pula, Anda harus menerapkan siklus hidup alur data dengan cepat.
Kebutuhan akan produk data baru di seluruh organisasi muncul dengan cepat dan sering. Tekan alur kerja siklus hidup untuk memverifikasi bahwa alur kerja tersebut sudah siap.
- Rencanakan dengan pemangku kepentingan untuk memastikan bahwa saluran Anda memberikan produk yang Anda butuhkan.
- Membangun alur—Bergantung pada platform dan antarmuka, Anda dapat membuat spesifikasi atau membuat DAG.
- Dokumentasikan alur — Ini dapat mencakup skema, metadata, atau dokumentasi tertulis (dokumentasi DCT adalah contoh yang menarik, tetapi ada di bagian lain dari tumpukan data).
- Uji alur Anda sebelum Anda menyebarkan — Alat alur memiliki pengujian bawaan, atau Anda dapat menggunakan alat orkestrasi seperti Airflow.
- Sebarkan alur.
- Monitor — Memantau peringatan kesalahan dan melakukan pembaruan.
- Ulangi dengan cepat saat kasus penggunaan berubah—Lanjutkan membangun komponen alur dan daur ulang sebelumnya.
2- Pilih tingkat abstraksi yang tepat
Untuk menjaga siklus hidup data tetap ketat, penting untuk tidak tersesat dalam detail implementasi teknis. Ini membutuhkan abstraksi.
Insinyur perangkat lunak sangat senang dengan konsep abstraksi. Abstraksi adalah penyederhanaan informasi ke dalam objek atau sistem yang lebih umum. Anda juga dapat menganggapnya sebagai generalisasi atau pemodelan.
Dalam rekayasa perangkat lunak, tingkat abstraksi yang relevan biasanya ada di dalam kode itu sendiri. Misalnya, fungsi dan bahasa pemrograman berorientasi objek adalah alat yang berguna, tetapi mereka tidak mengungkapkan detail tentang bagaimana mereka dijalankan.
Dengan data, Anda perlu bekerja pada tingkat abstraksi yang lebih tinggi daripada kode. Ada dua alasan utama untuk ini.
- Hubungan langsung antara produk data dan kasus penggunaan bisnis yang mereka tawarkan berarti Anda ingin berbicara tentang data dalam istilah yang lebih “dunia nyata”. Mengklarifikasi tingkat abstraksi ini berarti membangun lapisan semantik universal dan membantu menghindari masalah umum dari beberapa lapisan semantik yang bersaing yang muncul di berbagai alat BI dan grup pengguna.
- Tingkat teknologi yang Anda lihat di pemangku kepentingan data sangat beragam sehingga berbicara dalam hal sesuatu yang sangat teknis, seperti kode, tidak terlalu membantu.
Dalam kasus alur data, dua abstraksi terkait adalah tindakan menelan data dari satu sistem dan mendorongnya ke sistem lain (muara menggunakan istilah menangkap dan terwujud, tetapi dengan semantik yang berbeda).
Ketika kita berbicara tentang pipa menggunakan istilah seperti “tangkap” dan “materialisasi,” baik insinyur maupun pengguna bisnis dapat bersatu di sekitar nilai semantik pipa (Anda bisa mendapatkan data dari sistem X ke sistem Y dan melakukan Z).
3 — Buat Produk Data Deklaratif
Oke, Anda menangkap saya, ini benar-benar hanya kelanjutan dari diskusi abstraksi, tetapi itu akan memberi lebih banyak substansi pada argumen itu.
Pikirkan data sebagai produk. Ini adalah prinsip utama dari kerangka kerja mesh data umum.
Data sebagai produk dimiliki oleh domain yang berbeda dalam perusahaan Anda, grup pengguna yang memiliki keterampilan berbeda tetapi berbagi kasus penggunaan operasional untuk data Anda. Data sebagai produk dapat dengan cepat diubah menjadi artefak yang dapat mengambil banyak bentuk, tetapi selalu menggunakan case-driven. Dengan kata lain, mereka bukan tentang bagaimana, tetapi tentang apa.
Rekayasa perangkat lunak secara paralel dengan ini adalah pemrograman deklaratif. Pemrograman deklaratif berfokus pada apa yang dapat dilakukan suatu program. Ini berbeda dengan pemrograman imperatif, yang memberi tahu Anda dengan tepat bagaimana melakukan tugas.
Pemrograman deklaratif diabstraksikan di atas pemrograman imperatif: saat runtime, ketika sebuah program dikompilasi, bagaimana itu harus diselesaikan? Namun, pemrograman deklaratif memiliki potensi untuk meningkatkan fleksibilitas pada waktu berjalan dan menghemat sumber daya. Selain itu, itu membuatnya lebih mudah untuk dipahami secara mental, dan itu menjadi lebih mudah didekati.
Dengan membuat alur secara deklaratif (dibangun di atas fungsionalitas, bukan mekanisme), Anda dapat mendukung budaya data Anda sebagai produk dengan lebih baik.
Mulailah dengan produk yang coba disediakan oleh saluran Anda. Misalnya, panggil tampilan terwujud tertentu dan rancang alur berdasarkan itu. Pendekatan deklaratif untuk pipelining membuatnya sulit untuk tersesat dalam detail teknis dan melupakan nilai bisnis data Anda.
4 — Perlindungan dari Kegagalan
Dalam pengembangan perangkat lunak dan alur data, kegagalan tidak dapat dihindari. Ini adalah pelajaran yang diperoleh dengan susah payah yang telah banyak dari kita pelajari melalui kerja keras, seperti terburu-buru untuk memperbaiki sistem yang rusak secara dahsyat, kehilangan kemajuan dan data karena pemadaman, atau hanya membawa kesalahan bodoh ke dalam produksi.
Dalam konteks perangkat lunak dan data, tindakan pencegahan dan pencadangan yang sangat mirip dapat diterapkan.
Berikut adalah beberapa pertimbangan penting: Banyak dari fitur ini dapat dilakukan menggunakan alat orkestrasi data atau alat yang disediakan oleh vendor alur.
Pengujian
Ini harus menjadi bagian dari siklus hidup alur, sama seperti halnya dengan perangkat lunak.
Selain pengujian manual yang komprehensif sebelum penyebaran, Anda harus menulis pengujian unit otomatis untuk memantau alur produksi Anda. Anda mungkin ingin menggunakan alat orkestrasi seperti Airflow, atau Anda mungkin memerlukan pengaturan pemantauan yang lebih kuat untuk mendeteksi semua potensi masalah.
Sebagai aturan praktis, semakin banyak transformasi yang diterapkan alur data, semakin banyak pengujian yang diperlukan.
Kontrol Versi
Insinyur perangkat lunak menggunakan kontrol versi (biasanya Git) untuk berkolaborasi dalam pekerjaan mereka dan mempertahankan kemampuan untuk memutar kembali perangkat lunak ke versi sebelumnya.
Saat menggunakan produk vendor, alur kerja GitOps disediakan sehingga insinyur dapat menggunakan Git untuk berkolaborasi pada alur di lingkungan pengembangan pilihan mereka. Tapi tidak semuanya.
Bahkan jika Anda tidak dapat menggunakan Git untuk infrastruktur data Anda, vendor Anda telah mengaktifkan opsi untuk mencadangkan alur Anda, jadi manfaatkan fitur-fiturnya sebaik-baiknya.
Kemampuan penyimpanan dan pengisian ulang terdistribusi
Dengan munculnya cloud hosting dan penyimpanan, risiko pemadaman dan kehilangan data telah berkurang, tetapi belum hilang.
Infrastruktur data perlu didistribusikan. Ini berarti bahwa komponen yang berbeda harus didistribusikan di server yang berbeda dan dibuat toleran terhadap kesalahan. Tingkat kontrol atas ini tergantung pada penyedia cloud dan vendor yang Anda pilih.
Selalu iterasi
Pelajaran terakhir dari praktik terbaik rekayasa perangkat lunak adalah mengulangi ketika terjadi kesalahan.
Status quo dan praktik terbaik selalu fluks. Ini berlaku untuk rekayasa perangkat lunak, dan juga berlaku untuk rekayasa data.
Pendekatan terbaik selalu dipikirkan dengan baik, membuat perubahan yang aman, dan melibatkan dukungan dari semua pemangku kepentingan.
Mulailah dengan prinsip-prinsip ini dan bekerjalah dengannya agar sesuai dengan sistem dan budaya tim data Anda. Perhatikan area di mana efek positif dan perbaikan diperlukan, dan lanjutkan dari sana.
