Penggunaan kod rendah dalam platform analisis

Pembaca yang dihormati, selamat hari!

Tugas membina platform IT untuk mengumpul dan menganalisis data lambat laun timbul untuk mana-mana syarikat yang perniagaannya berdasarkan model penyampaian perkhidmatan yang dimuatkan secara intelektual atau penciptaan produk yang kompleks dari segi teknikal. Membina platform analisis adalah tugas yang kompleks dan memakan masa. Walau bagaimanapun, sebarang tugas boleh dipermudahkan. Dalam artikel ini saya ingin berkongsi pengalaman saya menggunakan alat kod rendah untuk membantu mencipta penyelesaian analisis. Pengalaman ini diperoleh semasa pelaksanaan beberapa projek dalam hala tuju Penyelesaian Data Besar syarikat Neoflex. Sejak 2005, arahan Penyelesaian Data Besar Neoflex telah menangani isu membina gudang data dan tasik, menyelesaikan masalah mengoptimumkan kelajuan pemprosesan maklumat dan mengusahakan metodologi untuk pengurusan kualiti data.

Tiada siapa yang akan dapat mengelakkan pengumpulan sedar data yang lemah dan/atau berstruktur kuat. Mungkin walaupun kita bercakap tentang perniagaan kecil. Lagipun, apabila mengembangkan perniagaan, seorang usahawan yang menjanjikan akan berhadapan dengan isu membangunkan program kesetiaan, ingin menganalisis keberkesanan mata jualan, akan memikirkan tentang pengiklanan yang disasarkan, dan akan bingung dengan permintaan untuk produk yang disertakan. . Untuk anggaran pertama, masalah itu boleh diselesaikan "di lutut". Tetapi apabila perniagaan berkembang, datang ke platform analisis masih tidak dapat dielakkan.

Walau bagaimanapun, dalam kes apakah tugas analisis data boleh berkembang menjadi masalah kelas "Sains Roket"? Mungkin pada masa ini apabila kita bercakap tentang data yang sangat besar.
Untuk memudahkan Sains Roket, anda boleh makan gajah seketul demi sekeping.

Lebih diskret dan autonomi aplikasi/perkhidmatan/perkhidmatan mikro anda, lebih mudah bagi anda, rakan sekerja anda dan seluruh perniagaan untuk mencerna gajah.

Hampir semua pelanggan kami menerima postulat ini, setelah membina semula landskap berdasarkan amalan kejuruteraan pasukan DevOps.

Tetapi walaupun dengan diet "berasingan, gajah", kita mempunyai peluang yang baik untuk "terlalu tepu" landskap IT. Pada masa ini ia patut berhenti, menghembus nafas dan melihat ke tepi platform kejuruteraan kod rendah.

Ramai pembangun takut dengan prospek jalan buntu dalam kerjaya mereka apabila beralih daripada menulis kod terus ke arah "menyeret" anak panah dalam antara muka UI sistem kod rendah. Tetapi kemunculan alat mesin tidak membawa kepada kehilangan jurutera, tetapi membawa kerja mereka ke tahap yang baru!

Mari kita fikirkan mengapa.

Analisis data dalam bidang logistik, industri telekomunikasi, penyelidikan media, sektor kewangan sentiasa dikaitkan dengan soalan berikut:

• Kelajuan analisis automatik;
• Keupayaan untuk menjalankan eksperimen tanpa menjejaskan aliran pengeluaran data utama;
• Kebolehpercayaan data yang disediakan;
• Tukar penjejakan dan versi;
• Bukti data, keturunan data, CDC;
• Penghantaran pantas ciri baharu kepada persekitaran pengeluaran;
• Dan yang terkenal: kos pembangunan dan sokongan.

Iaitu, jurutera mempunyai sejumlah besar tugas peringkat tinggi, yang boleh diselesaikan dengan kecekapan yang mencukupi hanya dengan membersihkan kesedaran mereka tentang tugas pembangunan peringkat rendah.

