અમે ઑનલાઇન સાઇટ્સ (ઉત્પાદન માટે કાંટાળો માર્ગ) પરથી જાહેરાત ઝુંબેશ પર ડેટા કેવી રીતે એકત્રિત કર્યો

એવું લાગે છે કે ઑનલાઇન જાહેરાતનું ક્ષેત્ર શક્ય તેટલું તકનીકી રીતે અદ્યતન અને સ્વચાલિત હોવું જોઈએ. અલબત્ત, કારણ કે યાન્ડેક્સ, મેલ.રૂ, ગૂગલ અને ફેસબુક જેવા તેમના ક્ષેત્રના આવા જાયન્ટ્સ અને નિષ્ણાતો ત્યાં કામ કરે છે. પરંતુ, જેમ તે બહાર આવ્યું છે, સંપૂર્ણતાની કોઈ મર્યાદા નથી અને હંમેશા સ્વચાલિત કરવા માટે કંઈક છે.

સોર્સ

કોમ્યુનિકેશન્સ જૂથ ડેન્ટસુ એજીસ નેટવર્ક રશિયા ડિજિટલ એડવર્ટાઇઝિંગ માર્કેટમાં સૌથી મોટી પ્લેયર છે અને તેની બિઝનેસ પ્રક્રિયાઓને ઑપ્ટિમાઇઝ અને સ્વચાલિત કરવાનો પ્રયાસ કરીને ટેક્નોલોજીમાં સક્રિયપણે રોકાણ કરી રહી છે. ઓનલાઈન એડવર્ટાઈઝીંગ માર્કેટની વણઉકેલાયેલી સમસ્યાઓમાંની એક વિવિધ ઈન્ટરનેટ પ્લેટફોર્મ પરથી જાહેરાત ઝુંબેશના આંકડા એકત્ર કરવાનું કાર્ય છે. આ સમસ્યાનો ઉકેલ આખરે ઉત્પાદનની રચનામાં પરિણમ્યો D1.ડિજિટલ (દીવાન તરીકે વાંચો), જેના વિકાસ વિશે આપણે વાત કરવા માંગીએ છીએ.

શા માટે?

1. પ્રોજેક્ટની શરૂઆતના સમયે, બજારમાં એક પણ તૈયાર ઉત્પાદન ન હતું જે જાહેરાત ઝુંબેશ પરના આંકડાઓના સંગ્રહને સ્વચાલિત કરવાની સમસ્યાને હલ કરે. આનો અર્થ એ છે કે આપણા સિવાય કોઈ આપણી જરૂરિયાતોને પૂર્ણ કરશે નહીં.

ઇમ્પ્રોવાડો, રોઇસ્ટેટ, સુપરમેટ્રિક્સ, સેગમેન્ટસ્ટ્રીમ જેવી સેવાઓ પ્લેટફોર્મ્સ, સોશિયલ નેટવર્ક્સ અને Google એનાલિટીક્સ સાથે એકીકરણ ઓફર કરે છે અને જાહેરાત ઝુંબેશના અનુકૂળ વિશ્લેષણ અને નિયંત્રણ માટે વિશ્લેષણાત્મક ડેશબોર્ડ્સ બનાવવાનું પણ શક્ય બનાવે છે. અમે અમારું ઉત્પાદન વિકસાવવાનું શરૂ કર્યું તે પહેલાં, અમે સાઇટ્સમાંથી ડેટા એકત્રિત કરવા માટે આમાંથી કેટલીક સિસ્ટમોનો ઉપયોગ કરવાનો પ્રયાસ કર્યો, પરંતુ, કમનસીબે, તેઓ અમારી સમસ્યાઓ હલ કરી શક્યા નહીં.

મુખ્ય સમસ્યા એ હતી કે ચકાસાયેલ ઉત્પાદનો ડેટા સ્ત્રોતો પર આધાર રાખે છે, સાઇટ દ્વારા પ્લેસમેન્ટના આંકડા પ્રદર્શિત કરે છે, અને જાહેરાત ઝુંબેશ પર આંકડા એકત્રિત કરવાની ક્ષમતા પ્રદાન કરતા નથી. આ અભિગમથી અમને એક જગ્યાએ વિવિધ સાઇટ્સના આંકડા જોવાની અને સમગ્ર અભિયાનની સ્થિતિનું વિશ્લેષણ કરવાની મંજૂરી મળી નથી.

