У дома звуков Използване на firehose: получаване на бизнес стойност от поточна анализа: препис на уебинар

Използване на firehose: получаване на бизнес стойност от поточна анализа: препис на уебинар

Anonim

От служители на Техопедия, 24 февруари 2016 г.

Отнемане: Домакинът Ребека Йозвяк обсъжда поточната анализа с най-добрите експерти в индустрията.

В момента не сте влезли. Моля, влезте или се регистрирайте, за да видите видеото.

Ребека Йозвяк: Дами и господа, здравей и добре дошли в горещите технологии на 2016 г.! Днешното заглавие е „Впрягане на Firehose: Получаване на бизнес стойност от Streaming Analytics.“ Това е Ребека Джозвяк. Аз съм вторият по команда за водещ на уебкасти, когато нашият скъп Ерик Кавана не може да бъде тук, така че е хубаво да видим толкова много от вас днес там.

Този епизод е малко по-различен от другите ни. Ние някак си говорихме какво е горещо и разбира се тази година е гореща. Последните няколко години бяха горещи. Винаги излизат нови неща. Днес говорим за поточна анализа. Самата поточна анализа е нещо ново. Разбира се стрийминг, централни данни, RFID данни, те не са непременно нови. Но в контекста на архитектурата на данни, ние бяхме толкова фокусирани върху данните в покой от десетилетия. Бази данни, файлови системи, хранилища на данни - всичко това е предназначено предимно за пакетна обработка. Но сега с преминаването към създаване на стойност от поточни данни, емоции от данни, някои го наричат ​​живи потоци, те наистина изискват архитектура, базирана на потоци, а не данни в покойни архитектури, с които сме свикнали и които трябва да са способни боравене с бързо поглъщане, обработка в реално време или почти в реално време. Трябва да може да се погрижи не само за Интернет на нещата, но и за Интернет на всичко.

Разбира се, в идеалния случай би било хубаво двете архитектури да живеят една до друга, едната ръка да мие другата, така да се каже. Докато данните за дни, данни за седмици, данни за години все още имат стойност, исторически анализи, анализ на тенденциите, тези данни на живо са тези, които движат интелигентността на живо в наши дни и затова поточната анализация стана толкова важна.

Говоря повече за това днес. Имаме нашия учен с данни, Дез Бланчфийлд, който се обажда от Австралия. В момента е рано сутрин за него. Имаме наш главен анализатор, д-р Робин Блур. Към нас се присъединява Anand Venugopal, продуктов ръководител за StreamAnalytix в Impetus Technologies. Те наистина са фокусирани върху поточната аналитична страна на това пространство.

С това ще продължа и ще го предам на Dez.

Дез Бланчфийлд: Благодаря. Трябва да хвана контрола върху екрана тук и да изскоча напред.

Ребека Йозвяк: Ето.

Дез Бланчфийлд: Докато ние грабваме слайдовете нагоре, нека само да разгледам основната тема.

Ще го държа на доста високо ниво и ще го поддържам приблизително до 10 минути. Това е много голяма тема. Участвах в събитие, в което прекарахме два до три дни, гмуркайки се в подробностите за това какво е обработка на потоци и текущите рамки, които разработваме и какво трябва да означава анализирането в тези потоци с голям обем.

Просто ще изясним какво имаме предвид чрез поточна анализа и след това ще се задълбочим дали бизнес стойността може да бъде получена, защото това наистина е това, което бизнесът търси. Те търсят хората да им обясняват много бързо и кратко, къде мога да извлека стойност, като прилагам някаква форма на анализи към нашите поточни данни?

Какво представлява поточната анализа?

Поточната аналитика дава на организациите начин да извлекат стойност от данните с голям обем и висока скорост, които получават през бизнеса в различни форми в движение. Съществената разлика тук е, че имахме дълга история на разработване на анализи и обективи и изгледи на данни, които обработваме в покой от десетилетия от създаването на мейнфрейм. Мащабната промяна в парадигмата, която наблюдаваме през последните три до пет години при това, което наричаме „уеб мащаб“, е проникване в потоците от данни, постъпващи в нас в реално време или близо до реално време, а не просто обработка и търсене на корелация на събитията или задейства събитие, но извършва наистина подробна и задълбочена анализа в тези потоци. Това е значително изместване към това, което правихме преди, или е събиране на данни, поставянето им в някакво хранилище, традиционно големи бази данни сега, големи големи рамки за данни като платформата Hadoop и извършване на обработка на пакетни режими за това и получаване някакъв вид прозрение.

Много добре се справихме с това много бързо и опитваме много тежко желязо в нещата, но все още наистина събираме данни, съхраняваме и след това ги разглеждаме и получаваме някаква информация или анализи за това. Преминаването към извършване на тези аналитични данни, докато данните се предават, беше много нова и вълнуваща област на растеж за видовете неща, които се случват около големи данни. Той изисква съвсем различен подход за просто улавяне, съхраняване и обработка и извършване на анализи.

Един от основните двигатели за смяната и фокуса към извършване на анализи в потока е, че можете да спечелите значителна бизнес стойност от получаването на тези прозрения по-бързо и по-лесно, докато данните ви идват, тъй като информацията се предоставя на бизнеса. Идеята за извършване на обработка в края на деня вече не е актуална в някои отрасли. Искаме да можем да правим анализите в движение. До края на деня вече знаем какво се е случило, както се е случило, а не да стигнем до края на деня и да вършим денонощна партидна работа и да получите тези прозрения.

Анализът на потока е свързан с проникването право в този поток, докато потоците от данни обикновено са множество потоци с много голям обем данни и данни, идващи при нас в движение много, много бързо и получаване на прозрения или анализи за тези потоци, докато те ни идват за разлика за да се позволи това да излиза в покой и да се извършва анализ на тях.

Както споменах, имахме десетилетия и десетилетия да изпълняваме това, което наричам партийна анализа. Сложих тук наистина страхотна снимка. Това е снимка на джентълмен, стоящ пред ограбен компютър, създаден от RAND Corporation преди цял живот и това е, което те са гледали на компютър в къща. Интересното е, че дори тогава те са имали тази концепция за всички тези малки циферблати и тези циферблати представляват информация, която идва от къщата и се обработва в реално време и ви казва какво се случва. Прост пример е набор от барометрично налягане и температура, които можем да видим къде виждаме какво се случва в реално време. Но си въобразявам, че още тогава, когато RAND Corporation сложиха този малък макет заедно, те всъщност мислеха вече за обработка на данни и извършване на анализи върху нея, тъй като влиза в формат на потока. Не съм съвсем сигурен защо поставят волан на компютъра, но това е доста готино.

От изобретението на принтера имахме оглед на заснемане на данни и извършване на анализи на партиди върху него. Както вече казах с голямата промяна сега и видяхме това от харесванията на играчите в уеб мащабите, които всички познаваме, всички те са домакински марки като Twitter, Facebook и LinkedIn, това интерактивно поведение, което имаме с тези социални платформите изискват не просто улавяне, съхраняване и след това обработка в пакетен режим, но всъщност те улавят и задвижват анализи в движение от потоците от данни, постъпващи през тях. Когато щракнете върху нещо, те не само трябва да го заснемат и съхраняват и да направят нещо по-късно, но и трябва да могат да го поставят веднага обратно в потока ми и да го споделят с други хора, които ме следват. Това е модел за пакетна обработка.

Защо щяхме да слизаме по този маршрут? Защо организациите биха инвестирали време, усилия и пари, дори да обмислят предизвикателството да се стремят по пътя на поточната анализа? Организациите имат това огромно желание да получат печалба в сравнение с конкурентите си в отраслите, в които се намират, и че печалбата на производителността може да бъде бързо реализирана чрез проста поточна анализа и може да започне с просто проследяване на данните в реално време, които вече сме запознат с. Имам малко екранна снимка на Google Analytics. Вероятно това е един от първите пъти, когато наистина използваме практическата анализа на потребителите. И тъй като хората посещаваха уебсайта ви и получавате броя на посещенията, с малко парче JavaScript в долната част на уеб страницата ви в HTML, вграден във вашия уебсайт, тези малки кодове се правеха в реално време обратно в Google и те бяха извършване на анализи на тези потоци от данни, идващи от всяка страница на вашия уебсайт, всеки обект на вашия уебсайт в реално време и те ви го изпращат обратно в тази наистина сладка малка уеб страница в табло за управление на графиката в реално време, сладки малки хистограми и линейна графика, показваща ви X брой хора, които са посетили страницата ви исторически, но ето колко са в момента.