Prasyarat untuk pembangun bergerak ke tahap baharu ialah evolusi dan pendigitalan perniagaan. Nilai pembangun juga berubah: terdapat kekurangan ketara pembangun yang boleh melibatkan diri dalam konsep perniagaan yang diautomasikan.

Mari kita lukiskan analogi dengan bahasa pengaturcaraan peringkat rendah dan peringkat tinggi. Peralihan daripada bahasa peringkat rendah ke bahasa peringkat tinggi adalah peralihan daripada menulis "arahan langsung dalam bahasa perkakasan" kepada "arahan dalam bahasa orang". Iaitu, menambah beberapa lapisan abstraksi. Dalam kes ini, peralihan kepada platform kod rendah daripada bahasa pengaturcaraan peringkat tinggi ialah peralihan daripada "arahan dalam bahasa orang" kepada "arahan dalam bahasa perniagaan." Sekiranya terdapat pembangun yang sedih dengan fakta ini, maka mereka telah sedih, mungkin, sejak saat Java Script dilahirkan, yang menggunakan fungsi pengisihan tatasusunan. Dan fungsi ini, sudah tentu, mempunyai pelaksanaan perisian di bawah hud dengan cara lain pengaturcaraan peringkat tinggi yang sama.

Oleh itu, kod rendah hanyalah penampilan tahap abstraksi yang lain.

Pengalaman yang digunakan menggunakan kod rendah

Topik kod rendah agak luas, tetapi sekarang saya ingin bercakap tentang aplikasi praktikal "konsep kod rendah" menggunakan contoh salah satu projek kami.

Bahagian Penyelesaian Data Besar Neoflex lebih mengkhusus dalam sektor kewangan perniagaan, membina gudang data dan tasik serta mengautomasikan pelbagai pelaporan. Dalam niche ini, penggunaan kod rendah telah lama menjadi standard. Antara alatan kod rendah yang lain, kita boleh menyebut alatan untuk mengatur proses ETL: Pusat Kuasa Informatica, IBM Datastage, Pentaho Data Integration. Atau Oracle Apex, yang bertindak sebagai persekitaran untuk pembangunan pesat antara muka untuk mengakses dan mengedit data. Walau bagaimanapun, penggunaan alat pembangunan kod rendah tidak selalu melibatkan membina aplikasi yang sangat disasarkan pada timbunan teknologi komersial dengan pergantungan yang jelas pada vendor.

Menggunakan platform kod rendah, anda juga boleh mengatur orkestrasi aliran data, mencipta platform sains data atau, sebagai contoh, modul untuk menyemak kualiti data.

Salah satu contoh pengalaman yang digunakan dalam menggunakan alat pembangunan kod rendah ialah kerjasama antara Neoflex dan Mediascope, salah satu peneraju dalam pasaran penyelidikan media Rusia. Salah satu objektif perniagaan syarikat ini ialah penghasilan data berdasarkan pengiklan, platform Internet, saluran TV, stesen radio, agensi pengiklanan dan jenama membuat keputusan mengenai pembelian pengiklanan dan merancang komunikasi pemasaran mereka.

Penyelidikan media ialah bidang perniagaan yang dimuatkan secara teknologi. Mengiktiraf jujukan video, mengumpul data daripada peranti yang menganalisis tontonan, mengukur aktiviti pada sumber web - semua ini membayangkan bahawa syarikat itu mempunyai kakitangan IT yang besar dan pengalaman yang besar dalam membina penyelesaian analisis. Tetapi pertumbuhan eksponen dalam jumlah maklumat, bilangan dan kepelbagaian sumbernya memaksa industri data IT untuk sentiasa maju. Penyelesaian paling mudah untuk menskalakan platform analisis Mediascope yang sudah berfungsi adalah dengan menambah kakitangan IT. Tetapi penyelesaian yang lebih berkesan ialah mempercepatkan proses pembangunan. Salah satu langkah menuju ke arah ini mungkin adalah penggunaan platform kod rendah.

Pada masa projek dimulakan, syarikat sudah mempunyai penyelesaian produk yang berfungsi. Walau bagaimanapun, pelaksanaan penyelesaian dalam MSSQL tidak dapat memenuhi sepenuhnya jangkaan untuk fungsi penskalaan sambil mengekalkan kos pembangunan yang boleh diterima.

