सैंटेंडर के पास रीयल-टाइम डेटा इंजेस्ट आर्किटेक्चर के अंदर (भाग 2)

सेंटेंडर की इंजीनियरिंग टीम के पेड्रो बोडो और एबेल फर्नांडीज अल्फोंसो को इस पोस्ट पर उनके सहयोग के लिए धन्यवाद कि कैसे सैंटेंडर यूके अपने अभिनव स्पेंडेलीटिक्स ऐप को पावर देने के लिए अपाचे एचबीज़ को रीयल-टाइम सर्विंग इंजन के रूप में उपयोग कर रहा है।

स्पेंड्लीटिक्स आईओएस ऐप को सेंटेंडर के व्यक्तिगत डेबिट और क्रेडिट-कार्ड ग्राहकों को ऐप्पल पे के माध्यम से किए गए भुगतान सहित अपने खर्च के शीर्ष पर रखने में मदद करने के लिए डिज़ाइन किया गया है। यह ग्राहकों को समय अवधि (साप्ताहिक, मासिक, वार्षिक), श्रेणी (यात्रा, सुपरमार्केट, नकद, आदि), और खुदरा विक्रेता द्वारा अपने कार्ड खर्च का विश्लेषण करने में सक्षम बनाने के लिए रीयल-टाइम लेनदेन डेटा का उपयोग करता है।

अपनी पिछली पोस्ट में, हमने बताया कि कैसे Apache Flume और Apache Kafka का उपयोग Apache HBase में लेनदेन को बदलने, समृद्ध करने और स्ट्रीम करने के लिए किया जाता है। प्रदर्शन को अनुकूलित करने के लिए Apache HBase में लेन-देन की व्यवस्था कैसे की जाती है, और हम प्रति-ग्राहक खरीद रुझानों के एकत्रीकरण प्रदान करने के लिए सहसंसाधकों का उपयोग कैसे करते हैं, इसका वर्णन करते हुए यह पोस्ट जारी है। Santander और Cloudera ने Spendlytics के साथ एक HBase यात्रा जारी रखी (और अभी भी चल रही है), जिसने स्कीमा डिज़ाइन और कोप्रोसेसर कार्यान्वयन के कई पुनरावृत्तियों और अनुकूलन को देखा है। हम आशा करते हैं कि सीखे गए ये सबक इस पोस्ट के मुख्य बिंदु हैं।

स्कीमा 1.0

अच्छा HBase स्कीमा डिज़ाइन इच्छित पहुँच पैटर्न को समझने के बारे में है। इसे ठीक करें और HBase उड़ जाएगा; इसे गलत समझें और क्षेत्र हॉटस्पॉट जैसे डिज़ाइन ट्रेडऑफ़ या कई क्षेत्रों में बड़े स्कैन करने के कारण आप उप-प्रदर्शन के साथ समाप्त हो सकते हैं। (एक हॉटस्पॉट एक HBase तालिका में वह जगह है जहाँ एक असमान रोकी वितरण के कारण अधिकांश अनुरोध एक ही क्षेत्र में रूट किए जा सकते हैं, जिससे रीजनसर्वर भारी हो जाता है और परिणामस्वरूप धीमी प्रतिक्रिया समय हो जाता है।)

स्पेंड्लीटिक्स के इच्छित एक्सेस पैटर्न के बारे में हम क्या जानते थे और इसने प्रारंभिक स्कीमा डिज़ाइन को कैसे प्रभावित किया:

• ग्राहक केवल अपने खातों पर लेनदेन का विश्लेषण करते हैं:
  • तेजी से रैखिक स्कैन प्रदर्शन के लिए, सभी ग्राहक लेनदेन क्रमिक रूप से संग्रहीत किए जाने चाहिए।
• ग्राहक आईडी एकरस रूप से बढ़ रही हैं:
  • अनुक्रमिक ग्राहक आईडी इस संभावना को बढ़ाते हैं कि नए ग्राहक एक ही क्षेत्र में सह-स्थित होंगे, संभावित रूप से एक क्षेत्र हॉट स्पॉट बना रहे हैं। इस समस्या से बचने के लिए, जब पंक्तिकी की शुरुआत में उपयोग किया जाता है, तो ग्राहक आईडी को नमकीन (उपसर्ग) या सभी क्षेत्रों में समान वितरण के लिए उलट दिया जाना चाहिए।
