Penerapan kode rendah dalam platform analitis

Pembaca yang budiman, selamat siang!

Tugas membangun platform TI untuk mengumpulkan dan menganalisis data cepat atau lambat muncul bagi perusahaan mana pun yang bisnisnya didasarkan pada model penyampaian layanan yang sarat intelektual atau penciptaan produk yang secara teknis rumit. Membangun platform analitis adalah tugas yang kompleks dan memakan waktu. Namun, tugas apa pun bisa disederhanakan. Pada artikel ini saya ingin berbagi pengalaman saya dalam menggunakan alat low-code untuk membantu menciptakan solusi analitis. Pengalaman ini diperoleh selama implementasi sejumlah proyek ke arah Solusi Big Data dari perusahaan Neoflex. Sejak tahun 2005, arahan Solusi Big Data Neoflex telah menangani masalah pembangunan gudang data dan danau, memecahkan masalah dalam mengoptimalkan kecepatan pemrosesan informasi dan mengerjakan metodologi untuk manajemen kualitas data.

Tidak ada seorang pun yang dapat menghindari akumulasi data yang terstruktur secara lemah dan/atau kuat secara sadar. Mungkin bahkan jika kita berbicara tentang usaha kecil. Lagi pula, ketika meningkatkan skala bisnis, wirausahawan yang menjanjikan akan dihadapkan pada masalah pengembangan program loyalitas, ingin menganalisis efektivitas tempat penjualan, memikirkan iklan yang ditargetkan, dan akan bingung dengan permintaan akan produk yang menyertainya. . Sebagai perkiraan pertama, masalahnya bisa diselesaikan “dengan berlutut”. Namun seiring pertumbuhan bisnis, penggunaan platform analitis masih merupakan hal yang tidak bisa dihindari.

Namun, dalam kasus apa tugas analisis data dapat berkembang menjadi masalah kelas “Ilmu Roket”? Mungkin saat ini kita sedang membicarakan data yang sangat besar.
Untuk mempermudah Ilmu Roket, Anda bisa memakan gajah sepotong demi sepotong.

Semakin terpisah dan otonom aplikasi/layanan/layanan mikro Anda, semakin mudah bagi Anda, kolega Anda, dan seluruh bisnis untuk mencerna hal tersebut.

Hampir semua klien kami menerima postulat ini, setelah membangun kembali lanskap berdasarkan praktik teknik tim DevOps.

Namun bahkan dengan pola makan yang “terpisah dan bersifat gajah”, kita mempunyai peluang besar untuk mengalami “kejenuhan yang berlebihan” terhadap lanskap TI. Pada saat ini ada baiknya berhenti, menghembuskan napas, dan melihat ke samping platform rekayasa kode rendah.

Banyak pengembang yang takut dengan prospek jalan buntu dalam karir mereka ketika beralih dari menulis kode secara langsung ke arah “menyeret” panah di antarmuka UI sistem kode rendah. Namun kemunculan peralatan mesin tidak menyebabkan hilangnya para insinyur, tetapi membawa pekerjaan mereka ke tingkat yang baru!

Mari kita cari tahu alasannya.

Analisis data di bidang logistik, industri telekomunikasi, riset media, sektor keuangan selalu dikaitkan dengan pertanyaan-pertanyaan berikut:

• Kecepatan analisis otomatis;
• Kemampuan untuk melakukan eksperimen tanpa mempengaruhi aliran produksi data utama;
• Keandalan data yang disiapkan;
• Ubah pelacakan dan pembuatan versi;
• Asal data, Data garis keturunan, CDC;
• Pengiriman cepat fitur-fitur baru ke lingkungan produksi;
• Dan yang terkenal: biaya pengembangan dan dukungan.

Artinya, para insinyur memiliki sejumlah besar tugas tingkat tinggi, yang dapat diselesaikan dengan efisiensi yang memadai hanya dengan menjernihkan kesadaran mereka akan tugas-tugas pengembangan tingkat rendah.