Както можете да видите на тази екранна снимка, тя казва 25 в момента. Това са 25 души в момента на тази снимка на тази страница. Това е първият реален шанс, който играхме на инструмента за анализ на потребителите. Мисля, че много хора наистина го получиха. Те просто разбраха силата да знаят какво става и как могат да отговорят на това. Когато мислим за мащаба на авиониката, самолетите, които летят наоколо, има само 18 700 вътрешни полета на ден само в САЩ. Прочетох книга преди време - беше преди около шест или седем години - че количеството данни, което се произвеждаше от тези самолети, беше около 200 до 300 мегабайта в стария инженерен модел. В днешните дизайни на самолети тези самолети произвеждат около 500 гигабайта данни или около половин терабайт данни на полет.

Когато правите математиката много бързо от върха на главата си, че 18 700 вътрешни полети на всеки 24 часа само във въздушното пространство на САЩ, ако всички съвременни самолети произвеждат около половин терабайт, това е от 43 до 44 петабайта данни, идващи през и това се случва, докато самолетите са във въздуха. Това се случва, когато кацат и те правят изхвърляне на данни. Тогава те влизат в магазина и имат пълно изхвърляне на данни от инженерните екипи, за да разгледат какво се случва в лагерите, колелата и вътре в двигателите. Някои от тези данни трябва да бъдат обработвани в реално време, за да могат да вземат решения, ако има истински проблем, докато самолетът е бил във въздуха или докато е на земята. Просто не можете да направите това в пакетен режим. В други индустрии, които виждаме там, около финанси, здравеопазване, производство и инженеринг, те също разглеждат как могат да получат с този нов поглед върху случващото се в реално време, за разлика от това, което просто се съхранява в базите данни на термин.

Съществува и тази концепция за работа с данни като това, което наричам нетрайна стока или нетрайна стока - че много данни губят стойност с течение на времето. Това все повече се случва с приложенията за мобилност и инструментите за социални медии, защото това, което хората казват и това, което е в тенденция сега, е това, което искате да отговорите. Когато мислите за други части от нашия живот с логистика и доставка на храна наоколо, ние разбираме концепцията за нетрайна стока в този смисъл. Но помислете за данните, които минават през вашата организация и стойността, която тя има. Ако някой прави някакъв бизнес с вас в момента и можете да взаимодействате с тях в реално време, не искате да чакате час, за да могат данните да бъдат заснети и поставени в система като Hadoop и след това да натиснете този бутон, няма да можете да се справите с него в момента и искате да можете да го направите по желание на клиента веднага. Има термин, който ще видите, че се появява много сега, където хората говорят за това, че има в реално време поток от данни, който може да ви даде персонализация, и тази настройка на персонализацията в системата, която използвате, към вашия индивидуален опит. Така че когато натиснете например инструмент като Google Search, ако аз направя заявка и вие направите същото, неизменно, ние не получаваме същите данни. По същество получаваме това, което наричам опит за знаменитост. Лекувам се еднократно. Получавам моя лична версия на случващото се в тези системи въз основа на профилите и данните, които са събрали върху мен и бях в състояние да направя анализи в реално време в потока.

Тази идея данните да са нетрайна стока за сега е истинско нещо и стойността на данните намалява с течение на времето е нещо, с което трябва да се справим днес. Това не е нещо от вчера. Обичам тази снимка на мечка, хващаща сьомга, която скача от реката, защото тя наистина рисува точно това, което виждам в поточната анализа. Това е тази масивна река от данни, която идва при нас, огън, ако щете, а мечката седи насред рекичката. Той ще извършва анализи в реално време върху случващото се около него, така че всъщност да може да разработи способността си да улавя тази риба във въздуха. Не е просто да потопите в потока и да вземете такъв. Това нещо скача във въздуха и трябва да бъде на точното място в точното време, за да улови тази риба. В противен случай той не получава закуска или обяд.

Една организация иска да направи същото с техните данни. Те искат да извлекат стойност от сегашните масивни обеми от данни в движение. Те искат да извършат анализи на тези данни и данни за висока скорост, така че не е само количеството данни, което идва при нас, но това е скоростта, с която идва от това. Например в областта на сигурността, всички ваши маршрутизатори, комутатори, сървъри, защитни стени и всички събития, които идват от тези и десетки хиляди, ако не и стотици хиляди устройства, в някои случаи са нетрайни данни. Когато мислим за това в Интернет на нещата и индустриалния Интернет, говорим за милиони ако не милиарди сензори в крайна сметка и тъй като данните идват през които извършва анализи, сега разглеждаме как да обработваме сложни събития със заповед и величина, каквито никога досега не сме виждали и днес трябва да се справим с това. Трябва да изграждаме инструменти и системи около това. Това е истинско предизвикателство за организациите, тъй като от една страна ние имаме много големите марки, които правят „Направи си сам“, изпечете го сами, когато имат капацитет за това и набор от умения и инженерство. Но за обикновената организация това не е така. Те нямат набор от умения. Те нямат капацитет, нито време, нито дори пари, за да инвестират в това. Всички те се стремят към тази концепция за вземане на решения в реално време.

Използвайте случаи, на които попаднах, и те са във всеки широк спектър от всеки сектор, който можете да си представите, хората седят и обръщат внимание и казват: как да приложим някои аналитични данни към нашите поточни данни? Говорим за онлайн услуги в мащаб. Има традиционните платформи за социални медии и онлайн електронни опашки и продажби на дребно - приложения например. Всички те се опитват да ни дадат това изживяване на знаменитости в реално време. Но когато попаднем в повече от услугите за технологичен стек, телефонни услуги, глас и видео, виждам хора да се разхождат да правят FaceTime по телефони. Просто избухва. Смята се, че хората държат телефона пред себе си и говорят с видеопоток на приятел, а не да го държат до ухото си повече. Но те знаят, че могат да го направят и се адаптираха и им хареса това преживяване. Разработването на тези приложения и платформите, които ги доставят, трябва да извършват анализи в реално време на този трафик и на профилите на трафика, така че да могат да правят прости неща като маршрутизиране на това видео перфектно, така че качеството на гласа в видеоклипът, който получавате, е адекватен, за да получите добро изживяване. Не можете да обработвате такъв тип данни. Това не би направило видео потока в реално време функционална услуга.

Във финансовите транзакции има предизвикателство за управление. Не е добре да стигнете до края на деня и да разберете, че сте нарушили закона, движейки лични данни около мястото. В Австралия имаме много интересно предизвикателство, при което преместването на данни, свързани с поверителността в офшорката, е не-не. Не можете да вземете моя PID, моите лични лични данни за идентификация в офшорка. В Австралия има закони, които да спрат това да се случва. По-специално доставчиците на финансови услуги със сигурност, правителствени услуги и агенции, те трябва да правят анализи в реално време на своите потоци от данни и инструкции с мен, за да са сигурни, че това, което ми предоставят, не напуска бреговете. Всички неща трябва да останат на място. Те трябва да го правят в реално време. Те не могат да нарушат закона и да поискат прошка по-късно. Откриване на измами - това е доста очевидно, за което чуваме при транзакции с кредитни карти. Но тъй като видовете транзакции, които извършваме във финансовите услуги, се променят много, много бързо, има много неща, които PayPal прави първо сега, когато открива измама в реално време, когато парите не се движат от едно нещо към друго, но са финансова транзакция между системите. Платформите за офериране на Ebay, откриването на измами трябва да се извършва в реално време в стрийминг офис.

