A Techopedia munkatársai, 2016. február 24
Elvihető: Rebecca Jozwiak a host elemzi az streaming analitikát az iparág legjobb szakértőivel.
Jelenleg nincs bejelentkezve. Kérjük, jelentkezzen be vagy jelentkezzen be a videó megtekintéséhez.
Rebecca Jozwiak: Hölgyeim és uraim, üdvözlet és üdvözlet a 2016-os Hot Technologies oldalán! A mai cím: „A Firehose kihasználása: Üzleti érték megszerzése a Streaming Analytics segítségével.” Ez Rebecca Jozwiak. Én vagyok a második parancs a webcast-házigazda számára, amikor kedves Eric Kavanagh nem lehet itt, tehát örülök, hogy ma nagyon sokan vannak itt.
Ez az epizód kissé különbözik a többiektől. Valahogy beszéltünk arról, hogy meleg van, és természetesen ez az év forró. Az elmúlt néhány év forró volt. Mindig új dolgok jelennek meg. Ma az analitikai adatfolyamról beszélünk. Az analitikai streaming maga is újfajta. Természetesen a streaming, a központi adatok, az RFID-adatok, ezek nem feltétlenül újak. De az adat-architektúrák kapcsán évtizedek óta annyira koncentrálunk a nyugalomban lévő adatokra. Adatbázisok, fájlrendszerek, adattárak - mindezt elsősorban kötegelt feldolgozás céljából. De most, amikor átalakítunk értéket az adatfolyamból, az érzelmekből, néhányan élő streamnek hívják őket, ténylegesen stream-alapú architektúrát igényelnek, nem pedig azokat a nyugalmi architektúrák adatait, amelyekhez már megszoktuk és amelyeknek képeseknek kell lenniük gyors bevitel, valós idejű vagy valósidejű feldolgozás kezelése. Nemcsak a tárgyak internetét, hanem a mindent internetet is képes kiszolgálni.
Természetesen, ideális esetben, jó lenne, ha a két építészet egymás mellett élne, úgymond az egyik kezük mosogatná a másikat. Noha a napi, hetek és éves adatoknak természetesen még mindig van értéke, történelmi elemzés, trend elemzés, manapság az élő adatok mozgatják az élő intelligenciát, és ezért a streaming analitika olyan fontos lett.
Ma erről többet beszélek. Van adat tudósunk, Dez Blanchfield, Ausztráliából. Jelenleg kora reggel van. Van fő elemzőnk, Dr. Robin Bloor. Csatlakozunk Anand Venugopalhoz, az Impetus Technologies StreamAnalytix termékvezetőjéhez. Valóban e terület streaming analitikai aspektusára összpontosítanak.
Ezzel megyek előre, és átadom Deznek.
Dez Blanchfield: Köszönöm. Itt kell megragadnom a képernyő irányítását, és fel kell lépnem.
Rebecca Jozwiak: Itt van.
Dez Blanchfield: Amíg felfelé megragadjuk a diákat, hadd fedjek le csak az alapvető témát.
Meglehetősen magas szinten tartom, és kb. 10 percig tartom. Ez egy nagyon nagy téma. Vettem részt egy olyan rendezvényen, ahol két-három napot töltöttünk azzal, hogy részletesebben belemerüljünk az adatfolyam-feldolgozásba, a jelenlegi keretrendszerbe, amelyet fejlesztünk, és mit jelent az elemzés ezen nagy mennyiségű adatfolyamokban.
Csak tisztázni fogjuk, hogy mit értünk az analitikai streaming elemzésével, majd megvizsgáljuk, levezethető-e az üzleti érték, mert ez az, amit a vállalkozások keresnek. Azt akarják, hogy a nép nagyon gyorsan és tömör módon magyarázza meg nekik. Hol lehet származtatni az értéket, ha valamilyen elemzési módszert alkalmazunk adatfolyamunkra?
Mi az a streaming analitika?
Az analitikai streaming lehetővé teszi a szervezetek számára, hogy nyerjék az értékeket a nagy mennyiségű és nagy sebességű adatokból, amelyeket az üzleti élet során különféle formában hajtanak végre. A lényeges különbség az, hogy régóta fejlesztettünk elemzést és objektívet, valamint olyan nézeteket, amelyeket nyugalomban dolgoztunk fel évtizedek óta a mainframe feltalálása óta. A hatalmas paradigmaváltás, amelyet az elmúlt három-öt évben láthattunk úgynevezett „webes méret” -nek, az érinti az adatfolyamokat, amelyek valós időben vagy közel valós időben érkeznek bennünk, és nem csupán az események korrelációjának feldolgozása és keresése. eseményindítók, de igazán részletes, mélyreható elemzést végeznek ezeken a patakokon. Jelentős elmozdulás annak, amit korábban végeztünk, vagyis az adatok gyűjtése, valamilyen tárolóba helyezése, hagyományosan nagy adatbázisokba helyezése, nagy, nagy adatkeretek, mint például a Hadoop platform, és batch-mode feldolgozása ezen, és valamilyen betekintést.
Nagyon jól tudjuk ezt gyorsan elvégezni, és sok nehéz vasat kipróbálni a dolgoknál, de még mindig tényleg adatokat gyűjtünk, tárolunk, majd megnézünk, és valamilyen betekintést vagy elemzést szerezünk rajta. Az elemzés elvégzése az adatok beáramlásakor nagyon új és izgalmas növekedési terület volt a nagy adatok körül zajló dolgok típusai számára. Teljesen más megközelítést igényel az elemzés egyszerű rögzítéséhez, tárolásához, feldolgozásához és elvégzéséhez.
Az elemzés elvégzésében és az elemzés folytatásában fókuszálás egyik fő mozgatórugója az, hogy jelentős üzleti értéket szerezhet, ha ezeket a betekintést gyorsabban és könnyebben megszerzi, amikor az adatok megérkeznek, mivel az információkat a vállalkozás rendelkezésére bocsátják. Bizonyos iparágakban a nap végén történő feldolgozás elképzelése már nem releváns. Azt akarjuk, hogy az elemzést menet közben is elvégezzük. A nap végére már tudjuk, mi történt, ahogy történt, ahelyett, hogy a nap végére érnénk, 24 órás kötegelt munkát végeznénk, és megismernénk ezeket a betekintéseket.
A streaming analitika lényege, hogy közvetlenül rákapcsol az adott adatfolyamra, míg az adatfolyamok általában nagyon sok adatmennyiségű több adatfolyam, és az adatok nagyon-nagyon gyorsan mozognak ránk, és betekintést vagy elemzést szereznek ezekben a patakokban, amikor hozzánk jönnek, szemben hogy megengedjük, hogy ez nyugalomban jöjjön ki, és elemzéseket végezzünk rájuk.
Mint már említettem, évtizedek és évtizedek óta végezzük úgynevezett kötegelt elemzést. Nagyon jó képet írtam ide. Ez egy olyan kép, amelyben egy úriember áll ki egy kigúnyolt számítógép előtt, amelyet a RAND Corporation készített egy életen át, és így néztek ki egy házban lévő számítógépre. Érdekes, hogy még akkor is megvolt a koncepció ezekre a kis tárcsákra, és ezek a tárcsák a házból érkező információkat valós időben dolgozták fel és elmondták, mi folyik itt. Egy egyszerű példa a légköri nyomás és hőmérséklet sorozata, amelyből láthatjuk, hol látjuk, mi történik valós időben. De azt hiszem, még akkor is, amikor a RAND Corporation összeállította ezt a kis makettot, valójában már az adatok feldolgozására gondoltak, és elemzéseket végeztek rajtuk, mivel adatfolyam formátumban érkeznek. Nem vagyok egészen biztos benne, miért tettek kormányt a számítógépre, de ez nagyon jó.
A nyomtató feltalálása óta célunk volt az adatok rögzítése és kötegelt elemzések elvégzése rajta. Mint már említettem a nagy váltással, és láthattuk ezt a webes szereplők kedvelőinek, akiket mindannyian ismerünk, mind háztartási márkák, mint például a Twitter, a Facebook és a LinkedIn, ez az interaktív viselkedés, mint mi azokkal a szociális partnerekkel A platformok megkövetelik nemcsak a rögzítést, tárolást és azután feldolgozást kötegelt módban, hanem ténylegesen elfogják és vezérlik az elemzést menet közben az átáramló adatfolyamokból. Amikor elküldöm valamit, akkor nemcsak el kell készítenie, tárolnia és meg kell tennie valamit később, hanem nekik is képesnek kell lenniük arra, hogy azonnal visszakerítsék a patakra, és megosszák más emberekkel, akik követnek. Ez egy kötegelt feldolgozási modell.
Miért mennénk ezen az úton? Miért fektetnének a szervezetek idejét, erőfeszítéseit és pénzét azáltal, hogy még figyelembe veszik a patak-elemzés útján való próbálkozás kihívását? A szervezeteknek ez a hatalmas vágyak vannak arra, hogy teljesítmény-nyereséget szerezzenek versenytársaik felett azokban az iparágakban, ahol működnek, és hogy a teljesítménynövekedés gyorsan megvalósítható egyszerű stream-elemzéssel, és elindulhat egy egyszerű, valós idejű adatok nyomon követésével, amelyet már vagyunk jártas. Van egy kis képernyőképem a Google Analyticsről. Ez valószínűleg az egyik első alkalom, amikor valóban megkaptuk a gyakorlati fogyasztói szintű elemzést. Tehát amikor az emberek meglátogatták az Ön weboldalát, és így megkapták a találatokat, weboldalának alján egy apró JavaScript darabmal HTML-beágyazva, ezek a kis kódok valós időben készültek vissza a Google felé, és ők elemzést végez azokon az adatfolyamokon, amelyek a webhely minden oldaláról, a webhely minden objektumáról valós időben elérhetők, és visszajuttatják neked ezt a nagyon aranyos kis weboldalt egy valós idejű grafikon, aranyos kis hisztogramok és vonaldiagram, amely megmutatja az X számát, akik történelmileg elérték az oldalt, de itt van hányan vannak jelenleg.
Mint látható a képernyőképen, ez most 25-et mond. A képernyőképezés idején jelenleg 25 ember volt azon az oldalon. Ez az első valódi esély, amelyet a fogyasztói szintű elemző eszközön játszottunk. Azt hiszem, sok ember valóban megkapta. Csak megértették, hogy mennyire tudják, mi folyik, és hogyan tudnak reagálni erre. Ha gondoljuk az avionics léptékére, a repülőgépek repülésére, csak napi 18 700 belföldi járat van az USA-ban. Elolvastam egy papírt - körülbelül hat vagy hét évvel ezelőtt -, hogy ezeknek a repülőgépeknek a régi műszaki modellben körülbelül 200-300 megabájtnyi adatát állították elő. A mai repülőgép-tervekben ezek a repülőgépek repülésenként körülbelül 500 gigabájt vagy körülbelül fél terabyte adatot hoznak létre.
Ha nagyon gyorsan elvégzi a matematikát, akkor az a 18 700 belföldi járat 24 óránként csak az Egyesült Államok légterében, ha az összes modern repülőgép körülbelül fél terabájtot termel, ez 43-44 petatates adat jön át, és akkor történik, amíg a repülőgépek a levegőben vannak. Ez akkor történik, amikor leszállnak, és adatcsempét végeznek. Ekkor mennek be a boltba, és teljes adatcsomagot kapnak a mérnöki csapatoktól, hogy megnézzék, mi történik a csapágyakban, kerekekben és a motorok belsejében. Ezen adatok egy részét valós időben kell feldolgozni, hogy döntéseket hozhassanak arról, hogy van-e valódi probléma, amikor a repülőgép a levegőben volt, vagy miközben a földön volt. Ezt csak nem lehet megtenni kötegelt módban. Más iparágakban, amelyeket a pénzügy, az egészségügy, a gyártás és a mérnöki munka körében látunk, azt is megvizsgálják, hogyan juthatnak el az új betekintéssel a valós időben zajló eseményekhez, szemben azzal, amit csak az adatbázisokban tárolnak egy távon.
Ez az elképzelés az adatkezelésről is szól, amit romlandó áruknak vagy romlandó árucikknek hívok - hogy sok adat idővel elveszíti értékét. Ez egyre inkább igaz a mobilitási alkalmazásokra és a közösségi média eszközökre, mert az, amit az emberek mondanak, és most mi a trend, az, amit meg akar válaszolni. Amikor életünk más részeire gondolunk, a logisztikával és az élelmiszerek szállításával, megértjük a romlandó áru fogalmát ebben az értelemben. De gondolkozzon azokra az adatokra, amelyek a szervezeten megy keresztül, és az értékére. Ha valaki jelenleg üzleti tevékenységet folytat veled, és valós időben kapcsolatba léphet velük, akkor nem akarja várni egy órát, hogy az adatokat rögzíteni lehessen, és el lehessen helyezni egy olyan rendszerbe, mint a Hadoop, majd nyomja meg ezt a gombot, jelenleg nem fogja megbirkózni vele, és azt akarja, hogy azonnal meg tudja csinálni. Van egy kifejezés, amelyet sokan felbukkannak, amikor az emberek arról beszélnek, hogy van egy ilyen valós idejű adatfolyam, amely személyre szabást nyújthat, és ez a testreszabás a használt rendszerben az egyéni élményhez igazodik. Tehát amikor megérinti egy olyan eszközt, mint például a Google Kereső eszköz, ha lekérdezést teszek, és ugyanazt a lekérdezést végzem, akkor mindig nem ugyanazokat az adatokat kapjuk. Lényegében azt kapjuk, amit híresség-élménynek nevezek. Egyszeri bánásmódban részesülnek. A személyes verziómat kapom arról, hogy mi történik ezekben a rendszerekben, a profilom és az adatok alapján, amelyeket rám gyűjtöttek, és valós időben képesek voltam elemzésre a patakban.
Az az elképzelés, hogy az adatok romlandó árucikké válnak, manapság valódi dolog, és az adatok értéke az idő múlásával csökken, és ezzel ma kell foglalkoznunk. Ez nem egy tegnapi dolog. Szeretem ezt a képet, amikor egy medve megragad egy lazacot, amely kiugrott a folyóból, mert valóban pontosan azt festi, amit streaming analitika szerint látok. Ez a hatalmas adatfolyam érkezik hozzánk, egy tűzoltó tömlő, ha akarsz, és a medve a patak közepén ül. Valós idejű elemzést fog végezni a körülötte zajló eseményekről, hogy valóban megtervezhesse annak képességét, hogy elfogja ezt a halat a levegőben. Ez nem olyan, mintha csak belemerülne a patakba és megragadná azt. Ez a dolog ugrik a levegőbe, és a megfelelő fogásnak megfelelő időben kell lennie, hogy elkapja ezt a halat. Egyébként nem kap reggelit vagy ebédet.
Egy szervezet ugyanazt akarja tenni az adatokkal. Értéket akarnak kihozni a jelenleg folyamatban lévő óriási adatmennyiségből. Ezeket az adatokat és a nagy sebességű adatokat elemzni akarják, tehát nem csak az adatok mennyisége érkezik hozzánk, hanem az, hogy milyen gyorsan érkeznek ezek. Például a biztonság szempontjából: az összes útválasztó, kapcsoló, szerver, tűzfal és az összes esemény ezekből származik, és több tízezer, ha nem több százezer eszközről származik, bizonyos esetekben romlandó adatok. Amikor a tárgyak internetében és az ipari interneten gondolkodunk, végül több millió, ha nem akár milliárd szenzorról beszélünk, és mivel az adatok jönnek keresztül, amelyek elemzést végeznek, most összetett események feldolgozására gondolunk olyan nagyságrendű és sebességű sebességgel, amelyet még soha nem látottunk, és ezzel ma kell foglalkoznunk. Építsünk eszközöket és rendszereket ennek körül. Valódi kihívás ez a szervezetek számára, mivel egyrészről megvannak a nagyon nagy márkák, amelyek DIY-t készítenek, sütik magukat, amikor képesek erre, készségkészletre és a mérnöki készítésre. De az átlagos szervezetnél ez nem ez a helyzet. Nincsenek képességeik. Nincs elég képességük, idejük vagy pénzük, hogy befektessenek a kitalálásához. Mindannyian a közel-valós idejű döntéshozatal ezen koncepciójára törekednek.
Használjon olyan eseteket, amelyekkel találkoztam, és az ágazat minden széles spektrumán megtalálható, amelyet el lehet képzelni. Az emberek ülnek és figyelnek, és azt mondják: hogyan alkalmazhatunk némi elemzést adatfolyamunkra? Web-szintű online szolgáltatásokról beszélünk. Vannak a hagyományos közösségi médiaplatformok, valamint az online e-farok és kiskereskedelem - például alkalmazások. Mindannyian megpróbálják adni nekünk ezt a valós idejű híresség-élményt. De amikor beleszámolunk a technológiai verem szolgáltatásokba, a telefonszolgáltatásokba, a hang- és videofelvételekbe, látom, hogy az emberek sétálnak a FaceTime telefonon. Csak felrobban. Megdöbbentő az a gondolatom, hogy az emberek a maguk előtt tartják a telefont, és egy barátjának video streamével beszélnek, szemben a fülükhöz tartással. De tudják, hogy meg tudják csinálni, és alkalmazkodtak, és tetszett nekik ez a tapasztalat. Ezeknek az alkalmazásoknak a fejlesztésével és az azokat szolgáltató platformokkal valós idejű elemzéseket kell végezni az adott forgalomra és a forgalom profiljaira, hogy egyszerű műveleteket végezzenek, mint például a videó tökéletes irányítása, hogy a hangminőség a A videód, amelyet kapsz, megfelelő a jó élmény eléréséhez. Az ilyen típusú adatokat nem lehet feldolgozni. Ez nem tenné a valós idejű videofolyam funkcionális szolgáltatássá.
A pénzügyi tranzakciók irányítási kihívást jelentenek. Nem jó, ha a nap végére érkezünk, és kiderül, hogy megsértette a törvényt, amellyel a személyes adatokat a hely körül mozgatja. Ausztráliában nagyon érdekes kihívásunk van, ahol a magánélettel kapcsolatos adatok tengeri áthelyezése nem-nem. Nem veheti át PID-én, személyes személyes azonosító adataimat, offshore-ban. Ausztráliában vannak törvények, amelyek megakadályozzák ezt. Különösen a pénzügyi szolgáltatóknak, a kormányzati szolgálatoknak és az ügynökségeknek, valós idejű elemzéseket kell végezniük az adatfolyamukon és az utasításokon velem, hogy megbizonyosodjanak arról, hogy amit nekem nyújtanak, nem hagyják el a partot. Minden cuccnak helyben kell maradnia. Valós időben kell csinálniuk. Nem tudják megsérteni a törvényt, és később megbocsátást kérhetnek. Csalások észlelése - ez elég nyilvánvaló, amiről hallunk a hitelkártya-tranzakciók során. Mivel azonban a pénzügyi szolgáltatásokban végrehajtott tranzakciók típusai nagyon, nagyon gyorsan változnak, vannak olyan dolgok, amelyeket a PayPal először hajt végre a csalások valós időben történő felismerésekor, amikor a pénz nem mozog egyik dologról a másikra, hanem a rendszerek közötti pénzügyi tranzakció. Az Ebay licitálási platformokat, a csalások felderítését valós időben, streaming irodában kell elvégezni.
Van egy tendencia, hogy a kitermelés végrehajtása és a terhelési tevékenység átalakítása a patakokban, így nem akarunk elfogni semmit, ami a patakba megy. Nem igazán tudjuk megtenni. Az emberek megtanultak, hogy az adatok nagyon gyorsan megsemmisülnek, ha mindent elfogunk. A trükk az, hogy elemzéseket végez ezeken a patakokon, elvégzi az ETL-t, és csak elfogja a szükséges információt, esetleg a metaadatokat, majd eljuttatja a prediktív elemzéseket, ahol valójában meg tudjuk mondani, mi fog történni egy kicsit tovább az útvonalakon, amit Most láttam a patakban az általunk elvégzett elemzés alapján.
Az energiaellátó és közműszolgáltatók a fogyasztók óriási vágyát tapasztalják meg, hogy kereslet-alapú árakat szabjanak. Lehet, hogy úgy dönt, hogy a zöld energiát szeretném megvásárolni a nap egy adott időpontjában, mert csak egyedül vagyok otthon, és nem használok sok eszközt. De ha vacsorázom, akkor szeretném, ha bekapcsolnám az összes eszközemet, és nem akarom olcsó energiát vásárolni, és várni kell annak kézbesítésére, de hajlandó vagyok fizetni több költségért, hogy megkapjam ezt az energiát. Ez a keresleti árképzés, különösen a közművek és az energiaterület területén, már megtörtént. Például az Uber egy klasszikus példa a teendőkre, amelyeket minden nap megtehet. Van néhány klasszikus példa arra, hogy az ausztráliai emberek 10 000 dollár viteldíjat kapnak a szilveszteri esti hatalmas kereslet miatt. Biztos vagyok benne, hogy foglalkoztak ezzel a kérdéssel, de az elemzés valós időben zajlik, miközben az autóban megmondja, hogy mennyit kell fizetnem.
A tárgyak internete és az érzékelő-patakok - csak most felkarcoltuk a felületet, és valójában csak az alapvető beszélgetés zajlott erről, de érdekes változást fogunk látni abban, hogy a technológia hogyan kezeli ezt, mert ha nem csak körülbelül ezrek vagy tízezrek, de százezrek és potenciálisan több milliárd eszköz áramlik az Ön felé, a mostani technológiai halom szinte sem azért van megtervezve, hogy ezzel megbirkózzon.
Van néhány igazán forró téma, amelyeket a helyszínen látunk, például a biztonság és a számítógépes kockázat. Nagyon valódi kihívások számukra. Van egy igazán ügyes eszköz, az úgynevezett északi az interneten, ahol ülhet és nézhet egy weboldalon a valós időben zajló különféle számítógépes támadásokat. Amikor megnézi, azt gondolja, hogy „ó, ez egy kedves aranyos kis weboldal”, de körülbelül öt perc múlva rájön, hogy a rendszer az adatok mennyiségét elemzi a világ minden tájáról származó különféle adatfolyamon. amelyeket táplálnak bennük. Felborul az a gondolat, hogy miként teljesítik ezt a lemezt a szélén, és ez az egyszerű kis képernyő jelenik meg, amely elmondja neked, hogy mihez vagy valami máshoz támadja meg valós időben, és hogy milyen típusú támadások történnek. De ez egy nagyon ügyes kis módszer, hogy egyszerűen megismerkedjünk azzal, amit a stream-elemzés valós időben potenciálisan meg tud tenni azáltal, hogy csak megnézed ezt az oldalt, és megismerkedsz csak a stream-ek mennyiségével és kihívásával, feldolgozva az elemzési lekérdezéseket őket, és ezt valós időben képviselik.
Úgy gondolom, hogy az ülés hátralévő részében az összes ilyen típusú dolgot egy érdekes nézetemmel fogom megvitatni, véleményem szerint, és ez a DIY kihívása, süssd ki magad, és ez megfelel a klasszikus egyszarvúak, akik engedhetik meg maguknak az ilyen típusú dolgok építését. Több milliárd dolláruk van ezeknek a mérnöki csapatoknak és az adatközpontoknak a felépítéséhez. De az ott működő szervezetek 99, 9% -ának, akik értéknövelni akarják a stream-elemzést üzleti tevékenységükben, be kell szerezniük a polcon kívüli szolgáltatást. Meg kell vásárolni egy terméket a dobozból, és általában szükségük van valamilyen tanácsadási szolgáltatásra és professzionális szolgáltatásra, hogy segítsék annak megvalósítását, és ezt az értéket megszerezzék az üzleti életben, és működő megoldásként adják vissza az üzletnek.
Ezzel visszaadlak neked, Rebecca, mert azt hiszem, erre fogunk most részletesen kitérni.
Rebecca Jozwiak: Kiváló. Nagyon köszönöm Dez. Nagyszerű bemutató.
Most átadom a labdát Robinnak. Elvenni.
Robin Bloor: Oké. Mivel Dez beleszámolt a patakok feldolgozásának gonosz morzsába, úgy tűnt, nem volt értelme számomra, hogy újra lefedjem. Szóval csak egy teljesen stratégiai nézetet fogok felvenni. Szinte egy nagyon magas szintről nézve, mi a fene folyik, és pozicionálom, mert szerintem ez segíthet az embereknek, főleg azoknak az embereknek, akiknek korábban még nincs táborában a nagy mélységű feldolgozási folyamat.
A patakok feldolgozása már hosszú ideje zajlik. CEP-nek hívtuk. Előtte voltak valós idejű rendszerek. Az eredeti folyamatvezérlő rendszerek valójában információáramot dolgoztak fel - természetesen semmi sem ment olyannyira, mint manapság. Ez a grafika, amelyet itt láthat a dián; valójában sok dolgot rámutat, de rámutat minden más felett és azon túl - az a tény, hogy itt létezik egy sor színválaszték, amelyek különböző színekben jelennek meg. Ami igazán történt az 1960 körül megérkezett számítástechnikai vagy kereskedelmi számítástechnikai találmány óta, az az, hogy minden egyszerűen gyorsabbá vált. Régebben attól függöttünk, hogy ez valójában hogyan jön ki, ha úgy tetszik, mint hullámok, mert így néz ki. Ez valójában attól függ. Mivel mindezt Moore törvénye hajtotta végre, és Moore törvénye mintegy hat év alatt tízszeres sebességet eredményezne nekünk. Akkor, amikor ténylegesen 2013-ra eljutottunk, az mind megtört, és hirtelen olyan gyors ütemben kezdtünk felgyorsulni, hogy még soha nem voltunk, ami különös módon példátlan. Körülbelül tízszeres tényezőt kaptunk a sebességnövekedés és ennélfogva körülbelül hatévente csökkenő késés miatt. A körülbelül 2010 óta eltelt hat évben legalább egy ezerből álló többszörösünk van. Egy helyett három nagyságrendű.
Ez történik, és úgy tűnik, hogy az ipar úgy vagy úgy fantasztikus sebességgel mozog - mert az. Csak az adott grafika jelentésének áttekintése mellett a válaszidők egyébként algoritmikus skálán vannak a függőleges tengelyen. A valós idő a számítógép sebessége, gyorsabb, mint az embereknél. Az interaktív idők narancssárgák. A számítógéppel való kapcsolatfelvételkor valóban azt szeretné, ha egy tized-től körülbelül egy másodpercig elkésne. Fentiekben van olyan tranzakciós, ahol valójában arra gondolunk, hogy mit csinálsz a számítógépen, de ha ez körülbelül tizenöt másodperc alatt kialszik, akkor elfogadhatatlanná válik. Az emberek valójában csak nem várják meg a számítógépet. Minden szakaszosan történt. Sok olyan tétel, amely sorozatban történt, most jön le közvetlenül a tranzakciós térbe, közvetlenül az interaktív térbe vagy akár a valósidejű térbe. Míg korábban egy hullámos, nagyon kevés adatmennyiséggel ezt meg tudtuk csinálni, mostantól igen nagy mennyiségű adatgal is meg tudjuk csinálni a hatalmas méretű környezetet.
Tehát alapvetően mindez azt mondja, hogy valóban a tranzakció és az interaktív emberi válaszidők vannak. Rendkívül sok dolog, amit most folynak a patakok, az, hogy tájékoztassák az embereket a dolgokról. Néhányan gyorsabban halad, és jól informálja a dolgokat, tehát valós időben van. Ezután engedélyt veszünk, hogy csak úgy dobjunk el, mint egy kő, és ezáltal az azonnali elemzés megvalósíthatóvá válik, és egyébként meglehetősen megfizethető. Nem csak a sebesség csökkent, hanem a teteje is összeomlott. Valószínűleg a leginkább befolyásolja ezeket az összes prediktív elemzést, különféle alkalmazások között. Egy perc múlva elmondom neked.
Ez csak a bolt. Van párhuzamos szoftver. 2004-ben beszélünk. Scale-out architektúra, többmagos chipek, memórianövelés, konfigurálható CPU. Az SSD-k most sokkal gyorsabban mennek, mint a forgó lemez. Nagyon sok búcsút adhat a forgó lemezről. Az SSD-k több magban is vannak, tehát ismét gyorsabb és gyorsabb. Hamarosan megjelenik, megszereztük a memristort a HP-től. Megvan a 3D XPoint az Inteltől és a Microntól. Ezek ígérete az, hogy mindez egyébként gyorsabb lesz. Amikor valójában két új memória-technológiára gondol, amelyek mindegyike az egész alapvető darabot elkészíti, az egyes áramköri lapok gyorsabban haladnak, még a végét sem láttuk.
A Streams technológia, amely valóban a következő üzenet, itt marad. Új építészetnek kell lennie. Úgy értem, Dez ezt már több pontban megemlítette előadásában. Az építészetet évtizedek óta adathalmazok és adatcsövek kombinációjának tekintjük. Hajlattunk feldolgozni a halmokat, és hajlamosak volt az adatokat az adatgyűjtésre a halom között. Most alapvetõen elmozdulunk az ún. Lambda adat architektúra felé, amely az adatfolyamok feldolgozását az adathalmokkal ötvözi. Amikor ténylegesen feldolgozza a történeti adatokkal beáramló eseményfolyamot adatfolyamként vagy adathalomként, erre gondolok a Lambda architektúrán. Ez még gyerekcipőben áll. Ez csak a kép egy része. Ha úgy gondolja, hogy valami olyan összetett, mint az Internet a Minden, amelyet Dez is megemlített, akkor valójában rájön, hogy mindenféle adatmeghatározási kérdés merül fel - döntések arról, hogy mit kell feldolgozni az adatfolyamban.
A dolog, amit itt mondok, az az, hogy amikor kötegelt feldolgozást hajtottunk végre, ténylegesen adatfolyamokat dolgoztunk fel. Egyszerűen nem tudtuk megcsinálni. Csak várunk, amíg nagy halom cucc lesz, majd egyszerre feldolgozzuk. Olyan helyzetbe megyünk, ahol valójában feldolgozhatjuk az anyagot a patakban. Ha feldolgozhatjuk az adatfolyamot, akkor az általunk tartott adathalmok statikus adatok lesznek, amelyekre hivatkoznunk kell az adatfolyam feldolgozásához.
Ez elvezet minket ehhez a dologhoz. Korábban már említettem ezt a biológiai analógiával kapcsolatos néhány bemutatóban. Abban a pillanatban, amikor emberek vagyunk, szeretnék gondolkodni. Három különálló hálózatunk van a valósidejű prediktív feldolgozáshoz. Szomatikusnak, autonómnak és enterikusnak nevezik őket. Az enterikus a gyomrod. Az autonóm idegrendszer harcol és repül. Valójában gyorsan reagál a környezetre. A szomatikus, amely gondoskodik a test mozgásáról. Ezek valós idejű rendszerek. Az érdekes dolog - vagy azt hiszem, nagyon érdekes - sokkal előrejelzőbbek, mint gondolnád. Olyan mintha valójában egy képernyőre nézel körülbelül 18 hüvelyk távolságra az arcától. Amit világosan lát, az egész, amit a test egyértelműen lát, valójában egy 8 × 10 téglalap. A testén kívüli minden valójában elmosódott a test szempontjából, de az elméje valójában kitölti a hiányosságokat, és nem homályos. Egyáltalán nem lát elmosódást. Világosan látja. Az agyad valójában prediktív módszert alkalmaz az adatfolyamra annak érdekében, hogy láthassa ezt az egyértelműséget. Ez egy furcsa dolog, de valójában megnézheti az idegrendszer működését és azt, hogy miként sikerül körülkerülnünk és ésszerűen viselkednénk - legalábbis néhányunk közül - ésszerűen udvariasan, és nem botlik a dolgokhoz.
Mindezt egy idegi analitikai skálán végez itt. Ami megtörténik, hogy a szervezeteknek ugyanazok a dolgok lesznek, és ugyanazokat a dolgokat fogják építeni, és az adatfolyamok feldolgozása lesz, ideértve a szervezet belső patakjait is - azok a dolgok, amelyek belül zajlanak ez, a dolgok, amelyek kívül esnek, az azonnali válaszok, amelyeket valójában meg kell tenni, természetesen táplálják az embert, hogy döntéseket hozzon, és mindezeket megtegye. Hová megyek, odamennünk, amennyire látom.
Ennek egyik következménye az, hogy a streaming alkalmazás szintje jól megy. Szörnyen sokkal több lesz, mint most látjuk. Jelenleg az alacsonyan lógó gyümölcsöt válogatjuk a nyilvánvaló dolgok elvégzéséhez.
Tehát egyébként ez a következtetés itt. Az analitikai adatfolyam streaming már egyszer egy rés, de ma már mainstream, és hamarosan általában elfogadják.
Ezzel visszaadom Rebecca-nak.
Rebecca Jozwiak: Nagyon köszönöm, Robin. Nagyszerű bemutató, mint általában.
Anand, most már felállsz. A padló a tiéd.
Anand Venugopal: Fantasztikus. Köszönöm.
A nevem Anand Venugopal és a StreamAnalytix termékvezetője vagyok. Ez egy termék, amelyet az Impetus Technologies kínál, a kaliforniai Los Gatos-ból.
Az Impetus nagy története volt a nagy adatfeldolgozó megoldások szolgáltatójaként a nagyvállalatok számára. Tehát ténylegesen számos streaming analitikai megvalósítást hajtottunk végre szolgáltató vállalatként, és rengeteg leckét tanultunk. Az utóbbi néhány évben váltottunk át termék- és megoldásközpontú vállalattá is, és a stream-elemzés felelősséget vállal az Impetus nagymértékben termékvezérelt vállalattá történő átalakításáért. Van néhány kritikus, nagyon-nagyon fontos eszköz, amelyet az Impetus a vállalkozásoknak való kitettségünknek köszönhetően törölt, és ezek közé tartozik a StreamAnalytix.
20 éve vagyunk az üzleti életben, és van egy nagyszerű termék és szolgáltatás keverék, amely hatalmas előnyt jelent számunkra. A StreamAnalytix az első öt vagy hat streaming megvalósításunkból levont tanulságokból származik.
Néhány dolgot meg fogok érinteni, de az elemzők, Dez és Robin fantasztikus munkát végeztek a teljes helyiség lefedésében, így kihagyok egy csomó átfedő tartalmat. Valószínűleg gyorsan megyek. A valódi streaming eseteken túl sok egyszerű kötegelt gyorsítást használunk, ahol szó szerint nagyon, nagyon fontos kötegelt folyamatok vannak a vállalkozásokban. Mint láthatja, egy esemény érzékelésének, elemzésének és az ahhoz való reagálásnak az egész ciklusa hetekbe telt a nagyvállalatokban, és mindannyian megpróbálják percre, néha másodpercre és milliszekundumra csökkenteni azt. Tehát bármi, ami gyorsabb, mint az összes kötegelt folyamat, a vállalkozás megszerzéséhez jelent, és ez nagyon jó dolog, ha az adatok értéke drámai módon csökken az életkorával, így annál nagyobb az érték a kezdeti részben másodpercben, amikor csak történt. Ideális esetben, ha előre tudja mondani, mi fog történni, akkor ez a legmagasabb érték. Ez azonban a pontosságtól függ. A következő legmagasabb érték az, ha ott van, amikor történik, elemezheti és reagálhat. Az érték természetesen drasztikusan csökkenti ezt követően a fő korlátozó BI-t, amelyben vagyunk.
Érdekes. Feltehet valamilyen drámai tudományos választ arra, hogy miért streaming analitika. Sok esetben azt látjuk, mert az már lehetséges, és mivel mindenki tudja, hogy a tétel régi, a tétel unalmas, és a tétel nem jó. Van elegendő oktatás, amely most már mindenkinek megtörtént, hogy streaming lehetséges és mindenkinek van Hadoop-ja. Most a Hadoop disztribúciókba ágyazott streaming technológia van, akár Storm, akár Spark streaming, és természetesen üzenetsorok, például Kafka stb.
Az általunk látott vállalkozások ugrálnak bele és kísérleteznek ezekkel az esetekkel, és két széles kategóriát látunk. Az egyiknek köze van az ügyfél-elemzéshez és az ügyfél-tapasztalathoz, a másikhoz pedig az operatív intelligencia. Kicsit később belemegyek ehhez a részletekbe. A teljes ügyfélszolgálat és az ügyfél-élmény szöge, és mi, az Impetus StreamAnalytix-nél, sok különböző módon végeztük el ezt, valójában az a tény, hogy valóban megragadjuk a fogyasztó többcsatornás elkötelezettségét valós időben, és nagyon-nagyon környezetfüggő élményeket adjunk nekik amelyek manapság nem gyakoriak. Ha az interneten, a Bank of America webhelyen böngész, és néhány terméket kutatott, és csak felhívta a call centeret. Azt mondanák: „Hé Joe, tudom, hogy néhány banki terméket kutatott, szeretné, ha kitöltnélek?” Ma nem számítana erre a mai napra, de ez az a fajta élmény, amely valóban lehetséges az adatfolyam-elemzéssel. Sok esetben ez hatalmas különbséget jelent, különösen akkor, ha az ügyfél kutatási lehetőségeket kezdett el veled megkötendő szerződéseikből való kilépéshez azáltal, hogy weboldalán megvizsgálja a korai felmondási záradékokat vagy a felmondási feltételeket, majd felhívja, és Ön képes közvetlenül szembenéznek velük, de csak közvetetten tesznek ajánlatot valamilyen első promócióval kapcsolatban, mivel a rendszer tudja, hogy ez a személy a megszűnés előtti időpontra szól, és amikor Ön megteszi ezt az ajánlatot, akkor nagyon jól meg tudja védeni ezt a csorbító ügyfelet és megóvhatja azt az eszközt. .
Ez lenne egy példa, és sok ügyfélszolgálat is nagyon jó példa. A ma megvalósításuknak köszönhetően csökkennek a call center költségei, és drámai, elragadó vásárlói élményt nyújt. Dez nagy munkát végzett néhány felhasználási eset összegzésében. Pár percig bámulhatja ezt a diagramot. Besoroltam függőleges, vízszintes és kombinált területekké, tárgyak internete, mobil alkalmazás és call center. Mindegyik függőleges és vízszintes. Attól függ, hogyan nézel rá. Alsó sorban látunk sok olyan horizontális felhasználást, amely meglehetősen általános az iparág vertikumainál, és vannak vertikális specifikus felhasználási esetek, ideértve a pénzügyi szolgáltatásokat, az egészségügyi ellátást, a távközlést, a gyártást stb. Ha valóban felteszi magának a kérdést, vagy elmondja magának hogy „ó, nem tudom, hogy vannak-e használati esetek. Nem vagyok biztos abban, hogy van-e valami üzleti érték a streaming elemzésben a saját vagy a vállalkozásom számára ”- gondolkodj bele, gondolj kétszer. Ha több emberrel szeretne beszélni, mert vannak olyan esetek, amelyek a vállalatánál relevánsak ma. Megvizsgálom, hogy az üzleti érték pontosan hogyan származik.
Az itt található piramis alján prediktív karbantartás, biztonság, csúszásgátlás stb. Van. Az ilyen használati esetek a bevételek és eszközök védelmét jelentik. Ha a Target megóvná az órák és hetek alatt bekövetkező biztonsági megsértéseiket, a CIO megmenthette volna a munkáját. Tíz vagy száz millió dollárt takaríthat meg, stb. A valós idejű adatfolyam-analitika valóban segít ezen eszközök védelmében és a veszteségek védelmében. Ez a közvetlen üzleti hozzáadott érték ott.
A következő kategória jövedelmezőbbé válik, csökkenti a költségeket és több bevételt szerez a jelenlegi működésből. Ez a jelenlegi vállalkozás hatékonysága. Ezek mind a felhasználási esetek kategóriája, amelyet valós idejű operatív intelligenciának hívunk, ahol mély betekintést kap a hálózat viselkedéséből, az ügyfelek műveleteinek viselkedéséből, az üzleti folyamatok viselkedéséből, és megkönnyítheti a finomítást. Mindezt valós időben, mert visszajelzést kap, riasztásokat kap. Valós időben kap eltéréseket, eltéréseket, és gyorsan cselekedhet, és elválaszthatja a határain kívül eső folyamatot.
Nagyon sok pénzt takaríthat meg drága tőkejavításokban és olyan dolgokban, amelyek Ön szerint szükségesek, és amelyek a hálózati szolgáltatás optimalizálásakor nem feltétlenül szükségesek. Hallottunk egy olyan esetről, amikor egy nagy telco elhalasztotta a 40 millió dolláros frissítést hálózati infrastruktúrájukban, mert úgy találták, hogy elegendő kapacitással rendelkeznek a jelenlegi forgalom irányításához, azaz a forgalom és hasonló dolgok intelligens útválasztásának optimalizálása és jobb végrehajtása révén. Mindez csak valósidejű elemzéssel és cselekvési mechanizmussal lehetséges, amelyek valós időben hatnak ezekre a betekintésekre.
A hozzáadott érték következő szintje a fel-eladás, a keresztértékesítés, ahol lehetősége van több bevételt és profitot szerezni a jelenlegi kínálatból. Ez egy klasszikus példa, amelyet sokan tudnak arról, hogy már megtapasztalták, ahol azon gondolkodik azon életében, ahol hajlandó ténylegesen olyan terméket vásárolni, amelyet ma nem kínálnak Önnek. Sok-sok esetben valójában ez történik. Van olyan dolgod a fejedben, hogy szeretsz vásárolni, tudod, hogy vásárolni akarsz, hogy van tennivalók listája vagy valami, amit a felesége mondott neked, vagy ha nincs felesége, de tényleg vásárolni akartál és vásárolsz egy weboldalon, vagy pedig egy kiskereskedelmi üzletben lépsz kapcsolatba, az üzletfelületnek egyszerűen nincs a kontextus, nincs intelligenciája ahhoz, hogy kiszámítsa, amire szüksége lehet. Ezért nem biztosítják biztonságosan üzleti tevékenységüket. Ha az streaming analitika felhasználható lenne a valódi pontos előrejelzések készítéséhez, és amelyek valóban lehetségesek abban, ami a legmegfelelőbb az adott helyzethez, akkor ebben az ügyfélben ebben az időben sok fel-eladás és keresztértékesítés található, és ez ismét származik streaming analitika - képesség alapján döntést hozni arról, hogy az ügyfél valószínűleg vásárol, vagy reagál erre az igazság abban a pillanatban, amikor van rá lehetőség. Ezért szeretem azt a képet, amelyet Dez mutatott a medvével, éppen arra, hogy megeszi ezt a halat. Nagyon sok ez.
Úgy gondoljuk, hogy van egy nagy kategória a drámai, átalakító változásokon egy vállalkozásban, amely teljesen új termékeket és szolgáltatásokat kínál, egyszerűen az ügyfelek viselkedésének megfigyelésén alapul, mindegyik egy másik vállalkozás viselkedésének megfigyelésén alapul. Ha mondjuk, hogy egy telekommunikációs vagy kábeltévé-társaság valóban megfigyeli az ügyfelek használati szokásait abban a piaci szegmensben, amelyet, mikor néz ki, mikor, stb., Akkor ténylegesen olyan termékeket és szolgáltatásokat hoznak létre, amelyek szinte könyörögnek valamilyen módon. Tehát a multi-screen viselkedés egész koncepciója jelenleg abban a pillanatban, amikor szinte magától értetődőnek tekintjük, hogy a mobil alkalmazásokban láthatjuk a TV vagy a kábel tartalmát. Néhány példa azokból az új termékekből és szolgáltatásokból származik, amelyeket számunkra kínálnak.
Belemérek: „Melyek a streaming analitika építészeti szempontjai?” Végül ezt próbáljuk megtenni. Ez a Lambda architektúra, ahol keverjük össze a történelmi adatokat és a valós idejű betekintést, és egyszerre látjuk. A Sigma ezt teszi lehetővé. Ma mind a tételes architektúra és a vállalati kép megvan. Valamely BI-verembe és felhasználási verembe belemegyünk, és hozzáadtuk a Lambda architektúrát. Mivel a sebességréteg vagy az igény és a Lambda az, hogy összekapcsoljuk ezt a két betekintést, és ezt kombinált módon látjuk, gazdag módon, amely ötvözi mindkét betekintést.
Van egy másik, a Kappa architektúrának nevezett paradigma is, amelyet akkor javasolnak, amikor az a feltevés az, hogy a sebességréteg az egyetlen bemeneti mechanizmus, amely hosszabb távon fennmarad. Minden megy keresztül ezen a sebességrétegen. Még nem is lesz offline ETL-mechanizmus. Minden ETL megtörténik. Tisztítás, adattisztítás, minőségi ETL - mindez történik a vezetéken, mert ne feledje, hogy minden adat valós időben született. Egy időben valós idő volt. Annyira megszoktuk, hogy ezt a tavakra, a folyókra és az óceánokra felvisszük, majd statikus elemzéssel elvégezzük, így elfelejtettük, hogy az adatok valamikor valós időben születtek. Az összes adat valós idejű eseményként született, amely az idő pillanatában történt, és a mai legtöbb tó adatait csak bekerítették az adatbázisba egy későbbi elemzés céljából, és most a Lambda és a Kappa architektúrában megvan az az előnye, hogy valójában látni, elemezni, előfeldolgozni és reagálni, amikor megérkezik. Ez az, amit ezek a technológiák lehetővé tesznek. Ha általános képet nézel, úgy néz ki, mintha a Hadoop benne van, MPP-k és adattárházai vannak.
Ezt feltette, mert fontos, hogy ne csak az új technológiákról beszéljünk egy szigeten. Integrálniuk kell. A jelenlegi vállalati kontextusban értelmeseknek kell lenniük, és mint vállalkozásokat kiszolgáló megoldásszolgáltatók nagyon érzékenyek vagyunk erre. Segítünk a vállalkozásoknak az egész ügy integrációjában. A bal oldalon vannak olyan adatforrások, amelyek mind a Hadoop, mind az adattárház rétegekbe, valamint a tetején lévő valós idejű rétegbe táplálkoznak, és ezek mindegyike entitás raktárszámítógép, ahogy láthatjuk, és az adatfogyasztási réteg a jobb oldalon található oldal. Folyamatos erőfeszítések történnek a megfelelés, a kormányzás, a biztonság, az életciklus-menedzsment stb. Többségének mozgatására, amelyek ma elérhetőek, mindannyian beépítették ezt az új technológiát.
Az egyik elem, amelyet a stream-analitika megpróbál tenni, ha a mai tájra nézzük, akkor sok minden zajlik a streaming-technológiai környezetben, és egy vállalati ügyfél szempontjából annyit kell megérteni. Annyival kell lépést tartani. A bal oldalon vannak adatgyűjtő mechanizmusok - NiFi, Logstash, Flume, Sqoop. Nyilvánvalóan kijelentem, hogy nem kimerítő. Bejutás az üzenetsorokba, majd a nyílt forrású streaming motorokba - Storm, Spark Streaming, Samza, Flink, Apex, Heron. A gém valószínűleg még nem nyílt forráskódú. Nem vagyok biztos benne, hogy van-e ez a Twitteren keresztül. Ezek a streaming motorok azután beállító elemző alkalmazás-összetevőket vezetnek vagy támogatnak, például komplex eseményfeldolgozás, gépi tanulás, prediktív analitika, riasztási modul, ETL streaming, gazdagítási statisztikai műveleti szűrők. Mindezeket most operátoroknak hívjuk. Az egymással összehúzódó operátorok halmaza szintén bizonyos szokásokat, amelyek nagyrészt megkötésre kerülnek, ha szükséges, streaming alkalmazásgá válik, amely streaming motoron fut.
Az alkotóelem-lánc részeként az adatokat el kell tárolnia és indexelnie kell a kedvenc adatbázisába, a kedvenc indexébe. Lehet, hogy el kell osztania a gyorsítótárat, és ismét, amely a felső rész jobb oldalán található adatmegjelenítő rétegbe vezet kereskedelmi termékekre vagy nyílt forrású termékekre, de végül valamilyen termékre van szüksége az adatok valós időben történő megjelenítéséhez. Ezenkívül más alkalmazásokat is el kell találnia. Mindannyian láttuk, hogy az értékek, amelyeket csak a betekintést nyújtó művelet eredményez, az adott elem egy analitikai veremből egy másik alkalmazáskötegbe vált, amely valószínűleg megváltoztatja valami az IVR oldalán, vagy hívásközpontot vált ki. kimenő hívás vagy valami hasonló. Integrálnunk kell ezeket a rendszereket és valamilyen mechanizmust az streaming-fürtünkhöz, hogy elindítsuk az adatok továbbítását más alkalmazásokból.
Ez az az egész stack balról jobbra haladva. Akkor megvan a szolgáltatási rétegek, a középső megfigyelés, a biztonsági általános szolgáltatási rétegek stb. Melyik termékeket látják el a vállalati térségben, amelyeket az ügyfelek látnak, mint például a Hadoop disztribúciók, amelyek mindegyike olyan streaming, mint ahogy mondtam, és van kereskedelmi vagy egyetlen -vendor megoldások, amelyek nyilvánvalóan a versenytársakban vannak. A tájban még sok más található, amelyeket itt esetleg nem említettünk.
Amit általában lát, azt a vállalati felhasználó látja. Mint láthatja, egy összetett és gyorsan fejlődő technológiai tájkép az adatfolyam-feldolgozáshoz. Egyszerűsítettük a választást és a felhasználói élményt. Amit azt gondoljuk, hogy a vállalkozásoknak valóban szükségük van mindezen funkciók absztrakciójára egyablakos, könnyen használható felületen, amely összekapcsolja azokat a technológiákat, amelyek valóban egyszerűvé teszik a használatot, és nem teszik ki az összes mozgó alkatrészt. valamint a degradációval, a teljesítménygel és az életciklus fenntartásával kapcsolatos kérdések a vállalkozás számára.
A funkcionális absztrakció egy. A második rész a streaming motor absztrakciója. A streaming motorok és a nyílt forráskódú domainek most három, négy vagy hat hónapban jelennek meg. Sokáig vihar volt. Feljött Samza, és most Spark Streaming van. Flink felemeli a fejét, és kezd felhívni a figyelmet. Még a Spark Streaming ütemterv útján állnak, ha potenciálisan más motort használnak a tiszta eseményfeldolgozáshoz, mert rájönnek arra is, hogy a Spark-ot tételekre tervezték, és utat mutatnak az építészeti elképzelésükben és az ütemtervükben, hogy potenciálisan eltérőek legyenek. motor az adatfolyam-feldolgozáshoz, a Spark Streaming jelenlegi mikrobatch mintázatán túl.
Ez egy valóság, amellyel meg kell birkóznod, hogy nagyon sok evolúció lesz. Tényleg meg kell védenie magát a technológiai áramlástól. Mivel alapértelmezés szerint ki kell választania egyet, majd élnie kell vele, ami nem optimális. Ha másképp nézi, akkor a következők között harcol: „oké, meg kellett vásárolnom egy saját platformot, ahol nincs zárolás, nincs nyílt forráskódú tőkeáttétel, nagyon költséges és korlátozott lehet. rugalmasság az összes ilyen nyílt forráskódú veremhez képest, ahol magad kellett volna csinálni. ”Ismét, amint mondtam, sok költség és késés jelent meg a piacra jutáskor. Amit a StreamAnalytix mond, az a nagyszerű platform egyik példája, amely összehozza a vállalati osztályt, megbízható, egyetlen gyártót, támogatott professzionális szolgáltatást - mindazt, ami vállalkozásként valóban szüksége van, és a nyílt forráskódú ökoszisztéma rugalmasságának erejét ahol egyetlen platform egyesíti őket - Ingest, CEP, analytics, visualization és mindez.
Ez egy nagyon-nagyon egyedi dolgot is elvégz, amely számos különböző technológiai motort hoz össze egyetlen felhasználói élmény alatt. Valóban azt gondoljuk, hogy a jövőben több streaming motor használható, mivel a különböző használati esetek valóban eltérő streaming architektúrákat igényelnek. Mint Robin mondta, a késések teljes spektruma létezik. Ha valóban ezredmillió másodperc vagy tízmillió másodperc késleltetési szintről beszél, akkor valóban szüksége van a Stormra, amíg van egy másik, ugyanolyan érett termék kevésbé engedékenységre vagy enyhe idõkeretre, és néhány másodperc, három másodperc alatt a késésekre, négy, öt másodperc alatt, akkor használhatja a Spark Streaming-t. Lehetséges, hogy vannak olyan motorok, amelyek mindkettőt megtehetik. A lényeg, hogy egy nagyvállalatban mindenféle eset fog fordulni. Nagyon szeretné, ha a hozzáférésnek és az általános szabályoknak több motorral kell rendelkezniük, egy felhasználói élménnyel, és ezt próbáljuk építeni a StreamAnalytix programban.
Csak egy gyors áttekintés az építészetről. Ezt egy kicsit átdolgozzuk, de alapvetően a bal oldalon többféle adatforrás érkezik - Kafka, RabbitMQ, Kinesis, ActiveMQ, ezek az összes adatforrás és üzenetsor várja az adatfolyam-feldolgozó platformot. össze kell állítania egy alkalmazást, amellyel elhúzhatja az operátorokat, mint például az ETL-ek, az összes dolgot, amelyről beszéltünk. Alatta több motor található. Jelenleg a Storm és a Spark Streaming van az iparág egyetlen és első vállalati szintű streaming platformja, amely több motor támogatással rendelkezik. Ez egy nagyon egyedi, rugalmasság, amelyet a valós idejű műszerfalak minden egyéb rugalmassága mellett kínálunk. Beépített CET motor. Zökkenőmentesen integráljuk a Hadoop és a NoSQL indexeket, a Solr és az Apache indexeket. Lehetősége van kedvenc adatbázisához, függetlenül attól, hogy mi az, és az alkalmazásokat gyorsan elkészítheti, nagyon gyorsan eljuthat a piacra, és továbbra is bizonyíthatja a jövőt. Ez az egész mantra a StreamAnalytix-ben.
Ezzel azt hiszem, befejezem a megjegyzésem. Nyugodtan forduljon hozzánk további kérdésekre. Szeretném nyitva tartani a szót a kérdések és válaszok, valamint a panelbeszélgetések számára.
Rebecca, neked.
Rebecca Jozwiak: Nagyszerű, oké. Nagyon szépen köszönöm. Dez és Robin, van néhány kérdése, mielőtt átadjuk a közönség kérdéseire és kérdéseire?
Robin Bloor: Van egy kérdésem. Visszateszem a fejhallgatót, hogy hallhass. Az egyik érdekes dolog, ha ezt kedvesen elmondanád nekem, sok olyan elem, amit láttam a nyílt forráskódú téren, úgy néz ki, amit éretlennek tartok nekem. Bizonyos értelemben igen, te is csinálhatsz különböző dolgokat. De úgy néz ki, hogy a szoftvert az első vagy a második kiadásban tekintjük a valóságban, és csak azon gondolkoztam, hogy milyen tapasztalatai vannak egy szervezetnél: mennyire látja problematikusnak a Hadoop környezet éretlenségét, vagy pedig nem t túl sok problémát okoz?
Anand Venugopal: Ez egy valóság, Robin. Teljesen igazad van. Az éretlenség nem feltétlenül a funkcionális stabilitás és a dolgok területén rejlik, de lehet, hogy néhány esetben is. De az éretlenség inkább a felhasználási készség szempontjából rejlik. A nyílt forráskódú termékek, amint megjelennek, és még ha a Hadoop disztribúció is felkínálja őket, mindegyik sokféle képes termék, alkatrész, csak összeütközött. Nem működnek együtt zökkenőmentesen, és nem olyan zökkenőmentes felhasználói élményt nyújtanak, amelyet a Bank of America, a Verizon vagy az AT&T hozhat létre, és hetek alatt telepíthetnek egy streaming elemző alkalmazást. Biztosan nem erre készültek. Ez az oka annak, hogy belépünk. Összehozzuk és valóban könnyű megérteni, telepíteni stb.
Ennek funkcionális érettsége, azt hiszem, nagymértékben ott van. Sok nagyvállalat például ma használja a Stormot. Sok nagy vállalkozás ma játszik a Spark Streaming-rel. Ezen motorok mindegyikének megvan a korlátja abban, hogy mit tud tenni, ezért fontos tudni, hogy mit tudsz és mit nem tudsz megtenni az egyes motorokkal, és nincs értelme a fejednek a falnak ütni és azt mondani: úgy döntött, hogy a Spark Streaming nem működik számomra ezen az iparágon. ”Nem fog működni. Lesz olyan esetek, amikor a Spark Streaming lesz a legjobb választás, és lesznek olyan esetek, amikor a Spark Streaming valószínűleg nem fog működni az Ön számára. Éppen ezért van szüksége több lehetőségre.
Robin Bloor: Ennek nagy részéhez szükség van szakértői csoportokra a fedélzeten. Úgy értem, hogy azt sem tudom, honnan kezdjem. A szakemberek ésszerű együttmûködése. Érdekel, hogy hogyan vesz részt az elkötelezettség és hogyan történik ez. Ennek oka az, hogy egy adott cég egy adott alkalmazást követ, vagy lát olyan stratégiát, amit stratégiai elfogadásnak neveznék, ahol azt akarják, hogy egy egész platform sok mindent megtegyen.
Anand Venugopal: Mindkettőre példákat látunk, Robin. Az első tíz márka közül, amelyeket mindenki tud, nagyon stratégiai módon jár el. Tudják, hogy különféle felhasználási esetekkel fognak élni, ezért olyan platformokat értékelnek, amelyek megfelelnek erre az igényre, azaz a különféle felhasználási esetek sokféle, többszörös bérlői módon történő alkalmazására egy vállalkozásban. Vannak egyszeri felhasználású eseti történetek, amelyek szintén kezdődnek. Van egy speciális üzleti tevékenység-figyelő típusú felhasználási eset egy olyan jelzálogkölcsön-társaságnál, amelyen dolgozunk, és amelyet Ön nem képzel el első felhasználási esetként, de ez az üzleti megoldás vagy felhasználási eset, amelyhez jöttek létre, majd összekapcsoltuk a pontokat az adatfolyammal . Azt mondták: „Tudod mit? Ez nagyszerű lehetőség az analitika streamingjére, és így tudjuk megvalósítani. ”Így kezdődött. Aztán ebben a folyamatban megtanulják és azt mondják: „Jaj, ha ezt meg tudjuk csinálni, és ha ez egy általános platform, akkor elválaszthatjuk az alkalmazást, rétegezhetjük őket platformra, és sok különböző alkalmazást építhetünk erre a célra. felület."
Robin Bloor: Dez, van kérdése?
Anand Venugopal: Dez valószínűleg néma.
Dez Blanchfield: Bocsánatkérés, néma. Csak magam jó beszélgetést folytattam. Csak követve Robin eredeti megfigyelését, teljesen igaza van. Úgy gondolom, hogy most a kihívás az, hogy a vállalkozások olyan ökoszisztémával, kulturális és magatartási környezettel rendelkezzenek, ahol a szabad és a nyílt forrású szoftverek valami olyan, amit nekik ismertek, és képesek olyan eszközöket használni, mint például a Firefox böngészőként, és megfelelő volt élettartama stabilá és biztonságossá válik. De az általuk használt nagyon nagy platformok közül néhány vállalati szintű védett platformok. Tehát a nyílt forráskódú platformok elfogadása nem mindig olyan, ami kulturálisan vagy érzelmileg könnyen átjuthat számukra. Láttam ezt csak olyan kis programok elfogadása során, amelyek helyi projektek voltak, hogy alapvető fogalom legyen a nagy adatokkal és az elemzéssel. Úgy gondolom, hogy az egyik legfontosabb kihívás, biztos vagyok benne, hogy már látta őket a szervezetekben, az a vágy, hogy elérjék az eredményt, ugyanakkor az egyik lábuk beragadt a régi dobozba, ahol ezt csak megvásárolhatták „Helyezzen be egy nagy márkát” az Oracle, az IBM és a Microsoft. Ezek az új és ismert márkák megjelennek a Hadoop platformon és még sok máson keresztül. Izgalmasabb márkák jönnek keresztül, amelyek olyan csúcstechnológiával rendelkeznek, mint a stream.
Milyen típusú beszélgetések vannak, amelyekben valamilyen módon megkapta vagy átvágta? Tudom, hogy ma reggel óriási látogatáson megyünk részt, és egy dolog, amiben biztos vagyok, mindenki számára az a véleményem, hogy „Hogyan vághatom át az egész kihívást jelentő réteget az igazgatótanácsról a vezetői szintre, ó, ez túl nyílt forrású és túl vérző? "Hogy mennek az ügyfelekkel folytatott beszélgetések, és hogyan vágják át azt a pontot, ahol enyhítik az ilyen típusú félelmeket, hogy fontolgassák a StreamAnalytix kedvelőinek elfogadását?
Anand Venugopal: Valójában meglehetõsen könnyû eladni értékjavaslatunkat, mivel az ügyfelek természetesen a nyílt forráskód felé mozdulnak elõnyben részesített megoldásként. Nem egyszerűen feladják és mondják: „Oké, most nyílt forrású megyek.” Valójában egy fő termék nagyon elkötelezett értékelésén mennek keresztül, mondjuk, hogy ez egy IBM vagy egy tipikus termék, mert ezek az eladó kapcsolatok. Nem bántak velünk vagy a nyílt forráskódú motorral a termékkel szemben. Hat-nyolc-tizenkét hetes értékelési időszakon megy keresztül. Meg fogják győzni magukat arról, hogy van egy bizonyos fokú teljesítmény és stabilitás, amit szeretnék, majd gondolkodnak, mondván: "Hú, tudod mit, ezt tényleg meg tudom csinálni."
Például ma van egy elsődleges elsődleges telco, amely stream elemzéssel működik a gyártás mellett a sok verem mellett, és ezt egy másik nagyon-nagyon jó ismert eladóval szemben értékelik, és csak miután meggyőztük az összes a teljesítmény, a stabilitás és az összes ilyen dolog. Nem veszik magától értetődőnek. Megtudták, hogy a nyílt forráskódú kompetencia az értékeléseik során, és rájönnek, hogy a legrosszabb eset: „Talán vannak azok a két felhasználási eset, amelyeket talán nem tudok megtenni, de manapság a legtöbb vállalkozásom gyorsulási használatát kiemelkedően lehetséges a nyílt forráskódú verem. ”És lehetővé teszjük annak használatát. Szóval ez a nagy édes folt ott. A nyílt forráskódot akarták. Tényleg arra törekszenek, hogy kiszabaduljanak az eladók bezáródási helyzetéből, amelyhez sok-sok évig szoktak. Aztán itt jönnek, és azt mondják: "Tudod mit, sokkal könnyebben és barátságosabbá tesszük a nyílt forráskódú felhasználást az Ön számára."
Dez Blanchfield: Úgy gondolom, hogy a másik kihívás, amelyet a vállalkozások találnak, amikor behozzák a hagyományos inkumbenst, gyakran egy generáció mögött állnak az izgalmas dolgok valamilyen vérző vonala mögött, amiről itt beszélünk, és nem értem, hogy negatív enyhe. Csak a valóság az, hogy generációval és utazással járnak, hogy kiadják azt, amelyet stabil platformon tartanak, az old-school fejlesztést és az UATN integrációs ciklusokat, teszteket és dokumentációt, valamint a marketing és az értékesítés. Míg abban a típusban, amelyet csinálsz, azt gondolom, hogy gondolkodni szeretnék az, hogy ha tegnap este a legfrissebb kiadásainkat nézegettem valamilyen kutatási munkával, megvan ez a keverék, ahol megvan a kompetencia előzetes tanácsadási és megvalósítási szempontból, de van egy verem, amelyet be tudsz gördíteni. Azt hiszem, ez az, ahol az inkumbensek egy ideig küzdenek. Sokan láttuk, mint én a piacon. Gyakran abban vannak, amit én felzárkózási csomópontnak hívok, míg attól, amit mondasz nekünk, amikor odakint beszélgetsz, és ott vagytok, amellyel megvalósítasz.
Adna nekünk néhány példát néhány olyan határ-vertikális oldalról, amelyeket látott elfogadni? Például valóban van olyan nichey környezet, mint a rakétatudomány, a műholdak űrbe helyezése és az adatok gyűjtése a Marsról. Csak néhány ember csinálja ezt a bolygón. De vannak olyan nagy vertikális pontok, mint például az egészség, például a repülésben, a hajózásban és a logisztikában, a gyártásban és a mérnöki munkákban, amelyek néhány példája a nagyobb és szélesebb körű iparágaknak, amelyekben eddig jártál, hogy igazán jót láttál örökbefogadás?
Anand Venugopal: A Telco nagy példa erre.
Csak itt fogom gyorsan megjavítani a diáimat. Látja itt a diát, 4. esettanulmány?
Ez egy nagy telco eset, amikor a set-top box adatait elnyelik, és több dolgot csinálnak vele. Megvizsgálják, mit valós időben csinálnak az ügyfelek. A set-top boxokban azt vizsgálják, hogy hol valós időben történnek hibák. Megpróbálják tájékoztatni a telefonos ügyfélszolgálatot, ha ez az ügyfél azonnal felhívja az ügyfél set-top boxjának kódhivatkozási adatait, a karbantartási jegyekkel kapcsolatos információk gyorsan összekapcsolják, hogy az adott ügyfél set-top boxjában van-e probléma, vagy sem, még mielőtt az ügyfél beszél egy szót. Minden kábelszolgáltató és minden nagyobb telco megpróbálja ezt megtenni. Befogadják a set-top box adatait, valós idejű elemzéseket végeznek, kampányelemzéseket végeznek, hogy hirdetéseiket el lehessen helyezni. Van egy hatalmas felhasználási eset.
Mint mondtam, ott van ez a jelzálogkölcsön-társaság, amely ismét általános mintázat, ahol nagy rendszerek vesznek részt az adatok feldolgozásakor. Azok az adatok, amelyek az A rendszeren keresztül a B rendszeren keresztül a C rendszerbe áramolnak, és ezek szabályozott vállalkozások, amelyeknek mindennek következetesnek kell lennie. A rendszerek gyakran szinkronban vannak egymással, az egyik rendszer azt mondja: „Száz száz kölcsönt dolgozok fel, amelynek teljes értéke 10 millió dollár.” A rendszer azt mondja: „Nem, feldolgozom más kölcsönök 110 kölcsönét. különböző számú. ”Ezt nagyon gyorsan meg kell oldaniuk, mert valójában ugyanazokat az adatokat dolgozzák fel és eltérő értelmezéseket végeznek.
Legyen szó hitelkártyáról, hitelkezelésről, üzleti folyamatról, vagy jelzálog üzleti folyamatról, vagy valami másról, segítünk nekik valós időben korrelációt és egyeztetést végrehajtani annak biztosítása érdekében, hogy ezek az üzleti folyamatok szinkronban maradjanak. Ez egy másik érdekes felhasználási eset. Van egy nagy amerikai kormányzati vállalkozó, aki DNS-forgalmat keres anomáliák észlelésére. Van egy offline képzési modell, amelyet felépítettek, és a modell alapján pontozza a valós idejű forgalmat. Néhány ilyen érdekes felhasználási eset. Van egy nagy légitársaság, amely a biztonsági várakozási sorokat nézi, és megpróbálják megadni neked azt az információt, hogy: „Hé, ez a kapu a repülőgép repüléséhez. A TSA várólistája ma körülbelül 45 perc, szemben a két órával, valami mással szemben. ”Először megkapja ezt a frissítést. Még mindig dolgoznak rajta. Érdekes IoT használati eset, de nagyszerű eset az analitikai adatfolyam streamingjeinek figyelembe vétele az ügyfél élménye szempontjából.
Rebecca Jozwiak: Ez itt Rebecca. Amíg a használati esetekkel foglalkozik, nagyszerű kérdés van egy közönség tagjától, aki azon kíváncsi: „Ezek esettanulmányok, ezek a kezdeményezések a ház információs rendszerének elemző oldalából vezethetők, vagy inkább a az a vállalkozás, akinek vannak kérdései vagy igényei? "
Anand Venugopal: Úgy gondolom, hogy körülbelül 60 százalékot, 50–55 százalékot látunk, nagyrészt nagyon proaktív, lelkes technológiai kezdeményezéseket, akik történetesen tudnak, akik meglehetősen hozzáértőek és megértenek bizonyos üzleti követelményeket, és valószínűleg van egy szponzoruk, azonosították, de ezek olyan technológiai csapatok, amelyek felkészülnek a bekövetkező üzleti célú támadásokra, és ha egyszer megteremtik a képességeket, tudják, hogy meg tudják csinálni, majd üzleti vállalkozásba mennek, és ezt agresszíven eladják. Az esetek 30–40 százalékában azt látjuk, hogy az üzleti vállalkozásnak már van egy bizonyos felhasználási esete, amely streaming elemzési képességet kér.
Rebecca Jozwiak: Ennek van értelme. Van egy újabb, kissé technikai kérdésem egy közönség tagjától. Kíváncsi, vajon ezek a rendszerek támogatják-e mind a strukturált, mind a nem strukturált adatfolyamokat, például a Twitter-patakok vagy a Facebook-üzenetek üledékeit valós időben, vagy először szűrni kell?
Anand Venugopal: A termékek és technológiák, amelyekről nagyon gyorsan beszélünk, mind a strukturált, mind a nem strukturált adatokat támogatják. Ezek konfigurálhatók. Minden adatnak van valamilyen felépítése, legyen az szöveg, XML vagy bármi más. Van bizonyos struktúra az időbélyeg-adagolás szempontjából. Lehet, hogy van egy másik blob, amelyet elemezni kell, így az adatszerkezetek elemzéséhez befecskendezni az adatfolyamba az elemzést. Ha struktúrált, akkor csak azt mondjuk a rendszernek: „Oké, ha vannak vesszővel elválasztott értékek és az első egy karakterlánc, a második egy dátum.” Tehát befecskendezzük ezt az elemzési intelligenciát a képernyő felső rétegeibe és könnyen feldolgozza a strukturált és a strukturálatlan adatokat is.
Rebecca Jozwiak: Van még egy kérdésem a közönség részéről. Tudom, hogy kissé elfuttunk az óra tetején. Ez a résztvevő tudni akarja, úgy tűnik, hogy a valós idejű streaming alkalmazások szükségességet és lehetőséget teremtenek a tranzakciós rendszerekbe való integrálásra, például az általuk előidézett csalásmegelőzési rendszerekre. Ebben az esetben kell-e megváltoztatni a tranzakciós rendszereket, hogy azok valamilyen módon illeszkedjenek ehhez?
Anand Venugopal: Ez egy egyesülés, igaz? Ez egy tranzakciós rendszer egyesítése. Néha az adatok forrásává válnak, amikor valós időben elemezzük a tranzakciókat, és sok esetben mondjuk, hogy van egy alkalmazásáramlás, és itt próbálok mutatni egy statikus adatkeresési webhelyet, majd a mi esetünkben valamilyen streaming be, és statikus adatbázist keres, mint például HBase vagy RDBMS, hogy gazdagítsa a streaming adatokat és a statikus adatokat együtt, hogy döntést hozzon, vagy analitikus betekintést nyújtson.
Van egy másik nagy ipari tendencia, amelyet szintén látunk - az OLAP és az OLTP konvergenciája -, és ezért van olyan adatbázis, mint például a Kudu, és a memóriában lévő adatbázisok, amelyek egyszerre támogatják a tranzakciókat és az analitikus feldolgozást. Az adatfeldolgozási réteg teljes mértékben a memóriában lenne, és megvizsgáljuk ezeket a tranzakciós adatbázisokat, vagy kapcsolódunk hozzájuk.
Rebecca Jozwiak: Azt hiszem, a vegyes munkaterhelés volt az utolsó ugrásszerű akadály. Dez, Robin, van még két kérdésed?
Dez Blanchfield: Befejezem az utolsó kérdést, és ezt megteszem, ha nem bánod. Az első kihívás, amellyel a szervezetek, amelyekkel az elmúlt évtizedben foglalkoztam, vezetett a stream-elemzés ezen izgalmas kihívásaihoz, az első dolog, hogy hajlamosak az asztalra helyezni, amikor az egész kihívás körül folytatott beszélgetést elindítottuk: megszerezzük a készségeket? Hogyan átalakíthatjuk a készségeket és hogyan szerezzük meg ezt a képességet belsőleg? Miután beérkezett a lendület, kézig tart minket az utazáson, majd nagyszerű első lépésként hajtja végre, és nagyon értelme van erre.
De a közepes és nagy méretű szervezeteknél milyen típusú dolgokat látsz jelenleg, hogy felkészüljenek erre, hogy ezt a képességet belsőleg kiépítsék, bármit megszerezzenek az alapszintű szókincsből, és milyen üzenetet tudnak tenni velük az ilyen jellegű keretrendszerre való áttérés körül, és meglévő műszaki személyzetük átalakítását az IT-től a vezérigazgatótól, hogy ők maguk is működtethessék ezt, miután felépítették és megvalósították? Röviden, milyen kihívásokkal és hogyan oldják meg őket, az ügyfelekkel, akikkel foglalkoznak, milyen típusú kihívásokat találtak, és hogyan oldják meg ezt az átképzést, valamint a tapasztalatok és ismeretek visszanyerését, hogy felkészüljenek erre és képes működni?
Anand Venugopal: Gyakran az a kis embercsoport, aki megpróbál elmenni és megvásárolni egy streaming analitikai platformot, már ésszerűen okos abban az értelemben, hogy tisztában vannak Hadoop-val, már megszerezték Hadoop MapReduce készségeiket, és mivel szorosan együttműködnek a Hadoop-tal disztribútor, mindkettő ismerős. Mindent megkap, például Kafka. Valamit csinálnak vele, és akár a Storm, akár a Spark streaming van a nyílt forráskódú domainben. Minden bizonnyal az emberek ismerik ezt vagy építik készségeiket körülötte. De egy kicsit olyan emberekkel kezdődik, akik elég képzettek és elég okosak. Konferenciákon vesznek részt. Tanulnak és intelligens kérdéseket tesznek fel a gyártókkal, és bizonyos esetekben a gyártókkal együtt tanulnak. Mivel a szállítók jönnek és bemutatkoznak az első találkozón, lehet, hogy nem tudnak cuccokat, de együttolvasják, majd elkezdenek játszani.
Ez a kicsi embercsoport a mag, majd növekedni kezd, és most mindenki rájön, hogy az első üzleti felhasználási eset működőképessé válik. Egy hullám kezdődik, és a múlt héten a Spark-csúcstalálkozón láthattuk, hogy egy nagyvállalat, mint például a Capital One, teljes erővel volt ott. A Sparkot választották. Beszéltek róla. Számos embert oktatnak Spark-ban, mert sok esetben felhasználóként is hozzájárulnak ehhez. Ugyanezt látjuk sok-sok nagyvállalattal. Néhány apró, nagyon okos embercsoporttal kezdődik, majd elindul az általános oktatás hulláma, és az emberek tudják, hogy ha egyszer egy magas rangú VP vagy egy rangidős igazgató igazodik egymáshoz, és fogadni akarnak erre a dologra, a szó megkerül és mindannyian elkezdenek felszerezni ezeket a képességeket.
Dez Blanchfield: Biztos vagyok benne, hogy fantasztikus idő van a bajnokok építésében is.
Anand Venugopal: Igen. Nagyon sok oktatást folytatunk, amikor együtt dolgozunk a kezdeti bajnokokkal, és sok-sok képzést tartunk, és nagyszámú vásárlónk számára sok-sok oktatást tartunk, és visszatértünk olyan képzési hullámokra, amelyek sok felhasználót a mainstream felhasználói fázisba vonultak, különösen a Hadoop MapReduce webhelyen. Megállapítottuk, hogy egy nagy hitelkártya-társaságban, amely magunk ügyfele, legalább öt-nyolc különféle képzési programot szállítottunk be. Mindezen termékek ingyenes közösségi kiadásai is rendelkezésre állnak, beleértve a miénket is, homokozódobozokat, amelyeket az emberek letölthetnek, megszokhatnak és oktathatnak magukat.
Dez Blanchfield: Ez minden, ami ma reggel van neked. Nagyon szépen köszönjük. Hihetetlenül érdekes látni, hogy milyen típusú modellek vannak, és milyen használati esetek vannak ma nekünk. Köszönöm.
Anand Venugopal: Nagyszerű. Nagyon köszönöm az emberek.
Rebecca Jozwiak: Köszönjük mindenkinek, hogy csatlakozott hozzánk a Hot Technologies webes közvetítéséhez. Izgalmas volt hallani Dez Blanchfield-től, Dr. Robin Bloor-tól és az Impetus Technologies-től, Anand Venugopal-tól. Köszönöm előadók. Köszönöm a felszólalókat és köszönöm a közönséget. A jövő hónapban újabb Hot Technologies van, szóval keresse meg. Tartalmunkat mindig az Insideanalysis.com oldalon archiválhatja. Sok tartalmat is feltettünk a SlideShare-re és néhány érdekes részletet a YouTube-ra is.
Ez van, srácok. Még egyszer köszönöm és jó napot kívánunk. Viszlát.
