📧 👩‍✈️ 🧓🏻 Dryad। वितरित कम्प्यूटिंग फ्रेमवर्क 💅🏽 👩🏽‍🔧 👩🏾‍🤝‍👨🏽

निम्नलिखित आँकड़ों के साथ वितरित आवेदन निष्पादन के लिए एक सामान्य ढांचे की कल्पना करें *:

* 2011 के लिए सांख्यिकीय डेटा।

अब कल्पना कीजिए कि यह हडोप नहीं है।

यह किस तरह का ढांचा है, इसकी नींव में रखे गए विचारों और अवधारणाओं के बारे में और क्यों इस ढांचे को हडोप की तुलना में अधिक नवीन (व्यक्तिपरक) है, नीचे चर्चा की जाएगी।

1. ड्राईड। सामान्य जानकारी

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

एक प्रत्यक्ष एसाइक्लिक ग्राफ के मॉडल पर आधारित अमूर्तता से बड़ी संख्या में समानांतर एल्गोरिदम , पुनरावृत्त एल्गोरिदम , मशीन लर्निंग एल्गोरिदम के निष्पादन की योजनाओं को प्रभावी ढंग से लागू करना संभव हो जाता है। इस प्रकार, केवल ( YARN से पहले) हडॉप ** में कार्यान्वित प्रोग्रामिंग मॉडल को कम / अनिवार्य रूप से ड्रायड द्वारा प्रदान किए गए वितरित कंप्यूटिंग मॉडल का केवल एक विशेष मामला है ।

ड्रायड को एक मध्यम या बड़े कंप्यूटिंग क्लस्टर (100 से 10K कंप्यूटिंग नोड्स से) पर चलाने के लिए अनुकूलित किया गया है और इसका उद्देश्य मुख्य रूप से दीर्घकालिक बैच की नौकरियों के लिए है, जिन्हें अक्सर बातचीत की आवश्यकता नहीं होती है।

2004 ... 2008

ड्रायड के अतीत, वर्तमान और भविष्य से निपटने के प्रयासों ने मुझे लेखों की एक सीमित संख्या में ले लिया, जिनमें से लेखक, मूल स्रोतों का हवाला देते हैं, न कि यह तर्क देते हैं कि:

इस तरह की प्रणाली के निर्माण का विचार माइकल इस्र्ड द्वारा 2004 में (Google MapReduce के साथ एक सादृश्य) उत्पन्न हुआ (बाद में उन्होंने Microsoft में शोधकर्ता का पद संभाला);
2006 में, बिल गेट्स ने खुद को कंप्यूटर साइंस सम्मेलन में ड्रायड प्रस्तुत किया;
ड्रायड को बिंग, माइक्रोसॉफ्ट एडकेंटर, ~~किनेक्ट~~ , विंडोज एचपीसी सर्वर 2008 आर 2 (उत्तरार्द्ध, विश्वसनीय रूप से ज्ञात) में उपयोग किया जाता है।

2008 ... 2009

ड्रायड में सन्निहित अवधारणाओं का वर्णन करने वाले मूलभूत दस्तावेजों में से एक, OSDI'08 पर " बेस्ट पेपर " (ऑपरेटिंग सिस्टम डिज़ाइन और कार्यान्वयन पर USENIX संगोष्ठी) से सम्मानित किया गया था।

नवंबर 2009 में, ड्रायड एक अकादमिक लाइसेंस के तहत उपलब्ध हो गया।

2010 ... 2011

2011 में, विंडोज एचपीसी टीम ने संबंधित विंडोज ऑपरेटिंग सिस्टम लाइन के लिए "लिनक्यू टू एचपीसी" (विंडोज एचपीसी सर्वर के लिए ड्रायड) के बीटा संस्करण की घोषणा की । उसी वर्ष, यह घोषणा की गई थी कि LINQ से HPC "पूर्वावलोकन संस्करण से" बाहर नहीं निकलेंगे (अर्थात, वास्तव में, समर्थन की समाप्ति के बारे में)।

2012 ... 2013 / UPD /

यह ध्यान देने योग्य है कि विंडोज एचपीसी टीम ने ड्राय प्रोजेक्ट के समर्थन / विकास के बारे में कुछ भी नहीं कहा (और सिद्धांत में नहीं कह सकता)। ड्रायड के आगे समर्थन के बारे में अन्य बयान या, इसके विपरीत, समर्थन का एक असमान नकार, पिछले (2012) और इस वर्ष पर ध्यान नहीं दिया गया है।