Има тенденция, която се движи към извършване на извличане и трансформиране на натоварваща активност в потоците, така че не искаме да улавяме нищо, което отива в потока. Наистина не можем да направим това. Хората са научили, че данните обичат да се разбиват наистина бързо, ако заснемем всичко. Номерът сега е да извършвате анализи на тези потоци и да правите ETL върху него и просто улавяте това, от което се нуждаете, потенциално метаданни и след това задвижвайте прогнозна анализа, където всъщност можем да кажем какво ще се случи малко по-надолу по пътищата на това, което ние току-що видях в потока въз основа на анализите, които направихме по този въпрос.

Доставчиците на енергия и комунални услуги изпитват това огромно желание от страна на потребителите да ценообразуват търсенето. Може да реша, че искам да купувам зелено захранване по едно конкретно време на деня, защото съм само вкъщи и не използвам много устройства. Но ако имам вечеря, може би искам да имам всичките си устройства и не искам да купувам евтина мощност и да чакам да бъде доставена, но съм готов да платя за повече разходи, за да получа тази мощност. Това ценообразуване на търсенето, особено в комуналните и енергийното пространство, вече се е случило. Uber например е класически пример за неща, които можете да правите всеки ден и всичко това се ръководи от ценообразуването на търсенето. Има някои класически примери, че хората в Австралия получават такси за 10 000 долара заради масовото търсене в новогодишната нощ. Сигурен съм, че са се занимавали с този проблем, но анализа на потока, който се извършва в реално време, докато сте в колата, казвайки колко трябва да платя.

Интернет на нещата и сензорни потоци - току-що само надраскахме повърхността по това и наистина просто проведохме основния разговор по този въпрос, но ще видим интересна промяна в това как технологията се справя с това, защото когато говориш не почти хиляди или десетки хиляди, но стотици хиляди и потенциално милиарди устройства, предаващи към вас, почти никой от технологичните стекове, които имаме сега, не са проектирани да се справят с това.

Има някои наистина горещи теми, които ще видим около мястото като сигурност и кибер риск. Те са много истински предизвикателства за нас. Има наистина чист инструмент, наречен Север в мрежата, където можете да седнете и гледате в уеб страница различни кибератаки, случващи се в реално време. Когато го погледнете, си мислите, "о, това е хубава сладка малка уеб страница", но след около пет минути там, вие осъзнавате обема данни, който системата прави анализи във всички различни потоци на всички различни устройства по света които се подават в тях. Той започва да заблуждава съзнанието как те изпълняват това в края на този запис по същество и ви предоставя онзи прост малък екран, който ви казва какво или нещо друго, което го атакува в реално време и какви видове атаки. Но това е наистина чист малък начин просто да получите добър вкус на това, което анализа на потока потенциално може да направи за вас в реално време, като просто гледате тази страница и усетите само обема и предизвикателството да вземете потоците, да обработите аналитични заявки на тях и представляващи това в реално време.

Мисля, че разговорът, който имам за останалата част от сесията, ще се справи с всички онези видове неща с един интересен изглед от моя гледна точка и това е предизвикателството на Направи си сам, изпечи го сам, подхожда на някои от класически еднорози, които са в състояние да си позволят да строят тези видове неща. Те имат милиарди долари за изграждането на тези инженерни екипи и за изграждането на техните центрове за данни. Но за 99, 9% от организациите там, които искат да постигнат стойност в своя бизнес на поточна анализа, те трябва да получат извънредовна услуга. Те трябва да купуват продукт извън кутията и обикновено се нуждаят от консултантска услуга и професионална услуга, която да им помогне да го реализират и те да получат тази стойност обратно в бизнеса и да го продадат обратно на бизнеса като работно решение.

С това ще ви върна, Ребека, защото вярвам, че това ще разгледаме подробно сега.

Ребека Йозвяк: Отлично. Благодаря ти много, Дез. Това е страхотно представяне.

Сега ще предам топката на Робин. Отнеси го.

Робин Блур: Добре. Тъй като Дез е влязъл в азотна песъчинка за обработка на потоци, не ми се струваше смисъл да го покривам отново. Така че просто ще взема напълно стратегическо мнение. Гледайки почти от много високо ниво на това, което става по дяволите, и позиционирането му, защото мисля, че това може да помогне на хората, особено на нас, които не сме вградени в потоци, обработващи на голяма дълбочина преди.

Обработката на потоци е от доста време. Наричахме го CEP. Преди това имаше системи в реално време. Оригиналните системи за контрол на процесите всъщност обработваха потоци от информация - разбира се, нищо не вървеше до сега. Тази графика, която виждате на слайда тук; всъщност посочва много неща, но посочва отгоре и отвъд всичко друго - фактът, че тук има спектър закъснения, които се появяват в различни цветове. Това, което всъщност се е случило след изобретяването на компютърните или търговските изчисления, пристигнали точно около 1960 г., е, че всичко е станало все по-бързо и бързо. Ние бяхме в състояние да зависи от начина, по който това всъщност излиза, ако харесвате на вълни, защото така изглежда. Това всъщност зависи от него. Тъй като всичко бе водено от закона на Мур и законът на Мур ще ни даде фактор с около десет пъти по-голяма скорост за период от около шест години. Тогава след като всъщност стигнахме до около 2013 г., всичко се счупи и изведнъж започнахме да се ускоряваме със скорост, която никога не сме, което е странно безпрецедентно. Получавахме коефициент от около десет по отношение на увеличаване на скоростта и следователно намаляване на латентността на всеки шест години. За шестте години от около 2010 г. сме получили кратно най-малко хиляда. Три порядъка, а не един.

Това е, което се случва и затова индустрията по един или друг начин изглежда се движи с фантастични скорости - защото е така. Тъкмо преминавайки през смисъла на тази конкретна графика, времето за реакция всъщност е в алгоритмичен мащаб надолу по вертикалната ос. В реално време е компютърната скорост, по-бърза от човешките същества. Интерактивните времена са оранжеви. Когато взаимодействате с компютъра, това е мястото, където наистина искате от една десета до около една секунда закъснение. По-горе има транзакция, в която всъщност мислим какво правите в компютъра, но ако това изчезне за около петнадесет секунди, става непоносимо. Хората всъщност просто няма да чакат компютъра. Всичко беше направено на партида. Много неща, които бяха направени на партида, сега се спускат право в транзакционното пространство, право в интерактивното пространство или дори в пространството в реално време. Докато преди това вълнообразен с много малки количества данни бихме могли да направим част от това, сега можем да направим с много големи количества данни, използвайки изключително мащабирана среда.

Така че в общи линии всичко това казва, че наистина са времената за реакция и интерактивна реакция на човека. Ужасно много от това, което се прави с потоци в момента, е да се информират хората за нещата. Някои от тях вървят по-бързо от това и информират добре нещата, така че е в реално време. Тогава ние вземаме лиценз просто да паднем като камък, което прави мигновената анализа осъществима и между другото доста достъпна. Не само скоростта е спаднала, а горната част също е срутена. Вероятно най-голямото въздействие във всички тях сред всички различни приложения, можете да направите всички тези аналитични прогнози. Ще ви кажа защо след минута.

Това е само магазина за хардуер. Имате паралелен софтуер. Говорим за 2004 г. Разширена архитектура, многоядрени чипове, увеличаване на паметта, конфигурируем процесор. SSD дисковете сега вървят толкова по-бързо от въртящия се диск. Можете до голяма степен да се сбогувате с въртящ се диск. SSDs също са в няколко ядра, така че отново по-бързо и по-бързо. Скоро да се появи, ние получихме метристора от HP. Имаме 3D XPoint от Intel и Micron. Обещанието на тези е, че така или иначе всичко ще стане по-бързо и по-бързо. Когато всъщност мислите за две нови технологии за памет, и двете от които ще направят цялостното основно парче, отделната платка върви много по-бързо, ние дори не сме виждали края на това.