Tugas di hadapan kami benar-benar bercita-cita tinggi - Neoflex dan Mediascope terpaksa mencipta penyelesaian perindustrian dalam masa kurang daripada setahun, tertakluk kepada keluaran MVP dalam suku pertama tarikh mula.

Tindanan teknologi Hadoop dipilih sebagai asas untuk membina platform data baharu berdasarkan pengkomputeran kod rendah. HDFS telah menjadi standard untuk penyimpanan data menggunakan fail parket. Untuk mengakses data yang terletak dalam platform, Hive telah digunakan, di mana semua etalase yang tersedia dipersembahkan dalam bentuk jadual luaran. Memuatkan data ke dalam storan telah dilaksanakan menggunakan Kafka dan Apache NiFi.

Alat Lowe-code dalam konsep ini digunakan untuk mengoptimumkan tugas yang paling intensif buruh dalam membina platform analisis - tugas pengiraan data.

Alat Datagram kod rendah telah dipilih sebagai mekanisme utama untuk pemetaan data. Datagram Neoflex ialah alat untuk membangunkan transformasi dan aliran data.
Menggunakan alat ini, anda boleh melakukannya tanpa menulis kod Scala secara manual. Kod Scala dijana secara automatik menggunakan pendekatan Seni Bina Dipacu Model.

Kelebihan yang jelas dari pendekatan ini ialah mempercepatkan proses pembangunan. Walau bagaimanapun, sebagai tambahan kepada kelajuan, terdapat juga kelebihan berikut:

• Melihat kandungan dan struktur sumber/penerima;
• Mengesan asal objek aliran data ke medan individu (keturunan);
• Pelaksanaan separa transformasi dengan melihat hasil perantaraan;
• Menyemak kod sumber dan melaraskannya sebelum pelaksanaan;
• Pengesahan automatik transformasi;
• Muat turun data automatik 1 dalam 1.

Halangan untuk masuk ke dalam penyelesaian kod rendah untuk menjana transformasi adalah agak rendah: pembangun perlu mengetahui SQL dan mempunyai pengalaman bekerja dengan alatan ETL. Perlu dinyatakan bahawa penjana transformasi dipacu kod bukanlah alat ETL dalam erti kata yang luas. Alat kod rendah mungkin tidak mempunyai persekitaran pelaksanaan kod mereka sendiri. Iaitu, kod yang dijana akan dilaksanakan dalam persekitaran yang wujud pada kluster walaupun sebelum memasang penyelesaian kod rendah. Dan ini mungkin satu lagi kelebihan untuk karma kod rendah. Memandangkan, selari dengan pasukan kod rendah, pasukan "klasik" boleh bekerja yang melaksanakan fungsi, contohnya, dalam kod Scala tulen. Membawa penambahbaikan daripada kedua-dua pasukan ke dalam pengeluaran akan menjadi mudah dan lancar.

Mungkin perlu diperhatikan bahawa selain kod rendah, terdapat juga penyelesaian tanpa kod. Dan pada teras mereka, ini adalah perkara yang berbeza. Kod rendah membolehkan pembangun mengganggu lebih banyak kod yang dihasilkan. Dalam kes Datagram, adalah mungkin untuk melihat dan mengedit kod Scala yang dijana; tiada kod mungkin tidak memberikan peluang sedemikian. Perbezaan ini sangat ketara bukan sahaja dari segi fleksibiliti penyelesaian, tetapi juga dari segi keselesaan dan motivasi dalam kerja jurutera data.

Seni bina penyelesaian

Mari cuba fikirkan dengan tepat bagaimana alat kod rendah membantu menyelesaikan masalah mengoptimumkan kelajuan membangunkan fungsi pengiraan data. Pertama, mari kita lihat seni bina berfungsi sistem. Contoh dalam kes ini ialah model pengeluaran data untuk penyelidikan media.

Sumber data dalam kes kami adalah sangat heterogen dan pelbagai:

• Meter orang (meter TV) ialah perisian dan peranti perkakasan yang membaca tingkah laku pengguna daripada responden panel televisyen - siapa, bila dan saluran TV yang ditonton dalam isi rumah yang mengambil bahagian dalam kajian. Maklumat yang dibekalkan ialah aliran selang tontonan siaran yang dipautkan kepada pakej media dan produk media. Data pada peringkat pemuatan ke dalam Data Lake boleh diperkaya dengan atribut demografi, geostratifikasi, zon waktu dan maklumat lain yang diperlukan untuk menganalisis tontonan televisyen bagi produk media tertentu. Ukuran yang diambil boleh digunakan untuk menganalisis atau merancang kempen pengiklanan, menilai aktiviti dan pilihan penonton, dan menyusun rangkaian penyiaran;
• Data boleh datang daripada sistem pemantauan untuk penstriman siaran televisyen dan mengukur tontonan kandungan sumber video di Internet;
• Alat pengukur dalam persekitaran web, termasuk meter berpusat tapak dan berpusatkan pengguna. Pembekal data untuk Data Lake boleh menjadi alat tambah penyemak imbas bar penyelidikan dan aplikasi mudah alih dengan VPN terbina dalam.
• Data juga boleh datang daripada laman web yang menyatukan hasil pengisian soal selidik dalam talian dan hasil temu bual telefon dalam tinjauan syarikat;
• Pengayaan tambahan bagi tasik data boleh berlaku dengan memuat turun maklumat daripada log syarikat rakan kongsi.

Pelaksanaan as is loading daripada sistem sumber ke dalam pementasan utama data mentah boleh diatur dalam pelbagai cara. Jika kod rendah digunakan untuk tujuan ini, penjanaan automatik skrip memuatkan berdasarkan metadata adalah mungkin. Dalam kes ini, tidak perlu turun ke peringkat pembangunan sumber untuk menyasarkan pemetaan. Untuk melaksanakan pemuatan automatik, kita perlu mewujudkan sambungan kepada sumber, dan kemudian menentukan dalam antara muka pemuatan senarai entiti yang akan dimuatkan. Struktur direktori dalam HDFS akan dibuat secara automatik dan akan sepadan dengan struktur storan data pada sistem sumber.

Walau bagaimanapun, dalam konteks projek ini, kami memutuskan untuk tidak menggunakan ciri platform kod rendah ini kerana syarikat Mediascope telah pun mula bekerja secara bebas untuk menghasilkan perkhidmatan serupa menggunakan gabungan Nifi + Kafka.

Perlu segera menunjukkan bahawa alat ini tidak boleh ditukar ganti, sebaliknya saling melengkapi. Nifi dan Kafka dapat berfungsi secara langsung (Nifi -> Kafka) dan secara terbalik (Kafka -> Nifi). Untuk platform penyelidikan media, versi pertama himpunan telah digunakan.

Dalam kes kami, NayFi perlu memproses pelbagai jenis data daripada sistem sumber dan menghantarnya kepada broker Kafka. Dalam kes ini, mesej dihantar ke topik Kafka tertentu menggunakan pemproses PublishKafka Nifi. Orkestrasi dan penyelenggaraan saluran paip ini dijalankan dalam antara muka visual. Alat Nifi dan penggunaan gabungan Nifi + Kafka juga boleh dipanggil pendekatan kod rendah untuk pembangunan, yang mempunyai halangan rendah untuk masuk ke dalam teknologi Data Besar dan mempercepatkan proses pembangunan aplikasi.

Peringkat seterusnya dalam pelaksanaan projek adalah untuk membawa data terperinci kepada format lapisan semantik tunggal. Jika entiti mempunyai atribut sejarah, pengiraan dilakukan dalam konteks partition yang dipersoalkan. Jika entiti itu bukan sejarah, maka pilihan boleh sama ada untuk mengira semula keseluruhan kandungan objek, atau menolak sepenuhnya untuk mengira semula objek ini (kerana kekurangan perubahan). Pada peringkat ini, kunci dijana untuk semua entiti. Kekunci disimpan dalam direktori Hbase yang sepadan dengan objek induk, yang mengandungi surat-menyurat antara kunci dalam platform analitik dan kunci daripada sistem sumber. Penyatuan entiti atom disertai dengan pengayaan dengan hasil pengiraan awal data analisis. Rangka kerja untuk pengiraan data ialah Spark. Fungsi yang diterangkan untuk membawa data kepada semantik tunggal juga dilaksanakan berdasarkan pemetaan daripada alat Datagram kod rendah.