2. ड्रायड इकोसिस्टम

ड्रायड परियोजना में 3 प्रमुख घटक होते हैं:

ड्रायड - वितरित अनुप्रयोगों का क्रम (इसके बाद, अस्पष्टता से बचने के लिए, हम इस घटक को ड्रायड रनटाइम कहेंगे);
DryadLINQ एक उच्च स्तरीय क्वेरी भाषा है जो .NET लैंग्वेज इंटीग्रेटेड प्रोग्रामिंग मॉडल पर आधारित है
क्वेरी (LINQ);
डिस्ट्रिब्यूटेड स्टोरेज कैटलॉग (डीएससी) एक वितरित फाइल सिस्टम है जो कि विन्यास अतिरेक के साथ है।

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

3. ड्राईड रनटाइम

ड्रायड रनटाइम वितरित अनुप्रयोगों का एक रनटाइम है , जैसे हैडोप, इस तरह के कार्यों को ले रहा है:

वितरित कार्यों का निर्धारण और प्रबंधन;
संसाधन प्रबंधन;
गलती सहिष्णुता;
निगरानी।

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

Dryad। निष्पादन का ग्राफ

3.1। डेटा चैनल

डेटा चैनल, साथ ही साथ कोने, अमूर्त हैं और इनके द्वारा दर्शाया गया है:

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

वितरित कार्य के सबसे कुशल निष्पादन के लिए क्लस्टर के भौतिक संसाधनों के बारे में जानकारी का खुलासा करने की आवश्यकता चैनल को "स्वच्छ" के रूप में अमूर्त नहीं बनाती है क्योंकि यह पहली नज़र में लगता है। फिर भी, वितरित एप्लिकेशन के डेवलपर को "चैनल" अमूर्तता का उल्लंघन नहीं दिखता है, क्योंकि वह अन्य स्तरों (कार्य प्रबंधक) के तहत छिपती है, जिस पर नीचे चर्चा की जाएगी।

3.2। डेटा मॉडल

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

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

3.3। नौकरी प्रबंधक

ड्रायड जॉब जॉब मैनेजर (जेएम) द्वारा ऑर्केस्ट्रेटेड है। नौकरी प्रबंधक में कार्यों की गणना के लिए एक ग्राफ बनाने के लिए एप्लिकेशन-विशिष्ट कोड होता है।

नौकरी प्रबंधक के लिए जिम्मेदार है:

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

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

3.4। नाम सर्वर। डेमॉन

नाम सर्वर नाम सर्वर क्लस्टर में उपलब्ध गणना नोड्स और उनके सामयिक स्थान के बारे में जानकारी के प्रकटीकरण के लिए जिम्मेदार है।

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

ड्रायड आर्किटेक्चर और जॉब मैनेजर , नाम सर्वर (एनएस) और डेमन (पीडी) के लिए इस आर्किटेक्चर में जगह नीचे दी गई है।

Dryad। निष्पादन का ग्राफ

चित्रण का स्रोत [3]

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

3.5। गतिशील ग्राफ परिवर्तन

Hadoop में JobTracker के समान Job Manager, स्थैतिक प्रदर्शन अनुकूलन प्रदान करता है। लेकिन Hadoop के विपरीत, ड्रायड में गतिशील रूप से प्रदर्शन को अनुकूलित करने की क्षमता है।

एक निर्देशित एसाइक्लिक ग्राफ के केंद्रीय ड्रायड अवधारणा के लिए धन्यवाद और कॉलबैक तंत्र के लिए समर्थन (कॉलबैक जेएम को वर्टेक्स ऑपरेशन के निष्पादन चरण में बदलाव के बारे में सूचित करता है), निष्पादन ग्राफ रनटाइम के दौरान बदलने में सक्षम है। डायनामिक परिवर्तन से आप निम्न समस्याओं को काफी हद तक हल कर सकते हैं:

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

इसके अलावा, रनटाइम के दौरान ग्राफ के गतिशील परिवर्तन और डेटा ट्रांसफर के एक विशिष्ट तरीके से "चैनल" की अवधारणा के अमूर्त होने के कारण, यह महत्वपूर्ण है (यही है, इसे लागू करना संभव है, यदि लागू नहीं किया गया है) डेटा न केवल उस नोड तक पहुंच सकता है जिस पर डेटा भौतिक रूप से संग्रहीत है। लेकिन यह भी:

एक डेमन एक अस्थायी फ़ाइल को एक रैक लोकल में वर्टेक्स ऑपरेशन के लिए इंटरमीडिएट परिणामों के साथ सहेज सकता है, जो इस डेटा को इनपुट के रूप में स्वीकार करता है;
एक डेमॉन होस्ट की रैम में डेटा को स्टोर कर सकता है यदि इस ऑपरेशन को इनपुट के रूप में स्वीकार करता है, जो एक ही कंप्यूट नोड पर चल रहा है।

3.6। दोष सहिष्णुता

जैसा कि पहले उल्लेख किया गया है, डेमन एक प्रॉक्सी है, इसलिए जॉब मैनेजर में रिमोट डेमॉन द्वारा शुरू किए गए एक वर्टेक्स ऑपरेशन की स्थिति और चरण का पता लगाने की क्षमता है। यदि डेमन "क्रैश" करता है, तो जॉब मैनेजर को इसके बारे में पता चल जाएगा:

एक त्रुटि संदेश जो डेमन ने अपनी प्रक्रिया को बंद करने से पहले जेएम को भेजा था
अगर डायमन को बंद करने के मामले में दिल की धड़कन संदेश का समय समाप्त हो गया है, तो कोई नैदानिक घटना जेएम को नहीं भेजी गई थी।

पीडी की विफलता का निदान करने के बाद, उस पर किए गए ऑपरेशन को दूसरे डेमॉन पर फिर से निष्पादित किया जाता है।

Dryad। दोष सहिष्णुता

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

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

लेकिन वितरित अनुप्रयोगों में से प्रत्येक के लिए अलग-अलग जेएम प्रक्रियाओं की उपस्थिति तुरंत 2 समस्याएं प्रस्तुत करती है:

नौकरी प्रबंधक के आरंभ पर खर्च किया गया समय
संसाधन साझा करने की समस्या, नौकरी प्रबंधक "पर्याप्त रूप से" मुक्त संसाधनों (सीपीयू, रैम, बैंडविड्थ) की मात्रा का अनुमान नहीं लगा सकता है, क्योंकि न जाने कितने और जेएम इस भौतिक कंप्यूटिंग नोड की सेवा कर रहे हैं।

4. अभ्यास

ड्रायड एक शैक्षणिक लाइसेंस [4] के तहत नि: शुल्क उपलब्ध है। फ्रेमवर्क शुरू करने के लिए, आपको Microsoft HPC पैक 2008 SP1, 4 Gb RAM, 1 Gb ईथरनेट और 200 Gb मुक्त स्थान क्लस्टर [1] के साथ एक Windows HPC क्लस्टर की आवश्यकता होगी।

ड्रायड एप्लिकेशन को C ++ और C # दोनों में लिखा जा सकता है (यह मान लेना उचित है कि कोई भी CLS- संगत भाषा उपयुक्त है)।

ड्रायड के लिए एक ऑपरेशन के वितरित निष्पादन के लिए निर्देश निम्नानुसार है (प्रारंभिक रीड, संयोजन, प्रारंभिक, इरेटेट, मर्ज वितरित निष्पादन के संबंधित चरणों के लिए जिम्मेदार कार्यों के नाम हैं; लिस्टिंग में उदाहरण अंकगणितीय माध्य मानते हैं):

///<summary>For iterator-based implementation</summary> [AssociativeDecomposable("InitialReduce", "Combine")] public static TOutput H(IEnumerable<TInput> source) { … }

लिस्टिंग 1. Iterator- आधारित कार्यान्वयन उदाहरण। स्रोत [२]

 public static double Average(IEnumerable<int> g) { IntPair final = g.Aggregate(x => PartialSum(x)); if (final.second == 0) return 0.0; return (double)final.first / (double)final.second; } [AssociativeDecomposable("InitialReduce", "Combine")] public static IntPair PartialSum(IEnumerable<int> g) { return InitialReduce(g); } public static IntPair InitialReduce(IEnumerable<int> g) { return new IntPair(g.Sum(), g.Count()); } public static IntPair Combine(IEnumerable<IntPair> g) { return new IntPair(g.Select(x => x.first).Sum(), g.Select(x => x.second).Sum()); }

 ///<summary>For accumulator-based implementation</summary> [AssociativeDecomposable("Initialize", "Iterate", "Merge")] public static TOutput H(IEnumerable<TInput> source) { … }