Технологията Streams, която е следващото съобщение наистина е тук, за да остане. Ще трябва да има нова архитектура. Искам да кажа, че Дез някак спомена това в няколко точки в своето представяне. В продължение на десетилетия ние разглеждахме архитектурата като комбинация от масиви от данни и данни. Ние сме склонни да обработваме групите и сме склонни да изпращаме данните между групите. Сега основно се придвижваме към това, което наричаме архитектура на данни Lambda, която комбинира обработката на потоци от данни с групи данни. Когато всъщност обработвате поток от събития, влизащи срещу исторически данни, като поток от данни или купчина данни, това имам предвид под Lambda архитектурата. Това е в началото. Това е само част от картината. Ако смятате нещо толкова сложно като Интернет на всичко, което Dez също спомена, всъщност ще разберете, че има различни видове проблеми с местоположението на данните - решения за това, което трябва да обработите в потока.

Нещото, което тук наистина казвам е, че когато обработвахме на партида, всъщност обработвахме потоци. Просто не можехме да го правим един по един. Просто изчакваме, докато има голяма купчина неща и след това ги обработваме наведнъж. Преминаваме към ситуация, в която всъщност можем да обработваме неща в потока. Ако можем да обработим нещата в потока, тогава групите от данни, които притежаваме, ще бъдат статичните данни, на които трябва да се справим, за да обработим данните в потока.

Това ни отвежда към това конкретно нещо. Споменах това преди в някаква презентация с биологичната аналогия. Начинът, по който бих искал да помислите, е в момента, в който сме хора. Имаме три различни мрежи за прогнозна обработка в реално време. Те се наричат ​​соматични, автономни и ентерични. Ентерикът е вашият стомах. Вегетативната нервна система се грижи за бой и полети. Всъщност се грижи за бързите реакции на околната среда. Соматичното, което се грижи за движението на тялото. Това са системи в реално време. Интересното в него - или мисля, че е нещо интересно - е, че много от тях са по-предсказващи, отколкото бихте си представили. Сякаш всъщност гледате екран на около 18 инча от лицето си. Всичко, което можете да видите ясно, всичко, на което тялото ви е способно да вижда ясно, всъщност е около 8 × 10 правоъгълник. Всичко извън това всъщност е замъглено, що се отнася до тялото ви, но умът ви всъщност попълва пропуските и го прави не замъглено. Въобще не виждате замъгляване. Виждате го ясно. Умът ви всъщност прави предсказуем метод на потока от данни, за да видите тази яснота. Това е нещо любопитно, но всъщност можете да разгледате начина, по който нервната система функционира, и начина, по който успяваме да заобиколим и да се държим разумно - поне някои от нас - разумно здравомислещи и да не се натъкваме на нещата през цялото време.

Всичко е направено от серия скала на невралната анализа тук. Това, което ще се случи е, че организациите ще имат един и същи вид и ще изграждат един и същи вид и ще бъдат обработването на потоци, включително вътрешните потоци на организацията - нещата, които се случват в то, нещата, които се случват извън него, мигновените отговори, които всъщност трябва да бъдат взети, разбира се, подхранват човешкото същество да взима решения, да прави всичко това. Натам тръгваме, доколкото виждам.

Едно от нещата, което е следствие от това, е, че нивото на приложението за стрийминг върви добре. Ще има ужасно много повече, отколкото виждаме сега. В момента ние берем ниско висящия плод да правим очевидните неща.

Така че така или иначе това е заключението тук. Поточната аналитика някога е ниша, но тя става мейнстрийм и скоро ще бъде приета като цяло.

С това ще го предам обратно на Ребека.

Ребека Йозвяк: Благодаря ви много, Робин. Страхотна презентация, както обикновено.

Ананд, ти си следващ. Подът е ваш.

Ананд Венугопал: Фантастичен. Благодаря ти.

Казвам се Ананд Венугопал и съм ръководител на продукта за StreamAnalytix. Това е продукт, предлаган от Impetus Technologies, извън Лос Гатос, Калифорния.

Impetus всъщност имаше голяма история в това да бъде доставчик на решения за големи данни за големи предприятия. Така че всъщност направихме редица поточни реализации на анализи като компания за услуги и научихме много уроци. През последните няколко години също направихме промяна към превръщането в продуктова компания и компания, ориентирана към решенията, а поточната аналитика е насочена към превръщането на Impetus в компания, която е до голяма степен ориентирана към продукти. Има някои критични, много, много ключови активи, които Impetus изчисти благодарение на излагането ни на предприятия и StreamAnalytix е един от тях.

Ние сме 20 години в бизнеса и има страхотна комбинация от продукти и услуги, което ни прави огромно предимство. И StreamAnalytix се роди от всички научени уроци от първите ни пет или шест реализации на стрийминг.

Ще засегна няколко неща, но анализаторите, Дез и Робин, свършиха фантастична работа по покриването на пространството като цяло, така че ще пропусна много съдържание, което се припокрива. Сигурно ще отида бързо. Освен истинските случаи на поточно предаване, използваме много просто пакетно ускорение, където има буквално много, много важни пакетни процеси в предприятията. Както можете да видите, целият този цикъл на усещане на дадено събитие и анализ и действие върху него всъщност може да отнеме седмици в големите предприятия и всички те се опитват да го свият до минути, а понякога секунди и милисекунди. Така че всичко по-бързо от всички тези партидни процеси са кандидати за бизнес придобиване и това е много добре казано, че стойността на данните драстично намалява с възрастта му, така че колкото повече стойност има в началната част за секундите, че току-що се е случило. В идеалния случай, ако можете да предвидите какво ще се случи, това е най-високата стойност. Това обаче зависи от точността. Следващата най-висока стойност е, когато е точно там, когато се случва, можете да я анализирате и да отговорите. Разбира се, стойността драстично намалява след това, основният ограничителен BI, в който се намираме.

Интересно е. Може да очаквате драматично научен отговор на въпроса защо стрийминг аналитиката. В много случаи това, което виждаме е, защото това е възможно и защото всички знаят, че партидата е стара, партидата е скучна и партидата не е готина. Има достатъчно образование, което всички са имали сега относно факта, че е възможно стрийминг и всички имат Hadoop сега. Сега дистрибуциите на Hadoop имат вградена технология за стрийминг в нея, независимо дали това е Storm или Spark streaming и разбира се опашки за съобщения, като Kafka и т.н.

Предприятия, които виждаме, скачат в него и започват да експериментират с тези случаи и виждаме две широки категории. Единият има нещо общо с анализа на клиентите и опита на клиента, а вторият - оперативно разузнаване. Ще се запозная с някои подробности по този въпрос малко по-късно. Цялото ъгъл на обслужване на клиентите и опит на клиентите и ние от Impetus StreamAnalytix направихме това по много различни начини е наистина всичко наистина, наистина улавяйки многоканалното ангажиране на потребителя в реално време и им предоставяме много, много контекстно чувствителни преживявания които не са често срещани днес. Ако сърфирате в мрежата, на уебсайта на Банката на Америка и изследвахте някои продукти и просто се обаждате в кол центъра. Биха ли казали: „Ей Джо, знам, че проучвахте някои банкови продукти, бихте ли искали да ви попълня?“ Не очаквате това днес, но това е видът опит, който е наистина възможен при поточната анализа. В много случаи това прави огромна разлика, особено ако клиентът е започнал да проучва начините да излезе от договора си с вас, като погледне клаузите за предсрочно прекратяване или условията за предсрочно прекратяване на уебсайта си, след което се обадете и вие сте в състояние да не директно да се сблъскате с тях за това, но просто косвено да направите оферта за някакъв вид първа промоция, защото системата знае, че този човек гледа на предсрочно прекратяване и вие правите тази оферта в този момент, можете много добре да защитите този бърз клиент и да защитите този актив,