અન્ય પરિબળ એ હતું કે પ્રારંભિક તબક્કે ઉત્પાદનો પશ્ચિમી બજારને લક્ષ્યમાં રાખતા હતા અને રશિયન સાઇટ્સ સાથે એકીકરણને સમર્થન આપતા ન હતા. અને તે સાઇટ્સ માટે કે જેની સાથે એકીકરણ લાગુ કરવામાં આવ્યું હતું, તમામ જરૂરી મેટ્રિક્સ હંમેશા પૂરતી વિગતો સાથે ડાઉનલોડ કરવામાં આવતા ન હતા, અને એકીકરણ હંમેશા અનુકૂળ અને પારદર્શક નહોતું, ખાસ કરીને જ્યારે તે કંઈક મેળવવા માટે જરૂરી હતું જે સિસ્ટમ ઇન્ટરફેસમાં નથી.
સામાન્ય રીતે, અમે તૃતીય-પક્ષ ઉત્પાદનો સાથે અનુકૂલન ન લેવાનું નક્કી કર્યું, પરંતુ અમારા પોતાના વિકસાવવાનું શરૂ કર્યું...

2. ઓનલાઈન જાહેરાત બજાર દર વર્ષે વધી રહ્યું છે, અને 2018 માં, જાહેરાતના બજેટની દ્રષ્ટિએ, તે પરંપરાગત રીતે સૌથી મોટા ટીવી જાહેરાત બજારથી આગળ નીકળી ગયું છે. તેથી એક સ્કેલ છે.

3. ટીવી જાહેરાત બજારથી વિપરીત, જ્યાં વ્યાપારી જાહેરાતોના વેચાણ પર એકાધિકાર છે, ત્યાં ઘણા બધા વ્યક્તિગત માલિકો વિવિધ કદની જાહેરાત ઇન્વેન્ટરીના પોતાના જાહેરાત ખાતાઓ સાથે ઇન્ટરનેટ પર કાર્યરત છે. જાહેરાત ઝુંબેશ, એક નિયમ તરીકે, એક સાથે ઘણી સાઇટ્સ પર ચાલે છે, જાહેરાત ઝુંબેશની સ્થિતિને સમજવા માટે, બધી સાઇટ્સમાંથી અહેવાલો એકત્રિત કરવા અને તેમને એક મોટા અહેવાલમાં જોડવા જરૂરી છે જે સમગ્ર ચિત્ર બતાવશે. આનો અર્થ એ છે કે ઑપ્ટિમાઇઝેશન માટે સંભવિત છે.

4. અમને એવું લાગતું હતું કે ઈન્ટરનેટ પર જાહેરાત ઈન્વેન્ટરીના માલિકો પાસે પહેલાથી જ આંકડા એકત્રિત કરવા અને તેને જાહેરાત ખાતાઓમાં પ્રદર્શિત કરવા માટે ઈન્ફ્રાસ્ટ્રક્ચર છે અને તેઓ આ ડેટા માટે API પ્રદાન કરવામાં સક્ષમ હશે. આનો અર્થ એ છે કે તકનીકી રીતે તેનો અમલ કરવો શક્ય છે. ચાલો તરત જ કહીએ કે તે એટલું સરળ ન હોવાનું બહાર આવ્યું છે.

સામાન્ય રીતે, પ્રોજેક્ટના અમલીકરણ માટેની તમામ પૂર્વજરૂરીયાતો અમને સ્પષ્ટ હતી, અને અમે પ્રોજેક્ટને જીવંત બનાવવા માટે દોડ્યા હતા...

ભવ્ય યોજના

શરૂ કરવા માટે, અમે એક આદર્શ સિસ્ટમનું વિઝન રચ્યું:

• 1C કોર્પોરેટ સિસ્ટમની જાહેરાત ઝુંબેશ તેના નામ, સમયગાળો, બજેટ અને વિવિધ પ્લેટફોર્મ પર પ્લેસમેન્ટ સાથે આપમેળે લોડ થવી જોઈએ.
• જાહેરાત ઝુંબેશમાં દરેક પ્લેસમેન્ટ માટે, તમામ સંભવિત આંકડાઓ તે સાઇટ્સ પરથી આપમેળે ડાઉનલોડ થવા જોઈએ જ્યાં પ્લેસમેન્ટ થઈ રહ્યું છે, જેમ કે છાપની સંખ્યા, ક્લિક્સ, વ્યૂ વગેરે.
• કેટલીક જાહેરાત ઝુંબેશને તૃતીય-પક્ષ મોનિટરિંગનો ઉપયોગ કરીને કહેવાતી જાહેરાત પ્રણાલીઓ જેમ કે Adriver, Weborama, DCM વગેરે દ્વારા ટ્રેક કરવામાં આવે છે. રશિયામાં ઔદ્યોગિક ઇન્ટરનેટ મીટર પણ છે - મેડિયાસ્કોપ કંપની. અમારી યોજના અનુસાર, સ્વતંત્ર અને ઔદ્યોગિક દેખરેખનો ડેટા પણ સંબંધિત જાહેરાત ઝુંબેશમાં આપમેળે લોડ થવો જોઈએ.
• ઈન્ટરનેટ પરની મોટાભાગની જાહેરાત ઝુંબેશ અમુક લક્ષ્ય ક્રિયાઓ (ખરીદી, કૉલ, ટેસ્ટ ડ્રાઈવ માટે સાઈન અપ વગેરે) ને ધ્યાનમાં રાખીને કરવામાં આવે છે, જે Google Analyticsનો ઉપયોગ કરીને ટ્રૅક કરવામાં આવે છે અને જેના માટેના આંકડા પણ ઝુંબેશની સ્થિતિ સમજવા માટે મહત્વપૂર્ણ છે અને અમારા ટૂલમાં લોડ થવું જોઈએ.