लिस्टिंग 2. Accumulator- आधारित कार्यान्वयन उदाहरण। स्रोत [२]

 public static double Average(IEnumerable<int> g) { IntPair final = g.Aggregate(x => PartialSum(x)); if (final.second == 0) return 0.0; else return (double)final.first / (double)final.second } [AssociativeDecomposable("Initialize", "Iterate", "Merge")] public static IntPair PartialSum(IEnumerable<int> g) { return new IntPair(g.Sum(), g.Count()); } public static IntPair Initialize() { return new IntPair(0, 0); } public static IntPair Iterate(IntPair x, int r) { x.first += r; x.second += 1; return x; } public static IntPair Merge(IntPair x, IntPair o) { x.first += o.first; x.second += o.second; return x; }

DryadLINQ क्वेरी भाषा कोड की जटिलता को घेर लेती है, इसलिए, सामान्य तौर पर, एप्लिकेशन डेवलपर को लिस्टिंग में सूचीबद्ध डिज़ाइन नहीं लिखना होगा। इस श्रृंखला में अगले लेख में DryadLINQ को शामिल किया जाएगा।

5. सीमाएं और नुकसान

अंत में, हम संक्षेप में ड्रायड की सीमाओं और मुख्य रूप से सॉफ्टवेयर के इस वर्ग के उद्देश्य की गलत धारणा से जुड़ी "गलत" उम्मीदों की समीक्षा करते हैं।

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

यह समझना भी आवश्यक है कि ड्रायड केवल एक वितरित कंप्यूटिंग ढांचा है , इसलिए आपको ड्रायड से उम्मीद नहीं करनी चाहिए:

लेनदेन समर्थन क्योंकि यह आरडीबीएमएस नहीं है;
GPU कंप्यूटिंग के लिए तुलनीय प्रदर्शन , क्योंकि ड्रायड मौलिक रूप से विभिन्न उपकरणों के साथ समस्याओं की एक व्यापक व्यापक श्रेणी को हल करता है;
ओपन सोर्स लाइसेंस क्योंकि ~~माइक्रोसॉफ्ट~~ मूल रूप से एक अलग प्रकार का उत्पाद (लेकिन अभी भी एक शैक्षणिक लाइसेंस के तहत मुफ्त पहुंच है);
वितरित अनुप्रयोगों का तेजी से विकास जो मानचित्र के ढांचे के भीतर काम करते हैं / प्रतिमान को कम करते हैं, क्योंकि ड्रायड Hadoop नहीं है: मानचित्र / कम मॉडल केवल Dryad के लिए एक विशेष मामला है, जबकि Hadoop के लिए यह एकमात्र संभव निष्पादन मॉडल है।

निष्कर्ष

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

सूत्रों की सूची

[१] द ड्रायड प्रोजेक्ट । Microsoft अनुसंधान।
[२] वाई। यू।, पीके गुंडा, एम। इसार्ड। डेटा-समानांतर कम्प्यूटिंग के लिए वितरित एकत्रीकरण: इंटरफेस और कार्यान्वयन , 2009।
[३] एम। इसार्ड, एम। बुडीयू, वाई। यू।, ए। बिरेल, और डी। पूरी तरह से। ड्रायड: अनुक्रमिक भवन ब्लॉकों से वितरित डेटा-समानांतर कार्यक्रम ।
कंप्यूटर सिस्टम पर यूरोपीयन कॉन्फ्रेंस की कार्यवाही में (2007)।
[४] ड्रायड और ड्रायड्लिनक्यू अकादमिक रिलीज़ । Microsoft अनुसंधान।

* वर्णानुक्रम में क्रमबद्ध।
** लेख में तुलना विशेष रूप से Hadoop प्लेटफ़ॉर्म के 1 संस्करण (यानी YARN के बिना) के साथ होती है। ड्रायड की एक विस्तृत तुलना डीबीएमएस, जीपीयू कंप्यूटिंग, और हडोप फ्रेमवर्क के साथ ड्राईड श्रृंखला में अंतिम लेख में की जाएगी।

Dryad। वितरित कम्प्यूटिंग फ्रेमवर्क