लोड किए गए एमपीपी डीबीएमएस से - विश्लेषणात्मक उपकरणों के साथ क्रियात्मक डेटा झील: सृजन का विवरण साझा करें

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



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

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

• विश्लेषणात्मक CRM, ग्राहक को उसके लिए अधिक सुविधाजनक उत्पादों की पेशकश करने की अनुमति देता है;
  
• ऋण कन्वेयर जो आपको जल्दी और सही तरीके से ऋण पर निर्णय लेने में मदद करते हैं;
  
• वफादारी प्रणाली अलग जटिलता के यांत्रिकी के अनुसार कैशबैक या बोनस अंक की गणना।
  

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

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

समाधान की योजना बनाना

यहां यह स्पष्ट करना आवश्यक है: औद्योगिक सॉफ्टवेयर और सर्वर एक बड़े बैंक के लिए भी एक महंगे सुख हैं। प्रत्येक संगठन शीर्ष एमपीपी डीबीएमएस में बड़ी मात्रा में डेटा स्टोर करने का जोखिम नहीं उठा सकता है। आपको हमेशा कीमत और गति, विश्वसनीयता और मात्रा के बीच चयन करना होगा।

उपलब्ध अवसरों का अधिकतम लाभ उठाने के लिए, हमने यह करने का निर्णय लिया:

• ईएलटी लोड और सीडी के ऐतिहासिक डेटा का सबसे अनुरोधित हिस्सा टेराडाटा डीबीएमएस पर छोड़ा जाना चाहिए;
  
• पूरी कहानी को Hadoop पर शिप करें, जो आपको जानकारी को बहुत सस्ता स्टोर करने की अनुमति देता है।
  

उस समय के आसपास, Hadoop पारिस्थितिकी तंत्र न केवल फैशनेबल हो गया, बल्कि उद्यम के उपयोग के लिए पर्याप्त रूप से विश्वसनीय, सुविधाजनक भी हो गया। वितरण किट चुनना आवश्यक था। आप अपना खुद का निर्माण कर सकते हैं या खुले अपाचे हडोप का उपयोग कर सकते हैं। लेकिन Hadoop पर आधारित उद्यम समाधानों के बीच, अन्य विक्रेताओं से तैयार किए गए वितरण - Cloudera और Hortonworks - अधिक साबित हुए हैं। इसलिए, हमने तैयार वितरण का उपयोग करने का भी निर्णय लिया।

चूँकि हमारा मुख्य कार्य अभी भी संरचित बड़े डेटा का भंडारण कर रहा था, Hadoop स्टैक में हम उन समाधानों में रुचि रखते थे जो शास्त्रीय SQL DBMSs के जितना संभव हो उतना करीब थे। यहां के नेता इम्पाला और हाइव हैं। क्लाउडरा इम्पाला, हॉर्टोनवर्क्स - हाइव समाधानों को विकसित और एकीकृत करता है।

एक गहन अध्ययन के लिए, हमने दोनों DBMS के लिए लोड परीक्षण का आयोजन किया, हमारे लिए प्रोफ़ाइल लोड को ध्यान में रखते हुए। मुझे कहना होगा कि इम्पाला और हाइव में डेटा प्रोसेसिंग इंजन काफी अलग हैं - हाइव आमतौर पर कई अलग-अलग विकल्प प्रस्तुत करता है। हालांकि, चुनाव इम्पाला पर गिर गया - और, तदनुसार, क्लाउडरा से वितरण।

मुझे इम्पाला के बारे में क्या पसंद आया

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

Sqoop और बाकी वास्तुकला

Hadoop स्टैक पर अगला सबसे महत्वपूर्ण उपकरण हमारे लिए Sqoop था। यह आपको संबंधपरक डीबीएमएस (हम टेराडाटा में रुचि रखते हैं) और एचडीएफएस के साथ पैराडाइट सहित विभिन्न प्रारूपों में हाडोप क्लस्टर में डेटा स्थानांतरित करने की अनुमति देता है। परीक्षणों में, Sqoop ने उच्च लचीलापन और प्रदर्शन दिखाया, इसलिए हमने इसका उपयोग करने का निर्णय लिया - ODBC / JDBC के माध्यम से डेटा कैप्चर करने और HDFS को बचाने के लिए अपने स्वयं के उपकरण विकसित करने के बजाय।

