Utumiaji wa nambari ya chini katika majukwaa ya uchanganuzi

Wasomaji wapendwa, siku njema!

Jukumu la kujenga majukwaa ya TEHAMA kwa ajili ya kukusanya na kuchambua data mapema au baadaye hutokea kwa kampuni yoyote ambayo biashara yake inategemea mtindo wa utoaji huduma uliojaa kiakili au uundaji wa bidhaa changamano za kiufundi. Kujenga majukwaa ya uchanganuzi ni kazi ngumu na inayotumia wakati. Walakini, kazi yoyote inaweza kurahisishwa. Katika makala hii nataka kushiriki uzoefu wangu katika kutumia zana za nambari za chini kusaidia kuunda suluhisho za uchanganuzi. Uzoefu huu ulipatikana wakati wa utekelezaji wa idadi ya miradi katika mwelekeo wa Big Data Solutions wa kampuni ya Neoflex. Tangu 2005, mwelekeo wa Big Data Solutions wa Neoflex umekuwa ukishughulika na masuala ya kujenga maghala ya data na maziwa, kutatua matatizo ya kuongeza kasi ya usindikaji wa habari na kufanya kazi kwenye mbinu ya usimamizi wa ubora wa data.

Hakuna mtu ataweza kuzuia mkusanyiko wa data dhaifu na/au iliyoundwa kwa nguvu. Labda hata kama tunazungumzia biashara ndogo ndogo. Baada ya yote, wakati wa kuongeza biashara, mjasiriamali anayeahidi atakabiliwa na maswala ya kukuza mpango wa uaminifu, atataka kuchambua ufanisi wa alama za uuzaji, atafikiria juu ya utangazaji uliolengwa, na atashangazwa na mahitaji ya bidhaa zinazoambatana. . Kwa makadirio ya kwanza, tatizo linaweza kutatuliwa "kwa goti". Lakini biashara inapokua, kuja kwenye jukwaa la uchanganuzi bado ni jambo lisiloepukika.

Walakini, ni katika hali gani kazi za uchanganuzi wa data zinaweza kukuza kuwa shida za darasa la "Sayansi ya Roketi"? Labda kwa sasa tunapozungumza juu ya data kubwa sana.
Ili kurahisisha Sayansi ya Roketi, unaweza kula tembo kipande kwa kipande.

Kadiri programu/huduma/huduma/huduma zako zinavyokuwa za kipekee na zenye uhuru zaidi, ndivyo itakavyokuwa rahisi kwako, wafanyakazi wenzako na biashara nzima kusaga tembo.

Takriban wateja wetu wote walikuja kwenye chapisho hili, baada ya kujenga upya mazingira kulingana na mazoea ya uhandisi ya timu za DevOps.

Lakini hata kwa mlo "tofauti, wa tembo", tuna nafasi nzuri ya "kuzidisha" kwa mazingira ya IT. Kwa wakati huu inafaa kuacha, kuvuta pumzi na kutazama upande jukwaa la uhandisi la nambari za chini.

Wasanidi programu wengi wanaogopa na matarajio ya mwisho katika taaluma yao wanapohama kutoka kwa kuandika nambari moja kwa moja kuelekea "kuburuta" mishale katika violesura vya UI vya mifumo ya misimbo ya chini. Lakini ujio wa zana za mashine haukusababisha kutoweka kwa wahandisi, lakini kuletwa kazi yao kwa kiwango kipya!

Hebu tujue ni kwa nini.

Uchambuzi wa data katika uwanja wa vifaa, tasnia ya mawasiliano ya simu, utafiti wa media, sekta ya kifedha kila wakati huhusishwa na maswali yafuatayo:

• Kasi ya uchambuzi wa kiotomatiki;
• Uwezo wa kufanya majaribio bila kuathiri mtiririko mkuu wa uzalishaji wa data;
• Kuegemea kwa data iliyoandaliwa;
• Badilisha ufuatiliaji na toleo;
• Uthibitisho wa data, Ukoo wa data, CDC;
• Utoaji wa haraka wa vipengele vipya kwa mazingira ya uzalishaji;
• Na sifa mbaya: gharama ya maendeleo na msaada.

Hiyo ni, wahandisi wana idadi kubwa ya kazi za kiwango cha juu, ambazo zinaweza kukamilika kwa ufanisi wa kutosha tu kwa kusafisha ufahamu wao wa kazi za kiwango cha chini cha maendeleo.

Masharti ya wasanidi programu kuhamia kiwango kipya yalikuwa mageuzi na ujanibishaji wa biashara. Thamani ya msanidi programu pia inabadilika: kuna uhaba mkubwa wa watengenezaji ambao wanaweza kuzama katika dhana za biashara kuwa otomatiki.

