🥇Paggamit ng mababang code sa analytical platform

Minamahal na mga mambabasa, magandang araw!

Ang gawain ng pagbuo ng mga IT platform para sa pagkolekta at pagsusuri ng data sa maaga o huli ay lumitaw para sa anumang kumpanya na ang negosyo ay batay sa isang modelo ng paghahatid ng serbisyo na na-load na intelektwal o ang paglikha ng mga teknikal na kumplikadong produkto. Ang pagbuo ng mga analytical platform ay isang kumplikado at nakakaubos ng oras na gawain. Gayunpaman, ang anumang gawain ay maaaring gawing simple. Sa artikulong ito, nais kong ibahagi ang aking karanasan sa paggamit ng mga tool na may mababang code upang makatulong sa paggawa ng mga analytical na solusyon. Ang karanasang ito ay nakuha sa panahon ng pagpapatupad ng isang bilang ng mga proyekto sa direksyon ng Big Data Solutions ng kumpanyang Neoflex. Mula noong 2005, ang direksyon ng Big Data Solutions ng Neoflex ay humaharap sa mga isyu ng pagbuo ng mga warehouse at lawa ng data, paglutas ng mga problema sa pag-optimize ng bilis ng pagproseso ng impormasyon at paggawa sa isang pamamaraan para sa pamamahala ng kalidad ng data.

Walang sinuman ang makakaiwas sa sinasadyang akumulasyon ng mahina at/o malakas na pagkakaayos ng data. Marahil kahit na ang pag-uusapan natin ay tungkol sa maliliit na negosyo. Pagkatapos ng lahat, kapag nag-scale ng isang negosyo, ang isang promising entrepreneur ay haharap sa mga isyu ng pagbuo ng isang loyalty program, gugustuhing suriin ang pagiging epektibo ng mga punto ng pagbebenta, iisipin ang tungkol sa naka-target na advertising, at malilito sa pangangailangan para sa mga kasamang produkto. . Sa isang unang pagtatantya, ang problema ay maaaring malutas "sa tuhod". Ngunit habang lumalaki ang negosyo, hindi pa rin maiiwasan ang pagdating sa isang analytical platform.

Gayunpaman, sa anong kaso maaaring maging mga problema sa klase ng "Rocket Science" ang mga gawain ng data analytics? Marahil sa sandaling pinag-uusapan natin ang tungkol sa talagang malaking data.
Upang gawing mas madali ang Rocket Science, maaari mong kainin ang elepante sa bawat piraso.

Kung mas discrete at autonomous ang iyong mga application/service/microservices, mas magiging madali para sa iyo, sa iyong mga kasamahan at sa buong negosyo na matunaw ang elepante.

Halos lahat ng aming mga kliyente ay dumating sa postulate na ito, na muling itinayo ang landscape batay sa mga kasanayan sa engineering ng mga koponan ng DevOps.

Ngunit kahit na may "hiwalay, elepante" na diyeta, mayroon kaming magandang pagkakataon na "oversaturation" ng IT landscape. Sa sandaling ito, sulit na huminto, huminga at tumingin sa gilid low-code engineering platform.

Maraming mga developer ang natatakot sa pag-asam ng isang dead end sa kanilang karera kapag lumalayo mula sa direktang pagsulat ng code patungo sa "pag-drag" ng mga arrow sa mga interface ng UI ng mga low-code system. Ngunit ang pagdating ng mga tool sa makina ay hindi humantong sa pagkawala ng mga inhinyero, ngunit dinala ang kanilang trabaho sa isang bagong antas!

Alamin natin kung bakit.

Ang pagsusuri ng data sa larangan ng logistik, industriya ng telecom, pananaliksik sa media, sektor ng pananalapi ay palaging nauugnay sa mga sumusunod na katanungan:

Bilis ng awtomatikong pagsusuri;
Kakayahang magsagawa ng mga eksperimento nang hindi naaapektuhan ang pangunahing daloy ng produksyon ng data;
Pagiging maaasahan ng inihandang data;
Baguhin ang pagsubaybay at bersyon;
Data proveance, Data lineage, CDC;
Mabilis na paghahatid ng mga bagong tampok sa kapaligiran ng produksyon;
At ang kilalang-kilala: ang halaga ng pag-unlad at suporta.

Iyon ay, ang mga inhinyero ay may malaking bilang ng mga gawaing may mataas na antas, na maaaring kumpletuhin nang may sapat na kahusayan lamang sa pamamagitan ng pag-clear sa kanilang kamalayan ng mga gawain sa pag-unlad na mababa ang antas.

Ang mga kinakailangan para sa mga developer upang lumipat sa isang bagong antas ay ang ebolusyon at digitalization ng negosyo. Ang halaga ng developer ay nagbabago din: mayroong isang malaking kakulangan ng mga developer na maaaring isawsaw ang kanilang mga sarili sa mga konsepto ng negosyo na awtomatiko.