Prasyarat bagi pengembang untuk pindah ke tingkat yang baru adalah evolusi dan digitalisasi bisnis. Nilai pengembang juga berubah: terdapat kekurangan signifikan pengembang yang dapat membenamkan diri dalam konsep bisnis yang diotomatisasi.

Mari kita analogikan dengan bahasa pemrograman tingkat rendah dan tingkat tinggi. Peralihan dari bahasa tingkat rendah ke bahasa tingkat tinggi merupakan peralihan dari penulisan “arahan langsung dalam bahasa perangkat keras” menuju “arahan dalam bahasa manusia”. Artinya, menambahkan beberapa lapisan abstraksi. Dalam hal ini, transisi ke platform kode rendah dari bahasa pemrograman tingkat tinggi merupakan transisi dari “arahan dalam bahasa manusia” menuju “arahan dalam bahasa bisnis”. Jika ada developer yang merasa sedih dengan kenyataan ini, maka mereka mungkin sudah sedih sejak lahirnya Java Script yang menggunakan fungsi pengurutan array. Dan fungsi-fungsi ini, tentu saja, memiliki implementasi perangkat lunak melalui cara lain dari pemrograman tingkat tinggi yang sama.

Oleh karena itu, kode rendah hanyalah tampilan dari tingkat abstraksi lainnya.

Pengalaman terapan menggunakan kode rendah

Topik kode rendah cukup luas, tetapi sekarang saya ingin berbicara tentang penerapan praktis “konsep kode rendah” menggunakan contoh salah satu proyek kami.

Divisi Solusi Big Data Neoflex lebih mengkhususkan diri pada sektor bisnis keuangan, membangun gudang data dan danau serta mengotomatisasi berbagai pelaporan. Di ceruk ini, penggunaan kode rendah telah lama menjadi standar. Alat kode rendah lainnya termasuk alat untuk mengatur proses ETL: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Atau Oracle Apex, yang bertindak sebagai lingkungan untuk perkembangan pesat antarmuka untuk mengakses dan mengedit data. Namun, penggunaan alat pengembangan kode rendah tidak selalu melibatkan pembangunan aplikasi yang sangat bertarget pada tumpukan teknologi komersial dengan ketergantungan yang jelas pada vendor.

Dengan menggunakan platform kode rendah, Anda juga dapat mengatur orkestrasi aliran data, membuat platform ilmu data, atau, misalnya, modul untuk memeriksa kualitas data.

Salah satu contoh penerapan pengalaman dalam menggunakan alat pengembangan kode rendah adalah kolaborasi antara Neoflex dan Mediascope, salah satu pemimpin di pasar riset media Rusia. Salah satu tujuan bisnis perusahaan ini adalah menghasilkan data yang menjadi dasar bagi pengiklan, platform Internet, saluran TV, stasiun radio, biro iklan, dan merek untuk mengambil keputusan mengenai pembelian iklan dan merencanakan komunikasi pemasaran mereka.

Riset media adalah bidang bisnis yang sarat teknologi. Mengenali urutan video, mengumpulkan data dari perangkat yang menganalisis tampilan, mengukur aktivitas pada sumber daya web - semua ini menyiratkan bahwa perusahaan memiliki staf TI yang banyak dan pengalaman luas dalam membangun solusi analitis. Namun pertumbuhan eksponensial dalam jumlah informasi, jumlah dan keragaman sumbernya memaksa industri data TI untuk terus mengalami kemajuan. Solusi paling sederhana untuk meningkatkan platform analitik Mediascope yang sudah berfungsi adalah dengan menambah staf TI. Namun solusi yang jauh lebih efektif adalah mempercepat proses pembangunan. Salah satu langkah menuju arah ini mungkin adalah penggunaan platform berkode rendah.

Pada saat proyek dimulai, perusahaan sudah memiliki solusi produk yang berfungsi. Namun, penerapan solusi di MSSQL tidak dapat sepenuhnya memenuhi harapan untuk menskalakan fungsionalitas sambil mempertahankan biaya pengembangan yang dapat diterima.