Това е един пример, плюс много услуги за клиенти са много добри примери. Ние прилагаме днес намалява разходите в кол центъра, както и предоставя драматични възхитителни преживявания на клиентите. Dez свърши чудесна работа в обобщаването на някои от случаите на употреба. Можете да се вгледате в тази диаграма за няколко минути. Класифицирах го като вертикали, хоризонтали и комбинации, IoT, мобилно приложение и кол център. Всички те са вертикални и хоризонтални. Зависи как го гледаш. Отдолу виждаме голяма част от хоризонталните приложения, които са доста често срещани във вертикалите на индустрията и има случаи на специфична вертикална употреба, включително финансови услуги, здравеопазване, телеком, производство и др. Ако наистина си задавате въпроса или си казвате че „о, не знам какви случаи на употреба има. Не съм сигурен дали наистина има някаква стойност на бизнеса в поточната анализация за моята компания или за нашето предприятие, ”помислете упорито, помислете два пъти. Говорете с повече хора, защото има случаи на употреба, които във вашата компания са актуални днес. Ще вляза в стойността на бизнеса за това как точно се извлича бизнес стойността.

В долната част на пирамидата тук имате предсказваща поддръжка, сигурност, защита от пени и др. Тези случаи на употреба представляват защита на приходите и имуществото. Ако Target защити тяхното нарушение на сигурността, което се случи в продължение на часове и седмици, CIO можеше да спаси работата си. Това би могло да спести десетки или стотици милиони долари и т.н. Анализът в поточно време в реално време наистина помага за защитата на тези активи и защитата на загубите. Това е директната добавена стойност на бизнеса точно там.

Следващата категория става все по-печеливша, намалява разходите и генерира повече приходи от текуща експлоатация. Това е ефективността на сегашното предприятие. Това са всички категории случаи на използване, които ние наричаме оперативно разузнаване в реално време, където получавате задълбочен поглед върху това как се държи мрежата, как се държат операциите на клиентите ви, как се държи вашият бизнес процес и сте в състояние да настроите всичко това в реално време, защото получавате обратна връзка, получавате сигнали. Получавате отклонения, отклонения в реално време и можете бързо да действате и разделяте процеса, който излиза извън границите.

Бихте могли също така да спестите много пари при скъпи капитални подобрения и неща, които смятате за необходими, които може да не са необходими, ако оптимизирате мрежовата услуга. Чухме за случай, в който основен telco отложи надстройка на 40 милиона долара в мрежовата си инфраструктура, защото установи, че имат достатъчно капацитет да управляват текущия си трафик, което е чрез оптимизиране и по-добро изпълнение на интелигентното маршрутизиране на трафика им и подобни неща. Всичко това е възможно само с някои анализи и механизъм за действие в реално време, които действат върху тези прозрения в реално време.

Следващото ниво на добавена стойност е надпродажба, кръстосана продажба, където има възможности за реализиране на повече приходи и печалба от текущи предложения. Това е класически пример, който много от нас знаят за това, че са преживели къде, мислите за живота си, където днес сте готови да купите продукт, който не ви се предлага. В много, много случаи това всъщност се случва. Имаш в ума си неща, които обичаш да купуваш, че знаеш, че искаш да купиш, че имаш списък със задачи или нещо такова, което жена ти е казала или ако нямаш жена, но наистина си искала да купиш и отивате или пазарувате на уебсайт, или взаимодействате в магазин за търговия на дребно, магазинът просто няма контекст, няма интелигентност, за да изчисли това, което може да ви е необходимо. Следователно, те не си осигуряват сигурността на бизнеса. Ако поточната аналитика може да бъде внедрена, за да направи наистина точни прогнози и които наистина са възможни за това, което би било най-подходящо за този конкретен контекст, този клиент в този момент на това място, има много надстройки и кръстосани продажби и това отново идва от поточна аналитичност - да бъде в състояние да вземе решение за склонност на това, което този клиент вероятно ще купи или отговори в този момент на истината, когато има възможност. Ето защо обичам онази снимка, която Дез показа с мечката тъкмо да яде тази риба. Това е доста.

Ние също така смятаме, че има голяма категория драматични, трансформационни промени в дадено предприятие, предлагащи изцяло нови продукти и услуги, просто базирани на наблюдение на поведението на клиентите, всички базирани на наблюдението на поведението на друго предприятие. Ако, да речем, телекомуникационна компания или кабелна компания наистина спазва моделите на използване на клиентите в какъв сегмент на пазара той гледа, каква програма по това време и т.н., те всъщност създават продукти и услуги, които почти се просят за някакъв начин. Така че цялата концепция за мултиекранното поведение точно сега, където сега почти го приемаме за даденост, че можем да виждаме телевизионно или кабелно съдържание в нашите мобилни приложения. Някои от тези примери идват от тези нови продукти и услуги, които ни се предлагат.

Ще вляза в „Какви са архитектурните съображения на поточната анализа?“ В крайна сметка се опитваме да направим. Това е архитектурата на Ламбда, където смесвате историческите данни и прозренията в реално време и ги виждате едновременно. Това позволява Sigma. Всички днес имаме пакетната архитектура и корпоративна картина. Ние се вглеждаме в някакъв BI стек и стек за използване и добавена архитектурата на Lambda. Тъй като скоростта на слоя или нуждата и Ламбда е свързана със сливането на тези две прозрения и виждането на това по комбиниран начин, в богат начин, който съчетава и двете прозрения.

Има и друга парадигма, наречена архитектура Kappa, която се предлага, когато предположението е, че скоростният слой е единственият входен механизъм, който ще се запази в дългосрочен план. Всичко ще премине през този скоростен слой. Дори няма да има офлайн механизъм ETL. Всички ETL ще се случат. Почистване, почистване на данни, качествен ETL - всичко това ще се случи на жица, защото имайте предвид, че всички данни са родени в реално време. В един момент беше реално време. Толкова сме свикнали да го поставяме върху езера, реки и океани, след това го правим чрез статичен анализ, че забравихме, че данните са родени в някакъв момент в реално време. Всички данни всъщност са родени като събитие в реално време, което се е случило във времето и повечето от данните днес на езерото просто са поставени в базата данни за по-късен анализ и сега имаме предимството в архитектурата на Lambda и Kappa всъщност виждайки го, анализирайки го, предварително го обработвайте и реагирайки на него, докато пристигне. Това е, което е разрешено от тези технологии. Когато го гледате като цялостна картина, тя изглежда като нещо такова, където има Hadoop вътре, има MPP и складове с данни, които вече имате.

Излагаме това, защото е важно да не говорим само за нови технологии на остров. Те трябва да се интегрират. Те трябва да имат смисъл в настоящия бизнес контекст и като доставчици на решения, които обслужват предприятия, ние сме много чувствителни към това. Ние помагаме на предприятията да интегрират цялата работа. Вляво има източници на данни, които се подават както в слоевете Hadoop и в хранилището на данни, така и в слоя в реално време отгоре. Всяко от тези образувания са складови компютри, както можете да видите, а слоят за потребление на данни е отдясно страна. Непрекъснато се правят усилия за преместване на по-голямата част от спазването, управлението, сигурността, управлението на жизнения цикъл и т.н., които са налични днес, всички те са били обединени в тази нова технология.

Едно от нещата, които анализа на поточните анализи се опитва да направи, ако погледнете пейзажа днес, има много неща в ландшафта на поточните технологии и от гледна точка на корпоративния клиент, има толкова много за разбиране. Има толкова много, за да бъдете в крак. Вляво има механизми за събиране на данни - NiFi, Logstash, Flume, Sqoop. Очевидно съм поставил отказ от отговорност, че не е изчерпателен. Влизане в опашки за съобщения и след това влизане в отворен код на поточни двигатели - Storm, Spark Streaming, Samza, Flink, Apex, Heron. Вероятно Heron все още не е с отворен код. Не съм сигурен дали е от Twitter. След това тези поточни двигатели водят или поддържат аналитичен компонент за приложение за настройка, като например сложна обработка на събития, машинно обучение, прогнозна анализация, модул за предупреждение, стрийминг на ETL, филтри за статистически операции за обогатяване. Това са всичко, което сега наричаме оператори. Наборът от тези оператори, когато се свързват заедно, потенциално би могъл също така да се извърши до голяма степен, ако е необходимо, да се превърне в приложение за стрийминг, което работи на поточно устройство.

