Paano namin nakolekta ang data sa mga kampanya sa advertising mula sa mga online na site (ang mahirap na landas patungo sa produkto)

Tila ang larangan ng online na advertising ay dapat na kasing teknolohikal na advanced at awtomatiko hangga't maaari. Siyempre, dahil ang mga higante at eksperto sa kanilang larangan tulad ng Yandex, Mail.Ru, Google at Facebook ay nagtatrabaho doon. Ngunit, tulad ng nangyari, walang limitasyon sa pagiging perpekto at palaging may isang bagay na i-automate.

Pinagmulan

Grupo ng komunikasyon Dentsu Aegis Network Russia ay ang pinakamalaking manlalaro sa digital advertising market at aktibong namumuhunan sa teknolohiya, sinusubukang i-optimize at i-automate ang mga proseso ng negosyo nito. Ang isa sa mga hindi nalutas na problema ng merkado ng online na advertising ay naging gawain ng pagkolekta ng mga istatistika sa mga kampanya sa advertising mula sa iba't ibang mga platform sa Internet. Ang solusyon sa problemang ito sa huli ay nagresulta sa paglikha ng isang produkto D1.Digital (read as DiVan), ang development na gusto naming pag-usapan.

Bakit?

1. Sa oras ng pagsisimula ng proyekto, walang isang yari na produkto sa merkado na lumutas sa problema ng pag-automate ng koleksyon ng mga istatistika sa mga kampanya sa advertising. Nangangahulugan ito na walang sinuman maliban sa ating sarili ang tutugon sa ating mga pangangailangan.

Ang mga serbisyo tulad ng Improvado, Roistat, Supermetrics, SegmentStream ay nag-aalok ng pagsasama sa mga platform, social network at Google Analitycs, at ginagawang posible rin na bumuo ng mga analytical na dashboard para sa maginhawang pagsusuri at kontrol ng mga kampanya sa advertising. Bago namin simulan ang pagbuo ng aming produkto, sinubukan naming gamitin ang ilan sa mga system na ito upang mangolekta ng data mula sa mga site, ngunit, sa kasamaang-palad, hindi nila malutas ang aming mga problema.

Ang pangunahing problema ay ang mga nasubok na produkto ay umasa sa mga pinagmumulan ng data, na nagpapakita ng mga istatistika ng placement ayon sa site, at hindi nagbigay ng kakayahang magsama-sama ng mga istatistika sa mga kampanya sa advertising. Ang diskarte na ito ay hindi nagbigay-daan sa amin na makita ang mga istatistika mula sa iba't ibang mga site sa isang lugar at suriin ang estado ng kampanya sa kabuuan.

Ang isa pang kadahilanan ay na sa mga unang yugto ang mga produkto ay naglalayong sa Western market at hindi sumusuporta sa pagsasama sa mga site ng Russia. At para sa mga site na iyon kung saan ipinatupad ang pagsasama, ang lahat ng kinakailangang sukatan ay hindi palaging na-download nang may sapat na detalye, at ang pagsasama ay hindi palaging maginhawa at transparent, lalo na kapag kinakailangan upang makakuha ng isang bagay na wala sa interface ng system.
Sa pangkalahatan, nagpasya kaming hindi umangkop sa mga produkto ng third-party, ngunit nagsimula kaming bumuo ng sarili naming...

2. Ang online na merkado ng advertising ay lumalaki taun-taon, at sa 2018, sa mga tuntunin ng mga badyet sa advertising, nalampasan nito ang tradisyonal na pinakamalaking merkado ng advertising sa TV. Kaya may sukat.

3. Hindi tulad ng merkado ng advertising sa TV, kung saan ang pagbebenta ng komersyal na advertising ay monopolyo, mayroong maraming mga indibidwal na may-ari ng imbentaryo ng advertising ng iba't ibang laki na tumatakbo sa Internet gamit ang kanilang sariling mga account sa advertising. Dahil ang isang kampanya sa advertising, bilang panuntunan, ay tumatakbo sa ilang mga site nang sabay-sabay, upang maunawaan ang estado ng kampanya sa advertising, kinakailangan upang mangolekta ng mga ulat mula sa lahat ng mga site at pagsamahin ang mga ito sa isang malaking ulat na magpapakita ng buong larawan. Nangangahulugan ito na may potensyal para sa pag-optimize.