डेटा विज्ञान के प्रशिक्षण मॉडल और संबंधित कार्यों के लिए, जो कि हडोप क्लस्टर पर सीधे निष्पादित करने के लिए अधिक सुविधाजनक हैं, हमने अपाचे स्पार्क का उपयोग किया। अपने क्षेत्र में, यह एक मानक समाधान बन गया है - और एक कारण है:

• स्पार्क एमएल मशीन लर्निंग लाइब्रेरी
  
• चार प्रोग्रामिंग भाषाओं (स्काला, जावा, पायथन, आर) के लिए समर्थन;
  
• विश्लेषणात्मक उपकरणों के साथ एकीकरण;
  
• इन-मेमोरी डेटा प्रोसेसिंग उत्कृष्ट प्रदर्शन देता है।
  

Oracle बिग डेटा उपकरण सर्वर एक हार्डवेयर प्लेटफ़ॉर्म के रूप में खरीदा गया था। हमने एक उत्पादक सर्किट में छह नोड्स के साथ 2x24-कोर सीपीयू और 256 जीबी मेमोरी प्रत्येक के साथ शुरू किया। वर्तमान कॉन्फ़िगरेशन में 512 जीबी मेमोरी तक विस्तारित के साथ 18 समान नोड्स हैं।



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

इम्पाला में लगभग सभी आधुनिक एंटरप्राइज एनालिटिक्स टूल्स के लिए इंटरफेस है। इसके अलावा, ODBC / JDBC इंटरफेस का समर्थन करने वाले मनमाने उपकरण ग्राहकों के रूप में जुड़े हो सकते हैं। SQL के साथ काम करने के लिए, हम Hadoop के लिए Hue और TOAD को मुख्य ग्राहक मानते हैं।

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

सितारों के लिए रेक के माध्यम से

QCD को उतारना सरल प्रतीत होता है। इनपुट और आउटपुट में, संबंधपरक DBMS, Sqoop के माध्यम से डेटा ले और ओवरफ़्लो करें। उपरोक्त विवरण को देखते हुए, हमारे साथ सब कुछ बहुत आसानी से हो गया, लेकिन, निश्चित रूप से, यह रोमांच के बिना नहीं था, और यह शायद पूरी परियोजना का सबसे दिलचस्प हिस्सा है।



हमारी मात्रा के साथ, हम पूरी तरह से हर दिन सभी डेटा को स्थानांतरित करने की उम्मीद नहीं कर सकते हैं। तदनुसार, प्रत्येक भंडारण सुविधा से यह सीखना आवश्यक था कि कैसे एक विश्वसनीय वेतन वृद्धि को अलग किया जाए, जो कि हमेशा आसान नहीं होता है जब ऐतिहासिक व्यापारिक तिथियों के लिए डेटा तालिका में बदल सकता है। इस समस्या को हल करने के लिए, हमने इतिहास को लोड करने और बनाए रखने के तरीकों के आधार पर वस्तुओं को व्यवस्थित किया। फिर, प्रत्येक प्रकार के लिए, Sqoop के लिए सही विधेय और रिसीवर में लोड करने की विधि निर्धारित की गई थी। और अंत में, उन्होंने नई वस्तुओं के डेवलपर्स के लिए निर्देश लिखे।

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

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

सभी MPP और विशेष रूप से Teradata में समानांतर डेटा भंडारण और अनुदेश निष्पादन से संबंधित एक विशेषता है। यदि इस सुविधा पर ध्यान नहीं दिया जाता है, तो यह पता चल सकता है कि सभी कार्य क्लस्टर के एक तार्किक नोड द्वारा लिए जाएंगे, जो 100-200 में एक बार क्वेरी निष्पादन को बहुत धीमा कर देगा। बेशक, हम इसकी अनुमति नहीं दे सकते थे, इसलिए, हमने एक विशेष इंजन लिखा था जो क्यूसीडी तालिकाओं के ईटीएल मेटाडेटा का उपयोग करता है और Sqoop कार्यों के समानांतर डिग्री के इष्टतम डिग्री का चयन करता है।

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