Hebu tuchore mlinganisho na lugha za kiwango cha chini na za juu za programu. Mpito kutoka kwa lugha za kiwango cha chini kuelekea za kiwango cha juu ni mpito kutoka kwa kuandika "maelekezo ya moja kwa moja katika lugha ya vifaa" kuelekea "maelekezo katika lugha ya watu". Hiyo ni, kuongeza safu fulani ya uondoaji. Katika kesi hii, mpito kwa majukwaa ya nambari za chini kutoka kwa lugha za kiwango cha juu cha programu ni mpito kutoka kwa "maelekezo katika lugha ya watu" kuelekea "maelekezo katika lugha ya biashara". Ikiwa kuna watengenezaji ambao wanahuzunishwa na ukweli huu, basi wamehuzunishwa, labda, tangu wakati Java Script ilizaliwa, ambayo hutumia kazi za kupanga safu. Na kazi hizi, bila shaka, zina utekelezaji wa programu chini ya hood kwa njia nyingine za programu sawa za kiwango cha juu.

Kwa hivyo, nambari ya chini ni mwonekano wa kiwango kingine cha uondoaji.

Uzoefu uliotumiwa kwa kutumia nambari ya chini

Mada ya kanuni ya chini ni pana kabisa, lakini sasa ningependa kuzungumza juu ya matumizi ya vitendo ya "dhana za chini" kwa kutumia mfano wa moja ya miradi yetu.

Kitengo cha Big Data Solutions cha Neoflex kinabobea zaidi katika sekta ya fedha ya biashara, kujenga maghala ya data na maziwa na kutoa taarifa otomatiki. Katika niche hii, matumizi ya kanuni ya chini kwa muda mrefu imekuwa kiwango. Miongoni mwa zana zingine za msimbo wa chini, tunaweza kutaja zana za kuandaa michakato ya ETL: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Au Oracle Apex, ambayo hufanya kama mazingira ya ukuzaji wa haraka wa violesura vya kupata na kuhariri data. Hata hivyo, matumizi ya zana za ukuzaji wa misimbo ya chini haihusishi kila wakati kuunda programu zinazolengwa sana kwenye safu ya teknolojia ya kibiashara na utegemezi wazi kwa muuzaji.

Kwa kutumia majukwaa ya msimbo wa chini, unaweza pia kupanga upangaji wa mtiririko wa data, kuunda majukwaa ya sayansi ya data au, kwa mfano, moduli za kuangalia ubora wa data.

Mojawapo ya mifano iliyotumika ya uzoefu katika kutumia zana za ukuzaji wa kanuni za chini ni ushirikiano kati ya Neoflex na Mediascope, mmoja wa viongozi katika soko la utafiti wa vyombo vya habari vya Urusi. Moja ya malengo ya biashara ya kampuni hii ni uzalishaji wa data kwa misingi ambayo watangazaji, majukwaa ya mtandao, chaneli za TV, vituo vya redio, mashirika ya utangazaji na chapa hufanya maamuzi kuhusu ununuzi wa matangazo na kupanga mawasiliano yao ya uuzaji.

Utafiti wa vyombo vya habari ni eneo la kiteknolojia la biashara. Kutambua mlolongo wa video, kukusanya data kutoka kwa vifaa vinavyochambua kutazama, kupima shughuli kwenye rasilimali za wavuti - yote haya yanamaanisha kuwa kampuni ina wafanyakazi wakubwa wa IT na uzoefu mkubwa katika kujenga ufumbuzi wa uchambuzi. Lakini ukuaji mkubwa wa kiasi cha habari, idadi na anuwai ya vyanzo vyake hulazimisha tasnia ya data ya IT kuendelea kila wakati. Suluhisho rahisi zaidi la kuongeza jukwaa la uchambuzi la Mediascope tayari linaweza kuwa kuongeza wafanyikazi wa IT. Lakini suluhisho la ufanisi zaidi ni kuharakisha mchakato wa maendeleo. Moja ya hatua zinazoongoza katika mwelekeo huu inaweza kuwa matumizi ya majukwaa ya chini ya kanuni.

Wakati mradi ulianza, kampuni tayari ilikuwa na suluhisho la bidhaa linalofanya kazi. Hata hivyo, utekelezaji wa suluhisho katika MSSQL haukuweza kukidhi kikamilifu matarajio ya utendakazi wa kuongeza wakati wa kudumisha gharama inayokubalika ya maendeleo.

