રિટેલમાં ટેબ્લો, ખરેખર?

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

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

કટ નીચે આપણે શું અનુભવ્યું અને આપણે શું શીખ્યા તે વિશે છે.

આપણે ક્યાંથી શરૂઆત કરી?

M.Video-Eldorado પાસે સારી રીતે વિકસિત ડેટા મોડલ છે: જરૂરી સ્ટોરેજ ઊંડાઈ અને મોટી સંખ્યામાં ફિક્સ-ફોર્મ રિપોર્ટ્સ સાથેની સંરચિત માહિતી (વધુ વિગતો જુઓ આ લેખ). આમાંથી, વિશ્લેષકો એક્સેલમાં પિવટ કોષ્ટકો અથવા ફોર્મેટ કરેલા ન્યૂઝલેટર્સ અથવા અંતિમ વપરાશકર્તાઓ માટે સુંદર પાવરપોઈન્ટ પ્રસ્તુતિઓ બનાવે છે.

લગભગ બે વર્ષ પહેલાં, ફિક્સ્ડ-ફોર્મ રિપોર્ટ્સને બદલે, અમે SAP એનાલિસિસ (એક્સેલ ઍડ-ઑન, આવશ્યકપણે OLAP એન્જિન પર પિવટ ટેબલ)માં વિશ્લેષણાત્મક અહેવાલો બનાવવાનું શરૂ કર્યું. પરંતુ આ સાધન બધા વપરાશકર્તાઓની જરૂરિયાતોને પહોંચી વળવા સક્ષમ ન હતું; મોટાભાગના વિશ્લેષકો દ્વારા પ્રક્રિયા કરાયેલ માહિતીનો ઉપયોગ કરવાનું ચાલુ રાખ્યું.

અમારા અંતિમ વપરાશકર્તાઓ ત્રણ શ્રેણીઓમાં આવે છે:

ટોચનું સંચાલન. સારી રીતે પ્રસ્તુત અને સ્પષ્ટ રીતે સમજી શકાય તેવી રીતે માહિતીની વિનંતી કરે છે.

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

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

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

ડેશબોર્ડ્સના વપરાશકર્તાઓ ટોચના સંચાલનના હોવાથી, ઉત્પાદનનો બીજો વધારાનો KPI દેખાયો - પ્રતિભાવ ગતિ. ડેટા અપડેટ થવા માટે કોઈ 20-30 સેકન્ડ રાહ જોશે નહીં. નેવિગેશન 4-5 સેકન્ડની અંદર અથવા વધુ સારું, તરત જ થઈ જવું જોઈએ. અને અમે, અરે, આ પ્રાપ્ત કરવામાં નિષ્ફળ ગયા.

અમારા મુખ્ય ડેશબોર્ડનું લેઆઉટ આના જેવું દેખાતું હતું:

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

વિગત 1. ડેટા વોલ્યુમ

વાર્ષિક વેચાણ માટેનું અમારું મુખ્ય ટેબલ લગભગ 300 મિલિયન પંક્તિઓ લે છે. ગયા વર્ષ અને તેના એક વર્ષ પહેલાની ગતિશીલતાને પ્રતિબિંબિત કરવી જરૂરી હોવાથી, એકલા વાસ્તવિક વેચાણ પરના ડેટાનું પ્રમાણ લગભગ 1 અબજ લીટીઓ છે. આયોજિત ડેટા અને ઑનલાઇન વેચાણ બ્લોક પરની માહિતી પણ અલગથી સંગ્રહિત કરવામાં આવે છે. તેથી, અમે કૉલમર ઇન-મેમરી DB SAP HANA નો ઉપયોગ કર્યો હોવા છતાં, ફ્લાય પરના વર્તમાન સ્ટોરેજમાંથી એક અઠવાડિયા માટે તમામ સૂચકાંકોની પસંદગી સાથેની ક્વેરી ની ઝડપ લગભગ 15-20 સેકન્ડ હતી. આ સમસ્યાનો ઉકેલ પોતે સૂચવે છે - ડેટાનું વધારાનું ભૌતિકીકરણ. પરંતુ તેમાં ખામીઓ પણ છે, તેમના વિશે નીચે વધુ.

વિગત 2. નોન-એડિટિવ સૂચકાંકો