Като част от тази верига от компоненти, вие също трябва да съхранявате и индексирате данните в любимата си база данни, вашия любим индекс. Може също да се наложи да разпространявате кеш и отново, което води в слоя за визуализация на данни от дясната страна в горната част до търговски продукти или продукти с отворен код, но в крайна сметка се нуждаете от някакъв продукт, който да визуализира тези данни в реално време. Също така понякога трябва да фигурирате други приложения. Всички сме виждали, че стойностите, получени само от действието, което предприемете за прозрение, че това действие ще бъде тригер от аналитичен стек в друг стек на приложения, който може би е променен, това е нещо в страната на IVR или задейства кол център изходящо повикване или нещо подобно. Трябва да имаме интегрирани тези системи и някакъв механизъм за вашия стрийминг клъстер, който да задейства други приложения за изпращане на данни надолу по веригата.

Това е цялостният стек от преминаване отляво надясно. След това разполагате със сервизните слоеве, средния мониторинг, общият защитен слой на защитата и др. Отидете до какви продукти, които са там, в корпоративното пространство, които клиентите виждат като дистрибуции на Hadoop, които всички текат както казах и има търговски или единични -vendor решения, които очевидно са в нашите конкуренти. В пейзажа има още много неща, които може би не сме споменавали тук.

Това, което виждате там, обикновено се вижда от корпоративния потребител. Както можете да видите, сложен и бързо развиващ се технологичен пейзаж за обработка на потоци. Трябва да опростим избора и тяхното потребителско изживяване. Това, което смятаме, че предприятията наистина се нуждаят, е функционалната абстракция на всичко това в един универсален, лесен за използване интерфейс, който обединява всички тези технологии, което го прави наистина лесен за използване и не излага всички движещи се части и проблемите на деградацията, въпросите на изпълнението и въпросите за поддръжка на жизнения цикъл на предприятието.

Функционалната абстракция е една. Втората част е абстракцията на поточния двигател. Поточните двигатели и домейните с отворен код се появяват веднъж на всеки три, четири или шест месеца. Беше Буря дълго време. Самза се появи и сега е Spark Streaming. Флинк повдига глава и започва да получава внимание. Дори пътната карта на Spark Streaming, те правят начин за потенциално използване на различен двигател за чиста обработка на събитията, защото също така осъзнават, че Spark е проектиран за партида и те правят път в архитектурната си визия и своята пътна карта за потенциално да имат различен двигател за обработка на потоци в допълнение към текущия модел на микропартията в Spark Streaming.

Това е реалност, която трябва да се бориш с това, че ще има много еволюция. Наистина трябва да се предпазите от този технологичен поток. Защото по подразбиране ще трябва да изберете един и след това да живеете с него, което не е оптимално. Ако го гледате по друг начин, вие се биете между „добре, трябва да си купя собствена платформа, където няма заключване, няма лост на отворен код, може да бъде много висока цена и ограничена гъвкавост спрямо всички тези стекове с отворен код, където трябва да се справите сами. ”Отново, както казах, това е много разходи и забавяне при достигането до пазара. Казваме, че StreamAnalytix е един пример за страхотна платформа, която обединява корпоративния клас, надежден, единичен доставчик, поддържано професионално обслужване - всичко това, от което наистина се нуждаете като предприятие и силата на гъвкавост на екосистемата с отворен код където една единствена платформа ги обединява - Ingest, CEP, анализи, визуализация и всичко това.

Освен това прави много, много уникално нещо, което събира много различни технологични двигатели под едно единствено потребителско изживяване. Ние наистина мислим, че бъдещето е в това да можем да използваме множество поточни двигатели, защото различните случаи на използване наистина изискват различни стрийминг архитектури. Както каза Робин, има цял спектър закъснения. Ако наистина говорите за ниво на латентност на милисекунди, десетки или дори стотици милисекунди, наистина се нуждаете от буря по това време, докато не се появи друг също толкова зрял продукт за по-малко снизходителност или снизходителни времеви рамки и закъснения от може би след няколко секунди, три, четири, пет секунди, в този диапазон, тогава можете да използвате Spark Streaming. Потенциално има и други двигатели, които биха могли да направят и двете. Долен ред, в голямо предприятие, ще се използват случаи от всякакъв вид. Наистина искате достъпът и общата съвкупност да имат няколко двигателя с едно потребителско изживяване и това е, което се опитваме да изградим в StreamAnalytix.

Само бърз преглед на архитектурата. Ще преработим това малко, но по същество, от лявата страна влизат множество източници на данни - Kafka, RabbitMQ, Kinesis, ActiveMQ, всички онези източници на данни и опашки за съобщения, влизащи в платформата за обработка на потоци, където стигате до сглобяването на приложение, където можете да изтеглите и пускате от оператори като ETL, всички неща, за които говорихме. Отдолу има множество двигатели. В момента ние имаме Storm and Spark Streaming като единствената и първа платформа за поточна платформа от корпоративен клас, която има множество поддръжка на двигателя. Това е много уникална гъвкавост, която предлагаме, освен цялата друга гъвкавост на разполагането на табла в реално време. Вграден CET двигател. Имаме безпроблемна интеграция с Hadoop и NoSQL индекси, Solr и Apache индекси. Можете да кацнете в любимата си база данни, без значение какво е и да изграждате приложения наистина бързо и да стигнете до пазара наистина бързо и да останете бъдещи доказателства. Това е цялата ни мантра в StreamAnalytix.

С това мисля, че ще завърша своите забележки. Чувствайте се свободни да се свържете с нас за повече въпроси. Бих искал да държа думата отворена за въпроси и отговори и дискусия на панела.

Ребека, до теб.

Ребека Йозвяк: Страхотно, добре. Много благодаря. Дез и Робин, имате ли някакви въпроси, преди да го предадем на Q&A на публиката?

Робин Блур: Имам въпрос. Ще си сложа слушалките отново, за да ме чуете. Едно от интересните неща, ако можете да ми кажете любезно, много от това, което съм виждал в пространството с отворен код, изглежда това, което бих казал незрял за мен. В известен смисъл, да, можете да правите различни неща. Но изглежда, че в действителност разглеждаме софтуера в неговото първо или второ издание и аз просто се чудех с вашия опит като организация, доколко виждате незрялостта на средата на Hadoop като проблемна или това е нещо, което не прави ' не създавам твърде много проблеми?

Ананд Венугопал: Това е реалност, Робин. Ти си абсолютно прав. Незрялостта не е непременно в областта на просто функционална стабилност и неща, но може би и някои случаи на това. Но незрялостта е повече в готовността за употреба. Продуктите с отворен код, когато излязат и дори докато се предлагат от дистрибуцията на Hadoop, всички те са много различни продукти, способни на работа, компоненти просто се плеснаха. Те не работят безпроблемно заедно и не са проектирани за гладко безпроблемно потребителско изживяване, което ще имаме като Bank of America или Verizon или AT&T, за да внедрим приложение за поточна анализа в рамките на седмици. Те не са проектирани за това със сигурност. Това е причината, поради която влизаме. Събираме го и го правим наистина лесно за разбиране, разгръщане и т.н.

Функционалната зрялост на него, според мен до голяма степен, има. Много големи предприятия използват например Storm днес. Днес много големи предприятия играят с Spark Streaming. Всеки от тези двигатели има своите ограничения в това, което може да прави, затова е важно да знаете какво можете и какво не можете да правите с всеки двигател и няма смисъл да чупите главата си в стената и да казвате: „Вижте аз избра Spark Streaming и това не работи за мен в този конкретен бранш. ”Няма да работи. Ще има случаи на използване, когато Spark Streaming ще бъде най-добрият вариант и ще има случаи, когато Spark Streaming може да не работи изобщо за вас. Ето защо наистина се нуждаете от множество опции.

Робин Блур: Е, за по-голямата част от това трябва да имате екипи от експерти. Искам да кажа, че дори не знам откъде да започна. Разумно сътрудничество на квалифицирани хора. Интересува ме как годежът, в който се включвате и как се случва. Дали защото конкретна компания е след конкретно приложение или виждате вид на това, което бих нарекъл стратегическо приемане, когато те искат цяла платформа да направи много неща.