Gumuhit tayo ng pagkakatulad sa mababang antas at mataas na antas ng mga programming language. Ang paglipat mula sa mababang antas ng mga wika patungo sa matataas na antas ay isang paglipat mula sa pagsulat ng "mga direktang direktiba sa wika ng hardware" patungo sa "mga direktiba sa wika ng mga tao". Iyon ay, pagdaragdag ng ilang layer ng abstraction. Sa kasong ito, ang paglipat sa mga low-code platform mula sa mataas na antas ng mga programming language ay isang paglipat mula sa "mga direktiba sa wika ng mga tao" patungo sa "mga direktiba sa wika ng negosyo". Kung may mga developer na nalulungkot sa katotohanang ito, marahil ay nalungkot sila, mula noong ipinanganak ang Java Script, na gumagamit ng mga function ng pag-uuri ng array. At ang mga function na ito, siyempre, ay may pagpapatupad ng software sa ilalim ng hood sa pamamagitan ng iba pang paraan ng parehong mataas na antas ng programming.

Samakatuwid, ang low-code ay ang hitsura lamang ng isa pang antas ng abstraction.

Inilapat na karanasan gamit ang mababang code

Ang paksa ng mababang code ay medyo malawak, ngunit ngayon nais kong pag-usapan ang praktikal na aplikasyon ng "mga konseptong mababa ang code" gamit ang halimbawa ng isa sa aming mga proyekto.

Ang Big Data Solutions division ng Neoflex ay mas dalubhasa sa sektor ng pananalapi ng negosyo, pagbuo ng mga data warehouse at lawa at pag-automate ng iba't ibang pag-uulat. Sa angkop na lugar na ito, ang paggamit ng mababang code ay matagal nang naging pamantayan. Sa iba pang mga tool na may mababang code, maaari naming banggitin ang mga tool para sa pag-aayos ng mga proseso ng ETL: Informatica Power Center, IBM Datastage, Pentaho Data Integration. O Oracle Apex, na gumaganap bilang isang kapaligiran para sa mabilis na pag-unlad ng mga interface para sa pag-access at pag-edit ng data. Gayunpaman, ang paggamit ng mga tool sa pag-develop na may mababang code ay hindi palaging nagsasangkot ng pagbuo ng mataas na naka-target na mga application sa isang stack ng komersyal na teknolohiya na may malinaw na pag-asa sa vendor.

Gamit ang mga low-code platform, maaari mo ring ayusin ang orkestrasyon ng mga stream ng data, lumikha ng mga platform ng data science o, halimbawa, mga module para sa pagsuri sa kalidad ng data.

Ang isa sa mga inilapat na halimbawa ng karanasan sa paggamit ng mga tool sa pagpapaunlad ng mababang code ay ang pakikipagtulungan sa pagitan ng Neoflex at Mediascope, isa sa mga pinuno sa merkado ng pananaliksik sa media ng Russia. Ang isa sa mga layunin ng negosyo ng kumpanyang ito ay ang paggawa ng data batay sa kung saan ang mga advertiser, mga platform sa Internet, mga channel sa TV, mga istasyon ng radyo, mga ahensya ng advertising at mga tatak ay gumagawa ng mga desisyon tungkol sa pagbili ng advertising at pagpaplano ng kanilang mga komunikasyon sa marketing.

Ang pananaliksik sa media ay isang teknolohikal na lugar ng negosyo. Pagkilala sa mga pagkakasunud-sunod ng video, pagkolekta ng data mula sa mga device na nagsusuri ng panonood, pagsukat ng aktibidad sa mga mapagkukunan ng web - lahat ng ito ay nagpapahiwatig na ang kumpanya ay may malaking kawani ng IT at napakalaking karanasan sa pagbuo ng mga analytical na solusyon. Ngunit ang exponential na paglago sa dami ng impormasyon, ang bilang at iba't ibang mga pinagmumulan nito ay pinipilit ang industriya ng data ng IT na patuloy na umunlad. Ang pinakasimpleng solusyon sa pag-scale sa gumagana nang Mediascope analytical platform ay maaaring paramihin ang IT staff. Ngunit ang isang mas epektibong solusyon ay ang pabilisin ang proseso ng pag-unlad. Ang isa sa mga hakbang na humahantong sa direksyon na ito ay maaaring ang paggamit ng mga low-code na platform.

Sa oras na nagsimula ang proyekto, ang kumpanya ay mayroon nang gumaganang solusyon sa produkto. Gayunpaman, ang pagpapatupad ng solusyon sa MSSQL ay hindi ganap na matugunan ang mga inaasahan para sa scaling functionality habang pinapanatili ang isang katanggap-tanggap na halaga ng pag-unlad.