Jukumu lililokuwa mbele yetu lilikuwa kubwa sana - Neoflex na Mediascope zililazimika kuunda suluhisho la kiviwanda chini ya mwaka mmoja, kulingana na kutolewa kwa MVP ndani ya robo ya kwanza ya tarehe ya kuanza.

Mkusanyiko wa teknolojia ya Hadoop ulichaguliwa kama msingi wa kujenga jukwaa jipya la data kulingana na kompyuta ya nambari za chini. HDFS imekuwa kiwango cha kuhifadhi data kwa kutumia faili za parquet. Ili kufikia data iliyo kwenye jukwaa, Hive ilitumiwa, ambayo mbele za duka zote zinazopatikana zinawasilishwa kwa namna ya meza za nje. Kupakia data kwenye hifadhi kulitekelezwa kwa kutumia Kafka na Apache NiFi.

Zana ya msimbo wa chini katika dhana hii ilitumika kuboresha kazi kubwa zaidi katika kujenga jukwaa la uchanganuzi - kazi ya kuhesabu data.

Zana ya Datagram ya msimbo wa chini ilichaguliwa kama njia kuu ya uchoraji ramani. Takwimu za Neoflex ni zana ya kukuza mabadiliko na mtiririko wa data.
Kutumia zana hii, unaweza kufanya bila kuandika nambari ya Scala kwa mikono. Nambari ya Scala inatolewa kiotomatiki kwa kutumia mbinu ya Usanifu wa Mfano.

Faida dhahiri ya njia hii ni kuharakisha mchakato wa maendeleo. Walakini, pamoja na kasi, pia kuna faida zifuatazo:

• Kuangalia maudhui na muundo wa vyanzo/wapokeaji;
• Kufuatilia asili ya vitu vya mtiririko wa data kwa nyanja za kibinafsi (ukoo);
• Utekelezaji wa sehemu ya mabadiliko kwa kutazama matokeo ya kati;
• Kukagua msimbo wa chanzo na kurekebisha kabla ya utekelezaji;
• Uthibitishaji wa moja kwa moja wa mabadiliko;
• Pakua data otomatiki 1 kati ya 1.

Kizuizi cha kuingia katika suluhu za misimbo ya chini kwa ajili ya kuzalisha mabadiliko ni kidogo sana: msanidi anahitaji kujua SQL na kuwa na uzoefu wa kufanya kazi na zana za ETL. Inafaa kutaja kwamba jenereta za mabadiliko zinazoendeshwa na msimbo sio zana za ETL kwa maana pana ya neno. Zana za msimbo wa chini haziwezi kuwa na mazingira yao ya utekelezaji wa nambari. Hiyo ni, nambari iliyotengenezwa itatekelezwa katika mazingira ambayo yalikuwepo kwenye nguzo hata kabla ya kusanidi suluhisho la nambari ya chini. Na hii labda ni nyongeza nyingine kwa karma ya nambari ya chini. Kwa kuwa, sambamba na timu ya msimbo wa chini, timu ya "classic" inaweza kufanya kazi ambayo inatekeleza utendaji, kwa mfano, katika kanuni safi ya Scala. Kuleta maboresho kutoka kwa timu zote mbili katika uzalishaji itakuwa rahisi na isiyo na mshono.

Labda inafaa kuzingatia kuwa pamoja na nambari ya chini, pia kuna suluhisho zisizo na nambari. Na kwa msingi wao, haya ni mambo tofauti. Msimbo wa chini huruhusu msanidi kuingiliana zaidi na msimbo unaozalishwa. Kwa upande wa Datagram, inawezekana kutazama na kuhariri msimbo wa Scala uliozalishwa; hakuna msimbo hauwezi kutoa fursa kama hiyo. Tofauti hii ni muhimu sana sio tu kwa suala la kubadilika kwa suluhisho, lakini pia kwa suala la faraja na motisha katika kazi ya wahandisi wa data.

Usanifu wa suluhisho

Wacha tujaribu kujua jinsi zana ya nambari ya chini husaidia kutatua shida ya kuongeza kasi ya kukuza utendaji wa hesabu ya data. Kwanza, hebu tuangalie usanifu wa kazi wa mfumo. Mfano katika kesi hii ni mfano wa utengenezaji wa data kwa utafiti wa media.

Vyanzo vya data kwa upande wetu ni tofauti sana na tofauti:

• Mita za watu (mita za TV) ni vifaa vya programu na maunzi ambavyo husoma tabia ya mtumiaji kutoka kwa wahojiwa wa jopo la televisheni - nani, lini na ni kituo gani cha televisheni kilitazamwa katika kaya inayoshiriki katika utafiti. Taarifa iliyotolewa ni mtiririko wa vipindi vya kutazama utangazaji vilivyounganishwa na kifurushi cha media na bidhaa ya media. Data katika hatua ya kupakiwa kwenye Ziwa la Data inaweza kurutubishwa kwa sifa za idadi ya watu, uwekaji nafasi, eneo la saa na taarifa nyingine muhimu kwa ajili ya kuchanganua utazamaji wa televisheni wa bidhaa fulani ya midia. Vipimo vilivyochukuliwa vinaweza kutumiwa kuchanganua au kupanga kampeni za utangazaji, kutathmini shughuli na mapendeleo ya hadhira, na kukusanya mtandao wa utangazaji;
• Data inaweza kutoka kwa mifumo ya ufuatiliaji kwa ajili ya kutiririsha matangazo ya televisheni na kupima utazamaji wa maudhui ya rasilimali za video kwenye Mtandao;
• Zana za kupimia katika mazingira ya wavuti, ikiwa ni pamoja na mita za tovuti na zinazozingatia mtumiaji. Mtoa huduma wa data wa Ziwa la Data anaweza kuwa nyongeza ya kivinjari cha upau wa utafiti na programu ya simu iliyo na VPN iliyojengewa ndani.
• Data inaweza pia kutoka kwenye tovuti zinazounganisha matokeo ya kujaza dodoso mtandaoni na matokeo ya usaili wa simu katika tafiti za kampuni;
• Uboreshaji wa ziada wa ziwa la data unaweza kutokea kwa kupakua maelezo kutoka kwa kumbukumbu za makampuni washirika.

Utekelezaji wa jinsi inavyopakia kutoka kwa mifumo ya chanzo hadi hatua ya msingi ya data ghafi inaweza kupangwa kwa njia mbalimbali. Ikiwa msimbo wa chini unatumiwa kwa madhumuni haya, uundaji wa moja kwa moja wa upakiaji wa hati kulingana na metadata inawezekana. Katika kesi hii, hakuna haja ya kwenda chini kwa kiwango cha chanzo kinachoendelea ili kulenga ramani. Ili kutekeleza upakiaji wa moja kwa moja, tunahitaji kuanzisha uunganisho kwenye chanzo, na kisha tufafanue kwenye interface ya upakiaji orodha ya vyombo vinavyopaswa kubeba. Muundo wa saraka katika HDFS utaundwa kiotomatiki na utalingana na muundo wa kuhifadhi data kwenye mfumo wa chanzo.

Hata hivyo, katika muktadha wa mradi huu, tuliamua kutotumia kipengele hiki cha jukwaa la kificho cha chini kutokana na ukweli kwamba kampuni ya Mediascope tayari imeanza kazi ya kujitegemea katika kuzalisha huduma sawa kwa kutumia mchanganyiko wa Nifi + Kafka.

Inafaa kuashiria mara moja kuwa zana hizi hazibadiliki, lakini ni za ziada. Nifi na Kafka wanaweza kufanya kazi kwa moja kwa moja (Nifi -> Kafka) na kinyume chake (Kafka -> Nifi) uhusiano. Kwa jukwaa la utafiti wa vyombo vya habari, toleo la kwanza la kifungu lilitumiwa.

Kwa upande wetu, NayFi alihitaji kuchakata aina mbalimbali za data kutoka kwa mifumo ya chanzo na kuzituma kwa wakala wa Kafka. Katika kesi hii, ujumbe ulitumwa kwa mada maalum ya Kafka kwa kutumia vichakataji vya PublishKafka Nifi. Upangaji na matengenezo ya mabomba haya hufanyika katika kiolesura cha kuona. Chombo cha Nifi na matumizi ya mchanganyiko wa Nifi + Kafka pia inaweza kuitwa njia ya chini ya kanuni ya maendeleo, ambayo ina kizuizi cha chini cha kuingia katika teknolojia za Data Kubwa na kuharakisha mchakato wa maendeleo ya maombi.

Hatua inayofuata katika utekelezaji wa mradi ilikuwa kuleta data ya kina kwa umbizo la safu moja ya kisemantiki. Ikiwa huluki ina sifa za kihistoria, hesabu hufanywa katika muktadha wa kizigeu kinachohusika. Ikiwa chombo sio cha kihistoria, basi inawezekana kwa hiari kuhesabu tena yaliyomo yote ya kitu, au kukataa kabisa kuhesabu tena kitu hiki (kwa sababu ya ukosefu wa mabadiliko). Katika hatua hii, funguo hutolewa kwa vyombo vyote. Vifunguo huhifadhiwa kwenye saraka za Hbase zinazolingana na vitu kuu, ambavyo vina mawasiliano kati ya funguo kwenye jukwaa la uchambuzi na funguo kutoka kwa mifumo ya chanzo. Ujumuishaji wa vyombo vya atomiki unaambatana na uboreshaji na matokeo ya hesabu ya awali ya data ya uchambuzi. Mfumo wa kukokotoa data ulikuwa Spark. Utendaji uliofafanuliwa wa kuleta data kwa semantiki moja pia ulitekelezwa kulingana na upangaji kutoka kwa zana ya Datagram ya msimbo wa chini.

