एंटरप्राइज़ डेटा के प्रकार

🌐 28 अन्य भाषाओं में भी उपलब्ध

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI से बनाई गई इमेज

AI द्वारा अनुवादित। समुदाय ने अभी इसकी समीक्षा नहीं की है। अंग्रेज़ी में पढ़ें

मॉड्यूल 2 (कुल 6 में से) — अध्याय एंटरप्राइज़ डेटा को समझना, Data Architect कोर्स का अध्याय 4। हर मॉड्यूल अपने आप में पूरा है। पिछला: Salesforce कई सिस्टमों में से एक है · अगला: Salesforce के आसपास के सिस्टम

यह मॉड्यूल किस सवाल का जवाब देता है: एक एंटरप्राइज़ के पास किस तरह का डेटा होता है, और वह अलग-अलग जगहों पर क्यों होना चाहिए?

एक ग्राहक रिकॉर्ड। देशों की एक सूची। एक ऑर्डर। एक फ़ील्ड की परिभाषा। पाँच साल की बिक्री का कुल योग। चार मिलियन डिलीवरी फ़ोटो। ये सब डेटा हैं, लेकिन आर्किटेक्चर के लिहाज़ से ये एक चीज़ नहीं हैं। ये अलग-अलग तरह बदलते हैं, अलग-अलग तरह बढ़ते हैं, अलग-अलग तरह इस्तेमाल होते हैं और इनके मालिक अलग-अलग लोग होते हैं, और इन्हें अपने-आप एक ही जगह नहीं रहना चाहिए। इसलिए जब कोई कहता है “हमें यह डेटा Salesforce में चाहिए,” तो मेरा अगला सवाल होता है: यह किस तरह का डेटा है? जवाब मुझे बताने लगता है कि इसके साथ क्या करना है।

प्रकार से शुरू करें, ऑब्जेक्ट से नहीं

Salesforce वाले होने के नाते हम ज़रूरतों को लगभग तुरंत संरचनाओं में बदल देते हैं: ग्राहक, Account; फ़ोटो, File; स्टेटस, पिकलिस्ट। आख़िरकार यह काम आता है। एंटरप्राइज़ के स्तर पर, मैं पहले जानना चाहता हूँ कि मैं किस तरह की जानकारी से निपट रहा हूँ। इसे वर्गीकृत करने के कई तरीके हैं (DAMA का body of knowledge मानक संदर्भ है), और मुझे छह प्रकार उपयोगी लगते हैं: मास्टर, रेफ़रेंस, ट्रांज़ैक्शनल, मेटाडेटा, एनालिटिकल और अनस्ट्रक्चर्ड। श्रेणियाँ आर्किटेक्चर नहीं हैं। ये बेहतर सवाल पूछने का एक तरीका हैं।

मास्टर डेटा: वे चीज़ें जिन्हें बिज़नेस जानता है

मास्टर डेटा उन टिकाऊ चीज़ों का वर्णन करता है जिनके इर्द-गिर्द बिज़नेस चलता है: ग्राहक, प्रोडक्ट, कीमतें, कर्मचारी, सप्लायर, लोकेशन, एसेट। Salesforce के किसी सेल्स org में ये आपके Accounts और Contacts, आपके प्रोडक्ट और आपकी price books हैं। Steve Trucking में रिटेल पार्टनर (Retail Partner) मास्टर डेटा है। Keystone कोई घटना नहीं है; यह एक संगठन है जिसके साथ Steve Trucking का लगातार चलने वाला रिश्ता है। नौ डिस्ट्रिब्यूशन सेंटर भी मास्टर डेटा हैं।

मास्टर डेटा उन ट्रांज़ैक्शनों से ज़्यादा जीता है जो उसका इस्तेमाल करते हैं: एक रिटेल पार्टनर की लाखों डिलीवरी हो सकती हैं। इसलिए इसके बारे में पहला सवाल हमेशा होता है इसका मालिक कौन है? ज़रूरी नहीं कि Salesforce हो। प्रोडक्ट का मालिक ERP हो सकता है। संभावित ग्राहकों का मालिक Salesforce हो सकता है, जबकि ग्राहक बनने के बाद आधिकारिक सिस्टम ERP बन जाता है। कई सिस्टमों से जोड़कर बनी ग्राहक की एंटरप्राइज़ पहचान (identity) का मालिक कोई MDM प्लेटफ़ॉर्म हो सकता है। अध्याय 6, मास्टर डेटा और पहचान, इसमें गहराई से जाता है। फ़िलहाल, इसका आकार पहचानें।