4. Para sa amin, ang mga may-ari ng imbentaryo ng advertising sa Internet ay mayroon nang imprastraktura para sa pagkolekta ng mga istatistika at pagpapakita ng mga ito sa mga account sa advertising, at makakapagbigay sila ng API para sa data na ito. Nangangahulugan ito na teknikal na posible na ipatupad ito. Sabihin natin kaagad na ito ay naging hindi gaanong simple.

Sa pangkalahatan, ang lahat ng mga kinakailangan para sa pagpapatupad ng proyekto ay malinaw sa amin, at tumakbo kami upang buhayin ang proyekto...

Malaking plano

Upang magsimula, bumuo kami ng isang pananaw ng isang perpektong sistema:

• Ang mga kampanya sa pag-advertise mula sa 1C corporate system ay dapat na awtomatikong mai-load dito kasama ng kanilang mga pangalan, tuldok, badyet at pagkakalagay sa iba't ibang platform.
• Para sa bawat placement sa loob ng isang kampanya sa advertising, ang lahat ng posibleng istatistika ay dapat na awtomatikong ma-download mula sa mga site kung saan nagaganap ang placement, tulad ng bilang ng mga impression, click, view, atbp.
• Ang ilang mga kampanya sa advertising ay sinusubaybayan gamit ang pagsubaybay ng third-party ng tinatawag na mga adserving system gaya ng Adriver, Weborama, DCM, atbp. Mayroon ding isang pang-industriya na metro ng Internet sa Russia - ang kumpanya ng Mediascope. Ayon sa aming plano, ang data mula sa independiyente at pang-industriyang pagsubaybay ay dapat ding awtomatikong mai-load sa kaukulang mga kampanya sa advertising.
• Karamihan sa mga kampanya sa advertising sa Internet ay naglalayong sa ilang mga target na aksyon (pagbili, pagtawag, pag-sign up para sa isang test drive, atbp.), na sinusubaybayan gamit ang Google Analytics, at mga istatistika na mahalaga din para sa pag-unawa sa katayuan ng kampanya at dapat na mai-load sa aming tool.

Ang unang pancake ay lumpy

Dahil sa aming pangako sa mga nababagong prinsipyo ng pagbuo ng software (maliksi, lahat ng bagay), nagpasya kaming bumuo muna ng isang MVP at pagkatapos ay umulit na tumungo sa nilalayon na layunin.
Nagpasya kaming bumuo ng MVP batay sa aming produkto DANBo (Detsu Aegis Network Board), na isang web application na may pangkalahatang impormasyon sa mga kampanya sa advertising ng aming mga kliyente.

Para sa MVP, ang proyekto ay pinasimple hangga't maaari sa mga tuntunin ng pagpapatupad. Pumili kami ng limitadong listahan ng mga platform para sa pagsasama. Ito ang mga pangunahing platform, tulad ng Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, at ang mga pangunahing adserving system na Adriver at Weborama.

Upang ma-access ang mga istatistika sa mga site sa pamamagitan ng API, gumamit kami ng isang account. Ang isang client group manager na gustong gumamit ng awtomatikong koleksyon ng mga istatistika sa isang advertising campaign ay kailangang magtalaga muna ng access sa mga kinakailangang advertising campaign sa mga site sa platform account.

Susunod ay ang gumagamit ng system DANBo kinailangang mag-upload ng file ng isang tiyak na format sa Excel system, na naglalaman ng lahat ng impormasyon tungkol sa placement (advertising campaign, platform, format, placement period, planned indicators, budget, atbp.) at mga identifier ng kaukulang mga campaign sa advertising sa mga site at counter sa mga adserving system.

Ito ay mukhang, lantaran, nakakatakot:

Ang na-download na data ay na-save sa isang database, at pagkatapos ay ang mga hiwalay na serbisyo ay nakolekta ng mga identifier ng kampanya sa mga site mula sa kanila at nag-download ng mga istatistika sa mga ito.

