Et schéngt, datt d'Beräich vun Online-Reklammen esou technologesch fortgeschratt an automatiséiert wéi méiglech soll sinn. Natierlech, well esou Risen an Experten an hirem Beräich wéi Yandex, Mail.Ru, Google a Facebook schaffen do. Awer, wéi et sech erausstellt, gëtt et keng Limite fir Perfektioun an et gëtt ëmmer eppes ze automatiséieren.
Kommunikatioun Grupp Dentsu Aegis Network Russland ass de gréisste Spiller am digitale Reklammmaart an investéiert aktiv an Technologie, probéiert seng Geschäftsprozesser ze optimiséieren an ze automatiséieren. Ee vun den ongeléiste Probleemer vum Online Reklammmaart ass d'Aufgab ginn fir Statistiken iwwer Werbekampagnen vu verschiddenen Internetplattformen ze sammelen. D'Léisung fir dëse Problem huet schlussendlech zu der Schafung vun engem Produkt gefouert D1.Digital (liesen als DiVan), d'Entwécklung vun deem mir wëllen schwätzen.
Firwat?
1. Zu der Zäit vum Start vum Projet gouf et net een eenzegt fäerdeg Produkt um Maart, deen de Problem vun der Automatiséierung vun der Sammlung vu Statistiken iwwer Werbekampagnen geléist huet. Dëst bedeit datt keen ausser eis selwer eis Bedierfnesser erfëllt.
Servicer wéi Improvado, Roistat, Supermetrics, SegmentStream bidden Integratioun mat Plattformen, sozialen Netzwierker a Google Analitycs, a maachen et och méiglech analytesch Dashboards ze bauen fir bequem Analyse a Kontroll vu Werbekampagnen. Ier mer ugefaang hunn eise Produkt z'entwéckelen, hu mir probéiert e puer vun dëse Systemer ze benotzen fir Daten vu Site ze sammelen, awer leider konnten se eis Probleemer net léisen.
Den Haaptproblem war datt déi getest Produkter op Datenquellen baséieren, Placementstatistike per Site ugewisen hunn an net d'Fähigkeit ubidden fir Statistiken iwwer Werbekampagnen ze aggregéieren. Dës Approche huet eis net erlaabt Statistike vu verschiddene Siten op enger Plaz ze gesinn an den Zoustand vun der Campagne als Ganzt ze analyséieren.
En anere Faktor war datt an den initialen Etappen d'Produkter op de westleche Maart gezielt waren an d'Integratioun mat russesche Site net ënnerstëtzen. A fir déi Siten mat deenen d'Integratioun ëmgesat gouf, goufen all déi néideg Metriken net ëmmer mat genuch Detail erofgelueden, an d'Integratioun war net ëmmer bequem an transparent, besonnesch wann et néideg war eppes ze kréien wat net an der Systeminterface ass.
Am Allgemengen hu mir décidéiert net un Drëtt-Partei Produkter unzepassen, awer hunn ugefaang eis eegen ze entwéckelen ...
2. Den Online Reklammmaart wiisst vu Joer zu Joer, an 2018, wat d'Reklammbudget ugeet, huet et den traditionell gréissten TV Reklammmaart iwwerholl. Also et gëtt eng Skala.
3. Am Géigesaz zu der TV Reklammen Maart, wou de Verkaf vun kommerziell Reklammen monopoliséiert ass, ginn et vill vun eenzelne Besëtzer vun Annoncen Stamminventar vu verschiddene Gréisste Betribssystemer um Internet mat hiren eegene Reklammen Konte. Well eng Werbekampagne, an der Regel, op e puer Siten gläichzäiteg leeft, fir den Zoustand vun der Werbekampagne ze verstoen, ass et néideg Berichter vun alle Site ze sammelen an se an ee grousse Bericht ze kombinéieren deen dat ganzt Bild weist. Dëst bedeit datt et Potenzial fir Optimisatioun ass.
4. Et huet eis geschéngt, datt d'Propriétairen vun Annoncen Inventar um Internet schonn d'Infrastruktur hunn fir Statistiken ze sammelen an se an Reklammen Konten ze weisen, a si kënnen eng API fir dës Donnéeën ze bidden. Dëst bedeit datt et technesch méiglech ass et ëmzesetzen. Loosst eis direkt soen datt et net sou einfach ass.
Am Allgemengen, all Viraussetzunge fir d'Ëmsetzung vum Projet waren eis offensichtlech, a mir sinn gelaf fir de Projet an d'Liewen ze bréngen ...
Grousse Plang
Fir unzefänken hu mir eng Visioun vun engem ideale System geformt:
- Werbekampagnen aus dem 1C Firmesystem sollten automatesch mat hiren Nimm, Perioden, Budgeten a Placementer op verschiddene Plattformen geluede ginn.
- Fir all Placement bannent enger Werbekampagne sollen all méiglech Statistike automatesch vun de Site erofgeluede ginn, wou d'Placement stattfënnt, wéi d'Zuel vun den Andréck, Klicks, Meenungen, etc.
- E puer Werbekampagnen ginn verfollegt mat Drëtt-Partei-Iwwerwaachung vu sougenannten Adserving-Systemer wéi Adriver, Weborama, DCM, etc. Et gëtt och en industriellen Internet Meter a Russland - d'Firma Mediascope. Eisem Plang sollen och Daten aus onofhängegen an industrieller Iwwerwaachung automatesch an déi entspriechend Werbekampagnen geluede ginn.
- Déi meescht Werbekampagnen um Internet riichten sech op bestëmmten Zilaktiounen (Kaafen, ruffen, umellen fir en Testfahrt, asw.), déi mat Google Analytics verfollegt ginn, a Statistike fir déi och wichteg sinn fir de Status vun der Campagne ze verstoen an ze verstoen. soll an eisem Tool gelueden ginn.
Déi éischt Pikaneki ass e klengen
Wéinst eisem Engagement fir flexibel Prinzipien vun der Softwareentwécklung (agil, alles), hu mir beschloss fir d'éischt e MVP z'entwéckelen an dann iterativ op dat virgesinnt Zil ze bewegen.
Mir hu beschloss MVP op Basis vun eisem Produkt ze bauen DANBo (Dentsu Aegis Network Board), dat ass eng Webapplikatioun mat allgemenger Informatioun iwwer d'Werbekampagnen vun eise Clienten.
Fir MVP gouf de Projet sou vill wéi méiglech a punkto Ëmsetzung vereinfacht. Mir hunn eng limitéiert Lëscht vu Plattforme fir Integratioun ausgewielt. Dëst waren d'Haaptplattformen, wéi Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, an d'Haaptreklamesystemer Adriver a Weborama.
Fir Zougang zu Statistiken op Siten iwwer d'API ze kréien, hu mir en eenzege Kont benotzt. E Client Group Manager, deen d'automatesch Sammlung vu Statistiken op enger Werbekampagne benotze wollt, huet fir d'éischt den Zougang zu den néidege Werbekampagnen op Siten op de Plattformkonto delegéiert.
Als nächst ass de System Benotzer DANBo hu missen e Fichier vun engem bestëmmte Format an den Excel System eroplueden, deen all Informatioun iwwer d'Placement (Werbekampagne, Plattform, Format, Plazéierungsperiod, geplangten Indikatoren, Budget, asw.) an Identifizéierer vun den entspriechende Werbekampagnen op der Siten a counters an adserving Systemer.
Et huet, éierlech gesot, erschreckend ausgesinn:
D'erofgeluede Donnéeën goufen an enger Datebank gespäichert, an dann getrennt Servicer gesammelt Campagne Identifizéierer op Siten vun hinnen an erofgeluede Statistiken op hinnen.
Fir all Site gouf e separaten Windows-Service geschriwwen, deen eemol am Dag ënner engem Servicekonto an der API vum Site gaang ass an Statistike fir spezifizéiert Kampagne-IDen erofgelueden huet. Datselwecht ass geschitt mat Adserving Systemer.
Déi erofgeluede Donnéeën goufen op der Interface a Form vun engem klenge personaliséierten Dashboard ugewisen:
Onerwaart fir eis huet MVP ugefaang ze schaffen an ugefaang aktuell Statistiken iwwer Werbekampagnen um Internet erofzelueden. Mir hunn de System op e puer Clienten ëmgesat, awer wa mir probéiert hunn ze skaléieren, hu mir sérieux Probleemer begéint:
- Den Haaptproblem war d'Komplexitéit vun der Virbereedung vun Daten fir d'Luede an de System. Och d'Plazéierungsdaten hu missen an e strikt fixe Format ëmgewandelt ginn ier d'Luede gelueden ginn. Et war néideg Entitéitsidentifizéierer vu verschiddene Site an der Downloaddatei opzehuelen. Mir sinn konfrontéiert mat der Tatsaach, datt et fir technesch ongebilte Benotzer ganz schwéier ass ze erklären, wou dës Identifizéierer um Site ze fannen a wou an der Datei se aginn musse ginn. Bedenkt datt d'Zuel vun de Mataarbechter an den Departementer déi Campagnen op Siten maachen an den Ëmsaz, huet dat zu enger enormer Ënnerstëtzung vun eiser Säit gefouert, mat deem mir absolut net zefridde waren.
- En anere Problem war datt net all Werbeplattformen Mechanismen haten fir den Zougang zu Werbekampagnen op aner Konten ze delegéieren. Awer och wann en Delegatiounsmechanismus verfügbar war, waren net all Annonceuren gewëllt Zougang zu hire Kampagnen op Drëtt Partei Konten ze ginn.
- E wichtege Faktor war d'Indignatioun, déi ënnert de Benotzer opgeworf gouf duerch d'Tatsaach, datt all déi geplangten Indikatoren an d'Placementdetailer, déi se schonn an eisem 1C Comptablesmethodsystem aginn, mussen se erëm aginn. DANBo.
Dëst huet eis d'Iddi ginn, datt déi primär Informatiounsquell iwwer d'Placement eise 1C System sollt sinn, an deem all Donnéeën präzis an op Zäit agefouert ginn (de Punkt hei ass datt d'Rechnungen op Basis vun 1C Daten generéiert ginn, sou datt d'korrekt Entree vun den Donnéeën an 1C ass eng Prioritéit fir jiddereen KPI). Dëst ass wéi en neit Konzept vum System entstanen ass ...
Konzept
Déi éischt Saach, déi mir decidéiert hunn ze maachen, war de System fir Statistiken iwwer Werbekampagnen um Internet ze trennen an e separat Produkt - D1.Digital.
Am neie Konzept hu mir beschloss ze lueden D1.Digital Informatioun iwwer Werbekampagnen a Placementer bannent hinnen aus 1C, an zitt dann Statistike vu Siten an AdServing Systemer op dës Plazen op. Dëst sollt d'Liewen fir d'Benotzer wesentlech vereinfachen (a wéi gewinnt méi Aarbecht un d'Entwéckler bäidroen) an d'Quantitéit vun der Ënnerstëtzung reduzéieren.
Den éischte Problem, dee mir begéint hunn, war vun enger organisatorescher Natur a war am Zesummenhang mat der Tatsaach, datt mir kee Schlëssel oder Zeechen fanne konnten, duerch déi mir Entitéite vu verschiddene Systemer mat Kampagnen a Placementer aus 1C vergläichen. D'Tatsaach ass datt de Prozess an eiser Gesellschaft esou entworf ass datt Werbekampagnen a verschiddene Systemer vu verschiddene Leit (Medienplaner, Kaaf, asw.) agefouert ginn.
Fir dëse Problem ze léisen, hu mir missen en eenzegaartegen hashed Schlëssel erfannen, DANBoID, deen Entitéite a verschiddene Systemer matenee verbënnt, an deen zimlech einfach an eenzegaarteg an erofgeluede Datesets identifizéiert ka ginn. Dësen Identifizéierer gëtt am internen 1C System fir all eenzel Placement generéiert a gëtt op Kampagnen, Placementer a Konter op all Site an an all AdServing Systemer transferéiert. D'Ëmsetzung vun der Praxis fir DANBoID an all Placementer ze setzen huet e bëssen Zäit gedauert, awer mir hunn et fäerdeg bruecht et ze maachen :)
Duerno hu mir erausfonnt datt net all Site eng API hunn fir automatesch Statistiken ze sammelen, an och déi déi eng API hunn, et gëtt net all déi néideg Donnéeën zréck.
Op dëser Etapp hu mir décidéiert d'Lëscht vun de Plattformen fir d'Integratioun wesentlech ze reduzéieren an op d'Haaptplattformen ze fokusséieren, déi an der grousser Majoritéit vu Werbekampagnen involvéiert sinn. Dës Lëscht enthält all déi gréisste Spiller am Reklammmaart (Google, Yandex, Mail.ru), sozial Netzwierker (VK, Facebook, Twitter), grouss AdServing an Analysesystemer (DCM, Adriver, Weborama, Google Analytics) an aner Plattformen.
D'Majoritéit vun de Site déi mir gewielt hunn, haten eng API déi d'Metriken ubitt déi mir gebraucht hunn. A Fäll wou et keng API gouf oder et net déi néideg Donnéeën enthält, hu mir Berichter benotzt, déi all Dag un eise Büro E-Mail geschéckt goufen, fir Daten ze lueden (a verschiddene Systemer ass et méiglech esou Berichter ze konfiguréieren, an anerer hu mir eis iwwer d'Entwécklung vun esou Berichter ausgemaach. fir eis).
Wann Dir Daten aus verschiddene Siten analyséiert, hu mir erausfonnt datt d'Hierarchie vun den Entitéiten net déiselwecht a verschiddene Systemer ass. Ausserdeem muss Informatioun a verschiddenen Detail vu verschiddene Systemer erofgeluede ginn.
Fir dëse Problem ze léisen, gouf d'SubDANBoID Konzept entwéckelt. D'Iddi vum SubDANBoID ass zimmlech einfach, mir markéieren d'Haaptentitéit vun der Kampagne um Site mam generéierten DANBoID, a mir lueden all nested Entitéite mat eenzegaartege Site Identifizéierer erop a bilden SubDANBoID no dem DANBoID Prinzip + Identifizéierer vum éischte Niveau nest Entity + Identifizéierer vun der zweeter Niveau nest Entity +... Dës Approche huet eis erlaabt Reklammekampagnen a verschiddene Systemer ze verbannen an detailléiert Statistiken doriwwer ze downloaden.
Mir hunn och de Problem vum Zougang zu Campagnen op verschiddene Plattformen ze léisen. Wéi mir uewen geschriwwen hunn, ass de Mechanismus fir den Zougang zu enger Campagne op e separaten technesche Kont ze delegéieren net ëmmer applicabel. Dofir hu mir eng Infrastruktur fir automatesch Autorisatioun iwwer OAuth missen entwéckelen mat Tokens a Mechanismen fir dës Tokens ze aktualiséieren.
Méi spéit am Artikel wäerte mir probéieren méi detailléiert d'Architektur vun der Léisung an d'technesch Detailer vun der Ëmsetzung ze beschreiwen.
Léisungsarchitektur 1.0
Beim Start vun der Implementatioun vun engem neie Produkt hu mir verstanen datt mir direkt d'Méiglechkeet hunn fir nei Site ze verbannen, also hu mir décidéiert de Wee vun der Mikroservicearchitektur ze verfollegen.
Beim Design vun der Architektur hu mir Connectoren op all extern Systemer getrennt - 1C, Werbeplattformen a Reklammsystemer - an getrennte Servicer.
D'Haaptidee ass datt all Connectoren op Siten déiselwecht API hunn a sinn Adapter déi de Site API op eng Interface bréngen déi fir eis bequem ass.
Am Zentrum vun eisem Produkt ass eng Webapplikatioun, déi e Monolith ass, deen esou entworf ass datt et einfach a Servicer ofgebaut ka ginn. Dës Applikatioun ass verantwortlech fir d'Veraarbechtung vun den erofgelueden Donnéeën, d'Statistike vu verschiddene Systemer ze sammelen a se dem System Benotzer ze presentéieren.
Fir tëscht de Connectoren an der Webapplikatioun ze kommunizéieren, hu mir missen en zousätzleche Service erstellen, dee mir Connector Proxy genannt hunn. Et mécht d'Funktioune vum Service Discovery an Task Scheduler aus. Dëse Service leeft Datensammlungsaufgaben fir all Connector all Nuecht. Eng Service Layer ze schreiwen war méi einfach wéi e Message Broker ze verbannen, a fir eis war et wichteg d'Resultat esou séier wéi méiglech ze kréien.
Fir Simplicitéit a Geschwindegkeet vun der Entwécklung hu mir och decidéiert datt all Servicer Web APIe sinn. Dëst huet et méiglech gemaach fir séier e proof-of-concept ze sammelen an z'iwwerpréiwen datt de ganzen Design funktionnéiert.
Eng separat, zimlech komplex Aufgab war den Accès opzebauen fir Daten aus verschiddene Konten ze sammelen, déi, wéi mir decidéiert hunn, vun de Benotzer iwwer d'Webinterface ausgefouert ginn. Et besteet aus zwee getrennte Schrëtt: als éischt füügt de Benotzer en Token derbäi fir op de Kont iwwer OAuth ze kommen, a konfiguréiert dann d'Sammlung vun Daten fir de Client aus engem spezifesche Kont. En Token iwwer OAuth ze kréien ass néideg well, wéi mir scho geschriwwen hunn, et net ëmmer méiglech ass den Zougang zum gewënschten Kont um Site ze delegéieren.
Fir en universelle Mechanismus ze kreéieren fir e Kont vu Site ze wielen, hu mir eng Method un de Connector API bäigefüügt, déi de JSON Schema zréckginn, deen an eng Form mat enger modifizéierter JSONEditor Komponent ofgeleet gëtt. Op dës Manéier konnten d'Benotzer d'Konten auswielen, aus deenen d'Daten eroflueden.
Fir d'Ufrolimiten ze respektéieren déi op Siten existéieren, kombinéiere mir Ufroe fir Astellunge bannent engem Token, awer mir kënne verschidde Token parallel veraarbecht.
Mir hunn MongoDB als Späichere fir gelueden Donnéeën fir d'Webapplikatioun a fir Connectoren gewielt, wat eis erlaabt eis net ze vill iwwer d'Datenstruktur an den initialen Etappe vun der Entwécklung ze këmmeren, wann den Objektmodell vun der Applikatioun all aneren Dag ännert.
Mir hu séier erausfonnt datt net all Daten gutt an MongoDB passen an zum Beispill et ass méi bequem fir alldeeglech Statistiken an enger relationaler Datebank ze späicheren. Dofir, fir Connectoren deenen hir Datestruktur méi gëeegent ass fir eng relational Datebank, hu mir ugefaang PostgreSQL oder MS SQL Server als Späichere ze benotzen.
Déi gewielte Architektur an Technologien hunn eis erlaabt den D1.Digital Produkt relativ séier ze bauen an ze lancéieren. Iwwer zwee Joer vun der Produktentwécklung hu mir 23 Connectoren op Siten entwéckelt, wäertvoll Erfarung gewonnen mat Drëtt-Partei APIen ze schaffen, geléiert d'Feele vu verschiddene Siten ze vermeiden, déi jidderee seng eegen haten, huet zu der Entwécklung vun der API vun op d'mannst 3 bäigedroen. Siten, automatesch erofgeluede Informatiounen iwwert bal 15 Campagnen a fir méi wéi 000 Placementer, gesammelt vill vun Feedback vun Benotzer op d'Operatioun vum Produit a konnt den Haaptgrond Prozess vun der Produit puer mol änneren, baséiert op dëser Feedback.
Léisungsarchitektur 2.0
Zwee Joer sinn zënter dem Ufank vun der Entwécklung vergaangen D1.Digital. D'konstante Erhéijung vun der Laascht op de System an d'Entstoe vu méi a méi nei Datequellen huet lues a lues Problemer an der existéierender Léisungsarchitektur opgedeckt.
Den éischte Problem ass am Zesummenhang mat der Quantitéit vun Daten aus de Siten erofgeluede. Mir ware mat der Tatsaach konfrontéiert datt d'Sammelen an d'Aktualiséierung vun all néideg Donnéeën vun de gréisste Siten ugefaang ze vill Zäit ze huelen. Zum Beispill, Daten aus dem AdRiver Adserving System sammelen, mat deem mir Statistike fir déi meescht Placementer verfollegen, dauert ongeféier 12 Stonnen.
Fir dëse Problem ze léisen, hu mir ugefaang all Zorte vu Berichter ze benotzen fir Daten aus Siten erofzelueden, mir probéieren hir API zesumme mat de Siten z'entwéckelen, sou datt d'Geschwindegkeet vu senger Operatioun eise Bedierfnesser entsprécht, an d'Daten eroflueden sou vill wéi méiglech parallel.
En anere Problem bezitt sech op d'Veraarbechtung vun den erofgeluede Donnéeën. Elo, wann nei Plazéierungsstatistiken ukommen, gëtt e Multi-Stage-Prozess fir Metriken nei ze berechnen lancéiert, deen d'Rohdaten lueden, d'aggregéiert Metriken fir all Site berechnen, Daten aus verschiddene Quelle matenee vergläichen, a Resumémetriken fir d'Campagne berechnen. Dëst verursaacht vill Laascht op der Webapplikatioun déi all d'Berechnungen mécht. E puer Mol, während dem Ëmberechnungsprozess, huet d'Applikatioun all d'Erënnerung um Server verbraucht, ongeféier 10-15 GB, wat de schiedlechsten Effekt op d'Aarbecht vun de Benotzer mam System hat.
Déi identifizéiert Probleemer an ambitiéis Pläng fir d'Weiderentwécklung vum Produkt hunn eis zu der Bedierfnes fir d'Applikatiounsarchitektur ze iwwerdenken.
Mir hunn ugefaang mat Stecker.
Mir hu gemierkt datt all Stecker no dem selwechte Modell funktionnéieren, also hu mir e Pipeline-Framework gebaut, an deem Dir e Connector erstellt, musst Dir nëmmen d'Logik vun de Schrëtt programméieren, de Rescht war universell. Wann e puer Connector Verbesserung erfuerdert, da transferéiere mir et direkt an en neie Kader zur selwechter Zäit wéi de Connector verbessert gëtt.
Zur selwechter Zäit hu mir ugefaang Connectoren op Docker a Kubernetes z'installéieren.
Mir hunn de Beweegung op Kubernetes fir eng zimlech laang Zäit geplangt, experimentéiert mat CI / CD Astellungen, awer ugefaang nëmmen ze beweegen wann ee Connector, wéinst engem Feeler, ugefaang huet méi wéi 20 GB Erënnerung um Server ze iessen, praktesch aner Prozesser ëmbréngen . Wärend der Enquête gouf de Connector an e Kubernetes-Cluster geplënnert, wou et schlussendlech bliwwen ass, och nodeems de Feeler fixéiert gouf.
Zimlech séier hu mir gemierkt datt Kubernetes praktesch war, a bannent sechs Méint hu mir 7 Connectoren a Connectors Proxy transferéiert, déi déi meeschte Ressourcen verbrauchen, an de Produktiounscluster.
No de Stecker hu mir décidéiert d'Architektur vum Rescht vun der Applikatioun z'änneren.
Den Haaptproblem war datt d'Donnéeë vu Stecker op Proxyen a grousse Chargen kommen, an dann op den DANBoID schloen an an d'Zentral Webapplikatioun fir d'Veraarbechtung geschéckt ginn. Wéinst der grousser Unzuel u Metriken-Recalculatioune gëtt et eng grouss Laascht op d'Applikatioun.
Et huet sech och zimmlech schwéier bewisen de Status vun eenzelnen Datesammlungsjobs ze iwwerwaachen a Feeler ze mellen, déi bannent Connectoren op eng zentral Webapplikatioun geschéien, sou datt d'Benotzer kënne gesinn wat geschitt a firwat Daten net gesammelt goufen.
Fir dës Problemer ze léisen, hu mir Architektur 2.0 entwéckelt.
Den Haaptunterschied tëscht der neier Versioun vun der Architektur ass datt amplaz vun der Web API, mir RabbitMQ an der MassTransit Bibliothéik benotze fir Messagen tëscht Servicer auszetauschen. Fir dëst ze maachen, hu mir de Connectors Proxy bal komplett nei schreiwen, sou datt et Connectors Hub ass. Den Numm gouf geännert well d'Haaptroll vum Service net méi ass fir Ufroe fir Connectoren an zréck ze schécken, mee an der Gestioun vun der Sammlung vu Metriken vu Connectoren.
Vun der zentraler Webapplikatioun hu mir Informatioun iwwer Placementer a Statistike vu Site an getrennten Servicer getrennt, wat et méiglech gemaach huet, onnéideg Neiberechnungen lass ze ginn an nëmmen schonn berechent a aggregéiert Statistiken um Placementniveau ze späicheren. Mir hunn och d'Logik nei geschriwwen an optimiséiert fir Basisstatistiken op Basis vu Matière Daten ze berechnen.
Zur selwechter Zäit migréiere mir all Servicer an Uwendungen op Docker a Kubernetes fir d'Léisung méi einfach ze skaléieren a méi bequem ze managen.
Wou si mer elo
Proof-of-Concept Architektur 2.0 Produkt D1.Digital prett a schafft an engem Testëmfeld mat enger limitéierter Set vu Stecker. Alles wat iwwreg bleift ass nach 20 Connectoren op eng nei Plattform ëmzeschreiwen, ze testen datt d'Donnéeën richteg gelueden sinn an all Metriken richteg berechent sinn, an de ganzen Design an d'Produktioun ausrollen.
Tatsächlech wäert dëse Prozess graduell geschéien a mir musse Réckkompatibilitéit mat alen APIen verloossen fir alles ze halen.
Eis direkt Pläng enthalen d'Entwécklung vun neie Connectoren, d'Integratioun mat neie Systemer an d'Addéiere vun zousätzleche Metriken un d'Set vun Daten erofgeluede vu verbonne Siten a Reklammsystemer.
Mir plangen och all Applikatiounen, och déi zentral Webapplikatioun, op Docker a Kubernetes ze transferéieren. Kombinéiert mat der neier Architektur wäert dëst d'Deployment, d'Iwwerwaachung an d'Kontroll vu verbrauchte Ressourcen wesentlech vereinfachen.
Eng aner Iddi ass ze experimentéieren mat der Auswiel vun der Datebank fir Statistiken ze späicheren, déi am Moment am MongoDB gespäichert ass. Mir hunn schonn e puer nei Connectoren op SQL Datenbanken transferéiert, awer do ass den Ënnerscheed bal net bemierkbar, a fir aggregéiert Statistike vum Dag, déi fir eng arbiträr Period ugefrot kënne ginn, kann de Gewënn zimlech sérieux sinn.
Allgemeng sinn d'Pläng grandios, loosst eis weidergoen :)
Auteuren vum Artikel R&D Dentsu Aegis Network Russland: Georgy Ostapenko (), Mikhail Kotsik ()
Source: will.com