Зміст
Джерело: Якуб Джирсак / Dreamstime.com
Винос:
Ведучий Ерік Кавана обговорює аналітику великих даних з галузевими експертами.
Ерік: Пані та панове, це кінець 2014 року - принаймні, майже. Це наша остання веб-трансляція року, люди! Ласкаво просимо до TechWise! Так, справді! Мене звуть Ерік Кавана. Я буду вашим модератором для дивовижної трансляції, люди. Я дуже, дуже раді. У нас є дві дивовижні аналітики в Інтернеті та дві чудові компанії - справжні новатори в цій цілій екосистемі великих даних. І ми будемо говорити все про те, що ключове значення для аналітики великих даних - це розуміння різниці. Отже, давайте далі, зануримось, люди.
У нас є кілька ведучих. Як бачите, справді на самому верху є ваша. Майк Фергюсон телефонує з Великобританії, куди йому довелося отримати пільги, щоб залишитися в офісній будівлі цього пізнього часу. Тож для нього це пізно У нас є доктор Робін Блор, наш власний головний аналітик у групі Bloor. У нас будуть Джордж Коругедо, генеральний директор і співзасновник RedPoint Global, і Кіт Ренісон, старший архітектор рішень з Інституту SAS. Це фантастичні компанії, люди. Це компанії, які справді інноваційні. І ми хочемо розібратися в деяких хороших речах того, що зараз відбувається у всьому світі великих даних. І давайте поглянемо, невеликі дані не пішли. До цього, дозвольте мені дати тут своє резюме.
Отже, є старий французький вираз: "Чим більше речей змінюється, тим більше вони залишаються тими ж". І давайте зіткнемося з деякими фактами тут - великі дані не вирішать проблем малих даних. Невеликі корпоративні дані все ще є. Це все ще скрізь. Це паливо операцій для інформаційної економіки сьогодні. І великі дані пропонують комплімент цим так званим невеликим корпоративним даним, але це не витісняє малих даних. Це все ще буде навколо. Мені подобається багато речей про великі дані, особливо такі речі, як машинні дані.
І сьогодні ми, мабуть, трохи поговоримо про дані соціальних медіа, що теж дуже потужна річ. А якщо ви думаєте, наприклад, про те, як соціальний бізнес змінив бізнес, добре подумайте про три швидкі веб-сайти тут: 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. У нас є потокова аналітика, про яку згадував Робін. І у нас є - якщо вам подобається - побудова моделей, можливо, і на приладах аналітичного сховища даних. Але все це ускладнило аналітичний пейзаж, зараз потрібні кілька платформ. І я здогадуюсь, що перед будь-яким бізнесом, який має фронт-офіс чи бек-офіс, або фінансами, закупівлями, персоналом та деякими операціями, є завдання визначити, які аналітичні проекти пов'язані з традиційною сценою зберігання даних. І коли ви знаєте, що аналітичні проекти пов’язані з цими новими великими платформами даних і де їх запустити, ви знаєте, яке аналітичне навантаження, але не втрачати з поля зору бізнес у тому сенсі, що це - ви зараз побачите, що це поєднання великих аналітичні проекти даних та традиційні проекти зберігання великих даних, які разом необхідні для зміцнення всередині клієнта чи навколо операцій, навколо ризику, фінансів чи сталості. І тому ми хочемо, щоб усе це було узгоджено з нашими стратегічними пріоритетами бізнесу, щоб ми залишалися на шляху до, знаєте, втиснути голки, які потрібно засунути, знаєте, для покращення результатів бізнесу, для зниження витрат, щоб зменшити ризики тощо, ви знаєте, для нашої компанії в цілому. Отже, справа тут не в тому, що одна замінює іншу великими даними та традиційними. Обидва вони використовуються разом. І це кардинально змінює архітектуру, ви знаєте.
Отже, у мене є порівняно нова архітектура, яку я буду використовувати зі своїми клієнтами. Отож, як ви бачите зараз вздовж низу, величезна кількість джерел даних, вже не просто структурованих. Деякі з них передають живі дані, такі як датчики, як дані про ринки, такі речі. Це можуть бути навіть дані в реальному кліці. Це можуть бути потокові відео в прямому ефірі. Тож її не треба було структурувати. Таким чином, ми можемо робити потокову обробку цих даних, щоб робити автоматичні дії в режимі реального часу, а будь-які цікавлять дані можуть бути відфільтровані і передані в інструменти управління інформацією підприємства, які можна використовувати для заселення аналітичних сховищ даних. Якщо ви не можете побачити тут поєднання, тепер у нас є традиційне зберігання даних, бази даних 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, а також усім іншим інструментам, які там є. Але факт полягає в тому, що наші програми передають оптимізований код прямо в ПРАВУ в Hadoop. І є дійсно цікавий коментар, який згадував Майк, бо, знаєте, питання про аналітику та нашу аналітику, лише тому, що вони в кластері, чи справді вони працюють паралельно? Ви можете задати те саме питання щодо багатьох інструментів якості даних, які там є.
Більшу частину дня інструменти з якості, які знаходяться там, або повинні витягувати дані, або вони висувають код. І в багатьох випадках це єдиний потік даних, який обробляється через те, як вам доведеться порівнюйте записи, іноді за типом діяльності з якістю даних. І факт полягає в тому, що, оскільки ми використовуємо ПРАВО, ми змогли реально скористатися паралелізацією.
І просто для швидкого огляду, оскільки ще один коментар робиться про важливість можливості розширення традиційних баз даних, нових баз даних тощо, які ми впроваджуємо або встановлюємо поза кластером. І ми підштовхуємо наші бінарні файли безпосередньо до менеджера ресурсів, ПРАВА. І це, і тоді YARN розподіляє його по вузлах кластеру. І що це робить, це те, що ПРИКОРА - ми дозволяємо YARN керувати і виконувати свою роботу, яка полягає в тому, щоб з'ясувати, де дані, і взяти роботу до даних, код до даних, а не переміщувати дані навколо. Коли ви почуєте інструменти якості даних, і вони говорять вам, найкраща практика - перемістити дані з Hadoop, біжіть за своє життя, адже це просто не так. Ви хочете віднести роботу до даних. І це саме те, що ПЕРЕГО робить перший. Він виводить наші бінарні файли до вузлів, де дані перебувають.
А також тому, що ми перебуваємо за межами кластеру, ми також можемо отримати доступ до всіх традиційних та реляційних баз даних, щоб ми могли мати завдання, які є 100% клієнтським сервером на традиційній базі даних, 100% Hadoop або гібридні завдання, які переходять через сервер клієнтів Hadoop , Oracle, Teradata - все, що ви хочете, і все в одній роботі, тому що одна реалізація може отримати доступ до обох сторін світу.
І тоді, повертаючись до всієї ідеї про народження інструментів, ви бачите тут, це просто просте уявлення. І ми намагаємось спростити світ. І ми це робимо, забезпечуючи широкий набір функціоналів навколо HDFS, щоб зробити це… І це не тому, що ми намагаємося ліквідувати всі інноваційні технології там. Просто підприємствам потрібна стабільність, і вони не люблять рішення на основі коду. І тому ми намагаємось надати підприємствам знайоме, повторюване, послідовне середовище додатків, яке дає їм можливість будувати та обробляти дані дуже передбачувано.
Швидко це такий вплив, який ми отримуємо від нашого застосування. Ви бачите MapReduce vs. Pig vs. RedPoint - у RedPoint немає рядків коду. Шість годин розробки в MapReduce, три години розвитку в Pig і 15 хвилин розвитку в RedPoint. І саме тут ми маємо величезний вплив. Час обробки також швидше, але час людей, час продуктивності людей, значно збільшується.
І моя остання слайд тут, я хочу повернутися до цієї ідеї, тому що це наше використання озера даних або центру даних або переробки даних як центральної точки прийому. Не могли погодитися більше з цією ідеєю. І зараз ми обговорюємо з великою кількістю головних службовців даних великих світових банків, і це архітектура вибору. Введення даних з усіх джерел здійснює обробку якості даних та керує керуванням даними всередині озера даних, а потім відсуває дані туди, куди потрібно, щоб перейти на підтримку програм, підтримати BI, що б там не було. І тоді, якщо у вас є аналітика в BI, вони можуть працювати безпосередньо всередині озера даних, де все краще, що може початися відразу. Але дуже добре на цій ідеї. Ця топологія тут одна - це те, що ми виявляємо, що ми отримуємо багато тяги на ринку. І це все.
Ерік: Гаразд, добре. Давайте рухатимемося прямо тут. Я піду і передам його Кіту. І, Кіт, у тебе близько 10, 12 хвилин, щоб тут розкотити будинок. У цих шоу ми взяли трохи довше. І ми рекламували 70 хвилин на цю. Отже, просто продовжуйте і клацніть будь-де на цьому слайді та використовуйте стрілку вниз і зніміть її.
Кіт: Звичайно. Без проблем, Еріку. Я ціную це. Я збираюся йти вперед і натискаю лише кілька творів про SAS, потім перейду, прямо в технологічну архітектуру, де SAS перетинається зі світом великих даних. У цьому матеріалі є багато що пояснити. Ми могли б витратити кілька годин, переглядаючи це детально, але десять хвилин - ви повинні мати можливість піти лише за коротким розумінням того, куди SAS взяв аналітику, управління даними та технології бізнес-аналізу в цей світ великих даних.
По-перше, трохи про SAS. Якщо ви не знайомі з цією організацією, ми впродовж останніх 38 років займаємось передовою аналітикою, бізнес-аналітикою та керуванням даними не просто великими даними, а невеликими даними та багатством даних. У нас величезна кількість клієнтів, близько 75 000 сайтів по всьому світу, що працюють з деякими найкращими організаціями. Ми є приватною організацією, яка має близько 13 000 співробітників і 3 млрд доларів доходу. І справді, я думаю, важлива частина полягає в тому, що ми традиційно мали багаторічну історію реінвестування значних сум свого доходу в нашу науково-дослідну організацію, яка справді принесла багато цих дивовижних технологій та платформ, які ви " збираємось побачити сьогодні.
Отже, я збираюся перейти прямо до цих справді страшних діаграм архітектури. Ми будемо працювати зліва направо на моїх слайдах. Отже, є знайомі речі, які ви збираєтеся бачити на цій платформі. Ліворуч усі ті джерела даних, про які ми говоримо, проникаємо в ці великі платформи даних. А потім у вас є ця велика платформа даних.
Я не просто поставив слово Hadoop там на самому верху, тому що в кінцевому підсумку приклади, які я сьогодні буду наводити, стосуються конкретно всіх технологій, де ми перетинаємо ці великі платформи даних. Hadoop, як буває, є одним із тих, де у нас є кілька найбільш надійних варіантів розгортання, але ми також перетинаємося досить багато і протягом певного часу розробили багато цих технологій з іншими нашими партнерами в сховищі даних для підприємств, такими як Teradata, Oracle, Pivotal тощо. Отже, я не можу вникати в деталі, коли всі різні технології підтримуються на якій платформі, але просто будьте впевнені, що всі, які я описую сьогодні, - це в основному все, що Hadoop, і величезна кількість з них перетинається з іншими технологічними партнерами, які ми маємо. Отже, у нас така велика платформа, що сидить там.
Наступним праворуч ми маємо наш Аналітичний сервер SAS LASR. Тепер, по суті, це масово паралельний сервер прикладних програм аналітичної пам'яті. Ми зрозуміли б, що це не база даних пам'яті. Це дійсно розроблено з нуля. Це не механізм запитів, але призначений для масового паралельного обслуговування аналітичних запитів. Отже, це додатки службових ключів, які ви бачите там праворуч.
Ми трохи розберемося, як люди знають, як розгортати ці речі. Але по суті, додаток - чи бачите ви там - перше - це наша високоефективна аналітика SAS. Це буде так - я використовую багато наших існуючих технологій і платформ, таких як Enterprise Miner або просто SAS, а не просто роблю багатопотоковість з деякими з тих алгоритмів, які ми вбудували в ті інструменти, які ми зробили для років, але також масово паралельно цим. Отже, щоб перемістити дані з цієї великої платформи даних у простір пам’яті на той LASR Analytic Server, щоб ми могли виконувати аналітичні алгоритми - ви знаєте, багато нового машинного навчання, нейронних мереж, випадкових регресій лісу, таких видів речі - знову ж таки, дані, що сидять у пам'яті. Отже, позбувшись певного вузького місця парадигми MapReduce, де ми потрапляємо до цих платформ, це не так, як ви хочете робити аналітичну роботу. Отже, ми хочемо мати можливість один раз підняти дані в простір пам’яті і повторити їх, знаєте, іноді тисячі разів. Отже, це концепція використання цього високоефективного аналітичного LASR-сервера.
Ми також - інші додатки під ним, візуальна аналітика, що дозволяє нам зберігати ці дані в пам'яті та обслуговувати більшу сукупність цих же даних. Таким чином, дозволяючи людям робити великі дослідження даних. Отже, перед тим, як виконати нашу розробку моделі, ми вивчаємо дані, розуміємо їх, запускаємо кореляції, робимо прогнозування чи тенденції дерев рішень - такі речі - але дуже візуально, інтерактивним способом щодо даних, що сидять у пам'яті платформа. Це також обслуговує наше співтовариство з Бі-Бі-Сі, оскільки воно має дуже широку базу користувачів, які можуть вражати цю платформу для того, щоб робити стандартні види запису, які ви бачите - що майже будь-який, знаєте, постачальник BI.
Наступним кроком ми переходимо на службу. І щоб допомогти нашим статистикам і нашим аналітикам, щоб вони могли робити подібне спеціальне моделювання з даними, що сидять у пам'яті, вилученими з візуальної аналітики та дослідження у нашій програмі візуальної статистики. Це можливість людям брати, не запускати статистику в партіях, які звикли повторювати, запускати моделі, бачити результати. Отже, що може запустити модель, дивіться результати. Це для візуального перетягування та інтерактивного статистичного моделювання. Таким чином, це допомагає нашим статистикам і нашим науковцям даних зробити багато того раннього розвідувального візуального статистичного дослідження.
І тоді ми не забули своїх кодерів - люди, які насправді хочуть мати, вміти знімати шари інтерфейсу навпроти, - це писати програми та писати власну кодову базу в SAS. І це наша статистика пам'яті Hadoop. І це - по суті, код коду, який дозволив нам взаємодіяти з цим аналітичним сервером LASR, щоб безпосередньо видавати команди та налаштовувати ці програми на основі нашого запиту. Це аналітичний фрагмент.
Як налаштовуються ці речі ... На жаль, хлопці, мені шкода. Там ми йдемо.
Отже, є дійсно кілька способів зробити це. Одне - зробити це з великими даними - в цьому випадку з Hadoop. І ось у нас є той SAS LASR Analytic Server, який працює в окремій групі машин, оптимізованих для жорсткої аналітики.Це добре розташоване і близько до великої платформи даних, що дозволяє нам масштабувати його окремо від великої платформи даних. Отже, ми бачимо, що люди роблять це, коли вони не хочуть мати щось подібне до того, що я характеризую, як програмне забезпечення вампірів, що їсть у кожному з вузлів кластеру Hadoop. І вони не обов'язково масштабують ту велику платформу даних, яка підходить для важкого підйому в аналітиці пам'яті. Так, у вас може бути 120 вузлів їх кластеру Hadoop, але вони можуть мати 16 вузлів аналітичних серверів, розроблених для виконання такої роботи.
Нам все ще дозволяється підтримувати цей паралелізм від великої платформи даних, щоб витягнути дані в пам'ять. Отже, це дійсно використання SAS з платформою Hadoop. Тоді інша модель призначення призначена для того, щоб сказати, що ж, ми можемо використовувати і цю товарну платформу і підштовхувати її - по суті, запускати аналітичний сервер LASR на платформах Hadoop. Тож ми тут ... ви працюєте на платформі великих даних. Це також деякі інші наші постачальники приладів. Отже, це дозволило нам по суті використовувати цю товарну платформу для виконання цієї роботи.
Ми бачимо, що частіше в таких речах, як високоефективна аналітика, де це аналітичний цикл одноразового використання або одноразового використання, більш орієнтований на партію, де ви знаходитесь - вам не хочеться обов'язково споживати простір пам’яті в Hadoop платформа. Ми дуже гнучкі в такій моделі розгортання, безумовно, працюючи з YARN у багатьох цих випадках, щоб переконатися, що ми граємо в хороші кластери.
Гаразд, так це аналітичний світ, просто щоб це було зрозуміло з аналітичним додатком. Але я зазначив, що SAS на самому початку також є платформою управління даними. І є речі, які доцільно підштовхувати логіку до тієї платформи, де це доречно. Отже, є кілька способів, як ми це робимо. Один з них - у світі інтеграції даних. Робота з трансформацією даних може не мати сенсу витягувати їх назад, як ми чули раніше, виконуючи важливі підпрограми якості даних. Ми хочемо, безумовно, просунути такі речі, як підпрограми якості даних вниз на цю платформу. А потім, такі речі, як моделювання балів. Отже, я розробив свою модель. Я не хочу переписувати цю річ у MapReduce і ускладнювати та забирати багато часу, щоб переробити цю роботу на рідну платформу бази даних.
Отже, якщо ви подивитесь, наприклад, на наш прискорювач оцінки Hadoop, який дозволяє нам по суті взяти модель і натиснути математичну логіку SAS вниз на цю платформу Hadoop і виконати її там, використовуючи паралелізм, який знаходиться у цій великій платформі даних. Тоді ми маємо наш прискорювач коду для різних платформ, включаючи Hadoop, і це дозволяє нам по суті паралельно керувати кодовим кодом даних SAS всередині платформи - таким чином, роблячи роботу з трансформацією даних на платформі. А потім наш прискорювач якості даних SAS, який дозволяє нам мати базу знань про якість, яка може робити такі речі, як гендерне узгодження, стандартизаційний код відповідності - все те, що стосується якості даних, які ви вже чули сьогодні.
І тоді, останній фрагмент, є завантажувач даних. Ми знаємо, що наші ділові користувачі повинні мати можливість не писати код і робити перетворення даних у цих великих платформах даних. Навантажувач даних - це приємний графічний інтерфейс WYSIWYG, який дозволяє нам з'єднати ці інші технології разом. Це як майстер поводження, скажімо, запустити запит Hive або запустити процедуру якості даних, і в цьому випадку не потрібно писати код.
Останнє, що я згадаю - це передня частина. У нас - як я вже згадував раніше - у світі величезна нога SAS. І це, ми не можемо просто робити всі ті платформи, які є там, щоб бути в цьому просторі негайно. Отже, у нас, безумовно, є певна кількість користувачів, яким потрібно отримати дані, що знаходяться на цих великих платформах даних, таких як вилучення даних із Терадати та повернення їх у Hadoop, і навпаки. Запуск моделей Я вже знаю, як запускатись на своїх серверах SAS, але мені потрібно отримати дані, які зараз розміщуються на платформі Hadoop. Отож, є ще одна маленька піктограма, яка називається "від", і яка дозволяє нам підключатися за допомогою наших двигунів доступу SAS - двигуни доступу до Хадоопа до Клудери в Полі, до Терадати, до Грінплума до ... І список продовжується. Це дозволяє нам використовувати наявні зрілі платформи SAS, які вже є, щоб отримати дані з цих платформ, виконати роботу, яку нам потрібно виконати, підштовхнути результати назад у ці області.
Останнє, що я зазначу, це те, що всі ці технології, які ви бачите, регулюються одними і тими ж загальноприйнятими метаданими. Отже, ми говоримо про отримання роботи з трансформації, правила якості даних при роботі, переміщення її в пам'ять, щоб можна було робити аналітику, розробку моделі в балах. У нас там весь аналітичний спосіб життя, життєвий цикл керуються загальними метаданими, управлінням, безпекою, всіма речами, про які ми говорили раніше сьогодні.
Отож, лише резюме, там потрібно забрати ці три великі речі. Одне полягає в тому, що ми можемо ставитися до платформи даних так само, як до будь-якого іншого джерела даних, витягуючи з них, підштовхуючи до них, коли це доречно і зручно. Ми можемо працювати з цими великими платформами даних, перераховуючи дані у спеціально розроблену аналітичну платформу пам'яті. Отже, це LASR-сервер.
І тоді, нарешті, ми можемо працювати безпосередньо в цих великих платформах даних, використовуючи свої можливості розподільної обробки, не переміщуючи дані.
Ерік: Ну, це фантастичні речі, люди. Так, це чудово! Отже, давайте заглибимося в деякі питання. Зазвичай на ці події ми їдемо приблизно 70 хвилин або трохи довше. Отже, я бачу, що у нас все ще чудова аудиторія. Джордж, я думаю, я перекладу тобі наше перше питання. Якщо ви говорите про просування вашого бінарного звуку в Hadoop, я думаю, це звучить для мене так, як ви справді оптимізували обчислювальний робочий процес. І це весь ключ, щоб можна було керувати цим типом управління даними в режимі реального часу, досягненнями якості якості даних, адже це саме те значення, яке ви хочете отримати, правда? Якщо ви не хочете повертатися в старий світ MDM, де він дуже громіздкий і займає багато часу, і вам дійсно доведеться змушувати людей діяти певними способами, що майже ніколи не працює. І ось, що ви зробили, ви скоротили цикл того, що було. Назвемо це днями, тижнями, іноді навіть місяцями до секунд, правда? Це те, що відбувається?
Джордж: Це абсолютно правильно, тому що масштаби, які ми отримуємо, та ефективність, яку ми отримуємо з кластеру, насправді приголомшливі в плані, просто, ви знаєте, я завжди трохи вагаюся щодо орієнтирів. Але тільки на порядок, коли ми запустили б мільярд, 1,2 мільярда записів і зробили повну стандартизацію адрес - я кажу, що машина середнього рівня HP, - це займе, як, знаєте, вісім процесорних машин, ви знаєте , Ви знаєте, 2 гіга оперативної пам’яті на ядро, для запуску потрібно 20 годин. Ми можемо це зробити приблизно через вісім хвилин на кластерному 12-вузловому кластері. Отже, масштаб обробки, який ми можемо зробити зараз, настільки різко відрізняється, що - і це дуже добре відповідає ідеї, що у вас є всі ці дані у вашому розпорядженні. Отже, не так ризикувати робити обробку. Якщо ви зробили це неправильно, можете переробити його. Ви маєте час, знаєте. Це дійсно змінило масштаб цього, де, ви знаєте, такі види ризиків справді стали справжніми бізнес-проблемами для людей, коли вони намагалися використовувати рішення MDM. У вас повинно бути 30 осіб в офшорних зонах, які здійснюють управління даними та все. І так, ви все ще повинні мати щось із цього, але швидкість та масштаб, з яким ви зараз можете це обробити, справді дає вам набагато більше місця для дихання.
Ерік: Так, це дійсно дуже гарний момент. Я люблю цей коментар. Отже, у вас є час переробити це ще раз. Це фантастично
Джордж: Так.
Ерік: Ну, це змінює динаміку, правда? Це змінює, як ви думаєте про те, що збираєтеся спробувати. Я маю на увазі, це я пам’ятаю 18 років тому в галузі, яка робила спецефекти, тому що у мене був клієнт, який був у тому просторі. І ти натискаєш кнопки, щоб зробити це, і ти підеш додому. І ви повернетесь, можливо, в суботу вдень, щоб побачити, як це відбувається. Але якщо ви помилилися, це було дуже, дуже, дуже боляче. І ось, це зовсім не так - це навіть не так вже й боляче, щоб у вас була можливість спробувати ще щось. Треба сказати, я думаю, що це справді дуже гарний момент.
Джордж: Це точно. Так, і ти дуєш зайву ногу. Ви знаєте, що за старих днів ви проходили на півдорозі роботу, і вона не вдається, ви підірвали свій SOS. Це воно.
Ерік: Так. І у вас великі проблеми, так. Це вірно.
Джордж: Це правильно. Це вірно.
Ерік: Кіт, дозволь мені перенести тебе. Я пам’ятаю, що робив інтерв’ю з вашим КІЛ, Кітом Коллінз, я вважаю, що повернувся, я думаю, 2011 рік, можливо. І він багато говорив про напрямок, який спеціально займає SAS стосовно роботи з клієнтами для вбудування аналітики, отриманої від SAS, в операційні системи. І звичайно, ми чули, як Майк Фергюсон говорив про важливість запам'ятовування. Вся ідея тут у тому, що ви хочете мати можливість пов'язати цей матеріал у своїх операціях. Ви не хочете аналізу у вакуумі, відключеному від підприємства. Це не має жодної цінності.
Якщо ви хочете аналізу, який може безпосередньо впливати та оптимізувати операції. І якщо я озирнусь назад - і мушу сказати, я вважав, що тоді це гарна ідея - це виглядає як реальна, дуже розумна ідея в ретроспективі. І я здогадуюсь, це справжня перевага, яку ви маєте І звичайно, ця велика спадщина, ця величезна база для встановлення та те, що ви були зосереджені на вкладанні цієї аналітики в операційні системи, а це означає, що зараз - і дано, це потребує певної роботи - я впевнений, що ви ' я над цим працював досить важко. Але тепер ви можете скористатися всіма цими новими нововведеннями і дійсно в плані того, щоб мати можливість оперувати всіма цими речами зі своїми клієнтами. Це справедлива оцінка?
Кіт: Так, абсолютно. Концепція полягає в тому, що ви отримуєте таке уявлення про розробку рішень чи наукові рішення, які, певно, є дослідницькими, науковими справами. Якщо ви не зможете по-справжньому зайнятись інженерією ... Якщо ви думаєте про розробку автомобіля, у вас є дизайнери, які роблять цей прекрасний автомобіль, але це не до того часу, поки інженери не складуть цей план на місце і не зроблять реальний життєздатний продукт перед вами насправді можна поставити речі на місце, і це, по суті, те, що зробив SAS. Він об'єднав рішення - процес прийняття рішень з процесом інженерії рішень разом, так що коли ви говорите про прискорювачі, конкретно прискорювачі балів, ви знаєте, якщо ви берете модель, яку ви розробили, і зможете її витіснити до Терадати або перенести її до Oracle або Hadoop, з нульовим простоєм для розробки моделі, до розгортання моделі. Це головне, оскільки моделі з часом деградують, точність цих моделей. Отже, чим довше вам потрібно взяти це і ввести його у виробництво, це втрата точності моделі.
І тоді, інший фрагмент - ви хочете мати змогу контролювати цей процес і керувати ним у часі. Ви хочете зневажити моделі, коли вони старі та неточні. Ви хочете подивитися на це, перевірити точність їх у часі та відновити їх. Таким чином, у нас є інструменти управління моделями, які також сидять поверх того, що дійсно відстежує метадані навколо модельованого процесу. І люди казали, що моделювання, ви знаєте, таке поняття, як фабрика моделей, або як би ви хотіли це назвати. Річ у тому, що ми вводимо метадані та управління в цей процес, і саме тут ми вражаємо три основні речі - ми допомагаємо людям заробляти гроші, заощаджуємо гроші та тримаємо їх у в'язниці.
Ерік: Цей останній теж досить великий. Я хочу уникати всього цього. Отже, давайте поговоримо ... Я задаю одне останнє запитання, можливо, ви обидва можете скакати на цьому. Неоднорідність нашого світу лише зростатиме, мені здається. Я думаю, що ми неодмінно побачимо деяку кристалізацію навколо гібридних хмарних середовищ. Але, тим не менш, ви побачите, як багато основних гравців стирчать. IBM нікуди не їде. Oracle нікуди не дінеться. SAP нікуди не дінеться. І так багато інших продавців, які беруть участь у цій грі.
Крім того, з оперативного боку, де у вас буквально тисячі і тисячі різноманітних програм. І я чув - більшість з вас говорили про це, але я думаю, що ви обидва погодилися б із тим, що я говорив. Зараз ми спостерігаємо цю тенденцію щодо просто обчислювальної потужності в аналітичних двигунах, архітектурі. Компанії вже багато років говорять про те, щоб можна було застосувати інші двигуни там і обслуговувати якусь точку оркестрації. І я здогадуюсь, Джордже, я вам спочатку кину це. Мені здається, це щось, що не зміниться. У нас буде таке неоднорідне середовище, а це означає, що такі речі, як CRM в режимі реального часу та якість даних та управління даними. Вам, як постачальнику, потрібно буде взаємодіяти з усіма цими різними інструментами. І саме цього хочуть клієнти. Вони не хочуть чогось, що гаразд з цими інструментами, і не так добре з цими інструментами. Вони хочуть отримати Швейцарію MDM та CRM, правда?
Джордж: Це правильно. І це цікаво, адже ми дуже це сприйняли. Частково це історія, яку ми мали у космосі. І очевидно, ми вже працювали над усіма іншими базами даних, Терадатами та частинами світу. А потім, у процесі впровадження, саме так, як ми це зробили, просто так, щоб ви мали цей проміжок у всіх цих різних базах даних. Однією з речей, які мені здаються цікавими, є те, що у нас є кілька клієнтів, які просто скасовуються для усунення всіх реляційних баз даних. І це цікаво Ви знаєте, я маю на увазі, це добре. Це цікаво. Але я просто не бачу, як це відбувається насправді на великих підприємствах. Я давно не бачу цього. Тож я думаю, що гібрид тут вже давно і з іншого боку нашої програми, де в нашій платформі управління кампаніями є наша платформа обміну повідомленнями. Ми насправді спеціально розробили це. Тепер ми випустили версію, яка робить це, і яка тепер може з'єднуватися з гібридним середовищем даних і запитувати Hadoop, або запитувати будь-яку базу даних, будь-яку аналітичну базу даних. Тож я думаю, що це лише хвиля майбутнього. І я погоджуюсь, що віртуалізація, безумовно, відіграє велику роль у цьому, але ми просто - ми переходимо безпосередньо до даних про всі наші програми.
Ерік: Гаразд, чудово. І, Кіт, я передам це вам. Що ви думаєте про неоднорідний світ, з яким ми стикаємося, виступаючи в ролі підніжжя?
Кіт: Так, це дійсно захоплююче. Думаю, що ми знаходимо більше - не лише в стороні управління даними, - але те, що насправді захоплює, це природа відкритої бази аналітичної бази. Отже, ми бачимо такі організації, як такі технології, як Spark, і люди, які використовують Python та R та всі ці інші технології з відкритим кодом.Я думаю, що це можна трактувати як певний конфлікт чи загрозу. Але насправді у нас є кілька справді чудових компліментів з усіма цими технологіями з відкритим кодом. Я маю на увазі, для одного ми працюємо на платформах з відкритим кодом, для бога.
Але також, як можливість інтегрувати, наприклад, модель R в парадигму SAS, дозволяє використовувати найкраще з обох світів, правда? Можливо, тому ми знаємо, що деякі експериментальні речі в академічному світі та деякі роботи з розробки моделі є надзвичайними та дуже корисними у процесі розробки моделі. Але також, якщо ви могли з’єднати це з інструментом виробничого класу, він робить багато очищення та якості, перевіряючи та переконуючись, що дані, що передаються в модель, є попередньо підготовленими, щоб не вийти з ладу на виконання. А потім, маючи змогу робити такі речі, як моделі чемпіонів-претендентів з моделями з відкритим кодом. Це те, що ми розглядаємо, щоб увімкнути, і як частина цієї дійсно неоднорідної екосистеми всіх цих технологій. Так, так це більше - для нас, це більше для використання цих технологій та пошуку компліментів.
Ерік: Ну, це були фантастичні речі, люди. Ми трохи пішли тут, але ми хотіли б отримати якомога більше питань. Сьогодні ми передамо файл запитань нашим презентаторам. Тож якщо на будь-яке запитання ви не отримали відповіді, ми переконаємось, що на нього надійде відповідь. І люди, це завершує 2014 рік. Ви справді на радіо DM завтра та наступного тижня, і все це зроблено, і це відпустка.
Величезна подяка всім вам за ваш час та увагу, за перегляд усіх цих чудових веб-трансляцій. Ми маємо чудовий рік у 2015 році. І ми скоро поговоримо з вами, люди. Знову дякую. Ми подбаємо Бувай.