Usanifu lengwa ulihitaji ufikiaji wa SQL kwa data kwa watumiaji wa biashara. Hive ilitumika kwa chaguo hili. Vipengee husajiliwa katika Hive kiotomatiki unapowezesha chaguo la "Registr Hive Table" katika zana ya msimbo wa chini.

Udhibiti wa mtiririko wa hesabu

Datagram ina kiolesura cha kuunda miundo ya mtiririko wa kazi. Upangaji unaweza kuzinduliwa kwa kutumia kipanga ratiba cha Oozie. Katika kiolesura cha msanidi wa mtiririko, inawezekana kuunda mipango ya mabadiliko ya data yanayolingana, mfululizo, au yanayotegemea utekelezaji. Kuna msaada kwa maandishi ya ganda na programu za java. Inawezekana pia kutumia seva ya Apache Livy. Apache Livy inatumika kuendesha programu moja kwa moja kutoka kwa mazingira ya maendeleo.

Ikiwa kampuni tayari ina ochestra yake ya mchakato, inawezekana kutumia API ya REST kupachika michoro kwenye mtiririko uliopo. Kwa mfano, tulikuwa na uzoefu mzuri wa kupachika michoro katika Scala katika waimbaji waimbaji walioandikwa katika PLSQL na Kotlin. API ya REST ya zana ya msimbo wa chini inajumuisha shughuli kama vile kuzalisha mwaka unaoweza kutekelezwa kulingana na muundo wa ramani, kuita ramani, kuita mfuatano wa upangaji, na, bila shaka, kupitisha vigezo kwa URL ili kuendesha upangaji.

Pamoja na Oozie, inawezekana kupanga mtiririko wa hesabu kwa kutumia Airflow. Labda sitakaa kwa muda mrefu juu ya ulinganisho kati ya Oozie na Airflow, lakini nitasema tu kwamba katika muktadha wa kazi kwenye mradi wa utafiti wa media, uchaguzi ulipendelea Airflow. Hoja kuu wakati huu zilikuwa jumuiya amilifu zaidi inayotengeneza bidhaa na kiolesura kilichoendelezwa zaidi + API.

Utiririshaji wa hewa pia ni mzuri kwa sababu hutumia Python inayopendwa kuelezea michakato ya hesabu. Na kwa ujumla, hakuna majukwaa mengi ya wazi ya usimamizi wa mtiririko wa kazi. Kuzindua na kufuatilia utekelezwaji wa michakato (pamoja na chati ya Gantt) huongeza pointi kwenye karma ya Airflow.

Umbizo la faili ya usanidi kwa ajili ya kuzindua mipangilio ya suluhu ya nambari za chini imekuwa ya kuwasilisha cheche. Hii ilitokea kwa sababu mbili. Kwanza, uwasilishaji wa cheche hukuruhusu kuendesha faili ya jar moja kwa moja kutoka kwa koni. Pili, inaweza kuwa na taarifa zote muhimu ili kusanidi mtiririko wa kazi (ambayo hurahisisha kuandika hati zinazozalisha Dag).
Kipengele cha kawaida cha mtiririko wa kazi wa Airflow katika kesi yetu ilikuwa SparkSubmitOperator.

SparkSubmitOperator hukuruhusu kuendesha mitungi - michoro ya Datagram iliyopakiwa na vigezo vya ingizo vilivyotayarishwa awali kwa ajili yake.

Inafaa kutaja kuwa kila kazi ya Airflow inaendeshwa kwa safu tofauti na haijui chochote kuhusu kazi zingine. Kwa hivyo, mwingiliano kati ya kazi unafanywa kwa kutumia waendeshaji wa kudhibiti, kama vile DummyOperator au BranchPythonOperator.

Kwa pamoja, utumiaji wa suluhisho la nambari ya chini ya Datagram kwa kushirikiana na ujumuishaji wa faili za usanidi (kuunda Dag) ulisababisha kuongeza kasi na kurahisisha mchakato wa kukuza mtiririko wa upakiaji wa data.

Onyesha mahesabu