Ang gawaing nauna sa amin ay tunay na ambisyoso - ang Neoflex at Mediascope ay kailangang gumawa ng isang pang-industriya na solusyon sa wala pang isang taon, napapailalim sa paglabas ng MVP sa loob ng unang quarter ng petsa ng pagsisimula.

Ang Hadoop technology stack ay pinili bilang pundasyon para sa pagbuo ng isang bagong platform ng data batay sa low-code computing. Ang HDFS ay naging pamantayan para sa pag-iimbak ng data gamit ang mga parquet file. Upang ma-access ang data na matatagpuan sa platform, ginamit ang Hive, kung saan ang lahat ng magagamit na storefront ay ipinakita sa anyo ng mga panlabas na talahanayan. Ang paglo-load ng data sa storage ay ipinatupad gamit ang Kafka at Apache NiFi.

Ang tool na Lowe-code sa konseptong ito ay ginamit upang i-optimize ang pinaka-labor-intensive na gawain sa pagbuo ng isang analytical platform - ang gawain ng pagkalkula ng data.

Ang tool na Datagram na may mababang code ay pinili bilang pangunahing mekanismo para sa pagmamapa ng data. Datagram ng Neoflex ay isang tool para sa pagbuo ng mga pagbabago at daloy ng data.
Gamit ang tool na ito, magagawa mo nang hindi manu-manong sumulat ng Scala code. Ang scala code ay awtomatikong nabuo gamit ang Model Driven Architecture na diskarte.

Ang isang malinaw na bentahe ng diskarteng ito ay ang pagpapabilis ng proseso ng pag-unlad. Gayunpaman, bilang karagdagan sa bilis, mayroon ding mga sumusunod na pakinabang:

Pagtingin sa nilalaman at istraktura ng mga mapagkukunan/tatanggap;
Pagsubaybay sa pinagmulan ng mga bagay sa daloy ng data sa mga indibidwal na field (lineage);
Bahagyang pagsasagawa ng mga pagbabago sa pagtingin sa mga intermediate na resulta;
Pagsusuri sa source code at pagsasaayos nito bago isagawa;
Awtomatikong pagpapatunay ng mga pagbabago;
Awtomatikong pag-download ng data 1 sa 1.

Ang hadlang sa pagpasok sa mga solusyon na mababa ang code para sa pagbuo ng mga pagbabago ay medyo mababa: kailangang malaman ng developer ang SQL at magkaroon ng karanasan sa pagtatrabaho sa mga tool ng ETL. Ito ay nagkakahalaga ng pagbanggit na ang code-driven transformation generators ay hindi ETL tool sa malawak na kahulugan ng salita. Maaaring walang sariling kapaligiran sa pagpapatupad ng code ang mga tool na may mababang code. Iyon ay, ang nabuong code ay isasagawa sa kapaligiran na umiral sa cluster bago pa man i-install ang low-code solution. At ito ay marahil isa pang plus para sa mababang code na karma. Dahil, kasabay ng isang low-code team, ang isang "classic" na team ay maaaring gumana na nagpapatupad ng functionality, halimbawa, sa purong Scala code. Ang pagdadala ng mga pagpapabuti mula sa parehong mga koponan sa produksyon ay magiging simple at walang putol.

Marahil ay nararapat na tandaan na bilang karagdagan sa mababang code, mayroon ding mga solusyon na walang code. At sa kanilang kaibuturan, ito ay iba't ibang bagay. Ang low-code ay nagbibigay-daan sa developer na mas makagambala sa nabuong code. Sa kaso ng Datagram, posibleng tingnan at i-edit ang nabuong Scala code; maaaring hindi magbigay ng ganoong pagkakataon ang walang code. Napakahalaga ng pagkakaibang ito hindi lamang sa mga tuntunin ng kakayahang umangkop ng solusyon, kundi pati na rin sa mga tuntunin ng kaginhawahan at pagganyak sa gawain ng mga inhinyero ng data.

Arkitektura ng solusyon

Subukan nating alamin nang eksakto kung paano nakakatulong ang isang tool na may mababang code na malutas ang problema sa pag-optimize ng bilis ng pagbuo ng functionality ng pagkalkula ng data. Una, tingnan natin ang functional architecture ng system. Ang isang halimbawa sa kasong ito ay ang data production model para sa media research.

Ang mga mapagkukunan ng data sa aming kaso ay napaka-magkakaiba at magkakaibang:

Ang mga metro ng tao (TV meter) ay software at hardware na mga device na nagbabasa ng gawi ng user mula sa mga respondent sa panel ng telebisyon - sino, kailan at anong channel sa TV ang napanood sa sambahayan na kalahok sa pag-aaral. Ang ibinigay na impormasyon ay isang stream ng mga pagitan ng panonood ng broadcast na naka-link sa pakete ng media at produkto ng media. Ang data sa yugto ng paglo-load sa Data Lake ay maaaring pagyamanin ng mga demograpikong katangian, geostratification, time zone at iba pang impormasyong kinakailangan para sa pagsusuri sa panonood sa telebisyon ng isang partikular na produkto ng media. Ang mga sukat na ginawa ay maaaring gamitin upang pag-aralan o planuhin ang mga kampanya sa advertising, tasahin ang aktibidad at kagustuhan ng madla, at i-compile ang broadcast network;
Ang data ay maaaring magmula sa mga sistema ng pagsubaybay para sa pag-stream ng mga broadcast sa telebisyon at pagsukat sa panonood ng nilalaman ng mapagkukunan ng video sa Internet;
Mga tool sa pagsukat sa kapaligiran ng web, kabilang ang parehong site-centric at user-centric na metro. Ang data provider para sa Data Lake ay maaaring isang research bar browser add-on at isang mobile application na may built-in na VPN.
Ang data ay maaari ding magmula sa mga site na pinagsasama-sama ang mga resulta ng pagsagot sa mga online na questionnaire at ang mga resulta ng mga panayam sa telepono sa mga survey ng kumpanya;
Maaaring mangyari ang karagdagang pagpapayaman ng data lake sa pamamagitan ng pag-download ng impormasyon mula sa mga log ng mga kasosyong kumpanya.

Ang pagpapatupad ng as is loading mula sa source system papunta sa pangunahing staging ng raw data ay maaaring isaayos sa iba't ibang paraan. Kung ginagamit ang mababang code para sa mga layuning ito, posible ang awtomatikong pagbuo ng mga script sa paglo-load batay sa metadata. Sa kasong ito, hindi na kailangang bumaba sa antas ng pagbuo ng pinagmulan upang i-target ang mga pagmamapa. Upang ipatupad ang awtomatikong paglo-load, kailangan nating magtatag ng isang koneksyon sa pinagmulan, at pagkatapos ay tukuyin sa interface ng paglo-load ang listahan ng mga entity na ilo-load. Ang istraktura ng direktoryo sa HDFS ay awtomatikong malilikha at tumutugma sa istraktura ng imbakan ng data sa source system.

Gayunpaman, sa konteksto ng proyektong ito, nagpasya kaming huwag gamitin ang feature na ito ng low-code platform dahil sa katotohanan na ang kumpanya ng Mediascope ay nakapag-iisa nang nagsimulang magtrabaho sa paggawa ng katulad na serbisyo gamit ang kumbinasyon ng Nifi + Kafka.

Ito ay nagkakahalaga kaagad na ipahiwatig na ang mga tool na ito ay hindi mapagpapalit, ngunit sa halip ay komplementary. Nagagawa ng Nifi at Kafka ang parehong direktang (Nifi -> Kafka) at sa reverse (Kafka -> Nifi) na koneksyon. Para sa platform ng pananaliksik sa media, ginamit ang unang bersyon ng bundle.

Sa aming kaso, kailangan ng NayFi na iproseso ang iba't ibang uri ng data mula sa mga source system at ipadala ang mga ito sa Kafka broker. Sa kasong ito, ipinadala ang mga mensahe sa isang partikular na paksa ng Kafka gamit ang mga processor ng PublishKafka Nifi. Ang orkestrasyon at pagpapanatili ng mga pipeline na ito ay isinasagawa sa isang visual na interface. Ang tool na Nifi at ang paggamit ng kumbinasyon ng Nifi + Kafka ay maaari ding tawaging isang low-code na diskarte sa pag-unlad, na may mababang hadlang sa pagpasok sa mga teknolohiya ng Big Data at pinapabilis ang proseso ng pagbuo ng application.

Ang susunod na yugto sa pagpapatupad ng proyekto ay upang magdala ng detalyadong data sa isang solong semantic layer na format. Kung ang isang entity ay may mga makasaysayang katangian, ang pagkalkula ay isinasagawa sa konteksto ng partisyon na pinag-uusapan. Kung ang entity ay hindi historikal, kung gayon, opsyonal na posible na muling kalkulahin ang buong nilalaman ng bagay, o ganap na tumanggi na muling kalkulahin ang bagay na ito (dahil sa kakulangan ng mga pagbabago). Sa yugtong ito, nabuo ang mga susi para sa lahat ng entity. Ang mga susi ay naka-imbak sa mga direktoryo ng Hbase na naaayon sa mga master object, na naglalaman ng isang sulat sa pagitan ng mga key sa analytical platform at ng mga key mula sa mga source system. Ang pagsasama-sama ng mga atomic na entity ay sinamahan ng pagpapayaman sa mga resulta ng paunang pagkalkula ng analytical data. Ang balangkas para sa pagkalkula ng data ay Spark. Ang inilarawang functionality para sa pagdadala ng data sa iisang semantics ay ipinatupad din batay sa mga pagmamapa mula sa low-code Datagram tool.