Para sa bawat site, isinulat ang isang hiwalay na serbisyo ng windows, na minsan sa isang araw ay sumailalim sa isang account ng serbisyo sa API ng site at nag-download ng mga istatistika para sa mga tinukoy na campaign ID. Ganito rin ang nangyari sa mga adserving system.

Ang na-download na data ay ipinakita sa interface sa anyo ng isang maliit na custom na dashboard:

Sa hindi inaasahan para sa amin, nagsimulang magtrabaho ang MVP at nagsimulang mag-download ng mga kasalukuyang istatistika sa mga kampanya sa advertising sa Internet. Ipinatupad namin ang system sa ilang mga kliyente, ngunit noong sinusubukan naming sukatin, nakatagpo kami ng mga seryosong problema:

• Ang pangunahing problema ay ang pagiging kumplikado ng paghahanda ng data para sa paglo-load sa system. Gayundin, ang data ng placement ay kailangang ma-convert sa isang mahigpit na naayos na format bago mag-load. Kinailangang isama ang mga entity identifier mula sa iba't ibang site sa download file. Kami ay nahaharap sa katotohanan na napakahirap para sa mga teknikal na hindi sanay na mga gumagamit na ipaliwanag kung saan mahahanap ang mga pagkakakilanlan na ito sa site at kung saan sa file ang mga ito ay kailangang ilagay. Isinasaalang-alang ang bilang ng mga empleyado sa mga departamentong nagpapatakbo ng mga kampanya sa mga site at ang turnover, nagresulta ito sa malaking halaga ng suporta sa aming panig, na talagang hindi namin ikinatuwa.
• Ang isa pang problema ay hindi lahat ng platform ng advertising ay may mga mekanismo para sa pagtatalaga ng access sa mga kampanya sa advertising sa ibang mga account. Ngunit kahit na may available na mekanismo ng pagtatalaga, hindi lahat ng advertiser ay handang magbigay ng access sa kanilang mga kampanya sa mga third-party na account.
• Ang isang mahalagang kadahilanan ay ang galit na napukaw sa mga gumagamit sa pamamagitan ng katotohanan na ang lahat ng mga nakaplanong tagapagpahiwatig at mga detalye ng pagkakalagay na naipasok na nila sa aming 1C accounting system, kailangan nilang muling ipasok sa DANBo.

Nagbigay ito sa amin ng ideya na ang pangunahing pinagmumulan ng impormasyon tungkol sa placement ay ang aming 1C system, kung saan ang lahat ng data ay naipasok nang tumpak at nasa oras (ang punto dito ay ang mga invoice ay nabuo batay sa 1C data, kaya tamang pagpasok ng data sa 1C ay isang priyoridad para sa lahat ng KPI). Ito ay kung paano lumitaw ang isang bagong konsepto ng system...

Pagkaunawa

Ang unang bagay na napagpasyahan naming gawin ay paghiwalayin ang sistema para sa pagkolekta ng mga istatistika sa mga kampanya sa advertising sa Internet sa isang hiwalay na produkto - D1.Digital.

Sa bagong konsepto, nagpasya kaming mag-load sa D1.Digital impormasyon sa mga kampanya sa advertising at mga pagkakalagay sa loob ng mga ito mula sa 1C, at pagkatapos ay kunin ang mga istatistika mula sa mga site at AdServing system patungo sa mga pagkakalagay na ito. Ito ay dapat na makabuluhang pasimplehin ang buhay para sa mga gumagamit (at, gaya ng dati, magdagdag ng higit pang trabaho sa mga developer) at bawasan ang dami ng suporta.

Ang unang problemang naranasan namin ay pang-organisasyon at nauugnay sa katotohanang hindi kami makahanap ng susi o senyales kung saan maaari naming paghambingin ang mga entity mula sa iba't ibang system na may mga kampanya at placement mula sa 1C. Ang katotohanan ay ang proseso sa aming kumpanya ay idinisenyo sa paraang ang mga kampanya sa advertising ay ipinasok sa iba't ibang mga sistema ng iba't ibang tao (mga tagaplano ng media, pagbili, atbp.).

