थोक सत्यापन वर्कफ़्लो: बड़ी सूची को साफ़ करना और श्रेणीबद्ध रिपोर्ट

एक नंबर की जांच एक संवाद है। पचास हज़ार की जांच अपने अलग अर्थशास्त्र वाली बैच प्रक्रिया है: प्रति पंक्ति लागत छोटी होनी चाहिए, विफलताएं ऐसी पठनीय होनी चाहिए कि हर पंक्ति किसी इंसान को पढ़नी न पड़े, और नतीजा अगली सुबह किसी के काम आने लायक होना चाहिए।

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

थोक सत्यापन एक मान की जांच से कैसे अलग है?

सारे अंतर इस बात में हैं कि अंकगणित के बाद क्या होता है। संवाद वाली जांच एक व्यक्ति को एक नतीजा लौटाती है जो मान को स्क्रीन पर देख सकता है। बैच वाली जांच ऐसी फ़ाइल की हर पंक्ति के लिए नतीजा लौटाती है जिसे अभी किसी ने देखा ही नहीं, और रिपोर्ट ही एकमात्र चीज़ है जिसे कोई पढ़ेगा।

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

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

इस लेख में जिन मानों का उल्लेख है, वे वर्णित हैं, उद्धृत नहीं। असली डेटा पर चलने वाले बैच में रिपोर्ट लिखने से पहले ऐसे मानों पर परदा डालना चाहिए, और यहां के उदाहरण केवल समझाने वाली आकृतियां हैं।

पहले साफ़ करें, फिर सत्यापित करें: पाइपलाइन

क्रियाओं का क्रम ही बाकी काम को संभव बनाता है, और वह वही क्रम है जो एक फ़ील्ड की जांच में होता है, बस हर पंक्ति पर लागू।

1. फ़ाइल को पाठ के रूप में पढ़ें और मूल मान ठीक वैसे ही सुरक्षित रखें जैसे दिए गए थे।
2. हर मान को सामान्य रूप दें — विभाजक हटाएं, खाली स्थान समेटें, केस एक करें — और दोनों रूप साथ रखें।
3. हर पंक्ति के लिए योजना या योजनाएं तय करें, उस कॉलम के आधार पर जिससे मान आया और, जहां कॉलम मिला-जुला हो, मान के आधार पर भी।
4. उचित जांच चलाएं, या दर्ज करें कि कोई नियम लागू नहीं होता।
5. हर पंक्ति को किसी श्रेणी में रखें, और फिर रिपोर्ट लिखें।

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

योजना की पहचान हर अलग पैटर्न के लिए एक बार करें, हर पंक्ति के लिए नहीं। एक ही किस्म के पहचानकर्ता वाली फ़ाइल में केवल एक बार देखना पड़ता है, और मिली-जुली फ़ाइल में भी आमतौर पर कुछ ही अलग आकृतियां होती हैं, इसलिए पहचान को स्मृति में रख लेना प्रति पंक्ति लागत को प्रति फ़ाइल लागत बना देता है।

नतीजे के सेट में कौन सी श्रेणियां होनी चाहिए?

श्रेणियां ही विफलताओं की सूची को निदान बनाती हैं, और उन्हें सत्यापनकर्ता के मौजूदा नतीजों से मेल खाना चाहिए, नई शब्दावली गढ़नी नहीं चाहिए।

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

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

डुप्लिकेट, खाली सेल और बहुत बड़ी फ़ाइलें

असली फ़ाइलों की ज़्यादातर मुश्किलें तीन साधारण स्थितियों से आती हैं।

दोहराव सामान्य रूप वाले मान पर पकड़े जाने चाहिए, क्योंकि एक ही नंबर की अलग-अलग विराम चिह्न वाली दो प्रतियां वही नंबर हैं। पहली बार आने वाली प्रतिलिपि को स्थान बताएं और बाकी को संदर्भ के रूप में सूचीबद्ध करें, ताकि समीक्षक देख सके कि यह पुनरावृत्ति आकस्मिक है या ढांचे का हिस्सा।

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

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

रिपोर्ट को काम लायक क्या बनाता है

सुबह नौ बजे बैठे समीक्षक को नतीजे से चार चीज़ें चाहिए: पंक्ति संख्या, जैसा मान आया वैसा ही, श्रेणी, और एक छोटा कारण। बाकी सब सजावट है।

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

क्रम भी मायने रखता है। श्रेणी के हिसाब से समूह बनाने पर एक समस्या के सारे उदाहरण एक जगह आ जाते हैं, जिससे समीक्षक चालीस हज़ार पंक्तियों को पढ़ने के बजाय पैटर्न पहचान लेता है। श्रेणी के भीतर पंक्ति क्रम से रखें ताकि फ़ाइल ऊपर से नीचे तक संपादित की जा सके।

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

डेवलपर के लिए: चंकिंग, समानांतरता और दोहराव सुरक्षा

बैच बनाने की परत वह जगह है जहां एक चलता हुआ स्क्रिप्ट भरोसेमंद कार्य बनता है।

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

जब फ़ाइल में असली मान हों तो परदा डालना वैकल्पिक नहीं है। थोक में चलने वाला कार्य सब कुछ एक साथ पढ़ता है, इसलिए बिना परदे वाली एक रिपोर्ट किसी एक विफल फ़ॉर्म की तुलना में कहीं बड़ा खुलासा है। पहली बार चलाने से पहले तय करें कि कौन से कॉलम दोहराए जा सकते हैं और कौन से काटने पड़ेंगे। बैच और उसे खिलाने वाले API के बीच का संबंध अगला पढ़ने लायक है: API सीमाओं पर सत्यापन बताता है कि फ़ाइल आने पर प्राप्त करने वाली सेवा को क्या करना चाहिए, और नंबर सत्यापन कैसे काम करता है वह प्रति-पंक्ति तर्क है जिस पर यह पाइपलाइन बनी है।

आगे के कदम

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