Ang target na arkitektura ay nangangailangan ng SQL access sa data para sa mga user ng negosyo. Ginamit ang hive para sa opsyong ito. Awtomatikong nakarehistro ang mga bagay sa Hive kapag pinagana mo ang opsyong "Registr Hive Table" sa tool na may mababang code.

Kontrol ng daloy ng pagkalkula

Ang Datagram ay may interface para sa paglikha ng mga disenyo ng daloy ng trabaho. Maaaring ilunsad ang mga pagmamapa gamit ang Oozie scheduler. Sa interface ng developer ng stream, posibleng gumawa ng mga scheme para sa parallel, sequential, o execution-dependent na mga pagbabagong-anyo ng data. Mayroong suporta para sa mga script ng shell at java program. Posible ring gamitin ang Apache Livy server. Ang Apache Livy ay ginagamit upang magpatakbo ng mga application nang direkta mula sa kapaligiran ng pag-unlad.

Kung ang kumpanya ay mayroon nang sariling proseso ng orkestra, posibleng gamitin ang REST API upang i-embed ang mga pagmamapa sa isang kasalukuyang daloy. Halimbawa, nagkaroon kami ng medyo matagumpay na karanasan sa pag-embed ng mga pagmamapa sa Scala sa mga orkestra na nakasulat sa PLSQL at Kotlin. Ang REST API ng isang tool na may mababang code ay kinabibilangan ng mga operasyon tulad ng pagbuo ng isang executable na taon batay sa disenyo ng pagmamapa, pagtawag sa isang pagmamapa, pagtawag ng pagkakasunod-sunod ng mga pagmamapa, at, siyempre, pagpasa ng mga parameter sa URL para magpatakbo ng mga pagmamapa.

Kasama ni Oozie, posibleng mag-ayos ng daloy ng pagkalkula gamit ang Airflow. Marahil ay hindi na ako magtatagal sa paghahambing sa pagitan ng Oozie at Airflow, ngunit sasabihin lamang na sa konteksto ng trabaho sa isang proyekto ng pananaliksik sa media, ang pagpili ay pumabor sa Airflow. Ang mga pangunahing argumento sa pagkakataong ito ay isang mas aktibong komunidad na bumubuo ng produkto at isang mas binuo na interface + API.

Maganda rin ang airflow dahil ginagamit nito ang minamahal na Python para ilarawan ang mga proseso ng pagkalkula. At sa pangkalahatan, walang napakaraming open source na mga platform ng pamamahala ng daloy ng trabaho. Ang paglulunsad at pagsubaybay sa pagsasagawa ng mga proseso (kabilang ang isang Gantt chart) ay nagdaragdag lamang ng mga puntos sa karma ng Airflow.

Ang format ng configuration file para sa paglulunsad ng mga low-code solution mappings ay naging spark-submit. Nangyari ito sa dalawang dahilan. Una, pinapayagan ka ng spark-submit na direktang magpatakbo ng jar file mula sa console. Pangalawa, maaari itong maglaman ng lahat ng kinakailangang impormasyon upang i-configure ang daloy ng trabaho (na nagpapadali sa pagsulat ng mga script na bumubuo ng Dag).
Ang pinakakaraniwang elemento ng daloy ng trabaho ng Airflow sa aming kaso ay ang SparkSubmitOperator.

Binibigyang-daan ka ng SparkSubmitOperator na magpatakbo ng mga garapon - naka-package na mga pagmamapa ng Datagram na may mga pre-generated na parameter ng input para sa kanila.

Ito ay nagkakahalaga ng pagbanggit na ang bawat gawain ng Airflow ay tumatakbo sa isang hiwalay na thread at walang alam tungkol sa iba pang mga gawain. Samakatuwid, ang pakikipag-ugnayan sa pagitan ng mga gawain ay isinasagawa gamit ang mga control operator, tulad ng DummyOperator o BranchPythonOperator.

Kung sama-sama, ang paggamit ng Datagram low-code solution kasabay ng universalization ng configuration files (forming Dag) ay humantong sa isang makabuluhang acceleration at simplification ng proseso ng pagbuo ng data loading flows.

Mga kalkulasyon ng showcase