• ग्राहकों के पास एक से अधिक कार्ड हैं
  • स्कैन को ऑप्टिमाइज़ करने के लिए, ग्राहक के लेन-देन को कार्ड अनुबंध के आधार पर और समूहबद्ध और क्रमबद्ध किया जाना चाहिए, यानी अनुबंध आईडी पंक्ति-कुंजी का हिस्सा होना चाहिए।
• लेन-देन को उनकी संपूर्णता में एक्सेस किया जाएगा, यानी खुदरा विक्रेता, व्यापारी, स्थान, मुद्रा और राशि जैसी विशेषताओं को अलग से पढ़ने की आवश्यकता नहीं है
  • लेन-देन विशेषताओं को अलग-अलग कक्षों में संग्रहीत करने से एक व्यापक, विरल तालिका प्राप्त होगी, जिससे खोज समय में वृद्धि होगी। चूंकि विशेषताओं को एक साथ एक्सेस किया जाएगा, इसलिए अपाचे एवरो रिकॉर्ड में उन्हें एक साथ क्रमबद्ध करना समझ में आता है। एवरो कॉम्पैक्ट है और हमें स्कीमा विकसित करने की क्षमता के साथ एक कुशल प्रतिनिधित्व प्रदान करता है।
• लेन-देन व्यक्तिगत रूप से, बैचों में (समय, श्रेणी और खुदरा विक्रेता के अनुसार), और कुल मिलाकर (समय, श्रेणी और खुदरा विक्रेता द्वारा) एक्सेस किए जाते हैं।
  • एक अद्वितीय लेन-देन आईडी को कॉलम क्वालिफायर के रूप में जोड़ने से पंक्ति-कुंजी में अधिक जटिलता जोड़े बिना व्यक्तिगत लेनदेन की पुनर्प्राप्ति की अनुमति मिल जाएगी।
  • परिवर्तनशील समयावधियों में लेनदेन की तेजी से स्कैनिंग को सक्षम करने के लिए, लेन-देन टाइमस्टैम्प को पंक्ति-कुंजी का हिस्सा बनाना चाहिए।
  • रोकी में श्रेणी और खुदरा विक्रेता जोड़ना बहुत बारीक हो सकता है और इसके परिणामस्वरूप एक जटिल पंक्ति कुंजी के साथ एक बहुत लंबी और संकीर्ण तालिका होगी। लंबा और संकरा होना ठीक है क्योंकि परमाणुता कोई समस्या नहीं है, लेकिन उन्हें कॉलम क्वालिफायर के रूप में रखने से द्वितीयक एकत्रीकरण का समर्थन करते हुए तालिका का विस्तार होगा।