Ананд Венугопал: Виждаме примери и за двамата, Робин. Някои от първите десет марки, за които всички знаят, се занимават с това по много стратегически начин. Те знаят, че те ще имат най-различни случаи на използване, така че оценяват платформи, които ще отговарят на тази нужда, което е множество от различни случаи на използване по много наемател, за да бъдат внедрени в предприятие. Има и истории за еднократна употреба, които започват също. Има конкретен случай на използване на мониторинг на бизнес активност в ипотечна компания, върху която работим, която не бихте си представили като случай на първа употреба, но това е бизнес решение или случай на използване, които те измислиха и след това свързахме точките за поточно предаване, Ние казахме: „Знаеш ли какво? Това е чудесен случай за поточна анализа и по този начин можем да я приложим. ”Така започна. След това, в този процес, те се обучават и казват: „О, уау, ако можем да направим това и ако това е обща платформа, тогава можем да разделим приложението, да ги слоем в платформа и да изградим много различни приложения за това платформа. "

Робин Блур: Дез, имате ли въпроси?

Ананд Венугопал: Дез вероятно е на безшумен.

Dez Blanchfield: Извинения, ням. Просто сам добре проведох разговор. Само следвайки оригиналното наблюдение на Робин, вие сте абсолютно прави. Мисля, че сега предизвикателството е предприятията да имат екосистема и културна и поведенческа среда, където безплатният софтуер с отворен код е нещо, което им е известно и те са в състояние да използват инструменти като Firefox като браузър и имат приличен живот, докато стане стабилна и сигурна. Но някои от онези много големи платформи, които използват са собствени платформи за корпоративния клас. Така че възприемането на това, което считам за платформи с отворен код, не винаги е нещо, което им е лесно да преминат в културен или емоционален план. Видях това само при приемането на малки програми, които бяха местни проекти, които просто играят с големи данни и анализи като основна концепция. Смятам, че едно от ключовите предизвикателства, сигурен съм, че сте ги виждали сега в организациите, е желанието им да получат резултата, но в същото време да имат единия си крак, забит в старата кутия, от която просто могат да си купят това от „Вмъкнете голяма марка“ Oracle, IBM и Microsoft. Тези нови и известни марки преминават с платформи Hadoop и дори повече. Идват по-вълнуващи марки, чрез които има водеща технология като stream.

Какви са видовете разговори, които сте водили или прекъсвате през това? Знам, че тази сутрин имаме масово присъствие и едно нещо, за което съм сигурен, че е на ума на всеки, е „Как да прережа целия този предизвикателен слой от дъската до нивото на управление, о, това е твърде отворен код и прекалено кървящ ръб? „Как минават разговорите, които провеждате с клиенти и как преминавате до онзи момент, в който по някакъв начин премахвате тези видове страхове, за да обмислите възприемането на харесванията на StreamAnalytix?

Ананд Венугопал: Всъщност намираме доста лесно да продадем предложението си за стойност, защото клиентите естествено се движат към отворен код като предпочитана опция. Те не се отказват лесно и казват: „Добре, сега ще отида с отворен код.“ Те всъщност преминават през много ангажирана оценка на основен продукт, да речем, че това е IBM или типичен продукт, защото имат тези връзки с доставчици. Те не биха се отнасяли към нас или към отворения код срещу този продукт. Те ще преминат през шест до осем до дванадесет седмици на оценка. Те ще се убедят, че има степен на производителност и стабилност тук, че аз искам, и тогава те решават да кажат: „Леле, знаеш ли какво, всъщност мога да направя това“.

Днес, например, имаме основен telco от първи ред, който разполага с поточна анализация, която работи в производството на голяма част от стека и те оценяват това срещу друг много, много известен доставчик и те се убедиха едва след като доказахме всичко ефективността, стабилността и всички тези неща. Не го приемат за даденост. Те откриха, че отворен код е компетентен чрез техните оценки и те осъзнават, че в най-лошия случай, „Може би има онези два случая на използване, които аз може би не мога да направя, но повечето от случаите на използване на ускоряване на бизнеса ми днес са изключително възможни с отворения код стек. “И ние даваме възможност за използването му. Това е голямото сладко място точно там. Искаха отворен код. Те наистина търсят да излязат от ситуацията на заключване на доставчика, с която са свикнали в продължение на много, много години. След това идваме и казваме: „Знаеш ли какво, ще направим отворен код много, много по-лесен и приятелски използван за теб.“

Дез Бланчфийлд: Смятам, че другото предизвикателство, което предприятията намират, е, когато въведат традиционното началство, те често са поколение зад някои от кървавите ръбове на вълнуващите неща, за които говорим тук, и нямам предвид това като отрицателна лека. Просто реалността е, че те имат поколение и пътуване, за да освободят това, което смятат за стабилни платформи, през които да преминат, цикъл на старите училища и интеграция в UATN, тестове и документация, маркетинг и продажби. Докато в типа, който правите, мисля, че нещото, което ми е интересно да си помисля, е, че разглеждайки някои от последните си версии снощи, правейки някаква изследователска работа, сега имате тази смес, където имате компетентност от аванс консултантска гледна точка и реализация, но вие също имате стак, в който можете да се включите. Мисля, че тук местните служители ще се борят за известно време. Виждали сме много от тях като мен на пазара. Те често са в това, което аз наричам догонващи възли, докато от това, което ни казвате, когато сте там, провеждате тези разговори и се реализирате.

Можете ли да ни дадете няколко примера за някои от граничните вертикали, които сте виждали осиновяване? Например, наистина има нишова среда като ракетната наука и поставянето на спътници в космоса и събирането на данни от Марс. На планетата има само шепа хора, които правят това. Но има големи вертикали като здравеопазването, например, в авиацията, в корабоплаването и логистиката, в производството и инженеринга, какви са няколко примера за по-големите и по-широки сектори на индустрията, които сте били досега, че сте виждали наистина добри осиновяване във?

Ананд Венугопал: Telco е голям пример.

Просто ще поправя слайдовете си тук. Можете ли да видите слайда тук, казус 4?

Това е случай на големи данни за приемане на телекомуникации и приемане на множество неща с тях. Те гледат какво наистина правят клиентите в реално време. Те гледат къде се случват грешки в реално време в приставки. Те се опитват да информират центъра за обаждания, ако този клиент се обади веднага, информацията за връзката на кода от приставката на този клиент, информацията за билети за поддръжка бързо корелира дали този конкретен клиентски приемник има проблем или дори не преди клиентът говори дума. Всяка кабелна компания, всеки голям telco се опитва да направи това. Те поглъщат данните от приставката, правят анализи в реално време, правят анализи на кампании, така че да могат да поставят рекламите си. Има огромен случай на използване.

Както казах, има тази ипотечна компания, която отново е общ модел, в който големи системи участват в обработката на данни от. Данните, които преминават през система А към система Б към система С и това са регулирани бизнеси, за които всичко трябва да бъде последователно. Често системите се синхронизират една с друга, една система казва: „Обработвам сто кредита на обща стойност 10 милиона долара.“ Системата казва: „Не, обработвам 110 кредита на някои други различен брой. ”Те трябва да разрешат това много бързо, защото всъщност обработват едни и същи данни и правят различни интерпретации.

Независимо дали става въпрос за кредитна карта, обработка на заем, бизнес процес или дали това е ипотечен бизнес процес или нещо друго, ние им помагаме да правят корелация и съгласуване в реално време, за да гарантират, че тези бизнес процеси остават в синхрон. Това е друг интересен случай на употреба. Има основен американски държавен изпълнител, който гледа DNS трафик, за да направи откриване на аномалия. Създаден е модел за обучение офлайн, който те изграждат и те правят оценката въз основа на този модел върху трафика в реално време. Някои от тези интересни случаи на употреба. Има голяма авиокомпания, която гледа опашки за сигурност и те се опитват да ви дадат тази информация, която казва: „Хей, това е вашата порта за вашия самолет за вашия полет. Днес опашката за TSA е около 45 минути срещу два часа срещу нещо друго. “Получавате тази актуализация предварително. Те все още работят по него. Интересен случай на използване на IoT, но страхотен случай на поточна аналитика, насочена към опита на клиента.

