Elvitel: Rebecca Jozwiak házigazda megbeszélte a streaming elemzést 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 cégnél! 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 streaming, központ adatok, 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éneti elemzése, trend elemzése, ezek az élő adatok mozgatják az élő intelligenciát manapság, é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: Tessék.
Dez Blanchfield: Miközben felmegyünk a diákra, hadd fedjek le az alapvető témát.
Meglehetősen magas szinten fogom tartani, é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, hogy belemerüljünk az adatfolyam-feldolgozás részleteibe, valamint a jelenleg kidolgozandó keretekbe, és mit kell érteniük az elemzést ezen a nagy volumenű adatfolyamon.
Csak tisztázni fogjuk, hogy mit értünk az analitikai streaming elemzésével, majd megvizsgáljuk, hogy származhat-e az üzleti érték, mert ez valójában az, amit a vállalkozások keresnek. Arra számítanak, hogy a nép nagyon gyorsan és tömör módon magyarázza meg nekik. Hol lehet származtatni é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éseket, objektíveket és nézeteket az adatokról, amelyeket évszázadok óta dolgozunk nyugalomban, 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 sikerült ezt nagyon gyorsan megtennünk, és sok vasat kipróbálhatnánk a dolgoknál, de még mindig tényleg adatgyűjtést végezünk, tárolunk, majd megnézünk, és valamilyen betekintést vagy elemzést szerezünk róla. 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.
Az adatfolyam-elemzés arról szól, hogy közvetlenül rákattintunk arra az adatfolyamra, míg az adatfolyamok általában nagyon nagy mennyiségű adat és adatfolyam több, nagyon gyorsan és gyorsan mozgásba kerülő adatfolyamát képezik, és betekintést vagy elemzést kapnak ezekről a folyamatokról, 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ést végeztek rajtuk, mivel stream formátumban jönnek be. Nem vagyok egészen biztos benne, miért tettek kormányt a számítógépre, de ez nagyon jó.
Az er 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 ezt láthattuk a webes szereplők kedvelőinek, akiket mindannyian ismerünk, mind háztartási márkák, mint a LinkedIn, és hogy az interaktív viselkedés, amelyet ezekkel a szociális platformokkal viselünk, megköveteli nem csak rögzítés, tárolás és feldolgozás kötegelt módban, hanem valójában menet közben is rögzítik és vezetik az elemzést az átjutó 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 engem. 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 Önt erre az igazán aranyos kis weboldalra egy valós idejű grafikon, aranyos kis hisztogramok és vonal irányítópultján grafikon, amely megmutatja az X azon emberek 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 ezen 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 gondolunk az avionics léptékére, a repülőgépek repülésére, csak az USA-ban napi 18 700 belföldi járat van. 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 termelnek.
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, azaz 43-44 petatates adat jön át, és akkor történik, amíg a repülőgépek a levegőben vannak. Ez történik, amikor leszállnak, és adatcsempét végeznek. Ekkor lépnek be a boltba, és a mérnöki csapatoknak teljes adatmennyiségük van, hogy megnézhessé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, miközben a repülőgép a levegőben volt, vagy a földön van. Csak nem tudja megtenni ezt 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 mi most 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 megy keresztül a szervezeten, és milyen értékéről rendelkezik. 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 olyan 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újt, és ez a testreszabás a használt rendszerben az egyéni tapasztalatokhoz 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 pontosan 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 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 ül a patak közepén. Valós idejű elemzést fog végezni a körülötte zajló eseményekről, hogy valóban megtervezhesse képességét a halak levegőben történő elfogására. 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 adatmennyiség érkezik hozzánk, hanem az is, hogy milyen gyorsan jön. Például a biztonság szempontjából: az összes útválasztó, kapcsoló, szerver, tűzfal és az összes esemény, amely azoktól érkezik, é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. Ehhez eszközöket és rendszereket kell építeni. 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 szervezet esetében ez nem így van. 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 azok minden szektor széles spektrumán megtalálhatók, amelyeket elképzelhet, 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édia platformok, 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 esetében irányítási kihívás van. Nem megfelelő a nap végére jutni, és kideríteni, hogy megszegte 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 velem az adatfolyamukon és az utasításokon, hogy megbizonyosodjanak arról, hogy mit nyújtanak nekem, nem hagyják el a partot. Minden cuccnak helyben kell maradnia. Valós időben kell megcsiná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.
Jelenleg egy tendencia van a kitermelés elvégzésével és a terhelési tevékenység átalakításával a patakokban, így nem akarunk elfogni bármit, ami a patakba megy. Nem igazán tudjuk megcsinálni. 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 nap egy adott időpontjában zöld energiát akarok vásárolni, mert csak egyedül vagyok otthon, és nem nagyon sok eszközt használok. De ha vacsorázom, akkor szeretném, ha az összes készülékemet bekapcsolnám, és nem akarok 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 dolgokra, amelyeket minden nap csinálhat, és mindezt a keresleti árképzés vezérli. 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ési folyamatot valós időben hajtják végre, miközben az autóban megmondják, 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.
Vannak olyan igazán forró témák, 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 megmondja neked, hogy mi vagy valami más támadja meg valós időben és milyen támadásokkal jár. 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árt kaptunk ezeknek a mérnöki csapatoknak és az adatközpontok felépítésének. 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 úgy gondolom, hogy ezt most fogjuk részletesebben tárgyalni.
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 felfogni.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 arra, hogy bármi más fölött és túlmutatjon - az a tény, hogy itt létezik sokféle késés, 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ügghetü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 a Moores-törvény hajtotta végre, és a Moores-törvény körülbelül 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 soha nem vagyunk soha, ami furcsán 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 ezer szorzót kaptunk. Egy helyett három nagyságrendű.
Éppen ez történik, és úgy tűnik, hogy az ipar úgy vagy úgy mozog fantasztikus sebességgel - 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. Amikor a számítógéppel lép kapcsolatba, akkor valóban azt szeretné, ha egy tized-től körülbelül egy másodpercig elkésne. Fentiekben van olyan tranzakció, 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 nem csak várnának a számítógépre. 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ő jelentkezik. 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, így valós időben. 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 alatt elmondom neked.
Ez csak a bolt. Van párhuzamos szoftver. Beszélünk 2004-ben. 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 megjelent, megszereztük a memrisztorot 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 előállítja, az egyes áramköri lapok gyorsabban haladnak, még a végét sem láttuk.
A Streams technológia, amely valójában a következő, 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úránk, azaz az adatfolyamok feldolgozása az adathalmokkal. Amikor ténylegesen feldolgozza a történeti adatokkal beáramló események adatfolyamát 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 a Minden internet, amelyet Dez is megemlített, akkor valójában felismeri, hogy mindenféle adatmeghatározási kérdés merül fel - döntések arról, hogy mit kell feldolgoznod a patakban.
A dolog, amit itt mondok, az az, hogy amikor kötegelt feldolgozást hajtottunk végre, ténylegesen adatfolyamokat dolgoztunk fel. Csak nem tudtuk megcsinálni egyszerre. Csak várunk, amíg nagy halom cucc lesz, majd egyszerre feldolgozzuk. Olyan helyzetbe megyünk, ahol valójában feldolgozhatjuk az adatfolyamot. 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. Úgy tűnik, hogy 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ányan közülünk - ésszerűen udvariasan és nem folyton a dolgokra.
Mindent itt egy idegi analitikai skála készít. 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 ténylegesen meg kell tenni, természetesen táplálják az embert, hogy döntéseket hozzon, és mindezeket megtegye. Hogy látom, itt megyünk.
Ennek egyik következménye az, hogy a streaming alkalmazás szintje jól megy. Szörnyen sokkal több lesz, mint amit most látunk. 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 az Impetus Technologies által kínált termék, 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 elemzési implementációt 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, ezért sok olyan tartalmat kihagyok, amely átfedésben van. 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 is, ami gyorsabb, mint az összes szakaszos folyamat, vállalkozást szerezhet, és nagyon jó érzés, hogy az adatok értéke drámai módon csökken az életkorával, tehát minél nagyobb az érték a kezdeti részben, másodpercben, amint 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 az, amit látunk, az azért van, mert most már lehetséges, és mivel mindenki tudja, hogy a tétel régi, a tétel unalmas és a tétel nem jó. Elég annyi oktatás, hogy mindenki megkapta azt a tényt, hogy streaming lehetséges és mindenkinek van Hadoopja. Most a Hadoop disztribúciókba ágyazott streaming technológia van, akár Storm, akár Spark streaming, és természetesen sorok, 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 sokféle módon megcsináltuk ezt valójában valójában az, hogy valóban megragadjuk a fogyasztó többcsatornás elkötelezettségét valós időben, és nagyon-nagyon érzékeny tapasztalatokat 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?” Nem számít arra, hogy ma, de ez az a tapasztalat, 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 az elemzés streaming-ében 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 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árokon 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ásával és jobb végrehajtásával. 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 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 akár weboldalon vásárol, vagy egy kiskereskedelmi üzletben vesz részt, az üzletben egyszerűen nincs meg az ügyfél, nincs intelligenciája ahhoz, hogy kiszámítsa, amire szüksége lehet. Ezért őrizetbe veszik ü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 erre a konkrét ügyféllel, 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 kábel tartalmat. 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.
Belépünk a következő kérdésbe: „Melyek a streaming analitika építészeti szempontjai?” Végül is 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 azokat. A Sigma ezt teszi lehetővé. Ma mind a tételes architektúra és a vállalati kép megvan. Valamely BI-verembe és hasznosítási verembe válogatunk, és hozzáadva a Lambda architektúrát. Mivel a sebességréteg vagy az igény és a Lambda az, hogy összekapcsoljuk ezt a két felismeré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úra nevű paradigma, amelyet javasolnak, ahol az a feltételezé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 hozzászoktunk, 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 itt lenne Hadoop, MPP-k és már vannak adattárházai.
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 viszonyok szerint é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ő. Bekerül a sorokba, majd bejut 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. 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ábbvitelének más alkalmazásait.
Ez a teljes halom balról jobbra megy. 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. 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ásodperces késésről beszélünk, tíz vagy akár száz ezredmásodpercrő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őre, valamint késésekre, amelyek talán néhány másodperc, három, 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 védelemnek több motorral kell rendelkeznie, egy felhasználói élmény mellett, és ezt próbáljuk építeni a StreamAnalytix programban.
Csak egy gyors áttekintés az építészetről. Kicsit átdolgozzuk, de alapvetően a bal oldalon többféle adatforrás érkezik - Kafka, RabbitMQ, Kinesis, ActiveMQ, ezek az összes adatforrás és sor várhatóan az adatfolyam-feldolgozási platformon érkeznek, ahol ö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 az egyetlen iparág és az első vállalati szintű streaming platform, 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 a teljes mantra a StreamAnalytix-ben.
Ezzel azt hiszem, hogy 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ű, rendben. 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. Vissza fogom helyezni a fejhallgatót, hogy hallhasson. 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 mondanám 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 zökkenőmentes felhasználói élményre tervezték őket, mint például a Bank of America, a Verizon vagy az AT&T, így hetek alatt telepíthetnek egy streaming elemző alkalmazást. Biztosan nem erre tervezték. Ez az oka annak, hogy belépünk. Összehozzuk és könnyen megértjük, telepítjük 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: Nos, ennek nagy részében szakértői csoportokkal kell rendelkeznie a fedélzeten. Úgy értem, hogy azt sem tudom, hol 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: Látunk példákat mindkettőre, 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, kérdése van?
Anand Venugopal: Dez valószínűleg néma.
Dez Blanchfield: Elnézést, 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, amelyekkel ilyen módon megismerkedtél vagy átvágtál? Tudom, hogy ma reggel óriási látogatáson megyünk részt, és egy dolog, amiben biztos vagyok, mindenki gondolkodik: „Hogyan vághatom át az egész kihívást jelentő réteget az igazgatótanácsról a vezetői szintre, ó, túl nyílt forrású és túl vérző széle? "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ú megoldások felé mozognak. 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ágosabban 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 nemzedék mögött vannak az izgalmas dolgok valamilyen vérző vonala mögött, amiről itt beszélünk, és nem értem, hogy ez negatív csekély tényező. Csak a valóság az, hogy kaptak egy generációt és egy utat, hogy átmenjenek, hogy kiadják azt, amit stabil platformon tartanak, a régi iskola fejlesztését és az UATN integrációs ciklusait, teszteléseit és dokumentációját, valamint a marketingt és az értékesítést. 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 őket, 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.
Tudna-e nekünk néhány példát bemutatni az olyan határ-vertikumokró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 korrelálják, hogy az adott ügyfél set-top boxjával 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, létezik ez a jelzálog-társaság, amely ismét egy á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 olyan 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, hitelfeldolgozá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, amely azt mondja: „Hé, ez a kapu a repülőgép számára a repüléshez. 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: 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, akiket azonosítottak, de ezek azok a technológiai csapatok, amelyek felkészülnek a bekövetkező üzleti célú támadásokra, és miután felépítették 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 valós időben a patakok vagy a hozzászólások üledékeit, vagy először ki kell szűrni?
Anand Venugopal: A termékek és technológiák, amelyekről nagyon gyorsan beszéltünk, támogatják a strukturált és a strukturálatlan adatokat is. Ezek konfigurálhatók. Minden adatnak van valamilyen felépítése, legyen az a vagy 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 a patakba az adatfolyamot. 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 tranzakciós rendszerek 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 a Kudu, és a memóriában lévő adatbázisok, amelyek egyszerre támogatják mind a tranzakciókat, mind az analitikus feldolgozást. Az adatfolyam-feldolgozó réteg teljes mértékben a memóriában lenne, és megvizsgáljuk ezen tranzakciós adatbázisok némelyikét, vagy kapcsolódhatunk 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: Be fogok ugrani egy utolsó kérdésbe, és ezt felvágom, 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 tevékenységeket tudnak tenni a szervezetet az ilyen jellegű keretrendszerre való áttérés körül, és meglévő műszaki személyzetüket az IT-től a vezérigazgatótól retoolizálják, hogy ők maguk is működtethessék ezt, miután összeállították és bevezették? Nagyon 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 számú ember, aki megpróbál elmenni és megvásárolni egy streaming analitikai platformot, már ésszerűen intelligens abban az értelemben, hogy Hadoop tudatában van, már megszerezte Hadoop MapReduce készségeit, és mivel szorosan együttműködik a Hadoop disztribúciós szolgáltatóval, vagy ismerik őket. 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 elkezdik felszerezni ezeket a képességeket.
Dez Blanchfield: Biztos vagyok benne, hogy fantasztikus idő van a bajnokok felépítésére is.
Anand Venugopal: Igen. Nagyon sok oktatást végezünk, 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 és hullámokra, amelyek sok felhasználót a mainstream felhasználási szakaszba vezettek, 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 és használati esetek vannak ma nekünk. Köszönöm.
Anand Venugopal: Nagy. 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.