પ્રથમ શાબ્દિક વસ્તુ ગઠ્ઠો છે

સૉફ્ટવેર ડેવલપમેન્ટના લવચીક સિદ્ધાંતો (ચપળ, બધી બાબતો) પ્રત્યેની અમારી પ્રતિબદ્ધતાને જોતાં, અમે પ્રથમ MVP વિકસાવવાનું નક્કી કર્યું અને પછી ઇચ્છિત લક્ષ્ય તરફ પુનરાવર્તિત રીતે આગળ વધવાનું નક્કી કર્યું.
અમે અમારા ઉત્પાદનના આધારે MVP બનાવવાનું નક્કી કર્યું DANBo (ડેન્ટસુ એજીસ નેટવર્ક બોર્ડ), જે અમારા ગ્રાહકોની જાહેરાત ઝુંબેશ પર સામાન્ય માહિતી સાથેની વેબ એપ્લિકેશન છે.

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 થી પ્લેસમેન્ટ પરની માહિતી, અને પછી આ પ્લેસમેન્ટ્સ માટે સાઇટ્સ અને એડસર્વિંગ સિસ્ટમ્સમાંથી આંકડા ખેંચો. આ વપરાશકર્તાઓ માટે જીવનને નોંધપાત્ર રીતે સરળ બનાવવાનું માનવામાં આવતું હતું (અને, હંમેશની જેમ, વિકાસકર્તાઓને વધુ કાર્ય ઉમેરો) અને સમર્થનની માત્રામાં ઘટાડો.

અમે જે પ્રથમ સમસ્યાનો સામનો કર્યો તે સંસ્થાકીય પ્રકૃતિની હતી અને તે હકીકત સાથે સંકળાયેલી હતી કે અમને એવી કોઈ કી અથવા ચિહ્ન મળી શક્યું નથી કે જેના દ્વારા અમે 1C થી ઝુંબેશ અને પ્લેસમેન્ટ સાથે વિવિધ સિસ્ટમોની એન્ટિટીની તુલના કરી શકીએ. હકીકત એ છે કે અમારી કંપનીમાં પ્રક્રિયા એવી રીતે ડિઝાઇન કરવામાં આવી છે કે વિવિધ લોકો (મીડિયા પ્લાનર્સ, ખરીદી, વગેરે) દ્વારા વિવિધ સિસ્ટમોમાં જાહેરાત ઝુંબેશ દાખલ કરવામાં આવે છે.

આ સમસ્યાને ઉકેલવા માટે, અમારે એક અનન્ય હેશ કી, DANBoID ની શોધ કરવી પડી હતી, જે વિવિધ સિસ્ટમોમાં એકસાથે એકમને લિંક કરશે, અને તે ડાઉનલોડ કરેલા ડેટા સેટ્સમાં એકદમ સરળતાથી અને અનન્ય રીતે ઓળખી શકાય છે. આ ઓળખકર્તા દરેક વ્યક્તિગત પ્લેસમેન્ટ માટે આંતરિક 1C સિસ્ટમમાં જનરેટ થાય છે અને તમામ સાઇટ્સ અને તમામ એડસર્વિંગ સિસ્ટમ્સમાં ઝુંબેશ, પ્લેસમેન્ટ અને કાઉન્ટર્સ પર ટ્રાન્સફર થાય છે. તમામ પ્લેસમેન્ટમાં DANBoID મૂકવાની પ્રથા લાગુ કરવામાં થોડો સમય લાગ્યો, પરંતુ અમે તે કરવામાં વ્યવસ્થાપિત થયા :)

પછી અમને જાણવા મળ્યું કે બધી સાઇટ્સ પાસે આપમેળે આંકડા એકત્ર કરવા માટે API નથી, અને જેની પાસે API છે, તે તમામ જરૂરી ડેટા પરત કરતું નથી.

આ તબક્કે, અમે એકીકરણ માટે પ્લેટફોર્મ્સની સૂચિને નોંધપાત્ર રીતે ઘટાડવાનું નક્કી કર્યું છે અને મોટાભાગની જાહેરાત ઝુંબેશમાં સામેલ મુખ્ય પ્લેટફોર્મ પર ધ્યાન કેન્દ્રિત કર્યું છે. આ સૂચિમાં જાહેરાત બજાર (Google, Yandex, Mail.ru), સામાજિક નેટવર્ક્સ (VK, Facebook, Twitter), મુખ્ય AdServing અને એનાલિટિક્સ સિસ્ટમ્સ (DCM, Adriver, Weborama, Google Analytics) અને અન્ય પ્લેટફોર્મના તમામ મોટા ખેલાડીઓનો સમાવેશ થાય છે.