અમારા ઘણા KPI રસીદોની સંખ્યા સાથે જોડાયેલા છે. અને આ સૂચક પંક્તિઓની સંખ્યાના COUNT DISTINCT (હેડરો તપાસો) દર્શાવે છે અને પસંદ કરેલ વિશેષતાઓને આધારે અલગ-અલગ રકમો દર્શાવે છે. ઉદાહરણ તરીકે, આ સૂચક અને તેના વ્યુત્પન્નની ગણતરી કેવી રીતે કરવી જોઈએ:

તમારી ગણતરીઓને સાચી બનાવવા માટે, તમે આ કરી શકો છો:

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

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

વિગત 3. ડેટા સરખામણી

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

પાછલા સમયગાળા સાથે સરખામણી (દિવસથી દિવસ, અઠવાડિયાથી સપ્તાહ, મહિનાથી મહિના)

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

ગયા વર્ષ સાથે સરખામણી

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

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

ભાગ 1: ટેબ્લોમાં વિશ્વાસ

IT સપોર્ટને સરળ બનાવવા અને ફેરફારોને ઝડપથી અમલમાં મૂકવા માટે, અમે નોન-એડિટિવ સૂચકાંકોની ગણતરી કરવા અને ટેબ્લોમાં ભૂતકાળના સમયગાળાની સરખામણી કરવા માટે તર્ક બનાવવાનું નક્કી કર્યું છે.

સ્ટેજ 1. બધું લાઈવ છે, કોઈ વિન્ડો ફેરફાર નથી.

આ તબક્કે, અમે વર્તમાન સ્ટોરફ્રન્ટ્સ સાથે ટેબ્લો કનેક્ટ કર્યું અને એક વર્ષ માટેની રસીદોની સંખ્યા કેવી રીતે ગણવામાં આવશે તે જોવાનું નક્કી કર્યું.

પરિણામ:

જવાબ હતાશાજનક હતો - 20 મિનિટ. નેટવર્ક પર ડેટાનું ટ્રાન્સફર, ટેબ્લો પર વધુ ભાર. અમને સમજાયું કે HANA પર નોન-એડિટિવ સૂચકાંકો સાથેનો તર્ક લાગુ કરવાની જરૂર છે. આનાથી અમને બહુ ડર ન લાગ્યો, અમને પહેલેથી જ BO અને એનાલિસિસનો સમાન અનુભવ હતો અને અમે જાણીએ છીએ કે HANA માં ઝડપી શોકેસ કેવી રીતે બનાવવું કે જે યોગ્ય રીતે ગણતરી કરેલ નોન-એડિટિવ સૂચકાંકો ઉત્પન્ન કરે. હવે ફક્ત તેમને ટેબ્લોમાં ગોઠવવાનું બાકી હતું.

સ્ટેજ 2. અમે ડિસ્પ્લે કેસને ટ્યુન કરીએ છીએ, કોઈ ભૌતિકકરણ નથી, બધું જ ફ્લાય પર છે.

અમે એક અલગ નવો શોકેસ બનાવ્યો છે જે ફ્લાય પર TABLEAU માટે જરૂરી ડેટા ઉત્પન્ન કરે છે. સામાન્ય રીતે, અમને સારું પરિણામ મળ્યું; અમે એક અઠવાડિયામાં તમામ સૂચકાંકો જનરેટ કરવાનો સમય ઘટાડીને 9-10 સેકન્ડ કર્યો. અને અમે પ્રામાણિકપણે અપેક્ષા રાખીએ છીએ કે ટેબ્લોમાં ડેશબોર્ડનો પ્રતિસાદ સમય પ્રથમ ઓપનિંગમાં 20-30 સેકન્ડનો હશે અને પછી 10 થી 12 સુધીના કેશને કારણે, જે સામાન્ય રીતે અમને અનુકૂળ રહેશે.

પરિણામ:

પ્રથમ ઓપન ડેશબોર્ડ: 4-5 મિનિટ
કોઈપણ ક્લિક: 3-4 મિનિટ
સ્ટોરફ્રન્ટના કામમાં આટલા વધારાના વધારાની અપેક્ષા કોઈને નહોતી.

ભાગ 2. ટેબ્લો માં ડાઇવ

સ્ટેજ 1. ટેબ્લો પ્રદર્શન વિશ્લેષણ અને ઝડપી ટ્યુનિંગ