Labda hatua iliyosheheni kiakili zaidi katika utengenezaji wa data ya uchanganuzi ni hatua ya maonyesho ya ujenzi. Katika muktadha wa moja ya mtiririko wa hesabu ya data ya kampuni ya utafiti, katika hatua hii, data hupunguzwa kwa utangazaji wa kumbukumbu, kwa kuzingatia marekebisho ya maeneo ya wakati na kuunganishwa na gridi ya matangazo. Inawezekana pia kurekebisha kwa mtandao wa utangazaji wa ndani (habari za ndani na utangazaji). Miongoni mwa mambo mengine, hatua hii inavunja vipindi vya utazamaji unaoendelea wa bidhaa za vyombo vya habari kulingana na uchambuzi wa vipindi vya kutazama. Mara moja, maadili ya kutazama yana "uzito" kulingana na habari juu ya umuhimu wao (hesabu ya sababu ya kurekebisha).

Hatua tofauti katika kuandaa maonyesho ni uthibitishaji wa data. Kanuni ya uthibitishaji inahusisha matumizi ya idadi ya mifano ya sayansi ya hisabati. Hata hivyo, matumizi ya jukwaa la msimbo wa chini hukuruhusu kuvunja algoriti changamano katika idadi ya michoro tofauti zinazoweza kusomeka. Kila moja ya michoro hufanya kazi nyembamba. Matokeo yake, utatuzi wa kati, ukataji miti na taswira ya hatua za utayarishaji wa data zinawezekana.

Iliamuliwa kutofautisha algorithm ya uthibitishaji katika hatua ndogo zifuatazo:

• Kujenga rejeshi za utegemezi wa kutazama mtandao wa TV katika eneo lenye kutazamwa kwa mitandao yote katika eneo hilo kwa siku 60.
• Uhesabuji wa masalia ya wanafunzi (mkengeuko wa thamani halisi kutoka kwa zile zilizotabiriwa na muundo wa rejista) kwa alama zote za rejista na kwa siku iliyohesabiwa.
• Uteuzi wa jozi zisizo za kawaida za mtandao wa eneo, ambapo salio la wanafunzi la siku ya malipo linazidi kawaida (iliyobainishwa na mipangilio ya operesheni).
• Uhesabuji upya wa masalio ya wanafunzi yaliyosahihishwa kwa jozi za mtandao wa Runinga za mkoa na zisizo za kawaida kwa kila mhojiwa ambaye alitazama mtandao katika eneo hilo, kubaini mchango wa mjibu huyu (kiasi cha mabadiliko katika masalio ya wanafunzi) wakati wa kutojumuisha utazamaji wa mjibu huyu kutoka kwa sampuli. .
• Tafuta wagombeaji ambao kutengwa kwao kunarejesha salio la wanafunzi la siku ya malipo kuwa ya kawaida.

Mfano hapo juu unathibitisha dhana kwamba mhandisi wa data tayari ana mengi juu ya akili yake ... Na, ikiwa hii ni kweli "mhandisi" na si "coder," basi hofu ya uharibifu wa kitaaluma wakati wa kutumia zana za chini za kanuni yeye. lazima hatimaye kurudi nyuma.

Ni nini kingine kinachoweza kufanya nambari ya chini?

Upeo wa utumiaji wa zana ya msimbo wa chini kwa kundi na uchakataji wa data bila hitaji la kuandika msimbo mwenyewe katika Scala hauishii hapo.

Matumizi ya nambari ya chini katika ukuzaji wa datalake tayari imekuwa kiwango kwetu. Pengine tunaweza kusema kwamba masuluhisho kulingana na mrundikano wa Hadoop yanafuata njia ya ukuzaji ya DWHs za kawaida kulingana na RDBMS. Zana za msimbo wa chini kwenye rafu ya Hadoop zinaweza kutatua kazi zote mbili za usindikaji wa data na kazi ya kujenga violesura vya mwisho vya BI. Aidha, ni lazima ieleweke kwamba BI inaweza kumaanisha si tu uwakilishi wa data, lakini pia uhariri wake na watumiaji wa biashara. Mara nyingi sisi hutumia utendaji huu tunapounda mifumo ya uchanganuzi ya sekta ya fedha.