Upang malutas ang problemang ito, kinailangan naming mag-imbento ng isang natatanging hashed key, ang DANBoID, na mag-uugnay sa mga entity sa iba't ibang mga system nang magkasama, at maaaring medyo madali at natatanging matukoy sa mga na-download na set ng data. Ang identifier na ito ay nabuo sa panloob na 1C system para sa bawat indibidwal na placement at inililipat sa mga campaign, placement at counter sa lahat ng site at sa lahat ng AdServing system. Nagtagal ang pagpapatupad ng kasanayan sa paglalagay ng DANBoID sa lahat ng placement, ngunit nagawa namin ito :)

Pagkatapos ay nalaman namin na hindi lahat ng site ay may API para sa awtomatikong pagkolekta ng mga istatistika, at kahit na ang mga may API, hindi nito ibinabalik ang lahat ng kinakailangang data.

Sa yugtong ito, nagpasya kaming makabuluhang bawasan ang listahan ng mga platform para sa pagsasama at tumuon sa mga pangunahing platform na kasangkot sa karamihan ng mga kampanya sa advertising. Kasama sa listahang ito ang lahat ng pinakamalaking manlalaro sa advertising market (Google, Yandex, Mail.ru), mga social network (VK, Facebook, Twitter), mga pangunahing AdServing at analytics system (DCM, Driver, Weborama, Google Analytics) at iba pang mga platform.

Ang karamihan sa mga site na napili namin ay may API na nagbibigay ng mga sukatan na kailangan namin. Sa mga kaso kung saan walang API o hindi ito naglalaman ng kinakailangang data, gumamit kami ng mga ulat na ipinadala araw-araw sa aming email sa opisina upang mag-load ng data (sa ilang mga system posible na i-configure ang mga naturang ulat, sa iba ay sumang-ayon kami sa pagbuo ng tulad ng mga ulat para sa amin).

Kapag sinusuri ang data mula sa iba't ibang mga site, nalaman namin na ang hierarchy ng mga entity ay hindi pareho sa iba't ibang mga system. Bukod dito, kailangang ma-download ang impormasyon sa iba't ibang detalye mula sa iba't ibang mga system.

Upang malutas ang problemang ito, binuo ang konsepto ng SubDANBoID. Ang ideya ng SubDANBoID ay medyo simple, minarkahan namin ang pangunahing entity ng campaign sa site gamit ang nabuong DANBoID, at ina-upload namin ang lahat ng nested entity na may mga natatanging identifier ng site at bumubuo ng SubDANBoID ayon sa prinsipyo ng DANBoID + identifier ng unang antas. nested entity + identifier ng second level nested entity +... Ang diskarte na ito ay nagbigay-daan sa amin na ikonekta ang mga campaign sa advertising sa iba't ibang system at mag-download ng mga detalyadong istatistika sa mga ito.

Kinailangan din naming lutasin ang problema sa pag-access sa mga kampanya sa iba't ibang platform. Gaya ng isinulat namin sa itaas, ang mekanismo ng pagtatalaga ng access sa isang kampanya sa isang hiwalay na teknikal na account ay hindi palaging naaangkop. Samakatuwid, kinailangan naming bumuo ng imprastraktura para sa awtomatikong awtorisasyon sa pamamagitan ng OAuth gamit ang mga token at mekanismo para sa pag-update ng mga token na ito.

Mamaya sa artikulo ay susubukan naming ilarawan nang mas detalyado ang arkitektura ng solusyon at ang mga teknikal na detalye ng pagpapatupad.

Arkitektura ng solusyon 1.0

Kapag sinimulan ang pagpapatupad ng isang bagong produkto, naunawaan namin na kailangan namin agad na magbigay para sa posibilidad ng pagkonekta ng mga bagong site, kaya nagpasya kaming sundan ang landas ng arkitektura ng microservice.