रेफ़रेंस डेटा: वह शब्दावली जो बिज़नेस साझा करता है

रेफ़रेंस डेटा वह नियंत्रित शब्दावली है जिससे दूसरे डेटा को वर्गीकृत किया जाता है: देश के कोड, मुद्राएँ, प्रोडक्ट की श्रेणियाँ, कारण कोड, स्टेटस। Steve Trucking की डिलीवरी के स्टेटस (scheduled, loaded, out for delivery, arriving, delivered, installed, exception, returned) रेफ़रेंस डेटा हैं। ये डिलीवरी नहीं हैं; ये वे शब्द हैं जिनसे डिलीवरी का वर्णन होता है।

यह छोटा और बेज़रर दिखता है, अक्सर आठ वैल्यू वाली एक पिकलिस्ट। छोटे को कम अहम न समझें। अगर Salesforce Delivered कहता है, ERP Complete कहता है और कोई रिटेल पार्टनर D भेजता है, तो किसी को तय करना होगा कि हर एक का मतलब क्या है और वे आपस में कैसे मैप होते हैं। रेफ़रेंस डेटा वह जगह है जहाँ इंटीग्रेशन की धारणाएँ छिपी रहती हैं।

ट्रांज़ैक्शनल डेटा: क्या हुआ

ट्रांज़ैक्शनल डेटा गतिविधि दर्ज करता है: दिया गया ऑर्डर, किया गया भुगतान, पूरी हुई डिलीवरी, खोला गया case। उसी सेल्स org में ये quotes और quote lines, orders और order items, payments हैं: हर एक वापस किसी ग्राहक और किसी प्रोडक्ट की ओर इशारा करता है। Steve Trucking की साल की 1 मिलियन डिलीवरी ट्रांज़ैक्शनल हैं, और उनके स्टेटस अपडेट भी: हर डिलीवरी पर लगभग आठ, यानी साल में आठ मिलियन स्टेटस बदलाव, ऐसे बिज़नेस में जो हर साल 30% बढ़ रहा है।

यह मास्टर डेटा से बिल्कुल अलग बढ़ोतरी का कर्व है। ऊपर तीन रिटेल पार्टनर; नीचे लाखों पंक्तियाँ। यहीं Steve की “शून्यों की गिनती” (Steve’s Number of Zeros) मायने रखती है: आप रिटेल पार्टनर → डिलीवरी → स्टेटस को देखकर हर बॉक्स को एक जैसा वज़न नहीं दे सकते। ट्रांज़ैक्शनल डेटा के साथ मैं तुरंत वॉल्यूम, रफ़्तार (velocity), रिटेंशन, इतिहास, आर्काइविंग, इंटीग्रेशन, और लोगों को असल में उसे कैसे ढूँढना है, इसके बारे में सोचता हूँ। भाग 2 वहाँ काफ़ी समय बिताता है।

मेटाडेटा: डेटा के बारे में डेटा

आप पूरे कोर्स में मेटाडेटा के साथ काम करते आए हैं: किसी ऑब्जेक्ट की परिभाषा, किसी फ़ील्ड का टाइप, उसका description, उसके संबंध। पूरे एंटरप्राइज़ के पास यह होता है: warehouse के स्कीमा, इंटीग्रेशन मैपिंग, डेटा कैटलॉग, API कॉन्ट्रैक्ट, और हर फ़ील्ड के लिए एक मालिक, एक संवेदनशीलता स्तर, एक परिभाषा, लिनिएज (डेटा की वंशावली) और एक रिटेंशन नियम। वैल्यू डेटा हैं; उनके मतलब का वर्णन मेटाडेटा है। जैसा अध्याय 3 ने कहा, Flag2__c किसी को कुछ नहीं बताता, और यह अब और ज़्यादा मायने रखता है क्योंकि AI यह समझने के लिए मेटाडेटा पढ़ता है कि डेटा का मतलब क्या है।

