पीवीएस-स्टूडियो अपाचे हाइव पर जाकर

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

पीवीएस-स्टूडियो के बारे में

पीवीएस-स्टूडियो स्टैटिक कोड एनालाइजर आईटी बाजार में 10 से अधिक वर्षों से मौजूद है और यह एक बहुक्रियाशील और आसानी से लागू होने वाला सॉफ्टवेयर समाधान है। फिलहाल, विश्लेषक सी, सी ++, सी #, जावा भाषाओं का समर्थन करता है और विंडोज, लिनक्स और मैकओएस प्लेटफार्मों पर काम करता है।

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

यदि आप एक खुले स्रोत geek हैं या, उदाहरण के लिए, आप एक छात्र हैं, तो आप पीवीएस-स्टूडियो के मुफ्त लाइसेंसिंग विकल्पों में से एक का उपयोग कर सकते हैं।

अपाचे हाइव के बारे में

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

वर्तमान में, Apache Hadoop को बिग डेटा की मूलभूत तकनीकों में से एक माना जाता है। इस प्रौद्योगिकी के मुख्य उद्देश्य डेटा के बड़े संस्करणों का भंडारण, प्रसंस्करण और प्रबंधन हैं। फ्रेमवर्क के मुख्य घटक Hadoop Common, HDFS , Hadoop MapReduce , Hadoop YARN हैं । समय के साथ, संबंधित परियोजनाओं और प्रौद्योगिकियों का एक पूरा पारिस्थितिकी तंत्र हैडोप के आसपास बना है, जिनमें से कई शुरू में परियोजना के हिस्से के रूप में विकसित हुए, और बाद में स्वतंत्र हो गए। इनमें से एक प्रोजेक्ट अपाचे हाइव है ।

अपाचे हाइव एक वितरित डेटा वेयरहाउस है। यह HDFS में संग्रहीत डेटा का प्रबंधन करता है और इस डेटा के साथ काम करने के लिए SQL- आधारित क्वेरी भाषा (HiveQL) प्रदान करता है। इस परियोजना के साथ एक विस्तृत परिचय के लिए, आप यहां की जानकारी का अध्ययन कर सकते हैं ।

विश्लेषण के बारे में

विश्लेषण के लिए चरणों का क्रम काफी सरल है और इसमें अधिक समय की आवश्यकता नहीं है:

• गिटहब के साथ अपाचे हाइव मिला;
• मैंने जावा विश्लेषक शुरू करने के लिए निर्देशों का उपयोग किया और विश्लेषण शुरू किया;
• मुझे एक विश्लेषक की रिपोर्ट प्राप्त हुई, इसका विश्लेषण किया और दिलचस्प मामलों पर प्रकाश डाला।

विश्लेषण के परिणाम: उच्च और मध्यम विश्वास स्तर (क्रमशः 602 और 854) की 1456 चेतावनियाँ 6500+ फाइलों के लिए जारी की गईं।

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

चेतावनी के बीच, 407 चेतावनियाँ (177 उच्च और 230 मध्यम) प्रति परीक्षण फ़ाइलों पर विचार नहीं किया गया था। नैदानिक ​​नियम V6022 पर विचार नहीं किया गया था (किसी अपरिचित कोड में गलत स्थितियों को सही से अलग करना मुश्किल है), जिसमें पहले से ही 482 चेतावनी थी। 179 चेतावनियों के साथ V6021 को भी नहीं माना गया।

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

पूर्व निर्धारित स्थिति

नैदानिक ​​नियम V6007 सभी शेष विश्लेषक चेतावनियों के बीच रिकॉर्ड धारक है। बस 200 से अधिक चेतावनी !!! कुछ, जैसे, हानिरहित, कुछ संदिग्ध हैं, जबकि अन्य पूरी तरह से वास्तविक गलतियाँ हैं! आइए उनमें से कुछ पर एक नज़र डालें।

V6007 अभिव्यक्ति 'key.startsWith ("hplsql।")' हमेशा सच होता है। Exec.java (675)