Seni bina sasaran memerlukan akses SQL kepada data untuk pengguna perniagaan. Hive telah digunakan untuk pilihan ini. Objek didaftarkan dalam Hive secara automatik apabila anda mendayakan pilihan "Registr Hive Table" dalam alat kod rendah.

Kawalan aliran pengiraan

Datagram mempunyai antara muka untuk mencipta reka bentuk aliran kerja. Pemetaan boleh dilancarkan menggunakan penjadual Oozie. Dalam antara muka pembangun strim, adalah mungkin untuk mencipta skema untuk transformasi data selari, berjujukan atau bergantung kepada pelaksanaan. Terdapat sokongan untuk skrip shell dan program java. Ia juga mungkin untuk menggunakan pelayan Apache Livy. Apache Livy digunakan untuk menjalankan aplikasi secara langsung dari persekitaran pembangunan.

Jika syarikat sudah mempunyai pengatur proses sendiri, adalah mungkin untuk menggunakan API REST untuk membenamkan pemetaan ke dalam aliran sedia ada. Sebagai contoh, kami mempunyai pengalaman yang agak berjaya dalam membenamkan pemetaan dalam Scala ke dalam orkestra yang ditulis dalam PLSQL dan Kotlin. API REST bagi alat kod rendah termasuk operasi seperti menjana tahun boleh laku berdasarkan reka bentuk pemetaan, memanggil pemetaan, memanggil jujukan pemetaan dan, sudah tentu, menghantar parameter ke URL untuk menjalankan pemetaan.

Bersama Oozie, adalah mungkin untuk mengatur aliran pengiraan menggunakan Aliran Udara. Mungkin saya tidak akan memikirkan perbandingan antara Oozie dan Aliran Udara, tetapi hanya akan mengatakan bahawa dalam konteks kerja projek penyelidikan media, pilihannya memihak kepada Aliran Udara. Hujah utama kali ini ialah komuniti yang lebih aktif membangunkan produk dan antara muka + API yang lebih maju.

Aliran udara juga bagus kerana ia menggunakan Python yang disayangi untuk menerangkan proses pengiraan. Dan secara umum, tidak begitu banyak platform pengurusan aliran kerja sumber terbuka. Melancarkan dan memantau pelaksanaan proses (termasuk carta Gantt) hanya menambah mata kepada karma Aliran Udara.

Format fail konfigurasi untuk melancarkan pemetaan penyelesaian kod rendah telah menjadi penyerahan percikan. Ini berlaku kerana dua sebab. Pertama, serah percikan membolehkan anda menjalankan fail balang secara langsung dari konsol. Kedua, ia boleh mengandungi semua maklumat yang diperlukan untuk mengkonfigurasi aliran kerja (yang menjadikannya lebih mudah untuk menulis skrip yang menjana Dag).
Elemen aliran kerja Aliran Udara yang paling biasa dalam kes kami ialah SparkSubmitOperator.

SparkSubmitOperator membolehkan anda menjalankan balang - pemetaan Datagram berpakej dengan parameter input pra-jana untuknya.

Perlu dinyatakan bahawa setiap tugas Aliran Udara berjalan dalam urutan yang berasingan dan tidak tahu apa-apa tentang tugas lain. Oleh itu, interaksi antara tugas dijalankan menggunakan pengendali kawalan, seperti DummyOperator atau BranchPythonOperator.

Secara keseluruhannya, penggunaan penyelesaian kod rendah Datagram bersama-sama dengan penyejagatan fail konfigurasi (membentuk Dag) membawa kepada pecutan dan penyederhanaan yang ketara dalam proses membangunkan aliran pemuatan data.