અમે પસંદ કરેલી મોટાભાગની સાઇટ્સમાં API છે જે અમને જરૂરી મેટ્રિક્સ પ્રદાન કરે છે. એવા કિસ્સાઓમાં જ્યાં કોઈ API નહોતું અથવા તેમાં જરૂરી ડેટા ન હતો, અમે ડેટા લોડ કરવા માટે દરરોજ અમારા ઑફિસના ઇમેઇલ પર મોકલવામાં આવતા અહેવાલોનો ઉપયોગ કર્યો હતો (કેટલીક સિસ્ટમોમાં આવા અહેવાલોને ગોઠવવાનું શક્ય છે, અન્યમાં અમે વિકાસ પર સંમત થયા હતા. અમારા માટે આવા અહેવાલો).

વિવિધ સાઇટ્સમાંથી ડેટાનું વિશ્લેષણ કરતી વખતે, અમને જાણવા મળ્યું કે વિવિધ સિસ્ટમોમાં એન્ટિટીની વંશવેલો સમાન નથી. તદુપરાંત, વિવિધ સિસ્ટમોમાંથી વિવિધ વિગતોમાં માહિતી ડાઉનલોડ કરવાની જરૂર છે.

આ સમસ્યાને ઉકેલવા માટે, SubDANBoID ખ્યાલ વિકસાવવામાં આવ્યો હતો. SubDANBoID નો વિચાર એકદમ સરળ છે, અમે જનરેટ કરેલ DANBoID સાથે સાઇટ પર ઝુંબેશની મુખ્ય એન્ટિટીને ચિહ્નિત કરીએ છીએ, અને અમે અનન્ય સાઇટ ઓળખકર્તાઓ સાથે તમામ નેસ્ટેડ એન્ટિટી અપલોડ કરીએ છીએ અને DANBoID સિદ્ધાંત + પ્રથમ સ્તરના ઓળખકર્તા અનુસાર SubDANBoID બનાવીએ છીએ. નેસ્ટેડ એન્ટિટી + બીજા સ્તરની નેસ્ટેડ એન્ટિટીનો ઓળખકર્તા +... આ અભિગમથી અમને વિવિધ સિસ્ટમ્સમાં જાહેરાત ઝુંબેશને જોડવાની અને તેના પર વિગતવાર આંકડા ડાઉનલોડ કરવાની મંજૂરી મળી.

અમારે અલગ-અલગ પ્લેટફોર્મ પર ઝુંબેશની ઍક્સેસની સમસ્યાને પણ હલ કરવાની હતી. જેમ આપણે ઉપર લખ્યું છે તેમ, ઝુંબેશની ઍક્સેસને અલગ તકનીકી ખાતામાં સોંપવાની પદ્ધતિ હંમેશા લાગુ પડતી નથી. તેથી, અમારે આ ટોકન્સને અપડેટ કરવા માટે ટોકન્સ અને મિકેનિઝમ્સનો ઉપયોગ કરીને OAuth દ્વારા સ્વચાલિત અધિકૃતતા માટે ઇન્ફ્રાસ્ટ્રક્ચર વિકસાવવાનું હતું.

પાછળથી લેખમાં આપણે ઉકેલના આર્કિટેક્ચર અને અમલીકરણની તકનીકી વિગતોનું વધુ વિગતવાર વર્ણન કરવાનો પ્રયાસ કરીશું.

સોલ્યુશન આર્કિટેક્ચર 1.0

નવી પ્રોડક્ટના અમલીકરણની શરૂઆત કરતી વખતે, અમે સમજી ગયા કે અમને તરત જ નવી સાઇટ્સને કનેક્ટ કરવાની સંભાવના પૂરી પાડવાની જરૂર છે, તેથી અમે માઇક્રોસર્વિસ આર્કિટેક્ચરના માર્ગને અનુસરવાનું નક્કી કર્યું.

આર્કિટેક્ચર ડિઝાઇન કરતી વખતે, અમે કનેક્ટર્સને તમામ બાહ્ય સિસ્ટમ્સ - 1C, જાહેરાત પ્લેટફોર્મ્સ અને જાહેરાત સિસ્ટમ્સ - અલગ સેવાઓમાં અલગ કર્યા.
મુખ્ય વિચાર એ છે કે સાઇટ્સના તમામ કનેક્ટર્સ સમાન API ધરાવે છે અને એડેપ્ટર છે જે સાઇટ API ને અમારા માટે અનુકૂળ ઇન્ટરફેસ પર લાવે છે.