Tugas yang kami hadapi benar-benar ambisius - Neoflex dan Mediascope harus menciptakan solusi industri dalam waktu kurang dari satu tahun, dengan syarat MVP dirilis pada kuartal pertama sejak tanggal mulai.

Tumpukan teknologi Hadoop dipilih sebagai landasan untuk membangun platform data baru berdasarkan komputasi kode rendah. HDFS telah menjadi standar penyimpanan data menggunakan file parket. Untuk mengakses data yang terletak di platform, digunakan Hive, di mana semua etalase yang tersedia disajikan dalam bentuk tabel eksternal. Memuat data ke dalam penyimpanan diimplementasikan menggunakan Kafka dan Apache NiFi.

Alat kode Lowe dalam konsep ini digunakan untuk mengoptimalkan tugas paling padat karya dalam membangun platform analitis - tugas penghitungan data.

Alat Datagram kode rendah dipilih sebagai mekanisme utama untuk pemetaan data. Datagram Neoflex adalah alat untuk mengembangkan transformasi dan aliran data.
Dengan menggunakan alat ini, Anda dapat melakukannya tanpa menulis kode Scala secara manual. Kode Scala dihasilkan secara otomatis menggunakan pendekatan Model Driven Architecture.

Keuntungan nyata dari pendekatan ini adalah mempercepat proses pengembangan. Namun selain kecepatan, ada juga kelebihannya sebagai berikut:

• Melihat isi dan struktur sumber/penerima;
• Menelusuri asal usul objek aliran data ke masing-masing bidang (garis keturunan);
• Eksekusi sebagian transformasi dengan melihat hasil antara;
• Meninjau kode sumber dan menyesuaikannya sebelum dieksekusi;
• Validasi transformasi secara otomatis;
• Pengunduhan data otomatis 1 in 1.

Hambatan untuk masuk ke solusi kode rendah untuk menghasilkan transformasi cukup rendah: pengembang perlu mengetahui SQL dan memiliki pengalaman bekerja dengan alat ETL. Perlu disebutkan bahwa generator transformasi berbasis kode bukanlah alat ETL dalam arti luas. Alat berkode rendah mungkin tidak memiliki lingkungan eksekusi kodenya sendiri. Artinya, kode yang dihasilkan akan dieksekusi di lingkungan yang ada di cluster bahkan sebelum solusi kode rendah diinstal. Dan ini mungkin merupakan nilai tambah lainnya untuk karma kode rendah. Karena, secara paralel dengan tim berkode rendah, tim "klasik" dapat bekerja yang mengimplementasikan fungsionalitas, misalnya, dalam kode Scala murni. Membawa perbaikan dari kedua tim ke dalam produksi akan menjadi sederhana dan lancar.

Mungkin perlu dicatat bahwa selain solusi berkode rendah, ada juga solusi tanpa kode. Dan pada intinya, ini adalah hal yang berbeda. Kode rendah memungkinkan pengembang untuk lebih banyak campur tangan dalam kode yang dihasilkan. Dalam kasus Datagram, dimungkinkan untuk melihat dan mengedit kode Scala yang dihasilkan; tanpa kode mungkin tidak memberikan kesempatan seperti itu. Perbedaan ini sangat signifikan tidak hanya dalam hal fleksibilitas solusi, tetapi juga dalam hal kenyamanan dan motivasi dalam pekerjaan para data engineer.

Arsitektur solusi

Mari kita coba mencari tahu dengan tepat bagaimana alat berkode rendah membantu memecahkan masalah mengoptimalkan kecepatan pengembangan fungsionalitas penghitungan data. Pertama, mari kita lihat arsitektur fungsional sistem. Contoh dalam hal ini adalah model produksi data untuk riset media.

Sumber data dalam kasus kami sangat heterogen dan beragam:

• People meter (TV meter) adalah perangkat lunak dan perangkat keras yang membaca perilaku pengguna dari responden panel televisi – siapa, kapan, dan saluran TV apa yang ditonton di rumah tangga yang berpartisipasi dalam penelitian. Informasi yang diberikan adalah aliran interval penayangan siaran yang terkait dengan paket media dan produk media. Data pada tahap pemuatan ke Data Lake dapat diperkaya dengan atribut demografi, geostratifikasi, zona waktu, dan informasi lain yang diperlukan untuk menganalisis penayangan televisi dari produk media tertentu. Pengukuran yang dilakukan dapat digunakan untuk menganalisis atau merencanakan kampanye periklanan, menilai aktivitas dan preferensi penonton, dan menyusun jaringan penyiaran;
• Data tersebut dapat berasal dari sistem pemantauan streaming siaran televisi dan pengukuran penayangan konten sumber video di Internet;
• Alat pengukuran di lingkungan web, termasuk pengukur yang berpusat pada situs dan yang berpusat pada pengguna. Penyedia data untuk Data Lake dapat berupa add-on browser bilah penelitian dan aplikasi seluler dengan VPN bawaan.
• Data juga dapat berasal dari situs yang menggabungkan hasil pengisian kuesioner online dan hasil wawancara telepon dalam survei perusahaan;
• Pengayaan tambahan pada data lake dapat dilakukan dengan mengunduh informasi dari log perusahaan mitra.

Implementasi pemuatan dari sistem sumber ke pementasan utama data mentah dapat diatur dengan berbagai cara. Jika kode rendah digunakan untuk tujuan ini, pembuatan skrip pemuatan otomatis berdasarkan metadata dimungkinkan. Dalam hal ini, tidak perlu turun ke tingkat pengembangan sumber untuk menargetkan pemetaan. Untuk menerapkan pemuatan otomatis, kita perlu membuat koneksi ke sumber, dan kemudian menentukan di antarmuka pemuatan daftar entitas yang akan dimuat. Struktur direktori di HDFS akan dibuat secara otomatis dan sesuai dengan struktur penyimpanan data pada sistem sumber.

Namun, dalam konteks proyek ini, kami memutuskan untuk tidak menggunakan fitur platform kode rendah ini karena perusahaan Mediascope telah secara mandiri mulai memproduksi layanan serupa menggunakan kombinasi Nifi + Kafka.

Penting untuk segera menunjukkan bahwa alat-alat ini tidak dapat dipertukarkan, melainkan saling melengkapi. Nifi dan Kafka dapat bekerja baik secara langsung (Nifi -> Kafka) maupun terbalik (Kafka -> Nifi). Untuk platform riset media, bundel versi pertama digunakan.

Dalam kasus kami, NayFi perlu memproses berbagai jenis data dari sistem sumber dan mengirimkannya ke broker Kafka. Dalam hal ini, pesan dikirim ke topik Kafka tertentu menggunakan prosesor PublishKafka Nifi. Orkestrasi dan pemeliharaan saluran pipa ini dilakukan dalam antarmuka visual. Alat Nifi dan penggunaan kombinasi Nifi + Kafka juga dapat disebut sebagai pendekatan pengembangan kode rendah, yang memiliki hambatan rendah untuk masuk ke teknologi Big Data dan mempercepat proses pengembangan aplikasi.

Tahap selanjutnya dalam implementasi proyek adalah membawa data rinci ke dalam format lapisan semantik tunggal. Jika suatu entitas memiliki atribut historis, penghitungan dilakukan dalam konteks partisi yang dimaksud. Jika entitas tersebut tidak historis, maka secara opsional dimungkinkan untuk menghitung ulang seluruh konten objek, atau menolak sepenuhnya menghitung ulang objek ini (karena kurangnya perubahan). Pada tahap ini, kunci dibuat untuk semua entitas. Kunci disimpan di direktori Hbase yang sesuai dengan objek master, yang berisi korespondensi antara kunci di platform analitik dan kunci dari sistem sumber. Konsolidasi entitas atom disertai dengan pengayaan hasil perhitungan awal data analitik. Kerangka kerja penghitungan data adalah Spark. Fungsionalitas yang dijelaskan untuk membawa data ke semantik tunggal juga diimplementasikan berdasarkan pemetaan dari alat Datagram kode rendah.

