Apache NIFI - Mallonga Superrigardo de Trajtoj en Praktiko

Enkonduko

Okazis, ke ĉe mia nuna laborloko mi devis konatiĝi kun ĉi tiu teknologio. Mi komencos per iom da fono. Ĉe la sekva renkontiĝo, nia teamo estis dirita ke ni bezonas krei integriĝon kun konata sistemo. Per integriĝo oni volis diri, ke ĉi tiu konata sistemo sendus al ni petojn per HTTP al specifa finpunkto, kaj ni, strange, resendus respondojn en formo de SOAP-mesaĝo. Ĉio ŝajnas simpla kaj bagatela. El tio sekvas, ke vi bezonas...

Objektivo

Kreu 3 servojn. La unua el ili estas la Database Update Service. Ĉi tiu servo, kiam novaj datumoj alvenas de triaparta sistemo, ĝisdatigas la datumojn en la datumbazo kaj generas dosieron en CSV-formato por transdoni ĝin al la sekva sistemo. La finpunkto de la dua servo nomiĝas - la FTP-Transportservo, kiu ricevas la transdonitan dosieron, validas ĝin kaj metas ĝin en dosierstokadon per FTP. La tria servo, la konsumanttransigo de datumoj, funkcias nesinkrone kun la unuaj du. Ĝi ricevas peton de triaparta ekstera sistemo por ricevi la dosieron diskutitan supre, prenas la pretan responddosieron, modifas ĝin (ĝisdatigas la id, priskribon, linkToFile kampojn) kaj sendas la respondon en formo de SOAP-mesaĝo. Tio estas, la ĝenerala bildo estas jena: la unuaj du servoj komencas sian laboron nur kiam la datumoj por ĝisdatigo alvenis. La tria servo funkcias konstante ĉar estas multaj konsumantoj de informoj, ĉirkaŭ 1000 petoj de datumoj por minuto. Servoj estas disponeblaj konstante kaj iliaj okazoj troviĝas en malsamaj medioj, kiel testo, demo, antaŭproduktado kaj prod. Malsupre estas diagramo pri kiel funkcias ĉi tiuj servoj. Mi tuj klarigu, ke iuj detaloj estis simpligitaj por eviti nenecesan kompleksecon.

Teknika Enprofundiĝo

Planante solvon al la problemo, ni unue decidis fari aplikojn en Java uzante la Spring-kadron, Nginx-balancilon, Postgres-datumbazon kaj aliajn teknikajn kaj ne tiom teknikajn aferojn. Ĉar la tempo por disvolvi teknikan solvon permesis al ni konsideri aliajn alirojn por solvi ĉi tiun problemon, nia rigardo falis sur la Apache NIFI-teknologion, kiu estas moda en certaj rondoj. Mi tuj diros, ke ĉi tiu teknologio permesis al ni rimarki ĉi tiujn 3 servojn. Ĉi tiu artikolo priskribos la disvolviĝon de dosiera transportservo kaj datumtransigo servo al la konsumanto, sed se la artikolo estas utila, mi skribos pri la servo por ĝisdatigi datumojn en la datumbazo.

Kio ĝi estas?

NIFI estas distribuita arkitekturo por rapida paralela ŝarĝo kaj prilaborado de datumoj, granda nombro da kromaĵoj por fontoj kaj transformoj, versio de agordoj kaj multe pli. Bela bonuso estas, ke ĝi estas tre facile uzebla. Trivialaj procezoj kiel getFile, sendHttpRequest kaj aliaj povas esti reprezentitaj kiel kvadratoj. Ĉiu kvadrato reprezentas procezon, kies interagado videblas en la malsupra figuro. Pli detala dokumentaro pri procezaj agordaj interagoj estis verkita tie , por tiuj, kiuj parolas la rusan - tie. La dokumentaro perfekte priskribas kiel malpaki kaj ruli NIFI, kaj ankaŭ kiel krei procezojn, ankaŭ konatajn kiel kvadratoj.
La ideo verki artikolon naskiĝis post longa serĉado kaj strukturado de la ricevitaj informoj en ion konscia, kaj ankaŭ la deziro iom plifaciligi la vivon al estontaj programistoj.

Ekzemplo:

Ekzemplo de kiel kvadratoj interagas unu kun la alia estas konsiderita. La ĝenerala skemo estas sufiĉe simpla: Ni ricevas HTTP-peton (Teorie, kun dosiero en la korpo de la peto. Por pruvi la kapablojn de NIFI, en ĉi tiu ekzemplo la peto komencas la procezon ricevi dosieron de la loka dosierstokado. ), tiam ni resendas respondon, ke la peto estis ricevita, paralele la procezon ricevi dosieron de FH kaj poste la procezon movi ĝin per FTP al FH. Indas klarigi, ke procezoj interagas inter si per la tiel nomata flowFile. Ĉi tiu estas la baza ento en NIFI, kiu stokas atributojn kaj enhavon. Enhavo estas la datumoj, kiuj estas reprezentataj de la flua dosiero. Tio estas, proksimume, se vi ricevas dosieron de unu kvadrato kaj translokigas ĝin al alia, la enhavo estos via dosiero.

Kiel vi povas vidi, ĉi tiu bildo montras la ĝeneralan procezon. HandleHttpRequest - akceptas petojn, ReplaceText - generas respondkorpon, HandleHttpResponse - sendas respondon. FetchFile - ricevas dosieron de dosierstokado, transdonas ĝin al la kvadrato PutSftp - metas ĉi tiun dosieron sur FTP, ĉe la specifita adreso. Nun pli pri ĉi tiu procezo.

En ĉi tiu kazo, peto estas la komenco de ĉio. Ni rigardu ĝiajn agordajn parametrojn.

Ĉio ĉi tie estas sufiĉe bagatela escepte de StandardHttpContextMap - ĉi tio estas speco de servo, kiu ebligas al vi sendi kaj ricevi petojn. Pli detale kaj eĉ kun ekzemploj, vi povas vidi - tie

Poste, ni rigardu la agordajn parametrojn de ReplaceText de la kvadrato. Indas atenti ReplacementValue - jen kio estos resendita al la uzanto en formo de respondo. En agordoj vi povas ĝustigi la nivelon de protokolado, vi povas vidi la protokolojn {kie vi malpakis nifi}/nifi-1.9.2/protokoloj, ekzistas ankaŭ malsukcesaj/sukcesaj parametroj - surbaze de ĉi tiuj parametroj vi povas reguligi la procezon entute. . Tio estas, en la kazo de sukcesa tekstotraktado, la procezo de sendo de respondo al la uzanto estos nomita, kaj en alia kazo ni simple ensalutos la malsukcesan procezon.

Estas nenio precipe interesa en la propraĵoj de HandleHttpResponse krom la stato kiam respondo estas sukcese kreita.

Ni ordigis la peton kaj respondon - ni pluiru ricevi la dosieron kaj meti ĝin sur la FTP-servilon. FetchFile - ricevas dosieron ĉe la vojo specifita en la agordoj kaj pasas ĝin al la sekva procezo.

Kaj tiam la kvadrato PutSftp - metas la dosieron en la dosierstokadon. Ni povas vidi la agordajn parametrojn sube.

Indas atenti la fakton, ke ĉiu kvadrato estas aparta procezo, kiu devas esti lanĉita. Ni rigardis la plej simplan ekzemplon, kiu ne postulas iun kompleksan personigon. Poste, ni rigardos la procezon iom pli komplikan, kie ni skribos iomete sur la sulkoj.

Pli kompleksa ekzemplo

La datumtransiga servo al la konsumanto montriĝis iom pli komplika pro la procezo de modifado de la SOAP-mesaĝo. La ĝenerala procezo estas montrita en la suba figuro.

Ĉi tie ankaŭ la ideo ne estas aparte komplika: ni ricevis peton de la konsumanto, ke li bezonas datumojn, sendis respondon, ke li ricevis mesaĝon, komencis la procezon por ricevi la responddosieron, poste redaktis ĝin kun certa logiko, kaj poste transdonis la dosieron al la konsumanto en la formo de SOAP-mesaĝo al la servilo.

Mi pensas, ke ne necesas priskribi denove tiujn kvadratojn, kiujn ni vidis supre - ni movu rekte al la novaj. Se vi bezonas redakti iun dosieron kaj ordinaraj ReplaceText-tipaj kvadratoj ne taŭgas, vi devos skribi vian propran skripton. Ĉi tio povas esti farita per la kvadrato ExecuteGroogyScript. Ĝiaj agordoj estas prezentitaj sube.