Kapag nagdidisenyo ng arkitektura, pinaghiwalay namin ang mga konektor sa lahat ng panlabas na system - 1C, mga platform ng advertising at mga sistema ng adserving - sa magkakahiwalay na mga serbisyo.
Ang pangunahing ideya ay ang lahat ng mga connector sa mga site ay may parehong API at mga adapter na nagdadala ng site API sa isang interface na maginhawa para sa amin.

Sa gitna ng aming produkto ay isang web application, na isang monolith na idinisenyo sa paraang madali itong ma-disassemble sa mga serbisyo. Ang application na ito ay responsable para sa pagproseso ng na-download na data, pag-collate ng mga istatistika mula sa iba't ibang mga system at pagpapakita ng mga ito sa mga user ng system.

Upang makipag-usap sa pagitan ng mga konektor at web application, kailangan naming lumikha ng karagdagang serbisyo, na tinawag naming Connector Proxy. Ginagawa nito ang mga function ng Service Discovery at Task Scheduler. Ang serbisyong ito ay nagpapatakbo ng mga gawain sa pagkolekta ng data para sa bawat connector gabi-gabi. Ang pagsulat ng isang layer ng serbisyo ay mas madali kaysa sa pagkonekta ng isang broker ng mensahe, at para sa amin ay mahalaga na makuha ang resulta sa lalong madaling panahon.

Para sa pagiging simple at bilis ng pag-unlad, napagpasyahan din namin na ang lahat ng mga serbisyo ay magiging mga Web API. Ginawa nitong posible na mabilis na mag-ipon ng isang patunay-ng-konsepto at i-verify na gumagana ang buong disenyo.

Ang isang hiwalay, medyo kumplikadong gawain ay ang pag-set up ng access upang mangolekta ng data mula sa iba't ibang mga account, na, tulad ng napagpasyahan namin, ay dapat na isagawa ng mga user sa pamamagitan ng web interface. Binubuo ito ng dalawang magkahiwalay na hakbang: una, nagdagdag ang user ng token para ma-access ang account sa pamamagitan ng OAuth, at pagkatapos ay iko-configure ang pangongolekta ng data para sa kliyente mula sa isang partikular na account. Ang pagkuha ng token sa pamamagitan ng OAuth ay kinakailangan dahil, gaya ng naisulat na namin, hindi laging posible na magtalaga ng access sa gustong account sa site.

Para gumawa ng unibersal na mekanismo para sa pagpili ng account mula sa mga site, kinailangan naming magdagdag ng paraan sa connectors API na nagbabalik ng JSON Schema, na na-render sa isang form gamit ang binagong bahagi ng JSONEditor. Sa ganitong paraan, nagawang piliin ng mga user ang mga account kung saan magda-download ng data.

Upang makasunod sa mga limitasyon ng kahilingan na umiiral sa mga site, pinagsasama namin ang mga kahilingan para sa mga setting sa loob ng isang token, ngunit maaari naming iproseso ang iba't ibang mga token nang magkatulad.

Pinili namin ang MongoDB bilang isang imbakan para sa na-load na data para sa web application at mga konektor, na nagbigay-daan sa amin na huwag masyadong mag-alala tungkol sa istraktura ng data sa mga unang yugto ng pag-unlad, kapag ang object model ng application ay nagbabago bawat ibang araw.

Nalaman namin sa lalong madaling panahon na hindi lahat ng data ay akma nang maayos sa MongoDB at, halimbawa, mas maginhawang mag-imbak ng mga pang-araw-araw na istatistika sa isang relational database. Samakatuwid, para sa mga konektor na ang istraktura ng data ay mas angkop para sa isang relational database, sinimulan naming gamitin ang PostgreSQL o MS SQL Server bilang imbakan.

Ang napiling arkitektura at teknolohiya ay nagbigay-daan sa amin na buuin at ilunsad ang produkto ng D1.Digital nang medyo mabilis. Sa paglipas ng dalawang taon ng pagbuo ng produkto, nakabuo kami ng 23 connector sa mga site, nagkamit ng napakahalagang karanasan sa pagtatrabaho sa mga third-party na API, natutunang iwasan ang mga pitfalls ng iba't ibang site, na ang bawat isa ay may kanya-kanyang sarili, na nag-ambag sa pagbuo ng API ng hindi bababa sa 3 mga site, awtomatikong nag-download ng impormasyon sa halos 15 mga kampanya at para sa higit sa 000 mga pagkakalagay, nakolekta ng maraming feedback mula sa mga gumagamit sa pagpapatakbo ng produkto at pinamamahalaang baguhin ang pangunahing proseso ng produkto nang maraming beses, batay sa feedback na ito.