Arsitektur target memerlukan akses SQL ke data untuk pengguna bisnis. Hive digunakan untuk opsi ini. Objek didaftarkan di Hive secara otomatis saat Anda mengaktifkan opsi "Registr Hive Table" di alat kode rendah.

Kontrol aliran perhitungan

Datagram memiliki antarmuka untuk membuat desain alur kerja. Pemetaan dapat diluncurkan menggunakan penjadwal Oozie. Di antarmuka pengembang aliran, dimungkinkan untuk membuat skema untuk transformasi data paralel, berurutan, atau bergantung pada eksekusi. Ada dukungan untuk skrip shell dan program java. Dimungkinkan juga untuk menggunakan server Apache Livy. Apache Livy digunakan untuk menjalankan aplikasi langsung dari lingkungan pengembangan.

Jika perusahaan sudah memiliki orkestrator prosesnya sendiri, REST API dapat digunakan untuk menyematkan pemetaan ke dalam alur yang ada. Misalnya, kami memiliki pengalaman yang cukup sukses dalam menyematkan pemetaan di Scala ke dalam orkestrator yang ditulis dalam PLSQL dan Kotlin. REST API dari alat berkode rendah mencakup operasi seperti menghasilkan tahun yang dapat dieksekusi berdasarkan desain pemetaan, memanggil pemetaan, memanggil urutan pemetaan, dan, tentu saja, meneruskan parameter ke URL untuk menjalankan pemetaan.

Bersamaan dengan Oozie, dimungkinkan untuk mengatur aliran perhitungan menggunakan Airflow. Mungkin saya tidak akan membahas perbandingan antara Oozie dan Airflow untuk waktu yang lama, tetapi saya hanya akan mengatakan bahwa dalam konteks pekerjaan pada proyek penelitian media, pilihannya jatuh pada Airflow. Argumen utama kali ini adalah komunitas yang lebih aktif dalam mengembangkan produk dan antarmuka + API yang lebih berkembang.

Aliran udara juga bagus karena menggunakan Python tercinta untuk menjelaskan proses perhitungan. Dan secara umum, tidak banyak platform manajemen alur kerja open source. Meluncurkan dan memantau pelaksanaan proses (termasuk bagan Gantt) hanya menambah poin karma Airflow.

Format file konfigurasi untuk meluncurkan pemetaan solusi kode rendah telah menjadi pengiriman percikan. Hal ini terjadi karena dua alasan. Pertama, spark-submit memungkinkan Anda menjalankan file jar secara langsung dari konsol. Kedua, ini dapat berisi semua informasi yang diperlukan untuk mengonfigurasi alur kerja (yang membuatnya lebih mudah untuk menulis skrip yang menghasilkan Dag).
Elemen paling umum dari alur kerja Airflow dalam kasus kami adalah SparkSubmitOperator.

SparkSubmitOperator memungkinkan Anda menjalankan jars - pemetaan Datagram yang dikemas dengan parameter masukan yang telah dibuat sebelumnya.

Perlu disebutkan bahwa setiap tugas Airflow berjalan di thread terpisah dan tidak mengetahui apa pun tentang tugas lainnya. Oleh karena itu, interaksi antar tugas dilakukan menggunakan operator kontrol, seperti DummyOperator atau BranchPythonOperator.

Secara keseluruhan, penggunaan solusi kode rendah Datagram bersamaan dengan universalisasi file konfigurasi (membentuk Dag) menghasilkan percepatan dan penyederhanaan yang signifikan dalam proses pengembangan aliran pemuatan data.