અમે વિશ્લેષણ કરવાનું શરૂ કર્યું કે ટેબ્લો તેનો મોટાભાગનો સમય ક્યાં વિતાવે છે. અને આ માટે ઘણા સારા સાધનો છે, જે, અલબત્ત, ટેબ્લોનું વત્તા છે. અમે જે મુખ્ય સમસ્યા ઓળખી છે તે ખૂબ જ જટિલ SQL ક્વેરીઝ હતી જે ટેબ્લો બનાવી રહી હતી. તેઓ મુખ્યત્વે આની સાથે સંકળાયેલા હતા:

- ડેટા ટ્રાન્સપોઝિશન. ટેબ્લો પાસે ડેટાસેટ્સ ટ્રાન્સપોઝ કરવા માટેના સાધનો ન હોવાથી, તમામ KPIsની વિગતવાર રજૂઆત સાથે ડેશબોર્ડની ડાબી બાજુ બનાવવા માટે, અમારે કેસનો ઉપયોગ કરીને ટેબલ બનાવવું પડ્યું. ડેટાબેઝમાં SQL ક્વેરીઝનું કદ 120 અક્ષરો સુધી પહોંચી ગયું છે.

- સમય અવધિની પસંદગી. ડેટાબેઝ સ્તર પર આવી ક્વેરી એક્ઝેક્યુટ કરવા કરતાં કમ્પાઈલ કરવામાં વધુ સમય લે છે:

તે. વિનંતી પ્રક્રિયા 12 સેકન્ડ + 5 સેકન્ડ અમલ.

અમે ટેબ્લો બાજુ પર ગણતરીના તર્કને સરળ બનાવવા અને ગણતરીના બીજા ભાગને સ્ટોરફ્રન્ટ અને ડેટાબેઝ સ્તર પર ખસેડવાનું નક્કી કર્યું. આનાથી સારા પરિણામો આવ્યા.

પ્રથમ, અમે ફ્લાય પર ટ્રાન્સપોઝિશન કર્યું, અમે વિકિ પર વર્ણવેલ આ અભિગમ અનુસાર, VIEW ગણતરીના અંતિમ તબક્કે સંપૂર્ણ બાહ્ય જોડાણ દ્વારા કર્યું. ટ્રાન્સપોઝ - વિકિપીડિયા, મફત જ્ઞાનકોશ и પ્રાથમિક મેટ્રિક્સ - વિકિપીડિયા, મફત જ્ઞાનકોશ.

એટલે કે, અમે એક સેટિંગ ટેબલ બનાવ્યું - એક ટ્રાન્સપોઝિશન મેટ્રિક્સ (21x21) અને એક પંક્તિ-દર-પંક્તિ ભંગાણમાં તમામ સૂચકાંકો પ્રાપ્ત કર્યા.

હતી:


તે બન્યું:


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

પરિણામે, ડેશબોર્ડની ઝડપ લગભગ 3 ગણી ઘટી ગઈ.

પરિણામ:

1. 5 સેકન્ડ - ડેશબોર્ડ્સ, વિઝ્યુલાઇઝેશનનું પાર્સિંગ
2. 15-20 સેકન્ડ - ટેબ્લોમાં પૂર્વ ગણતરીઓ કરવા સાથે પ્રશ્નોના સંકલન માટેની તૈયારી
3. 35-45 સેકન્ડ - એસક્યુએલ ક્વેરીઝનું સંકલન અને હાનામાં તેમના સમાંતર-ક્રમિક અમલ
4. 5 સેકન્ડ - પરિણામોની પ્રક્રિયા, સૉર્ટિંગ, ટેબ્લોમાં વિઝ્યુલાઇઝેશનની પુનઃ ગણતરી
5. અલબત્ત, આવા પરિણામો વ્યવસાયને અનુકૂળ ન હતા, અને અમે ઑપ્ટિમાઇઝેશન ચાલુ રાખ્યું.

સ્ટેજ 2. ટેબ્લોમાં ન્યૂનતમ તર્ક, સંપૂર્ણ ભૌતિકીકરણ