Miongoni mwa mambo mengine, kwa kutumia kanuni ya chini na, hasa, Datagram, inawezekana kutatua tatizo la kufuatilia asili ya vitu vya mkondo wa data na atomicity hadi kwenye mashamba ya mtu binafsi (ukoo). Ili kufanya hivyo, zana ya msimbo wa chini hutumia kiolesura cha Apache Atlas na Cloudera Navigator. Kimsingi, msanidi anahitaji kusajili seti ya vitu katika kamusi za Atlas na kurejelea vitu vilivyosajiliwa wakati wa kuunda ramani. Utaratibu wa kufuatilia asili ya data au kuchanganua utegemezi wa vitu huokoa muda mwingi inapohitajika kufanya uboreshaji wa algoriti za hesabu. Kwa mfano, wakati wa kuandaa taarifa za kifedha, kipengele hiki hukuruhusu kuishi kwa raha kipindi cha mabadiliko ya sheria. Baada ya yote, tunaelewa vizuri utegemezi wa fomu kati ya muktadha wa vitu vya safu ya kina, ndivyo tutakavyokutana na kasoro za "ghafla" na kupunguza idadi ya kazi tena.

Ubora wa Data na Msimbo wa Chini

Kazi nyingine iliyotekelezwa na zana ya msimbo wa chini kwenye mradi wa Mediascope ilikuwa kazi ya darasa la Ubora wa Data. Kipengele maalum cha utekelezaji wa bomba la uthibitishaji wa data kwa mradi wa kampuni ya utafiti ilikuwa ukosefu wa athari kwenye utendakazi na kasi ya mtiririko mkuu wa kukokotoa data. Ili kuweza kupanga mitiririko huru ya uthibitishaji wa data, Apache Airflow ambayo tayari imejulikana ilitumiwa. Kwa kuwa kila hatua ya utengenezaji wa data ilikuwa tayari, sehemu tofauti ya bomba la DQ ilizinduliwa sambamba.

Inachukuliwa kuwa mazoezi mazuri ya kufuatilia ubora wa data tangu ilipoanzishwa kwenye jukwaa la uchanganuzi. Kwa kuwa na taarifa kuhusu metadata, tunaweza kuangalia utiifu wa masharti ya kimsingi kutoka wakati taarifa inapoingia kwenye safu ya msingi - sio batili, vikwazo, funguo za kigeni. Utendaji huu unatekelezwa kulingana na uundaji wa kiotomatiki wa familia ya ubora wa data katika Datagram. Uzalishaji wa msimbo katika kesi hii pia unategemea metadata ya mfano. Kwenye mradi wa Mediascope, kiolesura kilifanywa na metadata ya bidhaa ya Usanifu wa Biashara.

Kwa kuoanisha zana ya nambari ya chini na Mbunifu wa Biashara, hundi zifuatazo zilitolewa kiotomatiki:

• Kuangalia uwepo wa maadili ya "null" kwenye sehemu na kirekebishaji "sio batili";
• Kuangalia uwepo wa nakala za ufunguo wa msingi;
• Kuangalia ufunguo wa kigeni wa shirika;
• Kuangalia upekee wa mfuatano kulingana na seti ya sehemu.

Kwa ukaguzi changamano zaidi wa upatikanaji na kutegemewa kwa data, uchoraji wa ramani uliundwa na Scala Expression, ambayo inachukua kama ingizo la msimbo wa hundi wa nje wa Spark SQL uliotayarishwa na wachambuzi huko Zeppelin.

Bila shaka, kizazi cha moja kwa moja cha hundi lazima kifikiwe hatua kwa hatua. Ndani ya mfumo wa mradi ulioelezewa, hii ilitanguliwa na hatua zifuatazo:

• DQ kutekelezwa katika daftari za Zeppelin;
• DQ iliyojengwa katika uchoraji wa ramani;
• DQ katika mfumo wa michoro kubwa tofauti iliyo na seti nzima ya hundi kwa chombo tofauti;
• Upangaji wa ramani za DQ zilizo na vigezo vya jumla zinazokubali maelezo kuhusu metadata na ukaguzi wa biashara kama ingizo.

Labda faida kuu ya kuunda huduma ya hundi ya parameterized ni kupunguzwa kwa muda inachukua ili kutoa utendaji kwa mazingira ya uzalishaji. Ukaguzi mpya wa ubora unaweza kukwepa muundo wa kawaida wa kutoa msimbo kwa njia isiyo ya moja kwa moja kupitia usanidi na mazingira ya majaribio:

• Ukaguzi wote wa metadata huzalishwa kiotomatiki muundo unaporekebishwa katika EA;
• Ukaguzi wa upatikanaji wa data (kuamua kuwepo kwa data yoyote kwa wakati fulani) inaweza kuzalishwa kulingana na saraka ambayo huhifadhi muda unaotarajiwa wa kuonekana kwa kipande kinachofuata cha data katika mazingira ya vitu;
• Ukaguzi wa uthibitishaji wa data ya biashara huundwa na wachambuzi katika daftari za Zeppelin. Kutoka hapo hutumwa moja kwa moja kwa meza za usanidi wa moduli za DQ katika mazingira ya uzalishaji.