एनालिटिकल डेटा: दूसरे डेटा से बनाया गया डेटा

“पिछले पाँच सालों में रिटेल पार्टनर के हिसाब से हमारी समय पर डिलीवरी की दर क्या है?” कोई ट्रांज़ैक्शन नहीं है। यह एक एनालिटिकल सवाल है, जिसका जवाब लाखों डिलीवरी से नया डेटा निकालकर मिलता है: समय पर डिलीवरी का प्रतिशत, नुकसान की दर, हर पार्टनर से आमदनी, इंस्टॉलेशन की गुणवत्ता, क्रू के रुझान। और यह एक अलग काम है। “ट्रक 217 का अगला स्टॉप कौन-सा है?” पूछने वाले डिस्पैचर को पाँच साल का इतिहास खंगालने की ज़रूरत नहीं। क्षेत्र के हिसाब से पाँच साल के समय पर प्रदर्शन की तुलना करने वाले नेतृत्व को है। इसीलिए एनालिटिकल डेटा आमतौर पर उस काम के लिए बने warehouse, lakehouse या एनालिटिक्स प्लेटफ़ॉर्म में रहता है। Salesforce किसी चीज़ को स्टोर कर सकता है, इससे ऑपरेशनल प्लेटफ़ॉर्म उस पर हर विश्लेषण चलाने की जगह नहीं बन जाता।

अनस्ट्रक्चर्ड डेटा: जो पंक्तियों में फ़िट नहीं होता

दस्तावेज़, PDF, इमेज, ऑडियो, वीडियो, ईमेल, ट्रांसक्रिप्ट, knowledge articles। Steve Trucking में डिलीवरी की फ़ोटो: हर डिलीवरी पर लगभग चार, इंस्टॉलेशन के साथ और ज़्यादा, साल में चार से पाँच मिलियन। फ़ोटो सिर्फ़ एक और फ़ील्ड नहीं है। वह बड़ी है, वह किसी के घर का अंदरूनी हिस्सा दिखा सकती है, उसके अपने रिटेंशन नियम हैं, और उसे अलग तरह से सर्च किया जाता है, अगर किया जाए तो।

यह प्रकार हर साल ज़्यादा मायने रखता है, क्योंकि AI अब उस जानकारी के साथ उपयोगी काम कर सकता है जो पहले स्ट्रक्चर्ड मॉडल के बाहर पड़ी रहती थी। ट्रांसक्रिप्ट डेटा है। PDF मैनुअल डेटा है। इंस्टॉलेशन की फ़ोटो डेटा है। इसका मतलब यह नहीं कि वह Salesforce के core में होनी चाहिए। इसका मतलब है कि वह लैंडस्केप पर होनी चाहिए।

Click to enlarge

छह प्रकार, हर एक के लिए चार सवाल। जवाब प्रकार-दर-प्रकार बदलते हैं, और असली बात यही है।

प्रकार सवाल का सिर्फ़ आधा हिस्सा है: वर्कलोड

हमारे पास किस तरह का डेटा है, यह जानना काफ़ी नहीं। मैं यह भी जानना चाहता हूँ कि हम उसके साथ क्या कर रहे हैं। यहाँ तीन वर्कलोड मायने रखते हैं, और इन्हें आपस में उलझाने से खराब आर्किटेक्चर बनता है।

ऑपरेशनल: बिज़नेस चलाना। एक डिस्पैचर डिलीवरी अपडेट करता है, एक क्रू स्टॉप पूरा करता है, एक एजेंट case खोलता है। ढेर सारे छोटे reads और writes: यह ढूँढो, वह अपडेट करो, आज के स्टॉप दिखाओ। यह OLTP है, online transaction processing, और Salesforce इसमें बहुत अच्छा है; एडमिन और डेवलपर यहीं रहते हैं।