અમે સમજી ગયા કે 10 સેકન્ડ સુધી ચાલતા સ્ટોરફ્રન્ટ પર ઘણી સેકન્ડના પ્રતિભાવ સમય સાથે ડેશબોર્ડ બનાવવું અશક્ય છે અને અમે ડેટાબેઝ બાજુ પર ડેટાને મટીરિયલાઇઝ કરવા માટેના વિકલ્પો ખાસ કરીને જરૂરી ડેશબોર્ડ માટે ધ્યાનમાં લીધા. પરંતુ અમે ઉપર વર્ણવેલ વૈશ્વિક સમસ્યાનો સામનો કરવો પડ્યો - નોન-એડિટિવ સૂચકાંકો. અમે એ સુનિશ્ચિત કરવામાં અસમર્થ હતા કે ફિલ્ટર્સ અથવા ડ્રિલડાઉન્સ બદલતી વખતે, ટેબ્લો વિવિધ સ્ટોરફ્રન્ટ્સ અને વિવિધ પ્રોડક્ટ વંશવેલો માટે પૂર્વ-ડિઝાઇન કરેલા સ્તરો વચ્ચે લવચીક રીતે સ્વિચ કરે છે (ઉદાહરણ તરીકે, UTE વગરની ત્રણ ક્વેરી, UTE1 અને UTE2 સાથે વિવિધ પરિણામો ઉત્પન્ન કરે છે). તેથી, અમે ડેશબોર્ડને સરળ બનાવવાનું, ડેશબોર્ડમાં ઉત્પાદન વંશવેલો છોડી દેવાનું અને સરળ સંસ્કરણમાં તે કેટલું ઝડપી હોઈ શકે તે જોવાનું નક્કી કર્યું.

તેથી, આ છેલ્લા તબક્કે, અમે એક અલગ રીપોઝીટરી એસેમ્બલ કરી જેમાં અમે તમામ KPIsને ટ્રાન્સપોઝ કરેલ સ્વરૂપમાં ઉમેર્યા. ડેટાબેઝ બાજુએ, આવા સ્ટોરેજ માટેની કોઈપણ વિનંતી 0,1 - 0,3 સેકન્ડમાં પ્રક્રિયા કરવામાં આવે છે. ડેશબોર્ડમાં અમને નીચેના પરિણામો મળ્યા છે:

પ્રથમ ઉદઘાટન: 8-10 સેકન્ડ
કોઈપણ ક્લિક: 6-7 સેકન્ડ

ટેબ્લો દ્વારા વિતાવેલા સમયનો સમાવેશ થાય છે:

1. 0,3 સે. - ડેશબોર્ડ પાર્સિંગ અને SQL પ્રશ્નોનું સંકલન
2. 1,5-3 સે. - મુખ્ય વિઝ્યુલાઇઝેશન માટે હાનામાં SQL ક્વેરીઝનો અમલ (પગલું 1 સાથે સમાંતર ચાલે છે)
3. 1,5-2 સે. - રેન્ડરીંગ, વિઝ્યુલાઇઝેશનની પુનઃ ગણતરી
4. 1,3 સે. - સંબંધિત ફિલ્ટર મૂલ્યો (બ્રાન્ડ, ડિવિઝન, શહેર, સ્ટોર), પાર્સિંગ પરિણામો મેળવવા માટે વધારાની SQL ક્વેરીઝનો અમલ

ટૂંકમાં તેનો સારાંશ આપવા માટે

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

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