Perhitungan pamer

Mungkin tahapan yang paling sarat secara intelektual dalam produksi data analitis adalah tahap pembuatan etalase. Dalam konteks salah satu aliran penghitungan data perusahaan riset, pada tahap ini, data direduksi menjadi siaran referensi, dengan mempertimbangkan koreksi zona waktu dan dihubungkan ke jaringan siaran. Dimungkinkan juga untuk menyesuaikan dengan jaringan siaran lokal (berita dan iklan lokal). Langkah ini antara lain membagi interval penayangan produk media secara terus-menerus berdasarkan analisis interval penayangan. Segera, nilai tampilan “ditimbang” berdasarkan informasi tentang signifikansinya (perhitungan faktor koreksi).

Langkah tersendiri dalam mempersiapkan etalase adalah validasi data. Algoritma validasi melibatkan penggunaan sejumlah model ilmu matematika. Namun, penggunaan platform kode rendah memungkinkan Anda memecah algoritma kompleks menjadi sejumlah pemetaan terpisah yang dapat dibaca secara visual. Masing-masing pemetaan melakukan tugas yang sempit. Hasilnya, proses debug menengah, pencatatan log, dan visualisasi tahapan persiapan data dapat dilakukan.

Diputuskan untuk mendiskritisasi algoritma validasi ke dalam subtahap berikut:

• Membangun regresi ketergantungan penayangan jaringan TV di suatu wilayah dengan penayangan semua jaringan di wilayah tersebut selama 60 hari.
• Perhitungan sisa siswa (penyimpangan nilai aktual dari yang diprediksi oleh model regresi) untuk semua titik regresi dan untuk hari penghitungan.
• Pilihan pasangan wilayah-jaringan yang anomali, di mana saldo siswa pada hari penyelesaian melebihi norma (ditentukan oleh pengaturan operasi).
• Penghitungan ulang sisa pelajar yang dikoreksi untuk pasangan wilayah-jaringan TV yang anomali untuk setiap responden yang menonton jaringan di wilayah tersebut, menentukan kontribusi responden ini (besarnya perubahan sisa pelajar) ketika tidak termasuk penayangan responden ini dari sampel .
• Cari kandidat yang pengecualiannya membuat saldo gaji siswa kembali normal.

Contoh di atas menegaskan hipotesis bahwa seorang insinyur data sudah memikirkan terlalu banyak hal... Dan, jika ini benar-benar seorang "insinyur" dan bukan "pembuat kode", maka ketakutan akan degradasi profesional saat menggunakan alat berkode rendah dia akhirnya harus mundur.

Apa lagi yang bisa dilakukan kode rendah?

Cakupan penerapan alat kode rendah untuk pemrosesan data batch dan streaming tanpa perlu menulis kode secara manual di Scala tidak berakhir di situ.

Penggunaan low-code dalam pengembangan datalake sudah menjadi standar bagi kami. Kita mungkin dapat mengatakan bahwa solusi berdasarkan tumpukan Hadoop mengikuti jalur pengembangan DWH klasik berdasarkan RDBMS. Alat berkode rendah di tumpukan Hadoop dapat menyelesaikan tugas pemrosesan data dan tugas membangun antarmuka BI akhir. Selain itu, perlu dicatat bahwa BI tidak hanya berarti representasi data, tetapi juga pengeditannya oleh pengguna bisnis. Kami sering menggunakan fungsi ini ketika membangun platform analitis untuk sektor keuangan.

