ఆన్‌లైన్ ప్రకటనల రంగం సాంకేతికంగా అభివృద్ధి చెందినదిగా మరియు సాధ్యమైనంత స్వయంచాలకంగా ఉండాలని అనిపిస్తుంది. వాస్తవానికి, Yandex, Mail.Ru, Google మరియు Facebook వంటి వారి రంగంలో దిగ్గజాలు మరియు నిపుణులు అక్కడ పని చేస్తారు. కానీ, అది ముగిసినట్లుగా, పరిపూర్ణతకు పరిమితి లేదు మరియు ఆటోమేట్ చేయడానికి ఎల్లప్పుడూ ఏదో ఉంటుంది.
కమ్యూనికేషన్ల సమూహం Dentsu Aegis నెట్వర్క్ రష్యా డిజిటల్ అడ్వర్టైజింగ్ మార్కెట్లో అతిపెద్ద ఆటగాడు మరియు సాంకేతికతలో చురుకుగా పెట్టుబడి పెడుతోంది, దాని వ్యాపార ప్రక్రియలను ఆప్టిమైజ్ చేయడానికి మరియు ఆటోమేట్ చేయడానికి ప్రయత్నిస్తోంది. వివిధ ఇంటర్నెట్ ప్లాట్‌ఫారమ్‌ల నుండి ప్రకటనల ప్రచారాలపై గణాంకాలను సేకరించడం ఆన్‌లైన్ ప్రకటనల మార్కెట్ యొక్క పరిష్కరించని సమస్యలలో ఒకటి. ఈ సమస్యకు పరిష్కారం చివరికి ఉత్పత్తిని సృష్టించింది D1.డిజిటల్ (దివాన్‌గా చదవండి), దీని అభివృద్ధి గురించి మనం మాట్లాడాలనుకుంటున్నాము.
ఎందుకు?
1. ప్రాజెక్ట్ ప్రారంభమయ్యే సమయంలో, ప్రకటనల ప్రచారాలపై గణాంకాల సేకరణను ఆటోమేట్ చేసే సమస్యను పరిష్కరించే ఒక్క రెడీమేడ్ ఉత్పత్తి కూడా మార్కెట్లో లేదు. అంటే మనం తప్ప ఎవరూ మన అవసరాలను తీర్చలేరు.
Improvado, Roistat, Supermetrics, SegmentStream వంటి సేవలు ప్లాట్‌ఫారమ్‌లు, సోషల్ నెట్‌వర్క్‌లు మరియు Google Analyticsతో ఏకీకరణను అందిస్తాయి మరియు అనుకూలమైన విశ్లేషణ మరియు ప్రకటనల ప్రచారాల నియంత్రణ కోసం విశ్లేషణాత్మక డాష్‌బోర్డ్‌లను రూపొందించడాన్ని కూడా సాధ్యం చేస్తాయి. మేము మా ఉత్పత్తిని అభివృద్ధి చేయడం ప్రారంభించే ముందు, మేము సైట్‌ల నుండి డేటాను సేకరించడానికి ఈ సిస్టమ్‌లలో కొన్నింటిని ఉపయోగించడానికి ప్రయత్నించాము, కానీ, దురదృష్టవశాత్తు, అవి మా సమస్యలను పరిష్కరించలేకపోయాయి.
ప్రధాన సమస్య ఏమిటంటే, పరీక్షించబడిన ఉత్పత్తులు డేటా మూలాధారాలపై ఆధారపడి ఉంటాయి, సైట్ వారీగా ప్లేస్‌మెంట్ గణాంకాలను ప్రదర్శిస్తాయి మరియు ప్రకటనల ప్రచారాలపై గణాంకాలను సమగ్రపరిచే సామర్థ్యాన్ని అందించలేదు. ఈ విధానం వివిధ సైట్‌ల నుండి గణాంకాలను ఒకే చోట చూడటానికి మరియు మొత్తం ప్రచారం యొక్క స్థితిని విశ్లేషించడానికి మాకు అనుమతించలేదు.
మరొక అంశం ఏమిటంటే, ప్రారంభ దశలలో ఉత్పత్తులు పాశ్చాత్య మార్కెట్‌ను లక్ష్యంగా చేసుకున్నాయి మరియు రష్యన్ సైట్‌లతో ఏకీకరణకు మద్దతు ఇవ్వలేదు. మరియు ఇంటిగ్రేషన్ అమలు చేయబడిన సైట్‌ల కోసం, అవసరమైన అన్ని కొలమానాలు ఎల్లప్పుడూ తగినంత వివరాలతో డౌన్‌లోడ్ చేయబడవు మరియు ఇంటిగ్రేషన్ ఎల్లప్పుడూ సౌకర్యవంతంగా మరియు పారదర్శకంగా ఉండదు, ప్రత్యేకించి సిస్టమ్ ఇంటర్‌ఫేస్‌లో లేనిదాన్ని పొందడం అవసరం.
సాధారణంగా, మేము మూడవ పక్ష ఉత్పత్తులకు అనుగుణంగా ఉండకూడదని నిర్ణయించుకున్నాము, కానీ మా స్వంతంగా అభివృద్ధి చేయడం ప్రారంభించాము...
2. ఆన్‌లైన్ ప్రకటనల మార్కెట్ సంవత్సరానికి పెరుగుతోంది మరియు 2018లో, ప్రకటనల బడ్జెట్‌ల పరంగా, ఇది సాంప్రదాయకంగా అతిపెద్ద TV ప్రకటనల మార్కెట్‌ను అధిగమించింది. కాబట్టి ఒక స్థాయి ఉంది.
3. TV ప్రకటనల మార్కెట్ వలె కాకుండా, వాణిజ్య ప్రకటనల అమ్మకం గుత్తాధిపత్యం కలిగి ఉంది, వారి స్వంత ప్రకటనల ఖాతాలతో ఇంటర్నెట్‌లో పనిచేసే వివిధ పరిమాణాల ప్రకటనల జాబితా యొక్క వ్యక్తిగత యజమానులు చాలా మంది ఉన్నారు. ప్రకటనల ప్రచారం, ఒక నియమం వలె, అనేక సైట్‌లలో ఒకేసారి నడుస్తుంది కాబట్టి, ప్రకటనల ప్రచారం యొక్క స్థితిని అర్థం చేసుకోవడానికి, అన్ని సైట్‌ల నుండి నివేదికలను సేకరించి, మొత్తం చిత్రాన్ని చూపించే ఒక పెద్ద నివేదికగా వాటిని కలపడం అవసరం. దీని అర్థం ఆప్టిమైజేషన్ కోసం సంభావ్యత ఉంది.
4. ఇంటర్నెట్‌లోని ప్రకటనల జాబితా యజమానులు ఇప్పటికే గణాంకాలను సేకరించి వాటిని ప్రకటనల ఖాతాలలో ప్రదర్శించడానికి మౌలిక సదుపాయాలను కలిగి ఉన్నారని మరియు వారు ఈ డేటా కోసం APIని అందించగలరని మాకు అనిపించింది. అంటే సాంకేతికంగా దీన్ని అమలు చేయడం సాధ్యమవుతుంది. ఇది అంత సులభం కాదని వెంటనే చెప్పండి.
సాధారణంగా, ప్రాజెక్ట్ అమలుకు అవసరమైన అన్ని అవసరాలు మాకు స్పష్టంగా ఉన్నాయి మరియు మేము ప్రాజెక్ట్‌కు జీవం పోయడానికి పరిగెత్తాము ...
భారీ ప్రణాళిక
ప్రారంభించడానికి, మేము ఆదర్శ వ్యవస్థ యొక్క దృష్టిని రూపొందించాము:
- 1C కార్పొరేట్ సిస్టమ్ నుండి ప్రకటనల ప్రచారాలు వాటి పేర్లు, కాలాలు, బడ్జెట్‌లు మరియు వివిధ ప్లాట్‌ఫారమ్‌లలోని ప్లేస్‌మెంట్‌లతో స్వయంచాలకంగా లోడ్ చేయబడాలి.
- ప్రకటనల ప్రచారంలోని ప్రతి ప్లేస్‌మెంట్ కోసం, ప్లేస్‌మెంట్ జరుగుతున్న సైట్‌ల నుండి ఇంప్రెషన్‌ల సంఖ్య, క్లిక్‌లు, వీక్షణలు మొదలైన వాటి నుండి సాధ్యమయ్యే అన్ని గణాంకాలు స్వయంచాలకంగా డౌన్‌లోడ్ చేయబడాలి.
- Adriver, Weborama, DCM మొదలైన ప్రకటనల వ్యవస్థలు అని పిలవబడే ద్వారా మూడవ పక్ష పర్యవేక్షణను ఉపయోగించి కొన్ని ప్రకటనల ప్రచారాలు ట్రాక్ చేయబడతాయి. రష్యాలో పారిశ్రామిక ఇంటర్నెట్ మీటర్ కూడా ఉంది - మీడియాస్కోప్ కంపెనీ. మా ప్లాన్ ప్రకారం, స్వతంత్ర మరియు పారిశ్రామిక పర్యవేక్షణ నుండి డేటా కూడా సంబంధిత ప్రకటనల ప్రచారాలలోకి స్వయంచాలకంగా లోడ్ చేయబడాలి.
- ఇంటర్నెట్‌లోని చాలా ప్రకటనల ప్రచారాలు నిర్దిష్ట లక్ష్య చర్యలను (కొనుగోలు చేయడం, కాల్ చేయడం, టెస్ట్ డ్రైవ్ కోసం సైన్ అప్ చేయడం మొదలైనవి) లక్ష్యంగా ఉంటాయి, వీటిని Google Analytics ఉపయోగించి ట్రాక్ చేస్తారు మరియు ప్రచారం యొక్క స్థితిని అర్థం చేసుకోవడానికి కూడా ముఖ్యమైన గణాంకాలు మరియు గణాంకాలు మన టూల్ లోకి లోడ్ చేయాలి .
మొదటి తిట్టు ముద్దగా ఉంది
సాఫ్ట్‌వేర్ డెవలప్‌మెంట్ (చురుకైన, అన్ని విషయాలు) యొక్క అనువైన సూత్రాలకు మా నిబద్ధత కారణంగా, మేము మొదట MVPని అభివృద్ధి చేసి, ఆపై ఉద్దేశించిన లక్ష్యం వైపు పునరుక్తిగా వెళ్లాలని నిర్ణయించుకున్నాము.
మేము మా ఉత్పత్తి ఆధారంగా MVPని నిర్మించాలని నిర్ణయించుకున్నాము DANBo (Dentsu Aegis నెట్వర్క్ బోర్డ్), ఇది మా క్లయింట్‌ల ప్రకటనల ప్రచారాలపై సాధారణ సమాచారంతో కూడిన వెబ్ అప్లికేషన్.
MVP కోసం, ప్రాజెక్ట్ అమలు పరంగా వీలైనంత సరళీకృతం చేయబడింది. మేము ఇంటిగ్రేషన్ కోసం పరిమిత ప్లాట్‌ఫారమ్‌ల జాబితాను ఎంచుకున్నాము. ఇవి Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB మరియు ప్రధాన ప్రకటన వ్యవస్థలు Adriver మరియు Weborama వంటి ప్రధాన ప్లాట్‌ఫారమ్‌లు.
API ద్వారా సైట్‌లలో గణాంకాలను యాక్సెస్ చేయడానికి, మేము ఒకే ఖాతాను ఉపయోగించాము. ప్రకటనల ప్రచారంలో గణాంకాల యొక్క స్వయంచాలక సేకరణను ఉపయోగించాలనుకునే క్లయింట్ సమూహ నిర్వాహకుడు ముందుగా ప్లాట్‌ఫారమ్ ఖాతాకు సైట్‌లలో అవసరమైన ప్రకటనల ప్రచారాలకు యాక్సెస్‌ను అప్పగించవలసి ఉంటుంది.
తదుపరిది సిస్టమ్ వినియోగదారు DANBo ఎక్సెల్ సిస్టమ్‌లోకి ఒక నిర్దిష్ట ఫార్మాట్ యొక్క ఫైల్‌ను అప్‌లోడ్ చేయాల్సి వచ్చింది, ఇందులో ప్లేస్‌మెంట్ (ప్రకటనల ప్రచారం, ప్లాట్‌ఫారమ్, ఫార్మాట్, ప్లేస్‌మెంట్ వ్యవధి, ప్రణాళికాబద్ధమైన సూచికలు, బడ్జెట్ మొదలైనవి) మరియు సంబంధిత ప్రకటనల ప్రచారాల ఐడెంటిఫైయర్‌ల గురించిన మొత్తం సమాచారం ఉంటుంది. ప్రకటన వ్యవస్థలలో సైట్లు మరియు కౌంటర్లు.
ఇది స్పష్టంగా, భయంకరంగా కనిపించింది:
డౌన్‌లోడ్ చేయబడిన డేటా డేటాబేస్‌లో సేవ్ చేయబడింది, ఆపై ప్రత్యేక సేవలు వాటి నుండి సైట్‌లలో ప్రచార ఐడెంటిఫైయర్‌లను సేకరించి వాటిపై గణాంకాలను డౌన్‌లోడ్ చేస్తాయి.
ప్రతి సైట్ కోసం, ఒక ప్రత్యేక విండోస్ సేవ వ్రాయబడింది, ఇది సైట్ యొక్క APIలోని ఒక సేవా ఖాతా కింద రోజుకు ఒకసారి వెళ్లి, పేర్కొన్న ప్రచార IDల కోసం గణాంకాలను డౌన్‌లోడ్ చేస్తుంది. ప్రకటన వ్యవస్థల విషయంలో కూడా అదే జరిగింది.
డౌన్‌లోడ్ చేయబడిన డేటా ఇంటర్‌ఫేస్‌లో చిన్న అనుకూల డాష్‌బోర్డ్ రూపంలో ప్రదర్శించబడుతుంది:
మాకు ఊహించని విధంగా, MVP పని చేయడం ప్రారంభించింది మరియు ఇంటర్నెట్‌లో ప్రకటనల ప్రచారాలపై ప్రస్తుత గణాంకాలను డౌన్‌లోడ్ చేయడం ప్రారంభించింది. మేము అనేక క్లయింట్‌లపై సిస్టమ్‌ను అమలు చేసాము, కానీ స్కేల్ చేయడానికి ప్రయత్నిస్తున్నప్పుడు, మేము తీవ్రమైన సమస్యలను ఎదుర్కొన్నాము:
- సిస్టమ్‌లోకి లోడ్ చేయడానికి డేటాను సిద్ధం చేసే సంక్లిష్టత ప్రధాన సమస్య. అలాగే, ప్లేస్‌మెంట్ డేటాను లోడ్ చేయడానికి ముందు ఖచ్చితంగా స్థిరమైన ఆకృతికి మార్చాలి. డౌన్‌లోడ్ ఫైల్‌లో వివిధ సైట్‌ల నుండి ఎంటిటీ ఐడెంటిఫైయర్‌లను చేర్చడం అవసరం. సాంకేతికంగా శిక్షణ లేని వినియోగదారులు సైట్‌లో ఈ ఐడెంటిఫైయర్‌లను ఎక్కడ కనుగొనాలో మరియు ఫైల్‌లో ఎక్కడ నమోదు చేయాలో వివరించడం చాలా కష్టం అనే వాస్తవాన్ని మేము ఎదుర్కొంటున్నాము. సైట్‌లలో ప్రచారాలు నిర్వహిస్తున్న డిపార్ట్‌మెంట్‌లలోని ఉద్యోగుల సంఖ్య మరియు టర్నోవర్‌ను పరిగణనలోకి తీసుకుంటే, దీని ఫలితంగా మా వైపు నుండి భారీ మొత్తంలో మద్దతు లభించింది, దీనితో మేము పూర్తిగా సంతోషంగా లేము.
- మరో సమస్య ఏమిటంటే, అన్ని అడ్వర్టైజింగ్ ప్లాట్‌ఫారమ్‌లు ఇతర ఖాతాలకు అడ్వర్టైజింగ్ క్యాంపెయిన్‌లకు యాక్సెస్‌ను డెలిగేట్ చేయడానికి మెకానిజమ్‌లను కలిగి ఉండవు. కానీ ప్రతినిధి బృందం అందుబాటులో ఉన్నప్పటికీ, ప్రకటనకర్తలందరూ మూడవ పక్షం ఖాతాలకు తమ ప్రచారాలకు యాక్సెస్‌ను మంజూరు చేయడానికి సిద్ధంగా లేరు.
- ఒక ముఖ్యమైన అంశం ఏమిటంటే, మా 1C అకౌంటింగ్ సిస్టమ్‌లోకి వారు ఇప్పటికే నమోదు చేసిన అన్ని ప్రణాళికాబద్ధమైన సూచికలు మరియు ప్లేస్‌మెంట్ వివరాలు, వారు తిరిగి ప్రవేశించాలి అనే వాస్తవం ద్వారా వినియోగదారులలో ఆగ్రహాన్ని రేకెత్తించింది. DANBo.
ప్లేస్‌మెంట్ గురించిన సమాచారం యొక్క ప్రాథమిక మూలం మా 1C సిస్టమ్‌గా ఉండాలనే ఆలోచనను ఇది మాకు అందించింది, దీనిలో మొత్తం డేటా ఖచ్చితంగా మరియు సమయానికి నమోదు చేయబడుతుంది (ఇక్కడ పాయింట్ ఏమిటంటే ఇన్‌వాయిస్‌లు 1C డేటా ఆధారంగా రూపొందించబడతాయి, కాబట్టి 1Cలోకి డేటాను సరిగ్గా నమోదు చేయండి ప్రతి ఒక్కరికీ ప్రాధాన్యత KPI). వ్యవస్థలో కొత్త భావన ఇలా ఉద్భవించింది...
భావన
ఇంటర్నెట్‌లో ప్రకటనల ప్రచారాలపై గణాంకాలను సేకరించే వ్యవస్థను ప్రత్యేక ఉత్పత్తిగా విభజించాలని మేము నిర్ణయించుకున్న మొదటి విషయం - D1.డిజిటల్.
కొత్త కాన్సెప్ట్‌లో, మేము లోడ్ చేయాలని నిర్ణయించుకున్నాము D1.డిజిటల్ 1C నుండి వాటిలోని ప్రకటనల ప్రచారాలు మరియు ప్లేస్‌మెంట్‌లపై సమాచారం, ఆపై ఈ ప్లేస్‌మెంట్‌లకు సైట్లు మరియు AdServing సిస్టమ్‌ల నుండి గణాంకాలను సేకరించండి. ఇది వినియోగదారుల జీవితాన్ని గణనీయంగా సులభతరం చేస్తుంది (మరియు, ఎప్పటిలాగే, డెవలపర్‌లకు మరింత పనిని జోడించండి) మరియు మద్దతు మొత్తాన్ని తగ్గిస్తుంది.
మేము ఎదుర్కొన్న మొదటి సమస్య సంస్థాగత స్వభావం మరియు మేము వివిధ సిస్టమ్‌ల నుండి ఎంటిటీలను 1C నుండి ప్రచారాలు మరియు ప్లేస్‌మెంట్‌లతో పోల్చగలిగే కీ లేదా గుర్తును కనుగొనలేకపోయాము. వాస్తవం ఏమిటంటే, మా కంపెనీలోని ప్రక్రియ వేర్వేరు వ్యక్తులు (మీడియా ప్లానర్లు, కొనుగోలు మొదలైనవి) వేర్వేరు వ్యవస్థల్లోకి ప్రకటనల ప్రచారాలను నమోదు చేసే విధంగా రూపొందించబడింది.
ఈ సమస్యను పరిష్కరించడానికి, మేము ఒక ప్రత్యేకమైన హాష్ కీ, DANBoIDని కనిపెట్టాలి, అది వివిధ సిస్టమ్‌లలోని ఎంటిటీలను ఒకదానితో ఒకటి లింక్ చేస్తుంది మరియు డౌన్‌లోడ్ చేసిన డేటా సెట్‌లలో చాలా సులభంగా మరియు ప్రత్యేకంగా గుర్తించబడుతుంది. ఈ ఐడెంటిఫైయర్ ప్రతి వ్యక్తిగత ప్లేస్‌మెంట్ కోసం అంతర్గత 1C సిస్టమ్‌లో రూపొందించబడింది మరియు అన్ని సైట్‌లలో మరియు అన్ని AdServing సిస్టమ్‌లలో ప్రచారాలు, ప్లేస్‌మెంట్‌లు మరియు కౌంటర్‌లకు బదిలీ చేయబడుతుంది. అన్ని ప్లేస్‌మెంట్‌లలో DANBoIDని ఉంచే అభ్యాసాన్ని అమలు చేయడానికి కొంత సమయం పట్టింది, కానీ మేము దీన్ని నిర్వహించగలిగాము :)
అన్ని సైట్లు స్వయంచాలకంగా గణాంకాలను సేకరించడానికి APIని కలిగి ఉండవని మరియు APIని కలిగి ఉన్నవాటికి కూడా, ఇది అవసరమైన మొత్తం డేటాను అందించదని మేము కనుగొన్నాము.
ఈ దశలో, మేము ఏకీకరణ కోసం ప్లాట్‌ఫారమ్‌ల జాబితాను గణనీయంగా తగ్గించాలని నిర్ణయించుకున్నాము మరియు ఎక్కువ భాగం ప్రకటనల ప్రచారాలలో పాల్గొన్న ప్రధాన ప్లాట్‌ఫారమ్‌లపై దృష్టి పెట్టాము. ఈ జాబితాలో అడ్వర్టైజింగ్ మార్కెట్ (Google, Yandex, Mail.ru), సోషల్ నెట్‌వర్క్‌లు (VK, Facebook, Twitter), ప్రధాన AdServing మరియు అనలిటిక్స్ సిస్టమ్‌లు (DCM, Adriver, Weborama, Google Analytics) మరియు ఇతర ప్లాట్‌ఫారమ్‌లలోని అతిపెద్ద ఆటగాళ్లందరూ ఉన్నారు.
మేము ఎంచుకున్న చాలా సైట్లు మనకు అవసరమైన కొలమానాలను అందించే APIని కలిగి ఉన్నాయి. API లేనప్పుడు లేదా అవసరమైన డేటాను కలిగి ఉండని సందర్భాల్లో, డేటాను లోడ్ చేయడానికి మేము మా కార్యాలయ ఇమెయిల్‌కు ప్రతిరోజూ పంపిన నివేదికలను ఉపయోగించాము (కొన్ని సిస్టమ్‌లలో అటువంటి నివేదికలను కాన్ఫిగర్ చేయడం సాధ్యమవుతుంది, మరికొన్నింటిలో మేము అలాంటి నివేదికల అభివృద్ధిని అంగీకరించాము. మనకి).
వివిధ సైట్‌ల నుండి డేటాను విశ్లేషించేటప్పుడు, వివిధ సిస్టమ్‌లలో ఎంటిటీల సోపానక్రమం ఒకేలా ఉండదని మేము కనుగొన్నాము. అంతేకాకుండా, సమాచారాన్ని వివిధ సిస్టమ్‌ల నుండి విభిన్న వివరాలతో డౌన్‌లోడ్ చేసుకోవాలి.
ఈ సమస్యను పరిష్కరించడానికి, SubDANBoID భావన అభివృద్ధి చేయబడింది. SubDANBoID ఆలోచన చాలా సులభం, మేము సైట్‌లో ప్రచారం యొక్క ప్రధాన ఎంటిటీని రూపొందించిన DANBoIDతో గుర్తించాము మరియు మేము అన్ని సమూహ ఎంటిటీలను ప్రత్యేకమైన సైట్ ఐడెంటిఫైయర్‌లతో అప్‌లోడ్ చేస్తాము మరియు DANBoID సూత్రం + మొదటి స్థాయి ఐడెంటిఫైయర్ ప్రకారం SubDANBoIDని ఏర్పరుస్తాము. nested entity + identifier of the second level nested entity +... ఈ విధానం మాకు వివిధ సిస్టమ్‌లలో ప్రకటనల ప్రచారాలను కనెక్ట్ చేయడానికి మరియు వాటిపై వివరణాత్మక గణాంకాలను డౌన్‌లోడ్ చేయడానికి అనుమతించింది.
మేము వివిధ ప్లాట్‌ఫారమ్‌లలో ప్రచారాలకు ప్రాప్యత సమస్యను కూడా పరిష్కరించాల్సి వచ్చింది. మేము పైన వ్రాసినట్లుగా, ప్రత్యేక సాంకేతిక ఖాతాకు ప్రచారానికి ప్రాప్యతను అప్పగించే విధానం ఎల్లప్పుడూ వర్తించదు. అందువల్ల, మేము ఈ టోకెన్‌లను అప్‌డేట్ చేయడానికి టోకెన్‌లు మరియు మెకానిజమ్‌లను ఉపయోగించి OAuth ద్వారా ఆటోమేటిక్ ఆథరైజేషన్ కోసం మౌలిక సదుపాయాలను అభివృద్ధి చేయాల్సి వచ్చింది.
తరువాత వ్యాసంలో మేము పరిష్కారం యొక్క నిర్మాణం మరియు అమలు యొక్క సాంకేతిక వివరాలను మరింత వివరంగా వివరించడానికి ప్రయత్నిస్తాము.
సొల్యూషన్ ఆర్కిటెక్చర్ 1.0
కొత్త ఉత్పత్తిని అమలు చేయడం ప్రారంభించినప్పుడు, కొత్త సైట్‌లను కనెక్ట్ చేసే అవకాశాన్ని వెంటనే అందించాల్సిన అవసరం ఉందని మేము అర్థం చేసుకున్నాము, కాబట్టి మేము మైక్రోసర్వీస్ ఆర్కిటెక్చర్ మార్గాన్ని అనుసరించాలని నిర్ణయించుకున్నాము.
ఆర్కిటెక్చర్‌ని డిజైన్ చేస్తున్నప్పుడు, మేము అన్ని బాహ్య సిస్టమ్‌లకు కనెక్టర్‌లను వేరు చేసాము - 1C, అడ్వర్టైజింగ్ ప్లాట్‌ఫారమ్‌లు మరియు ప్రకటన సిస్టమ్‌లు - ప్రత్యేక సేవలు.
ప్రధాన ఆలోచన ఏమిటంటే, సైట్‌లకు అన్ని కనెక్టర్లు ఒకే APIని కలిగి ఉంటాయి మరియు సైట్ APIని మనకు అనుకూలమైన ఇంటర్‌ఫేస్‌కు తీసుకువచ్చే అడాప్టర్‌లు.
మా ఉత్పత్తి మధ్యలో ఒక వెబ్ అప్లికేషన్ ఉంది, ఇది సేవలలో సులభంగా విడదీయబడే విధంగా రూపొందించబడిన ఏకశిలా. డౌన్‌లోడ్ చేసిన డేటాను ప్రాసెస్ చేయడం, వివిధ సిస్టమ్‌ల నుండి గణాంకాలను క్రోడీకరించడం మరియు వాటిని సిస్టమ్ వినియోగదారులకు అందించడం కోసం ఈ అప్లికేషన్ బాధ్యత వహిస్తుంది.
కనెక్టర్లు మరియు వెబ్ అప్లికేషన్ మధ్య కమ్యూనికేట్ చేయడానికి, మేము కనెక్టర్ ప్రాక్సీ అని పిలిచే అదనపు సేవను సృష్టించాలి. ఇది సర్వీస్ డిస్కవరీ మరియు టాస్క్ షెడ్యూలర్ యొక్క విధులను నిర్వహిస్తుంది. ఈ సేవ ప్రతి రాత్రి ప్రతి కనెక్టర్ కోసం డేటా సేకరణ పనులను అమలు చేస్తుంది. మెసేజ్ బ్రోకర్‌ని కనెక్ట్ చేయడం కంటే సర్వీస్ లేయర్‌ను రాయడం చాలా సులభం మరియు వీలైనంత త్వరగా ఫలితాన్ని పొందడం మాకు ముఖ్యం.
అభివృద్ధి యొక్క సరళత మరియు వేగం కోసం, మేము అన్ని సేవలు వెబ్ APIలుగా ఉండాలని కూడా నిర్ణయించాము. ఇది ప్రూఫ్-ఆఫ్-కాన్సెప్ట్‌ను త్వరగా సమీకరించడం మరియు మొత్తం డిజైన్ పనిచేస్తుందని ధృవీకరించడం సాధ్యం చేసింది.
విభిన్న ఖాతాల నుండి డేటాను సేకరించడానికి యాక్సెస్‌ను సెటప్ చేయడం అనేది ఒక ప్రత్యేకమైన, కాకుండా సంక్లిష్టమైన పని, మేము నిర్ణయించినట్లుగా, వెబ్ ఇంటర్‌ఫేస్ ద్వారా వినియోగదారులచే నిర్వహించబడాలి. ఇది రెండు వేర్వేరు దశలను కలిగి ఉంటుంది: మొదట, వినియోగదారు OAuth ద్వారా ఖాతాను యాక్సెస్ చేయడానికి టోకెన్‌ను జోడిస్తుంది, ఆపై నిర్దిష్ట ఖాతా నుండి క్లయింట్ కోసం డేటా సేకరణను కాన్ఫిగర్ చేస్తుంది. OAuth ద్వారా టోకెన్ పొందడం అవసరం ఎందుకంటే, మేము ఇప్పటికే వ్రాసినట్లుగా, సైట్‌లో కావలసిన ఖాతాకు ప్రాప్యతను అప్పగించడం ఎల్లప్పుడూ సాధ్యం కాదు.
సైట్‌ల నుండి ఖాతాను ఎంచుకోవడానికి యూనివర్సల్ మెకానిజమ్‌ను రూపొందించడానికి, మేము JSON స్కీమాను తిరిగి అందించే కనెక్టర్ల APIకి ఒక పద్ధతిని జోడించాల్సి ఉంటుంది, ఇది సవరించిన JSONEditor కాంపోనెంట్‌ని ఉపయోగించి ఫారమ్‌లోకి అందించబడుతుంది. ఈ విధంగా, వినియోగదారులు డేటాను డౌన్‌లోడ్ చేసే ఖాతాలను ఎంచుకోగలిగారు.
సైట్‌లలో ఉన్న అభ్యర్థన పరిమితులకు అనుగుణంగా, మేము సెట్టింగ్‌ల కోసం అభ్యర్థనలను ఒక టోకెన్‌లో కలుపుతాము, అయితే మేము వివిధ టోకెన్‌లను సమాంతరంగా ప్రాసెస్ చేయవచ్చు.
మేము వెబ్ అప్లికేషన్ మరియు కనెక్టర్లు రెండింటి కోసం లోడ్ చేయబడిన డేటా కోసం మొంగోడిబిని స్టోరేజ్‌గా ఎంచుకున్నాము, ఇది అప్లికేషన్ యొక్క ఆబ్జెక్ట్ మోడల్ ప్రతిరోజూ మారినప్పుడు అభివృద్ధి యొక్క ప్రారంభ దశలలో డేటా నిర్మాణం గురించి ఎక్కువగా చింతించకుండా ఉండటానికి మాకు వీలు కల్పించింది.
మొంగోడిబిలో మొత్తం డేటా సరిగ్గా సరిపోదని మేము త్వరలో కనుగొన్నాము మరియు ఉదాహరణకు, రోజువారీ గణాంకాలను రిలేషనల్ డేటాబేస్‌లో నిల్వ చేయడం మరింత సౌకర్యవంతంగా ఉంటుంది. అందువల్ల, రిలేషనల్ డేటాబేస్ కోసం డేటా నిర్మాణం మరింత అనుకూలంగా ఉండే కనెక్టర్ల కోసం, మేము PostgreSQL లేదా MS SQL సర్వర్‌ని నిల్వగా ఉపయోగించడం ప్రారంభించాము.
ఎంచుకున్న నిర్మాణం మరియు సాంకేతికతలు D1.Digital ఉత్పత్తిని సాపేక్షంగా త్వరగా నిర్మించడానికి మరియు ప్రారంభించేందుకు మాకు అనుమతినిచ్చాయి. రెండు సంవత్సరాల ఉత్పత్తి అభివృద్ధిలో, మేము సైట్‌లకు 23 కనెక్టర్‌లను అభివృద్ధి చేసాము, థర్డ్-పార్టీ APIలతో పనిచేసిన అమూల్యమైన అనుభవాన్ని పొందాము, వివిధ సైట్‌ల యొక్క ఆపదలను నివారించడం నేర్చుకున్నాము, ప్రతి ఒక్కటి వారి స్వంతం, కనీసం 3 API అభివృద్ధికి దోహదపడింది సైట్లు, దాదాపు 15 ప్రచారాలపై స్వయంచాలకంగా డౌన్‌లోడ్ చేయబడిన సమాచారాన్ని మరియు 000 కంటే ఎక్కువ ప్లేస్‌మెంట్‌ల కోసం, ఉత్పత్తి యొక్క ఆపరేషన్‌పై వినియోగదారుల నుండి చాలా అభిప్రాయాన్ని సేకరించి, ఈ అభిప్రాయం ఆధారంగా ఉత్పత్తి యొక్క ప్రధాన ప్రక్రియను అనేకసార్లు మార్చగలిగాయి.
సొల్యూషన్ ఆర్కిటెక్చర్ 2.0
అభివృద్ధి పనులు ప్రారంభించి రెండేళ్లు దాటింది D1.డిజిటల్. సిస్టమ్‌పై లోడ్‌లో స్థిరమైన పెరుగుదల మరియు మరిన్ని కొత్త డేటా మూలాల ఆవిర్భావం క్రమంగా ఇప్పటికే ఉన్న సొల్యూషన్ ఆర్కిటెక్చర్‌లో సమస్యలను బహిర్గతం చేసింది.
మొదటి సమస్య సైట్‌ల నుండి డౌన్‌లోడ్ చేయబడిన డేటా మొత్తానికి సంబంధించినది. అతిపెద్ద సైట్‌ల నుండి అవసరమైన మొత్తం డేటాను సేకరించడం మరియు నవీకరించడం చాలా సమయం తీసుకుంటుందనే వాస్తవాన్ని మేము ఎదుర్కొన్నాము. ఉదాహరణకు, మేము చాలా ప్లేస్‌మెంట్‌ల కోసం గణాంకాలను ట్రాక్ చేసే AdRiver ప్రకటనల సిస్టమ్ నుండి డేటాను సేకరించడానికి దాదాపు 12 గంటల సమయం పడుతుంది.
ఈ సమస్యను పరిష్కరించడానికి, మేము సైట్‌ల నుండి డేటాను డౌన్‌లోడ్ చేయడానికి అన్ని రకాల నివేదికలను ఉపయోగించడం ప్రారంభించాము, మేము సైట్‌లతో కలిసి వారి APIని అభివృద్ధి చేయడానికి ప్రయత్నిస్తున్నాము, తద్వారా దాని ఆపరేషన్ యొక్క వేగం మా అవసరాలకు అనుగుణంగా ఉంటుంది మరియు డేటా డౌన్‌లోడ్‌ను వీలైనంత వరకు సమాంతరంగా చేస్తుంది.
మరొక సమస్య డౌన్‌లోడ్ చేయబడిన డేటా ప్రాసెసింగ్‌కు సంబంధించినది. ఇప్పుడు, కొత్త ప్లేస్‌మెంట్ గణాంకాలు వచ్చినప్పుడు, కొలమానాలను తిరిగి లెక్కించే బహుళ-దశల ప్రక్రియ ప్రారంభించబడుతుంది, ఇందులో ముడి డేటాను లోడ్ చేయడం, ప్రతి సైట్‌కు సమగ్ర కొలమానాలను లెక్కించడం, విభిన్న మూలాల నుండి డేటాను ఒకదానితో ఒకటి పోల్చడం మరియు ప్రచారం కోసం సారాంశ కొలమానాలను లెక్కించడం వంటివి ఉంటాయి. ఇది అన్ని గణనలను చేసే వెబ్ అప్లికేషన్‌పై చాలా లోడ్‌ను కలిగిస్తుంది. అనేక సార్లు, రీకాలిక్యులేషన్ ప్రక్రియలో, అప్లికేషన్ సర్వర్‌లోని మొత్తం మెమరీని 10-15 GB వినియోగిస్తుంది, ఇది సిస్టమ్‌తో వినియోగదారుల పనిపై అత్యంత హానికరమైన ప్రభావాన్ని కలిగి ఉంది.
ఉత్పత్తి యొక్క మరింత అభివృద్ధి కోసం గుర్తించబడిన సమస్యలు మరియు ప్రతిష్టాత్మక ప్రణాళికలు అప్లికేషన్ నిర్మాణాన్ని పునఃపరిశీలించవలసిన అవసరాన్ని మాకు దారితీశాయి.
మేము కనెక్టర్లతో ప్రారంభించాము.
అన్ని కనెక్టర్లు ఒకే మోడల్‌కు అనుగుణంగా పనిచేస్తాయని మేము గమనించాము, కాబట్టి మేము కనెక్టర్‌ను రూపొందించడానికి పైప్‌లైన్ ఫ్రేమ్‌వర్క్‌ను నిర్మించాము, దీనిలో మీరు దశల తర్కాన్ని మాత్రమే ప్రోగ్రామ్ చేయాలి, మిగిలినవి సార్వత్రికమైనవి. ఏదైనా కనెక్టర్‌కు మెరుగుదల అవసరమైతే, కనెక్టర్ మెరుగుపరచబడుతున్న సమయంలోనే మేము దానిని వెంటనే కొత్త ఫ్రేమ్‌వర్క్‌కి బదిలీ చేస్తాము.
అదే సమయంలో, మేము డాకర్ మరియు కుబెర్నెట్‌లకు కనెక్టర్‌లను అమలు చేయడం ప్రారంభించాము.
మేము చాలా కాలం పాటు కుబెర్నెట్స్‌కు వెళ్లాలని ప్లాన్ చేసాము, CI/CD సెట్టింగ్‌లతో ప్రయోగాలు చేసాము, కానీ ఒక కనెక్టర్ లోపం కారణంగా సర్వర్‌లో 20 GB కంటే ఎక్కువ మెమరీని తినడం ప్రారంభించినప్పుడు మాత్రమే కదలడం ప్రారంభించాము, ఆచరణాత్మకంగా ఇతర ప్రక్రియలను నాశనం చేస్తుంది. . విచారణ సమయంలో, కనెక్టర్ కుబెర్నెటెస్ క్లస్టర్‌కి తరలించబడింది, లోపం పరిష్కరించబడిన తర్వాత కూడా అది చివరికి అలాగే ఉండిపోయింది.
Kubernetes అనుకూలమైనదని మేము చాలా త్వరగా గ్రహించాము మరియు ఆరు నెలల్లో మేము 7 కనెక్టర్లు మరియు కనెక్టర్ల ప్రాక్సీని అత్యధిక వనరులను వినియోగించే ఉత్పత్తి క్లస్టర్‌కు బదిలీ చేసాము.
కనెక్టర్‌లను అనుసరించి, మేము మిగిలిన అప్లికేషన్ యొక్క నిర్మాణాన్ని మార్చాలని నిర్ణయించుకున్నాము.
ప్రధాన సమస్య ఏమిటంటే, డేటా పెద్ద బ్యాచ్‌లలో కనెక్టర్ల నుండి ప్రాక్సీలకు వస్తుంది, ఆపై DANBoIDని తాకుతుంది మరియు ప్రాసెసింగ్ కోసం సెంట్రల్ వెబ్ అప్లికేషన్‌కు పంపబడుతుంది. పెద్ద సంఖ్యలో కొలమానాల రీకాలిక్యులేషన్‌ల కారణంగా, అప్లికేషన్‌పై పెద్ద లోడ్ ఉంది.
వ్యక్తిగత డేటా సేకరణ ఉద్యోగాల స్థితిని పర్యవేక్షించడం మరియు సెంట్రల్ వెబ్ అప్లికేషన్‌కు కనెక్టర్‌లలో సంభవించే లోపాలను నివేదించడం కూడా చాలా కష్టమని నిరూపించబడింది, తద్వారా వినియోగదారులు ఏమి జరుగుతుందో మరియు డేటా ఎందుకు సేకరించబడటం లేదు.
ఈ సమస్యలను పరిష్కరించడానికి, మేము ఆర్కిటెక్చర్ 2.0ని అభివృద్ధి చేసాము.
ఆర్కిటెక్చర్ యొక్క కొత్త వెర్షన్ మధ్య ప్రధాన వ్యత్యాసం ఏమిటంటే, వెబ్ APIకి బదులుగా, మేము సేవల మధ్య సందేశాలను మార్పిడి చేయడానికి RabbitMQ మరియు MassTransit లైబ్రరీని ఉపయోగిస్తాము. దీన్ని చేయడానికి, మేము కనెక్టర్ల ప్రాక్సీని దాదాపు పూర్తిగా తిరిగి వ్రాయవలసి ఉంటుంది, ఇది కనెక్టర్ల హబ్‌గా మారుతుంది. సేవ యొక్క ప్రధాన పాత్ర ఇకపై కనెక్టర్‌లకు మరియు వెనుకకు అభ్యర్థనలను ఫార్వార్డ్ చేయడంలో ఉండదు, కానీ కనెక్టర్ల నుండి కొలమానాల సేకరణను నిర్వహించడం వలన పేరు మార్చబడింది.
సెంట్రల్ వెబ్ అప్లికేషన్ నుండి, మేము సైట్‌ల నుండి ప్లేస్‌మెంట్‌లు మరియు గణాంకాల గురించిన సమాచారాన్ని ప్రత్యేక సేవలుగా విభజించాము, ఇది అనవసరమైన రీకాలిక్యులేషన్‌లను వదిలించుకోవడం మరియు ప్లేస్‌మెంట్ స్థాయిలో ఇప్పటికే లెక్కించిన మరియు సమగ్ర గణాంకాలను మాత్రమే నిల్వ చేయడం సాధ్యపడింది. మేము ముడి డేటా ఆధారంగా ప్రాథమిక గణాంకాలను లెక్కించడానికి లాజిక్‌ను కూడా తిరిగి వ్రాసాము మరియు ఆప్టిమైజ్ చేసాము.
అదే సమయంలో, పరిష్కారాన్ని స్కేల్ చేయడం సులభతరం చేయడానికి మరియు నిర్వహించడానికి మరింత సౌకర్యవంతంగా చేయడానికి మేము అన్ని సేవలు మరియు అప్లికేషన్‌లను డాకర్ మరియు కుబెర్నెట్‌లకు తరలిస్తున్నాము.
మనం ఇప్పుడు ఎక్కడున్నాం
ప్రూఫ్-ఆఫ్-కాన్సెప్ట్ ఆర్కిటెక్చర్ 2.0 ఉత్పత్తి D1.డిజిటల్ పరిమిత కనెక్టర్లతో పరీక్ష వాతావరణంలో సిద్ధంగా మరియు పని చేస్తుంది. మరో 20 కనెక్టర్‌లను కొత్త ప్లాట్‌ఫారమ్‌కు తిరిగి వ్రాయడం, డేటా సరిగ్గా లోడ్ చేయబడిందా మరియు అన్ని కొలమానాలు సరిగ్గా లెక్కించబడ్డాయో లేదో పరీక్షించి, మొత్తం డిజైన్‌ను ఉత్పత్తిలోకి మార్చడం మాత్రమే మిగిలి ఉంది.
వాస్తవానికి, ఈ ప్రక్రియ క్రమంగా జరుగుతుంది మరియు ప్రతిదీ పని చేయడానికి మేము పాత APIలతో వెనుకబడిన అనుకూలతను వదిలివేయవలసి ఉంటుంది.
మా తక్షణ ప్రణాళికలలో కొత్త కనెక్టర్ల అభివృద్ధి, కొత్త సిస్టమ్‌లతో ఏకీకరణ మరియు కనెక్ట్ చేయబడిన సైట్లు మరియు ప్రకటన సిస్టమ్‌ల నుండి డౌన్‌లోడ్ చేయబడిన డేటా సెట్‌కు అదనపు మెట్రిక్‌లను జోడించడం వంటివి ఉన్నాయి.
మేము సెంట్రల్ వెబ్ అప్లికేషన్‌తో సహా అన్ని అప్లికేషన్‌లను డాకర్ మరియు కుబెర్నెట్‌లకు బదిలీ చేయాలని కూడా ప్లాన్ చేస్తున్నాము. కొత్త ఆర్కిటెక్చర్‌తో కలిపి, ఇది వినియోగించే వనరుల విస్తరణ, పర్యవేక్షణ మరియు నియంత్రణను గణనీయంగా సులభతరం చేస్తుంది.
గణాంకాలను నిల్వ చేయడానికి డేటాబేస్ ఎంపికతో ప్రయోగాలు చేయడం మరొక ఆలోచన, ఇది ప్రస్తుతం MongoDBలో నిల్వ చేయబడింది. మేము ఇప్పటికే అనేక కొత్త కనెక్టర్‌లను SQL డేటాబేస్‌లకు బదిలీ చేసాము, కానీ అక్కడ తేడా దాదాపుగా గుర్తించబడదు మరియు ఏకపక్ష వ్యవధి కోసం అభ్యర్థించబడే రోజువారీగా సమగ్ర గణాంకాల కోసం, లాభం చాలా తీవ్రంగా ఉంటుంది.
సాధారణంగా, ప్రణాళికలు గొప్పవి, ముందుకు వెళ్దాం :)
R&D వ్యాసం రచయితలు డెంట్సు ఏజిస్ నెట్వర్క్ రష్యా: జార్జి ఒస్టాపెంకో (), మిఖాయిల్ కోట్సిక్ ()
మూలం: www.habr.com