Pengiraan showcase

Mungkin peringkat yang paling dimuatkan secara intelektual dalam penghasilan data analisis ialah langkah membina pameran. Dalam konteks salah satu aliran pengiraan data syarikat penyelidikan, pada peringkat ini, data dikurangkan kepada siaran rujukan, dengan mengambil kira pembetulan untuk zon waktu dan dipautkan ke grid siaran. Ia juga mungkin untuk menyesuaikan untuk rangkaian penyiaran tempatan (berita dan pengiklanan tempatan). Antara lain, langkah ini memecahkan selang tontonan berterusan produk media berdasarkan analisis selang tontonan. Serta-merta, nilai tontonan "ditimbang" berdasarkan maklumat tentang kepentingannya (pengiraan faktor pembetulan).

Langkah berasingan dalam menyediakan pameran ialah pengesahan data. Algoritma pengesahan melibatkan penggunaan beberapa model sains matematik. Walau bagaimanapun, penggunaan platform kod rendah membolehkan anda memecahkan algoritma yang kompleks kepada beberapa pemetaan yang boleh dibaca secara visual yang berasingan. Setiap pemetaan melaksanakan tugas yang sempit. Akibatnya, penyahpepijatan pertengahan, pengelogan dan visualisasi peringkat penyediaan data adalah mungkin.

Ia telah memutuskan untuk mendiskrisikan algoritma pengesahan ke dalam subperingkat berikut:

• Membina regresi kebergantungan tontonan rangkaian TV di rantau dengan tontonan semua rangkaian di rantau ini selama 60 hari.
• Pengiraan sisa pelajar (penyimpangan nilai sebenar daripada yang diramalkan oleh model regresi) untuk semua titik regresi dan untuk hari yang dikira.
• Pilihan pasangan rangkaian rantau anomali, di mana baki pelajar bagi hari penyelesaian melebihi norma (dinyatakan oleh tetapan operasi).
• Pengiraan semula baki pelajar yang diperbetulkan untuk pasangan rangkaian rantau-TV anomali bagi setiap responden yang menonton rangkaian di rantau tersebut, menentukan sumbangan responden ini (jumlah perubahan dalam baki pelajar) apabila mengecualikan tontonan responden ini daripada sampel .
• Cari calon yang pengecualiannya menjadikan baki pelajar bagi hari gaji kembali normal.

Contoh di atas mengesahkan hipotesis bahawa seorang jurutera data sudah mempunyai terlalu banyak perkara di fikirannya... Dan, jika ini benar-benar "jurutera" dan bukan "pengekod," maka ketakutan terhadap kemerosotan profesional apabila menggunakan alat kod rendah dia akhirnya mesti berundur.

Apa lagi yang boleh dilakukan oleh kod rendah?

Skop penggunaan alat kod rendah untuk pemprosesan data kelompok dan strim tanpa perlu menulis kod secara manual dalam Scala tidak berakhir di sana.

Penggunaan kod rendah dalam pembangunan datalake telah menjadi standard bagi kami. Kita mungkin boleh mengatakan bahawa penyelesaian berdasarkan timbunan Hadoop mengikut laluan pembangunan DWH klasik berdasarkan RDBMS. Alat kod rendah pada timbunan Hadoop boleh menyelesaikan kedua-dua tugas pemprosesan data dan tugas membina antara muka BI akhir. Selain itu, perlu diingatkan bahawa BI boleh bermakna bukan sahaja perwakilan data, tetapi juga penyuntingannya oleh pengguna perniagaan. Kami sering menggunakan fungsi ini apabila membina platform analisis untuk sektor kewangan.

