ડેલ્ટા: ડેટા સિંક્રોનાઇઝેશન અને એનરિચમેન્ટ પ્લેટફોર્મ

દરે નવો પ્રવાહ શરૂ થવાની અપેક્ષાએ ડેટા એન્જિનિયર અમે રસપ્રદ સામગ્રીનો અનુવાદ તૈયાર કર્યો છે.

ઝાંખી

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

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

આ સમસ્યાઓ ઉકેલવા માટે ડેલ્ટા વિકસાવવામાં આવી હતી. ડેલ્ટા આખરે ડેટા સિંક્રોનાઇઝેશન અને સંવર્ધન માટે સુસંગત, ઇવેન્ટ-આધારિત પ્લેટફોર્મ પૂરું પાડે છે.

હાલના ઉકેલો

ડબલ એન્ટ્રી

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

સમસ્યાઓ:

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

લોગ ટેબલ બદલો

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

સમસ્યાઓ:

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

બીજી સમસ્યા એવી સિસ્ટમ્સમાં સ્કીમા ફેરફારો મેળવવામાં રહેલી છે જે ટ્રાન્ઝેક્શનલ સ્કીમા ફેરફારો [1][2], જેમ કે MySQL ને સપોર્ટ કરતી નથી. તેથી, ફેરફાર કરવાની પેટર્ન (ઉદાહરણ તરીકે, સ્કીમા ફેરફાર) અને ટ્રાન્ઝેક્શનલી તેને ચેન્જ લોગ ટેબલમાં રેકોર્ડ કરવાની પદ્ધતિ હંમેશા કામ કરશે નહીં.

વિતરિત વ્યવહારો

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

સમસ્યાઓ:

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

ડેલ્ટા

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

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

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

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

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

CDC (ચેન્જ-ડેટા-કેપ્ચર)

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

ડેલ્ટા-કનેક્ટર ઘણી વધારાની સુવિધાઓને સપોર્ટ કરે છે જેમ કે:

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

અમે હાલમાં MySQL અને Postgres ને સપોર્ટ કરીએ છીએ, જેમાં AWS RDS અને Aurora પર જમાવટનો સમાવેશ થાય છે. અમે કસાન્ડ્રા (મલ્ટી-માસ્ટર) ને પણ સમર્થન આપીએ છીએ. તમે અહીં ડેલ્ટા-કનેક્ટર વિશે વધુ વિગતો મેળવી શકો છો બ્લોગ પોસ્ટ.

કાફકા અને પરિવહન સ્તર

ડેલ્ટાનું ઇવેન્ટ ટ્રાન્સપોર્ટ લેયર પ્લેટફોર્મની મેસેજિંગ સર્વિસ પર બનેલ છે કીસ્ટોન.

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

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

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

અમે પણ વધારો કર્યો પ્રતિકૃતિ પરિબળ 2 થી 3 અને ન્યૂનતમ ઇન્સિંક પ્રતિકૃતિઓ 1 થી 2. આ ક્લસ્ટર પર લખનારા પ્રકાશકોને અન્ય તમામ પાસેથી acksની જરૂર પડે છે, તેની ખાતરી કરીને કે 2 માંથી 3 પ્રતિકૃતિમાં પ્રકાશક દ્વારા મોકલવામાં આવેલા સૌથી વર્તમાન સંદેશાઓ છે.

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

ડેટા ડિલિવરી ગેરંટી વધુ વધારવા માટે, અમે ઉપયોગ કર્યો સંદેશ ટ્રેકિંગ સિસ્ટમ આત્યંતિક પરિસ્થિતિઓમાં કોઈપણ સંદેશની ખોટ શોધવા માટે (ઉદાહરણ તરીકે, પાર્ટીશન લીડરમાં ઘડિયાળ ડિસિંક્રોનાઇઝેશન).

સ્ટ્રીમ પ્રોસેસિંગ ફ્રેમવર્ક

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

ડેલ્ટા Flink અને SPaaS પર આધારિત સ્ટ્રીમ પ્રોસેસિંગ ફ્રેમવર્ક પ્રદાન કરે છે જે ઉપયોગ કરે છે ટીકા-આધારિત ડીએસએલ (ડોમેન વિશિષ્ટ ભાષા) અમૂર્ત તકનીકી વિગતો માટે. ઉદાહરણ તરીકે, બાહ્ય સેવાઓને કૉલ કરીને ઇવેન્ટ્સને સમૃદ્ધ કરવામાં આવશે તે પગલાને વ્યાખ્યાયિત કરવા માટે, વપરાશકર્તાઓએ નીચેનું DSL લખવાની જરૂર છે, અને ફ્રેમવર્ક તેના આધારે એક મોડેલ બનાવશે, જે ફ્લિંક દ્વારા ચલાવવામાં આવશે.

આકૃતિ 3. ડેલ્ટામાં DSL પર સંવર્ધનનું ઉદાહરણ

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

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

આકૃતિ 4. ડેલ્ટા સ્ટ્રીમ પ્રોસેસિંગ ફ્રેમવર્ક આર્કિટેક્ચર

આ અભિગમના ઘણા ફાયદા છે:

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

ઉત્પાદન ઉપયોગ

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

આકૃતિ 5. ડેલ્ટાની ઉચ્ચ-સ્તરની આર્કિટેક્ચર.

સ્વીકૃતિઓ

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

સ્ત્રોતો

1. dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
2. dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html
3. માર્ટિન ક્લેપમેન, એલિસ્ટર આર. બેરેસફોર્ડ, બોર્જ સ્વિંગેન: ઑનલાઇન ઇવેન્ટ પ્રોસેસિંગ. કોમ્યુન. ACM 62(5): 43–49 (2019). DOI: doi.org/10.1145/3312527

મફત વેબિનાર માટે સાઇન અપ કરો: "એમેઝોન રેડશિફ્ટ સ્ટોરેજ માટે ડેટા બિલ્ડ ટૂલ."

સોર્સ: www.habr.com