Apache NIFI - Գործնականում առանձնահատկությունների համառոտ ակնարկ

Ներածություն

Այնպես ստացվեց, որ իմ ներկայիս աշխատանքի վայրում ես ստիպված էի ծանոթանալ այս տեխնոլոգիային։ Ես կսկսեմ մի փոքր նախապատմությունից: Հաջորդ հանդիպմանը մեր թիմին ասացին, որ մեզ պետք է ինտեգրացիա ստեղծել հայտնի համակարգ. Ինտեգրում ասելով ենթադրվում էր, որ այս հայտնի համակարգը մեզ հարցումներ կուղարկի HTTP-ի միջոցով կոնկրետ վերջնակետ, և մենք, տարօրինակ կերպով, պատասխաններ կուղարկենք SOAP հաղորդագրության տեսքով: Ամեն ինչ պարզ և չնչին է թվում: Սրանից հետևում է, որ անհրաժեշտ է...

Առաջադրանք

Ստեղծեք 3 ծառայություն: Դրանցից առաջինը Database Update Service-ն է: Այս ծառայությունը, երբ նոր տվյալներ են հայտնվում երրորդ կողմի համակարգից, թարմացնում է տվյալների բազայի տվյալները և ստեղծում է ֆայլ CSV ձևաչափով՝ այն հաջորդ համակարգին փոխանցելու համար: Երկրորդ ծառայության վերջնակետը կոչվում է՝ FTP Transport Service, որը ստանում է փոխանցված ֆայլը, վավերացնում է այն և տեղադրում այն ​​ֆայլերի պահեստում FTP-ի միջոցով: Երրորդ ծառայությունը՝ սպառողների տվյալների փոխանցման ծառայությունը, աշխատում է ասինխրոն առաջին երկուսի հետ: Այն ստանում է երրորդ կողմի արտաքին համակարգից վերը քննարկված ֆայլը ստանալու հարցումը, վերցնում է պատրաստ պատասխան ֆայլը, փոփոխում է այն (թարմացնում է ID-ն, նկարագրությունը, linkToFile դաշտերը) և պատասխանն ուղարկում է SOAP հաղորդագրության տեսքով: Այսինքն՝ ընդհանուր պատկերը հետևյալն է. առաջին երկու ծառայություններն իրենց աշխատանքը սկսում են միայն այն ժամանակ, երբ թարմացման տվյալները հասել են։ Երրորդ ծառայությունն անընդհատ աշխատում է, քանի որ ինֆորմացիայի շատ սպառողներ կան՝ րոպեում մոտ 1000 տվյալների հարցում։ Ծառայությունները հասանելի են մշտապես, և դրանց օրինակները գտնվում են տարբեր միջավայրերում, ինչպիսիք են թեստը, ցուցադրությունը, նախնական արտադրությունը և արտադրությունը: Ստորև բերված է դիագրամ, թե ինչպես են աշխատում այդ ծառայությունները: Անմիջապես պարզաբանեմ, որ որոշ մանրամասներ պարզեցվել են՝ ավելորդ բարդություններից խուսափելու համար։

Տեխնիկական խորացում

Խնդրի լուծումը պլանավորելիս մենք նախ որոշեցինք Java-ում հավելվածներ պատրաստել՝ օգտագործելով Spring Framework, Nginx balancer, Postgres տվյալների բազա և այլ տեխնիկական և ոչ այնքան տեխնիկական բաներ։ Քանի որ տեխնիկական լուծում մշակելու ժամանակը մեզ թույլ տվեց դիտարկել այս խնդրի լուծման այլ մոտեցումներ, մեր հայացքն ընկավ Apache NIFI տեխնոլոգիայի վրա, որը մոդայիկ է որոշակի շրջանակներում: Անմիջապես կասեմ, որ այս տեխնոլոգիան մեզ թույլ տվեց նկատել այս 3 ծառայությունները։ Այս հոդվածը նկարագրելու է ֆայլերի փոխադրման ծառայության և սպառողին տվյալների փոխանցման ծառայության մշակումը, բայց եթե հոդվածը օգտակար լինի, ես կգրեմ տվյալների բազայում տվյալների թարմացման ծառայության մասին:

Ինչ է դա:

NIFI-ը բաշխված ճարտարապետություն է՝ տվյալների արագ զուգահեռ բեռնման և մշակման համար, մեծ թվով պլագիններ աղբյուրների և փոխակերպումների համար, կոնֆիգուրացիաների տարբերակման և շատ ավելին: Լավ բոնուսն այն է, որ այն շատ հեշտ է օգտագործել: Չնչին գործընթացները, ինչպիսիք են getFile-ը, sendHttpRequest-ը և այլն, կարող են ներկայացվել որպես քառակուսիներ: Յուրաքանչյուր քառակուսի ներկայացնում է մի գործընթաց, որի փոխազդեցությունը կարելի է տեսնել ստորև բերված նկարում: Գործընթացի տեղադրման փոխազդեցությունների վերաբերյալ ավելի մանրամասն փաստաթղթեր են գրվել այստեղ ռուսերեն խոսողների համար, այստեղ. Փաստաթղթերը հիանալի նկարագրում են, թե ինչպես բացել և գործարկել NIFI-ն, ինչպես նաև ինչպես ստեղծել գործընթացներ, որոնք նաև հայտնի են որպես քառակուսիներ:
Հոդված գրելու գաղափարը ծնվել է երկար փնտրտուքներից և ստացված տեղեկատվությունը գիտակցված ինչ-որ բանի մեջ դասավորելուց, ինչպես նաև ապագա ծրագրավորողների կյանքը մի փոքր հեշտացնելու ցանկությունից հետո:

Օրինակ

Դիտարկվում է օրինակ, թե ինչպես են քառակուսիները փոխազդում միմյանց հետ: Ընդհանուր սխեման բավականին պարզ է. մենք ստանում ենք HTTP հարցում (տեսականորեն, հարցման մարմնում ֆայլով: NIFI-ի հնարավորությունները ցուցադրելու համար, այս օրինակում հարցումը սկսում է ֆայլի ստացման գործընթացը տեղական ֆայլերի պահեստից: ), այնուհետև մենք պատասխան ենք ուղարկում, որ հարցումը ստացվել է, զուգահեռաբար FH-ից ֆայլ ստանալու գործընթացը, այնուհետև այն FTP-ով FH տեղափոխելու գործընթացը: Արժե հստակեցնել, որ գործընթացները փոխազդում են միմյանց հետ, այսպես կոչված, flowFile-ի միջոցով։ Սա NIFI-ի հիմնական միավորն է, որը պահպանում է ատրիբուտները և բովանդակությունը: Բովանդակությունը այն տվյալն է, որը ներկայացված է հոսքային ֆայլով: Այսինքն, կոպիտ ասած, եթե մի հրապարակից ֆայլ ստանաս ու տեղափոխես մյուսը, բովանդակությունը կլինի քո ֆայլը։

Ինչպես տեսնում եք, այս նկարը ցույց է տալիս ընդհանուր գործընթացը: HandleHttpRequest - ընդունում է հարցումները, ReplaceText - առաջացնում է պատասխան մարմին, HandleHttpResponse - ուղարկում է պատասխան: FetchFile - ֆայլ է ստանում ֆայլի պահեստից, փոխանցում այն ​​հրապարակի PutSftp - այս ֆայլը դնում է FTP-ի վրա՝ նշված հասցեով: Այժմ ավելի շատ այս գործընթացի մասին:

Այս դեպքում խնդրանքը ամեն ինչի սկիզբն է։ Դիտարկենք դրա կազմաձևման պարամետրերը:

Այստեղ ամեն ինչ բավականին աննշան է, բացառությամբ StandardHttpContextMap-ի. սա մի տեսակ ծառայություն է, որը թույլ է տալիս ուղարկել և ստանալ հարցումներ: Ավելի մանրամասն և նույնիսկ օրինակներով կարող եք տեսնել. այստեղ

Հաջորդը, եկեք նայենք քառակուսու ReplaceText կազմաձևման պարամետրերին: Արժե ուշադրություն դարձնել ReplacementValue-ին. ահա թե ինչ կվերադարձվի օգտատիրոջը պատասխանի տեսքով։ Կարգավորումներում դուք կարող եք կարգավորել գրանցման մակարդակը, կարող եք տեսնել տեղեկամատյանները {որտեղ բացել եք nifi}/nifi-1.9.2/logs, կան նաև ձախողման/հաջողության պարամետրեր. այս պարամետրերի հիման վրա դուք կարող եք կարգավորել գործընթացը որպես ամբողջություն: . Այսինքն՝ տեքստի հաջող մշակման դեպքում կկանչվի օգտատիրոջը պատասխան ուղարկելու գործընթացը, իսկ մեկ այլ դեպքում մենք պարզապես կգրանցենք անհաջող գործընթացը։

HandleHttpResponse հատկություններում առանձնապես հետաքրքիր բան չկա, բացի այն կարգավիճակից, երբ պատասխանը հաջողությամբ ստեղծվում է:

Մենք դասավորել ենք հարցումն ու պատասխանը. եկեք անցնենք ֆայլի ստացմանը և այն FTP սերվերի վրա տեղադրելուն: FetchFile - ստանում է ֆայլ կարգավորումներում նշված ճանապարհով և փոխանցում այն ​​հաջորդ գործընթացին:

Եվ հետո PutSftp քառակուսին - ֆայլը տեղադրում է ֆայլի պահեստում: Ստորև կարող ենք տեսնել կազմաձևման պարամետրերը:

Արժե ուշադրություն դարձնել այն փաստին, որ յուրաքանչյուր հրապարակ առանձին գործընթաց է, որը պետք է մեկնարկի։ Մենք նայեցինք ամենապարզ օրինակին, որը չի պահանջում որևէ բարդ անհատականացում: Հաջորդը, մենք կանդրադառնանք գործընթացին մի փոքր ավելի բարդ, որտեղ մենք մի փոքր կգրենք ակոսների վրա:

Ավելի բարդ օրինակ

Սպառողին տվյալների փոխանցման ծառայությունը պարզվեց, որ մի փոքր ավելի բարդ է SOAP հաղորդագրության փոփոխման գործընթացի պատճառով: Ընդհանուր գործընթացը ներկայացված է ստորև բերված նկարում:

Այստեղ գաղափարը նույնպես առանձնապես բարդ չէ՝ սպառողից հարցում ստացանք, որ իրեն տվյալներ են պետք, պատասխան ուղարկեցինք, որ հաղորդագրություն է ստացել, սկսեցինք պատասխան ֆայլի ստացման գործընթացը, այնուհետև խմբագրեցինք որոշակի տրամաբանությամբ, այնուհետև. ֆայլը փոխանցել է սպառողին SOAP հաղորդագրության տեսքով սերվերին:

Կարծում եմ, կարիք չկա նորից նկարագրելու այն քառակուսիները, որոնք տեսանք վերևում. եկեք անմիջապես անցնենք նորերին: Եթե ​​Ձեզ անհրաժեշտ է որևէ ֆայլ խմբագրել, և սովորական ReplaceText տիպի քառակուսիները հարմար չեն, դուք ստիպված կլինեք գրել ձեր սեփական սցենարը: Դա կարելի է անել՝ օգտագործելով ExecuteGroogyScript քառակուսին: Դրա կարգավորումները ներկայացված են ստորև:

Սցենարը այս հրապարակում բեռնելու երկու տարբերակ կա: Առաջինը սկրիպտով ֆայլ ներբեռնելու միջոցով է: Երկրորդը scriptBody-ի մեջ սկրիպտ մտցնելն է: Որքան ես գիտեմ, executeScript քառակուսին աջակցում է մի քանի լեզուների, որոնցից մեկը groovy է: Ես կհիասթափեցնեմ java ծրագրավորողներին. նման քառակուսիներում դուք չեք կարող java-ով սցենարներ գրել: Նրանց համար, ովքեր իսկապես ցանկանում են, դուք պետք է ստեղծեք ձեր սեփական պատվերով հրապարակը և ավելացնեք այն NIFI համակարգին: Այս ամբողջ օպերացիան ուղեկցվում է դափի հետ բավականին երկար պարով, որին այս հոդվածում չենք զբաղվի։ Ես ընտրեցի ակամա լեզուն։ Ստորև ներկայացված է թեստային սցենար, որը պարզապես աստիճանաբար թարմացնում է ID-ն SOAP հաղորդագրության մեջ: Կարևոր է նշել. Դուք վերցնում եք ֆայլը flowFile-ից և թարմացնում եք այն, մի մոռացեք, որ այն պետք է նորից տեղադրեք այնտեղ, թարմացված: Հարկ է նաև նշել, որ ոչ բոլոր գրադարաններն են ներառված: Կարող է պատահել, որ դուք դեռ պետք է ներմուծեք lib-երից մեկը: Մեկ այլ թերություն այն է, որ այս քառակուսի սցենարը բավականին դժվար է կարգաբերել: NIFI JVM-ին միանալու և վրիպազերծման գործընթացը սկսելու միջոց կա: Անձամբ ես գործարկեցի տեղական հավելված և մոդելավորեցի նիստից ֆայլ ստանալը: Ես նաև լոկալ կարգաբերում եմ արել: Սխալները, որոնք հայտնվում են սկրիպտը բեռնելիս, բավականին հեշտ են Google-ի համար և գրվում են հենց NIFI-ի կողմից մատյանում:

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)
}

Փաստորեն, այստեղ ավարտվում է քառակուսու հարմարեցումը: Հաջորդը, թարմացված ֆայլը տեղափոխվում է հրապարակ, որը պատասխանատու է ֆայլը սերվեր ուղարկելու համար: Ստորև ներկայացված են այս քառակուսու կարգավորումները:

Մենք նկարագրում ենք այն մեթոդը, որով կփոխանցվի SOAP հաղորդագրությունը: Մենք գրում ենք որտեղ. Հաջորդը դուք պետք է նշեք, որ սա SOAP է:

Ավելացնել մի քանի հատկություններ, ինչպիսիք են հյուրընկալողը և գործողությունը (soapAction): Մենք պահպանում ենք և ստուգում: Դուք կարող եք տեսնել ավելի շատ մանրամասներ, թե ինչպես ուղարկել SOAP հարցումներ այստեղ

Մենք դիտարկեցինք NIFI գործընթացների օգտագործման մի քանի տարբերակներ: Ինչպե՞ս են նրանք փոխազդում և ո՞րն է նրանց իրական օգուտը: Դիտարկված օրինակները փորձնական են և մի փոքր տարբերվում են այն ամենից, ինչ իրականում տեղի է ունենում մարտում: Հուսով եմ, որ այս հոդվածը մի փոքր օգտակար կլինի մշակողների համար: Շնորհակալություն ուշադրության համար. Հարցերի դեպքում գրեք։ Ես կփորձեմ պատասխանել.

Source: www.habr.com