• पढ़ने के प्रदर्शन को अनुकूलित करने के लिए रुझान डेटा को यथासंभव पूर्व-गणना की जानी चाहिए।
  • इस पर और बाद में, लेकिन अभी के लिए यह जान लें कि हमने रुझानों को संग्रहीत करने के लिए एक दूसरा स्तंभ परिवार जोड़ा है।

  उपरोक्त के आधार पर, प्रारंभिक स्कीमा डिज़ाइन को इस प्रकार दर्शाया गया है:

  

  कंप्यूटिंग रुझान

  प्रारंभिक डिजाइन का पहलू जो हमने सबसे ज्यादा सीखा, वह था कंप्यूटिंग ट्रेंड। आवश्यकता यह थी कि ग्राहकों को श्रेणी और खुदरा विक्रेता द्वारा घंटे के हिसाब से अपने खर्च का विश्लेषण करने में सक्षम बनाया जाए। डेटा बिंदुओं में सबसे छोटा और सबसे बड़ा लेनदेन मूल्य, कुल लेनदेन मूल्य और लेनदेन की संख्या शामिल थी। प्रतिक्रिया समय 200ms या उससे कम होना चाहिए।

  प्रीकंप्यूटिंग रुझान हमें सबसे तेज़ प्रतिक्रिया समय देंगे इसलिए यह हमारा पहला दृष्टिकोण था। रुझान लेन-देन से पीछे नहीं रह सकते थे इसलिए उनकी गणना लेखन पथ पर की जानी थी। यह पढ़ने के प्रदर्शन के लिए बहुत अच्छा होगा, लेकिन हमें कुछ चुनौतियों के साथ प्रस्तुत किया:HBase में रुझानों को सबसे अच्छा कैसे व्यवस्थित किया जाए, और लेखन प्रदर्शन को गंभीर रूप से प्रभावित किए बिना उनकी जल्दी और मज़बूती से गणना कैसे की जाए।

  हमने विभिन्न स्कीमा डिज़ाइनों के साथ प्रयोग किया और जहाँ संभव हो कुछ प्रसिद्ध डिज़ाइनों का लाभ उठाने का प्रयास किया (जैसे कि OpenTSDB की स्कीमा)। कई पुनरावृत्तियों के बाद हम ऊपर दिखाए गए स्कीमा डिज़ाइन पर बस गए। लेन-देन तालिका में संग्रहीत, एक अलग कॉलम परिवार में, प्रवृत्ति मान एक पंक्ति में एक साथ व्यवस्थित होते हैं, प्रति ग्राहक एक प्रवृत्ति पंक्ति के साथ। Rowkey को ग्राहक के लेन-देन के समान उपसर्ग देकर (उदाहरण के लिए, <reverse_customer_id>::<contract_id> ) यह सुनिश्चित करता है कि रुझान पंक्ति को संबंधित ग्राहक के लेनदेन रिकॉर्ड के साथ क्रमबद्ध किया जाएगा। परिभाषित क्षेत्र सीमाओं और एक कस्टम क्षेत्र विभाजन नीति के साथ, हम यह भी गारंटी दे सकते हैं कि प्रवृत्ति पंक्ति हमेशा ग्राहक के लेन-देन रिकॉर्ड के साथ मिल जाएगी, जिससे प्रवृत्ति एकत्रीकरण पूरी तरह से कोप्रोसेसर में सर्वर-साइड रहने के लिए सक्षम होगा।

  प्रवृत्तियों को पूर्व-गणना करने के लिए, हमने एक कस्टम पर्यवेक्षक सहसंसाधक . लागू किया लेखन पथ में शामिल होने के लिए। (पर्यवेक्षक सहसंसाधक RDBMS में ट्रिगर के समान होते हैं, जिसमें वे किसी विशिष्ट घटना के होने से पहले या बाद में उपयोगकर्ता कोड निष्पादित करते हैं। उदाहरण के लिए, Put पूर्व या पोस्ट करें। या Get ।)

  postPut पर सहसंसाधक निम्नलिखित क्रियाएं करता है:

  1. चेक करता है Put एक प्रवृत्ति विशेषता (ध्वज) के लिए। प्रवृत्ति रिकॉर्ड को अपडेट करते समय पुनरावर्ती कॉल से बचने के लिए विशेषता केवल नए लेनदेन रिकॉर्ड पर सेट की गई है। यह कोप्रोसेसर को Put . के लिए छोड़े जाने की भी अनुमति देता है जिन रुझानों को अपडेट करने की आवश्यकता नहीं है (उदा. बस्तियां )।
  2. ग्राहक के लिए ट्रेंड रिकॉर्ड प्राप्त करें। एक ग्राहक के ट्रेंड रिकॉर्ड को उनके लेन-देन (रोकी उपसर्ग के आधार पर) के साथ जोड़ा जाता है ताकि सहसंसाधक इसे वर्तमान क्षेत्र से सीधे प्राप्त कर सके। समानांतर में रुझानों को अपडेट करने की कोशिश कर रहे कई रीजनसर्वर हैंडलर थ्रेड्स को रोकने के लिए ट्रेंड रो को लॉक करना होगा।
  3. डेटा बिंदु अपडेट करें:
  4. रुझान पंक्ति को अपडेट और अनलॉक करें।

  परीक्षण के दौरान समाधान सटीक साबित हुआ, और अपेक्षित पठन प्रदर्शन आवश्यकताओं को पार कर गया। हालाँकि, इस दृष्टिकोण के साथ कुछ चिंताएँ थीं। पहला यह था कि विफलता को कैसे संभाला जाए:प्रवृत्तियों को एक अलग पंक्ति में संग्रहीत किया जाता है ताकि परमाणुता की गारंटी नहीं दी जा सके। दूसरा यह था कि समय के साथ रुझानों की सटीकता को कैसे सत्यापित किया जाए; यानी, हमें किसी भी प्रवृत्ति की अशुद्धि की पहचान करने और उसे दूर करने के लिए एक तंत्र को लागू करने की आवश्यकता होगी। जब हमने HA आवश्यकताओं और इस तथ्य पर भी विचार किया कि हमें विभिन्न डेटा केंद्रों में HBase के दो, सक्रिय-सक्रिय उदाहरणों को चलाने की आवश्यकता होगी, तो यह एक बड़ी समस्या हो सकती है। न केवल समय के साथ प्रवृत्ति सटीकता में कमी आ सकती है, बल्कि दो समूहों में भी बहाव हो सकता है और जिस पद्धति का उपयोग हम उन्हें सिंक्रनाइज़ करने के लिए करते हैं, उसके आधार पर उन्हें समेटना होगा। अंत में, बग्स को ठीक करना या नए डेटा पॉइंट जोड़ना मुश्किल होगा क्योंकि हमें संभवतः सभी रुझानों को पीछे से ट्रैक और पुनर्गणना करना होगा।

  इसके बाद लेखन प्रदर्शन हुआ। प्रत्येक नए लेन-देन के लिए पर्यवेक्षक को एक प्रवृत्ति रिकॉर्ड प्राप्त करना था, 32 डेटा बिंदुओं को अपडेट करना था, और प्रवृत्ति रिकॉर्ड को वापस रखना था। यह सब एक ही क्षेत्र की सीमा के भीतर होने के बावजूद, हमने पाया कि थ्रूपुट 20,000 से अधिक राइट्स प्रति सेकंड से घटकर 1,000 राइट्स प्रति सेकंड (प्रति रीजनसेवर) हो गया। यह प्रदर्शन अल्पावधि में स्वीकार्य था, लेकिन अनुमानित दीर्घकालिक भार का समर्थन करने के लिए इसका पैमाना नहीं होगा।

  हम जानते थे कि लेखन प्रदर्शन एक जोखिम था इसलिए हमारे पास एक बैकअप योजना थी, और वह एक समापन बिंदु कोप्रोसेसर था . एंडपॉइंट कोप्रोसेसर RDBMS में संग्रहीत कार्यविधियों के समान होते हैं, जिसमें वे आपको सर्वर-साइड गणना करने की अनुमति देते हैं - उस क्षेत्र सर्वर पर जहां डेटा स्थित है, न कि क्लाइंट पर। समापन बिंदु प्रभावी रूप से HBase API का विस्तार करते हैं।

  प्रीकंप्यूटिंग प्रवृत्तियों के बजाय, एंडपॉइंट उन्हें फ्लाई, सर्वर-साइड पर गणना करता है। परिणामस्वरूप हम ट्रेंड कॉलम परिवार को स्कीमा से हटा सकते हैं और अशुद्धि और विचलन का जोखिम इसके साथ चला गया। प्रेक्षक से दूर जाने के परिणामस्वरूप अच्छा लेखन प्रदर्शन हुआ, लेकिन क्या पठन पर्याप्त तेज़ होगा? संक्षेप में, हाँ। एक ग्राहक के लेन-देन के साथ एक ही क्षेत्र तक सीमित और कार्ड और टाइमस्टैम्प द्वारा क्रमबद्ध, एंडपॉइंट स्कैन और तेजी से एकत्र कर सकता है, अच्छी तरह से स्पेंलिटिक्स के 200ms उद्देश्य के भीतर। इसका यह भी अर्थ है कि एक क्लाइंट अनुरोध (इस मामले में स्पेंड्लीटिक्स एपीआई से) केवल एक एंडपॉइंट इंस्टेंस (एकल रीजनसेवर) के लिए रूट किया जाता है और क्लाइंट को एक पूर्ण परिणाम के साथ एक ही प्रतिक्रिया वापस मिल जाएगी-यानी कोई क्लाइंट-साइड नहीं एकाधिक समापन बिंदुओं से आंशिक परिणामों को एकत्रित करने के लिए प्रसंस्करण की आवश्यकता होती है, जो कि ऐसा होगा यदि ग्राहक के लेन-देन कई क्षेत्रों में फैले हुए हैं।

  सबक सीखा

  स्पेंड्लीटिक्स जुलाई 2015 से लाइव है। तब से हमने एक्सेस पैटर्न की बारीकी से निगरानी की है और प्रदर्शन को अनुकूलित करने के तरीकों पर गौर किया है। हम लगातार उपयोगकर्ता अनुभव में सुधार करना चाहते हैं और ग्राहकों को उनके कार्ड खर्च में अधिक से अधिक अंतर्दृष्टि प्रदान करना चाहते हैं। इस पोस्ट के शेष भाग में उन पाठों का वर्णन किया गया है जो हमने उत्पादन में स्पेंड्लीटिक्स चलाने से सीखे हैं और कुछ अनुकूलन जो लागू किए गए हैं।

  प्रारंभिक रिलीज के बाद हमने कई दर्द बिंदुओं की पहचान की जिन्हें हम सुधारने पर ध्यान केंद्रित करना चाहते थे। पहला यह था कि लेन-देन विशेषता द्वारा परिणामों को कैसे फ़िल्टर किया जाए। जैसा कि पहले उल्लेख किया गया है, लेन-देन विशेषताओं को एवरो रिकॉर्ड में एन्कोड किया गया है, लेकिन हमने पाया कि एक्सेस पैटर्न की बढ़ती संख्या विशेषता द्वारा फ़िल्टर करना चाहती थी और उपयोगकर्ताओं को यह क्लाइंट-साइड करने के लिए मजबूर किया गया था। प्रारंभिक समाधान एक कस्टम HBase को लागू करना था ValueFilter जिसने हमारे अपने जटिल फ़िल्टर एक्सप्रेशन को स्वीकार किया, उदाहरण के लिए:

  category='SUPERMARKETS' AND amount > 100 AND 
  (brand LIKE 'foo%' OR brand = 'bar')

  प्रत्येक एवरो रिकॉर्ड के लिए एक्सप्रेशन का मूल्यांकन किया जाता है, जिससे हम परिणाम सर्वर-साइड को फ़िल्टर कर सकते हैं और क्लाइंट को लौटाए जाने वाले डेटा की मात्रा को कम कर सकते हैं (नेटवर्क बैंडविड्थ और क्लाइंट-साइड प्रोसेसिंग की बचत)। फ़िल्टर स्कैन प्रदर्शन को प्रभावित करता है, लेकिन प्रतिक्रिया समय 200ms उद्देश्य के भीतर ही रहता है।

  लेखन को अनुकूलित करने के लिए आवश्यक और परिवर्तनों के कारण यह एक अस्थायी समाधान बन गया। क्रेडिट-कार्ड निपटान प्रक्रिया के काम करने के तरीके के कारण, हमें सबसे पहले एक अधिकृत प्राप्त होता है बिक्री के समय से लेन-देन (लगभग वास्तविक समय में) और फिर कुछ समय बाद बस गया क्रेडिट-कार्ड नेटवर्क से लेनदेन (बैच में)। अनिवार्य रूप से बसे . को मर्ज करके इन लेन-देनों को समेटने की आवश्यकता है अधिकृत . के साथ लेनदेन पहले से ही HBase में लेनदेन, लेनदेन आईडी पर शामिल होना। इस प्रक्रिया के भाग के रूप में लेन-देन विशेषताएँ बदल सकती हैं और नई विशेषताएँ जोड़ी जा सकती हैं। एकल विशेषताओं को अपडेट करते समय भी पूरे एवरो रिकॉर्ड को फिर से लिखने के ऊपरी हिस्से के कारण यह दर्दनाक साबित हुआ। इसलिए अपडेट के लिए विशेषताओं को अधिक सुलभ बनाने के लिए हमने उन्हें एवरो क्रमांकन की जगह, कॉलम में व्यवस्थित किया।

  हम केवल लेन-देन-स्तर की परमाणुता की भी परवाह करते हैं, इसलिए लेन-देन को घंटे के हिसाब से बकेट करने से हमें कोई फायदा नहीं हुआ। इसके अलावा, बस गए लेन-देन जो अब बैच में आते हैं, उनमें केवल दिन-स्तर की ग्रैन्युलैरिटी होती है, जिससे मौजूदा अधिकृत के साथ उनका मिलान करना मुश्किल (महंगा) हो जाता है। घंटे द्वारा संग्रहीत लेनदेन। इस समस्या को हल करने के लिए, हमने लेन-देन आईडी को रोकी में स्थानांतरित कर दिया और टाइमस्टैम्प अनाज को घंटों के बजाय दिनों में घटा दिया। समाधान प्रक्रिया अब बहुत आसान हो गई है क्योंकि हम केवल HBase में परिवर्तनों को बल्क लोड कर सकते हैं और निपटान कर सकते हैं मूल्यों को प्राथमिकता दी जाती है।

  संक्षेप में:

  • पर्यवेक्षक सहसंसाधक एक मूल्यवान उपकरण हो सकते हैं, लेकिन उनका बुद्धिमानी से उपयोग करें।
  • कुछ उपयोग के मामलों के लिए, समापन बिंदुओं का उपयोग करके HBase API का विस्तार करना एक अच्छा विकल्प है।
  • परिणाम सर्वर-साइड ट्रिम करके प्रदर्शन को बेहतर बनाने के लिए कस्टम फ़िल्टर का उपयोग करें।
  • सीरियलाइज़्ड मान सही उपयोग के मामले के लिए समझ में आता है, लेकिन फ़ील्ड और कॉलम के लिए मूल समर्थन का समर्थन करके HBase की ताकत के लिए खेलते हैं।
  • पूर्व-गणना परिणामों को प्रबंधित करना कठिन है; ऑन-द-फ्लाई कंप्यूटिंग से अतिरिक्त विलंबता सार्थक हो सकती है।
  • एक्सेस पैटर्न बदल जाएगा, इसलिए चुस्त रहें और गेम में आगे रहने के लिए HBase स्कीमा में बदलाव करने के लिए तैयार रहें।

  रोडमैप

  एक अनुकूलन जिसका हम वर्तमान में मूल्यांकन कर रहे हैं वह है हाइब्रिड कोप्रोसेसर। इससे हमारा तात्पर्य यह है कि प्रवृत्तियों को पूर्व-गणना करने के लिए पर्यवेक्षक और समापन बिंदु सहसंसाधक दोनों का संयोजन है। हालांकि, पहले के विपरीत, हम इसे लिखने के रास्ते पर नहीं बल्कि पृष्ठभूमि में HBase के फ्लश और कॉम्पैक्शन ऑपरेशंस में शामिल करके ऐसा करेंगे। एक प्रेक्षक फ्लश और संघनन घटनाओं के दौरान निपटान . के आधार पर रुझानों की गणना करेगा उस समय उपलब्ध लेनदेन। फिर हम लेन-देन के डेल्टा के ऑन-द-फ्लाई एकत्रीकरण के साथ पूर्व-गणना रुझानों को संयोजित करने के लिए एक समापन बिंदु का उपयोग करेंगे। इस तरह से प्रवृत्तियों को पूर्व-गणना करके हम लेखन प्रदर्शन को प्रभावित किए बिना, पठन को प्रदर्शन में बढ़ावा देने की आशा करते हैं।

  एक अन्य दृष्टिकोण जिसका हम ट्रेंड एग्रीगेशन के लिए मूल्यांकन कर रहे हैं, और सामान्य रूप से HBase एक्सेस के लिए, अपाचे फीनिक्स है। फीनिक्स HBase के लिए एक SQL स्किन है जो मानक JDBC API का उपयोग करके एक्सेस को सक्षम बनाता है। हमें उम्मीद है कि SQL और JDBC का उपयोग करके यह HBase एक्सेस को आसान बना देगा और हमारे द्वारा लिखे जाने वाले कोड की मात्रा को कम कर देगा। हम फीनिक्स के बुद्धिमान निष्पादन पैटर्न का भी लाभ उठा सकते हैं और तेजी से एकत्रीकरण के लिए कोप्रोसेसर और फिल्टर में निर्मित कर सकते हैं। स्पेंलिटिक्स की स्थापना के समय फीनिक्स को उत्पादन के उपयोग के लिए बहुत अपरिपक्व माना जाता था, लेकिन ईबे और सेल्सफोर्स की पसंद द्वारा इसी तरह के उपयोग के मामलों की रिपोर्ट के साथ, अब पुनर्मूल्यांकन करने का समय है। (सीडीएच के लिए एक फीनिक्स पैकेज स्थापना और मूल्यांकन के लिए उपलब्ध है, लेकिन बिना किसी समर्थन के, क्लाउडेरा लैब्स के माध्यम से।)

  सेंटेंडर ने हाल ही में घोषणा की कि यह वॉयस बैंकिंग तकनीक लॉन्च करने वाला पहला बैंक है जो ग्राहकों को अपने स्मार्टबैंक ऐप से बात करने और उनके कार्ड खर्च के बारे में पूछने में सक्षम बनाता है। इस तकनीक के पीछे का मंच क्लौडेरा है, और स्पेंड्लीटिक्स के लिए आर्किटेक्चर—जैसा कि पोस्ट के इस सेट में वर्णित है—ब्लूप्रिंट डिज़ाइन के रूप में कार्य करता है।

  जेम्स किनले क्लोडेरा में एक प्रमुख समाधान वास्तुकार हैं।

  इयान बस क्लौडेरा में एक वरिष्ठ समाधान वास्तुकार हैं।

  पेड्रो बोडो, सैंटेंडर (इस्बान) यूके में एक Hadoop इंजीनियर हैं।

  हाबिल फर्नांडीज अल्फोंसो सेंटेंडर (इस्बान) यूके में एक Hadoop इंजीनियर हैं।