एनालिटिकल: बिज़नेस को समझना। पाँच साल की हर डिलीवरी, पार्टनर और DC के हिसाब से समूहित, साल-दर-साल तुलना, फ़ाइनेंस से जोड़कर। अब हम खंगाल रहे हैं और जोड़ (aggregate) रहे हैं। यह OLAP है, online analytical processing, और warehouse, lakehouse और एनालिटिक्स प्लेटफ़ॉर्म इसी के लिए बने हैं। सीधे शब्दों में: org बिज़नेस चलाता है; warehouse और lake उसका विश्लेषण करते हैं। एक क्लासिक गलती है यह वर्कलोड ऑपरेशनल प्लेटफ़ॉर्म पर डालना और फिर शून्य बढ़ने पर हैरान होना। अगर कोई बार-बार भारी मात्रा में इतिहास खंगालना चाहता है, तो इसे “बस एक और रिपोर्ट” न समझें। पूछें कि क्या यह सही प्लेटफ़ॉर्म है। भाग 2 इस पर स्केल के लिए डिज़ाइन (coming soon) में लौटता है (core को अपना warehouse न बनाएँ), और भाग 3 रिलेशनल से आगे (coming soon) में दिखाता है कि एनालिटिकल संरचनाएँ कैसे बनती हैं।

स्ट्रीमिंग: चलता हुआ डेटा। Events, telemetry, स्टेटस बदलाव, सेंसर रीडिंग। Steve Trucking के ट्रक रोज़ लगभग 200,000 GPS रीडिंग भेजते हैं। डिस्पैचर को परवाह है कि ट्रक 217 अभी कहाँ है। क्या Salesforce को हर ट्रक की हर मिनट की रीडिंग रखनी है? शायद नहीं। “यह अभी कहाँ है?” और “पिछली तिमाही में रूट की कुशलता के रुझान क्या थे?” एक ही स्रोत से आते हैं, और स्टोरेज के बिल्कुल अलग फ़ैसलों तक ले जाते हैं।

इसे कितनी तेज़ी से चलना है?

फिर latency। क्लास में मैं इसे ऐसे कहता हूँ: real time है दरवाज़े पर खड़े होकर किसी के लौटने का इंतज़ार करना। आप उसे बाहर भेजते हैं और वहीं खड़े रहते हैं, क्योंकि उसके लौटे बिना आप आगे नहीं बढ़ सकते। यह synchronous है। Near real time है उसे जाते देखना और किसी और काम में लग जाना; जब वह थोड़ी देर में लौटता है, तब आप उसे देखते हैं। यह asynchronous है। और फिर है batch: कोई एक-एक करके दरवाज़े से बाहर नहीं जाता। डेटा इंतज़ार करता है और एक तय समय पर समूह में चलता है: हर घंटे, हर कुछ घंटों में, या रोज़। बहुत-सी स्थितियों में batch काफ़ी होता है, और कुछ में नहीं। कौन-सी कौन-सी है, यह जानना ही काम है। ये तीनों सिर्फ़ इंटीग्रेशन के शब्द नहीं हैं; ये आर्किटेक्चर के चुनाव हैं।

आम ERP इंटीग्रेशन लें। ERP में सुबह 11 बजे एक नया प्रोडक्ट बनता है। क्या सेल्स को सच में दोपहर 12 बजे तक उसे बेचना है? मैंने दोनों जवाब देखे हैं। कुछ क्लाइंट उसे जितनी जल्दी हो सके चाहते हैं; दूसरे कहते हैं, अगर हमने वह SKU आप तक भेजा ही नहीं, तो हम उम्मीद नहीं कर सकते कि आप उसे अभी बेचें। इसलिए प्रोडक्ट आमतौर पर रोज़ आते हैं, कभी-कभी उससे जल्दी। ग्राहक, कम से कम रोज़; मैंने हर घंटे भी देखा है, और अति के मामलों में near real time। ऑर्डर अलग हैं: fulfillment शुरू होना है, इसलिए near real time। सेल्सपर्सन डील बंद करके आगे बढ़ जाता है, और ऑर्डर कुछ सेकंड से एक-दो मिनट में ERP में पहुँच जाता है। “एंटरप्राइज़ डेटा” के लिए कोई एक सही latency नहीं है। पूछें कि बिज़नेस को असल में क्या चाहिए, और सिर्फ़ इसलिए सब कुछ real time न बनाएँ कि वह प्रभावशाली लगता है। Real time की एक कीमत होती है।

