Съдържание
Източник: Якуб Джарсак / Dreamstime.com
За вкъщи:
Домакинът Ерик Кавана обсъжда анализа на големи данни с експерти от индустрията.
Ерик: Дами и господа, края на 2014 г. е - поне, почти. Това е последното ни излъчване в мрежата за годината, хора! Добре дошли в TechWise! Да, именно! Казвам се Ерик Кавана. Аз ще бъда ваш модератор за страхотно уебкаст, хора. Наистина съм много развълнувана. Имаме два страхотни анализатора онлайн и две страхотни компании - истински новатори в цялата тази екосистема с големи данни. И ние ще говорим всичко за ключа към анализа на големите данни е разбирането на разликата. Така че, нека да продължим и да се гмурнем направо, хора.
Имаме няколко презентатори. Както можете да видите, наистина в началото ви има ваши. Майк Фъргюсън се обажда по целия път от Обединеното кралство, където трябваше да получи специални привилегии, за да остане в офисната си сграда този късно. За това е късно за него Имаме д-р Робин Блур, наш собствен главен анализатор от групата Bloor. И ще имаме Джордж Коругедо, главен изпълнителен директор и съосновател на RedPoint Global, и Кийт Ренисън, старши архитект на решенията от SAS Institute. Това са фантастични компании, хора. Това са компании, които наистина иновации. И ще разровим някои добри неща от това, което се случва навън в целия свят на големи данни. И нека си признаем, малките данни не са изчезнали. И към това, нека да дам моето резюме тук.
Има един стар френски израз: "Колкото повече неща се променят, толкова повече остават същите." И нека да се сблъскаме с някои факти тук - големите данни няма да решат проблемите с малките данни. Корпоративните малки данни все още са там. Все още е навсякъде. Това е горивото на операциите за съвременната информационна икономика. И големите данни предлагат комплимент за тези така наречени малки корпоративни данни, но не заместват малките данни. Все още ще е наоколо. Харесвам много неща за големите данни, особено неща като машинно генерирани данни.
И днес вероятно ще поговорим малко за данните в социалните медии, което също е много мощно. И ако мислите например за това как социалното е променило бизнеса, добре помислете за три бързи уебсайта тук:, LinkedIn и. Помислете за факта, че преди пет години никой не правеше такива неща. е абсолютен югърнаут в наши дни. , разбира се, е огромен. Това е гаргантуан. И тогава LinkedIn е фактически стандарт за корпоративна мрежа и комуникация. Тези сайтове са хумористични и за да може да се използват данните, които са в тях, ще се възстанови някои функции за промяна на играта. Това наистина ще направи много полезно за много организации - поне за тези, които се възползват от това.
Без грешки, без стрес - Вашето стъпка по стъпка ръководство за създаване на софтуер, променящ живота, без да разрушава живота ви
Не можете да подобрите уменията си за програмиране, когато никой не се интересува от качеството на софтуера.
Така че, управлението - управлението все още е от значение. Отново големите данни не обезсилват необходимостта от управление. Честно казано, има съвсем нова необходимост да се съсредоточим върху това как да управляваме света на големите данни. Как да се уверите, че разполагате със своите процедури и правила; че правилните хора получават достъп до правилните данни; че имате контакти, тук ли сте замесени роднини? Всъщност знаете откъде идват данните, какво се е случило с нея. И това всичко се променя.
Откровено казано съм наистина впечатлен от някои от това, което видях навън в целия този нов свят, използвайки екосистемата Hadoop, което, разбира се, е много повече от съхранение по отношение на функционалността. Hadoop също е изчислителен двигател. И компанията трябва да измисли как да използва тази изчислителна мощност, тази способност за паралелна обработка. Ще направят наистина много готини неща. Ще научим за това днес.
Другото, което трябва да се отбележи, това е нещо, за което д-р Блур говори в близкото минало, е, че вълната на иновациите не е приключила. Така че, видяхме много, разбира се, внимание около Hadoop. Виждали сме компании като Cloudera и Hortonworks, знаете, наистина правят вълни. И те днес развиват партньорства с, добре, компаниите на повикване, честно казано. И те развиват партньорства с много хора. Но иновационната вълна не свършва. От Фондация Apache има още проекти, които променят не само крайната точка, ако искате - приложенията, които хората използват - но и самата инфраструктура.
Така че цялата тази разработка на YARN - още един преговарящ ресурс - наистина е като операционна система за големи данни. И това е голяма, голяма работа И така, ще научим как това променя нещата също. Така че, само няколко части очевидни съвети тук, внимавайте за продължаването на дълги договори, знаете, пет-, десетгодишни договори ще бъдат вълната, пътят, който ми се струва. Ще искате да избегнете заключването на всяка цена. Днес ще научим за всичко това.
И така, първият ни аналитичен говорител днес - първият ни говорител на цялата програма е Майк Фъргюсън, който се обажда от Обединеното кралство. С това ще ти предам ключовете, Майк, и ще ти позволя да го вземеш. Майк Фъргюсън, пода е твой.
Майк, нали? Може да сте на заглушаване. Не го чувам. Може да се наложи да му се обадим. И просто ще скочим право към слайдовете на Робин Блур. Робин, тук ще се класирам на бедния Майк Фъргюсън. Ще отида за секунда.
Това ли си, Майк? Можеш ли да ни чуеш? Нее. Мисля, че ще трябва да вървим напред и първо да вървим с Робин. Така че, задръжте една секунда, хора. Ще изтегля някои връзки към слайдовете тук след няколко минути. Така че с това, нека да предам ключовете на Робин Блур. Робин, можеш да отидеш първо вместо Майк, а аз ще се обадя на Майк след секунда.
Робин: Добре.
Ерик: Дръжте, Роб. Остави ме да продължа напред, Роб. Ще отнеме секунда
Робин: Добре.
Ерик: Да. Можете да говорите за това, с което се занимаваме, но по отношение на управлението. Знам, че ще говорите за управление. Обикновено това се обмисля във връзка с малки корпоративни данни. Така че сега имам пързалката, Робин. Не мърдай нищо. И ето ти. Подът е ваш. Отнеси го.
Робин: Добре. Да. Искам да кажа, добре, че предварително сме се уговорили, Майк ще говори за аналитичната страна, а аз ще говоря за страната на управлението. До известна степен управлението следва аналитиката в смисъл, че това е причината, поради която правите големи данни за данни, и причината да сглобите целия софтуер, за да правите аналитиката, е именно тук.
Има проблем И проблемът е, че знаете, че данните трябва да се оправят. Данните трябва да бъдат обект на мащаб. Данните трябва да бъдат обединени и управлявани по начин, който позволява анализирането да се извършва с пълна увереност - предполагам, е думата. И така, аз реших, че ще говоря за управлението на уравнението. Предполагам, нещото, което трябва да кажа, е, че знаете, че управлението вече беше проблем. Управлението вече беше проблем и то започва да се превръща в проблем в цялата игра на хранилището на данни.
Това, което всъщност се е случило, е превърнато в много по-голям проблем. И причината да се превърне в много по-голям проблем, както и повече данни, но искам да кажа, това са причините, наистина. Броят на източниците на данни се е разширил драстично. Преди това източниците на данни като цяло бяха дефинирани от това, което захранва хранилището на данни. Складът за данни обикновено се захранва от RTP системи. Възможно е малко външни данни, не много.
Сега, ние отидохме в свят, където, знаете ли, пазар на данни се появява в момента и следователно ще има търговия с данни. Вече имате много и много поточни източници на данни, които всъщност можете да внесете в организацията. Имаме данни от социалните медии, които са ги взели, премахнали за своя сметка, така да се каже. Искам да кажа, че много от стойността в сайтовете за социални медии е всъщност информацията, която те обобщават и следователно могат да предоставят на хората.
Разбрахме, знаем, че те вече са съществували. Вече имахме онези регистрационни файлове, нали знаете, при появата на Splunk. И скоро стана ясно, че има стойност в лог файл. И така, в организацията имаше данни, които бяха - които бихме могли да наречем нови източници на данни, както и външни източници. Това е едно. И това наистина означава, че знаете, каквито и правила за управление на данните да сме имали преди, те ще трябва да бъдат разширени, по един или друг начин, и ще трябва да продължават да се разширяват, за да управляват действително данни. Но сега започваме да се събираме по един или друг начин.
И слизайки в този списък имаме поточно предаване и скоростта на пристигане на данни. Една от, според мен, причините за популярността на Hadoop е, че той може да бъде използван до голяма степен за събиране на много данни. Той може също да поглъща скоростта на данните, че ако всъщност не е необходимо да го използвате веднага, това е хубава успоредна, огромна паралелна среда. Но също така сте разбрали, че в момента има доста голям брой поточни аналитики. Преди беше просто банковият сектор, който се интересуваше от стрийминг на приложения, но сега вече е глобален. Всички гледат на поточните приложения по един или друг или друг начин, като потенциално средство за извличане на стойност от данните и извършване на анализи за организацията.
Имаме неструктурирани данни. Статистиката, обикновено част от единствените 10% от данните в света, е в релационни бази данни. Сега една от основните причини за това беше, че всъщност е неструктурирана и тя беше - голяма част от нея имаше в мрежата, но доста разпръсната за различни уебсайтове. Тези данни се оказаха също анализируеми, също използваеми. И с навлизането на технологията Symantec, която постепенно се промъква в ситуацията, става все повече и повече.Така че, наистина трябва да събираме и управляваме неструктурирани данни и това означава, че е много по-голямо, отколкото преди. Имаме социални данни, които вече споменах, но смисълът от това, основният въпрос за това, вероятно е необходимо почистване.
Имаме данни от Интернет на нещата. Това е различен вид ситуация. Вероятно ще има толкова много от това, но много от тях ще трябва да останат разпределени някъде в близост до мястото, което управлява. Но вие също ще искате да го изтеглите по един или друг начин, за да направите анализа в рамките на организацията върху данните. Това е добавен още един фактор. И тези данни ще бъдат структурирани по различен начин, защото вероятно - вероятно ще бъдат форматирани в JSON или в XML, така че да се декларира. И не само, по един или друг начин, че всъщност ние привличаме данни и сме в състояние да направим вид схема при четене на този конкретен фрагмент от данни.
Имаме проблем с произхода и това е въпрос на анализа. Резултатите във всеки анализ, на който правите данни, наистина не могат да бъдат одобрени, ако желаете, да бъдат приети за валидни, освен ако не знаете произхода на данните. Искам да кажа, това е просто професионализъм по отношение на дейността на учените по данни. Но знаете, за да имаме произход на данни, това означава, че всъщност трябва да управляваме данни и да водим бележка към неговия произход.
Имаме проблем с компютърната мощност и паралели и всичко, което прави, е всичко да върви по-бързо. Проблемът е, че очевидно някои процеси, които имаме на мястото, може да са твърде бавни за всичко останало. Така че, вероятно има несъответствия по отношение на скоростта.
Имаме появата на машинно обучение. Машинното обучение всъщност има ефект от превръщането на анализите в различна игра, отколкото беше преди. Но наистина можете да го използвате само ако имате силата.
Получихме факта на нови аналитични натоварвания. Имаме паралелен свят и някои аналитични алгоритми трябва да бъдат изпълнени успоредно за максимален ефект. И следователно проблемът всъщност е да управлявате как всъщност по един или друг начин натискате данните наоколо, правите данните, ако те са налични. И къде всъщност изпълнявате аналитичните натоварвания, защото може да правите това в базата данни. Така че може да го правите в рамките на аналитични приложения.
Така че има цяла поредица от предизвикателства пред управлението. Това, което направихме тази година - изследванията, които направихме тази година, наистина бяха около големи архитектури на данни. И когато всъщност се опитваме да го обобщим, изводът, до който стигнахме - диаграмата, която измислихме, изглеждаше много така.
Няма да се занимавам с това, особено тъй като Майк ще направи доста средства за архитектура на данни за анализи. Но това, което аз всъщност харесвам хората да се съсредоточат само върху тази област на дъното, където по един или друг начин ние събираме данни. Имаме нещо, към което бих искал да се позова, е рафинерията на данни или центъра за обработка на данни. И там се осъществява управлението. Знаете ли, ако се съсредоточим, изглежда така. Знаете ли, тя се захранва от данни от вътрешни и външни източници. Центърът трябва на теория да взема всички данни, които се генерират. Той трябва или да бъде поточен и управляван, както е поточен, ако трябва да направите анализи и поточни данни, и след това да преминете към центъра. Или иначе казано, всичко това влиза в центъра. И има няколко неща, които се случват - които се случват в центъра. И не можете да имате определено количество анализи и SQL, които се извършват в центъра. Но също така имате нужда от виртуализация на данните във всяка клетка, за да преместите данни в други области. Но преди да се случи нещо от това, всъщност трябва по един или друг начин да извършите прецизиране на подготовката на данните. Можете да го наречете подготовка на данни. Тя е много по-голяма от това. Това са нещата, които според мен включва.
Имаме управление на системата и управление на услуги, в известен смисъл, че това е основната част от слоя данни, тогава всъщност трябва да приложим всички системи, управляващи усилията за управление на операционната система, които традиционно сме правили за почти всички операционни системи. Но ние също така трябва по един или друг начин да наблюдаваме други неща, които се случват, за да се уверим, че тези различни нива на услуги са изпълнени, тъй като трябва да бъдат дефинирани нива на услуги или какъвто и да е вид анализи, както се действа, или BI данните са е действал.
Нуждаем се от мониторинг и управление на изпълнението. Ако не друго, ние се нуждаем от това, за да знаем какви допълнителни компютърни ресурси може да се наложи да отделим в различни моменти от време. Но също така, много голяма натовареност е тук в действителност, доста сложна и се конкурира помежду си за ресурси. Има нещо доста сложно, което трябва да се направи в тази област.
Вече имаме жизнен цикъл на данните по начин, който никога досега не сме го имали. Сделката тук наистина е отвъд всичко друго, че не сме събирали данни и ги изхвърляме преди това. Склонни сме да събираме данни, от които се нуждаем и вероятно ги съхраняваме, а след това ги архивираме. Но ужасно много от това, което ще правим от тук нататък, е проучване на данни. И ако не искате данните, нека ги погребете Така че, жизнените цикли на данните са различно нещо в зависимост от ситуацията, но също така ще бъдат много повече събиране на данни. Следователно, знаете, откъде е произлязъл агрегат от какво ... какъв е източникът на агрегация и т.н., и така нататък. Това е всичко необходимо.
Линията от данни естествено отпуска заеми. Без него трябва да знаете проблемите, така че данните ... Трябва да знаем, че данните са валидни, но с това колко надеждни са всъщност.
Имаме и картографиране на данни, защото много от данните всъщност ще бъдат, по един или друг начин. И това е, ако желаете, това се отнася до известна степен в MDM. Просто сега е много по-сложно, защото когато имате много страници от данни, дефинирани от JSON или въз основа на нашата XML схема при четене, тогава ще трябва да по някакъв или друг начин да станете много активни активност по картографиране на данни.
Има ситуация с управление на метаданни, която е повече от MDM, защото по един или друг начин е необходимо да се изгради това, което бих искал да мисля сега като вид склад за метаданни от всичко, от което имате интерес. Има метаданни откритие, тъй като някои от данните не е задължително да декларират своите метаданни и искаме да ги използваме незабавно. И тогава, има почистване на данни, което е огромно нещо, как серия от неща, които човек може да направи там. Има и сигурност на данните. Всички тези данни трябва да бъдат защитени до приемливо ниво и това може да означава дори в определени случаи - например криптиране на много от стойностите.
Така че цялото това натоварване всъщност е империята за управление. Всичко това, по един или друг начин, трябва да се извършва едновременно или преди, цялата ни аналитична дейност. Това е голям брой координирани приложения. Това е система сама по себе си. И тогава тези, които не го правят в различни моменти, ще страдат от липсата му, тъй като продължават напред, защото страшно много от тези неща всъщност не са задължителни. В крайна сметка просто увеличавате ентропията, ако не ги направите.
Така че по отношение на анализа на данните и управлението, нещото, което бих казал, е, че всъщност едната ръка мие другата. Без управление, анализи и BI няма да се развихрят навреме. И без анализи и BI, няма да има голяма нужда от управление на данните. И така, двете неща наистина вървят ръка за ръка. Както казват в Близкия изток, "едната ръка мие другата." И това е всъщност всичко, което имам да кажа. Надявам се - надяваме се, че сега се върнахме Майк
Ерик: Ние го правим. Майк, предполагам, че си там. Ще избутам слайда ви нагоре.
Майк: Аз съм. Добре, чуваш ли ме?
Ерик: Да, чувам те. Звучи прекрасно. Така че, нека да ви представя ... Ето. А вие сега сте водещият. Отнеси го.
Майк: Добре, благодаря! Добро утро, добър следобед, добра вечер на всички вас навън. Простете хълцането в началото. По някаква причина аз се заглуших и виждам всички, но не можеха да ме чуят.
Добре. И така, това, което искам да направя бързо, е да говоря за, знаете, аналитична екосистема за големи данни. Ако искате да ми зададете въпроси, аз ще кажа, в тази сесия или по-късно, можете да се свържете с мен в данните ми за контакт тук. Както казах, посред нощ тук, във Великобритания.
Е, нека да стигна до това, за което искам да говоря. Ясно е, че през последните няколко години видяхме появата на всякакъв вид нови намерени типове данни, които бизнесът сега иска да анализира - всичко - от данните за кликвания до разбирането на поведението в мрежата, данните в социалните медии, за които Ерик говори по време на началото на програмата тук. Мисля, че Робин спомена JSON, BSON, XML - така, полуструктурирани данни, които се самоописват. Разбира се, имаме и цял тон други неща - всичко - от неструктурирани данни, дневници на ИТ инфраструктурата, данни от сензори. Всички тези сравнително нови източници на данни, от които сега бизнесът се заинтересува, защото съдържа ценна представа, която би могла да задълбочи това, което знаем.
Така че това означава, че аналитичният пейзаж е надхвърлил традиционното съхранение на данни. Ние все още структурираме данните в света на комбинация от структурирани и многоструктурни данни, при които многоструктурните данни могат да идват от вътрешната или външната страна на предприятието в много случаи. И в резултат на тези нови типове данни и нови нужди за анализ, видяхме появата на нови аналитични натоварвания - всичко от анализиране на данни в движение, което от своя страна превръща традиционната архитектура за съхранение на данни, донякъде, където ние , в традиционните кръгове интегрирайте данните, почистете ги, трансформирайте ги, съхранявайте и анализирайте. Но анализирайки данните в движение, ние ги улавяме, интегрираме, подготвяме чрез анализ и след това съхраняваме. Така че, анализът на данните продължава, преди да се съхранява навсякъде.
Ние сложен анализ на структурирани данни, може би за разработване на модели, за развитие на статистически и предсказуеми модели, което не е нещо ново за някои хора в традиционното пространство за съхранение на данни. Имаме проучвателен анализ на данните на модела. Това е количеството структурирани данни там. Имаме нови натоварвания под формата на графичен анализ, който за моите клиенти във финансовите услуги включва неща като измама. Тя включва и киберсигурност. Включва социалните мрежи, разбира се, разбиране на влияещи и подобни неща там. Дори го усвоих в управлението, има няколко години анализ на графики.
Ние имаме оптимизация на хранилището на данни или разтоварване на обработката на ETL, което е по-скоро един вид използване на ИТ, CIO може да финансира това. И дори архивиране на данни и складове за данни, за да ги поддържате онлайн в неща като Hadoop. И така, всички тези нови аналитични натоварвания добавят нови платформи, нови платформи за съхранение към аналитичния пейзаж. И така, вместо просто да имаме традиционни хранилища за данни, данни, това, което сега имаме, е Hadoop. Ние имаме NoSQL бази данни, като графични бази данни, които често се използват за аналитични натоварвания. Разбира се, можем да направим анализ на графики сега на самия Hadoop, както и в СУБД на графики NoSQL. Имаме поточна анализа, която Робин спомена. И ние имаме - ако желаете - изграждане на модели, може би и на аналитични уреди за съхранение на данни. Но всичко това усложнява аналитичния пейзаж, сега са необходими множество платформи. И предполагам, че предизвикателството за всеки бизнес с преден офис или заден офис или финанси, поръчки, HR и някакъв вид операции е да разберем кои аналитични проекти са свързани с традиционна сцена за съхранение на данни. И след като знаете, че аналитичните проекти са свързани с тези нови големи платформи за данни и къде да се движите, знаете кое аналитично натоварване, но да не изпускате от поглед на бизнеса в смисъл, че е - сега ще видите, че това е комбинация от големи проекти за анализиране на данни и традиционни проекти за съхранение на големи данни, които заедно са необходими, за да се засилят вътре около клиенти или около операции, около риск, финансиране или устойчивост. Ето защо ние искаме всичко това да бъде приведено в съответствие с нашите стратегически бизнес приоритети, за да останем на пътя, знаете, да вкарате иглите, които трябва да бъдат вкарани, знаете, за подобряване на бизнес резултатите, за намаляване на разходите, за намаляване на рисковете и т.н., знаете, за нашата компания като цяло. Така че не е, че единият замества другия тук с големи данни и традиционен. И двете се използват заедно. И това драматично променя архитектурата, нали знаете.
И така, това, което имам тук, е сравнително нова архитектура, която ще използвам с клиентите си. И така, както виждате сега по дъното, голям набор от източници на данни, не само структурирани вече. Някои от тях предават на живо данни като сензори, като пазарни данни, такива неща. Може дори да са данни на клик на живо. Това може да бъде поточно видео на живо. Така че не е необходимо да се структурира. Така че ние можем да правим поточна обработка на тези данни, за да предприемаме автоматични действия в реално време, а всякакви интересуващи данни могат да бъдат филтрирани и предадени в инструменти за управление на информацията за предприятието, които могат да се използват за попълване на аналитични магазини за данни. Освен ако не можете да видите в комбинацията тук, сега имаме традиционно съхранение на данни, Hadoop и NoSQL бази данни. Имаме и управление на основни данни в комбинацията. И това оказва по-голям натиск върху целия набор от инструменти за управление на данни, не само за попълване на тези хранилища на данни, но и за преместване на данни между тях.
На всичкото отгоре трябва да опростим инструментите за достъп. Не можем просто да се обърнем към потребителя и да кажем: „вземете всички тези хранилища с данни, задръжте тези API-та - вашият проблем“. Това, което трябва да направите, е да опростите достъпа. И така, вид в пунктирните редове там, ще видите виртуализацията на данните и оптимизацията са вид скриване на сложността на многократното съхранение на данни, опитайте се и улеснете достъпа на крайните потребители до това. И разбира се, има набор от инструменти на върха, знаете - всичко от традиционните BI инструменти, които са започнали отначало в горната част на съхранение на данни, постепенно се движат вляво от вашата диаграма, за да се свържат в Hadoops и след това по света на базите данни NoSQL.
Имаме търсене за получаване на нов лизинг за живот, по-специално около структурираните, неструктурирани данни, които често се съхраняват в Hadoop. Имаме персонализирани аналитични приложения, които да се правят на платформата Hadoop с MapReduce, така че рамката Spark например. Имаме инструменти за анализ на графики, за да се съсредоточим върху много специфични натоварвания там. И така, набор от инструменти и потоци от данни също са по-сложни. Това вече не е само еднопосочна улица в хранилището с данни. Сега те са главни данни, разбира се.
Имаме нови източници на данни, или са заснети в NoSQL, знаете, магазини за данни като MongoDB, като Cassandra, като HBase. Имаме данни, въведени директно в Hadoop за анализ и подготовка на данни там. Имаме нови данни от Hadoop и хранилищата с данни. Имаме архив, който излиза от складовете с данни в Hadoop. Сега имаме информационни емисии, към които знаете, и всички бази данни NoSQL. И така, това, което можете да видите тук, има много повече дейност в управлението на данни. И това означава, че поставя софтуера за управление на данни под значителен натиск. Това вече не е само еднопосочна улица. Това е двупосочно движение на данни. Продължава много повече активност и следователно мащабируемостта е важна както на фронта на инструмента за управление на данни, така и на източника на данни.
И така, тази диаграма се връща към онази архитектура, която споменах преди малко. Показва ви различните аналитични натоварвания, работещи в различни части на тази архитектура. Някакво долу вляво, вие получавате поточно предаване в реално време, обработка на потоци на данни, които излизат от, знаете, от всякакъв вид хранилище на живо. Имаме анализ на класа в базата данни с графики NoSQL. Може да се случи и на Hadoop. С рамката Spark например и GraphX там имаме разследващ анализ и рафинерията на данни, за които Робин говори, че се случва в Hadoop. Все още имаме традиционно натоварване и съхранение на данни, знаете ли, потребителите на енергия изграждат статистически и прогнозни модели, може би на уредите за съхранение на данни. И все още се опитваме да опростим достъпа до всичко това, за да улесним крайните потребители.
И така, успехът около цялата тази настройка е нещо повече от аналитична страна. Знаеш ли, можем да поставим аналитичните платформи, но ако не можем да заснемем и поглъщаме, знаете, данни за висока скорост и голям обем в мащаба, няма много смисъл. Знаеш ли, нямам какво да анализирам. И така, успехът на анализа на големи данни изисква оперативните системи да се увеличават. Това означава, че можете да поддържате нови транзакции, знаете, върхове. Знаеш ли, че всякакви транзакционни данни, които се заснемат там, биха могли да бъдат, всякакви нови проценти на пристигане много, много високи проценти на пристигане на данни с висока скорост като сензори или каквото и да е поглъщане. Трябва да можем да се погрижим за всичко това - да можем да събираме този вид данни и да ги предоставяме за анализ. Ние също трябва да мащабираме самите анализи, да опростим достъпа до данни, които споменах вече. И тогава, завържете това. Знаеш ли, ние трябва да можем да усъвършенстваме обратно в тези операционни системи, за да му дадем затворен цикъл.
Така че, мащабирането на оперативната страна на къщата за заснемане на данни, знаете ли, влиза в света на базата данни NoSQL. Искам да кажа, тук виждате пет категории от базата данни на NoSQL. Тази категория ще бъде моделирана само като комбинация от останалите четири по-горе. Като цяло знаете, неговите ключови стойности, съхранявани документи и бази данни от фамилията на колоните - първите три там - които се използват за повече вид транзакционни и не-транзакционни данни.
Някои от тези бази данни, поддържащи като свойства; някои от тях не. Но въпреки това, знаете, виждаме въвеждането на такива, за да мащабирате тези видове приложения. И така, например, тъй като ние се отдалечихме от само служители, които въвеждат транзакции с клавиатури, към сега клиенти и от масивите, използващи нови устройства, за да могат да направят това. Забелязахме огромно увеличение на броя на сделките, които се сключват в предприятията. И така, ние трябва да мащабираме транзакционните приложения, за да направим това.
Сега, най-общо казано, това може да се направи на бази данни NewSQL като релационна база данни като NuoDB и VoltDB, показани тук. Или някои от базите данни NoSQL, които може би поддържат ACID свойства, които могат да гарантират обработката на транзакции, може да са в игра. Това се отнася също и за транзакционните данни, като например данните за пазарската количка преди транзакция, знаете, преди хората да купуват неща, сензорни данни, знаете, тъй като аз губя сензорно отчитане сред стотици милиони показания на сензора. Не е голяма работа. Кликнете, знаете ли, в света на кликвания - ако използвам кликване, няма нищо голямо.Значи, знаете, не е задължително там да имаме свойства на ACID и там често влизат в действие базите данни на NoSQL, тя беше там - тази способност да прави много висока и правилна обработка в мащаб, за да заснеме тези нови видове данни.
В същото време искаме анализите да мащабират. И така, изтеглянето на данните от хранилищата на данни към аналитичните платформи вече няма да го хаква, защото данните са твърде големи. Това, което наистина искаме, е да изтласкаме аналитиката по друг начин, надолу в хранилището на корпоративните данни в Hadoop, в поточна обработка, за да можем да избутим аналитика към данните. Въпреки това, само защото някой казва, че е в анализа на бази данни или в Hadoop аналитика, не означава непременно анализацията да се извършва паралелно. И честно казано, ако ще инвестирате в тези нови масово паралелни мащабируеми технологии като Hadoop, като уредите за съхранение на данни и какво ли още не, като двигателите за обработка на клъстерирани потоци, се нуждаем от анализи, за да работим паралелно.
Това е само проверката. Знаете, ако имаме аналитични данни, които да ви помогнат да прогнозираме нещата за клиентите, за операциите, за риска и т.н., ние искаме те да работят паралелно, а не просто да работят в платформата. Искаме и двете. И това е така, защото, знаете, технологията е като тези нови инструменти за визуално откриване, като SAS. Той всъщност е един от нашите спонсори тук.
Едно нещо, което хората искат, е поне да експлоатират тези в Hadoop, а след това и в анализа на бази данни. И ние искаме те да работят паралелно, за да можем да постигнем необходимата производителност при толкова големи обеми от данни. В същото време се опитваме да опростим достъпа до всичко това. И така, SQL вече е на дневен ред. Знаете ли, SQL е - SQL в Hadoop е горещ в момента. В момента го проследявам в 19 SQL и Hadoop инициативи. Плюс това, можете да видите, ние можем да получим тези данни, знаете, по много начини, така че директен достъп до SQL на самия Hadoop, да стигнем до SQL до индекс за търсене. По този начин, като, знаете, някои от доставчиците на търсене в това пространство, ние можем да имаме SQL достъп до аналитични релационни бази данни, които имат таблици на Excel до Hadoop.
Вече можем да имаме SQL достъп до сървър за виртуализация на данни, който след това сам може да бъде свързан към склад за данни в Hadoop. Дори сега започвам да виждам появата на SQL достъп до поточни данни на живо. И така, SQL достъпът до всичко това бързо нараства. И част от предизвикателството е, само защото там се предлага достъп до SQL. Въпросът е, може ли SQL да се справи със сложни данни? И това не е непременно ясно. Тук има всякакви усложнения, включително фактът, че данните от JSON могат да бъдат вложени. Можем да имаме варианти на схеми с варианти. И така, първият запис има една схема. Вторият запис има различна схема. Тези неща са много различни от това, което се случва в релационен свят.
Така че, ние трябва да зададем въпроси за това какъв тип данни се опитваме да анализираме и какви са аналитичните характеристики. Знаете ли, панел, който искате да направите? Машинно обучение ли е? Графичен анализ ли е? Можете ли да го направите от SQL? Знаеш ли, това е извикващо от SQL? Колко паралелни потребители имаме да правим това? Знаете ли, имаме стотици едновременни потребители. Възможно ли е това за сложни данни? Знаеш ли, всички тези неща са ключови въпроси. Така че, аз направих списък от няколко тук, които смятам, че трябва да помислите. Знаеш ли, какви файлови формати? За какви типове данни говорим? Какви аналитични функции можем да използваме от SQL, за да получим сложни данни? И видът на функциите работи паралелно. Искам да кажа, че те трябва да вървят паралелно, ако трябва да можем да мащабираме това. И мога ли да се присъединя към данни в Hadoop днес извън него, знаете ли, или това не е възможно? И какво ще правя с всички тези различни видове натоварвания на заявките?
И както ще видим, знаете, че от това, което видях, има много разлики в дистрибуцията на SQL и Hadoop. Това са всички, които проследявам. И между другото, това е чистият SQL на Hadoop. Това дори не включва виртуализация на данните в този момент. И така, много там и много място за консолидация, което мисля, че ще се случи през следващата година, осемнадесет месеца или повече. Но също така отваря и друго нещо, което е, че мога да имам потенциално множество SQL двигатели на едни и същи данни в Hadoop. И това е нещо, което не бихте могли да направите във връзка.
Разбира се, това означава, че след това трябва да знаете, знаете, какъв вид натоварване на заявките изпълнявам? Трябва ли да пускам това в партида на конкретен SQL по Hadoop инициатива? Трябва ли да пускам интерактивни заявки за натоварване чрез друга SQL по Hadoop инициатива и т.н., така че да знам към кого да се свържа? В идеалния случай, разбира се, не бива да правим това. Трябваше просто да имаме въпрос по въпроса. Знаете, някои оптимизатор измисля най-добрия начин да го направите. Но според мен все още не сме напълно там.
Но въпреки това виртуализацията на данните, споменах по-рано, има много важна роля за опростяване на достъпа до множество хранилища на данни. И ако направим нова информация за Hadoop, със сигурност е възможно да се присъединим към тези данни и традиционните хранилища на данни чрез виртуализация на данни, например, без непременно да преместваме данните от Hadoop в традиционните хранилища на данни. Разбира се, можете да го направите и вие. Възможно е също така, ако архивирам данни от традиционните хранилища на данни в Hadoop. Все още мога да се свържа с него и да се присъединя към нещата, които са в нашия склад за данни, към виртуализация на данните. Така че за мен мисля, че виртуализацията на данните има голямо бъдеще в тази цялостна архитектура и опростява достъпа до всички тези хранилища на данни.
И да не забравяме, че когато създаваме тези нови прозрения, независимо дали става въпрос за релационни или NoSQL системи, все пак искаме да направим тези прозрения обратно в нашите операции, за да можем да увеличим максимално стойността на това, което сме открили, за да можем да използваме това за по-ефективни, по-навременни решения в тази среда, за да оптимизираме нашия бизнес.
Така че, за да приключим тогава, това, което виждам, е необходимо, знаете ли, нови източници на данни се появяват. Имаме нови платформи за по-сложна архитектура, ако искате, за да се справите с това. И Hadoop става много, много важен, достатъчен за подготовка на данни за нашите течни пясъчни кутии, за архивни заявки, архив от хранилище на данни, управление на данни, разпространяващи крилете си, за да надхвърли складирането на данни в управлението на данни във всички тези платформи и нови инструменти, които да бъдат в състояние да анализира и достъп до данни в тези среди, да може да има мащабируеми технологии за по-добро приемане на данни и мащабиране на аналитика, като ги натиска надолу в платформите, за да ги направи повече паралелни. И тогава, да се надяваме, също да опростим достъпа до всичко чрез възникващия SQL, идващ отгоре. Така че това ви дава представа откъде сме се насочили. Така че с това ще се върна към, предполагам, Ерик сега, нали?
Ерик: Добре, това е фантастично. И хора, трябва да кажа, че между това, което току-що получихте от Робин и Майк, вероятно става въпрос за толкова изчерпателен и кратък преглед на целия пейзаж от гледането, както ще намерите навсякъде. Нека да продължа напред и да се наредим на опашка първо Джордж Коругедо. И ето го. Нека да разгледам това за бърза секунда. Добре, Джордж, щях да ти предам ключовете и да го отнеса. Подът е ваш.
Георги: Страхотно! Благодаря ти много, Ерик, и благодаря ти, Роб и Майк. Това беше страхотна информация и много, с които се съгласяваме. И така, да се върнем към дискусията на Робин, защото, знаете, не е случайно, че RedPoint е тук и SAS е тук. Тъй като RedPoint, ние наистина се фокусираме върху данните от него върху управлението, върху обработката на данните и подготовката за използване в аналитиката. И така, позволете ми да се преместя през тези два слайда. И наистина да поговорим и да разберем по темата на Робин за MDM и колко е важно и колко полезно, мисля - и според нас - Hadoop може да бъде в света на MDM и качеството на данните.
Знаеш ли, Робин говореше малко, знаеш как това е свързано със света на хранилището на корпоративни данни и идвам - знаеш ли, прекарах няколко години в Accenture. И това, което беше интересно е, колко пъти трябваше да влизаме във фирми и да се опитваме да разберем какво да правим със склада за данни, който по принцип беше изоставен. И много от това се случи, тъй като екипът на хранилището на данни всъщност не приведе в съответствие своите бизнес сгради или потребителите на данните. Или просто отне толкова дълго време, че до момента, в който са построили нещата, се е развило използването на бизнеса или бизнес обосновката за него.
И едно от нещата, които според мен са толкова развълнувани, идеята да използвам Hadoop за главно управление на данни, за качество на данните и за подготовка на данни, е фактът, че винаги можете да се върнете към атомните данни в Hadoop данни езеро или резервоар за данни, хранилище за данни или център, или каквато форма на шум искате да използвате. Но тъй като винаги пазите тези атомни данни, винаги имате възможност да се приведете в съответствие с бизнес потребителите. Защото като анализатор - понеже всъщност започнах кариерата си на статистик - знаете, нищо не е по-лошо от това, знаете, складовете с корпоративни данни са прекрасни за управление на отчетите, но ако искате да направите наистина прогнозна анализа, те са наистина не е толкова полезно, защото това, което наистина искате, са подробните поведенчески данни, които по някакъв начин са обобщени и обобщени в хранилището с данни. Така че аз мисля, че това е наистина важна характеристика и това е едно нещо, което мисля, че може да не съм съгласен с Робин, е че аз лично бих оставял данни в езерото с данни или в центъра за данни възможно най-дълго, защото толкова дълго, колкото данните са там и са чисти, можете да го погледнете от една посока, в друга посока. Можете да го обедините с други данни. Винаги имате тази възможност да се върнете към нея и да преструктурирате, а след това да се приведете в съответствие с бизнес единица и нуждата, която този отдел може да има.
Един от другите видове интересни неща в това е, че тъй като това е толкова мощна изчислителна платформа, голяма част от това натоварване, за което говорихме, виждаме, че всичко идва направо в Hadoop. И докато, мисля, Майк говори за всички различни технологии, които съществуват там в света - в този тип екосистема с големи данни, ние смятаме, че Hadoop наистина е работният кон, който прави този голям мащаб в изчислително интензивна обработка, която изискват главните данни и качеството на данните. Защото, ако можете да го направите там, знаете, само чистата икономия на преместване на данни от скъпите ви бази данни и в икономични бази данни, това наистина води до голяма част от усвояването в момента в големите предприятия.
Сега, разбира се, има някои предизвикателства, нали? Около технологиите има предизвикателства. Много от тях са много незрели. Бих казал, знам, не знам колко, но редица технологии, за които Майк спомена, все още са в нулева точка - нещо издание, нали? Така че, тези технологии са много млади, много незрели, все още базирани на код. И това наистина създава предизвикателство за предприятията. И ние наистина се фокусираме върху решаването на проблеми на ниво предприятие. И така, ние смятаме, че трябва да има различен начин и това е, което предлагаме, е различен начин за разглеждане на някои от нещата при използването на някои от тези съвсем зараждащи се технологии.
И така, и след това другият интересен проблем тук, който беше споменат по-рано, който е, когато имате данни, които улавяте в Hadoop среда от какъвто и да е тип, знаете, обикновено това е схема за четене, а не схема при запис с някои изключения. И това четене, много от него се правят от статистиците. И така, статистиците трябва да разполагат с инструменти, които им позволяват правилно да структурират данните за аналитични цели, защото в края на деня, за да направят данните полезни, той трябва да бъде структуриран под някаква форма, за да ги види или да отговори на въпрос или бизнес, някакъв вид бизнес, създават бизнес стойност.
И така, там, където влизаме, е, че имаме много широко-базиран и зрял EPL, ELT главен ключ за качество на данните и приложение за управление. Тя е на пазара от много, много години. И има цялата функционалност или голяма част от функционалността, която Робин изброи в тази кръгова графика - всичко - от просто чисто заснемане на сурови данни в най-различни формати и XML структури и какво ли още не, до възможността да се извърши всичко почистване, попълване на данните, корекция на данните, геопространствени битови ядра на данните. Това е нещо, което става все по-важно в наши дни с Интернет на нещата. Знаеш ли, има голяма география, свързана с голяма част от това, което правим или голяма част от тези данни. И така, целият анализ, токенизацията, изчистването, корекцията, форматирането, структурирането и т.н., всичко това се прави в нашата платформа.
И тогава и може би се сещаме за най-важното е идеята за дедупликацията. Знаеш ли, че в основата, ако разгледаш каквото и да е определение за управление на главни данни, ядрото на него е дедупликацията. Той ще може да идентифицира обекти в различни източници на данни и след това да създаде главен запис за това образувание. И това образувание може да бъде човек. Предприятието може да бъде част от самолет, например. Субектът може да бъде храна, каквато сме направили за един от клиентите на нашия здравен клуб. Създадохме основна база данни за храни за тях. Така че, каквито и да са субектите, с които работим - и разбира се, все по-често, има хора и пълномощници за тяхната идентичност, които са неща като социални дръжки или акаунти, каквито и устройства да са свързани с хора, някои неща като коли и телефони и всичко друго, което може да си представите.
Знаете, работим с клиент, който влага всякакви сензори в спортно облекло. И така, данните идват от всяка посока. И по един или друг начин това е отражение или представяне на основното образувание. И все повече това са хората и способността да се идентифицират връзките между всички тези източници на данни и как те се отнасят към тази основна единица, а след това да можете да проследявате тази основна единица във времето, така че да можете да анализирате и разберете промените между това образувание и всички онези други елементи, които са в представите на това образувание, наистина критични за дългосрочен и надлъжен анализ на хората, например. И това наистина е едно от наистина важните предимства, които според мен големите данни могат да ни донесат са много по-добро разбиране на хората и в дългосрочен план и разбиране на кон и как хората се държат, когато се държат чрез какви устройства и т.н. ,
Така че, позволете ми да се придвижа бързо тук. Ерик спомена Прежда. Знаеш ли, аз го хвърлям само за малко, защото докато ПРЕЖДА - хората говорят за ПРЕЖДА. Все още има много невежество, според мен, за ПРАЖДА. И наистина не много хора - все още има много неразбиране за ПРЕЖДА. И факт е, че ако приложението ви е било архитектирано по правилния начин и имате правилното ниво или паралелизация в архитектурата на приложението си, тогава можете да се възползвате от YARN, за да използвате Hadoop като своя платформа за мащабиране. И точно това сме направили.
Знаете ли, отново, само за да посочите някои от определенията около ПРЕЖДА. За нас наистина това, което е YARN, ни даде възможност за себе си и други организации да станем връстници на MapReduce и Spark, както и всички други инструменти, които са там. Но факт е, че нашите приложения задвижват оптимизиран код директно в YARN в Hadoop. Има един наистина интересен коментар, който Майк спомена, защото, знаете, въпросът за аналитиката и нашата анализа, само защото те са в клъстера, наистина ли работят паралелно? Можете да зададете същия въпрос за много от инструментите за качество на данните, които са там.
През по-голямата част от деня качествените инструменти, които са там, или трябва да извадят данните, или те въвеждат код. И в много случаи това е един поток от данни, който се обработва поради начина, по който трябва да сравнявайте записи, понякога по видове дейности с качество на данните. И факт е, че тъй като използваме YARN, ние наистина успяхме да се възползваме от паралелизацията.
И само за да ви дам бърз преглед, защото се прави още един коментар за важността да можем да разширим традиционните бази данни, новите бази данни и т.н., които внедряваме или инсталираме извън клъстера. И натискаме нашите двоични файлове директно в ресурсния мениджър, ПРЕЖДА. И това, и след това YARN го разпределя по възлите в клъстера. И това, което прави, е, че ПРАВАТА - ние позволяваме на YARN да управлява и да върши своята работа, която е да разберем къде са данните и да вземем работата към данните, кода към данните и да не движим данните наоколо. Когато чуете инструменти за качество на данните и ви казват, че най-добрата практика е да преместите данните от Hadoop, бягайте за живота си, защото това не е точно така. Искате да отнесете работата към данните. И това е, което първо прави ПРАВО. Той извежда нашите двоични файлове до възлите, където се намират данните.
И също така, тъй като сме извън клъстера, можем също така да имаме достъп до всички традиционни и релационни бази данни, така че да можем да имаме работни места, които са 100% клиентски сървър в традиционна база данни, 100% Hadoop или хибридни задачи, които преминават през клиентския сървър на Hadoop , Oracle, Teradata - каквото си искаш и всички в една и съща работа, защото това изпълнение може да има достъп до двете страни на света.
И тогава, връщайки се към цялата идея за зараждането на инструментите, виждате тук, това е просто обикновено представяне. И това, което се опитваме да опростим света. И начинът, по който го правим е, като внасяме много широк набор от функционалности около HDFS, за да го направим ... И това не е, защото се опитваме да премахнем всички иновативни технологии там. Просто предприятията се нуждаят от стабилност и не харесват решения, базирани на кодове. И така, това, което се опитваме да направим, е да дадем на предприятията позната, повтаряема се и последователна среда за приложение, която им дава възможност да изграждат и обработват данни по много предсказуем начин.
Бързо това е вида на въздействието, което получаваме с нашето приложение. Виждате MapReduce срещу Pig срещу RedPoint - няма редове с код в RedPoint. Шест часа разработка в MapReduce, три часа развитие в Pig и 15 минути развитие в RedPoint. И точно там имаме наистина огромно влияние. Времето за обработка също е по-бързо, но времето на хората, времето за продуктивност на хората, значително се увеличава.
И последният ми слайд тук, искам да се върна към тази идея, защото това е нашето използване на езеро с данни или център за данни или рафинерия за данни като централна точка на поглъщане. Не можех да се съглася повече с тази идея. В момента сме в дискусии с много главни служители по данни на големи световни банки и това е архитектурата на избор.Поглъщането на данни от всички източници прави обработката на качеството на данните и овладява управлението на данните вътре в езерото с данни и след това избутват данни там, където е необходимо, за да отидат за поддръжка на приложения, да поддържат BI, каквото и да е това. И тогава, ако имате анализи в BI, те могат да работят директно в езерото с данни, където е още по-добре, което може да започне веднага. Но много на борда с тази идея. Тази топология тук е тази, която откриваме, че печелим много сцепление от пазара. И това е.
Ерик: Добре, добре. Нека се движим точно тук. Ще продължа напред и ще го предам на Кийт. И, Кийт, имаш около 10, 12 минути, за да разтърсиш къщата тук. Трябваше да продължим малко дълго в тези предавания. И рекламирахме 70 минути за тази. Така че, просто продължете напред и кликнете навсякъде върху този слайд и използвайте стрелката надолу и я отнесете.
Кийт: Разбира се. Няма проблем, Ерик. Оценявам го. Ще продължа напред и ще ударя само няколко парчета за SAS, след което ще преминем, направо в технологичните архитектури, където SAS се пресича със света на големите данни. Във всички тези неща има много неща за обяснение. Бихме могли да прекараме часове, преглеждайки го с подробности, но десет минути - трябва да можете да се разхождате само с кратко разбиране за това къде SAS е взел технологии за анализи, управление на данни и бизнес разузнаване в този свят с големи данни.
Първо, само малко за SAS. Ако не сте запознати с тази организация, ние през последните 38 години правим напреднали анализи, бизнес разузнаване и управление на данни с не само големи данни, но и малки данни и богатство на данни през последните 38 години. Имаме огромен съществуващ клиент, около 75 000 сайтове по целия свят, които работим с някои от най-добрите организации там. Ние сме частна организация с около 13 000 служители и 3 милиарда долара приходи. И наистина наистина, предполагам, важната част е, че традиционно сме имали дългогодишна история за реинвестиране на значителни суми от нашите приходи обратно в нашата научноизследователска и развойна организация, което наистина е довело до носенето на много от тези невероятни технологии и платформи. “ ще видим днес.
И така, ще скоча право в тези наистина страшни архитектурни диаграми. Ще работим от ляво на дясно в моите слайдове. Така че има познати неща, които ще видите в тази платформа. От лявата страна всички онези източници на данни, за които говорим, постъпваме в тези големи платформи за данни. И тогава, имате тази голяма платформа за данни.
Не съм сложил думата Hadoop там най-отгоре, защото в крайна сметка примерите, които днес ще дам, са конкретно около всички технологии, където се пресичат с тези големи платформи за данни. Hadoop просто се оказва един от тези, при които имаме някои от най-стабилните опции за внедряване, но също така пресичаме доста и сме разработили доста от тези технологии за известно време с някои от нашите други партньори за съхранение на корпоративни данни като Teradata, Oracle, Pivotal и други подобни. Така че, не мога да изпадам в подробности, тъй като всички различни технологии се поддържат на коя платформа, но просто бъда уверен, че всички, които описвам днес, са предимно всичко, което Hadoop и огромно количество от тях се пресичат с други технологични партньори, които ние имаме. Имаме толкова голяма платформа, която седи там.
Следващият точно вдясно, имаме нашия аналитичен сървър SAS LASR. Сега това по същество е масово успореден в сървъра за приложения за аналитична памет. Бихме ясни, че това не е база данни в паметта. Наистина е проектиран отначало. Това не е двигателят на заявките, но е създаден да обслужва аналитични заявки в масивен мащаб по масов паралелен начин. Това са приложенията на служебните ключове, които виждате от дясната страна.
Ще разгледаме малко повече неща, знаете как хората разгръщат тези неща. Но по същество приложението - виждате ли там - първото, е нашата високоефективна анализа на SAS. Това ще бъде - използвам много от съществуващите ни технологии и платформи като Enterprise Miner или просто SAS, а не просто правя многопоточност с някои от тези алгоритми, които сме вградили в тези инструменти, които сме направили за години, но и масово успоредни на тези. Така че, за да преместите данните от тази голяма платформа за данни в пространството на паметта към този LASR аналитичен сървър, така че да можем да изпълняваме аналитични алгоритми - знаете ли, много от новото машинно обучение, невронни мрежи, произволни горски регресии, такива видове неща - отново данните, седнали в паметта. И така, да се отървем от това определено затруднително място в парадигмата MapReduce, където ние ще бъдем подадени до тези платформи, това не е начинът, по който искате да правите аналитична работа. Така че, ние искаме да можем да вдигнем данните еднократно в пространството на паметта и да повторите през него, знаете ли, понякога хиляди пъти. Това е концепцията за използване на този високоефективен аналитичен LASR сървър.
Ние също - другите приложения под него, визуалната анализация, която ни позволява да запазим тези данни в паметта и да обслужваме по-голяма популация на същите данни. Така че, позволявайки на хората да правят големи данни за проучване. Така че, преди да работим за разработването на модела си, ние изследваме данните, разбираме ги, пускаме корелации, правим прогнози или тенденции на дървета с решения - такива неща - но по много визуален, интерактивен начин за данни, които седят в паметта платформа. Това също обслужва нашата BI общност, доколкото има много широки бази от потребители, които могат да достигнат тази платформа, за да правят стандартни видове записи, които виждате - което е почти всеки, знаете ли, BI доставчик там.
Следващата стъпка преминаваме в сервиз. И за да помогнем на нашите статистици и нашите аналитици да могат да правят такъв вид ad-hoc моделиране с данни, седнали в паметта, отстранени от визуална анализа и проучване в нашето приложение за визуална статистика. Това е възможност хората да вземат, да не пускат статистически данни в партиди, които преди да повтарят итератират, пускат моделите, вижте резултатите. Така че това може да стартира модела, вижте резултатите. Това е за визуално плъзгане и пускане в интерактивно статистическо моделиране. Така че това обслужва нашите статистици и нашите учени с данни да свършат много от тази ранна проучвателна визуална статистика.
И тогава, ние не сме забравили нашите кодери - хората, които наистина искат да имат, да могат да отлепят слоевете на интерфейса срещуположно, е да пишат приложения и да напишат своя собствена кодова база в SAS. И това е нашата статистика на паметта за Hadoop. И това е - по същество кодовият слой, който ни позволи да взаимодействаме с този аналитичен LASR сървър за директно издаване на команди и персонализиране на тези приложения въз основа на нашата заявка. Това е аналитичното парче.
Как се настройват тези неща ... Ами сега, съжалявам, момчета. Ето.
Така че, има наистина няколко начина, по които правим това Единият е да го направите с големи данни - в случая с Hadoop. И точно тук имаме онзи SAS LASR Analytic Server, работещ в отделен куп машини, оптимизирани за хардкор аналитики. Това е добре сгушено и близо до платформата за големи данни, което ни позволява да го мащабираме отделно от платформата за големи данни. И така, виждаме хората да правят това, когато не искат да имат нещо, което аз характеризирам като софтуер за вампири, изяждащ се във всеки от възлите в своя клъп Hadoop. И не е задължително мащабирането на тази платформа за големи данни, подходяща за извършване на тежки анализи на паметта. Така че може да имате 120 възли от техния клъстер Hadoop, но те могат да имат 16 възли от аналитични сървъри, които са проектирани да вършат такава работа.
Все още ни е позволено да поддържаме този паралелизъм от платформата за големи данни, за да дърпаме данните в паметта. Така че, това наистина е използващ SAS с платформата Hadoop. Тогава различен модел за назначаване е да кажем, добре, че можем да използваме и тази стокова платформа и да прокараме това - по същество стартирайте Analytic LASR Server на платформите Hadoop. И така, ние сме тук ... вие работите в платформата за големи данни. Това са и някои други наши доставчици на уреди. Така че това ни позволява по същество да използваме тази стокова платформа, за да вършим тази работа.
Виждаме, че по-често с неща като високоефективна аналитика, при която това е аналитичен цикъл с едно обслужване или еднократна употреба, по-вид ориентирана към партида, където сте - не искате непременно да консумирате пространството на паметта в Hadoop платформа. Ние сме много гъвкави в този вид модел на внедряване, определено в нашата работа с YARN в много от тези случаи, за да сме сигурни, че играем хубави клъстери.
Добре, така че това е аналитичният свят, само за да е ясно с аналитичното приложение. Но споменах, че SAS в самото начало също е платформа за управление на данни. И има неща, които са подходящи, за да вкарате логиката в тази платформа, когато е уместно. И така, има няколко начина, по които правим това. Единият е в света на интеграцията на данни, извършването на работа по преобразуване на данни може да няма смисъл да го изваждаме назад, както чухме преди, изпълнявайки рутини за качество на данните, които са големи. Искаме определено да избутаме неща като рутинни за качеството на данните надолу в тази платформа. И след това, неща като оценяване на модела. И така, разработих своя модел. Не искам да пренаписвам това нещо в MapReduce и да ми е трудно и отнема много време да преработя тази работа в родната платформа на базата данни.
Така че, ако погледнете например нашия ускорител за оценка на Hadoop, който ни позволява по същество да вземем модел и да избутаме математическата логика на SAS надолу в тази платформа Hadoop и да я изпълним там, използвайки паралелизма, който е в тази голяма платформа за данни. След това имаме своя ускорител на кодове за различни платформи, включително Hadoop, и това ни позволява по същество да изпълняваме стъпков код на SAS данни вътре в платформата по масовски успореден начин - така че извършването на трансформация на данни работи в платформата. И след това нашият ускорител за качество на SAS, който ни позволява да разполагаме с база знания за качество, която да прави неща като съвпадение на пола, код за съвпадение на стандартизация - всички различни неща за качество на данните, които чухте вече днес.
И тогава, последно парче, има Data Loader. Ние знаем, че нашите бизнес потребители ще трябва да могат да не пишат код и да работят преобразуването на данни в тези големи платформи за данни. Data Loader е приятен WYSIWYG GUI, който ни позволява да обгърнем тези други технологии заедно. Това е като съветник за преминаване, да речем, да стартирате запитване в Hive или да изпълните рутина за качество на данните и не е необходимо да пишете код в този случай.
Последното нещо, което ще спомена е това предно парче. Имаме - както споменах преди - масивен крак SAS там по света. И това не можем просто задължително да направим всички онези платформи, които са там, да бъдат незабавно в това пространство. Така че, ние определено имаме съществуващ крак от потребители, които трябва да получат данни, седнали в тези големи платформи за данни, като например извеждане на данни от Teradata и връщането им обратно в Hadoop, и обратно. Стартиране на моделите вече знам как да стартирам на сървърите си SAS, но трябва да получа данни, които сега се поставят в платформата Hadoop. Така че, има тази друга малка икона там, наречена „от“, и която ни позволява да се свързваме, използвайки нашите SAS двигатели за достъп - двигатели за достъп до Hadoop до Cloudera в Пола, към Teradata, към Greenplum до… И списъкът продължава. Това ни позволява да използваме съществуващите си зрели платформи SAS, които вече са налични, за да получим данни от тези платформи, да свършим работата, която трябва да свършим, да изтласкаме резултатите обратно в тези области.
Последното нещо, което ще спомена е, че всички тези технологии, които виждате, се управляват от едни и същи стандартни метаданни. Така че, ние говорим за получаване на работа по преобразуването, за правилото за качество на данните при работа, за преместването му в паметта, за да можем да правим анализи, разработване на модел в оценката. Там имаме целия аналитичен начин на живот, жизнения цикъл, управляван от общи метаданни, от управление, от сигурност, от всички неща, за които говорихме по-рано днес.
Така че, само резюме, има наистина тези три големи неща, които да вземете там. Единият е, че можем да третираме платформата за данни, както всеки друг източник на данни, издърпвайки от тях, натискайки към тях, когато е подходящо и удобно. Можем да работим с онези големи платформи за данни, изброявайки данните в специално изградена разширена аналитика в платформата за памет. Това е LASR сървърът.
И после, последно, можем да работим директно в тези големи платформи за данни, използвайки своите възможности за дистрибуционна обработка, без да движим данните наоколо.
Ерик: Е, това са фантастични неща, хора. Да, това е страхотно! Така че, нека се потопим право на някои въпроси. Обикновено ходим около 70 минути или малко повече на тези събития. Така че, виждам, че все още имаме страхотна публика, която седи там. Джордж, предполагам, че ще ти предам първия въпрос. Ако говорите за изтласкване на двоичния си звук в Hadoop, мисля, че това ми звучи, като че наистина сте оптимизирали изчислителния работен процес. И това е целият ключ, за да можем да правим такива видове управление на данни в реално време, постижения в качеството на данните, защото това е ценността, която искате да получите, нали? Ако не искате да се върнете в стария свят на MDM, където е много тромав и отнема много време, и наистина трябва да принуждавате хората да действат по определени начини, което почти никога не работи. И така, това, което сте направили, сте съкратили цикъла на това, което е било. Да го наречем дни, седмици, понякога дори месеци до секунди, нали? Това ли се случва?
Джордж: Това е точно така, защото мащабът, който получаваме и ефективността, която получаваме от клъстер, е наистина потресаващ по отношение на, просто, знаете ли, аз винаги съм малко колеблив по отношение на показателите. Но само за реда на величината, когато щяхме да пуснем милиард, 1,2 милиарда записи и да извършим пълна стандартизация на адреси - казвам, машина на HP от среден клас - ще отнеме, като, знаете, осем процесорни машини, знаете ли , 2 гига RAM на ядро, знаете, това ще отнеме 20 часа, за да стартирате. Можем да направим това след около осем минути в клъстер с 12 възли. И така, мащабът на обработката, който можем да извършим сега, е толкова драматично различен, че - и много добре отива на идеята, че имате всички тези данни на ваше разположение. Така че, не е толкова рисковано да се извърши обработката. Ако сте го направили погрешно, можете да го повторите. Имаш време, знаеш. Това наистина промени мащаба на това, където, знаете ли, тези видове рискове наистина се превърнаха в истински бизнес проблеми за хората, когато се опитваха да работят с MDM решения. Трябва да имате 30 души в офшорка, които да управляват данни и всичко останало. И така, все още трябва да имате част от това, но скоростта и мащабът, с който можете да го обработите сега, наистина ви дават много повече място за дишане.
Ерик: Да, това е наистина много добър момент. Обичам този коментар. Така че, имате време да го преработите отново. Това е фантастично.
Георги: Да.
Ерик: Е, това променя динамиката, нали? Това променя начина, по който мислите за това, което ще опитате. Искам да кажа, спомням си това преди 18 години в индустрията да правя специални ефекти, защото имах клиент, който беше в това пространство. И ще натиснеш бутоните, за да го направи и ще се прибереш. И ще се върнете, може би в събота следобед, за да видите как става. Но ако сте сгрешили, това беше много, много, много болезнено. И сега не е почти - дори не е толкова болезнено, така че имате възможност да опитате още неща. Трябва да кажа, мисля, че това е наистина много добър момент.
Джордж: Точно така. Да, и издухваш допълнителния си крак. Знаеш ли, минаваш на половината работа през старите времена и тя се проваля, взривил си SOS. Това е.
Ерик: Точно така. И вие сте в големи проблеми, да. Това е вярно.
Джордж: Точно така. Това е вярно.
Ерик: Кийт, позволете ми да го прехвърля. Спомням си, че направих интервю с вашия CIL, Кийт Колинс, вярвам, че отново, мисля, 2011 г. може би. И той говори много за посоката, която SAS предприема конкретно по отношение на работата с клиенти, за да вгради аналитиката, получена от SAS, в операционните системи. И разбира се, чухме Майк Фъргюсън да говори за важността на запомнянето. Цялата идея тук е, че искате да можете да свържете тези неща във вашите операции. Не искате анализ във вакуум, изключен от предприятието. Това няма никаква стойност.
Ако искате анализ, който може директно да повлияе и оптимизира операциите. И ако погледна назад - и трябва да кажа, реших, че тогава е добра идея - в ретроспекция изглежда като наистина много умна идея. И предполагам, това е истинско предимство, което вие имате И разбира се, това голямо наследство, тази огромна инсталационна база и фактът, че сте били съсредоточени върху вграждането на тези аналитични данни в операционните системи, което означава, че сега - и при условие, ще отнеме известна работа - сигурен съм, че работих по него доста усилено. Но сега можете да използвате всички тези нови иновации и наистина сте в състояние да оперирате всички тези неща с вашите клиенти. Това справедлива оценка ли е?
Кит: Да, абсолютно. Идеята е, че получавате тази идея за проектиране на решения или науки за решения, което е, в известна степен, това е проучвателно, научно-уж нещо. Освен ако не можете да направите инженеринг на процеса наистина ... Ако мислите за разработването на автомобил, имате дизайнери, които правят този красив автомобил, но това е, докато инженерите не поставят този план на място и направят реално жизнеспособен продукт преди вас може действително да постави нещата на мястото си и това е по същество това, което SAS направи. Той е обединил решенията - процес на вземане на решения заедно с процеса на проектиране на решения заедно, така че когато говорите за ускорителите, конкретните акселератори за оценка, ако знаете, ако вземете разработен от вас модел и ще можете да го избутате до Teradata или го изкарайте до Oracle или до Hadoop, с нулев престой за разработка на модел, до внедряване на модел. Това е ключовото, тъй като моделите се разграждат с времето, точността на тези модели. И така, колкото повече време отнемете това и да го пуснете в производство, това е загуба на точност на модела.
И тогава, другото парче е, искате да можете да наблюдавате и управлявате този процес във времето. Искате да остарите моделите, когато остареят и неточни. Искате да го разгледате, да проверите точността на тях във времето и да ги изградите отново. И така, ние имаме инструменти за управление на модели, които също се намират върху това, които наистина проследяват метаданните около моделирания процес. И хората са казали, че моделирането, знаете ли, тази концепция е като фабрика за модели, или каквото искате да я наречете. Работата е там, че въвеждаме метаданни и управление в процеса и точно тук са трите големи неща, които постигаме - помагаме на хората да правят пари, спестяваме пари и ги държим извън затвора.
Ерик: И този последен е доста голям. Искам да избегна всичко това. Така че, нека да поговорим за ...Задавам един последен въпрос, може би всеки от вас може да скочи върху това. Хетерогенността на нашия свят само ще се увеличи, струва ми се. Мисля, че определено ще видим някаква кристализация около хибридни облачни среди. Но въпреки това, вие ще видите много от основните играчи да стърчат. IBM не отива никъде. Oracle не отива никъде. SAP не отива никъде. И има толкова много други доставчици, които участват в тази игра.
Също така от оперативната страна, където имате буквално хиляди и хиляди различни видове приложения. И чух - повечето от вас говорят за това, но мисля, че и двамата бихте се съгласили с казаното от мен. Вече виждаме тази тенденция по отношение на изчислителната мощност в аналитичните двигатели, архитектурата. Компаниите от години говорят за възможността да се включат в другите двигатели и да обслужват нещо като оркестрация. И предполагам, Джордж, първо ще ти го хвърля. Струва ми се, че това е нещо, което няма да се промени. Ще имаме тази разнородна среда, което означава, че има неща като CRM в реално време и качеството на данните и управлението на данните. Като доставчик ще трябва да се свържете с всички тези различни инструменти. И това е, което клиентите искат. Те няма да искат нещо, което да се оправи с тези инструменти и не е толкова добре с тези инструменти. Те ще искат Швейцария на MDM и CRM, нали?
Джордж: Точно така. И е интересно, защото ние много го приехме. Част от него е историята, която имахме в космоса. И очевидно вече работихме върху всички останали бази данни, Терадатите и частите на света. И след това, направихме - в процеса на внедряване, по-точно по начина, по който го направихме, само за да го направим - имате този обхват във всички тези различни бази данни. Едно от нещата, които ми се струват интересни е, че ние имаме някои клиенти, които са просто адаптирани към премахването на всички релационни бази данни. И това е интересно Знаеш, искам да кажа, че е добре. Интересно е. Но просто не виждам, че това наистина се случва в мащаб на големи предприятия. Не виждам това да се случва от дълго време. Така че, мисля, че хибридът е тук от доста дълго време и от другата страна на нашето приложение, където в нашата платформа за управление на кампании имаме нашата платформа за съобщения. Всъщност сме го проектирали специално. Сега пуснахме версия, която прави това и която вече може да се свърже с хибридната среда за данни и да запитва Hadoop или да запитва всяка база данни, всяка аналитична база данни. Така че мисля, че това е само вълната на бъдещето. И аз съм съгласен, че виртуализацията със сигурност ще играе голяма роля в това, но ние сме просто - отиваме веднага към данните на всички наши приложения.
Ерик: Добре, страхотно. И, Кийт, ще ти го прехвърля. Какво мислите за разнородния свят, с който се сблъскваме в ролята на крака?
Кит: Да, наистина е очарователно. Мисля, че това, което намираме повече - не само в страната на управлението на данни - но това, което наистина е завладяващо в момента, е природата на аналитичната база с отворен код. И така, виждаме организации като или технологии като Spark, които се появяват на борда, и хора, които използват Python и R и всички тези други технологии с отворен код. Мисля, че това може да се тълкува като някакъв конфликт или заплаха до известна степен. Но реалността е, че имаме някои наистина прекрасни комплименти с всички тези технологии с отворен код. Искам да кажа, за един, ние работим върху платформи с отворен код, за Бог.
Но също така, като да можете да интегрирате, например, R модел в парадигма SAS ви позволява да използвате най-доброто от двата свята, нали? Както знаем, така че знаем, че някои от експерименталните неща в академичния свят и някои от работата по разработването на модела са изключително и много полезни в процеса на разработване на модела. Но също така, ако можете да го сдвоите с инструмент от производствен клас, той прави много от почистването и качеството и проверява и се уверява, че данните, предаващи се в модела, са подготвени правилно, така че да не се провалят при изпълнение. И след това, да можете да правите неща като шампионски модели предизвикатели с модели с отворен код. Това са нещата, които гледаме да дадем възможност, и като част от тази наистина разнородна екосистема на всички тези технологии. Да, така че е повече - за нас е по-скоро да възприемем тези технологии и да търсим комплиментите.
Ерик: Това са фантастични неща, хора. Ние отидохме малко по-дълго тук, но бихме искали да стигнем до възможно най-много въпроси. Ще препратим файла с въпроси и отговори на нашите презентатори днес. Така че, ако на всеки въпрос, който сте задали, не е отговорен, ще се погрижим да получи отговор. И хора, това приключва за 2014 г. Наистина в DM Radio утре и следващата седмица, а след това всичко е готово и е почивка за празници.
Толкова много благодаря на всички вас за отделеното време и внимание, за преливането през всички тези прекрасни уеб предавания. Имаме страхотна година за 2015 г. И ще поговорим с вас скоро, хора. Благодаря отново. Ще се погрижим. Чао чао.