અમારા ઉત્પાદનના કેન્દ્રમાં એક વેબ એપ્લિકેશન છે, જે એક મોનોલિથ છે જે એવી રીતે ડિઝાઇન કરવામાં આવી છે કે તેને સેવાઓમાં સરળતાથી ડિસએસેમ્બલ કરી શકાય છે. આ એપ્લિકેશન ડાઉનલોડ કરેલ ડેટાની પ્રક્રિયા કરવા, વિવિધ સિસ્ટમોમાંથી આંકડાઓ ભેગા કરવા અને તેને સિસ્ટમ વપરાશકર્તાઓ સમક્ષ રજૂ કરવા માટે જવાબદાર છે.

કનેક્ટર્સ અને વેબ એપ્લિકેશન વચ્ચે વાતચીત કરવા માટે, અમારે એક વધારાની સેવા બનાવવી પડી, જેને અમે કનેક્ટર પ્રોક્સી કહીએ છીએ. તે સર્વિસ ડિસ્કવરી અને ટાસ્ક શેડ્યૂલરના કાર્યો કરે છે. આ સેવા દરેક કનેક્ટર માટે દરરોજ રાત્રે ડેટા સંગ્રહ કાર્યો ચલાવે છે. મેસેજ બ્રોકરને કનેક્ટ કરવા કરતાં સર્વિસ લેયર લખવું સરળ હતું અને અમારા માટે શક્ય તેટલું ઝડપથી પરિણામ મેળવવું મહત્વપૂર્ણ હતું.

વિકાસની સરળતા અને ઝડપ માટે, અમે એ પણ નક્કી કર્યું છે કે બધી સેવાઓ વેબ API હશે. આનાથી પ્રૂફ-ઓફ-કન્સેપ્ટને ઝડપથી એસેમ્બલ કરવાનું શક્ય બન્યું અને ચકાસવું કે સમગ્ર ડિઝાઇન કામ કરે છે.

એક અલગ, તેના બદલે જટિલ કાર્ય વિવિધ એકાઉન્ટ્સમાંથી ડેટા એકત્રિત કરવા માટે ઍક્સેસ સેટ કરવાનું હતું, જે અમે નક્કી કર્યું છે તેમ, વપરાશકર્તાઓ દ્વારા વેબ ઇન્ટરફેસ દ્વારા હાથ ધરવામાં આવવું જોઈએ. તેમાં બે અલગ-અલગ પગલાઓનો સમાવેશ થાય છે: પ્રથમ, વપરાશકર્તા OAuth દ્વારા એકાઉન્ટને ઍક્સેસ કરવા માટે ટોકન ઉમેરે છે, અને પછી ચોક્કસ એકાઉન્ટમાંથી ક્લાયંટ માટે ડેટાના સંગ્રહને ગોઠવે છે. OAuth દ્વારા ટોકન મેળવવું જરૂરી છે કારણ કે, જેમ આપણે પહેલેથી જ લખ્યું છે તેમ, સાઇટ પર ઇચ્છિત એકાઉન્ટની ઍક્સેસ સોંપવી હંમેશા શક્ય નથી.

સાઇટ્સમાંથી એકાઉન્ટ પસંદ કરવા માટે સાર્વત્રિક મિકેનિઝમ બનાવવા માટે, અમારે કનેક્ટર્સ API માં એક પદ્ધતિ ઉમેરવાની હતી જે JSON સ્કીમા પરત કરે છે, જે સંશોધિત JSONEditor ઘટકનો ઉપયોગ કરીને ફોર્મમાં રેન્ડર કરવામાં આવે છે. આ રીતે, યુઝર્સ એવા એકાઉન્ટ્સને પસંદ કરવામાં સક્ષમ હતા કે જેમાંથી ડેટા ડાઉનલોડ કરવો.

સાઇટ્સ પર અસ્તિત્વમાં છે તે વિનંતી મર્યાદાઓનું પાલન કરવા માટે, અમે એક ટોકનમાં સેટિંગ્સ માટેની વિનંતીઓને જોડીએ છીએ, પરંતુ અમે સમાંતર રીતે વિવિધ ટોકન્સ પર પ્રક્રિયા કરી શકીએ છીએ.

અમે વેબ એપ્લિકેશન અને કનેક્ટર્સ બંને માટે લોડ કરેલા ડેટા માટે સંગ્રહ તરીકે MongoDB પસંદ કર્યું છે, જેણે અમને વિકાસના પ્રારંભિક તબક્કામાં ડેટા સ્ટ્રક્ચર વિશે વધુ ચિંતા કરવાની મંજૂરી આપી નથી, જ્યારે એપ્લિકેશનનું ઑબ્જેક્ટ મોડેલ દર બીજા દિવસે બદલાય છે.