Ребека Йозвяк: Това е Ребека. Докато сте обект на случаи на употреба, има голям въпрос от страна на член на аудиторията, който се чуди: „Това ли са казуси, дали тези инициативи се движат от аналитичната страна на информационните системи на къщата или повече се движат от бизнесът, който има предвид конкретни въпроси или нужди? “

Ананд Венугопал: Мисля, че виждаме около 60 процента или около 50 процента до 55 процента, до голяма степен много проактивни, ентусиазирани технологични инициативи, които случайно знаят, които са доста умели и разбират определени бизнес изисквания и вероятно имат един спонсор, който те идентифицирани, но това са технологични екипи, които се подготвят за настъплението на случаите на бизнес употреба, които следват и след като веднъж изградят способността, те знаят, че могат да направят това и след това започват бизнес и агресивно продават това. В 30 процента до 40 процента от случаите виждаме, че бизнесът вече има конкретен случай на използване, който моли за способност за поточна анализа.

Ребека Йозвяк: Това има смисъл. Имам друг малко по-технически въпрос от член на аудиторията. Той се чуди дали тези системи поддържат както структурирани, така и неструктурирани потоци от данни, като утайки от потоци в Twitter или Facebook публикации в реално време, или трябва първоначално да се филтрира?

Anand Venugopal: Продуктите и технологиите, за които говорим, много бързо поддържат както структурирани, така и неструктурирани данни. Те могат да бъдат конфигурирани. Всички данни имат някаква структура, независимо дали е текст или XML или изобщо нещо. Има някаква структура от гледна точка на това, че има емисия с времеви печат. Може би има още едно петно, което трябва да се анализира, за да можете да инжектирате анализи в потока, за да анализирате структурите от данни. Ако тя е структурирана, тогава просто казваме на системата: „Добре, ако има стойности, разделени със запетая, а първата е низ, втората е дата.“ Така че можем да вмъкнем тази анализираща информация в слоевете на екрана и обработвайте лесно както структурирани, така и неструктурирани данни.

Ребека Йозвяк: Имам още един въпрос от публиката. Знам, че сме минали малко покрай върха на часа. Този участник иска да знае, изглежда, че приложенията за поточно предаване в реално време може да развиват както нужда, така и възможност за интегриране обратно в системите за транзакции, например системи за предотвратяване на измами. В такъв случай трябва ли системите за транзакции да бъдат оправени, за да отговарят на това?

Ананд Венугопал: Това е сливане, нали? Това е сливане на системи за транзакции. Те понякога стават източник на данни, където анализираме транзакции в реално време и в много случаи, когато да кажем, че има поток от приложения и тук се опитвам да покажа статичен сайт за търсене на данни и след това в нашия случай, където някакъв вид стрийминг в и търсите статична база данни като HBase или RDBMS, за да обогатите поточните данни и статичните данни заедно, за да вземете решение или аналитичен поглед.

Има и друга голяма индустриална тенденция, която също наблюдаваме - конвергенцията на OLAP и OLTP - и затова имате бази данни като Kudu и бази данни в паметта, поддържащи едновременно транзакции и аналитична обработка. Слоят за обработка на потоци ще бъде изцяло в паметта и ще разгледаме или взаимодействаме с някои от тези транзакционни бази данни.

Ребека Йозвяк: Смесеното натоварване беше едно от последните препятствия за прескачане, според мен. Дез, Робин, имате ли двама още въпроси?

Дез Бланчфийлд: Ще прескоча един последен въпрос и ще се спра на този въпрос, ако нямате нищо против. Първото предизвикателство, с което организациите, с които се занимавам през последното десетилетие или така, води до това вълнуващо предизвикателство на поточната анализа, първото нещо, което те са склонни да поставят отново на масата, когато започнахме разговора около цялото това предизвикателство, е къде да получаваме набор от умения? Как да преквалифицираме набора от умения и как да постигнем тази способност вътрешно? Влизането на импулс и ръка ни държи през пътуването и след това се изпълнява като чудесна първа стъпка и има много смисъл да правим това.

Но за средна до голяма организация какви са нещата, които виждате в момента, за да се подготвите за това, да изградите тази способност вътрешно, да получите нещо от просто основен речник около нея и какво послание могат да правят организацията около прехода към този вид рамка и преоборудването на техния технически персонал от ИТ от изпълнителния директор, за да могат те сами да управляват това, след като го изградите и приложите? Само накратко, какъв вид предизвикателства и как ги решават, клиентите, с които се справяте, видовете предизвикателства, които са намерили и как преминават през решаването на това преквалифициране и възстановяване на опит и знания, за да се подготвите за това и да бъдете можеш ли да обиколиш оперативно?

Ананд Венугопал: Често малкият набор от хора, които се опитват да излязат и да купят платформа за поточна аналитика, вече са разумно интелигентни, тъй като са наясно с Hadoop, те вече са придобили уменията си Hadoop MapReduce и понеже работят в тясно сътрудничество с Hadoop продавач на дистрибуция, те или са познати. Всичко получава Кафка, например. Те правят нещо с него или Storm или Spark streaming са в тяхната отворена програма. Определено хората са запознати с него или изграждат умения около него. Но започва с малък набор от хора, които са достатъчно квалифицирани и са достатъчно умни. Те посещават конференции. Те учат и че задават интелигентни въпроси на продавачите, а в някои случаи се учат с доставчиците. Тъй като продавачите идват и представят на първата среща, те може да не знаят неща, но те четат заедно и след това започват да играят с него.

Тази малка група от хора е ядрото и тогава тя започва да расте и всички сега осъзнават, че първият случай на използване на бизнеса става операционализиран. Там започва вълна и видяхме на срещата на върха Spark миналата седмица, където голямо предприятие като Capital One беше навън и в пълна сила. Те избираха Спарк. Те говореха за това. Те обучават много от своите хора в Spark, защото допринасят за това и в много случаи като потребител. Виждаме същото с много, много големи предприятия. Започва с няколко малки групи от много умни хора и след това започва вълна от цялостно образование и хората знаят, че веднъж старши вицепрезидент или веднъж старши директор е в съответствие и те искат да залагат на това нещо и думата се заобикаля и всички започват да набират тези умения.

Дез Бланчфийлд: Сигурен съм, че и вие имате фантастично време, като изградите и тези шампиони.

Ананд Венугопал: Да. Ние правим много образование, тъй като работим с първоначалните шампиони и провеждаме курсове за обучение и много, много за нашите големи клиенти, ние се върнахме назад и имахме вълни и вълни от обучение, за да вкараме много от потребителите във фазата на масовото използване, особено в сайта Hadoop MapReduce. Установихме, че в голяма компания за кредитни карти, която е наш клиент, сме доставили поне може би пет до осем различни програми за обучение. Имаме и безплатни издания на общността за всички тези продукти, включително нашите, пясъчни кутии, които хората могат да изтеглят, свикват и се обучават също така.

Дез Бланчфийлд: Това е всичко, което имам тази сутрин за вас. Благодаря ти много. Струва ми се невероятно интересно да видя типовете модели и използваните калъфи, които имате за нас днес. Благодаря ти.

Ананд Венугопал: Страхотно. Благодаря много хора.

Ребека Йозвяк: Благодаря на всички, че се присъединиха към нас в тези уеб предавания за горещи технологии. Беше увлекателно да чуя от Дез Бланчфийлд, д-р Робин Блур и от Impetus Technologies, Ананд Венугопал. Благодаря ви презентатори. Благодаря ви оратори и ви благодаря публиката. Следващия месец имаме още една гореща технология, така че потърсете това. Винаги можете да намерите съдържанието ни архивирано в Insideanalysis.com. Също така поставяме много съдържание в SlideShare и някои интересни битове и в YouTube.

Това е всичко приятели. Благодаря отново и имам добър ден. Чао чао.

Използване на firehose: получаване на бизнес стойност от поточна анализа: препис на уебинар