Estas du ebloj por ŝargi la skripton en ĉi tiun kvadraton. La unua estas elŝutante dosieron kun skripto. La dua estas enmetante skripton en scriptBody. Laŭ mia scio, la kvadrato executeScript subtenas plurajn lingvojn - unu el ili estas groovy. Mi seniluziigos javajn programistojn - vi ne povas skribi skriptojn java en tiaj kvadratoj. Por tiuj, kiuj vere volas, vi devas krei vian propran kvadraton kaj aldoni ĝin al la NIFI-sistemo. Ĉi tiu tuta operacio estas akompanata de sufiĉe longa danco kun tamburino, pri kiu ni ne traktos en ĉi tiu artikolo. Mi elektis la gajan lingvon. Malsupre estas testa skripto, kiu simple pliige ĝisdatigas la identigilon en SOAP-mesaĝo. Gravas noti. Vi prenas la dosieron de flowFile kaj ĝisdatigas ĝin, ne forgesu, ke vi devas remeti ĝin tien, ĝisdatigita. Estas ankaŭ notinde, ke ne ĉiuj bibliotekoj estas inkluzivitaj. Povas okazi, ke vi ankoraŭ devas importi unu el la liboj. Alia malavantaĝo estas, ke la skripto en ĉi tiu kvadrato estas sufiĉe malfacile elpurigebla. Estas maniero konekti al la NIFI JVM kaj komenci la sencimigan procezon. Persone, mi lanĉis lokan aplikaĵon kaj simulis ricevi dosieron de la kunsido. Mi ankaŭ faris sencimigojn loke. Eraroj kiuj aperas dum ŝarĝo de skripto estas sufiĉe facilaj por Guglo kaj estas skribitaj de NIFI mem al la protokolo.

import org.apache.commons.io.IOUtils
import groovy.xml.XmlUtil
import java.nio.charset.*
import groovy.xml.StreamingMarkupBuilder

def flowFile = session.get()
if (!flowFile) return
try {
    flowFile = session.write(flowFile, { inputStream, outputStream ->
        String result = IOUtils.toString(inputStream, "UTF-8");
        def recordIn = new XmlSlurper().parseText(result)
        def element = recordIn.depthFirst().find {
            it.name() == 'id'
        }

        def newId = Integer.parseInt(element.toString()) + 1
        def recordOut = new XmlSlurper().parseText(result)
        recordOut.Body.ClientMessage.RequestMessage.RequestContent.content.MessagePrimaryContent.ResponseBody.id = newId

        def res = new StreamingMarkupBuilder().bind { mkp.yield recordOut }.toString()
        outputStream.write(res.getBytes(StandardCharsets.UTF_8))
} as StreamCallback)
     session.transfer(flowFile, REL_SUCCESS)
}
catch(Exception e) {
    log.error("Error during processing of validate.groovy", e)
    session.transfer(flowFile, REL_FAILURE)
}

Efektive, ĉi tie finiĝas la personigo de la kvadrato. Poste, la ĝisdatigita dosiero estas translokigita al la kvadrato, kiu respondecas pri sendado de la dosiero al la servilo. Malsupre estas la agordoj por ĉi tiu kvadrato.

Ni priskribas la metodon per kiu SOAP-mesaĝo estos elsendita. Ni skribas kie. Poste vi devas indiki, ke ĉi tio estas SAPO.

Aldonu plurajn ecojn kiel gastiganto kaj ago (soapAction). Ni konservas kaj kontrolas. Vi povas vidi pliajn detalojn pri kiel sendi SOAP-petojn tie

Ni rigardis plurajn eblojn por uzi NIFI-procezojn. Kiel ili interagas kaj kio estas ilia vera utilo? La konsiderataj ekzemploj estas provaj kaj iomete diferencas de tio, kio efektive okazas en batalo. Mi esperas, ke ĉi tiu artikolo estos iom utila por programistoj. Dankon pro via atento. Se vi havas demandojn, skribu. Mi provos respondi.

fonto: www.habr.com