Arkitektura ng solusyon 2.0

Dalawang taon na ang lumipas mula nang magsimula ang pag-unlad D1.Digital. Ang patuloy na pagtaas ng load sa system at ang paglitaw ng parami nang parami ng mga bagong data source ay unti-unting nagsiwalat ng mga problema sa umiiral na arkitektura ng solusyon.

Ang unang problema ay nauugnay sa dami ng data na na-download mula sa mga site. Kami ay nahaharap sa katotohanan na ang pagkolekta at pag-update ng lahat ng kinakailangang data mula sa pinakamalaking mga site ay nagsimulang tumagal ng masyadong maraming oras. Halimbawa, ang pagkolekta ng data mula sa AdRiver adserving system, kung saan sinusubaybayan namin ang mga istatistika para sa karamihan ng mga placement, ay tumatagal ng humigit-kumulang 12 oras.

Upang malutas ang problemang ito, sinimulan naming gamitin ang lahat ng uri ng mga ulat upang mag-download ng data mula sa mga site, sinusubukan naming bumuo ng kanilang API kasama ng mga site upang ang bilis ng operasyon nito ay matugunan ang aming mga pangangailangan, at iparallelize ang pag-download ng data hangga't maaari.

Ang isa pang problema ay nauugnay sa pagproseso ng na-download na data. Ngayon, kapag dumating ang mga bagong istatistika ng placement, inilunsad ang isang multi-stage na proseso ng muling pagkalkula ng mga sukatan, na kinabibilangan ng pag-load ng raw data, pagkalkula ng pinagsama-samang sukatan para sa bawat site, paghahambing ng data mula sa iba't ibang pinagmulan sa bawat isa, at pagkalkula ng mga sukatan ng buod para sa kampanya. Nagdudulot ito ng maraming load sa web application na gumagawa ng lahat ng kalkulasyon. Ilang beses, sa panahon ng proseso ng muling pagkalkula, naubos ng application ang lahat ng memorya sa server, mga 10-15 GB, na may pinakamasamang epekto sa trabaho ng mga user sa system.

Ang mga natukoy na problema at ambisyosong mga plano para sa karagdagang pag-unlad ng produkto ay humantong sa amin sa pangangailangang muling isaalang-alang ang arkitektura ng aplikasyon.

Nagsimula kami sa mga konektor.
Napansin namin na ang lahat ng mga konektor ay gumagana ayon sa parehong modelo, kaya bumuo kami ng isang pipeline framework kung saan upang lumikha ng isang connector kailangan mo lamang i-program ang lohika ng mga hakbang, ang iba ay unibersal. Kung ang ilang connector ay nangangailangan ng pagpapahusay, pagkatapos ay agad namin itong ilipat sa isang bagong framework kasabay ng pagpapahusay ng connector.

Kasabay nito, nagsimula kaming mag-deploy ng mga connector sa Docker at Kubernetes.
Pinlano namin ang paglipat sa Kubernetes sa loob ng mahabang panahon, nag-eksperimento sa mga setting ng CI/CD, ngunit nagsimulang lumipat lamang kapag ang isang connector, dahil sa isang error, ay nagsimulang kumain ng higit sa 20 GB ng memorya sa server, na halos pumapatay sa iba pang mga proseso. . Sa panahon ng pagsisiyasat, inilipat ang connector sa isang cluster ng Kubernetes, kung saan nanatili ito sa huli, kahit na naayos na ang error.

Mabilis naming napagtanto na maginhawa ang Kubernetes, at sa loob ng anim na buwan, inilipat namin ang 7 connector at Connectors Proxy, na kumukonsumo ng pinakamaraming mapagkukunan, sa production cluster.