Antara lain, menggunakan kod rendah dan, khususnya, Datagram, adalah mungkin untuk menyelesaikan masalah menjejaki asal objek aliran data dengan atomicity hingga ke medan individu (keturunan). Untuk melakukan ini, alat kod rendah melaksanakan antara muka dengan Apache Atlas dan Cloudera Navigator. Pada asasnya, pembangun perlu mendaftarkan satu set objek dalam kamus Atlas dan merujuk objek berdaftar semasa membina pemetaan. Mekanisme untuk menjejaki asal data atau menganalisis kebergantungan objek menjimatkan banyak masa apabila perlu untuk membuat penambahbaikan pada algoritma pengiraan. Sebagai contoh, semasa menyediakan penyata kewangan, ciri ini membolehkan anda bertahan dengan lebih selesa dalam tempoh perubahan perundangan. Lagipun, lebih baik kita memahami pergantungan antara bentuk dalam konteks objek lapisan terperinci, semakin kurang kita akan menghadapi kecacatan "tiba-tiba" dan mengurangkan bilangan kerja semula.

Kualiti Data & Kod Rendah

Tugas lain yang dilaksanakan oleh alat kod rendah pada projek Mediascope ialah tugas kelas Kualiti Data. Keanehan pelaksanaan saluran paip pengesahan data untuk projek syarikat penyelidikan adalah kekurangan kesan ke atas prestasi dan kelajuan aliran pengiraan data utama. Untuk dapat mengatur aliran pengesahan data bebas, Apache Airflow telah digunakan. Memandangkan setiap langkah pengeluaran data telah sedia, bahagian berasingan saluran paip DQ telah dilancarkan secara selari.

Ia dianggap sebagai amalan yang baik untuk memantau kualiti data dari saat ia ditubuhkan dalam platform analisis. Mempunyai maklumat tentang metadata, kami boleh menyemak pematuhan syarat asas dari saat maklumat memasuki lapisan utama - bukan batal, kekangan, kunci asing. Fungsi ini dilaksanakan berdasarkan pemetaan yang dijana secara automatik bagi keluarga kualiti data dalam Datagram. Penjanaan kod dalam kes ini juga berdasarkan metadata model. Pada projek Mediascope, antara muka telah dijalankan dengan metadata produk Enterprise Architect.

Dengan memasangkan alat kod rendah dengan Arkitek Perusahaan, semakan berikut dijana secara automatik:

• Menyemak kehadiran nilai "null" dalam medan dengan pengubah "not null";
• Menyemak kehadiran pendua kunci utama;
• Menyemak kunci asing entiti;
• Menyemak keunikan rentetan berdasarkan set medan.

Untuk semakan ketersediaan dan kebolehpercayaan data yang lebih kompleks, pemetaan telah dibuat dengan Ungkapan Scala, yang mengambil sebagai input kod semakan Spark SQL luaran yang disediakan oleh penganalisis di Zeppelin.

Sudah tentu, penjanaan automatik cek mesti dicapai secara beransur-ansur. Dalam rangka kerja projek yang diterangkan, ini didahului dengan langkah-langkah berikut:

• DQ dilaksanakan dalam buku nota Zeppelin;
• DQ terbina dalam pemetaan;
• DQ dalam bentuk pemetaan besar-besaran berasingan yang mengandungi set keseluruhan semakan untuk entiti berasingan;
• Pemetaan DQ berparameter universal yang menerima maklumat tentang metadata dan semakan perniagaan sebagai input.

Mungkin kelebihan utama mencipta perkhidmatan semakan berparameter ialah pengurangan masa yang diperlukan untuk menyampaikan fungsi kepada persekitaran pengeluaran. Pemeriksaan kualiti baharu boleh memintas corak klasik penghantaran kod secara tidak langsung melalui persekitaran pembangunan dan ujian:

• Semua semakan metadata dijana secara automatik apabila model diubah suai dalam EA;
• Semakan ketersediaan data (menentukan kehadiran sebarang data pada satu masa) boleh dijana berdasarkan direktori yang menyimpan jangkaan masa kemunculan sekeping data seterusnya dalam konteks objek;
• Semakan pengesahan data perniagaan dibuat oleh penganalisis dalam buku nota Zeppelin. Dari sana ia dihantar terus ke jadual persediaan modul DQ dalam persekitaran pengeluaran.

Tiada risiko menghantar skrip terus ke pengeluaran. Walaupun dengan ralat sintaks, maksimum yang mengancam kami ialah kegagalan untuk melakukan satu semakan, kerana aliran pengiraan data dan aliran pelancaran semakan kualiti dipisahkan antara satu sama lain.