श्रेणियों के पीछे के चार सवाल

आपको घूम-घूमकर यह घोषणा करने की ज़रूरत नहीं कि “यह ट्रांज़ैक्शनल डेटा है!” वर्गीकरण इसलिए है ताकि हर अहम डेटा सेट के बारे में चार सवाल उठें:

• इसका मालिक कौन है? कौन-सा सिस्टम आधिकारिक है? मैं इसे तीन हिस्सों में बाँटता हूँ: यह कहाँ बनाया जाता है, कहाँ एडिट किया जाता है, और कहाँ संदर्भित किया जाता है? अध्याय 6 इनमें गहराई से जाता है (कहाँ बनता है, कहाँ एडिट होता है, कहाँ संदर्भित होता है, और कितनी तेज़ी से?)।
• यह कितनी तेज़ी से बदलता है? साल में एक बार, रोज़, एक सेकंड में दसियों से सैकड़ों बार?
• यह कितना बड़ा होता है? दस रिकॉर्ड, दस हज़ार, दस मिलियन, दस बिलियन?
• इसका जीवनचक्र क्या है? क्या यह हमेशा रहता है, आर्काइव होता है, इसे डिलीट करना ज़रूरी है, समय के साथ इसकी कीमत घटती है?

ये चार सवाल मुझे “क्या Salesforce इसे स्टोर कर सकता है?” से कहीं ज़्यादा बताते हैं। और ये वह सब जोड़ देते हैं जो हम पहले सीख चुके हैं: स्वामित्व, जीवनचक्र, शून्यों की गिनती, डेटा कहाँ रहता है।

एक बिज़नेस हर प्रकार बनाता है

Steve Trucking में रिटेल पार्टनर मास्टर डेटा है; स्टेटस की शब्दावली रेफ़रेंस डेटा है; हर डिलीवरी ट्रांज़ैक्शनल है; उसके फ़ील्ड की परिभाषाएँ मेटाडेटा हैं; पाँच साल का समय पर डिलीवरी का स्कोरकार्ड एनालिटिकल है; इंस्टॉलेशन की फ़ोटो अनस्ट्रक्चर्ड है; और GPS फ़ीड स्ट्रीमिंग है। यह सब “Steve Trucking का डेटा” है। इसमें से किसी का मतलब यह नहीं कि यह सब एक ही डेटाबेस में होना चाहिए। यही बदलाव है।

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

आर्किटेक्ट यहाँ क्या तय करता है

• हर अहम डेटा सेट किस प्रकार का डेटा है, और उसका मालिक कौन है।
• उसका वर्कलोड ऑपरेशनल है, एनालिटिकल, स्ट्रीमिंग, या मिला-जुला।
• वह कितनी तेज़ी से बदलता है, और दूसरे सिस्टमों को वह बदलाव सच में कितनी जल्दी देखना है।
• वॉल्यूम और जीवनचक्र कैसे तय करते हैं कि वह कहाँ और कितने समय तक रहे।
• क्या Salesforce उसका मालिक हो, उसकी कॉपी रखे, उसे संदर्भित करे, या उसे किसी ऐसी जगह छोड़ दे जो उस वर्कलोड के लिए बेहतर हो।

जब कोई आपको कोई ज़रूरत थमाए, तो सीधे इस पर न कूदें कि कौन-सा ऑब्जेक्ट, कौन-सा फ़ील्ड, कौन-सा API। पहले पूछें कि यह किस प्रकार का डेटा है, इसका मालिक कौन है, यह कितनी तेज़ी से बदलता है, कितना बड़ा होता है, कितने समय तक रहता है, और हम इसके साथ क्या करना चाहते हैं। एक Account, एक डिलीवरी event, पाँच साल का एक aggregate और एक फ़ोटो, ये सब एक ही बिज़नेस के लिए मायने रख सकते हैं, बिना एक ही आर्किटेक्चरल समस्या हुए।

और जानें

• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, दूसरा संस्करण (2017) (अंग्रेज़ी में): डेटा की श्रेणियों और डेटा मैनेजमेंट का मानक संदर्भ।
• Steve Trucking का ब्रीफ़, खंड 4 (वॉल्यूम)।