Forrás: Stephen Vanhorn / Dreamstime.com
Elvitel:
Eric Kavanagh házigazda megbeszélte a Hadoop-ot, hol volt és hol megy az ipari bennfentesekkel.
Szerkesztők megjegyzés: Ez egy élő internetes közvetítés átirata. A webes adást teljes egészében itt tekintheti meg.Eric Kavanagh: Hölgyeim és uraim, itt az ideje, hogy bölcs legyen! Itt az ideje egy teljesen új TechWise-shownak! A nevem Eric Kavanagh. A TechWise alapító epizódjának moderátora vagyok. Pontosan így van. Ez a Techopedia és a Bloor Group, természetesen a Belső Elemzés hírnevének partnersége.
A nevem Eric Kavanagh. Modellezni fogom ezt az igazán érdekes és résztvevő eseményt, emberek. Mélyre fogunk mélyedni a szövésbe, hogy megértsük, mi folyik ezzel a Hadoop nevű nagy dolggal. Mi az elefánt a szobában? Hadoopnak hívják. Megpróbáljuk kitalálni, hogy mit jelent, és mi folyik vele.
Mindenekelőtt nagy köszönet szponzorunknak, a GridGainnek, az Actiannek, a Zettasetnek és a DataTorrentnek. Néhány szót kapunk mindegyiktől, az esemény vége felé. Kérdések és válaszok is vannak, tehát ne légy félénk - bármikor felteheti a kérdéseit.
Átvizsgáljuk a részleteket, és a nehéz kérdéseket feltesszük szakértőinkre. És a szakértőkről beszélve, hé, ott vannak. Tehát, a saját Dr. Robin Bloor-tól és az emberektől fogunk hallani, nagyon örülök annak, hogy legendás Ray Wang, a fő elemző és a Constellation Research alapítója. Ma online van, hogy elmondja nekünk gondolatait, és olyan, mint Robin, hihetetlenül sokszínű és nagyon sok különböző területre összpontosít, képes szintetizálni őket, és valóban megérteni, mi folyik ezen az egész információs technológia területén. és adatkezelés.
Tehát van egy kis aranyos elefánt. Mint láthatja, az út elején van. Ez csak most kezdődik, csak egyfajta kezdés, ez az egész Hadoop dolog. Úgy gondolom, hogy 2006-ban vagy 2007-ben, amikor kiadták a nyílt forráskódú közösségnek, de sok minden zajlik, emberek. Hatalmas fejlesztések történtek. Valójában el akarom hozni a történetet, ezért gyorsan megosztom az asztali számítógépet, legalábbis azt hiszem, hogy vagyok. Csináljunk egy gyors asztali megosztást.
Megmutatom neked ezt az őrült, őrült történetet. Tehát az Intel 740 millió dollárt fektetett be, hogy megvásárolja a Cloudera 18 százalékát. Azt gondoltam, és szeretem: "Szent karácsony!" Megkezdtem a matematikát, és ez olyan, mint: "Ez 4,1 milliárd dollár értékű." Gondoljunk egy pillanatra erre. Úgy értem, ha a WhatsApp értéke 2 milliárd dollár, akkor azt gondolom, hogy Cloudera akár 4,1 milliárd dollár is lehet, igaz? Úgy értem, miért nem? Néhány ilyen szám manapság csak az ablakon van, emberek. Úgy értem, tipikusan a beruházás szempontjából, ha van EBITDA és az összes többi különféle mechanizmus, a bevételek többszöri száma és így tovább. Nos, ez egy szar a bevétel többszörösének köszönhetően, ha eléri a 4,1 milliárd dollárt a Cloudera számára, amely egy fantasztikus vállalat. Ne érts téged - vannak nagyon-nagyon okos emberek ott, köztük a srác, aki az egész Hadoop-őrültséget, Doug Cutting-et indította oda, nagyon sok nagyon intelligens ember, akik nagyon sokat csinálnak jó dolgok, de az lényeg az, hogy a 4,1 milliárd dollár, ez sok pénz.
Tehát itt egyfajta fogságba eső nyilvánvaló pillanat, amikor átmegyek a fejemre, azaz egy chip, Intel. Chiptervezőik hoznak néhány Hadoop-optimalizált chipet - gondolkodnom kell, emberek. Ez csak a gondolkodásom. Ez csak egy pletyka, tőlem érkezik, ha akarsz, de ez valamilyen értelme. És mit jelent ez az egész?
Tehát itt van az elméletem. Mi történik? Sok ilyen cucc nem új. A masszív párhuzamos feldolgozás nem újszerű. A párhuzamos feldolgozás nem új. Már egy ideje a szuperszámítógép világában voltam. Ezeknek a dolgoknak a nagy része, amelyek történnek, nem új, de van egyfajta általános tudatosság, hogy ezen problémák némelyikének megtámadására új mód van. Amit látom, ha megnézzük a Cloudera vagy a Hortonworks néhány nagy gyártóját és néhány ilyen srácot, akkor mit csinálnak valójában, ha a legfinomabb desztillált szintre forraljuk, az az alkalmazásfejlesztés. Ezt csinálják.
Új alkalmazásokat terveznek - néhányukban üzleti elemzést végeznek; némelyikük csak a feltöltő rendszereket foglalja magában. Az egyik eladó, aki erről beszélt, egész nap csinál ilyen fajta cuccot, a mai műsorban. De ha ez szörnyen új, akkor ismét a válasz: "nem igazán", de nagy dolgok történnek, és személy szerint úgy gondolom, hogy mi történik az Intel-rel, ha ezt a hatalmas beruházást piacra hozza. Nézik a mai világot, és látják, hogy ez ma egyfajta monopólium. Vannak és megverték csak a csapot a rossz MySpace-ből. A LinkedIn megverte a takon a szegény Who's Who-t. Tehát körülnéz, és ez egy szolgáltatás, amely dominálja manapság ezen különféle terekben. Úgy gondolom, hogy az Intel az, hogy az összes zsetonját Cloudera-ra dobja, és megpróbálja megemelni a verem tetejére - ez csak az elmélem.
Tehát az emberek, amint mondtam, hosszú Q&A ülést fogunk tartani, tehát ne légy félénk. bármikor felteheti kérdéseit. Ezt megteheti a webcast-konzol ezen Q & A összetevőjével. És ezzel szeretnék megismerkedni a tartalommal, mert rengeteg dolgot kellett átjutnunk.
Tehát, Robin Bloor, hadd adjak át neked a kulcsokat, és a padló a tied.
Robin Bloor: Rendben, Eric, köszönöm. Vegyük fel a táncoló elefántokat. Furcsa dolog, hogy az elefántok az egyetlen szárazföldi emlősök, akik nem tudnak ugrálni. Ezen a képen az összes elefántnak legalább egy lába van a földön, tehát feltételezem, hogy ez megvalósítható, de bizonyos mértékig ezek nyilvánvalóan Hadoop elefántok, tehát nagyon-nagyon képesek.
Valójában azt a kérdést, hogy véleményem szerint meg kell vitatni, és őszintén meg kell vitatni. Ezt meg kell vitatni, mielőtt bárhova máshová megy, vagyis valóban el kell kezdenie beszélni arról, hogy mi Hadoop valójában.
Az egyik dolog, amely feltétlenül a „man-play” alapból származik, a kulcsérték-áruház. Régebben kulcsértékes üzletek voltak. Régebben az IBM nagygépen voltak. A mini számítógépeknél volt; A DEC VAX-nek IMS fájlja volt. Volt olyan ISAM képességek, amelyek szinte minden minikomputeren megtalálhatók. De valamikor a 80-as évek végén, az Unix belépett, és az Unixnak valójában nem volt kulcsfontosságú tárolója. Amikor az Unix kifejlesztette, nagyon gyorsan fejlődtek. Ami történt, az az volt, hogy az adatbázis-gyártók, különös tekintettel az Oracle-ra, ott gőzöltek, és eladták az adatbázisokat, hogy megválaszolhassanak minden olyan adatot, amelyet érdekelne kezelni a Unix-on. Kiderült, hogy a Windows és a Linux ugyanaz. Tehát az iparág 20 év legnagyobb részében egy általános célú kulcsérték-áruház nélkül működött. Nos, hát itt van. Nem csak vissza, hanem méretezhető is.
Most azt hiszem, hogy valóban ez az alapja annak, mi a Hadoop valójában, és bizonyos mértékig meghatározza, hová megy. Mit szeretünk a kulcsértékű üzletekben? Azok, akik olyan idős vagyok, mint én, és valóban emlékszem, hogy együtt dolgoztak a kulcsérték-üzletekkel, rájönnek, hogy nagyjából használhatnák őket informálisan adatbázis létrehozására, de csak informálisan. Tudod, hogy a metaadatok gyorsan tárolják a programkódot, de valójában létrehozhat egy külső fájlt, és ha egy kulcsérték-tárolót egy kicsit adatbázishoz hasonlóan kezdeni szeretne. De természetesen nem volt minden olyan helyreállítási képessége, amely egy adatbázisban volt, és nem volt szörnyű sok dolgunk, amelyeket az adatbázisok most megkaptak, de ez egy nagyon hasznos funkció a fejlesztők számára, és ez az egyik oka annak, hogy hogy a Hadoop annyira népszerűnek bizonyult - egyszerűen azért, mert kódolók, programozók, fejlesztők gyorsak. Rájöttek, hogy nem csak az üzlet kulcsértéke, hanem egy kulcsfontosságú értékű áruház is. Nagyjából határozatlan időre csökken. Ezeket a mérlegeket több ezer szerverre küldtem, tehát ez az igazán nagy dolog Hadoopnál, pontosan ez.
Ráadásul a MapReduce-t is tartalmazza, amely egy párhuzamosítási algoritmus, de valójában ez véleményem szerint nem fontos. Szóval, tudod, Hadoops egy kaméleon. Ez nem csak fájlrendszer. Láttam különféle igényeket a Hadoop iránt: ez egy titkos adatbázis; ez nem titkos adatbázis; ez egy közös üzlet; egy elemző eszközkészlet; annak ELT-környezete; adattisztító eszköz; ez egy adatfolyam-streaming platform; archívumtár; gyógyítja a rákot és így tovább. Ezen dolgok többsége valójában nem igaz a Hadoop vanília esetében. A Hadoop valószínűleg egy prototípus - ez egy SQL adatbázis prototípus-környezete, de valójában nincs, ha a korosztályt a Hadoop fölé helyezi az életkor-katalógusban, akkor van valami, ami adatbázisnak tűnik, de ez nem igazán olyan, amit bárki egy adatbázist hívnánk a képesség szempontjából. Nagyon sok ilyen képességről biztosan beszerezheti őket a Hadoop-on. Nyilvánvalóan sok ilyen. Valójában beszerezhet valamilyen forrást a Hadoop-ról, de maga Hadoop nem az, amit én működési szempontból edzettnek neveznék, és ezért a Hadoop-ról szóló megállapodás, valójában nem lennék más dolga, az az, hogy valamilyen harmadik félnek kell lennie. termékek annak fokozására.
Tehát, ha rólad beszélünk, akkor csak néhány sort dobhat be, ahogy a Hadoop túljuttatásáról beszélek. Először is, a valós idejű lekérdezési képesség, jól tudja, hogy a valós idejű üzleti idő, valójában szinte mindig a teljesítmény szempontjából kritikus. Úgy értem, miért tervezne valós időben? Hadoop nem igazán csinálja ezt. Valamit valós időben végez, de valójában nem valós idejű dolgot. Streaming-et végez, de nem úgy, mint a valóban missziókritikus típusú alkalmazás-streaming platformoknak hívható streaming. Különbség van az adatbázis és az eltávolítható tároló között. A Hadoop feletti szinkronizálás lehetővé teszi az adattárolást. Ez olyan, mint egy adatbázis, de nem ugyanaz, mint egy adatbázis. A Hadoop natív formájában, véleményem szerint, egyáltalán nem minősül adatbázisnak, mivel nagyon kevés dolog tartozik az adatbázishoz. Hadoop sokat csinál, de nem csinálja különösebben jól. A meglévő képességek ismét megmutatták a távoli képességeket abban, hogy valóban rendelkezzenek gyors képességgel ezen a területen.
A másik dolog, amelyet meg kell érteni a Hadoop kapcsán, az a fajta, hogy messze jött a fejlesztés óta. A korai napokban fejlesztették ki; akkor fejlesztették ki, amikor olyan kiszolgálóink voltak, amelyek kiszolgálónként valójában csak egy processzort tartalmaztak. Soha nem volt többmagos processzoraink, és rácsok futtatására, rácsok indítására és megszakítókra építettük. A Hadoop egyik tervezési célja az volt, hogy soha ne veszítse el a munkát. És ez valóban a lemezhibáról szól, mert ha több száz szerverrel rendelkezik, akkor valószínűsíthető, hogy ha már vannak lemezeid a szerveren, akkor valószínűleg valami hasonlót kapsz, mint például a 99.8. Ez azt jelenti, hogy átlagosan az egyik kiszolgáló meghibásodik 300 vagy 350 naponként egyszer, egy évben egy napon. Tehát ha ezek százai lennének, akkor valószínű, hogy az év bármelyik napján szerverhibát kapsz.
A Hadoop kifejezetten e probléma megoldására lett kifejlesztve - oly módon, hogy bármi meghiúsul, pillanatfelvételeket készít minden, ami folyik, minden egyes kiszolgálón, és helyreállíthatja a futó kötegelt feladatot. És ez minden, ami a Hadoop-on valaha is futott, kötegelt feladatok voltak, és azt kell mondani, hogy ez egy igazán hasznos képesség. Néhány futtatott kötegmunka - különösen a Yahoo-ban, ahol azt hiszem, hogy Hadoop ilyen született - két vagy három napig futna, és ha egy nap elteltével kudarcot vallott, akkor nem akart elveszíteni a munkát ezt megtették. Tehát ez volt a tervezési pont a Hadoop elérhetőségének mögött. Nem hívná ezt a magas rendelkezésre állást, de a soros kötegelt munkák magas elérhetőségének nevezhetné. Valószínűleg így lehet megnézni. A magas rendelkezésre állás mindig a munkavonal jellemzői szerint van konfigurálva. Jelenleg a Hadoop csak az ilyen típusú helyreállítás szempontjából igazán soros kötegelt munkákra konfigurálható. A vállalati magas rendelkezésre állás valószínűleg a tranzakciós LLP szempontjából a legmegfelelőbb. Úgy gondolom, hogy ha nem úgy néz ki, mint egy valós idejű dolog, akkor Hadoop még nem csinálja. Valószínűleg hosszú távolság van attól, hogy ezt megtegyük.
De itt van a gyönyörű dolog Hadoop kapcsán. Ez a jobb oldali ábra, amelyen a szélén található szállítók listája található, és az összes rajzon található vonal jelzi az eladók és a Hadoop ökoszisztéma más termékei közötti kapcsolatokat. Ha megnézzük, ez hihetetlenül lenyűgöző ökoszisztéma. Nagyon figyelemre méltó. Nyilvánvalóan sok eladóval beszélünk képességeink szempontjából. A beszállítók között, akikkel beszéltem, van néhány igazán rendkívüli lehetőség a Hadoop és a memóriában való használat, a Hadoop tömörített archívumként való felhasználásának módja, a Hadoop ETL-környezetként való használata és így tovább. De valóban, ha maga a Hadoop termékkel egészíti ki, akkor az rendkívül jól működik egy adott helyiségben. Tehát, miközben kritizálom a natív Hadoop-ot, nem kritizálom a Hadoop-ot, amikor valójában hozzátesz valamilyen erőt hozzá. Véleményem szerint a Hadoop népszerűsége garantálja jövőjét. Ez alatt azt gondolom, hogy még ha minden kód sor is eltűnik, amelyet eddig a Hadoop-on írtak, akkor nem hiszem, hogy a HDFS API eltűnik. Más szavakkal, azt hiszem, hogy az API fájlrendszer megmarad, és esetleg a YARN, az ütemező, amely átnézi.
Ha tényleg megnézed, ez egy nagyon fontos képesség és egyfajta viasz erre egy perc alatt, de a másik dolog, ami, mondjuk, izgalmas emberek a Hadoopról, az egész nyílt forráskódú kép. Tehát érdemes átnézni, mi a nyílt forráskódú kép azon szempontból, amit valódi képességnek tartok.Noha a Hadoop és annak minden alkotóeleme minden bizonnyal képes megtenni azt, amit adathossznak nevezünk - vagy amint én inkább adattartálynak hívom - ez minden bizonnyal nagyon jó átmeneti terület az adatok adagolására a szervezetbe vagy az adatok gyűjtésére a szervezetben - rendkívül jó homokozódobozokhoz és a horgászathoz szükséges adatokhoz. Nagyon jó, mint prototípus-fejlesztési platform, amelyet a nap végén megvalósíthat, de fejlesztési környezetként szinte mindent tud, amire szükség van. Archívumtárként meglehetősen sok mindent megtalál, amire szüksége van, és természetesen nem drága. Nem hiszem, hogy el kellene választanunk a két dolog egyikét a Hadooptól, annak ellenére, hogy formálisan, ha úgy gondolják, nem a Hadoop alkotóelemei. Az online ék hatalmas mennyiségű elemzést hozott a nyílt forráskódú világba, és az elemzés nagy részét jelenleg a Hadoop futtatja, mert ez egy kényelmes környezetet biztosít, amelyben sok külső adatot felvehet és csak elkezdi játszani. egy analitikus homokozóban.
És akkor megvan a nyílt forráskódú képességek, amelyek mindkettő gépi tanulás. Mindkettő rendkívül hatékony abban az értelemben, hogy hatékony analitikai algoritmusokat valósít meg. Ha összerakod ezeket a dolgokat, megvan néhány nagyon-nagyon fontos képességmagja, amely valamilyen módon valószínűsíthető - függetlenül attól, hogy önmagában fejlődik-e, vagy a szállítók jönnek be a hiányzó darabok kitöltésére - ez nagyon valószínűleg hosszú ideig folytatódik, és minden bizonnyal azt hiszem, hogy a gépi tanulás már nagyon nagy hatással van a világra.
A Hadoop, a YARN fejlődése mindent megváltoztatott. Ami történt, a MapReduce-t nagyjából hegesztették a korai HDFS fájlrendszerbe. A YARN bevezetésekor az első kiadásban ütemezési képességet hozott létre. Az első kiadástól nem számíthat a rendkívül kifinomult ütemezésre, de ez azt jelentette, hogy ez már nem szükségszerűen egy javítókörnyezet. Olyan környezet volt, amelyben több feladat ütemezhető volt. Amint ez megtörtént, volt egy sor gyártó, akik tartózkodtak a Hadoop-tól - csak belépett és csatlakoztak ehhez, mert akkor csak megnézhetik, mint egy fájlrendszer ütemezési környezetét, és a cuccokat címezhetik azt. Vannak még olyan adatbázis-gyártók is, amelyek az adatbázisokat a HDFS-en telepítették, mert csak elviszik a motort, és csak a HDFS-re teszik át. A lépcsőzetes és a YARN használatával ez egy nagyon érdekes környezetvé válik, mivel összetett munkafolyamatokat hozhat létre HDFS-en keresztül, és ez valójában azt jelenti, hogy elképzelheti, hogy valóban egy olyan platformon gondolkodik, amely egyidejűleg több feladatot is képes futtatni, és egyre inkább elmozdul. missziókritikus dolgokat csinálni. Ha ezt megteszi, valószínűleg meg kell vásárolnia néhány harmadik féltől származó összetevőt, például a biztonságot és így tovább, és így tovább, amelyeknek a Hadoopnak valójában nincs könyvvizsgálói fiókja, hogy kitöltse a hiányosságokat, de Ön bejutni arra a pontra, ahol még a natív nyílt forráskóddal is megtehet érdekes dolgokat.
Ami azt hiszem, hogy a Hadoop valójában megy, személy szerint hiszem, hogy a HDFS alapértelmezett kicsomagolási fájlrendszerré válik, és ezért az operációs rendszerré, az operációs rendszerké válik az adatáramlás rácsához. Úgy gondolom, hogy hatalmas jövője van ennek, és nem hiszem, hogy ott áll meg. És azt hiszem, hogy az ökoszisztéma valójában csak segít, mert szinte mindenki, a tér minden eladója, ténylegesen vagy úgy integrálja a Hadoopot, és csak lehetővé teszik. Egy másik, a Hadoop túlzott mértékét érdemes megjegyezni, hogy ez nem túl jó platform, plusz a párhuzamosítás. Ha valóban megnézed, amit csinál, akkor valójában mit csinál, amikor rendszeresen készít egy pillanatképet minden szerveren, amikor végrehajtja a MapReduce feladatait. Ha nagyon gyors párhuzamosítást tervezne, akkor semmit sem csinál. Valójában valószínűleg nem önmagában használja a MapReduce-ot. A MapReduce csak az, amit mondanám, félig képes párhuzamosságra.
Kétféle megközelítés létezik a párhuzamosság szempontjából: az egyik a folyamatok csövezése, a másik pedig a MapReduce adatok elosztása, és elvégzi az adatok megosztását, tehát nagyon sok olyan munka van, ahol a MapReduce valójában nem lenne a leggyorsabb módszer erre, ám ez mégis megteszi. ad párhuzamosságot, és ettől nem lehet elvonni. Ha sok adat van, az ilyen teljesítmény általában nem olyan hasznos. A YARN, amint már említettem, nagyon fiatal ütemezési képesség.
A Hadoop egyfajta vonal húzza a homokba, a Hadoop nem adatraktár. Olyan távol, mint adattárház, ez szinte abszurd javaslat, hogy azt mondjuk, hogy van. Ebben a diagramban azt látom, hogy egyfajta adatáramlást hajtunk végre egy Hadoop-adattárolóból egy óriási méretű adatbázisba, amelyet valójában csinálunk, egy vállalati adattárházba. Megmutatom a régi adatbázisokat, adataim adatait az adattárházba, és a kirakodási tevékenységeket az adatraktárból kirakodó adatbázisok létrehozása céljából, de valójában ez egy olyan kép, amiben kezdem megjelenni, és azt mondanám, hogy ez olyan, mint a mi történik az adatraktárral a Hadoop segítségével. De ha magát nézi az adattárházra, rájössz, hogy az adattárház alatt van egy optimalizáló. Elosztott lekérdezéses dolgozók nagyon sok folyamaton ültek át, talán nagyon sok nagyszámú lemezen. Ami történik egy adattárházban. Valójában ez egy olyan architektúra, amelyet egy adattárházra építettek, és jó ideje eltart ahhoz, hogy valami ilyesmi felépüljön, és a Hadoop-nak egyáltalán nincs. Tehát a Hadoop nem adattárház, és véleményem szerint ez nem válik majd hamarosan.
Megvan ez a relatív adattároló, és nagyon érdekesnek tűnik, ha a világot csak egy esemény sorozatának tekintik, amely a szervezetbe áramlik. Ezt mutatom a diagram bal oldalán. Ha átviszi a szűrési és útválasztási képességet, és a streaminghez szükséges dolgok kiszorulnak a streaming alkalmazásoktól, és minden más egyenesen az adattárolóba kerül, ahol elkészítik és megtisztítják, majd az ETL továbbítja egyetlen adathoz. raktár vagy logikus adattárház, amely több motorból áll. Véleményem szerint ez a természetes fejlõdés a Hadoop számára.
Az ETW szempontjából érdemes rámutatni arra, hogy maga az adattárház ténylegesen költözött - nem az volt, ami volt. Természetesen manapság arra számítanak, hogy hierarchikus adatok szerint hierarchikus képességek vannak arra vonatkozóan, hogy az emberek vagy egyesek mi hívják az adattárházban található dokumentumokat. Ez a JSON. Lehetséges, hogy hálózati lekérdezéseket végez grafikon-adatbázisokkal, esetleg elemzéssel. Tehát, mi felé haladunk, egy ETW, amelynek ténylegesen bonyolultabb munkaterhelése van, mint amiben szoktuk. Tehát ez egyfajta érdekes, mert bizonyos értelemben azt jelenti, hogy az adattárház még kifinomultabbá válik, és emiatt még hosszabb időt vesz igénybe, mielőtt Hadoop bárhonnan hozzáér hozzá. Az adattárház jelentése kibővül, de magában foglalja még az optimalizálást is. Optimalizálási képességgel kell rendelkeznie, nem csak a lekérdezések felett, hanem ezen tevékenységek mindegyike felett.
Valóban ennyi. Ez minden, amit akartam mondani Hadoopról. Azt hiszem, továbbadhatom Ray-nak, aki még nem kapott diákat, de mindig jól beszél.
Eric Kavanagh: Fogom venni a diákat. Itt van a barátunk, Ray Wang. Szóval, Ray, mit gondolsz erről?
Ray Wang: Most azt hiszem, hogy ez volt a legértékesebb és legtökéletesebb történelem a kulcsfontosságú üzletekben, és ahol Hadoop a vállalkozásokkal kapcsolatosan ment el, amelyek ki vannak téve, tehát mindig sokat tanulok, amikor Robint hallgatok.
Valójában van egy diam. Felbukkanhatom itt egy diát.
Eric Kavanagh: Csak lépjen tovább, és kattintson a, kattintson a Start gombra, és menjen megosztani az asztalát.
Ray Wang: Megvan, oda megy. Valójában megosztom. Láthatja magát az alkalmazást. Lássuk, hogy megy.
A Hadoopról szóló összes beszédet, majd mélyen belemenünk a technológiákról szóló beszélgetésbe, amelyek léteznek és ahová a Hadoop halad, és sokszor azt szeretném visszavonni, hogy valóban megbeszéljék az üzletet. Sok olyan dolog, ami a technológiai oldalon történik, valójában ez a darab, ahol az adatraktárakról, az információkezelésről, az adatminőségről, az adatok elsajátításáról beszéltünk, és így hajlamosak vagyunk ezt látni. Tehát, ha megnézzük ezt a grafikont az alján, az nagyon érdekes, hogy az a személytípus, akit belefoglalunk a Hadoopról szóló beszélgetésbe. Vannak olyan technikusok és adattudósok, akik gekonónálnak, nagyon izgalmasak, és általában az adatforrásokról szólnak, igaz? Hogyan tudjuk elsajátítani az adatforrásokat? Hogyan tudjuk ezt a megfelelő minőségi szintekre juttatni? Mit tegyünk a kormányzással? Mit tehetünk a különféle források összehangolása érdekében? Hogyan tartjuk meg a származást? És minden ilyen vita. És hogyan lehetne több SQL-t kihozni a Hadoop-ból? Tehát ez a rész ezen a szinten zajlik.
Akkor az információs és a zenekari oldalon ez az, ahol érdekes lesz. Már kezdjük kötni ennek a betekintésnek a kimeneteleit, amelyeket megkapunk, vagy visszavonulunk az üzleti folyamatokhoz? Hogyan kapcsolhatjuk össze bármilyen metaadat-modelldel? Összekapcsoljuk a pontokat az objektumok között? Így az új igék és megbeszélések arról, hogy miként használjuk ezeket az adatokat, és elmozdulnak attól, ami hagyományosan a CRUD világában van: létrehozunk, olvasunk, frissítünk, törölünk, egy olyan világba, amelyben arról beszélünk, hogy hogyan veszünk részt, osszunk meg vagy működünk együtt, szeret vagy húz valamit.
Itt kezdjük látni az izgalmat és az innovációt, különösképp arról, hogy miként lehet ezeket az információkat felhasználni és értékükbe hozni. Ez a technológiai vezérelt vita a piros vonal alatt. E piros vonal fölött azokat a kérdéseket kapjuk, amelyeket mindig is fel akartunk tenni, és egyikük, amelyeket mindig felteszünk, például az, hogy például az Ön számára a kiskereskedelemben az a kérdés, hogy „Miért értékesítik jobban a vörös pulóverek? Alabamában, mint a kék pulóverek Michiganben? " Gondolkodhatott rajta, és azt mondhatja: "Ez egyfajta érdekes." Látod ezt a mintát. Feltesszük ezt a kérdést, és azon gondolkodunk: "Hé, mit csinálunk?" Talán az állami iskolákról van szó - Michigan vagy Alabama. OK, értem, látom, hová megyünk. És így kezdjük el megszerezni a ház üzleti oldalát, a pénzügyi szereplőket, a hagyományos BI képességekkel rendelkezőket, a marketinggel foglalkozó embereket és a HR munkatársait, mondván: "Hol vannak a mintáim?" Hogyan juthatunk el ezekhez a mintákhoz? És így látunk egy új módszert az innovációra a Hadoop oldalán. Valójában arról szól, hogyan tudjuk gyorsabban felfrissíteni a frissítési betekintést. Hogyan tudunk ilyen típusú kapcsolatokat létrehozni? Egészen azon emberekhez vezet, akik úgy működnek, mint a hirdetés: tech, amelyek alapvetõen megpróbálják a hirdetéseket és a releváns tartalmat összekapcsolni a valós idejû ajánlattételi hálózatoktól a konual hirdetésekig és a hirdetések elhelyezéséig, és ezt menet közben teszik.
Tehát érdekes ezt nézni. Látja Hadoop előrehaladását: "Hé, itt van a technológiai megoldás. Itt kell tennünk, hogy ezt az információt megkapjuk az embereknek." Akkor, amikor áthalad az üzletágon, ez az, ahol érdekes lesz. Ez a betekintés. Hol van az előadás? Hol van a levonás? Hogyan jósolunk dolgokat? Hogyan tudunk befolyást gyakorolni? És akkor hozza ezt az utolsó szintet, ahol valójában egy másik Hadoop innovációt látunk, amelyek a döntési rendszerek és tevékenységek körül zajlanak. Mi a következő legjobb akció? Tehát tudod, hogy a kék pulóverek jobban eladnak Michiganben. Egy csomó kék pulóvert ülsz Alabamában. Nyilvánvaló az, hogy "igen, ezt szállítsuk oda." Hogyan csináljuk? Mi a következő lépés? Hogyan tudjuk ezt visszakötni? Talán a következő legjobb fellépés, talán egy javaslat, talán valami, amely segít megakadályozni egy problémát, talán nem cselekedet is, amely önmagában is művelet. Tehát kezdjük látni, hogy ilyen minták jelennek meg. És az a szépség, amit visszatért ahhoz, amit mond a kulcsértékes boltokról, Robinról, az, hogy ilyen gyorsan történik. Olyan módon történik, hogy mi még nem így gondolkodtunk.
Valószínűleg azt mondanám, hogy az elmúlt öt évben felvettünk. Elkezdtük azon gondolkodni, hogy miként tudjuk újra felhasználni a kulcsérték-tárolókat, de éppen az elmúlt öt évben az emberek nagyon eltérő módon nézik meg, és ez olyan, mintha a technológiai ciklusok 40 éves mintákban megismétlődnének, tehát ez kedves egy vicces dolog, ahol a felhőre nézünk, és én ugyanúgy szeretem a mainframe időbeli megosztását. A Hadoop-ra nézünk, és hasonlóan a kulcsérték-tárolóhoz - talán ez egy adat mart, kevesebb, mint az adattárház -, és így ezeket a mintákat újból meglátjuk. Amit most próbálok tenni, arra gondolok, hogy mit csináltak az emberek 40 évvel ezelőtt? Milyen megközelítéseket és technikákat és módszereket alkalmaztak, amelyeket az emberek technológiái korlátoztak? Ez egyfajta hajtóereje ennek a gondolkodási folyamatnak. Tehát amikor áttekintettük a Hadoop mint eszköz nagyobb képét, amikor visszatérünk és gondolkodunk az üzleti következményekről, ez egy olyan út, amelyet általában átvezetünk az embereknek, hogy megnézhessük, milyen darabokat, mely részeket tartalmaznak az adatok döntési út. Ez csak valami, amit meg akartam osztani. Ez egy olyan gondolkodás, amelyet belsőleg alkalmaztunk, és remélhetőleg hozzáadunk a beszélgetéshez. Szóval visszaadom neked, Eric.
Eric Kavanagh: Ez fantasztikus. Ha tudsz maradni néhány kérdéssel és kérdéssel kapcsolatban. De tetszett, hogy visszavitte az üzleti szintet, mert a nap végén az üzletről szól. A dolgok elvégzéséről és annak biztosításáról van szó, hogy okosan költenek pénzt, és ez az egyik kérdés, amelyet már láttam, így a felszólalók érdemes gondolkodni azon, hogy mi a Hadoop útvonal TCL-je. Van valami kedves hely a között, például az irodai polcok szerszámaival, a dolgok hagyományos módon történő elvégzésével és az új szerszámkészletekkel, mert ismételje meg, gondoljon rá, sok ilyen cucc nem új, csak egyfajta azt hiszem, a legmegfelelőbb módszer egy új módszerrel történő összeillesztés.
Tehát menjünk előre, és ismertessük barátunkat, Nikitát Ivanovot. A GridGain alapítója és vezérigazgatója. Nikita, megyek előre, és átadom a kulcsot neked, és azt hiszem, odakint vagy. Hallasz engem Nikita?
Nikita Ivanov: Igen, itt vagyok.
Eric Kavanagh: Kiváló. Tehát a padló a tied. Kattintson arra a diára. Használja a lefelé mutató nyilat, és vegye el. Öt perc.
Nikita Ivanov: Melyik diára kattinthatok?
Eric Kavanagh: Csak kattintson a csúszda bárhová, majd a billentyűzet lefelé mutató nyílával mozoghat. Csak kattintson a diára, és használja a lefelé mutató nyilat.
Nikita Ivanov: Rendben, csak néhány gyors dia a GridGainról. Mit tegyünk a beszélgetés során? A GridGain alapvetően memóriában lévő számítógépes szoftvert állít elő, és a kifejlesztett platform része a memóriában lévő Hadoop gyorsító. A Hadoop szempontjából inkább magunkra gondolunk, mint a Hadoop teljesítmény szakembereire. Amit alapvetően a memórián belüli számítástechnikai platformon végezzük, amely olyan technológiákból áll, mint például az adatrács, a memória streaming és a számítási rácsok, képes lesz plug-and-play Hadoop gyorsítót telepíteni. Ez nagyon egyszerű. Jó lenne, ha kidolgozunk valamilyen plug-and-play megoldást, amely közvetlenül a Hadoop telepítéséhez telepíthető. Ha Önnek, a MapReduce fejlesztőjének, fellendítésre van szüksége anélkül, hogy új szoftvert kellene írnia, vagy a kód megváltoztatása, vagy a változás, vagy alapvetően minden minimális konfigurációs változtatással kell rendelkeznie a Hadoop-fürtön. Ezt fejlesztettük ki.
Alapvetően a memóriában lévő Hadoop gyorsító két elem optimalizálásán alapszik a Hadoop ökoszisztémájában. Ha a Hadoop-ra gondolsz, akkor elsősorban a HDFS-en alapul, amely a fájlrendszer. A MapReduce, amely a versenyek párhuzamos, a fájlrendszer tetején történő futtatásának kerete. A Hadoop optimalizálása érdekében mindkét rendszert optimalizáljuk. Fejlesztettünk egy memória-fájlrendszert, amely teljesen kompatibilis, 100% -ban kompatibilis plug-and-play funkcióval, HDFS-sel. Futtathat a HDFS helyett, a HDFS tetején is futtathatja. Fejlesztettünk egy memóriában lévő MapReduce-t is, amely plug-and-play kompatibilis a Hadoop MapReduce-val, de sok optimalizálás történik a MapReduce munkafolyamata és a MapReduce ütemezésének működése szempontjából.
Például erre a diára nézzen, ahol megmutatjuk a másolat halmazát. A bal oldalon a tipikus operációs rendszer található a GDM-mel, ezen a diagramon felül az alkalmazás központja. Közepén van a Hadoop. És a Hadoop ismét a HDFS-en és a MapReduce-en alapul. Tehát ez ábrázolja ezen a diagramon, hogy mi az, amit beágyazunk a Hadoop verembe. Ismét plug-and-play; nem kell módosítania a kódot. Csak ugyanúgy működik. A következő dián alapvetően megmutattuk, hogyan optimalizáltuk a MapReduce munkafolyamatot. Ez valószínűleg a legérdekesebb rész, mert a legtöbb előnyt nyújt Önnek, ha a MapReduce feladatokat futtatja.
A tipikus MapReduce, amikor elküldi a munkát, és a bal oldalon diagram látható, a szokásos alkalmazás. Tehát általában a munkát nyújtja be, és a munka egy munkakövetőhöz kerül. Kölcsönhatásba lép a Hadoop névcsomóponttal, és a névcsomópont valójában a szoftver, amely kezeli a digitális fájlokkal való interakciót, és egyfajta megőrzi a fájlok könyvtárat, majd a job tracker kölcsönhatásba lép az egyes csomópontok feladatkövetőjével és a a feladatkövető kapcsolatba lép egy Hadoop adatcsomóponttal, hogy adatokat szerezzen. Tehát ez alapvetően nagyon fajta magas szintű áttekintés arról, hogy hogyan kap a MapReduce feladat a számítógépekben. Mint láthatja, hogy mit teszünk a memóriánkkal, a Hadoop MapReduce már teljes mértékben megkerüli ezt a komplex ütemezést, amely sok időt vesz igénybe a végrehajtás során, és közvetlenül az ügyféltől a GridGain adatcsomópontra megy, és a GridGain adatcsomó megőrzi mindazt az e- memória a nyilvánvalóan gyors, gyors végrehajtáshoz.
Tehát alapvetően megengedjük, hogy az 5x-től egészen a 100-szoros teljesítménynövekedésig terjedjen bizonyos típusú rakományoknál, különösen a rövid levélű hasznos teher esetén, ahol szó szerint minden másodpercben mérik. Drámai lendületet adhatunk a teljesítménynek, szó szerint alapvető változás nélkül.
Rendben, ez számomra csak egy.
Eric Kavanagh: Igen, tartsa be a kérdéseket és válaszokat. Semmi kétség felőle.
Hadd adjak át John Santaferraro-nak. John, csak kattintson erre a diára. A lefelé mutató nyíl segítségével lépjen tovább.
John Santaferraro: Jól van. Nagyon köszönöm, Eric.
A nézetem és az Actian perspektíva valóban az, hogy a Hadoop valójában az értékteremtésről szól, tehát ez a digitális média példája. A Hadoop-ba pumpált adatok nagy része a digitális médiával, a digitális marketinggel és az ügyfelekkel kapcsolatos, tehát remek lehetőség van - 226 milliárd dolláros kiskereskedelmi vásárlásra kerül sor a következő évben. A nagy adatok és a Hadoop új adatok begyűjtéséről szól, hogy betekintést nyújtson belőlük a részvételhez.Hogyan hajtja meg a 14% -kal magasabb marketing megtérülést és profitot a megfelelő közepes X, a megfelelő csatornák és a megfelelő digitális marketing terv kitalálása alapján? Hogyan javíthatja a marketingbefektetések általános megtérülését? Mellesleg, 2017-ben a Hadoopra tekintve gondolkodnunk kell az a tény, hogy a CMO, a marketing vezérigazgatója, a 2017-es kiadások meghaladják az informatikai kiadásokat, tehát valójában az értéknövelésről szól. Véleményünk szerint mindenféle zaj zajlik a diagram bal oldalán, amikor az adatok a Hadoopba kerülnek.
Végül ügyfeleink vásárlói örömöt, versenyelőnyt, világszínvonalú kockázatkezelést, zavaró új üzleti modelleket akarnak létrehozni, és mindezt megteszik az átalakító érték biztosítása érdekében. Mindezeket az adatokat a Hadoop-ban szeretné elfogni, és képesek lennének az osztályon belüli legjobb dolgokra, például az adatok felfedezésére korlátozások nélkül, az ott élő adatok bármilyen méretű késleltetése nélkül - mozogva reaktívról prediktív típusú elemzéseket végez, és mindent dinamikusan végez, ahelyett, hogy statikusan nézi az adatokat. Mi önt a Hadoopba? Hogyan lehet elemezni, amikor megérkezik? Hová tegye a nagy teljesítményű elemzést? És végül mindent egy szegmensre mozgat.
Tehát amit tettünk az Actiannél az Actian Analytics platformon, egy exoskeletont építettünk a Hadoop körül, hogy megadjuk mindazokat a képességeket, amelyekre szüksége van, így bármilyen adatforráshoz csatlakozhat, amely a Hadoopba behozza, és mint egy adatszolgáltatás bárhol, ahol szüksége van rá. Van olyan analitikai, adatkeverési és adatgazdagítási típusú operátorok, amelyeket szó szerint húzunk és dobunk be, hogy kiépítsük ezeket az adatokat és az analitikus munkafolyamatokat, és bármilyen programozás elvégzése nélkül, ezt a terhelést YARN-en keresztül toljuk le a Hadoop csomópontok, így nagy teljesítményű adattudományt végezhet natív módon a Hadoop segítségével. Tehát az összes adat előkészítése, az összes adattudomány a Hadoop-on nagymértékben párhuzamos, rendkívül optimalizált, nagy teljesítményű, majd amikor szüksége van rá, nagy sebességű kapcsolaton keresztül jobbra mozgatja a nagyteljesítményű elemző motorhoz , ahol szuper alacsony alacsony késleltetésű elemzést végezhet, és mindezt a valós idejű elemzéseknek a felhasználók számára történő továbbítására, a gépek közötti számítógépes kommunikációra, valamint az elemzésekre és az üzleti folyamatokra vonatkozó fogadások fogadására, nagy adatok adagolására alkalmazások vagy alkalmazások.
Ez egy példa a telco churn-re, ahol ennek a diagramnak a tetejére, ha éppen például telco churn-t építesz, ahol egyfajta adatot gyűjtöttél és a Hadoop-ba töltötted, akkor mintegy 5% -ot tudnék azonosítani. a lehetséges csávódó közönségnek. Amint lefelé halad ezen a táblán, és további típusú adatforrásokat ad hozzá, az ott található középső oszlopban összetettebb elemzéseket végez. Lehetővé teszi, hogy az érzés ellen fellépjen az azonosítás érdekében. Az 5% -os azonosítástól a 70% -os azonosításig mozoghat. Tehát a távközlési társaságok, a kiskereskedelmi szervezetek, a gyorsszolgáltatók bármelyike számára, bárki számára, akinek van ügyfélbázisa, ahol félelem és károk vannak a csüggedés miatt.
Ez a fajta elemzés a Hadoop exoskeleton-kompatibilis verzióján futtatja az igazi értéket. Amit itt láthat, az az ilyen érték. Ez egy példa a távközlési társaság éves jelentéséből, amely bemutatja a tényleges előfizetők számát (32 millió). Meglévő cserélési arányuk, amelyet minden telefonszám 1,14, 4,3 millió előfizető veszített el évente, 1,14 milliárd dollárt és 2,1 milliárd bevételt jelent. Ez egy nagyon szerény példa arra, hogy hogyan generál értéket a Hadoopban élő adataiból, ahol láthatja az újbóli megszerzés potenciális költségeit, ahol a potenciál az, ha a Hadoopot az exoskeleton futó elemzéssel használják, hogy alapvetően segítséget nyújtanak ennek a telekommunikációs cégnek a 160 mentésében. millió dollár mellett elkerülhető a 294 millió veszteség. Ez a fajta példa, amire gondolunk, hogy előrehozza a Hadoop-ot.
Eric Kavangh: Rendben, fantasztikus. És Jim, hadd menjek előre, és adjak neked kulcsokat. Tehát, Jim Vogt. Ha rákattintana a diára, és használja a billentyűzet lefelé mutató nyílát.
Jim Vogt: Megvan. Nagyszerű kép. Rendben, köszönöm szépen. Majd egy kicsit elmondok a Zettaset-ről. Egész délután itt beszéltünk a Hadoop-ról. Ami érdekes a cégünknél, az az, hogy alapvetően karrierünket azáltal, hogy a vállalkozás számára új technológiát keményítünk meg - képessé tehetjük a hiányosságok kiküszöbölését új technológiánkban, hogy ez széles körben alkalmazható legyen a vállalati működési környezetben. Jelenleg néhány dolog történik a piacon. Olyan, mint egy nagy nyitott medenceparti, ugye? De most a szülők hazaértek. És alapvetően megpróbáljuk visszahozni ezt a dolgot a valóság bizonyos érteleméhez, azzal, hogy hogyan építhetünk itt egy valódi infrastruktúradarabot, amely méretezhető, megismételhető, erőforrás-igénytelen és biztonságos, és ami a legfontosabb. A mai piacon a legtöbb ember még mindig ellenőrzi a gumiabroncsokat a Hadoop-on. A fő ok az, hogy van néhány dolog. Az egyik az, hogy magában a nyílt forráskódban, bár nagyon sok hasznos dolgot végez az adatforrások keverése, a struktúrára vonatkozó adatok és a nagyon hasznos adatforrások megtalálása szempontjából, valójában nagyon sok hiányzó és vállalati tulajdonság hiányzik. a biztonság, a nagyobb rendelkezésre állás és az ismételhetőség körül, hogy az embereknek nem csupán 10 vagy 20 csomópontú fürtöt, hanem 2000 és 20 000 csomópontú fürtöt kell telepíteniük - több klaszter is létezik. Amit az utóbbi két évben bevételszerzésre fordítottak, az elsősorban az ezen osztályozási klaszterek felállítását támogató szolgáltatások volt. Tehát van egy nem megismételhető szoftverfolyamat, amely ezt ténylegesen aktív módon bevezetheti a piacra.
Tehát amit a szoftverünkbe beépítettünk, egy pár dolog. Valójában átláthatóak vagyunk a disztribúciókban. A nap végén nem érdekel, hogy CVH vagy HDP, az mind nyílt forráskódú. Ha megvizsgáljuk azokat a nyers Apache-összetevőket, amelyek építették ezeket a disztribúciókat, akkor valójában nincs ok, miért kellene magát egyetlen disztribúcióba zárnia. És így az egész disztribúción dolgozunk.
A másik dolog az, hogy átlátszó módon kitöltsük a hiányosságokat néhány olyan elem tekintetében, amelyek hiányoznak magából a kódból, a nyílt forrásból. Tehát beszéltünk a HA-ról. A HA nagyszerű abban, hogy nem nyújt feladatátvételt, de mi történik, ha valamelyik aktív folyamat, amelyet ezekre a klaszterekre állít, meghiúsul? Ez leteheti, vagy létrehozhat egy biztonsági lyukat, ha akarod. Amikor a szoftverkomponenseket beépítettük a megoldásba, mindegyik HA esernyő alá esik, ahol aktívan figyeljük a fürtön futó összes folyamatot. Ha a kódszerepek csökkennek, akkor le veszi a klasztert, tehát alapvetően azt jelenti, hogy a feladatátvétel nem nagy, hacsak nem aktívan figyeli a fürtön futó összes folyamatot, akkor nem rendelkezik igaz HA-val. Ez tehát elengedhetetlen ahhoz, amit itt, a Zettasetnél fejlesztettünk ki. És oly módon, hogy ténylegesen megvan egy szabadalom, amelyet erről kiadtak és tavaly novemberben megadtak ennek a HA-megközelítésnek a körül, amely éppen meglehetősen újszerű és különbözik a nyílt forráskódú verziótól, és sokkal keményebb a vállalkozás számára.
A második darab valódi RBAC-t képes végrehajtani. Az emberek RBAC-ról beszélnek. Más nyílt forrású projektekről beszélnek. Miért kellene újra létrehoznia ezeket a bejegyzéseket, valamint azokat a felhasználókat és szerepeket, amikor már léteznek LDAP-ben vagy az aktív könyvtárban? Tehát összekapcsoljuk ezeket átlátható módon, és az összes folyamatunkat nemcsak ezen RBAC esernyő, hanem a HA égisze alatt is összehajtjuk. Elkezdik beépíteni ezt az infrastruktúra-titkosítást, titkosítást az adatok nyugalmi állapotában, a mozgás állapotában, az összes olyan megkeményített biztonsági darabból, amelyre valóban szükségük van az információk biztonságához.
Valójában ezt vezeti az iparágak, amelyek a következő csúszkán vannak, amelyek finanszírozást és egészségügyi ellátást profitálnak, és megfelelnek a követelményeinknek. Önnek képesnek kell lennie arra, hogy megvédje ezeket az adatkészleteket, és nagyon dinamikus módon kell megcsinálnia, mivel ezek az adatok bárhol elhelyezkedhetnek ezen a párhuzamos csomóponton és klaszteren, és másolhatók és így tovább, tehát alapvetően ez az a nagy esernyő, amelyet építettünk. Az utolsó darab, amire az embereknek szükségük van, hogy képesek legyenek összerakni a darabokat. Tehát miután megbeszéljük az elemzést, amellyel John beszélt, és hogy ki tudjuk használni az adatok értékét, és ezt egy nyílt felületen keresztül elvégezzük, ezt az infrastruktúrát használjuk - ezt építettük be szoftverünkbe.
Tehát az a három eset, amelyben itt voltam, és srácok, akik itt bántalmaznak, valójában a pénzügyek, az egészségügy és a felhő körül zajlott, ahol többszörös bérlői környezettel kell foglalkoznia, és lényegében el kell különítenie az emberek érzékeny adatait, tehát A biztonság és a teljesítmény kulcsfontosságú az ilyen típusú alkalmazásokban, függetlenül attól, hogy felhőben vagy érzékeny adatkörnyezetben működik-e.
Az itt látható legutóbbi dia valóban arra az infrastruktúrára vonatkozik, amelyet cégként összegyűjtöttünk, és nem csupán a Hadoopra jellemző. Ez valami, amelyet ugyanúgy alkalmazhatunk más NoSQL technológiákra is, és itt továbbfejlesztjük társaságunkat. És akkor be fogunk vonni más nyílt forráskódú összetevőket is, például a HBase-t és így tovább, és biztosítani kell azokat az infrastruktúrán belül oly módon, hogy Ön nem kötődik egyetlen disztribúcióhoz. Olyan, mintha valóban nyitott, biztonságos és robusztus infrastruktúrája van a vállalkozás számára. Tehát erről van szó, és erre törekszünk, hogy alapvetően felgyorsítsuk a Hadoop alkalmazását, hogy az emberek megszabaduljanak a húsz csomópontú csoportoktól, és valójában bízzanak abban, hogy egy sokkal nagyobb környezetet alkalmaznak, amely jobban szem előtt tartja a Hadoopot, és felgyorsítja a piac mentén. Köszönöm.
Eric Kavanagh: Ez fantasztikus, nagyszerű. Ne felejtsd el a kérdéseket és válaszokat. Végül, utoljára, de nem utolsósorban, megkaptuk Phu Hoangot, a DataTorrent vezérigazgatóját. Hadd menjek előre, és átadjam a kulcsot neked. A kulcsok most a tiéd. Kattintson a csúszda bárhová, a billentyűzet lefelé mutató nyílával mozgathatja őket.
Phu Hoang: Nagyon köszönöm.
Tehát igen, azért vagyok itt, hogy a DataTorrentről beszéljek, és valójában azt hiszem, hogy a DataTorrent története nagyszerű példa arra, amit Robin és Ray beszélt az ülésen, amikor azt mondják, hogy Hadoop nagyszerű munka, nagy alap . De sok célja van. De a jövő világos, mivel a Hadoop ökoszisztéma, ahol több játékos érkezik, képesek felépíteni és hozzáadott értéket hozzáadni az alapítvány tetejére, hogy valóban a tárolástól a betekintésig működjenek, és ez valójában a DataTorrent története.
Amit ma beszélni fogok, valójában a valós idejű nagy adatok átvilágításáról szól. Amit látod, miközben az ügyfelekkel lépünk kapcsolatba, soha nem találkoztam egyetlen olyan ügyféllel, aki azt mondta nekem: "Hé, célom az, hogy akcióórákat vagy napokat tegyek meg az üzleti eseményeim megérkezése után". Valójában mind azt mondják, hogy azonnal akarnak cselekedni az események bekövetkezése után. A késés problémája az, hogy a Hadoop ma a MapReduce paradigmája. Hogy megértsük miért, érdemes áttekinteni a Hadoop történetét.
A Yahoo mérnöki tevékenységének nagy részét vezettem, amikor felvételtük Doug Cutting-re, a Hadoop alkotójára, és több mint száz mérnököt megbíztunk a Hadoop felépítésére az internetes keresés, a reklám és az adattudomány feldolgozása érdekében. De a Hadoop valóban hátulként lett felépítve, hogy ezeket a nagyon nagy fájlokat olvassa, írja és feldolgozza. Tehát, bár hatalmas méretezhetősége és magas költsége miatt rendkívül zavaró technológia, van egy lyuk abban, hogy sok késés van a nagy fájlok feldolgozásához. Most méltányosnak mondhatjuk, hogy a Hadoop mára egy olyan plató operációs rendszerré vált, amely valóban számítástechnikai és széles körben alkalmazkodik számos vállalkozás számára. Még mindig ugyanazt a folyamatot gyűjtik az események nagy fájlokká, és futtatják ezeket a kötegelt Hadoop feladatokat, hogy a következő napon belépjenek. Amit a vállalati ügyfelek most azt akarják, hogy pontosan ugyanazokat a betekintéseket akarják, de azt akarják építeni, hogy ezeket a betekintést sokkal korábban megszerezzék, és ez lehetővé teszi számukra, hogy ténylegesen cselekedjenek ezekre az eseményekre, amikor az esemény történik, nem pedig talán néhány órával később, miután megtörtént. vissza feldolgozva.
Eric Kavanagh: Szeretné előremozgatni a diáit, csak a kíváncsiságból?
Phu Hoang: Igen, most jön. Hadd illusztráljam ezt az egyik példát. Ebben a példában a Hadoop használatával hátrafelé, ahol folyamatosan foglalkozik fájlokkal, először egy szervezet felhalmozhatja az összes eseményt a teljes napra, 24 órás adatokra. Ezután kötegelik feldolgozásra, amely további nyolc órát vehet igénybe a MapReduce segítségével, és így már 32 óra telt el az idő, mielőtt bármilyen betekintést kapnának. A valós idejű adatfolyam-feldolgozással azonban az események bekerülnek és azonnal feldolgozásra kerülnek, nincs felhalmozási idő. Mivel mindezt a feldolgozást, mind a memóriában elvégzzük, a memórián belüli feldolgozás szintén másodperc alatt van. Egész idő alatt 30 órával csökkenti az eltelt időt valami nagyon kicsire. Ha 30 órát 10 órára csökkent, az értékes, de ha másodpercre tudjuk csökkenteni, történik valami mélyreható. Most már tehet lépéseket az eseményedre, amíg az esemény még nem zajlik, és ez lehetővé teszi a vállalkozások számára, hogy megértsék, mit csinálnak termékeik, üzleti tevékenységüket, mit csinálnak a felhasználók valós időben, és reagálni tudnak erre.
Nézzük meg, hogyan történik ez. Valójában a piaci erők és a technológia kombinációja lehetővé tette a DataTorrenthez hasonló megoldás összegyűjtését, tehát piaci szempontból a Hadoop valójában a tényleges big data architektúrává válik, amint mondtuk, igaz? Egy 2013-ban végzett IDC-tanulmányban azt mondják, hogy ez év végére a vállalkozások kétharmada telepítette a Hadoopot és a DataTorrent számára, legyen az Apache Hadoop vagy valamelyik hitelesített partnerünk, például Cloudera vagy Hortonworks, a Hadoop valóban egyértelműen a választás vállalkozás számára. Technológiai szempontból, és azt hiszem, hogy Robin és Ray erre utaltak, a Hadoop 2.0-t úgy hozták létre, hogy valóban lehetővé tegye a Hadoop számára, hogy sokkal általánosabb esetekre terjesszen ki, mint a MapReduce kötegelt paradigma, és társalapítóm, Amal, aki a Yahoo-nál vezette a A Hadoop 2.0 fejlesztése valóban lehetővé teszi az operációs rendszer ezen rétegének, hogy még sok más számítási paradigma legyen rajta, és a valós idejű adatfolyamot választottuk. Ha a valós idejű streaming e rétegét a YARN tetejére helyezi, akkor valójában a DataTorrentre gondolhat, mint a MapReduce valós idejű egyenértékére. Bármit is tehetsz a MapReduce használatával kötegelt formátumban, most megteheted a DataTorrent streamingjét, és hatalmas mennyiségű adatot tudunk feldolgozni. Az adatokat több dimenzióban szeletelhetjük és kockázhatjuk. Elosztottuk a számítástechnikát, és a YARN-t használjuk erőforrások biztosításához. Megvan a teljes nyílt forráskódú Hadoop ökoszisztéma, amely lehetővé teszi a gyors alkalmazásfejlesztést.
Hadd beszéljek egy kicsit a DataTorrent aktív képességeiről. Öt perc alatt nehéz számomra, hogy sokat adok neked részletesebben, de hadd engedjek meg, hogy csak megvitassam és újra megkülönböztessem. Először is, a másodperc alatt a skálázható lenyelés, ugye? Ez arra utal, hogy a DataTorrent platformja képes arra, hogy ezt valós időben ki tudja venni több száz adatforrásból, és azonnal megkezdi azok feldolgozását. Ez közvetlenül kapcsolódik a MapReduce hátsó feldolgozásához, amely a Hadoop 1.0-ban található, és az események méretétől függően változhatnak. Lehetnek olyan egyszerűek, mint egy sor a naplófájlban, vagy sokkal összetettebbek lehetnek, mint például a CDR, hívás adatrekord a telekommunikációs iparban. A DataTorrent a beérkező terheléstől függően képes dinamikusan felfelé vagy lefelé skálázni a felszívódást, és másodpercenként több tízmillió bejövő esemény kezelésére képes. A másik fő dolog itt természetesen maga a feldolgozás, amely valós idejű ETL logikában van. Tehát amint az adatok mozgásban vannak, belemegy az ETL logikába, ahol verem-átalakítást és betöltést végez, és így tovább. És a logika valóban akkor valósul meg, ha egy sorozatot összekapcsolunk egymással összekapcsolt operátoroknak egy adatfolyam-grabban. Ma több mint 400 operátor nyílt forráskódú, és lehetővé teszi az alkalmazások nagyon gyors létrehozását. És mindent lefednek, a bemeneti csatlakozóktól kezdve az összes folyamatig, az adatbázis-illesztőprogramokig és csatlakozókig, ahol mindenféle információt el kell tölteni az áramváltásra.
A kombináció, ha mindezt memóriában végzi, és a skálát több száz csomóponton megteremti, valóban megteremti a kiváló teljesítményt. A DataTorrent másodpercenkénti késleltetéssel képes milliárd eseményt feldolgozni másodpercenként.
Az utolsó darab, amelyet szeretnék kiemelni, a magas rendelkezésre állású architektúra. A DataTorrent platformja teljes körűen feladja az ismereteket; ez azt jelenti, hogy a platform automatikusan puffereli az eseményt, és rendszeresen ellenőrzi a lemezen lévő operátorok állapotát annak biztosítása érdekében, hogy esetleg ne legyen probléma. Az alkalmazások másodpercek alatt meg tudják mondani adatnapló és emberi beavatkozás nélkül. Egyszerűen fogalmazva: az adatlap milliárd eseményt dolgoz fel, és másodpercekben adatban tárolja az adatokat, 24/7 fut, és soha, soha nem megy le. A képességek valóban megkülönböztetik a DataTorrent a piactól, és valóban a vállalkozás vezető kritikus, valós idejű elemző platformjává teszik. Ezzel meghívjuk Önt, hogy látogasson el honlapunkra, és ellenőrizze minket.
Kösz.
Eric Kavanagh: Igen, nagyon köszönöm. Felteszek egy kérdést, valójában egy megjegyzést, és hagyom, hogy magyarázzon rá. Tényleg azt hiszem, hogy itt van a labda azzal a koncepcióval, hogy átadja ezeket az operátorokat, és hagyja, hogy az emberek szinte a Legoshoz hasonlóan használják ezeket az operátorokat nagy adat-alkalmazások készítéséhez. Tudna beszélni arról, hogy mi megy bele ezekbe az üzemeltetőkbe és összevarrja őket, hogyan csinálja valójában ezt?
Phu Hoang: Nagyszerű kérdés. Tehát mindenekelőtt ezek az operátorok vannak a szokásos Java Logic alkalmazásban. Ezekből 400-at szállítunk. Mindenféle feldolgozást végeznek, és így az alkalmazás felépítéséhez valójában csak összekapcsolja az operátorokat egy adatáramlási grafikonba. Vevőinkben azt tapasztaljuk, hogy számos operátort használnak, amelyek a könyvtárunkban vannak, valamint saját maguk veszik fel az egyedi logika feladatát, és operátoraivá teszik, hogy ezt grafikonba tudják igazítani.
Eric Kavanagh: Oké, jó. Véleményem szerint jó az, ha John Santaferraro-t vonjuk be az Actianből, mert srácok, kissé hasonló megközelítést alkalmaznak, számomra úgy tűnik, hogy egyfajta menedzsment réteget nyitnak, hogy különféle operátorokkal játszhassanak. Tudsz beszélni arról, hogy mit csinálsz azzal kapcsolatban, hogy milyen eszközökről éppen beszélünk, John?
John Santaferraro: Igen, pontosan. Van analitikai operátorok, valamint transzformációs operátorok, operátorok az adatok keveréséhez és gazdagításához, és ez nagyon hasonló. A drag and drop felületet használva összekapcsolhatja ezeket az adatfolyamokat vagy munkafolyamatokat, sőt akár az analitikus munkafolyamatokat is. Így minden, attól kezdve, hogy csatlakozhatunk az adatokhoz, képesek vagyunk az adatok keverésére és gazdagítására, az adatok tudományának vagy a gépi tanulási algoritmusoknak a futtatására, majd ezt akár egy nagy teljesítményű, alacsony késleltetésű elemző motorba is. Azt találjuk, hogy mind a nyílt forráskódú kilenc projektre épül.Tehát megragadunk egy csomó operátort, amelyet fejlesztnek, majd ezt felvesszük, és a YARN-en keresztül, nagyon hasonlóan ahhoz, amit Phu a DataTorrent-ben leírt, lenyomjuk ezt úgy, hogy párhuzamos legyen a Hadoop összes csomópontjával. fürt. Nagyon sok arról szól, hogy a Hadoop-ban lévő adatokat sokkal hozzáférhetőbbé tegyék az üzleti felhasználók és a kevésbé képzett munkavállalók számára, valaki adattudóson kívül.
Eric Kavanagh: Rendben, hadd menjek újra Nikitát. Az ötöt is feldobom. Tudna beszélni arról, hogyan közelíti meg ezt a megoldást azzal a viszonylatban, amiről a két úriember éppen beszélt? Hogyan valósítja meg valaki ezeket a dolgokat, és kihasználja a GridGain szolgáltatást?
Nikita Ivanov: Nos, azt hiszem, a legnagyobb különbség köztünk, és gyakorlatilag a többi részünk között az, hogy nem követeljük meg, hogy készítsen bármilyen felvételt - nem kell tenned semmit, ez egy plug-and-play. Ha van ma alkalmazásod, akkor gyorsabban fog működni. Nem kell módosítania a kódot; nem kell tennie semmit; telepítenie kell a GridGain szoftvert a Hadoop-fürt oldalához, és ennyi is. Szóval ez a legnagyobb különbség, és beszélgettünk ügyfeleinkkel. Ma számos különféle megoldás létezik, amelyek felszólítanak valamit változtatni: programozás, az API végrehajtása, az interfészek használata és az semmi. A miénk nagyon egyszerű. Nem kell sok időt fektetnie a Hadoop ökoszisztémájába, és bármit is tett, a MapReduce vagy az eszközök továbbra is használják. A GridGain segítségével nem kell megváltoztatnia egyetlen kódsorot, csak gyorsabban fog működni. Ez a legnagyobb különbség, és ez a legnagyobb a számunkra.
Eric Kavanagh: Tegyük vissza ide Jim-et is. Jim, az idézet megöl engem. Közben le kellett írnom. Beteszem valamiféle fedélzetre, de a Hadoop ökoszisztéma most olyan, mint egy medence parti, és a szülők éppen otthon jöttek. Ez vicces cucc ember; ez ragyogó. Tudsz beszélni arról, hogy srácok hogyan jönnek a színpadra? Hogyan valósítja meg ezt? Meddig tart ez? Hogyan működik mindez?
Jim Kaskade: Igen. Tehát van néhány változat, a céltól függően, de manapság tipikusan olyan értékeléseket látunk, amelyekben figyelembe veszik a biztonságot. Ami történt néhány más esetben, és különösen az elmúlt évben, amikor az emberek nagy terveket telepítettek, az volt, hogy volt egyfajta tudományos projekt, ha akarsz, vagy valaki a technológiával játszik, és egy klaszter felállt, dolgozott, és dolgozom vele, de akkor megjelenik a biztonsági srác, és ha élő adatközpontra megy, akkor alapvetően ugyanazokat a követelményeket kell teljesítenie, mint amelyek az adatközpontban működő egyéb berendezésekre vonatkoznak, ha egy olyan infrastruktúra, amelyet kiépítünk. Tavaly még néhány banknál azt mondták, hogy tavaly 400–1000 csomópontot telepítenek, és még mindig ülnek egy 20 csomópontú fürtön, főleg azért, mert most egy biztonsági személy csatlakoztatva van. a pénzügyi megfelelésről, az információs csoportokról, amelyek a fürtön ülnek, és így tovább. Ügyféltől függően változik, de általában ez az, ami meghosszabbítja a ciklusokat, és ez jellemző egy új technológiára, ahol ha valóban ezt a termelési környezetbe szeretné telepíteni, akkor ennek valójában rendelkeznie kell ezekkel a darabokkal, beleértve a nagyon értékes nyitott termékeket is. - forrásokat szerez, ugye?
Eric Kavanagh: Oké, jó. Lássuk. Vissza fogom hozni Phu-t az egyenletbe. Jó kérdésünk van az ön számára. Az egyik résztvevő azt kérdezi, hogy miben különbözik a DataTorrent a Stormtól, a Kafkától vagy a Redis infrastruktúrától. Phu, odakint vagy? Hé, Phu, hallasz engem? Talán elnémítom.
Vegyük vissza Ray Wang ebbe. Ray, sokat látott ezekről a technológiákról, és megnézte, hogyan működnek. Nagyon szeretem ezt az irányítást átadni vagy az irányítást átadni az üzemeltetők végfelhasználói számára. Szeretek róluk gondolni, mint egy igazán hatalmas Legos-ra, amelyet felhasználhatnak ezeknek az alkalmazásoknak a felépítésére. Meg tudja kommentálni? Mit gondol erről?
Ray Wang: Tekintettel a műszaki háttérre, azt mondom, hogy félek - féltem szar nélkül! De őszintén szólva azt gondolom, hogy fontos, hogy értem a skálát. Nincs mód arra, hogy csak annyi kérést tegyen fel. Gondolj arra a régi módszerre, amellyel adattárolást végeztünk. Az üzletben jelentést kellett benyújtanom, hogy azok megfeleljenek az összes rendszernek. Úgy értem, nevetséges. Tehát meg kell találnunk a ház üzleti oldalának módját, és határozottan adatcsempészekké kell válnunk. Valójában azt gondoljuk, hogy ezen a világon több digitális művészt és embert fogunk látni, akik rendelkeznek a megfelelő készségekkel, de megértjük, hogyan lehet ezeket az adatokat felhasználni, és hogyan lehet ezeket üzleti értékké alakítani. És így ezeknek a digitális kézműveseknek, az adatkezelőknek - attól függően, hogyan nézel ki erre - valójában szükségük van mind az érdeklődésre, mind a megfelelő kérdéskészletre, hanem a tudásra, hogy tudják, mikor az adatkészlet bűzlik. Ha hamis pozitív vagy hamis negatívot kapok, akkor miért történik ez?
Úgy gondolom, hogy a statisztika alapszintje, az elemzés alapszintje annak megértése, hogy szükség lesz valamilyen képzésre. De nem hiszem, hogy túl nehéz lesz. Azt hiszem, ha megkapja a megfelelő embereket, akiknek képesnek kell lenniük megtörténni. Nem demokratizálhatja a teljes döntéshozatali folyamatot. Látom, hogy ez történik. Ezt sok vállalatban látjuk. Vannak olyan pénzügyi szolgáltatások, amelyeket az ügyfelek tesznek. Néhány kiskereskedelmi ember ezt csinálja, különösen a borotvavékony margókban, amelyeket a kiskereskedelemben lát. Határozottan láttam ezt a csúcstechnikában, itt a völgyben. Csak ilyenek az emberek. Ilyen módon alakul ki, de eltart egy ideig, mert ezek az alapvető adatkészségek még mindig hiányoznak. És azt hiszem, ezt össze kell kombinálnunk azokkal a dolgokkal, amelyeket ezek a srácok csinálnak itt ezen a webinaron.
Eric Kavanagh: Nos, nagyon jó pontot hoz fel. Például, hogy hány vezérlőt szeretne adni az átlagos végfelhasználónak. Nem akarja adni repülőgép pilótafülkét valakinek, aki először vezet autóval. Azt szeretné, hogy képes legyen szorosan ellenőrizni, hogy mi felettük van. Azt hiszem, hogy az izgalmamat az okozza, hogy képesek vagyok maguknak a dolgoknak csinálni, de a legfontosabb az, hogy a megfelelő embert be kell helyezned ebbe a pilótafülkébe. Van valaki, aki igazán tudja, mit csinál. Nem számít, amit hallatsz az eladó közösség tagjaitól, amikor valaki erőteljesebb eszközei rendkívül összetettek, úgy értem, ha a 13, 14, 15 operátorból álló sorozat összeállításáról beszélünk, hogy az adatok egyfajta átalakítását elvégezzük, ott nem sok ember tudná ezt jól megtenni. Azt hiszem, sok-sokkal több embert fogunk elérni, akik ezt jól csinálják, mert az eszközök már ott vannak, és játszhatsz a dolgokkal, és lesz egy lendület ahhoz, hogy tökéletesítsük ezt a folyamatot, vagy legalábbis jó lesz rajta.
Valójában elveszítettük Phu-t, de ő már visszatért a vonalon. Tehát, Phu, az a kérdés az Ön számára, hogy miben különbözik a DataTorrent a Stormtól, a Kafkától vagy a Redistől vagy ezektől?
Phu Hoang: Szerintem ez nagy kérdés. Tehát a Redis természetesen valóban egy memóriában lévő adattár, és csatlakozunk a Redishez. Úgy látjuk, hogy valóban adatfeldolgozó, adatfolyam-feldolgozó motorunk. A Kafka ismét egy nagyszerű busz üzenetküldő busz, amelyet használunk. Valójában ez az egyik kedvenc üzenetküldő buszunk, de valakinek meg kell tennie a nagy adatfeldolgozást több száz csomóponton keresztül, amely hibatűrő, skálázható, és ezt megismétlem, mint az általunk játszott feladatot. Tehát igen, hasonlóak vagyunk a Stormhoz, de azt hiszem, hogy a Stormot már régóta kifejlesztették, még Hadoop előtt, és nincs vállalkozási szintű gondolkodása a skálázhatóságról a több száz és millióra, most pedig akár milliárd eseményre is , és nem rendelkezik valóban azzal a HA képességgel, amelyet szerintem a vállalkozás megkövetel.
Eric Kavanagh: Nagyszerű. És tudod, hogy a HA-ról szólva ezt ürügyként fogom felhasználni, hogy visszahozjam Robin Bloort a beszélgetésbe. Csak tegnap beszéltünk erről. Mit ért a magas rendelkezésre állás? Mit ért a hibatűrés alatt? Mit ért például a valós időben? Ezek olyan kifejezések, amelyeket meg lehet hajlítani. Mindig ezt látjuk a vállalati technológia világában. Jó kifejezés, ha más emberek valamilyen fényt vetnek rá, használnak, együtt választanak és mozognak, majd a dolgok hirtelen nem egészen azt jelentik, amit régen. Tudod, Robin, az egyik kisállatom a VOIP egész világegyeteme. Olyan ez, mint "Miért csökkentenénk a minőséget? Nem fontos megérteni, amit az emberek mondanak neked, és miért számít?" De csak azt kérném, hogy írjon meg véleményt erről. Még mindig nevetek Ray megjegyzéséért, hogy fél valami szégyentől, hogy ezeket az embereket megadja. Mit gondolsz arról?
Ray Wang: Ó, szerintem ez egy Pók-ember probléma, nemde? Nagy hatalommal jár a nagy felelősség. Te tényleg, a rendelkezésre álló képességek szempontjából, úgy értem, hogy régen tényleg megváltoztatott. Tudod, adnék az informatikusoknak néhány olyan képességet, amelyeket most megszereztek. Rendkívüli mennyiségű munkát végeztünk azzal, amit azt mondanám, hogy egy nagyszerű munka, amit a gépek jelenleg végeznek, és ezzel párhuzamosan. Olyan dolgokat csinálnak, amelyeket soha nem tudtunk volna elképzelni. Úgy értem, hogy matematikailag megértettük volna, de soha nem tudtuk volna elképzelni, hogy ezt megtesszük. Vannak olyan emberek, akik megértik az adatokat, és Ray-nek teljesen igaza van ebben. A félelmet az az oka, hogy az emberek valójában rossz következtetéseket fognak levonni, hogy belekapaszkodnak az adatokba, és rendkívül erőteljesen alkalmaznak valamit, és úgy tűnik, hogy valamit javasolnak, és azt fogják hinni, anélkül, hogy valójában bármire képesek is volna egyszerű, mintha valaki ellenőrzést végez arról, hogy eredményük valóban érvényes eredmény-e. Mindig ezt tettem a biztosítótársaságban, ahol dolgoztam. Ha valaki munkát végzett, valaki mindig ellenőrzi. Legalább egy ember mindent ellenőrzött annak ellenére, aki megtette. Ezekben a környezetekben a szoftver rendkívül erős, de a megfelelő használathoz meg kell felelnie a tudománynak. Egyébként lefekvés előtt könny lesz, nem lesz?
Eric Kavanagh: Szeretem ezt az idézetet, ami fantasztikus. Hadd lássam. Megyek és megragadok csak erre a csúszdára a GridGainból felfelé, beszélhetnék, Nikita, amikor jössz játszani, hogy valójában hogyan töltheted fel ezeket az alkalmazásokat? Úgy értem, megértem, mit csinálsz, de hogyan néz ki ez a folyamat, hogy valójában beágyazódjon, befonódjon és mindezeket a dolgokat futtassa?
Nikita Ivanov: Nos, a folyamat viszonylag egyszerű. Alapvetően csak telepítenie kell a GridGain programot, és végre kell hajtania egy apró konfigurációs változtatást, csak hogy tudassa a Hadoop-lal, hogy van a HDFS, ha használni szeretné a HDFS-t, és be kell állítania, hogy melyik módon kívánja használni. Egyébként megszerezheti a BigTop-tól. Valószínűleg a legegyszerűbb módja annak telepítéséhez, ha a Hadoopot használja. Erről szól. Az új verziók megjelenésével, kissé, körülbelül néhány hét múlva, május végéig, még egyszerűsített eljárást fogunk készíteni erre. Tehát a memóriában lévő Hadoop gyorsító lényege, hogy ne kódolja. Ne változtasson a kódján. Csak annyit kell tennie, hogy telepítenie kell, és elegendő RAM van a fürtben, és ki is kell mennie, tehát a folyamat nagyon egyszerű.
Eric Kavanagh: Hadd hozjam vissza John Santaferraro-t. Itt még néhány kérdést felveszünk. Tudod, John, srácok, természetesen különféle szempontból figyeltünk téged. Ön a PEAR Excel programban volt; amit az Actianbe összeraktak. Természetesen az Actianust korábban Ingres-nek hívták, és ti srácok tettél még néhány más akvizíciót. Hogyan varrja össze ezeket a dolgokat? Tudom, hogy nem akarja, hogy ezzel túl technikailag bánjon, de srácok, nagyon sok dolgod van. Megvan a Data Rush. Nem vagyok biztos benne, hogy ez még mindig ugyanazon a néven - de van egy csomó különböző termék, amelyeket összefontak, hogy létrehozzák ezt a platformot. Beszélj arról, hogy mi folyik ott, és hogy ez mekkora.
John Santaferraro: A jó hír, Eric, hogy külön-külön azokban a vállalatokban, amelyeket megvásárolunk a Pervasive-ben, a PEAR Excel-ben, és még akkor is, amikor az Actian fejlesztették ki, mindenki nagyon hasonló architektúrával fejlesztette ki termékét. Elsőként nyitottak voltak az adatokkal és más platformokkal való kölcsönhatásban. A második, mindent párhuzamosítva hajtott környezetben futottak. Harmadik szám: minden rendkívül optimalizált volt. Ez lehetővé tette az integrációs pontok gyors létrehozását, hogy már ma létrehozhassa ezeket az adatfolyamokat. Megalapítottuk az integrációt, tehát Ön hozza létre az adatfolyamokat. Az adatok keverését és gazdagítását közvetlenül a Hadoop-on végez, minden párhuzamos, minden optimalizált. Ha akarod, ezt áthelyezik nagy teljesítményű motorjainkba. Ezután már van egy nagy teljesítményű kapcsolat a Hadoop és a nagymértékben párhuzamos elemző motorunk között, amely ezeket a szuper-alacsony késésű dolgokat elvégzi, például segít a banknak minden második percben újra kiszámolni és átdolgozni teljes kockázati portfóliójukat, és ezt a valósidejű kereskedési rendszerünkbe adagolni. vagy betáplálhat valamilyen asztalra a vagyonkezelő számára, hogy így reagáljanak a bank legértékesebb ügyfeleire.
Már összeraktuk ezeket a darabokat. További integrációra van szükség. De ma az Actian Analytics platformot kínáljuk, mivel az integráció nagy része kész volt. Ez már befejeződött, tehát összekapcsoljuk ezeket a darabokat, hogy az egész analitikai értékláncot az adatok összekapcsolásától, az összes feldolgozástól, az általunk futtatni kívánt bármilyen elemzéstől megkapjuk, majd felhasználjuk táplálja be ezeket az automatizált üzleti folyamatokat, hogy valóban javítsa ezt a tevékenységet az idő múlásával. Az egész arról szól, hogy ma már létezik a teljes platform, amely már létezik.
Eric Kavanagh: Ez nagyon jó dolog. És azt hiszem, Jim, visszahozok még egy pár megjegyzést, és Robin, csak egy nagy kérdéshez szeretnék felhívni téged, gondolom. Emberek, megtartjuk ezeket a kérdéseket - továbbadjuk azokat az embereknek, akik ma részt vettek a rendezvényen. Ha valaha úgy érzi, hogy a feltett kérdésre nem válaszoltak, akkor nyugodtan bátran reagálhat a sajátodra. Van valamilyen információm rólam, és arról, hogyan lehet megszeretni tőlem. Ezenkívül most feltettem egy linket a teljes pakliba a nem szponzoráló gyártók diáival. Tehát minden eladónak közöljük a szót az egész Hadoop térben. Azt mondtuk: "Mondja el nekünk, mi a történetetek; mondja el nekünk, hogy mi folyik." Ez egy hatalmas fájl. Kb. 40 plusz megabájt.
De Jim, hadd hozjam vissza önöket, és csak egyfajta beszélgetésről - ismét imádom ezt a koncepciót -, ahol a medence partáról beszélünk, amely véget ér. Beszélne arról, hogy van-e képességed felfüggeszteni a tetejét a nyílt forráskódú közösségben zajló eseményekkel kapcsolatban? Mert ez egy nagyon gyorsan változó környezet. De azt hiszem, srácok, nagyon okos stratégiájukkal szolgálnak egy ilyen vállalkozás-edző gyártó kiszolgálására, amely a tetején vagy körülötte ül. Tudsz beszélni a fejlesztési ciklusokról és arról, hogy miként tudsz felfüggeszteni az eseményeket?
Jim Vogt: Persze. Nagyon gyorsan mozog, ha csak egy pillanatkép-frissítést nézünk meg, de a funkcionális szempontból ma szállítunk, ez kb. Egy-másfél évvel magasabb, mint amit ma a biztonsági képességekkel kibővíthetünk a közösség számára. . Nem úgy, hogy nem fognak odajutni; csak időbe telik. Ez egy másik folyamat, van közreműködői és így tovább, és csak időbe telik. Amikor egy ügyfélhez megyünk, nagyon jól meg kell ismernünk a nyílt forráskódot, és nagyon jól kell tudnunk főként az általunk hozott biztonsági dolgokat. Annak érdekében, hogy valójában szabadalmakat állítsunk ki és nyújtsunk be szabadalmakat, az, hogy ezen szellemi tulajdonban, a szellemi tulajdonban van valami valódi érték ezen nyílt forrású komponensek megszilárdítása körül. Amikor támogatunk egy ügyfelet, az összes változó nyílt forrású összetevőt és minden változó disztribúciót támogatnunk kell, ahogy mi történik, és rendelkeznünk kell a speciális funkciók ismereteivel, amelyeket a nyílt forráskódhoz adunk hozzá a az általunk létrehozott megoldás. Cégként, bár nem akarjuk, hogy az ügyfél Hadoop szakértő legyen, nem gondoljuk, hogy szerelőnek kell lennie az autó vezetéséhez. Szerelőnek kell lennünk, aki megérti az autó és annak működését, valamint megérti, mi történik a kódunk és a nyílt forráskód között.
Eric Kavanagh: Nagyszerű. Phu, felteszek egy utolsó kérdést. Akkor Robin, van egy kérdésem az ön számára, majd összefoglaljuk, emberek. Archiváljuk ezt a webes adást. Ahogy javasoltam, fel fogunk lépni a insideanalysis.com webhelyen. Mi is megyünk előre, és készen állunk néhány dolgot a Techopedia-ra. Nagy köszönet azoknak, akik kapcsolatba léptek velünk a hűvös új sorozat elkészítésében.
De Phu ... Emlékszem, hogy néztem a dolgok bemutatóját, és őszintén meghökkenttem, amit csináltál. Meg tudja magyarázni, hogyan érheti el a feladatátvétel nélküli szintet?
Phu Hoang: Persze, szerintem ez nagy kérdés. Valójában a probléma három összetevőből állt. Az első számú: nem veszítheti el azokat az eseményeket, amelyek a Hadoop-fürtben az operátortól a operátorig mozognak. Tehát szükségünk van esemény-pufferelésre. De még ennél is fontosabb, hogy az operátorokon belül lehet olyan állapotokat, amelyeket számít. Tegyük fel, hogy valóban számít pénzre. Van benne egy részösszeg, tehát ha ez a csomópont leesik, és a memóriában van, akkor ez a szám eltűnik, és nem indíthat egy pontból. Honnan kezdnéd?
Tehát ma valójában rendszeresen ellenőriznie kell az operátor állapotát ehhez. Ezt az intervallumot megadja úgy, hogy ne váljon nagy fejpénzzé, de amikor egy csomópont leesik, visszatérhet, és képes visszatérni pontosan a megfelelő állapotba, ahol utoljára ellenőrzött, és képes behozni az eseményeket az állam. Ez lehetővé teszi, hogy folytathassa úgy, mintha az esemény valójában még soha nem történt volna meg. Természetesen az utolsó annak ellenőrzése, hogy az alkalmazáskezelő hibatűrő-e is, hogy ez ne essen le. Tehát mindhárom tényezőnek helyben kell lennie, hogy elmondhassa, hogy teljesen hibatűrő.
Eric Kavanagh: Igen, ez remek. Hadd menjek és dobjak egy utolsó kérdést Robin Bloornak. Tehát az egyik résztvevő azt kérdezi, gondolja-e valaki, hogy a Hortonworks vagy egy másik olyan nagy játékos, mint például az Intel, bemerít és beruház? Nem hiszem, hogy ebben kétséges lenne. Nem vagyok lepve, de azt gondolom, hogy lenyűgözött, hogy az Intel beugrott korábban, mint egy IBM vagy Oracle, de azt hiszem, talán az IBM és az Oracle srácai azt gondolják, hogy máris csak a közös opcióval fedezték fel. mi jön ki a nyílt forrású mozgalomból. Mit gondolsz arról?
Robin Bloor: Nagyon kíváncsi lépés. Figyelembe kell venni azt a tényt, hogy az Intelnek már volt saját Hadoop disztribúciója, és amit ténylegesen megtett, ezt csak átadta a Cloudera-nak.Az iparágban sok olyan hatalom létezik, mint az Intel, és nehéz tudni, hogy mi az üzleti modell valójában, ha van Hadoop disztribúciója, mert nehéz pontosan tudni, hogy mire fogják használni a jövőben. Más szavakkal, nem tudjuk, honnan származnak szükségszerűen a bevételi források.
Valakivel, mint például az Intel, csak nagyon sok folyamatot akarnak megoldani. Minél inkább támogatni fogják fő üzleti tervüket, ahogyan a Hadoop-ot használják. Nagyon könnyű egyszerűsített magyarázatot adni arról, hogy mire készül az Intel. Nem olyan könnyű kitalálni, hogy mit tehetnek a kód chipekbe helyezése szempontjából. Nem vagyok 100% -ban biztos abban, hogy meg fogják-e csinálni. Úgy értem, nagyon nehéz dolog ezt hívni. Úgy gondolom, hogy a hardver szintjén következő lépésük a chip-rendszer. Amikor egy chipen megyünk a rendszerbe, akkor valószínűleg érdemes néhány alapszoftvert feltenni a chipre, hogy úgy mondjam. Tehát odahelyezzük a HDFS-t; ennek lehet értelme. De nem hiszem, hogy erről szól ez a pénzbefektetés. Azt hiszem, hogy ez a pénzbefektetés csak arra irányult, hogy megbizonyosodjon arról, hogy az Intelnek van kéz a játékban, és valóban tovább halad.
Ami még vásárolni fog, ezt szintén nehéz megmondani. Úgy értem, minden bizonnyal a világ SAP-jainak és oraklusainak elegendő pénzük van ahhoz, hogy belevásároljanak, vagy az IBM-nek elegendő pénze van ahhoz, hogy belevásároljon. De tudod, ez mind nyílt forráskódú. Az IBM soha nem vásárolt Linux disztribúciót, annak ellenére, hogy sok pénzt szántottak a Linuxra. Nem törte meg a szívüket, hogy valójában nem volt Linux disztribúciójuk. Nagyon örülnek, hogy együttműködnek a Red Hat-tal. Azt mondanám, hogy talán a Red Hat megvásárolja e disztribúciók egyikét, mert tudják, hogyan kell működésbe hozni ezt az üzleti modellt, de nehéz megmondani.
Eric Kavanagh: Igen, nagyszerű pont. Tehát emberek, megyek előre, csak utoljára itt osztom meg az asztalomat, és mutatok meg néhány dolgot. Tehát az esemény után nézd meg a Techopedia alkalmazást - ezt láthatja a bal oldalon. Ez egy olyan történet, amelyet igazán írtál, azt hiszem, néhány hónappal ezelőtt vagy másfél hónappal ezelőtt. Nagyon sokféle tapasztalatból származik, amikor különféle beszállítókkal beszélgettünk, és megpróbáltunk belemerülni ahhoz, hogy megértsük, mi történik pontosan az űrben, mert néha nehéz lehet navigálni a zümmögő szavak és a hype között. és a terminológiát és így tovább.
Szintén nagyon nagy köszönet mindazoknak, akik Twitterezték. Volt egy fasz egy Tweet folyam itt. Szóval, köszönöm mindenkinek. Látja, hogy csak folytatódik és folytatódik. Sok nagyszerű Tweet ma a TechWise-n.
Ez az első új sorozatunk, az emberek. Nagyon köszönjük a hangolást. Hamarosan értesítjük, mi folyik a következő sorozatban. Azt hiszem, valószínűleg valamikor júniusban fogunk az elemzésre összpontosítani. És az emberek ezzel vélekedve azt gondolom, hogy tovább fogunk zárni az eseményünket. Holnap elküldjük a linket a mai diákra, és meglátogatjuk azt a teljes fedélzetet is, amely egy hatalmas fedélzet. Körülbelül húsz különböző gyártónk van a Hadoop történetükkel. Valóban megpróbálunk önnek egyfajta tartalom-összefoglalót adni egy adott téma körül. Tehát a lefekvés előtt történő olvasáshoz vagy bármikor, ha érdekli, elmerülhet, és megpróbálhatja megszerezni ezt a stratégiai képet arról, hogy mi folyik itt az iparban.
Ezzel búcsút fogunk adni neked, emberek. Ismét nagyon köszönöm. Látogasson el a insideanalysis.com és a Techopedia oldalra, és a jövőben mindent megtudjon erről, és legközelebb vegye fel velünk a kapcsolatot. Viszlát.