Pada dasarnya, perkhidmatan DQ berjalan secara kekal dalam persekitaran pengeluaran dan bersedia untuk memulakan kerjanya sebaik sahaja sekeping data seterusnya muncul.

Daripada kesimpulan

Kelebihan menggunakan kod rendah adalah jelas. Pembangun tidak perlu membangunkan aplikasi dari awal. Dan pengaturcara yang dibebaskan daripada tugas tambahan menghasilkan keputusan dengan lebih cepat. Kelajuan, seterusnya, membebaskan masa tambahan untuk menyelesaikan isu pengoptimuman. Oleh itu, dalam kes ini, anda boleh bergantung pada penyelesaian yang lebih baik dan lebih cepat.

Sudah tentu, kod rendah bukanlah ubat mujarab, dan keajaiban tidak akan berlaku dengan sendirinya:

• Industri kod rendah sedang melalui peringkat "semakin kukuh", dan belum ada piawaian industri yang seragam;
• Banyak penyelesaian kod rendah tidak percuma, dan membelinya harus menjadi langkah sedar, yang harus dibuat dengan penuh keyakinan terhadap faedah kewangan menggunakannya;
• Banyak penyelesaian kod rendah tidak selalu berfungsi dengan baik dengan GIT/SVN. Atau mereka menyusahkan untuk digunakan jika kod yang dihasilkan disembunyikan;
• Apabila mengembangkan seni bina, mungkin perlu untuk memperhalusi penyelesaian kod rendah - yang, seterusnya, menimbulkan kesan "lampiran dan pergantungan" pada pembekal penyelesaian kod rendah.
• Tahap keselamatan yang mencukupi adalah mungkin, tetapi ia sangat intensif buruh dan sukar untuk dilaksanakan dalam enjin sistem kod rendah. Platform kod rendah harus dipilih bukan sahaja berdasarkan prinsip mencari faedah daripada penggunaannya. Apabila memilih, adalah wajar bertanya soalan tentang ketersediaan fungsi untuk kawalan akses dan delegasi/peningkatan data pengenalan ke tahap keseluruhan landskap IT organisasi.

Walau bagaimanapun, jika semua kelemahan sistem yang dipilih diketahui oleh anda, dan faedah daripada penggunaannya, bagaimanapun, berada dalam majoriti yang dominan, kemudian beralih kepada kod kecil tanpa rasa takut. Lebih-lebih lagi, peralihan kepadanya tidak dapat dielakkan - sama seperti mana-mana evolusi tidak dapat dielakkan.

Jika seorang pembangun pada platform kod rendah melakukan tugasnya lebih pantas daripada dua pembangun tanpa kod rendah, maka ini memberi syarikat itu permulaan yang lebih baik dalam semua aspek. Ambang untuk kemasukan ke dalam penyelesaian kod rendah adalah lebih rendah daripada ke dalam teknologi "tradisional", dan ini mempunyai kesan positif terhadap isu kekurangan kakitangan. Apabila menggunakan alat kod rendah, adalah mungkin untuk mempercepatkan interaksi antara pasukan berfungsi dan membuat keputusan yang lebih pantas tentang ketepatan laluan penyelidikan sains data yang dipilih. Platform peringkat rendah boleh memacu transformasi digital sesebuah organisasi kerana penyelesaian yang dihasilkan boleh difahami oleh pakar bukan teknikal (terutamanya pengguna perniagaan).

Jika anda mempunyai tarikh akhir yang ketat, logik perniagaan yang sarat, kekurangan kepakaran teknologi, dan anda perlu mempercepatkan masa anda untuk memasarkan, maka kod rendah ialah satu cara untuk memenuhi keperluan anda.

Tidak dinafikan kepentingan alat pembangunan tradisional, tetapi dalam banyak kes, menggunakan penyelesaian kod rendah adalah cara terbaik untuk meningkatkan kecekapan tugas yang diselesaikan.

Sumber: www.habr.com