Содержание
Источник: Якуб Джирсак / Dreamstime.com
вынос:
Ведущий Эрик Кавана обсуждает аналитику больших данных с экспертами отрасли.
Эрик: Дамы и господа, это конец 2014 года - по крайней мере, почти. Это наша последняя веб-трансляция в этом году, ребята! Добро пожаловать в TechWise! Да, в самом деле! Меня зовут Эрик Кавана. Я буду вашим модератором для потрясающей трансляции, ребята. Я очень, очень взволнован. У нас есть два замечательных онлайн-аналитика и две замечательные компании - настоящие новаторы во всей этой экосистеме больших данных. И мы будем говорить о том, что ключом к анализу больших данных является понимание различий. Итак, давайте идти дальше и нырнуть прямо, ребята.
У нас есть несколько докладчиков. Как вы видите, на самом деле ваша верхушка. Майк Фергюсон звонит по всему пути из Великобритании, где ему пришлось получить особые привилегии, чтобы остаться в своем офисном здании так поздно. Вот так поздно для него. У нас есть доктор Робин Блур, наш собственный главный аналитик в Bloor Group. У нас будут Джордж Коругедо, генеральный директор и соучредитель RedPoint Global, и Кит Ренисон, старший архитектор решений из Института SAS. Это фантастические компании, ребята. Это действительно инновационные компании. И мы собираемся углубиться в некоторые хорошие моменты того, что происходит сейчас во всем мире больших данных. И давайте посмотрим правде в глаза, небольшие данные не исчезли. И на этом позвольте мне дать мое резюме здесь.
Итак, есть старое французское выражение: «Чем больше вещи меняются, тем больше они остаются неизменными». И давайте посмотрим правде в глаза на некоторые факты - большие данные не решат проблемы небольших данных. Корпоративные небольшие данные все еще там. Это все еще везде. Это топливо операций для современной информационной экономики. И большие данные предлагают комплимент этим так называемым маленьким корпоративным данным, но они не вытесняют маленькие данные. Это все еще будет вокруг. Мне действительно нравится многое из больших данных, особенно такие, как сгенерированные компьютером данные.
И сегодня мы, вероятно, немного поговорим о данных в социальных сетях, что тоже очень важно. И если вы думаете, например, о том, как социальные сети изменили бизнес, просто подумайте о трех быстрых веб-сайтах здесь: LinkedIn и. Подумайте о том, что пять лет назад никто не занимался такими вещами. является абсолютным безжалостным в эти дни. , конечно, огромен. Это гигантский. Кроме того, LinkedIn является стандартом де-факто для корпоративных сетей и коммуникаций. Эти сайты огромны, и чтобы иметь возможность использовать данные, которые в них содержатся, он оживит некоторые изменяющие игру функциональные возможности. Это действительно принесет много пользы многим организациям - по крайней мере, тем, которые используют это в своих интересах.
Нет ошибок, нет стресса - ваше пошаговое руководство по созданию изменяющего жизнь программного обеспечения без разрушения вашей жизни
Вы не можете улучшить свои навыки программирования, когда никто не заботится о качестве программного обеспечения.
Итак, управление - управление все еще имеет значение. Опять же, большие данные не отменяют необходимость управления. Откровенно говоря, совершенно необходимо сосредоточиться на том, как управлять миром больших данных. Как вы убедитесь, что у вас есть свои процедуры и политики на месте; что правильные люди получают доступ к нужным данным; что у вас есть контакты, у вас есть участие здесь? Вы на самом деле знаете, откуда поступают данные, что с ними произошло. И это все меняется.
Я, честно говоря, действительно впечатлен тем, что я увидел во всем этом новом мире, использующем экосистему Hadoop, которая, конечно, намного больше, чем хранилище с точки зрения функциональности. Hadoop также является вычислительным движком. И компания должна выяснить, как использовать эту вычислительную мощность, эти возможности параллельной обработки. Они собираются делать действительно классные вещи. Мы узнаем об этом сегодня.
Еще одна вещь, которую стоит упомянуть, это то, о чем доктор Блур говорил в недавнем прошлом, это то, что волна инноваций еще не закончилась. Итак, мы видели много внимания, конечно, вокруг Hadoop. Знаете, мы видели такие компании, как Cloudera и Hortonworks, которые действительно делают несколько волн. И они, откровенно говоря, развивают партнерские отношения с компаниями, находящимися на связи сегодня. И они развивают партнерские отношения со многими людьми. Но волна инноваций не закончилась. Есть больше проектов, выходящих из Apache Foundation, которые меняют не только конечную точку, если хотите, приложения, которые используют люди, но и саму инфраструктуру.
Таким образом, вся эта разработка YARN - еще одного участника переговоров о ресурсах - действительно похожа на операционную систему для больших данных. И это большое, большое дело. Итак, мы собираемся узнать, как это тоже меняет вещи. Итак, всего пара ясных советов, будьте осторожны с продолжающимися контрактами, вы знаете, пяти-, десятилетние контракты станут волной, путем, который мне кажется. Вы хотите избежать блокировки любой ценой. Мы собираемся узнать обо всем этом сегодня.
Итак, наш первый аналитик, выступающий сегодня - наш первый докладчик по всей программе - Майк Фергюсон, звонящий из Великобритании. После этого я передам тебе ключи, Майк, и позволю тебе забрать их. Майк Фергюсон, вам слово.
Майк, ты там? Вы можете быть на немом. Я не слышу его. Возможно, нам придется перезвонить ему. И мы просто подпрыгнем прямо к слайдам Робина Блура. Робин, я собираюсь поднять звание бедного Майка Фергюсона здесь. Я собираюсь пойти на секунду.
Это ты, Майк? Вы нас слышите? Неа. Я думаю, что мы должны идти вперед и идти с Робином в первую очередь. Итак, подождите одну секунду, ребята. Я также потяну несколько ссылок на слайды здесь через пару минут. Итак, позвольте мне передать ключи Робину Блуру. Робин, ты можешь идти первым вместо Майка, а я позвоню Майку через секунду.
Робин: Хорошо.
Эрик: Подожди, Роб. Позволь мне идти вперед и поднять твой слайд, Роб. Это займет секунду.
Робин: Хорошо.
Эрик: Да. Вы можете поговорить о том, с чем мы имеем дело, здесь, с точки зрения управления. Я знаю, что вы собираетесь поговорить об управлении. Об этом обычно думают мошенники из небольших корпоративных данных. Итак, у меня есть слайд, Робин. Ничего не двигай. И вот, пожалуйста. Вам слово. Унеси это.
Робин: Хорошо. Да уж. Я имею в виду, ну, мы вроде как договорились заранее, Майк поговорил об аналитической стороне, а я расскажу об управлении. В определенной степени руководство следует аналитике в том смысле, что это причина того, что вы выполняете большие объемы данных, и причина, по которой вы собираете все программное обеспечение для аналитики, в этом и заключается ценность.
Есть проблема. И проблема в том, что, вы знаете, данные должны быть обработаны. Данные должны быть упорядочены. Данные должны собираться и управляться таким образом, чтобы аналитика проходила с полной уверенностью - я думаю, это слово. Итак, я думал, что буду говорить о том, какова сторона управления в уравнении. Я думаю, на самом деле нужно сказать, что, вы знаете, управление уже было проблемой. Управление уже было проблемой, и оно начинает становиться проблемой во всей игре хранилища данных.
То, что на самом деле произошло, превратилось в гораздо большую проблему. И причина, по которой это превратилось в гораздо большую проблему, а также в большее количество данных, но я имею в виду, что это действительно причины. Количество источников данных значительно расширилось. Раньше источники данных, которые у нас были, в общем и целом определялись тем, что питало хранилище данных. Хранилище данных обычно запитывается системами RTP. Возможно немного внешних данных, немного.
Теперь мы попали в мир, где, как вы знаете, рынок данных появляется прямо сейчас, и, следовательно, будет торговля данными. У вас уже есть множество различных потоковых источников данных, которые вы действительно можете принести в организацию. У нас есть данные соцсетей, которые сняли их, так сказать, за свой счет. Я имею в виду, что огромное значение в социальных сетях на самом деле представляет информация, которую они собирают и поэтому могут сделать доступной для людей.
У нас также есть открытие, вы знаете, как будто они уже существовали. Вы знаете, у нас уже были эти файлы журналов, когда появился Splunk. И вскоре стало очевидно, что в лог-файле есть значение. Итак, внутри организации были данные, которые мы могли бы назвать новыми источниками данных, а также внешними источниками. Итак, это одна вещь. И это действительно означает, что, как вы знаете, какими бы правилами управления данными мы ни занимались ранее, их придется, так или иначе, расширять и продолжать расширять, чтобы фактически управлять данные. Но сейчас мы начинаем собираться так или иначе.
И по этому списку у нас есть потоковая передача и скорость поступления данных. Одна из причин популярности Hadoop, я думаю, в том, что он может использоваться для сбора большого количества данных. Он также может потреблять скорость передачи данных, так что если вам на самом деле не нужно использовать ее немедленно, это хорошая параллельная, огромная параллельная среда. Но у вас также есть тот факт, что сейчас существует довольно много потоковой аналитики. Раньше это были просто банковские сектора, которые были заинтересованы в потоковых приложениях, но теперь они стали глобальными. И каждый смотрит на потоковые приложения, так или иначе, потенциальное средство извлечения выгоды из данных и аналитики для организации.
У нас есть неструктурированные данные. Статистические данные, которые обычно являются частью только 10% мировых данных, хранятся в реляционных базах данных. Так вот, одной из основных причин этого было то, что в основном это было на самом деле неструктурировано, и это было - большая часть этого была в Интернете, но в значительной степени разбросана по различным сайтам. Эти данные оказались также пригодными для анализа и использования. И с появлением технологии Symantec, которая постепенно проникает в ситуацию, становится все больше и больше.Таким образом, существует необходимость в сборе и управлении неструктурированными данными, а это означает, что они намного больше, чем были раньше. У нас есть социальные данные, о которых я уже упоминал, но главное в этом то, что они, вероятно, нуждаются в очистке.
У нас есть данные Интернета вещей. Это какая-то другая ситуация. Скорее всего, таких будет много, но многим придется распространяться где-то рядом с местом, где они работают. Но вы также захотите, так или иначе, задействовать его для анализа данных в рамках организации. Итак, это добавил еще один фактор. И эти данные будут структурированы по-другому, потому что они, вероятно, - вероятно, будут отформатированы в JSON или в XML, так что они объявят себя. И не только тем или иным образом, что мы на самом деле извлекаем данные и можем создать вид схемы для чтения этого конкретного фрагмента данных.
У нас есть проблема провенанса, и это проблема аналитики. Результаты любого анализа данных, которые вы делаете, на самом деле не могут быть - если хотите - одобрены, считаться действительными, если вы не знаете происхождение данных. Я имею в виду, что это просто профессионализм с точки зрения деятельности ученых данных. Но вы знаете, для того, чтобы иметь происхождение данных, это означает, что мы на самом деле должны управлять данными и вести примечание к их происхождению.
У нас есть проблема компьютерных мощностей и параллелей, и все, что мы делаем, это заставляют все идти быстрее. Проблема в том, что, очевидно, определенные процессы, которые мы внедрили, могут быть слишком медленными для всего остального. Таким образом, возможны несоответствия с точки зрения скорости.
У нас появилось машинное обучение. Машинное обучение на самом деле приводит к тому, что аналитика становится игрой, отличной от той, что была раньше. Но вы можете действительно использовать его, только если у вас есть сила.
Мы получили факт новых аналитических нагрузок. У нас есть параллельный мир, и некоторые аналитические алгоритмы должны выполняться параллельно для максимального эффекта. И поэтому проблема на самом деле заключается в том, чтобы управлять тем, как вы, так или иначе, перемещаете данные, делаете их, если они доступны. И где вы на самом деле выполняете аналитические рабочие нагрузки, потому что вы можете делать это в базе данных. Таким образом, вы можете делать это в аналитических приложениях.
Итак, существует целый ряд проблем управления. То, что мы сделали в этом году - исследование, которое мы провели в этом году, было действительно посвящено архитектуре больших данных. И когда мы на самом деле пытаемся обобщить это, вывод, к которому мы пришли - диаграмма, к которой мы пришли, выглядела примерно так.
Я не буду вдаваться в подробности, тем более что Майк собирается немало потрудиться на архитектуре данных для аналитики. Но на самом деле мне нравится, когда люди просто сосредотачиваются на этой нижней области, где мы, так или иначе, собираем данные. У нас есть кое-что, на что я хотел бы сослаться - это центр обработки данных или центр обработки данных. И именно здесь происходит управление. Итак, вы знаете, если мы как-то сфокусируемся, это выглядит так. Вы знаете, это питается данными из внутренних и внешних источников. Хаб должен теоретически принимать все генерируемые данные. Он должен быть либо потоковым, либо управляемым, как и потоковый, если вам нужно выполнять аналитику и потоковую передачу данных, а затем передавать в концентратор. Или иначе, все это входит в центр. И есть много вещей, которые происходят - которые происходят в центре. И вы не можете использовать определенное количество аналитики и SQL в хабе. Но вам также нужна виртуализация данных в каждой ячейке для передачи данных в другие области. Но прежде чем это произойдет, вам, так или иначе, нужно уточнить обработку данных. Вы можете назвать это подготовкой данных. Это намного больше, чем это. Это те вещи, которые, я думаю, включают в себя.
У нас есть управление системой и управление услугами, в том смысле, что это основная часть уровня данных, и нам фактически необходимо применить все усилия по управлению операционными системами, которые мы традиционно делали, практически ко всем операционным системам. Но нам также необходимо, так или иначе, отслеживать другие происходящие события, чтобы убедиться, что эти различные уровни обслуживания выполняются, потому что обязательно должны быть определены уровни обслуживания или любой вид аналитики как выполняемый, или данные BI будучи действующим.
Нам нужен мониторинг производительности и управление. Во всяком случае, нам нужно это для того, чтобы знать, какие дополнительные компьютерные ресурсы нам может потребоваться выделить в различные моменты времени. Но на самом деле здесь очень много рабочей нагрузки, довольно сложной и конкурирующей между собой за ресурсы. Есть что-то довольно сложное, что нужно сделать в этой области.
Теперь мы получили жизненный цикл данных таким образом, которого у нас никогда не было раньше. Сделка здесь на самом деле превыше всего, что мы не собирали данные и не выбрасывали их раньше. Мы собирали данные, которые нам были нужны, и, вероятно, хранили их, а затем архивировали. Но с этого момента мы будем очень много изучать. А если вам не нужны данные, давайте похороним их. Таким образом, жизненные циклы данных - это разные вещи в зависимости от ситуации, но они также будут намного более агрегированными. Следовательно, вы знаете, зная, откуда взялась совокупность, что ... что является источником совокупности, и так далее, и тому подобное. Это все необходимое.
Данные родословной естественно одалживают. Без этого вы должны знать проблемы, поэтому данные… Мы должны знать, что данные действительны, но насколько надежны они на самом деле.
У нас также есть сопоставление данных, потому что большая часть данных будет, так или иначе. И это, если хотите, это в определенной степени относится к МДМ. Просто сейчас все намного сложнее, потому что, когда у вас есть огромное количество данных, определенных JSON или основанных на нашей XML-схеме на чтение, вам нужно, так или иначе, быть очень активным продолжается картографическая деятельность.
Есть ситуация с управлением метаданными, которая больше, чем MDM, потому что необходимо, так или иначе, создать то, что я хотел бы представить сейчас как своего рода хранилище метаданных всего, что вас интересует. Есть метаданные обнаружение, потому что для некоторых данных не обязательно будут объявлены метаданные, и мы хотим использовать их немедленно. И затем, есть очистка данных, которая является огромной вещью как ряд вещей, которые можно сделать там. И безопасность данных тоже есть. Все эти данные должны быть защищены до приемлемого уровня, и это может даже означать в некоторых случаях - например, шифрование многих значений.
Таким образом, вся эта рабочая нагрузка фактически является империей управления. Все это, так или иначе, должно происходить в одно и то же время или раньше, всей нашей аналитической деятельности. Это большое количество согласованных заявок. Это система сама по себе. И затем, те, кто не делают этого в разные моменты времени, будут страдать от нехватки этого по мере продвижения вперед, потому что очень многие из этих вещей на самом деле не являются обязательными. В результате вы просто увеличиваете энтропию, если не делаете этого.
Итак, с точки зрения анализа данных и управления, я бы сказал, что одна рука моет другую. Без управления аналитика и бизнес-аналитика не будут колебаться во времени. А без аналитики и BI не было бы особой необходимости управлять данными в любом случае. Итак, две вещи действительно идут рука об руку. Как говорят на Ближнем Востоке, «одна рука моет другую». И это на самом деле все, что я должен сказать. Надеюсь, надеюсь, мы вернули Майка.
Эрик: Мы делаем. Майк, я полагаю, ты здесь. Я собираюсь подтолкнуть ваш слайд вверх.
Майк: я. Хорошо, ты меня слышишь?
Эрик: Да, я тебя слышу. Вы звучите замечательно. Итак, позвольте мне представить ... Вот, пожалуйста. И ты теперь ведущий. Унеси это.
Майк: Хорошо, спасибо! Доброе утро, добрый день, добрый вечер всем вам там. Прости икоту в начале. По какой-то причине я отключился и вижу всех, но они меня не слышали.
Хорошо. Итак, я хочу быстро поговорить о, как вы знаете, аналитической экосистеме больших данных. Если вы хотите задать мне вопросы, я скажу, на этом сеансе или позже, вы можете связаться со мной по моим контактным данным здесь. Как я уже сказал, среди ночи здесь, в Великобритании.
Что ж, позвольте мне перейти к тому, о чем я хочу поговорить. Очевидно, что за последние несколько лет мы стали свидетелями появления всех видов новых типов данных, которые компании теперь хотят анализировать - от данных о потоках кликов до понимания поведения в Интернете, данных социальных сетей, о которых говорил Эрик на конференции. начало программы здесь. Я думаю, что Робин упомянул JSON, BSON, XML - так, полуструктурированные данные, которые самоописывают. Конечно, у нас также есть масса других вещей - от неструктурированных данных, журналов ИТ-инфраструктуры, данных датчиков. Все эти относительно новые источники данных, в которых сейчас заинтересованы компании, поскольку они содержат ценную информацию, которая потенциально может углубить то, что мы знаем.
Таким образом, это в основном означает, что аналитическая среда вышла за пределы традиционного хранилища данных. Мы по-прежнему структурируем данные в мир сочетания структурированных и многоструктурных данных, где во многих случаях многоструктурные данные могут поступать изнутри или снаружи предприятия. И в результате этих новых типов данных и новых потребностей в анализе мы стали свидетелями появления новых аналитических рабочих нагрузок - от анализа данных в движении, что несколько переворачивает традиционную архитектуру хранилищ данных с ног на голову, где мы в традиционных кругах интегрировать данные, очищать их, преобразовывать, хранить и анализировать. Но анализируя данные в движении, мы собираем данные, интегрируем их, подготавливаем, анализируем и затем храним. Итак, анализ данных продолжается до того, как они будут сохранены где-либо.
Мы проводим комплексный анализ структурированных данных, возможно, для разработки моделей, разработки статистических и прогнозных моделей, что не является чем-то новым для некоторых людей в традиционном пространстве хранилищ данных. Мы получили предварительный анализ данных на модели. Это количество структурированных данных там. У нас появились новые рабочие нагрузки в форме анализа графиков, которые для моих клиентов в сфере финансовых услуг включают такие вещи, как мошенничество. Это также включает в себя кибербезопасность. Это включает в себя социальные сети, конечно, понимание влияющих и тому подобное там. Я даже освоил его в управлении, уже несколько лет анализирую графики.
У нас есть оптимизация хранилища данных или разгрузка обработки ETL, которая является своего рода примером использования ИТ, и ИТ-директор мог бы финансировать это. И даже архивирование данных и хранилищ данных, чтобы держать их в сети в таких вещах, как Hadoop. Таким образом, все эти новые аналитические рабочие нагрузки добавили новые аналитические платформы, новые платформы хранения. Таким образом, вместо того, чтобы просто иметь традиционные хранилища данных, витрины данных, мы получили теперь Hadoop. У нас есть базы данных NoSQL, такие как графовые базы данных, которые часто используются для аналитических рабочих нагрузок. Конечно, теперь мы можем проводить анализ графиков как на самой Hadoop, так и в СУБД с графами NoSQL. У нас есть потоковая аналитика, о которой упоминал Робин. И у нас есть - если хотите - создание моделей, возможно, также на устройствах аналитического хранилища данных. Но все это усложнило аналитическую среду, и теперь нужны разные платформы. И я полагаю, что для любого бизнеса с фронт-офисом или бэк-офисом, а также с финансами, закупками, отделом кадров и какими-либо операциями необходимо выяснить, какие аналитические проекты связаны с традиционной сценой хранилища данных. И как только вы узнаете, что аналитические проекты связаны с этими новыми платформами больших данных и где их выполнять, вы знаете, какую аналитическую нагрузку, но не упускать из виду бизнес в том смысле, что это - вы теперь увидите, что это сочетание больших проекты по анализу данных и традиционные проекты хранения больших данных, которые вместе необходимы для укрепления внутри, вокруг клиента или вокруг операций, вокруг риска, или финансирования, или устойчивости. И поэтому мы хотим, чтобы все это соответствовало нашим стратегическим бизнес-приоритетам, чтобы мы продолжали идти по пути, знаете ли, подтолкнуть иголки, которые нужно подтолкнуть, вы знаете, для повышения эффективности бизнеса, для снижения затрат, Вы знаете, снизить риски и т. д. для нашей компании в целом. Таким образом, дело не в том, что одно здесь заменяет другое большими данными и традиционными. Это оба используются вместе. И это резко меняет архитектуру, вы знаете.
Итак, здесь у меня есть относительно новая архитектура, которую я буду использовать со своими клиентами. И так, как вы можете видеть теперь внизу, огромный спектр источников данных, не просто структурированных. Некоторые из них передают потоковые данные, такие как датчики, например, данные о рынках, и тому подобное. Это могут быть даже живые данные о кликах. Это может быть потоковое видео в реальном времени. Так что это не должно быть структурировано. Таким образом, мы можем выполнять потоковую обработку этих данных для выполнения автоматических действий в режиме реального времени, и любые представляющие интерес данные могут быть отфильтрованы и переданы в инструменты управления информацией предприятия, которые можно использовать для заполнения хранилищ аналитических данных. Если вы не видите в этом миксе здесь, теперь у нас есть традиционные хранилища данных, базы данных 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 on Hadoop и т. Д., Чтобы я знал, к какому из них подключаться? В идеале, конечно, мы не должны этого делать. Мы должны были просто спросить об этом. Вы знаете, какой-то оптимизатор находит лучший способ сделать это. Но мы еще не полностью там, по моему мнению.
Но, тем не менее, виртуализация данных, о которой я упоминал ранее, играет очень важную роль для упрощения доступа к нескольким хранилищам данных. И если мы действительно создадим новое понимание Hadoop, мы, безусловно, сможем присоединиться к этим хранилищам данных к традиционным хранилищам данных, например, посредством виртуализации данных, без необходимости переноса данных из Hadoop в традиционные хранилища данных. Конечно, вы тоже можете это сделать. Также возможно, что я заархивирую данные из традиционных хранилищ данных в Hadoop. Я все еще могу получить его и присоединиться к тому, что есть в нашем хранилище данных для виртуализации данных. Так что для меня, я думаю, у виртуализации данных большое будущее в этой общей архитектуре и упрощении доступа ко всем этим хранилищам данных.
И не забывайте, что когда мы создаем эти новые идеи, будь то в реляционных системах или системах NoSQL, мы все же хотим вернуть эти идеи обратно в наши операции, чтобы мы могли максимизировать ценность того, что мы нашли, чтобы мы могли использовать это для более эффективных и своевременных решений в этой среде для оптимизации нашего бизнеса.
Итак, если подвести итог, то, что я вижу, так это то, что нам нужны новые источники данных. У нас есть новые платформы на более сложной архитектуре, если хотите, чтобы справиться с этим. И Hadoop становится очень, очень важным, достаточным для подготовки данных для наших жидких песочниц, для запросов архива, архивирования из хранилища данных, управления данными, расширяющего свои возможности, чтобы выйти за пределы хранилищ данных и управлять ими на всех этих платформах, а также для разработки новых инструментов. возможность анализировать данные в этих средах и получать к ним доступ; иметь масштабируемые технологии, позволяющие лучше обрабатывать данные; масштабировать аналитику, подталкивая их к платформам, чтобы сделать их более параллельными. И затем, мы надеемся, также упростить доступ ко всему этому через появляющийся SQL, приходящий сверху. Итак, это дает вам представление о том, куда мы направляемся. Итак, теперь я перейду к Эрику, не так ли?
Эрик: Хорошо, это фантастика. И, ребята, я должен сказать, что между тем, что вы только что получили от Робина и Майка, он, вероятно, настолько же исчерпывающий и краткий в обзоре всего ландшафта с точки зрения того, что вы найдете где угодно. Позвольте мне идти вперед и поставить в очередь Джорджа Коругедо первым. И вот оно. Позвольте мне взять это на секунду. Хорошо, Джордж, я собираюсь передать вам ключи и забрать их. Вам слово.
Джордж: Отлично! Большое спасибо, Эрик, и спасибо, Роб и Майк. Это была отличная информация и многое, с чем мы согласны. Итак, возвращаясь к обсуждению Робина, потому что, знаете, не случайно, что RedPoint здесь и SAS здесь. Потому что RedPoint, мы действительно сосредоточены на стороне данных на управлении, на обработке данных и подготовке к использованию в аналитике. Итак, позвольте мне пройти через эти два слайда. И действительно, поговорим и поймем точку зрения Робина о MDM, о том, насколько это важно и насколько полезно, я думаю - и мы думаем - Hadoop может быть в мире MDM и качества данных.
Знаете, Робин немного говорил о том, как это связано с миром корпоративных хранилищ данных, и я прихожу - вы знаете, я провел несколько лет в Accenture. И что было интересно, так это то, сколько раз мы приходили в компании и пытались выяснить, что делать с хранилищем данных, которое в основном было заброшено. И многое из этого произошло из-за того, что команда хранилища данных на самом деле не согласовывала свою сборку с бизнес-пользователями или с потребителями данных. Или же это заняло так много времени, что к тому времени, когда они создали эту вещь, бизнес-использование или ее бизнес-обоснование эволюционировали.
И одна из вещей, которые, я думаю, меня очень волнует, это идея использовать Hadoop для управления основными данными, для качества данных и для подготовки данных, это то, что вы всегда можете вернуться к элементарным данным в Озеро данных Hadoop или хранилище данных, или хранилище данных, или концентратор, или любая другая форма, которую вы хотите использовать. Но поскольку вы всегда храните эти элементарные данные, у вас всегда есть возможность согласоваться с бизнес-пользователями. Потому что, как аналитик - потому что я фактически начал свою карьеру в качестве статистика - вы знаете, нет ничего хуже, чем, как вы знаете, хранилища корпоративных данных, которые прекрасно подходят для составления отчетов, но если вы хотите по-настоящему прогнозировать аналитику, они на самом деле не очень полезно, потому что вам действительно нужны детальные поведенческие данные, которые каким-то образом суммируются и агрегируются в хранилище данных. Итак, я думаю, что это действительно важная особенность, и я могу не согласиться с Робином в том, что я лично оставляю данные в озере данных или в концентраторе данных как можно дольше, потому что до тех пор, пока данные есть, и они чистые, вы можете смотреть на них с одной стороны, с другой стороны. Вы можете объединить его с другими данными. У вас всегда есть такая возможность вернуться к нему и реструктурировать, а затем привести себя в соответствие с бизнес-подразделением и потребностями, которые могут возникнуть у этого подразделения.
Еще один интересный момент в этом заключается в том, что, поскольку это такая мощная вычислительная платформа, большая часть той рабочей нагрузки, о которой мы говорили, мы видим, что все это идет прямо в Hadoop. И хотя, я думаю, Майк говорил обо всех различных технологиях, которые существуют в мире - в этом типе экосистемы больших данных, мы думаем, что Hadoop действительно является рабочей лошадкой для выполнения такого масштабного процесса в вычислительно интенсивной обработке, которая основные данные и качество данных требуют. Потому что, если вы можете сделать это там, вы знаете, просто экономическую выгоду перемещения данных из ваших дорогих баз данных в экономичные базы данных, это действительно стимулирует столь большую популярность сейчас на крупных предприятиях.
Теперь, конечно, есть некоторые проблемы, верно? Есть проблемы вокруг технологий. Многие из них очень незрелые. Я бы сказал, вы знаете, я не знаю, сколько, но ряд технологий, о которых упоминал Майк, все еще находится в релизах с нулевой точкой, верно? Таким образом, эти технологии очень молоды, очень незрелые, все еще основаны на коде. И это действительно создает проблемы для предприятий. И мы действительно сосредоточены на решении проблем на уровне предприятия. Итак, мы думаем, что должен быть другой путь, и это то, что мы предлагаем, это другой способ использования некоторых из этих очень зарождающихся технологий.
И так, а затем еще одна интересная проблема, о которой упоминалось ранее: когда у вас есть данные, которые вы собираете в среде Hadoop любого типа, вы знаете, это обычно схема при чтении, а не схема при записи с некоторыми исключениями. И это чтение, многое из этого делается статистиками. Итак, у статистиков должны быть инструменты, позволяющие им правильно структурировать данные для аналитических целей, потому что в конце дня, чтобы сделать данные полезными, их необходимо структурировать в некоторой форме, чтобы увидеть некоторые из них или ответить на вопрос или бизнес, какой-то тип бизнеса, создает ценность для бизнеса.
Таким образом, мы пришли к выводу, что у нас есть очень обширный и зрелый EPL, главный ключ качества данных ELT и приложение для управления. Это было на рынке много, много лет. И он обладает всеми функциями или большей частью функций, которые Робин перечислил на этом круговом графике - все, от простого захвата необработанных данных в целом ряде форматов и XML-структур и тому подобного, до способности выполнять всю очистку, завершение данных, исправление данных, геопространственные основные биты данных. Это то, что становится все более и более важным в наши дни с Интернетом вещей. Вы знаете, география связана с большей частью того, что мы делаем, или с большей частью этих данных. Итак, весь анализ, токенизация, очистка, исправление, форматирование, структурирование и т. Д. - все это делается на нашей платформе.
И тогда, и, возможно, мы думаем, что наиболее важным является идея дедупликации. Вы знаете, по сути, если вы посмотрите на какое-либо определение управления основными данными, ядром его является дедупликация. Он может идентифицировать объекты в разных источниках данных, а затем создать основную запись для этого объекта. И эта сущность может быть человеком. Например, сущность может быть частью самолета. Субъект может быть едой, как мы сделали для одного из наших клиентов в клубе здоровья. Мы создали для них базу данных основных продуктов питания. Итак, с какими бы сущностями мы ни работали - и, конечно же, все чаще появляются люди и доверенные лица для их идентичностей, такие как социальные дескрипторы или учетные записи, любые устройства, связанные с людьми, некоторые вещи, такие как автомобили и телефоны и все остальное, что вы можете себе представить.
Вы знаете, мы работаем с клиентом, который использует всевозможные датчики в спортивной одежде. Таким образом, данные поступают со всех сторон. И так или иначе, это отражение или представление основной сущности. И все чаще это люди и способность идентифицировать отношения между всеми этими источниками данных и то, как они связаны с этой основной сущностью, а затем возможность отслеживать эту основную сущность с течением времени, чтобы вы могли анализировать и понимать изменения между этой сущностью и все те другие элементы, которые в этих представлениях этой сущности, например, действительно важны для долгосрочного и продольного анализа людей. И это действительно одно из действительно важных преимуществ, которые, я думаю, большие данные могут принести нам, намного лучше понимают людей, и в долгосрочной перспективе, и понимают, как и как ведут себя люди, когда они ведут себя через какие устройства и т. Д. ,
Итак, позвольте мне быстро пройти через это. Эрик упомянул YARN. Вы знаете, я добавляю это всего на несколько секунд, потому что пока YARN - люди говорят о YARN. Я думаю, что по-прежнему много невежества в отношении пряжи. И на самом деле не так много людей - все еще много недоразумений о YARN. И дело в том, что если ваше приложение правильно спроектировано и у вас есть надлежащий уровень или распараллеливание в архитектуре приложения, то вы можете воспользоваться YARN для использования Hadoop в качестве платформы масштабирования. И это именно то, что мы сделали.
Вы знаете, опять же, просто чтобы указать на некоторые определения вокруг YARN. Для нас действительно то, что такое YARN, позволило нам и другим организациям стать партнерами MapReduce и Spark, а также всех других инструментов, которые существуют. Но дело в том, что наши приложения загружают оптимизированный код непосредственно в YARN в Hadoop. И есть очень интересный комментарий, который упомянул Майк, потому что, вы знаете, вопрос об аналитике и нашей аналитике, просто потому, что они в кластере, они действительно работают параллельно? Вы можете задать тот же вопрос о множестве инструментов качества данных, которые существуют.
Большую часть дня инструменты качества, которые существуют, должны либо извлекать данные, либо вводить код. И во многих случаях это один поток данных, который обрабатывается из-за того, как вам нужно сравнивайте записи, иногда по типу данных по качеству деятельности И дело в том, что, поскольку мы используем YARN, мы смогли по-настоящему воспользоваться преимуществами распараллеливания.
И просто для краткого обзора, потому что еще один комментарий о важности возможности расширения традиционных баз данных, новых баз данных и т. Д., Которые мы внедряем или устанавливаем вне кластера. И мы помещаем наши двоичные файлы прямо в менеджер ресурсов, YARN. И это, а затем YARN распределяет его по узлам в кластере. И это то, что YARN - мы позволяем YARN управлять и выполнять свою работу, то есть выяснять, где находятся данные, и переносить работу на данные, код на данные, а не перемещать их. Когда вы слышите, как инструменты обеспечения качества данных говорят вам, что лучше всего переносить данные из Hadoop, работать ради своей жизни, потому что это не совсем так. Вы хотите перенести работу на данные. И это то, что YARN делает первым. Он выводит наши двоичные файлы в узлы, где находятся данные.
Кроме того, поскольку мы находимся за пределами кластера, мы также можем получить доступ ко всем традиционным и реляционным базам данных, поэтому у нас могут быть задания, которые состоят из 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 Analytic Server, чтобы мы могли выполнять аналитические алгоритмы - вы знаете, много нового машинного обучения, нейронные сети, случайные лесные регрессии, такие виды вещи - опять же данные, хранящиеся в памяти. Таким образом, избавление от определенного узкого места в парадигме MapReduce, когда мы получаем доступ к этим платформам, - это не тот способ, которым вы хотите выполнять аналитическую работу. Итак, мы хотим иметь возможность поднять данные один раз в пространство памяти и перебирать их, вы знаете, иногда тысячи раз. Вот в чем заключается концепция использования этого высокопроизводительного сервера Analytic LASR.
Мы также - другие приложения под ним, визуальная аналитика, которая позволяет нам сохранять эти данные в памяти и обслуживать большее количество людей с теми же данными. Итак, позволяя людям проводить исследование больших данных. Поэтому, прежде чем приступить к нашей работе по разработке модели, мы исследуем данные, разбираемся в них, проводим корреляции, прогнозируем или определяем тренды деревьев решений - такого рода вещи - но очень наглядным, интерактивным способом для данных, находящихся в памяти. Платформа. Это также помогает нашему BI-сообществу, поскольку у него очень широкая база пользователей, которые могут использовать эту платформу для выполнения стандартных видов записи, которые вы увидите, - которые, как вы знаете, практически у любого поставщика BI.
Следующим шагом мы переходим затем в сервис. И чтобы помочь нашим специалистам по статистике и нашим аналитикам иметь возможность выполнять такого рода специальное моделирование с данными, хранящимися в памяти, удаленными из визуальной аналитики и исследованиями в нашем приложении визуальной статистики. Это возможность для людей, чтобы не запускать статистику в пакетах, которые раньше использовались для итераций, запускать модели, видеть результаты. Итак, что может запустить модель, смотрите результаты. Это для визуального перетаскивания в интерактивное статистическое моделирование. Таким образом, это помогает нашим статистикам и нашим специалистам по данным выполнять большую часть этой ранней исследовательской визуальной статистики.
И потом, мы не забыли наших кодеров - люди, которые действительно хотят иметь, иметь возможность очистить слои интерфейса друг от друга, это написать приложения и написать свою собственную кодовую базу в SAS. И это наша статистика в памяти для Hadoop. И это, по сути, уровень кода, который позволил нам взаимодействовать с этим Analytic LASR Server, чтобы напрямую выдавать команды и настраивать эти приложения на основе нашего запроса. Это аналитическая часть.
Как все это устроить ... Ой, извините, ребята. Там мы идем.
Таким образом, есть несколько способов сделать это. Один из них - сделать это с большими данными, в данном случае - с 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, который позволяет нам объединить эти другие технологии. Это как пошаговый мастер, скажем, для выполнения запроса Hive или выполнения процедуры качества данных, и в этом случае не нужно писать код.
Последнее, что я упомяну, это передняя часть. Как я уже говорил, у нас есть огромная SAS-нога в мире. И это, мы не можем просто обязательно сделать все те платформы, которые существуют, чтобы быть в этом пространстве немедленно. Таким образом, у нас определенно есть существующая группа пользователей, которым необходимо получать данные, находящиеся на этих платформах больших данных, такие как извлечение данных из Teradata и помещение их обратно в Hadoop, и наоборот. Работая с моделями, я уже знаю, как работать на своих серверах SAS, но мне нужно получить данные, которые теперь размещаются на платформе Hadoop. Итак, есть еще один маленький значок, который называется «от», и который позволяет нам подключаться с помощью наших механизмов доступа SAS - механизмов доступа к Hadoop, Cloudera в Пола, Teradata, Greenplum и… И этот список можно продолжить. Это позволяет нам использовать наши существующие зрелые платформы SAS, которые уже существуют, для получения данных с этих платформ, выполнять ту работу, которая нам необходима, и возвращать результаты обратно в эти области.
Последнее, что я упомяну, это то, что все эти технологии, которые вы видите, управляются одними и теми же стандартными общими метаданными. Итак, мы говорим о том, как заставить работать преобразование, работать с правилом качества данных, перенести его в память, чтобы иметь возможность выполнять аналитику, разрабатывать модели в скорингах. Мы получили там весь аналитический образ жизни, жизненный цикл которого определяется общими метаданными, управлением, безопасностью, всеми вещами, о которых мы говорили ранее сегодня.
Итак, просто резюмируем, есть действительно три большие вещи, которые нужно отнять там. Во-первых, мы можем обращаться с платформой данных так же, как с любым другим источником данных, извлекая из них, подталкивая к ним, когда это уместно и удобно. Мы можем работать с этими платформами больших данных, помещая данные в специализированную расширенную аналитику в платформе памяти. Итак, это сервер LASR.
И, наконец, наконец, мы можем работать непосредственно на этих платформах больших данных, используя их возможности распределенной обработки без перемещения данных.
Эрик: Ну, это фантастика, ребята. Да, это здорово! Итак, давайте вернемся к некоторым вопросам. Обычно на эти события уходит около 70 минут или чуть больше. Итак, я вижу, что у нас все еще есть отличная аудитория. Джордж, я полагаю, я передам тебе наш первый вопрос. Если вы говорите о вставке вашего бинарного звука в Hadoop, я думаю, это звучит для меня так, будто вы действительно оптимизировали вычислительный рабочий процесс. И в этом весь ключ для того, чтобы иметь возможность осуществлять такие виды управления данными в режиме реального времени, достижения в стиле качества данных, потому что именно эту ценность вы хотите получить, верно? Если вы не хотите возвращаться в старый мир MDM, где он очень громоздок и отнимает много времени, и вам действительно нужно заставить людей действовать определенным образом, что почти никогда не работает. Итак, то, что вы сделали, вы сузили цикл того, что было. Давайте назовем это днями, неделями, а иногда даже месяцами, не так ли? Это то, что происходит?
Джордж: Это совершенно верно, потому что масштаб, который мы получаем, и производительность, которую мы получаем из кластера, действительно ошеломляет с точки зрения, просто, вы знаете, я всегда немного сомневаюсь в тестах. Но только на порядок, когда мы запустим миллиард, 1,2 миллиарда записей и проведем полную стандартизацию адресов - я говорю, что машина среднего класса HP - это займет, как вы знаете, восемь процессорных машин, вы знаете, 2 гигабайта ОЗУ на ядро, вы знаете, это займет 20 часов. Мы можем сделать это примерно за восемь минут на кластере из 12 узлов. Итак, масштаб обработки, которую мы можем сделать сейчас, настолько сильно отличается - и это прекрасно сочетается с идеей, что у вас есть все эти данные в вашем распоряжении. Таким образом, это не так рискованно, чтобы сделать обработку. Если вы сделали это неправильно, вы можете повторить это. У тебя есть время, ты знаешь. Это действительно изменило масштабы этого, когда, вы знаете, такие риски стали настоящими бизнес-проблемами для людей, когда они пытались использовать решения MDM. У вас должно быть 30 человек в оффшорной зоне, которые управляют данными и все такое. И так, вам все еще нужно что-то из этого, но скорость и масштаб, с которым вы можете обрабатывать это сейчас, действительно дают вам гораздо больше передышки.
Эрик: Да, это действительно очень хороший момент. Мне нравится этот комментарий. Итак, у вас есть время, чтобы повторить это снова. Это фантастично.
Джордж: Да.
Эрик: Ну, это меняет динамику, верно? Это меняет то, как вы думаете о том, что вы собираетесь попробовать. Я имею в виду, я помню это 18 лет назад в индустрии создания спецэффектов, потому что у меня был клиент, который был в этом пространстве. И вы нажимаете кнопки, чтобы сделать это, и вы идете домой. И вы вернетесь, может быть, в субботу днем, чтобы посмотреть, как идут дела. Но если вы ошиблись, это было очень, очень, очень больно. И теперь, это не так близко - это даже близко не настолько болезненно, так что у вас есть возможность попробовать больше вещей. Я должен сказать, я думаю, что это действительно очень хороший момент.
Джордж: Это совершенно верно. Да, и вы взорвали свою дополнительную ногу. Знаете, в старые времена вы получаете работу на полпути, и она терпит неудачу, вы взорвали SOS. Это оно.
Эрик: Верно. И у тебя большие проблемы, да. Верно.
Джордж: Это верно. Верно.
Эрик: Кит, позволь мне передать тебе одну. Я помню, как давал интервью вашему CIL, Кита Коллинзу, думаю, в 2011 году, может быть. И он много говорил о направлении, в котором SAS работала, особенно в отношении работы с клиентами, для встраивания аналитических данных, полученных из SAS, в операционные системы. И, конечно, мы слышали, как Майк Фергюсон говорил о важности запоминания. Вся идея здесь в том, что вы хотите иметь возможность связать эти вещи со своими операциями. Вам не нужен анализ в вакууме, отключенном от предприятия. Это не имеет никакой ценности.
Если вам нужен анализ, который может напрямую влиять и оптимизировать операции. И если я оглядываюсь назад - и я должен сказать, я думал, что тогда это была хорошая идея - это кажется очень, очень умной идеей в ретроспективе. И я предполагаю, что это реальное преимущество, которое вы, ребята, имеете. И, конечно же, это великое наследие, эта огромная база установки и тот факт, что вы сосредоточились на внедрении этой аналитики в операционные системы, что означает, что сейчас - и, разумеется, потребуется определенная работа - я уверен, что вы » Я работал над этим довольно усердно. Но теперь вы можете использовать все эти новые инновации и действительно можете использовать все эти возможности для своих клиентов. Это справедливая оценка?
Кит: Да, абсолютно. Идея в том, что вы получаете представление о дизайне решений или науках о решениях, которое, в некоторой степени, является исследовательским, научно-исследовательским. Если вы не можете заниматься разработкой этого процесса, чтобы по-настоящему… Если вы думаете о разработке автомобиля, у вас есть дизайнеры, которые делают этот красивый автомобиль, но только после того, как инженеры разработают этот план и сделают реальный жизнеспособный продукт перед вами. может на самом деле поставить вещи на место, и это, по сути, то, что сделал SAS. Он объединил процесс принятия решений - процесс принятия решений с процессом принятия решений, так что когда вы говорите об ускорителях, особенно о ускорителях скоринга, вы знаете, если вы берете модель, которую вы разработали, и сможете ее вытолкнуть. в Teradata или в Oracle или Hadoop с нулевым временем простоя для разработки моделей и развертывания моделей. Это важно, потому что модели со временем ухудшают точность этих моделей. Таким образом, чем дольше вы берете это и запускаете в производство, тем больше потеря точности модели.
И затем, другой момент, вы хотите иметь возможность контролировать и управлять этим процессом с течением времени. Вы хотите отказаться от моделей, когда они стареют и неточны. Вы хотите посмотреть на это, проверить их точность с течением времени и восстановить их. Итак, у нас также есть инструменты управления моделями, которые действительно отслеживают метаданные вокруг моделируемого процесса. И люди говорили, что моделирование, вы знаете, такого рода концепция похожа на фабрику моделей, или как вы хотите это назвать. Дело в том, что это ввод метаданных и управления в процесс, и именно здесь мы сталкиваемся с тремя важными вещами - мы помогаем людям зарабатывать деньги, экономить деньги и не допускать их в тюрьму.
Эрик: Последний тоже довольно большой. Я ищу, чтобы избежать всего этого. Итак, давайте поговорим о ...Я задаю последний вопрос, может быть, каждый из вас может как-то подскочить на этом. Мне кажется, что гетерогенность нашего мира будет только возрастать. Я думаю, что мы определенно увидим некоторую кристаллизацию вокруг гибридных облачных сред. Но, тем не менее, вы увидите много крупных игроков. IBM никуда не денется. Оракул никуда не денется. SAP никуда не денется. И есть много других поставщиков, которые участвуют в этой игре.
Кроме того, с операционной стороны, где у вас есть буквально тысячи и тысячи различных видов приложений. И я слышал - большинство из вас говорят об этом, но я думаю, что вы оба согласились бы с тем, что я говорил. Сейчас мы наблюдаем эту тенденцию с точки зрения вычислительной мощности в аналитических движках, архитектуре. Компании уже много лет говорят о возможности подключиться к другим двигателям и обслуживать своего рода точку оркестровки. И я думаю, Джордж, я сначала брошу это тебе. Мне кажется, что это не изменится. У нас будет гетерогенная среда, а это значит, что есть такие вещи, как CRM в реальном времени, качество данных и управление данными. Вам, как продавцу, нужно будет взаимодействовать со всеми этими различными инструментами. И это то, что клиенты захотят. Они не будут хотеть чего-то, что будет хорошо с этими инструментами и не очень хорошо с этими инструментами. Они собираются хотеть Швейцарию MDM и CRM, верно?
Джордж: Это верно. И это интересно, потому что мы очень это приняли. Частично это история, которую мы имели в космосе. И, очевидно, мы уже работали со всеми другими базами данных, Teradatas и кусочками мира. И затем, - в процессе реализации, особенно так, как мы это сделали, просто так - у вас есть охват всех этих различных баз данных. Одна из вещей, которые мне кажутся интересными, заключается в том, что у нас есть клиенты, которые просто одержимы уничтожением всех реляционных баз данных. И это интересно. Вы знаете, я имею в виду, это нормально. Это интересно. Но я просто не вижу, чтобы это действительно происходило в масштабах большого предприятия. Я не вижу, что это происходит в течение длительного времени. Итак, я думаю, что гибрид здесь уже давно и на другой стороне нашего приложения, где у нас есть платформа обмена сообщениями в нашей платформе управления кампаниями. Мы на самом деле специально разработали его. Теперь мы выпустили версию, которая делает это и которая теперь может подключаться к гибридной среде данных и запрашивать Hadoop или запрашивать любую базу данных, любую аналитическую базу данных. Так что я думаю, что это только волна будущего. И я согласен, что виртуализация, безусловно, сыграет в этом большую роль, но мы просто - мы собираемся перейти к данным всех наших приложений.
Эрик: Хорошо, отлично. И, Кит, я передам это тебе. Что вы думаете о неоднородном мире, с которым мы сталкиваемся, действуя как своего рода нога?
Кит: Да, это действительно увлекательно. Я думаю, что мы находим больше - не только в части управления данными - но то, что сейчас действительно увлекательно, - это природа аналитической базы с открытым исходным кодом. Итак, мы видим такие организации или такие технологии, как Spark, и люди, использующие Python и R и все эти другие технологии с открытым исходным кодом. Я думаю, что это можно интерпретировать как своего рода конфликт или угрозу в некоторой степени. Но реальность такова, что у нас есть действительно замечательные комплименты со всеми этими технологиями с открытым исходным кодом. Я имею в виду, во-первых, мы работаем поверх платформ с открытым исходным кодом, ради всего святого.
Но также, как и возможность интеграции, например, модели R в парадигму SAS, вы можете использовать лучшее из обоих миров, верно? Например, мы знаем, что некоторые экспериментальные вещи в академическом мире и некоторые работы по разработке моделей необычайно полезны в процессе разработки моделей. Но также, если вы могли бы соединить это с инструментом производственного класса, он выполняет большую часть очистки, качества и проверки, а также проверяет, что данные, передаваемые в модель, правильно подготовлены, чтобы не дать сбой. на исполнении. И затем, возможность делать что-то вроде моделей чемпионов-претендентов с моделями с открытым исходным кодом. Это то, на что мы обращаем внимание, и как часть этой действительно неоднородной экосистемы всех этих технологий. Да, так что это больше - для нас это больше о применении этих технологий и поиске комплиментов.
Эрик: Ну, это были фантастические вещи, ребята. Мы проделали здесь немного времени, но нам хотелось бы получить как можно больше вопросов. Мы передадим файл вопросов и ответов нашим докладчикам сегодня. Поэтому, если на любой вопрос, который вы задали, не было ответа, мы позаботимся о том, чтобы на него ответили. И, ребята, это завершает 2014 год. С уважением, на радио DM завтра и на следующей неделе, а потом все готово, и это каникулы.
Огромное спасибо всем вам за ваше время и внимание, за то, что вы просмотрели все эти замечательные веб-трансляции. У нас замечательный год на 2015 год. И мы скоро поговорим с вами, ребята. Еще раз спасибо. Мы позаботимся. Пока-пока.