અમને ટૂંક સમયમાં જાણવા મળ્યું કે મોંગોડીબીમાં તમામ ડેટા સારી રીતે બંધબેસતા નથી અને, ઉદાહરણ તરીકે, રિલેશનલ ડેટાબેઝમાં દૈનિક આંકડા સંગ્રહિત કરવા વધુ અનુકૂળ છે. તેથી, કનેક્ટર્સ માટે કે જેમનું ડેટા માળખું રિલેશનલ ડેટાબેઝ માટે વધુ યોગ્ય છે, અમે સ્ટોરેજ તરીકે PostgreSQL અથવા MS SQL સર્વરનો ઉપયોગ કરવાનું શરૂ કર્યું.

પસંદ કરેલ આર્કિટેક્ચર અને તકનીકોએ અમને D1.Digital ઉત્પાદનને પ્રમાણમાં ઝડપથી બનાવવા અને લોન્ચ કરવાની મંજૂરી આપી. પ્રોડક્ટ ડેવલપમેન્ટના બે વર્ષમાં, અમે સાઇટ્સ પર 23 કનેક્ટર્સ વિકસાવ્યા, તૃતીય-પક્ષ API સાથે કામ કરવાનો અમૂલ્ય અનુભવ મેળવ્યો, વિવિધ સાઇટ્સની મુશ્કેલીઓ ટાળવાનું શીખ્યા, જે દરેકની પોતાની હતી, ઓછામાં ઓછા 3ના API ના વિકાસમાં ફાળો આપ્યો. સાઇટ્સ, લગભગ 15 ઝુંબેશો અને 000 થી વધુ પ્લેસમેન્ટ્સ માટે આપમેળે માહિતી ડાઉનલોડ કરે છે, ઉત્પાદનની કામગીરી પર વપરાશકર્તાઓ પાસેથી ઘણો પ્રતિસાદ એકત્રિત કરે છે અને આ પ્રતિસાદના આધારે, ઉત્પાદનની મુખ્ય પ્રક્રિયાને ઘણી વખત બદલવામાં વ્યવસ્થાપિત છે.

સોલ્યુશન આર્કિટેક્ચર 2.0

વિકાસની શરૂઆત થયાને બે વર્ષ વીતી ગયા છે D1.ડિજિટલ. સિસ્ટમ પરના ભારમાં સતત વધારો અને વધુ અને વધુ નવા ડેટા સ્ત્રોતોના ઉદભવથી હાલના સોલ્યુશન આર્કિટેક્ચરમાં ધીમે ધીમે સમસ્યાઓ જાહેર થઈ.

પ્રથમ સમસ્યા સાઇટ્સ પરથી ડાઉનલોડ કરેલ ડેટાની માત્રા સાથે સંબંધિત છે. અમને એ હકીકતનો સામનો કરવો પડ્યો હતો કે સૌથી મોટી સાઇટ્સમાંથી તમામ જરૂરી ડેટા એકત્રિત કરવા અને અપડેટ કરવામાં ઘણો સમય લાગવા લાગ્યો. ઉદાહરણ તરીકે, AdRiver જાહેરાત પ્રણાલીમાંથી ડેટા એકત્રિત કરવામાં, જેની સાથે અમે મોટાભાગના પ્લેસમેન્ટ માટે આંકડાઓ ટ્રૅક કરીએ છીએ, લગભગ 12 કલાક લે છે.

આ સમસ્યાને ઉકેલવા માટે, અમે સાઇટ્સમાંથી ડેટા ડાઉનલોડ કરવા માટે તમામ પ્રકારના રિપોર્ટ્સનો ઉપયોગ કરવાનું શરૂ કર્યું, અમે સાઇટ્સ સાથે મળીને તેમના API ને વિકસાવવાનો પ્રયાસ કરી રહ્યા છીએ જેથી કરીને તેની કામગીરીની ઝડપ અમારી જરૂરિયાતોને પૂર્ણ કરે, અને શક્ય તેટલું ડેટા ડાઉનલોડને સમાંતર બનાવે.

બીજી સમસ્યા ડાઉનલોડ કરેલ ડેટાની પ્રક્રિયા સાથે સંબંધિત છે. હવે, જ્યારે નવા પ્લેસમેન્ટના આંકડા આવે છે, ત્યારે મેટ્રિક્સની પુનઃગણતરી કરવાની બહુ-તબક્કાની પ્રક્રિયા શરૂ કરવામાં આવે છે, જેમાં કાચો ડેટા લોડ કરવો, દરેક સાઇટ માટે એકીકૃત મેટ્રિક્સની ગણતરી કરવી, વિવિધ સ્ત્રોતોમાંથી ડેટાની એકબીજા સાથે સરખામણી કરવી અને ઝુંબેશ માટે સારાંશ મેટ્રિક્સની ગણતરી કરવી શામેલ છે. આનાથી વેબ એપ્લિકેશન પર ઘણો ભાર પડે છે જે બધી ગણતરીઓ કરે છે. ઘણી વખત, પુનઃગણતરી પ્રક્રિયા દરમિયાન, એપ્લિકેશને સર્વર પરની તમામ મેમરીનો વપરાશ કર્યો, લગભગ 10-15 GB, જે સિસ્ટમ સાથેના વપરાશકર્તાઓના કાર્ય પર સૌથી વધુ નુકસાનકારક અસર ધરાવે છે.