अंत में - डेटा प्रकारों के साथ एक प्रश्न। रूपांतरण टाइप करने के लिए इम्पाला काफी स्वतंत्र है, इसलिए हमें केवल TIMESTAMP और CHAR / VARCHAR के प्रकारों में कुछ कठिनाइयों का सामना करना पड़ा। दिनांक-समय के लिए, हमने इम्पाला में डेटा को पाठ (STRING) प्रारूप YYYY-MM-DD HH: MM: SS में संग्रहीत करने का निर्णय लिया। यह दृष्टिकोण, जैसा कि यह निकला, तारीख और समय को बदलने के कार्यों का उपयोग करना संभव बनाता है। दी गई लंबाई के स्ट्रिंग डेटा के लिए, यह पता चला है कि इम्पाला में STRING प्रारूप में भंडारण उनके लिए अवर नहीं है, इसलिए हमने इसका उपयोग किया है।

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

विश्लेषक टूलकिट

हम पूरे प्रोजेक्ट के एक और लक्ष्य के बारे में नहीं भूले हैं - विश्लेषकों को इस सभी धन का उपयोग करने में सक्षम बनाने के लिए। यहां मूल सिद्धांत दिए गए हैं जिन्होंने हमें यहां निर्देशित किया है:

• उपयोग और समर्थन में उपकरण की सुविधा
  
• डेटा साइंस टास्क में प्रयोज्यता
  
• अनुप्रयोग सर्वर या शोधकर्ता के कंप्यूटर के बजाय Hadoop क्लस्टर के कंप्यूटिंग संसाधनों का उपयोग करने की अधिकतम संभावना
  

और यहाँ हम क्या पर बंद कर दिया:

• पायथन + एनाकोंडा। उपयोग किया गया वातावरण iPython / Jupyter है
  
• आर + चमकदार। शोधकर्ता आर स्टूडियो के डेस्कटॉप या वेब संस्करण में काम करता है, शाइनी का उपयोग उन वेब अनुप्रयोगों को विकसित करने के लिए किया जाता है जो आर में विकसित एल्गोरिदम के उपयोग से तेज होते हैं।
  
• स्पार्क। डेटा के साथ काम करने के लिए, पायथन (pyspark) और R के इंटरफेस का उपयोग किया जाता है, जो पिछले पैराग्राफ में निर्दिष्ट विकास वातावरण में कॉन्फ़िगर किए गए हैं। दोनों इंटरफेस आपको स्पार्क एमएल लाइब्रेरी का उपयोग करने की अनुमति देते हैं, जो Hadoop / Spark क्लस्टर पर ML मॉडल को प्रशिक्षित करना संभव बनाता है।
  
• इम्पाला डेटा ह्यू, स्पार्क के माध्यम से और मानक ओडीबीसी इंटरफेस और इप्लीयर जैसे विशेष पुस्तकालयों का उपयोग करके विकास के वातावरण से सुलभ है
  

वर्तमान में, डेटा लेक में रिटेल स्टोरेज से लगभग 100 टीबी डेटा है, साथ ही कई ओएलटीपी स्रोतों से लगभग 50 टीबी है। झील को दैनिक रूप से अपडेट किया जाता है। भविष्य में, हम उपयोगकर्ता सुविधा में वृद्धि करने जा रहे हैं, इम्पाला पर एक ईएलटी लोड लागू करते हैं, डेटा लेक पर अपलोड किए गए स्रोतों की संख्या बढ़ाते हैं, और उन्नत विश्लेषिकी के अवसरों का विस्तार करते हैं।

अंत में, मैं उन सहयोगियों को कुछ सामान्य सलाह देना चाहूंगा जो अभी बड़ी रिपॉजिटरी बनाने में अपनी यात्रा शुरू कर रहे हैं:

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

वैसे, आप इस बारे में पढ़ सकते हैं कि हमारे विश्लेषकों ने मशीन लर्निंग और बैंक डेटा का उपयोग एक अलग पोस्ट में क्रेडिट जोखिमों के साथ कैसे किया।