Kasunod ng mga konektor, nagpasya kaming baguhin ang arkitektura ng natitirang bahagi ng application.
Ang pangunahing problema ay ang data ay nagmumula sa mga konektor sa mga proxy sa malalaking batch, at pagkatapos ay pinindot ang DANBoID at ipinadala sa gitnang web application para sa pagproseso. Dahil sa malaking bilang ng mga metrics recalculations, may malaking load sa application.

Napakahirap ding subaybayan ang katayuan ng mga indibidwal na trabaho sa pangongolekta ng data at mag-ulat ng mga error na nagaganap sa loob ng mga konektor sa isang sentral na web application upang makita ng mga user kung ano ang nangyayari at kung bakit hindi kinokolekta ang data.

Upang malutas ang mga problemang ito, binuo namin ang architecture 2.0.

Ang pangunahing pagkakaiba sa pagitan ng bagong bersyon ng arkitektura ay sa halip na ang Web API, ginagamit namin ang RabbitMQ at ang MassTransit library upang makipagpalitan ng mga mensahe sa pagitan ng mga serbisyo. Upang gawin ito, kailangan naming halos ganap na muling isulat ang Connectors Proxy, na ginagawa itong Connectors Hub. Ang pangalan ay binago dahil ang pangunahing tungkulin ng serbisyo ay hindi na sa pagpapasa ng mga kahilingan sa mga konektor at pabalik, ngunit sa pamamahala ng koleksyon ng mga sukatan mula sa mga konektor.

Mula sa gitnang web application, pinaghiwalay namin ang impormasyon tungkol sa mga placement at istatistika mula sa mga site sa magkakahiwalay na serbisyo, na naging posible upang maalis ang mga hindi kinakailangang muling pagkalkula at mag-imbak lamang ng nakalkula at pinagsama-samang mga istatistika sa antas ng placement. Muli rin naming isinulat at na-optimize ang lohika para sa pagkalkula ng mga pangunahing istatistika batay sa raw data.

Kasabay nito, inililipat namin ang lahat ng serbisyo at application sa Docker at Kubernetes upang gawing mas madaling sukatin ang solusyon at mas madaling pamahalaan.

Nasaan na tayo ngayon

Proof-of-concept na arkitektura 2.0 na produkto D1.Digital handa at nagtatrabaho sa isang pagsubok na kapaligiran na may limitadong hanay ng mga konektor. Ang natitirang gawin ay muling isulat ang isa pang 20 connector sa isang bagong platform, subukan na ang data ay na-load nang tama at lahat ng mga sukatan ay kinakalkula nang tama, at ilunsad ang buong disenyo sa produksyon.

Sa katunayan, unti-unting mangyayari ang prosesong ito at kailangan nating iwan ang backward compatibility sa mga lumang API para mapanatiling gumagana ang lahat.

Kasama sa aming mga agarang plano ang pagbuo ng mga bagong connector, pagsasama sa mga bagong system at pagdaragdag ng mga karagdagang sukatan sa set ng data na na-download mula sa mga konektadong site at adserving system.

Plano rin naming ilipat ang lahat ng application, kabilang ang central web application, sa Docker at Kubernetes. Kasama ng bagong arkitektura, ito ay makabuluhang pasimplehin ang deployment, pagsubaybay at kontrol ng mga natupok na mapagkukunan.

Ang isa pang ideya ay mag-eksperimento sa pagpili ng database para sa pag-iimbak ng mga istatistika, na kasalukuyang naka-imbak sa MongoDB. Naglipat na kami ng ilang bagong konektor sa mga database ng SQL, ngunit doon halos hindi napapansin ang pagkakaiba, at para sa pinagsama-samang mga istatistika sa araw, na maaaring hilingin sa isang arbitrary na panahon, ang pakinabang ay maaaring maging seryoso.

Sa pangkalahatan, ang mga plano ay engrande, magpatuloy tayo :)

Mga may-akda ng artikulong R&D Dentsu Aegis Network Russia: Georgy Ostapenko (shmiigaa), Mikhail Kotsik (hitex)

Pinagmulan: www.habr.com