Hakuna hatari za kusafirisha hati moja kwa moja hadi kwa toleo la umma. Hata kukiwa na hitilafu ya kisintaksia, upeo unaotishia ni kushindwa kufanya ukaguzi mmoja, kwa sababu mtiririko wa kukokotoa data na mtiririko wa uzinduzi wa ukaguzi wa ubora hutenganishwa kutoka kwa kila mmoja.

Kimsingi, huduma ya DQ inaendeshwa kwa kudumu katika mazingira ya uzalishaji na iko tayari kuanza kazi yake wakati kipande kinachofuata cha data kinapoonekana.

Badala ya hitimisho

Faida ya kutumia nambari ya chini ni dhahiri. Watengenezaji hawana haja ya kuendeleza programu kutoka mwanzo. Na programu iliyoachiliwa kutoka kwa kazi za ziada hutoa matokeo haraka. Kasi, kwa upande wake, hutoa muda wa ziada wa kutatua masuala ya uboreshaji. Kwa hiyo, katika kesi hii, unaweza kutegemea ufumbuzi bora na wa haraka.

Kwa kweli, nambari ya chini sio panacea, na uchawi hautatokea peke yake:

• Sekta ya kificho cha chini inapitia hatua ya "kuimarika zaidi", na hakuna viwango vya viwandani vinavyofanana bado;
• Ufumbuzi mwingi wa kanuni za chini sio bure, na ununuzi wao unapaswa kuwa hatua ya ufahamu, ambayo inapaswa kufanywa kwa ujasiri kamili katika faida za kifedha za kuzitumia;
• Suluhisho nyingi za nambari ya chini hazifanyi kazi vizuri kila wakati na GIT/SVN. Au ni ngumu kutumia ikiwa nambari iliyotengenezwa imefichwa;
• Wakati wa kupanua usanifu, inaweza kuwa muhimu kuboresha suluhisho la nambari ya chini - ambayo, kwa upande wake, husababisha athari ya "kiambatisho na utegemezi" kwa mtoaji wa suluhisho la nambari ya chini.
• Kiwango cha kutosha cha usalama kinawezekana, lakini ni kazi kubwa sana na ni vigumu kutekeleza katika injini za mfumo wa chini. Majukwaa ya msimbo wa chini yanapaswa kuchaguliwa sio tu kwa kanuni ya kutafuta faida kutoka kwa matumizi yao. Wakati wa kuchagua, inafaa kuuliza maswali kuhusu upatikanaji wa utendaji wa udhibiti wa ufikiaji na ugawaji/upanuzi wa data ya kitambulisho hadi kiwango cha mazingira yote ya IT ya shirika.

Hata hivyo, ikiwa mapungufu yote ya mfumo uliochaguliwa yanajulikana kwako, na faida kutokana na matumizi yake, hata hivyo, ni katika wengi walio wengi, kisha uende kwenye kanuni ndogo bila hofu. Zaidi ya hayo, mpito kwake hauepukiki - kama vile mageuzi yoyote hayaepukiki.

Ikiwa msanidi mmoja kwenye jukwaa la msimbo wa chini anafanya kazi yake kwa kasi zaidi kuliko watengenezaji wawili bila msimbo wa chini, basi hii inatoa kampuni kichwa katika mambo yote. Kizingiti cha kuingia katika ufumbuzi wa kanuni za chini ni chini kuliko katika teknolojia za "jadi", na hii ina athari nzuri juu ya suala la uhaba wa wafanyakazi. Unapotumia zana za msimbo wa chini, inawezekana kuharakisha mwingiliano kati ya timu za kazi na kufanya maamuzi ya haraka kuhusu usahihi wa njia iliyochaguliwa ya utafiti wa sayansi ya data. Majukwaa ya kiwango cha chini yanaweza kuendesha mageuzi ya kidijitali ya shirika kwa sababu suluhu zinazotolewa zinaweza kueleweka na wataalamu wasio wa kiufundi (hasa watumiaji wa biashara).

Ikiwa una tarehe za mwisho ngumu, mantiki ya biashara iliyopakia, ukosefu wa utaalamu wa kiteknolojia, na unahitaji kuharakisha muda wako wa soko, basi nambari ya chini ni njia moja ya kukidhi mahitaji yako.

Hakuna kukataa umuhimu wa zana za maendeleo za jadi, lakini katika hali nyingi, kutumia ufumbuzi wa kanuni za chini ni njia bora ya kuongeza ufanisi wa kazi zinazotatuliwa.

Chanzo: mapenzi.com