Antara lain, dengan menggunakan kode rendah dan, khususnya, Datagram, masalah pelacakan asal objek aliran data dengan atomisitas hingga ke bidang individual (garis keturunan) dapat diselesaikan. Untuk melakukan hal ini, alat berkode rendah mengimplementasikan antarmuka dengan Apache Atlas dan Cloudera Navigator. Pada dasarnya, pengembang perlu mendaftarkan sekumpulan objek dalam kamus Atlas dan mereferensikan objek yang terdaftar saat membuat pemetaan. Mekanisme pelacakan asal data atau analisis ketergantungan objek menghemat banyak waktu ketika diperlukan perbaikan pada algoritma perhitungan. Misalnya, saat menyiapkan laporan keuangan, fitur ini memungkinkan Anda untuk lebih nyaman bertahan dalam periode perubahan undang-undang. Lagi pula, semakin baik kita memahami ketergantungan antar-bentuk dalam konteks objek pada lapisan terperinci, semakin sedikit kita akan menemukan cacat “mendadak” dan mengurangi jumlah pengerjaan ulang.

Kualitas Data & Kode Rendah

Tugas lain yang diterapkan oleh alat berkode rendah pada proyek Mediascope adalah tugas kelas Kualitas Data. Ciri khusus penerapan jalur verifikasi data untuk proyek perusahaan riset adalah kurangnya dampak terhadap kinerja dan kecepatan aliran penghitungan data utama. Untuk dapat mengatur alur verifikasi data independen, Apache Airflow yang sudah familiar digunakan. Saat setiap langkah produksi data telah siap, bagian terpisah dari pipeline DQ diluncurkan secara paralel.

Memantau kualitas data sejak awal digunakan di platform analitik dianggap sebagai praktik yang baik. Memiliki informasi tentang metadata, kita dapat memeriksa kepatuhan terhadap kondisi dasar sejak informasi memasuki lapisan utama - bukan nol, batasan, kunci asing. Fungsionalitas ini diimplementasikan berdasarkan pemetaan kelompok kualitas data yang dihasilkan secara otomatis di Datagram. Pembuatan kode dalam hal ini juga didasarkan pada metadata model. Pada proyek Mediascope, antarmuka dilakukan dengan metadata produk Enterprise Architect.

Dengan memasangkan alat berkode rendah dengan Enterprise Architect, pemeriksaan berikut dibuat secara otomatis:

• Memeriksa keberadaan nilai “null” di bidang dengan pengubah “not null”;
• Memeriksa keberadaan duplikat kunci utama;
• Memeriksa kunci asing suatu entitas;
• Memeriksa keunikan string berdasarkan sekumpulan bidang.

Untuk pemeriksaan ketersediaan dan keandalan data yang lebih kompleks, pemetaan dibuat dengan Scala Expression, yang mengambil masukan kode pemeriksaan Spark SQL eksternal yang disiapkan oleh analis di Zeppelin.

Tentu saja, pembuatan pemeriksaan otomatis harus dilakukan secara bertahap. Dalam kerangka proyek yang dijelaskan, hal ini didahului dengan langkah-langkah berikut:

• DQ diimplementasikan di notebook Zeppelin;
• DQ dibangun ke dalam pemetaan;
• DQ berupa pemetaan masif terpisah yang memuat keseluruhan rangkaian pemeriksaan untuk suatu entitas tersendiri;
• Pemetaan DQ berparameter universal yang menerima informasi tentang metadata dan pemeriksaan bisnis sebagai masukan.

Mungkin keuntungan utama dari membuat layanan pemeriksaan berparameter adalah pengurangan waktu yang diperlukan untuk mengirimkan fungsionalitas ke lingkungan produksi. Pemeriksaan kualitas baru dapat melewati pola klasik pengiriman kode secara tidak langsung melalui lingkungan pengembangan dan pengujian:

• Semua pemeriksaan metadata dihasilkan secara otomatis ketika model dimodifikasi di EA;
• Pemeriksaan ketersediaan data (menentukan keberadaan data apa pun pada suatu titik waktu) dapat dihasilkan berdasarkan direktori yang menyimpan perkiraan waktu kemunculan bagian data berikutnya dalam konteks objek;
• Pemeriksaan validasi data bisnis dibuat oleh analis di buku catatan Zeppelin. Dari sana mereka dikirim langsung ke tabel pengaturan modul DQ di lingkungan produksi.