ઓળખાયેલ સમસ્યાઓ અને ઉત્પાદનના વધુ વિકાસ માટેની મહત્વાકાંક્ષી યોજનાઓ અમને એપ્લિકેશન આર્કિટેક્ચર પર પુનર્વિચાર કરવાની જરૂરિયાત તરફ દોરી ગઈ.

અમે કનેક્ટર્સથી શરૂઆત કરી.
અમે નોંધ્યું છે કે બધા કનેક્ટર્સ સમાન મોડેલ અનુસાર કાર્ય કરે છે, તેથી અમે એક પાઇપલાઇન ફ્રેમવર્ક બનાવ્યું છે જેમાં કનેક્ટર બનાવવા માટે તમારે ફક્ત પગલાઓના તર્કને પ્રોગ્રામ કરવો પડશે, બાકીનું સાર્વત્રિક હતું. જો કોઈ કનેક્ટરને સુધારણાની જરૂર હોય, તો અમે તેને તરત જ નવા ફ્રેમવર્કમાં સ્થાનાંતરિત કરીએ છીએ તે જ સમયે જ્યારે કનેક્ટર સુધારી રહ્યું છે.

તે જ સમયે, અમે Docker અને Kubernetes માટે કનેક્ટર્સ જમાવવાનું શરૂ કર્યું.
અમે ઘણા લાંબા સમય સુધી કુબરનેટ્સમાં જવાની યોજના બનાવી હતી, CI/CD સેટિંગ્સ સાથે પ્રયોગ કર્યો હતો, પરંતુ જ્યારે એક કનેક્ટર, ભૂલને કારણે, સર્વર પર 20 GB થી વધુ મેમરી ખાવાનું શરૂ કર્યું ત્યારે જ ખસેડવાનું શરૂ કર્યું હતું, જે વ્યવહારીક રીતે અન્ય પ્રક્રિયાઓને મારી નાખે છે. . તપાસ દરમિયાન, કનેક્ટરને કુબરનેટ્સ ક્લસ્ટરમાં ખસેડવામાં આવ્યું હતું, જ્યાં ભૂલ સુધારાઈ ગયા પછી પણ આખરે તે રહી ગયું હતું.

ખૂબ જ ઝડપથી અમને સમજાયું કે કુબરનેટ્સ અનુકૂળ છે, અને છ મહિનાની અંદર અમે 7 કનેક્ટર્સ અને કનેક્ટર્સ પ્રોક્સી, જે સૌથી વધુ સંસાધનોનો ઉપયોગ કરે છે, ઉત્પાદન ક્લસ્ટરમાં સ્થાનાંતરિત કર્યા.

કનેક્ટર્સને અનુસરીને, અમે બાકીની એપ્લિકેશનના આર્કિટેક્ચરને બદલવાનું નક્કી કર્યું છે.
મુખ્ય સમસ્યા એ હતી કે ડેટા કનેક્ટર્સથી પ્રોક્સીઝમાં મોટા બેચમાં આવે છે, અને પછી DANBoID ને હિટ કરે છે અને પ્રક્રિયા માટે કેન્દ્રીય વેબ એપ્લિકેશન પર મોકલવામાં આવે છે. મોટી સંખ્યામાં મેટ્રિક્સ પુનઃગણતરીને કારણે, એપ્લિકેશન પર મોટો ભાર છે.

વ્યક્તિગત ડેટા કલેક્શન જોબ્સની સ્થિતિનું નિરીક્ષણ કરવું અને સેન્ટ્રલ વેબ એપ્લિકેશન સાથે કનેક્ટર્સમાં થતી ભૂલોની જાણ કરવી પણ ખૂબ મુશ્કેલ સાબિત થયું જેથી વપરાશકર્તાઓ જોઈ શકે કે શું થઈ રહ્યું છે અને શા માટે ડેટા એકત્રિત કરવામાં આવી રહ્યો નથી.

આ સમસ્યાઓ ઉકેલવા માટે, અમે આર્કિટેક્ચર 2.0 વિકસાવ્યું છે.

આર્કિટેક્ચરના નવા સંસ્કરણ વચ્ચેનો મુખ્ય તફાવત એ છે કે વેબ API ને બદલે, અમે સેવાઓ વચ્ચે સંદેશાઓની આપ-લે કરવા માટે RabbitMQ અને MassTransit લાઇબ્રેરીનો ઉપયોગ કરીએ છીએ. આ કરવા માટે, અમારે કનેક્ટર્સ પ્રોક્સીને લગભગ સંપૂર્ણપણે ફરીથી લખવું પડ્યું, તેને કનેક્ટર્સ હબ બનાવ્યું. નામ બદલવામાં આવ્યું હતું કારણ કે સેવાની મુખ્ય ભૂમિકા હવે કનેક્ટર્સ અને પાછળની વિનંતીઓને ફોરવર્ડ કરવામાં નથી, પરંતુ કનેક્ટર્સના મેટ્રિક્સના સંગ્રહને સંચાલિત કરવામાં છે.