Marahil ang pinaka-intellectually load na yugto sa paggawa ng analytical data ay ang hakbang ng pagbuo ng mga showcase. Sa konteksto ng isa sa mga daloy ng pagkalkula ng data ng kumpanya ng pananaliksik, sa yugtong ito, binabawasan ang data sa isang reference na broadcast, na isinasaalang-alang ang mga pagwawasto para sa mga time zone at naka-link sa grid ng broadcast. Posible ring mag-adjust para sa lokal na broadcast network (lokal na balita at advertising). Sa iba pang mga bagay, pinaghihiwa-hiwalay ng hakbang na ito ang mga pagitan ng tuluy-tuloy na pagtingin sa mga produkto ng media batay sa pagsusuri ng mga agwat ng panonood. Kaagad, ang mga halaga ng pagtingin ay "timbang" batay sa impormasyon tungkol sa kanilang kahalagahan (pagkalkula ng isang kadahilanan ng pagwawasto).

Ang isang hiwalay na hakbang sa paghahanda ng mga showcase ay ang pagpapatunay ng data. Kasama sa validation algorithm ang paggamit ng ilang mathematical science models. Gayunpaman, ang paggamit ng isang low-code platform ay nagbibigay-daan sa iyo na hatiin ang isang kumplikadong algorithm sa isang bilang ng mga hiwalay na visually readable mappings. Ang bawat isa sa mga pagmamapa ay gumaganap ng isang makitid na gawain. Bilang resulta, posible ang intermediate na pag-debug, pag-log at visualization ng mga yugto ng paghahanda ng data.

Napagpasyahan na i-discretize ang validation algorithm sa mga sumusunod na substage:

Bumuo ng mga regression ng mga dependency sa panonood ng TV network sa isang rehiyon na may panonood sa lahat ng network sa rehiyon sa loob ng 60 araw.
Pagkalkula ng mga nalalabi sa estudyante (mga paglihis ng aktwal na mga halaga mula sa mga hinulaang modelo ng regression) para sa lahat ng mga punto ng regression at para sa kinakalkula na araw.
Isang seleksyon ng mga maanomalyang pares ng network-rehiyon, kung saan ang balanse ng estudyante sa araw ng pag-aayos ay lumampas sa pamantayan (tinukoy ng mga setting ng operasyon).
Muling pagkalkula ng naitama na natitirang estudyante para sa maanomalyang mga pares ng network ng rehiyon-TV para sa bawat respondent na nanood ng network sa rehiyon, na tinutukoy ang kontribusyon ng respondent na ito (ang halaga ng pagbabago sa nalalabi na pinag-aaralan) kapag hindi kasama ang pagtingin sa respondent na ito mula sa sample .
Maghanap ng mga kandidato na ang pagbubukod ay nagbabalik sa balanse ng estudyante sa araw ng suweldo sa normal.

Ang halimbawa sa itaas ay nagpapatunay sa hypothesis na ang isang data engineer ay mayroon nang labis na iniisip... At, kung ito ay talagang isang "engineer" at hindi isang "coder," kung gayon ang takot sa propesyonal na pagkasira kapag gumagamit ng mga tool na mababa ang code. dapat sa wakas ay umatras.

Ano pa ang magagawa ng mababang code?

Ang saklaw ng aplikasyon ng isang tool na may mababang code para sa pagproseso ng batch at stream ng data nang hindi kinakailangang manu-manong magsulat ng code sa Scala ay hindi nagtatapos doon.

Ang paggamit ng low-code sa pagbuo ng datalake ay naging pamantayan na para sa amin. Malamang na masasabi natin na ang mga solusyon batay sa Hadoop stack ay sumusunod sa landas ng pag-unlad ng mga klasikong DWH batay sa RDBMS. Ang mga tool na may mababang code sa Hadoop stack ay maaaring malutas ang parehong mga gawain sa pagproseso ng data at ang gawain ng pagbuo ng mga panghuling interface ng BI. Bukod dito, dapat tandaan na ang BI ay maaaring mangahulugan hindi lamang ang representasyon ng data, kundi pati na rin ang kanilang pag-edit ng mga gumagamit ng negosyo. Madalas naming ginagamit ang functionality na ito kapag gumagawa ng mga analytical na platform para sa sektor ng pananalapi.