Tidak ada risiko pengiriman skrip langsung ke produksi. Bahkan dengan kesalahan sintaksis, ancaman maksimal yang kami hadapi adalah kegagalan melakukan satu pemeriksaan, karena aliran perhitungan data dan aliran peluncuran pemeriksaan kualitas terpisah satu sama lain.

Intinya, layanan DQ berjalan secara permanen di lingkungan produksi dan siap memulai pekerjaannya saat data berikutnya muncul.

Alih-alih sebuah kesimpulan

Keuntungan menggunakan kode rendah sudah jelas. Pengembang tidak perlu mengembangkan aplikasi dari awal. Dan seorang programmer yang terbebas dari tugas tambahan memberikan hasil lebih cepat. Kecepatan, pada gilirannya, memberikan waktu tambahan untuk menyelesaikan masalah pengoptimalan. Oleh karena itu, dalam hal ini, Anda dapat mengandalkan solusi yang lebih baik dan lebih cepat.

Tentu saja, kode rendah bukanlah obat mujarab, dan keajaiban tidak akan terjadi dengan sendirinya:

• Industri kode rendah sedang melalui tahap “semakin kuat”, dan belum ada standar industri yang seragam;
• Banyak solusi berkode rendah tidak gratis, dan membelinya harus menjadi langkah sadar, yang harus dilakukan dengan keyakinan penuh akan manfaat finansial dari penggunaannya;
• Banyak solusi kode rendah tidak selalu berfungsi dengan baik dengan GIT/SVN. Atau tidak nyaman digunakan jika kode yang dihasilkan disembunyikan;
• Saat memperluas arsitektur, mungkin perlu untuk menyempurnakan solusi kode rendah - yang, pada gilirannya, memicu efek “keterikatan dan ketergantungan” pada pemasok solusi kode rendah.
• Tingkat keamanan yang memadai dimungkinkan, namun sangat padat karya dan sulit diterapkan pada mesin sistem kode rendah. Platform berkode rendah harus dipilih tidak hanya berdasarkan prinsip mencari keuntungan dari penggunaannya. Saat memilih, ada baiknya mengajukan pertanyaan tentang ketersediaan fungsionalitas untuk kontrol akses dan delegasi/eskalasi data identifikasi ke tingkat keseluruhan lanskap TI organisasi.

Namun, jika semua kekurangan dari sistem yang dipilih diketahui oleh Anda, dan manfaat dari penggunaannya masih mendominasi, maka lanjutkan ke kode kecil tanpa rasa takut. Selain itu, transisi ke arah tersebut tidak dapat dihindari - sama seperti evolusi lainnya yang tidak dapat dihindari.

Jika satu pengembang pada platform kode rendah melakukan pekerjaannya lebih cepat daripada dua pengembang tanpa kode rendah, maka hal ini memberikan perusahaan keunggulan dalam segala hal. Ambang batas untuk masuk ke dalam solusi low-code lebih rendah dibandingkan dengan teknologi “tradisional”, dan hal ini berdampak positif pada masalah kekurangan personel. Saat menggunakan alat berkode rendah, interaksi antar tim fungsional dapat dipercepat dan pengambilan keputusan lebih cepat mengenai kebenaran jalur penelitian ilmu data yang dipilih. Platform tingkat rendah dapat mendorong transformasi digital suatu organisasi karena solusi yang dihasilkan dapat dipahami oleh spesialis non-teknis (khususnya pengguna bisnis).

Jika Anda memiliki tenggat waktu yang ketat, logika bisnis yang padat, kurangnya keahlian teknologi, dan Anda perlu mempercepat waktu Anda untuk memasarkan, maka low-code adalah salah satu cara untuk memenuhi kebutuhan Anda.

Tidak dapat disangkal pentingnya alat pengembangan tradisional, namun dalam banyak kasus, menggunakan solusi kode rendah adalah cara terbaik untuk meningkatkan efisiensi tugas yang diselesaikan.

Sumber: www.habr.com