1. ટેબ્લો મોટી માત્રામાં ડેટા સાથે કામ કરી શકતું નથી. જો મૂળ ડેટા મોડેલમાં તમારી પાસે 10 GB થી વધુ ડેટા (આશરે 200 મિલિયન X 50 પંક્તિઓ) છે, તો ડેશબોર્ડ ગંભીરપણે ધીમું થઈ જશે - દરેક ક્લિક માટે 10 સેકન્ડથી લઈને ઘણી મિનિટ સુધી. અમે લાઇવ-કનેક્ટ અને અર્ક બંને સાથે પ્રયોગ કર્યો. ઓપરેટિંગ ઝડપ તુલનાત્મક છે.
2. બહુવિધ સ્ટોરેજ (ડેટાસેટ્સ) નો ઉપયોગ કરતી વખતે મર્યાદા માનક માધ્યમોનો ઉપયોગ કરીને ડેટાસેટ્સ વચ્ચેનો સંબંધ દર્શાવવાનો કોઈ રસ્તો નથી. જો તમે ડેટાસેટ્સને કનેક્ટ કરવા માટે વર્કઅરાઉન્ડનો ઉપયોગ કરો છો, તો આ પ્રભાવને ખૂબ અસર કરશે. અમારા કિસ્સામાં, અમે દરેક જરૂરી વ્યુ સેક્શનમાં ડેટાને મટિરિયલાઇઝ કરવાનો અને અગાઉ પસંદ કરેલા ફિલ્ટર્સને સાચવીને આ મટિરિયલાઇઝ્ડ ડેટાસેટ્સ પર સ્વિચ કરવાનો વિકલ્પ ધ્યાનમાં લીધો - આ ટેબ્લોમાં કરવું અશક્ય હોવાનું બહાર આવ્યું.
3. ટેબ્લોમાં ગતિશીલ પરિમાણો બનાવવાનું શક્ય નથી. ડેટાસેટમાંથી અન્ય પસંદગીના પરિણામ અથવા અન્ય SQL ક્વેરીનાં પરિણામ સાથે, ફક્ત મૂળ વપરાશકર્તા ઇનપુટ અથવા સ્થિરતા સાથે તમે એક પરિમાણ ભરી શકતા નથી કે જેનો ઉપયોગ અર્કમાં અથવા લાઇવ-કનેક્ટ દરમિયાન ડેટાસેટને ફિલ્ટર કરવા માટે થાય છે.
4. OLAP|PivotTable તત્વો સાથે ડેશબોર્ડ બનાવવા સાથે સંકળાયેલ મર્યાદાઓ.
   MSTR, SAP SAC, SAP એનાલિસિસમાં, જો તમે રિપોર્ટમાં ડેટાસેટ ઉમેરો છો, તો તેના પરના તમામ ઑબ્જેક્ટ્સ ડિફૉલ્ટ રૂપે એકબીજા સાથે સંબંધિત છે. ટેબ્લોમાં આ નથી; કનેક્શન મેન્યુઅલી ગોઠવેલું હોવું જોઈએ. આ કદાચ વધુ લવચીક છે, પરંતુ અમારા બધા ડેશબોર્ડ્સ માટે આ તત્વો માટે ફરજિયાત આવશ્યકતા છે - તેથી આ વધારાના શ્રમ ખર્ચ છે. તદુપરાંત, જો તમે સંબંધિત ફિલ્ટર્સ બનાવો છો જેથી કરીને, ઉદાહરણ તરીકે, જ્યારે કોઈ પ્રદેશને ફિલ્ટર કરતી વખતે, શહેરોની સૂચિ ફક્ત આ પ્રદેશના શહેરો સુધી મર્યાદિત હોય, તો તમે તરત જ ડેટાબેઝ અથવા એક્સ્ટ્રેક્ટમાં ક્રમિક ક્વેરીઝ સાથે સમાપ્ત કરો છો, જે નોંધપાત્ર રીતે ધીમું કરે છે. ડેશબોર્ડ.
5. કાર્યોમાં મર્યાદાઓ. સામૂહિક પરિવર્તન કાં તો અર્ક પર અથવા, ખાસ કરીને, Live-connecta ના ડેટાસેટ પર કરી શકાતું નથી. આ ટેબ્લો પ્રેપ દ્વારા કરી શકાય છે, પરંતુ તે વધારાનું કાર્ય છે અને શીખવા અને જાળવવાનું બીજું સાધન છે. ઉદાહરણ તરીકે, તમે ડેટા ટ્રાન્સપોઝ કરી શકતા નથી અથવા તેની સાથે જોડાઈ શકતા નથી. વ્યક્તિગત કૉલમ્સ અથવા ફીલ્ડ્સ પર પરિવર્તન દ્વારા શું બંધ થાય છે, જે કેસ અથવા જો દ્વારા પસંદ કરવું આવશ્યક છે, અને આ ખૂબ જ જટિલ SQL ક્વેરીઝ જનરેટ કરે છે, જેમાં ડેટાબેઝ તેનો મોટાભાગનો સમય ક્વેરી ટેક્સ્ટને કમ્પાઇલ કરવામાં વિતાવે છે. ટૂલની આ અસમર્થતાને શોકેસ સ્તરે ઉકેલવાની હતી, જે વધુ જટિલ સ્ટોરેજ, વધારાના ડાઉનલોડ્સ અને પરિવર્તન તરફ દોરી જાય છે.

અમે ટેબ્લો પર છોડ્યું નથી. પરંતુ અમે ટેબ્લ્યુને ઔદ્યોગિક ડેશબોર્ડ્સ બનાવવા માટે સક્ષમ સાધન અને કંપનીની સમગ્ર કોર્પોરેટ રિપોર્ટિંગ સિસ્ટમને બદલવા અને ડિજિટલાઇઝ કરવા માટેના સાધન તરીકે માનતા નથી.

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

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

સોર્સ: www.habr.com