Sa iba pang mga bagay, gamit ang mababang-code at, sa partikular, ang Datagram, posible na malutas ang problema ng pagsubaybay sa pinagmulan ng mga object ng stream ng data na may atomicity hanggang sa mga indibidwal na field (lineage). Upang gawin ito, ang tool na may mababang code ay nagpapatupad ng interface sa Apache Atlas at Cloudera Navigator. Mahalaga, ang developer ay kailangang magrehistro ng isang hanay ng mga bagay sa mga diksyunaryo ng Atlas at sumangguni sa mga nakarehistrong bagay kapag gumagawa ng mga pagmamapa. Ang mekanismo para sa pagsubaybay sa pinagmulan ng data o pagsusuri sa mga dependency ng object ay nakakatipid ng maraming oras kapag kinakailangan na gumawa ng mga pagpapabuti sa mga algorithm ng pagkalkula. Halimbawa, kapag naghahanda ng mga pahayag sa pananalapi, ang tampok na ito ay nagbibigay-daan sa iyo upang mas kumportable na makaligtas sa panahon ng mga pagbabago sa pambatasan. Pagkatapos ng lahat, mas mahusay na nauunawaan natin ang inter-form na dependence sa konteksto ng mga bagay ng isang detalyadong layer, mas mababa ang makakatagpo natin ng "biglaang" mga depekto at bawasan ang bilang ng mga rework.

Kalidad ng Data at Mababang-code

Ang isa pang gawain na ipinatupad ng tool na may mababang code sa proyekto ng Mediascope ay ang gawain sa klase ng Data Quality. Ang isang espesyal na tampok ng pagpapatupad ng pipeline ng pag-verify ng data para sa proyekto ng kumpanya ng pananaliksik ay ang kakulangan ng epekto sa pagganap at bilis ng pangunahing daloy ng pagkalkula ng data. Upang makapag-orchestrate ng mga independiyenteng daloy ng pag-verify ng data, ginamit ang pamilyar na Apache Airflow. Habang ang bawat hakbang ng paggawa ng data ay handa na, ang isang hiwalay na bahagi ng pipeline ng DQ ay inilunsad nang magkatulad.

Itinuturing na mabuting kasanayan ang pagsubaybay sa kalidad ng data mula sa sandali ng pagsisimula nito sa analytical platform. Sa pagkakaroon ng impormasyon tungkol sa metadata, maaari naming suriin ang pagsunod sa mga pangunahing kondisyon mula sa sandaling ang impormasyon ay pumasok sa pangunahing layer - hindi null, mga hadlang, mga dayuhang key. Ipinapatupad ang functionality na ito batay sa mga awtomatikong nabuong mapping ng pamilya ng kalidad ng data sa Datagram. Ang pagbuo ng code sa kasong ito ay batay din sa metadata ng modelo. Sa proyekto ng Mediascope, isinagawa ang interface kasama ang metadata ng produkto ng Enterprise Architect.

Sa pamamagitan ng pagpapares ng low-code tool sa Enterprise Architect, awtomatikong nabuo ang mga sumusunod na pagsusuri:

Sinusuri ang pagkakaroon ng "null" na mga halaga sa mga patlang na may "hindi null" modifier;
Sinusuri ang pagkakaroon ng mga duplicate ng pangunahing key;
Sinusuri ang foreign key ng isang entity;
Sinusuri ang pagiging natatangi ng isang string batay sa isang hanay ng mga patlang.

Para sa mas kumplikadong mga pagsusuri sa availability at pagiging maaasahan ng data, isang pagmamapa ang ginawa gamit ang Scala Expression, na kumukuha bilang input ng external na Spark SQL check code na inihanda ng mga analyst sa Zeppelin.

Siyempre, ang awtomatikong pagbuo ng mga tseke ay dapat na makamit nang paunti-unti. Sa loob ng balangkas ng inilarawang proyekto, naunahan ito ng mga sumusunod na hakbang:

Ipinatupad ang DQ sa mga Zeppelin notebook;
DQ na binuo sa pagmamapa;
DQ sa anyo ng magkahiwalay na malalaking pagmamapa na naglalaman ng isang buong hanay ng mga pagsusuri para sa isang hiwalay na entity;
Mga pangkalahatang parameterized na DQ mapping na tumatanggap ng impormasyon tungkol sa metadata at mga pagsusuri sa negosyo bilang input.

Marahil ang pangunahing bentahe ng paglikha ng isang parameterized check service ay ang pagbawas sa oras na kinakailangan upang maihatid ang functionality sa kapaligiran ng produksyon. Maaaring lampasan ng mga bagong pagsusuri sa kalidad ang klasikong pattern ng paghahatid ng code nang hindi direkta sa pamamagitan ng mga kapaligiran sa pag-develop at pagsubok:

Lahat ng mga pagsusuri sa metadata ay awtomatikong nabubuo kapag ang modelo ay binago sa EA;
Ang mga pagsusuri sa availability ng data (pagtukoy sa pagkakaroon ng anumang data sa isang punto sa oras) ay maaaring mabuo batay sa isang direktoryo na nag-iimbak ng inaasahang timing ng paglitaw ng susunod na piraso ng data sa konteksto ng mga bagay;
Ang mga pagsusuri sa validation ng data ng negosyo ay ginawa ng mga analyst sa Zeppelin notebook. Mula doon sila ay direktang ipinadala sa DQ module setup tables sa production environment.