void initOptions() { .... if (key == null || value == null || !key.startsWith("hplsql.")) { // <= continue; } else if (key.compareToIgnoreCase(Conf.CONN_DEFAULT) == 0) { .... } else if (key.startsWith("hplsql.conn.init.")) { .... } else if (key.startsWith(Conf.CONN_CONVERT)) { .... } else if (key.startsWith("hplsql.conn.")) { .... } else if (key.startsWith("hplsql.")) { // <= .... } } 

एक काफी लंबा अगर और-अगर निर्माण! विश्लेषक अंतिम पर शपथ लेता है यदि (key.startsWith ("hplsql।")) , कार्यक्रम कोड खंड तक पहुँच जाता है, तो इसकी सच्चाई का संकेत। वास्तव में, यदि आप if-else-if निर्माण की शुरुआत को देखते हैं, तो चेक पहले ही पूरा हो चुका है। और मामले में हमारी लाइन "hplsql" के विकल्प से शुरू नहीं हुई। , फिर कोड का निष्पादन तुरंत अगले पुनरावृत्ति पर कूद गया।

V6007 अभिव्यक्ति 'columnNameProperty.length () == 0' हमेशा गलत है। OrcRecordUpdater.java (238)

 private static TypeDescription getTypeDescriptionFromTableProperties(....) { .... if (tableProperties != null) { final String columnNameProperty = ....; final String columnTypeProperty = ....; if ( !Strings.isNullOrEmpty(columnNameProperty) && !Strings.isNullOrEmpty(columnTypeProperty)) { List<String> columnNames = columnNameProperty.length() == 0 ? new ArrayList<String>() : ....; List<TypeInfo> columnTypes = columnTypeProperty.length() == 0 ? new ArrayList<TypeInfo>() : ....; .... } } } .... } 

शून्य के साथ कॉलमनामप्रोपरेटी की स्ट्रिंग लंबाई की तुलना करना हमेशा गलत होगा । ऐसा इसलिए है क्योंकि हमारी तुलना परीक्षण के तहत है ! Strings.isNullOrEmpty (columnNameProperty) । यदि कार्यक्रम की स्थिति प्रश्न में हमारी स्थिति तक पहुंचती है, तो कॉलमनामप्रॉपर्टी लाइन गैर-शून्य होने की गारंटी है और खाली नहीं है।

यह कॉलम टाइपप्रॉपर्टी पंक्ति के लिए भी सही है। नीचे दी गई चेतावनी पंक्ति:

• V6007 अभिव्यक्ति 'columnTypeProperty.length () == 0' हमेशा गलत है। OrcRecordUpdater.java (239)

V6007 अभिव्यक्ति 'colOrScalar1.equals ("कॉलम")' हमेशा गलत है। GenVectorCode.java (3469)

 private void generateDateTimeArithmeticIntervalYearMonth(String[] tdesc) throws Exception { .... String colOrScalar1 = tdesc[4]; .... String colOrScalar2 = tdesc[6]; .... if (colOrScalar1.equals("Col") && colOrScalar1.equals("Column")) // <= { .... } else if (colOrScalar1.equals("Col") && colOrScalar1.equals("Scalar")) { .... } else if (colOrScalar1.equals("Scalar") && colOrScalar1.equals("Column")) { .... } 

}

यहाँ एक तुच्छ कॉपी-पेस्ट है। यह पता चला है कि colOrScalar1 लाइन एक ही समय में विभिन्न मूल्यों के बराबर होनी चाहिए, और यह असंभव है। जाहिरा तौर पर, चर colOrScalar1 को बाईं ओर, और दाईं ओर colOrScalar2 की जाँच की जानी चाहिए।

नीचे दी गई लाइनों में अधिक समान चेतावनियाँ:

• V6007 अभिव्यक्ति 'colOrScalar1.equals ("स्केलर") हमेशा गलत है। GenVectorCode.java (3475)
• V6007 अभिव्यक्ति 'colOrScalar1.equals ("कॉलम")' हमेशा गलत है। GenVectorCode.java (3486)

नतीजतन, अगर-और-अगर निर्माण में कोई कार्रवाई कभी निष्पादित नहीं होगी।

V6007 के लिए कुछ अन्य चेतावनी:

• V6007 अभिव्यक्ति 'वर्ण == अशक्त' हमेशा गलत है। RandomTypeUtil.java (43)
• V6007 अभिव्यक्ति 'writeIdHwm> 0' हमेशा गलत है। TxnHandler.java (1603)
• V6007 अभिव्यक्ति 'फ़ील्ड। असेंबल ("*")' हमेशा सही होती है। Server.java (983)
• V6007 अभिव्यक्ति 'currentGroups! = नल' हमेशा सच है। GenericUDFCurrentGroups.java (90)
• V6007 अभिव्यक्ति 'this.wh == null' हमेशा झूठी होती है। नया विवरण नहीं-शून्य संदर्भ। स्टोरेजबेडअथोराइजेशनप्रोवाइडर.जाव (93), स्टोरेजबेडअथोरीकरणप्रोवाइडर.जॉव (92)
• और इसी तरह ...

एनपीई

V6008 'डगलॉक' की संभावित अशक्तता। QueryTracker.java (557), QueryTracker.java (553)

 private void handleFragmentCompleteExternalQuery(QueryInfo queryInfo) { if (queryInfo.isExternalQuery()) { ReadWriteLock dagLock = getDagLock(queryInfo.getQueryIdentifier()); if (dagLock == null) { LOG.warn("Ignoring fragment completion for unknown query: {}", queryInfo.getQueryIdentifier()); } boolean locked = dagLock.writeLock().tryLock(); ..... } } 

शून्य वस्तु को पकड़ा, प्रतिज्ञा की और ... काम करना जारी रखा। यह इस तथ्य की ओर जाता है कि वस्तु की जांच करने के बाद शून्य वस्तु की डीफ्रेंसिंग होती है। Pechalka!

सबसे अधिक संभावना है, एक शून्य संदर्भ के मामले में, आपको तुरंत फ़ंक्शन से बाहर निकलना चाहिए या कुछ विशेष अपवाद फेंकना चाहिए।

V6008 समारोह 'अनलॉक' में 'बफर' के अशांति को रोकने के लिए 'बफ़र'। मेटाडेटाचेजावा (410), मेटाडेटाचेजावा (465)

 private boolean lockBuffer(LlapBufferOrBuffers buffers, ....) { LlapAllocatorBuffer buffer = buffers.getSingleLlapBuffer(); if (buffer != null) { // <= return lockOneBuffer(buffer, doNotifyPolicy); } LlapAllocatorBuffer[] bufferArray = buffers.getMultipleLlapBuffers(); for (int i = 0; i < bufferArray.length; ++i) { if (lockOneBuffer(bufferArray[i], doNotifyPolicy)) continue; for (int j = 0; j < i; ++j) { unlockSingleBuffer(buffer, true); // <= } .... } .... } .... private void unlockSingleBuffer(LlapAllocatorBuffer buffer, ....) { boolean isLastDecref = (buffer.decRef() == 0); // <= if (isLastDecref) { .... } } 

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

शिफ्ट का पालन नहीं किया

V6034 शिफ्ट के मान से 'bitShiftsInWord - 1' प्रकार के आकार के साथ असंगत हो सकता है: 'bitShiftsInWord - 1' = [-1 ... 30]। अनसाइन्टइंटेंट २००s.जावा (१igned ९ १)

 private void shiftRightDestructive(int wordShifts, int bitShiftsInWord, boolean roundUp) { if (wordShifts == 0 && bitShiftsInWord == 0) { return; } assert (wordShifts >= 0); assert (bitShiftsInWord >= 0); assert (bitShiftsInWord < 32); if (wordShifts >= 4) { zeroClear(); return; } final int shiftRestore = 32 - bitShiftsInWord; // check this because "123 << 32" will be 123. final boolean noRestore = bitShiftsInWord == 0; final int roundCarryNoRestoreMask = 1 << 31; final int roundCarryMask = (1 << (bitShiftsInWord - 1)); // <= .... } 

संभावित ऑफसेट -1। यदि, उदाहरण के लिए, शब्दशः == 3 और बिटशिफ्टइवॉर्ड == 0 प्रश्न में विधि के इनपुट पर आते हैं, तो निर्दिष्ट पंक्ति में 1 << -1 होगा। क्या यह योजनाबद्ध है?

V6034 शिफ्ट 'जे' के मान से आकार के अनुसार असंगत हो सकता है: 'जे' = [0 ... 63]। IoTrace.java (272)

 public void logSargResult(int stripeIx, boolean[] rgsToRead) { .... for (int i = 0, valOffset = 0; i < elements; ++i, valOffset += 64) { long val = 0; for (int j = 0; j < 64; ++j) { int ix = valOffset + j; if (rgsToRead.length == ix) break; if (!rgsToRead[ix]) continue; val = val | (1 << j); // <= } .... } .... } 

निर्दिष्ट पंक्ति में, चर j [0 ... 63] श्रेणी में मान ले सकता है। इस वजह से, लूप में वैल के मूल्य की गणना डेवलपर के अनुसार नहीं हो सकती है। अभिव्यक्ति (1 << j) में, इकाई प्रकार int की है , और, इसे 32 या अधिक से स्थानांतरित करते हुए, हम अनुमेय की सीमा से परे जाते हैं। स्थिति को मापने के लिए, आपको लिखना होगा ((लंबा) 1 << j) ।

लॉगिंग के बारे में उत्साही

V6046 गलत प्रारूप। विभिन्न प्रकार के प्रारूप आइटम अपेक्षित हैं। उपयोग नहीं किए गए तर्क: 1, 2. आँकड़े। जजाव (89)

 private static ImmutableList<PersistedRuntimeStats> extractStatsFromPlanMapper (....) { .... if (stat.size() > 1 || sig.size() > 1) { StringBuffer sb = new StringBuffer(); sb.append(String.format( "expected(stat-sig) 1-1, got {}-{} ;", // <= stat.size(), sig.size() )); .... } .... if (e.getAll(OperatorStats.IncorrectRuntimeStatsMarker.class).size() > 0) { LOG.debug( "Ignoring {}, marked with OperatorStats.IncorrectRuntimeStatsMarker", sig.get(0) ); continue; } .... } 

String.format () के माध्यम से एक स्ट्रिंग को स्वरूपित करते समय , डेवलपर ने सिंटैक्स को भ्रमित किया। नीचे पंक्ति: उत्तीर्ण पैरामीटर परिणामी स्ट्रिंग में नहीं मिला। मैं मान सकता हूं कि पिछले कार्य में डेवलपर ने लॉगिंग पर काम किया था, जहां से उसने सिंटैक्स उधार लिया था।

अपवाद चुरा लिया

V6051 'अंत' ब्लॉक में 'रिटर्न' स्टेटमेंट के उपयोग से अनचाहे अपवादों का नुकसान हो सकता है। ObjectStore.java (9080)

 private List<MPartitionColumnStatistics> getMPartitionColumnStatistics(....) throws NoSuchObjectException, MetaException { boolean committed = false; try { .... /*some actions*/ committed = commitTransaction(); return result; } catch (Exception ex) { LOG.error("Error retrieving statistics via jdo", ex); if (ex instanceof MetaException) { throw (MetaException) ex; } throw new MetaException(ex.getMessage()); } finally { if (!committed) { rollbackTransaction(); return Lists.newArrayList(); } } } 

अंत में ब्लॉक से कुछ वापस करना एक बहुत बुरा अभ्यास है, और इस उदाहरण के साथ हम इसे देखेंगे।

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

इसी तरह की चेतावनी:

• V6051 'अंत' ब्लॉक में 'रिटर्न' स्टेटमेंट के उपयोग से अनचाहे अपवादों का नुकसान हो सकता है। ObjectStore.java (808)

... अन्य

V6009 फ़ंक्शन 'तुलना' को एक विषम तर्क प्राप्त होता है। एक ऑब्जेक्ट 'o2.getWorkerIdentity ()' का उपयोग अपनी स्वयं की पद्धति के तर्क के रूप में किया जाता है। LlapFixedRegistryImpl.java (244)

 @Override public List<LlapServiceInstance> getAllInstancesOrdered(....) { .... Collections.sort(list, new Comparator<LlapServiceInstance>() { @Override public int compare(LlapServiceInstance o1, LlapServiceInstance o2) { return o2.getWorkerIdentity().compareTo(o2.getWorkerIdentity()); // <= } }); .... } 

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

V6020 को शून्य से विभाजित करें। 'भाजक' भाजक मानों की श्रेणी में शून्य शामिल है। SqlMathUtil.java (265)

 public static long divideUnsignedLong(long dividend, long divisor) { if (divisor < 0L) { /*some comments*/ return (compareUnsignedLong(dividend, divisor)) < 0 ? 0L : 1L; } if (dividend >= 0) { // Both inputs non-negative return dividend / divisor; // <= } else { .... } } 

यहां सब कुछ काफी सरल है। 0 से विभाजित करने पर कई चेकों ने चेतावनी नहीं दी।

अधिक चेतावनी:

• V6020 मॉड शून्य से। 'भाजक' भाजक मानों की श्रेणी में शून्य शामिल है। SqlMathUtil.java (309)
• V6020 को शून्य से विभाजित करें। 'भाजक' भाजक मानों की श्रेणी में शून्य शामिल है। SqlMathUtil.java (276)
• V6020 को शून्य से विभाजित करें। 'भाजक' भाजक मानों की श्रेणी में शून्य शामिल है। SqlMathUtil.java (312)

V6030 की विधि 'के दाईं ओर स्थित है।' ऑपरेटर को बाएं ऑपरेंड के मूल्य की परवाह किए बिना बुलाया जाएगा। शायद, '' का उपयोग करना बेहतर है। OperatorUtils.java (573)

 public static Operator<? extends OperatorDesc> findSourceRS(....) { .... List<Operator<? extends OperatorDesc>> parents = ....; if (parents == null | parents.isEmpty()) { // reached end eg TS operator return null; } .... } 

तार्किक ऑपरेटर के बजाय || एक बिटवाइज़ ऑपरेटर लिखा | इसका मतलब यह है कि बाईं ओर के परिणाम की परवाह किए बिना सही पक्ष को निष्पादित किया जाएगा। माता-पिता == अशक्त के मामले में इस तरह का एक टाइपो, अगले तार्किक उपप्रकार में तुरंत NPE का नेतृत्व करेगा।

V6042 अभिव्यक्ति 'A' के साथ संगतता के लिए जाँच की जाती है, लेकिन 'B' टाइप करने के लिए डाली जाती है। वेक्टरकॉल्यूमनएसिग्निफैक्टरी.जावा (347)

 public static VectorColumnAssign buildObjectAssign(VectorizedRowBatch outputBatch, int outColIndex, PrimitiveCategory category) throws HiveException { VectorColumnAssign outVCA = null; ColumnVector destCol = outputBatch.cols[outColIndex]; if (destCol == null) { .... } else if (destCol instanceof LongColumnVector) { switch(category) { .... case LONG: outVCA = new VectorLongColumnAssign() { .... } .init(.... , (LongColumnVector) destCol); break; case TIMESTAMP: outVCA = new VectorTimestampColumnAssign() { .... }.init(...., (TimestampColumnVector) destCol); // <= break; case DATE: outVCA = new VectorLongColumnAssign() { .... } .init(...., (LongColumnVector) destCol); break; case INTERVAL_YEAR_MONTH: outVCA = new VectorLongColumnAssign() { .... }.init(...., (LongColumnVector) destCol); break; case INTERVAL_DAY_TIME: outVCA = new VectorIntervalDayTimeColumnAssign() { .... }.init(...., (IntervalDayTimeColumnVector) destCol);// <= break; default: throw new HiveException(....); } } else if (destCol instanceof DoubleColumnVector) { .... } .... else { throw new HiveException(....); } return outVCA; } 

विचाराधीन वर्ग LongColumnVector ColumnVector को विस्तारित करता है और TimestampColumnVector को ColumnVector को विस्तारित करता है । LongColumnVector के स्वामित्व के लिए हमारी डेस्टकॉल ऑब्जेक्ट की जाँच करना हमें स्पष्ट रूप से बताता है कि इस वर्ग की वस्तु सशर्त विवरण के अंदर होगी। इसके बावजूद, हम टाइमस्टैम्पकॉल्यूमिनेक्टर के लिए कास्टिंग कर रहे हैं! जैसा कि आप देख सकते हैं, ये कक्षाएं अलग-अलग हैं, न कि उनके सामान्य माता-पिता की गिनती। परिणामस्वरूप - ClassCastException ।

सभी एक ही प्रकार के बारे में कहा जा सकता है

• V6042 अभिव्यक्ति 'A' के साथ संगतता के लिए जाँच की जाती है, लेकिन 'B' टाइप करने के लिए डाली जाती है। वेक्टरकॉल्यूमनएसिग्नेटफैक्टिंग.जवा (390)

V6060 शून्य से सत्यापित होने से पहले 'var' संदर्भ का उपयोग किया गया था। वर.जावा (402), वर.जावा (395)

 @Override public boolean equals(Object obj) { if (getClass() != obj.getClass()) { // <= return false; } Var var = (Var)obj; if (this == var) { return true; } else if (var == null || // <= var.value == null || this.value == null) { return false; } .... } 

डेरीफेरिंग के बाद नल के साथ एक var ऑब्जेक्ट की एक अजीब तुलना हुई है। इस संदर्भ में, var और obj एक ही ऑब्जेक्ट ( var = (Var) obj ) हैं। अशक्त के लिए जाँच से तात्पर्य है कि एक अशक्त वस्तु आ सकती है। और बराबरी (अशक्त) के मामले में , हम उम्मीद की झूठी के बजाय पहली पंक्ति NPE पर तुरंत प्राप्त करते हैं । काश, एक जाँच होती है, लेकिन वहाँ नहीं।

चेक होने से पहले ऑब्जेक्ट का उपयोग करने वाले समान संदिग्ध क्षण:

• V6060 नल के खिलाफ सत्यापित होने से पहले 'मान' संदर्भ का उपयोग किया गया था। ParquetRecordReaderWrapper.java (168), ParquetRecordReaderWrapper.java (166)
• V6060 'defaultConstraintCols' संदर्भ का उपयोग शून्य से पहले सत्यापित किए जाने से पहले किया गया था। HiveMetaStore.java (2539), HiveMetaStore.java (2530)
• V6060 'projIndxLst' संदर्भ का उपयोग इससे पहले कि यह अशक्त के खिलाफ सत्यापित किया गया था। RelOptHiveTable.java (683), RelOptHiveTable.java (682)
• V6060 नल के खिलाफ सत्यापित होने से पहले 'पुराने' संदर्भ का उपयोग किया गया था। ObjectStore.java (4343), ObjectStore.java (4339)
• और इसी तरह ...

निष्कर्ष

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

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

हाइव की जाँच करते समय, पर्याप्त संख्या में दोष और संदिग्ध क्षणों का पता चला था। यदि यह लेख अपाचे हाइव विकास टीम का ध्यान आकर्षित करता है, तो हम इस मुश्किल काम में योगदान करने में प्रसन्न होंगे।

Apache Hadoop के बिना Apache Hive की कल्पना करना असंभव है, इसलिए संभावना है कि PVS-Studio का गेंडा भी वहीं दिखेगा। लेकिन यह सब आज के लिए है, लेकिन अब के लिए विश्लेषक डाउनलोड करें और अपनी खुद की परियोजनाओं की जांच करें।

यदि आप इस लेख को अंग्रेजी बोलने वाले दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद के लिंक का उपयोग करें: मैक्सिम स्टेफानोव। पीवीएस-स्टूडियो ने अपाचे हाइव का दौरा किया ।