સેન્ટ્રલ વેબ એપ્લિકેશનથી, અમે સાઇટ્સમાંથી પ્લેસમેન્ટ્સ અને આંકડાઓ વિશેની માહિતીને અલગ સેવાઓમાં અલગ કરી છે, જેણે બિનજરૂરી પુનઃગણતરીથી છૂટકારો મેળવવાનું અને પ્લેસમેન્ટ સ્તર પર ફક્ત પહેલેથી જ ગણતરી કરેલ અને એકત્રિત આંકડાઓને સંગ્રહિત કરવાનું શક્ય બનાવ્યું છે. અમે કાચા ડેટા પર આધારિત મૂળભૂત આંકડાઓની ગણતરી માટે તર્કને ફરીથી લખ્યો અને ઑપ્ટિમાઇઝ પણ કર્યો.

તે જ સમયે, અમે સોલ્યુશનને માપવામાં સરળ અને મેનેજ કરવા માટે વધુ અનુકૂળ બનાવવા માટે તમામ સેવાઓ અને એપ્લિકેશનોને ડોકર અને કુબરનેટ્સ પર સ્થાનાંતરિત કરી રહ્યા છીએ.

અત્યારે આપણે ક્યાં છીએ

પ્રૂફ-ઓફ-કન્સેપ્ટ આર્કિટેક્ચર 2.0 ઉત્પાદન D1.ડિજિટલ કનેક્ટર્સના મર્યાદિત સેટ સાથે પરીક્ષણ વાતાવરણમાં તૈયાર અને કામ કરવું. બસ, બીજા 20 કનેક્ટર્સને નવા પ્લેટફોર્મ પર ફરીથી લખવાનું બાકી છે, ડેટા યોગ્ય રીતે લોડ થયો છે અને તમામ મેટ્રિક્સની ગણતરી યોગ્ય રીતે કરવામાં આવી છે તેની ચકાસણી કરવી અને સમગ્ર ડિઝાઇનને પ્રોડક્શનમાં રોલ આઉટ કરવાનું બાકી છે.

વાસ્તવમાં, આ પ્રક્રિયા ધીમે ધીમે થશે અને આપણે બધું કામ ચાલુ રાખવા માટે જૂના API સાથે પછાત સુસંગતતા છોડવી પડશે.

અમારી તાત્કાલિક યોજનાઓમાં નવા કનેક્ટર્સનો વિકાસ, નવી સિસ્ટમ્સ સાથે એકીકરણ અને કનેક્ટેડ સાઇટ્સ અને જાહેરાત સિસ્ટમ્સ પરથી ડાઉનલોડ કરેલા ડેટાના સેટમાં વધારાના મેટ્રિક્સ ઉમેરવાનો સમાવેશ થાય છે.

અમે કેન્દ્રીય વેબ એપ્લિકેશન સહિતની તમામ એપ્લિકેશનોને ડોકર અને કુબરનેટ્સમાં સ્થાનાંતરિત કરવાની પણ યોજના બનાવીએ છીએ. નવા આર્કિટેક્ચર સાથે જોડાઈને, આ ઉપયોગમાં લેવાતા સંસાધનોની જમાવટ, દેખરેખ અને નિયંત્રણને નોંધપાત્ર રીતે સરળ બનાવશે.

બીજો વિચાર એ છે કે આંકડા સંગ્રહિત કરવા માટે ડેટાબેઝની પસંદગી સાથે પ્રયોગ કરવો, જે હાલમાં મોંગોડીબીમાં સંગ્રહિત છે. અમે પહેલાથી જ ઘણા નવા કનેક્ટર્સને એસક્યુએલ ડેટાબેસેસમાં સ્થાનાંતરિત કર્યા છે, પરંતુ ત્યાં તફાવત લગભગ અસ્પષ્ટ છે, અને દિવસના એકંદર આંકડાઓ માટે, જેને મનસ્વી સમયગાળા માટે વિનંતી કરી શકાય છે, લાભ ખૂબ ગંભીર હોઈ શકે છે.

સામાન્ય રીતે, યોજનાઓ ભવ્ય છે, ચાલો આગળ વધીએ :)

લેખના લેખકો આર એન્ડ ડી ડેન્ટસુ એજીસ નેટવર્ક રશિયા: જ્યોર્જી ઓસ્ટાપેન્કો (શ્મિગા), મિખાઇલ કોટસિક (hitexx)

સોર્સ: www.habr.com