Walang mga panganib ng direktang pagpapadala ng mga script sa produksyon. Kahit na may error sa syntax, ang pinakamataas na nagbabanta sa amin ay ang pagkabigo na magsagawa ng isang pagsusuri, dahil ang daloy ng pagkalkula ng data at ang daloy ng paglulunsad ng pagsusuri sa kalidad ay hiwalay sa isa't isa.

Sa esensya, ang serbisyo ng DQ ay permanenteng tumatakbo sa kapaligiran ng produksyon at handang simulan ang trabaho nito sa sandaling lumitaw ang susunod na piraso ng data.

Sa halip ng isang konklusyon

Ang bentahe ng paggamit ng mababang code ay halata. Hindi kailangang i-develop ng mga developer ang application mula sa simula. At ang isang programmer na napalaya mula sa karagdagang mga gawain ay gumagawa ng mga resulta nang mas mabilis. Ang bilis naman, ay nagbibigay ng karagdagang oras para sa paglutas ng mga isyu sa pag-optimize. Samakatuwid, sa kasong ito, maaari kang umasa sa isang mas mahusay at mas mabilis na solusyon.

Siyempre, ang low-code ay hindi isang panlunas sa lahat, at ang magic ay hindi mangyayari sa sarili nitong:

Ang industriya na may mababang code ay dumadaan sa yugto ng "pagpapalakas", at wala pang magkakatulad na pamantayang pang-industriya;
Maraming mga solusyon na mababa ang code ay hindi libre, at ang pagbili ng mga ito ay dapat na isang malay na hakbang, na dapat gawin nang buong kumpiyansa sa mga pinansiyal na benepisyo ng paggamit ng mga ito;
Maraming mga low-code na solusyon ang hindi palaging gumagana nang maayos sa GIT/SVN. O hindi sila maginhawang gamitin kung nakatago ang nabuong code;
Kapag pinalawak ang arkitektura, maaaring kailanganin na pinuhin ang mababang-code na solusyon - na, sa turn, ay naghihikayat sa epekto ng "attachment at pag-asa" sa tagapagtustos ng solusyon na mababa ang code.
Posible ang isang sapat na antas ng seguridad, ngunit ito ay napakahirap sa paggawa at mahirap ipatupad sa mga low-code system engine. Ang mga low-code na platform ay dapat piliin hindi lamang sa prinsipyo ng paghahanap ng mga benepisyo mula sa kanilang paggamit. Kapag pumipili, ito ay nagkakahalaga ng pagtatanong tungkol sa availability ng functionality para sa access control at delegasyon/pagtaas ng data ng pagkakakilanlan sa antas ng buong IT landscape ng organisasyon.

Gayunpaman, kung ang lahat ng mga pagkukulang ng napiling sistema ay alam mo, at ang mga benepisyo mula sa paggamit nito, gayunpaman, ay nasa dominanteng mayorya, pagkatapos ay lumipat sa maliit na code nang walang takot. Bukod dito, ang paglipat dito ay hindi maiiwasan - tulad ng anumang ebolusyon ay hindi maiiwasan.

Kung ang isang developer sa isang low-code platform ay gumagawa ng kanyang trabaho nang mas mabilis kaysa sa dalawang developer na walang low-code, kung gayon ito ay nagbibigay sa kumpanya ng isang head start sa lahat ng aspeto. Ang threshold para sa pagpasok sa mga low-code na solusyon ay mas mababa kaysa sa "tradisyonal" na mga teknolohiya, at ito ay may positibong epekto sa isyu ng mga kakulangan ng tauhan. Kapag gumagamit ng mga tool na mababa ang code, posibleng mapabilis ang pakikipag-ugnayan sa pagitan ng mga functional na team at gumawa ng mas mabilis na mga desisyon tungkol sa kawastuhan ng napiling landas ng pananaliksik sa agham ng data. Ang mga low-level na platform ay maaaring magmaneho ng digital transformation ng isang organisasyon dahil ang mga solusyong ginawa ay mauunawaan ng mga hindi teknikal na espesyalista (lalo na sa mga user ng negosyo).

Kung mayroon kang masikip na mga deadline, puno ng lohika ng negosyo, kakulangan ng teknolohikal na kadalubhasaan, at kailangan mong pabilisin ang iyong oras sa pagbebenta, kung gayon ang low-code ay isang paraan upang matugunan ang iyong mga pangangailangan.

Hindi maikakaila ang kahalagahan ng mga tradisyunal na tool sa pag-unlad, ngunit sa maraming mga kaso, ang paggamit ng mga solusyon na mababa ang code ay ang pinakamahusay na paraan upang mapataas ang kahusayan ng mga gawaing nilulutas.

Pinagmulan: www.habr.com

Application ng low-code sa analytical platform