Винос: Ведуча Ребекка Йозвяк обговорює поточну аналітику з провідними фахівцями галузі.
На даний момент ви не ввійшли в систему. Будь ласка, увійдіть або зареєструйтесь, щоб переглянути відео.
Ребекка Йозвяк: Пані та панове, привіт, ласкаво просимо до Hot Technologies 2016! Сьогоднішня назва - "Запрягання Firehose: отримання ділової цінності від Streaming Analytics". Це Ребекка Йозв'як. Я другий, хто командує ведучим веб-трансляцій, коли наш дорогий Ерік Кавана не може бути тут, тож приємно бачити сьогодні стільки з вас.
Цей епізод трохи відрізняється від інших. Ми якось поговорили про те, що спекотно, і звичайно, цей рік - гарячий. Останні кілька років були гарячими. Завжди виходять нові речі. Сьогодні ми говоримо про потокову аналітику. Потокова аналітика сама по собі нова. Звичайно потокові, центральні дані, дані RFID, це не обов'язково нові. Але в архітектурі даних ми десятиліттями настільки зосереджені на даних у спокої. Бази даних, файлові системи, сховища даних - все це переважно для пакетної обробки. Але тепер із зміною створення цінності за допомогою потокових даних, даних емоцій, деякі називають це живими потоками, вони дійсно потребують потокової архітектури, а не даних спокійних архітектур, до яких ми звикли, і до яких потрібно бути здатними обробка швидкого прийому, в режимі реального часу або майже в режимі реального часу. Він повинен вміти обслуговувати не лише Інтернет речей, але Інтернет всього.
Звичайно, в ідеалі було б непогано, щоб дві архітектури жили поруч, одна рука мила іншу, так би мовити. Незважаючи на те, що давні дані, дані за тижні, давні роки, як і раніше, мають значення, історичну аналітику, аналіз тенденцій, це живі дані, які рухають живий інтелект в наші дні, і тому потокова аналітика стала такою важливою.
Я сьогодні говорю про це більше. У нас є наш науковець Дез Бланчфілд, який зателефонував з Австралії. Зараз йому рано вранці. У нас є наш головний аналітик, доктор Робін Блер. До нас приєднується Ананд Венугопал, керівник продукту StreamAnalytix в Impetus Technologies. Вони дійсно зосереджені на потоковому аналітичному аспекті цього простору.
З цим я збираюся йти вперед і передавати його Дезу.
Dez Blanchfield: Дякую. Мені потрібно захопити контроль над екраном тут і попсувати вперед.
Ребекка Йозвяк: Ось ви йдете.
Dez Blanchfield: Поки ми розбираємо слайди вгору, дозвольте мені просто висвітлити основну тему.
Я буду тримати її на високому рівні, і я триматиму її приблизно 10 хвилин. Це дуже велика тема. Я брав участь у заході, коли ми провели два-три дні, заглиблюючись у деталі того, що таке обробка потоків, та поточні рамки, які ми розробляємо, і що має робити аналітика в цих потоках великого обсягу.
Ми будемо просто роз'яснювати, що ми маємо на увазі, використовуючи поточну аналітику, а потім поглибимося, чи можна отримати цінність бізнесу, оскільки це справді те, що шукає бізнес. Вони хочуть, щоб люди пояснили їм дуже швидко і стисло, де я можу отримати значення, застосувавши якусь форму аналітики до наших потокових даних?
Що таке потокова аналітика?
Потокова аналітика дає організаціям можливість отримувати цінність із даних про великі та високі швидкості, які вони отримують через бізнес у різних формах у русі. Важлива відмінність тут полягає в тому, що ми мали довгу історію розробки аналітики та об'єктивів та переглядів даних, які ми обробляли в спокої десятиліттями з моменту винайдення мейнфрейму. Помітна зміна парадигми, яку ми спостерігали протягом останніх трьох-п’яти років у тому, що ми називаємо “веб-шкалою”, - це проникнення в потоки даних, що надходять до нас в режимі реального часу або майже в реальному часі, а не просто обробка та пошук співвідношення подій або запускає події, але виконуючи справді детальну, глибоку аналітику в цих потоках. Це суттєвий перехід до того, що ми робили до цього, або збирати дані, вводити їх у якесь сховище, традиційно великі бази даних зараз, великі рамки великих даних, такі як платформа Hadoop, і виконувати обробку пакетного режиму на цьому і отримувати якесь прозріння.
Нам дуже добре це робити дуже швидко і намагаються багато важкого заліза, але ми все-таки дійсно фіксуємо дані, зберігаємо їх, а потім переглядаємо їх і отримуємо якусь інформацію та аналітику. Перехід до виконання такої аналітики під час передачі даних був дуже новою та захоплюючою сферою зростання для типів речей, що відбуваються навколо великих даних. Він вимагає зовсім іншого підходу, щоб просто захопити, зберігати та обробляти та виконувати аналітику.
Одним з ключових рушій для зміни та зосередження уваги на аналітиці в потоці є те, що ви можете отримати значну цінність для бізнесу, отримуючи цю інформацію швидше і легше, коли дані надходять до вас, оскільки інформація стає доступною для бізнесу. Ідея робити обробку в кінці дня вже не актуальна в певних галузях. Ми хочемо, щоб ми могли робити аналітику на льоту. На кінець дня ми вже знаємо, що сталося, як це сталося, а не доходити до кінця дня та виконувати цілодобову партійну роботу та отримувати цю інформацію.
Потокова аналітика полягає в тому, щоб потрапити прямо в цей потік, тоді як потоки даних, як правило, є декількома потоками з дуже великими обсягами даних і даних, що надходять до нас в рух дуже, дуже швидко, і отримують розуміння або аналітику цих потоків, оскільки вони приходять до нас. щоб дозволити цьому виходити в спокої і виконувати аналітику на них.
Як я вже згадував, у нас було десятиліття і десятиліття виконувати те, що я називаю пакетною аналітикою. Я поставив тут дуже класну картину. Це зображення джентльмена, що стоїть перед знущається комп’ютером, який було створено корпорацією RAND все життя тому, і саме так вони виглядали на комп'ютері в будинку. Що цікаво, це те, що вже тоді вони мали цю концепцію всіх цих маленьких циферблатів, і ці циферблати представляли інформацію, що надходить з дому та обробляється в режимі реального часу і розповідає вам, що відбувається. Простий приклад - це набір барометричного тиску і температури, який ми можемо бачити, де ми бачимо, що відбувається в режимі реального часу. Але я думаю, що ще тоді, коли корпорація RAND зібрала цей маленький макет разом, вони насправді вже думали про обробку даних та проведення аналітики на ній, як це надходить у потоковому форматі. Я не зовсім впевнений, чому вони поклали кермо на комп'ютер, але це дуже круто.
З часу створення цього ефіру ми мали уявлення про збирання даних та проведення пакетної аналітики. Як я вже говорив з великим зрушенням зараз, і ми це бачили на вподобання гравців веб-масштабів, яких ми всі знаємо, всі вони є домашніми брендами, як і LinkedIn, та інтерактивна поведінка, яку ми маємо з цими соціальними платформами, вимагає не просто захоплювати, зберігати та обробляти в пакетному режимі, але вони фактично фіксують та залучають аналітику на льоту з потоків даних, що надходять. Коли я щось щебечу, їм не тільки потрібно захопити та зберігати та робити щось пізніше, але й потрібно мати можливість негайно повернути його в мій потік і поділитися цим з іншими людьми, які йдуть за мною. Це модель пакетної обробки.
Чому ми пішли б по цьому маршруту? Чому організації вкладають час, зусилля та гроші, навіть якщо розглядати завдання, спрямований на шлях потокової аналітики? Організації мають таке величезне бажання досягти підвищення продуктивності над своїми конкурентами у галузях, в яких вони перебувають, і збільшення продуктивності може бути швидко впроваджене за допомогою простої потокової аналітики, і це може початися з простого відстеження даних у реальному часі, що ми вже є знайомий з. У мене там невеликий скріншот Google Analytics. Це, мабуть, один із перших випадків, коли ми справді отримали практичну аналітику споживачів. Отже, коли люди відвідували ваш веб-сайт, і ви отримуєте кількість підрахунків звернень, за допомогою крихітного фрагмента JavaScript у нижній частині вашої веб-сторінки в HTML, вбудованому у ваш веб-сайт, ці маленькі коди робляться в реальному часі назад до Google, і вони були виконуючи аналітику на потоках даних, що надходять із кожної сторінки на вашому веб-сайті, кожного об'єкта на вашому веб-сайті в режимі реального часу, і вони повертаються вам на цій справді милій маленькій веб-сторінці на інформаційній панелі графіка в режимі реального часу, милі маленькі гістограми та рядки графік, що показує X кількість людей, які історично потрапляють на вашу сторінку, але ось скільки їх зараз.
Як ви можете бачити на цьому скріншоті, він говорить про 25 зараз. Наразі це 25 людей на той момент, коли цей знімок екрана був на цій сторінці. Це перший реальний шанс, який ми зіграли на інструменті аналізу споживачів. Я думаю, що багато людей насправді це зрозуміли. Вони просто зрозуміли силу знання того, що відбувається, і як вони можуть на це реагувати. Коли ми думаємо про масштаби авіоніки, літаки навколо яких літають, то в США лише 18 700 внутрішніх рейсів на день. Я прочитав доповідь деякий час тому - це було близько шести-семи років тому - що кількість даних, що їх виробляли ці літаки, становила від 200 до 300 мегабайт у старій технічній моделі. У сучасних проектах літаків ці літаки виробляють близько 500 гігабайт даних або близько половини терабайт даних за один політ.
Коли ви дуже швидко зробите математику з верхньої частини голови, то 18 700 внутрішніх рейсів кожні 24 години тільки в повітряному просторі США, якщо всі сучасні літаки виробляють близько половини терабайт, це 43 до 44 петабайт даних, що надходять через це відбувається, поки літаки перебувають у повітрі. Це відбувається, коли вони приземляються, і вони роблять звалища даних. Тоді вони заходять у магазин і мають повний переказ даних від інженерних команд, щоб подивитися на те, що відбувається в підшипниках, колесах та всередині двигунів. Деякі з цих даних мають бути оброблені в режимі реального часу, щоб вони могли приймати рішення, якщо виникає реальна проблема, поки літак знаходився в повітрі або поки він знаходиться на землі. Ви просто не можете цього робити в пакетному режимі. В інших галузях, які ми бачимо там, серед фінансів, охорони здоров'я, виробництва та інженерії, вони також розглядають, як вони можуть отримати це нове розуміння того, що відбувається в режимі реального часу, на відміну від того, що просто зберігається в базах даних на термін.
Існує також така концепція поводження з даними, як те, що я називаю швидкопсувним товаром або швидкопсувним товаром - багато даних втрачають значення з часом. Це все частіше трапляється з додатками для мобільних пристроїв та інструментами соціальних медіа, тому що те, про що говорять люди, і що зараз у тренді - це те, на що ти хочеш відповісти. Коли ви думаєте про інші частини нашого життя з логістикою та доставкою їжі навколо, ми розуміємо поняття швидкопсувного товару в цьому сенсі. Але подумайте про дані, які проходять через вашу організацію, і про значення, яке вона має. Якщо хтось із вами зараз займається деяким бізнесом і ви можете спілкуватися з ними в режимі реального часу, ви не хочете чекати години, щоб дані могли бути захоплені і поміщені в систему на зразок Hadoop, а потім натисніть цю кнопку, не зможете зараз з цим впоратися, і ви хочете мати можливість це зробити на вимогу клієнта негайно. Зараз у вас з’явиться термін, який зараз з’являється багато, де люди говорять про наявність потоку даних у режимі реального часу, який може надати вам персоналізацію, і про налаштування персоналізації в системі, яку ви використовуєте, під свій індивідуальний досвід. Тому, наприклад, коли ви потрапляєте на такий інструмент, як інструмент пошуку Google, якщо я запитую, а ви робите той самий запит, незмінно ми не отримуємо точні дані. Ми отримуємо по суті те, що я називаю досвідом знаменитостей. Мене лікують одноразово. Я отримую власну особисту версію того, що відбувається в цих системах, на основі профілів та даних, які вони зібрали на мене, і я мав змогу робити аналітику в режимі реального часу в потоці.
Ця ідея того, що дані є швидкопсувним товаром, є справжньою справою, і значення даних, що зменшуються з часом, - це те, з чим ми маємо мати справу сьогодні. Це не вчорашня річ. Мені подобається ця картина ведмедя, що хапає лосося, вистрибуючи з річки, тому що він дійсно малює саме те, що я бачу в потоковій аналітиці. Це ця величезна річка даних, що надходить до нас, вогонь, якщо хочете, а ведмідь сидить посеред струмка. Він буде робити аналітику в реальному часі щодо того, що відбувається навколо нього, щоб він міг реалізувати свою здатність захоплювати рибу в повітрі. Це не так, як просто зануритися в потік і схопити його. Ця річ стрибає в повітрі, і їй потрібно бути в потрібному місці в потрібний час, щоб зловити цю рибу. Інакше він не снідає та не обідає.
Організація хоче зробити те ж саме зі своїми даними. Вони хочуть отримати цінність із того, що зараз перебуває в русі величезних обсягів даних. Вони хочуть провести аналітику цих даних і даних про швидку швидкість, тому це не лише кількість даних, що надходять до нас, а це швидкість, з якої вони надходять. Наприклад, у безпеці - це всі ваші маршрутизатори, комутатори, сервери, брандмауери та всі події, що надходять з тих, і десятки тисяч, якщо не сотні тисяч пристроїв, у деяких випадках - швидкопсувні дані. Коли ми думаємо про це в Інтернеті речей та промисловому Інтернеті, ми говоримо про мільйони, якщо не мільярди датчиків, і коли дані надходять через які проводить аналітику, ми зараз дивимось на складну обробку подій з порядком та швидкістю, якого ми ще ніколи не бачили, і нам сьогодні доводиться займатися цим. Нам потрібно будувати інструменти та системи навколо цього. Це справжній виклик для організацій, оскільки, з одного боку, у нас є дуже великі бренди, які роблять DIY, печу самі, коли у них є можливість зробити це і набір навичок та інженерії. Але для пересічної організації це не так. У них немає наборів навичок. Вони не мають ні можливості, ні часу, ні навіть грошей, щоб вкласти їх у з'ясування. Усі вони спрямовані на цю концепцію прийняття рішень у реальному часі.
Використовуйте випадки, з якими я стикався, і вони знаходяться в кожному широкому спектрі кожного сектора, який ви можете собі уявити, люди сидять і звертають увагу та говорять: як ми можемо застосувати аналітику до наших даних потоку? Ми говоримо про веб-сервіси в масштабному масштабі. Існують традиційні платформи соціальних медіа та електронна пошта та роздрібна торгівля в Інтернеті - наприклад, програми. Всі вони намагаються надати нам цей досвід знаменитості в реальному часі. Але коли ми переходимо до більшої кількості технологічних служб стеки, телефонних послуг, голосу та відео, я бачу людей, які гуляють навколо, роблячи FaceTime по телефонах. Це просто вибух. Мені здається, що люди тримають телефон перед собою і розмовляють з відеопотоком друга, на відміну від того, щоб більше тримати його за вухо. Але вони знають, що можуть це зробити, і вони пристосувались і їм сподобався цей досвід. Розвиток цих додатків і платформ, які їх постачають, повинні виконувати аналітику в реальному часі на цьому трафіку та на профілях трафіку, щоб вони могли робити прості речі, такі як ідеально маршрутизувати це відео, щоб якість голосу в Відео, яке ви отримуєте, є адекватним, щоб отримати хороший досвід. Ви не можете обробляти такі дані. Це не зробить відеопотік у режимі реального часу функціональним сервісом.
У фінансових операціях виникає проблема управління. Не годиться добиратися до кінця дня і дізнатися, чи ти порушив закон, переміщуючи приватні дані навколо місця. В Австралії у нас є дуже цікавий виклик, коли переміщення даних, пов’язаних з конфіденційністю, за межами берега - це ні-ні. Ви не можете брати мої PID, мої особисті особисті ідентифікаційні дані за кордон. В Австралії існують закони, які запобігають цьому. Постачаючи фінансові послуги, зокрема, державні служби та агенції, вони повинні робити аналітику в реальному часі зі своїми потоками даних та інструкціями зі мною, щоб переконатися, що те, що вони мені надають, не залишає берегів. Усі речі повинні залишатися на місцях. Вони повинні зробити це в режимі реального часу. Вони не можуть порушити закон і просити прощення пізніше. Виявлення шахрайства - це досить очевидний варіант, який ми чуємо про транзакції кредитними картками. Але оскільки види трансакцій, які ми робимо у фінансових послугах, змінюються дуже, дуже швидко, є певні речі, які PayPal роблять першими зараз, щоб виявити шахрайство в режимі реального часу, коли гроші не переходять від однієї речі до іншої, але це фінансова операція між системами. Платформи для торгів на Ebay та виявлення шахрайства повинні здійснюватися в реальному часі в потоковому офісі.
Зараз спостерігається тенденція до видобутку та перетворення навантажувальної активності в потоках, тому ми не хочемо фіксувати все, що йде до потоку. Ми не можемо цього реально зробити. Люди дізналися, що дані люблять розбиватися дуже швидко, якщо ми все захопимо. Хитрість тепер полягає в тому, щоб виконувати аналітику на цих потоках і робити ETL на ній і просто фіксувати те, що вам потрібно, потенційно метадані, а потім задіяти прогностичну аналітику, де ми можемо реально потім розповісти, що відбудеться трохи далі вниз по шляхах того, що ми Щойно бачили у потоці на основі аналітики, яку ми виконували на цьому.
Постачальники енерго- та комунальних послуг відчувають таке масове бажання споживачів мати ціноутворення попиту. Я можу вирішити, що хочу придбати зелену енергію в один конкретний час дня, тому що я вдома один і не використовую багато пристроїв. Але якщо у мене буде вечеря, я, можливо, захочу ввімкнути всі свої пристрої, і я не хочу купувати дешеву електроенергію і чекати її доставки, але готовий заплатити більше витрат, щоб отримати цю потужність. Таке ціноутворення попиту, особливо на комунальні та енергетичні простори, вже відбулося. Наприклад, Uber - це класичний приклад того, що ви можете робити щодня, і все це залежить від ціноутворення попиту. Є декілька класичних прикладів того, як люди в Австралії отримують вартість проїзду в 10 000 доларів через велику потребу в новорічну ніч. Я впевнений, що вони вирішили цю проблему, але поточну аналітику проводять в режимі реального часу, перебуваючи в машині, розповідаючи, скільки я повинен заплатити.
Інтернет речей та потоки датчиків - ми лише подряпали поверхню, і ми справді просто провели основну розмову з цього питання, але ми побачимо цікавий зрух у тому, як технологія має справу з цим, тому що коли ви не говорите майже тисячі чи десятки тисяч, але сотні тисяч і, можливо, мільярди пристроїв, що передаються вам, майже жоден з технологічних стеків, які ми зараз отримали, не розроблений з цим.
Є кілька дійсно гарячих тем, які ми побачимо навколо, як безпека та кібер-ризик. Вони є для нас дуже реальними викликами. В Інтернеті є дійсно акуратний інструмент під назвою "Північ", де ви можете сидіти і дивитися на веб-сторінці різні кібератаки, що відбуваються в режимі реального часу. Дивлячись на це, ти думаєш, "о, це приємна маленька веб-сторінка", але приблизно через п’ять хвилин там ти розумієш об'єм даних, що система робить аналітику на всіх різних потоках усіх різних пристроїв у всьому світі. які подаються в них. Починає затуманювати розум того, як вони це виконують в основному на краю запису, і надає вам той простий маленький екран, який підкаже вам, що або на що інше атакує його в режимі реального часу та які типи атак. Але це дійсно акуратний маленький спосіб просто отримати гарний смак того, що аналізація потоку потенційно може зробити для вас у режимі реального часу, просто переглянувши цю сторінку та зрозумівши лише об’єм та завдання взяти потоки, обробляти аналітичні запити на їх і представляючи це в режимі реального часу.
Я думаю, що розмова, яку я маю на решті сесії, стосується всіх тих речей з одним цікавим поглядом, з моєї точки зору, і це є завданням DIY, випікайте його самостійно, підходить для деяких класичні єдинороги, які здатні дозволити собі будувати такі речі. Вони отримали мільярди доларів, щоб створити ці інженерні команди та побудувати їх центри обробки даних. Але 99,9% організацій, які хочуть досягти цінності у своєму бізнесі потокової аналітики, їм потрібно отримати послугу, що не є звичайною. Їм потрібно купувати товар поза коробкою, і вони, як правило, потребують певної консалтингової послуги та професійної послуги, яка допоможе їм реалізувати її, і вони отримують цю цінність у бізнесі та продають її назад як бізнес як робоче рішення.
З цим я повернуся до вас, Ребекка, тому що я вважаю, що саме зараз ми розберемося в деталях.
Ребекка Йозвяк: Відмінно. Дуже дякую, Дез. Це відмінна презентація.
Тепер я передаю м'яч Робіну. Відняти її.
Робін Блор: Добре. Оскільки Дез пішов у нітроподібну крупу переробки потоків, мені, здавалося, не було сенсу знову покривати це. Тож я просто збираюся взяти повністю стратегічний погляд.Дивлячись майже з дуже високого рівня на те, що відбувається в пеклі, і позиціонувати його, тому що я думаю, що це може допомогти людям, особливо нам людям, які раніше не перебувають у таборах, що переробляють потоки на великій глибині.
Обробка потоків тривала вже давно. Ми називали це CEP. До цього були системи в режимі реального часу. Оригінальні системи управління процесами насправді обробляли потоки інформації - звичайно, нічого не йшло так далеко, як зараз. Ця графіка, яку ви бачите на слайді тут; насправді вказується на багато речей, але вказує на вище та поза будь-яким іншим - на те, що тут є спектр затримок, що з’являються в різних кольорах. Що насправді сталося з часу винайдення обчислювальних чи комерційних обчислень, які надійшли приблизно в 1960 році, - це все стало все швидше і швидше. Раніше ми могли залежати від того, як це насправді виходило, якщо вам подобається в хвилях, адже це так виглядає. Це фактично залежить від цього. Тому що все це рухалося законом Мура, і закон Мура дав би нам коефіцієнт швидкості приблизно в десять разів протягом періоду близько шести років. Потім, коли насправді прийшло приблизно до 2013 року, це все зламалось, і ми раптом почали прискорюватися зі швидкістю, яку ми ніколи не бували, що дивно безпрецедентно. Ми отримували коефіцієнт приблизно десять у плані збільшення швидкості, а отже, скорочення затримки приблизно кожні шість років. За шість років, приблизно з 2010 року, ми отримали кратний принаймні тисячу. Три порядки, а не один.
Саме так відбувається і тому галузь так чи інакше, здається, рухається з фантастичною швидкістю - адже це так. Щойно переглядаючи значення цієї графіки, часи відгуку насправді є в алгоритмічному масштабі вниз по вертикальній осі. Реальний час - швидкість роботи за комп’ютером, швидше, ніж люди. Інтерактивні часи помаранчеві. Це коли ви взаємодієте з комп’ютером, де вам дуже потрібно від десятої до приблизно однієї секунди затримки. Вище є транзакція, де ми насправді думаємо про те, що ти робиш за комп’ютером, але якщо це погасне приблизно через п’ятнадцять секунд, це стає нестерпним. Люди насправді просто не чекатимуть комп’ютера. Все робилося партійно. Багато речей, які були зроблені партією, зараз спускаються прямо в транзакційний простір, прямо в інтерактивний простір або навіть у простір реального часу. Якщо раніше хвилеподібний з дуже невеликими обсягами даних ми могли б зробити щось із цього, то тепер ми можемо зробити з дуже великими обсягами даних, використовуючи надзвичайно масштабоване середовище.
Таким чином, все це говорить, що це дійсно час транзакцій та інтерактивних людей. Надзвичайно багато того, що зараз робиться з потоками, - це інформувати людей про речі. Деякі з них проходять швидше, ніж це, і він добре інформує, так що це в реальному часі. Тоді ми беремо ліцензію просто кинутись, як камінь, що робить миттєву аналітику здійсненною і, до речі, цілком доступною. Справа не в тому, що швидкість знизилася, а верхній просто зійшов. Мабуть, найбільший вплив у цьому серед усіх різних застосувань ви можете виконати з усією цією прогнозною аналітикою. Я скажу вам через хвилину.
Це просто магазин обладнання. Ви отримали паралельне програмне забезпечення. Ми говоримо про 2004 рік. Масштабна архітектура, багатоядерні чіпи, збільшення пам’яті, налаштований процесор. Тепер SSD накопичуються набагато швидше, ніж спінінг. Ви можете дуже сильно розпрощатися з диском на прощання. SSD також є в декількох ядрах, тому знову швидше і швидше. Незабаром ми з'явилися, що ми отримали пам'ятник від HP. Ми отримали 3D XPoint від Intel та Micron. Обіцянка цих полягає в тому, що це змусить все це все швидше і швидше. Коли ви насправді думаєте про дві нові технології пам’яті, обидві з яких зроблять цілий фундаментальний невеликий шматок, окрема плата піде швидше, ми навіть не бачили її завершення.
Технологія потоків, яка є наступною насправді, тут залишається. Тут має бути нова архітектура. Я маю на увазі, що Дез щось про це згадував у кількох пунктах у своїй презентації. Десятиліттями ми розглядали архітектуру як поєднання наборів даних і даних. Ми прагнули обробляти купи, і ми прагнули передавати дані між купами. Зараз ми в основному рухаємось до того, що ми називаємо архітектурою даних лямбда, яка поєднує обробку потоків даних із набором даних. Коли ви фактично обробляєте потік подій, що надходять проти історичних даних, як потік даних або купа даних, це я маю на увазі під архітектурою Lambda. Це в зародковому стані. Це лише частина малюнка. Якщо ви вважаєте щось таке складне, як Інтернет усього, про що також згадував Dez, ви дійсно зрозумієте, що існують всілякі проблеми з розташуванням даних - рішення щодо того, що слід обробляти в потоці.
Що я тут справді говорю, це те, що коли ми обробляли пакетно, ми фактично обробляли потоки. Ми просто не могли цього робити по черзі. Ми просто чекаємо, поки з’явиться велика купа речей, а потім обробляємо все це відразу. Ми переходимо до ситуації, коли насправді ми можемо обробляти речі в потоці. Якщо ми можемо обробити матеріали в потоці, то масиви даних, які ми маємо, стануть статичними даними, на які нам потрібно посилатися, щоб обробити дані в потоці.
Це приводить нас до цієї конкретної речі. Я вже згадував про це в деяких презентаціях з біологічною аналогією. Те, про що я хотів би, щоб ви думали, це на даний момент ми люди. У нас є три різні мережі для прогнозування в режимі реального часу. Їх називають соматичними, вегетативними та ентеричними. Ентерик - це ваш шлунок. Вегетативна нервова система доглядає за бійкою та польотами. Він насправді доглядає за швидкими реакціями на навколишнє середовище. Соматичне, яке доглядає за переміщенням тіла. Це системи в режимі реального часу. Цікаве про це - або я думаю, якесь цікаве - чимало воно є більш передбачувальним, ніж ви могли б собі уявити. Це так, ніби ви насправді дивитесь на екран приблизно в 18 дюймах від свого обличчя. Все, що ви можете чітко бачити, все, що ваше тіло здатне чітко бачити, насправді - це прямокутник 8 × 10. Все, що знаходиться поза цим, насправді розмито, що стосується вашого тіла, але ваш розум фактично заповнює прогалини і робить його не розмитим. Ви зовсім не бачите розмиття. Ви це чітко бачите. Ваш розум насправді робить метод прогнозування потоку даних для того, щоб ви бачили цю чіткість. Це щось цікаве, але ви можете насправді подивитися на те, як працює нервова система, і на те, як нам вдається обійти і поводити себе розумно - принаймні, деякі з нас - досить розумно і не натрапляючи на речі весь час.
Все це зроблено серією шкали нейронної аналітики всередині. Що відбудеться, це те, що в організаціях відбуватиметься така ж річ і збирається будувати такий самий предмет, і це буде обробка потоків, включаючи внутрішні потоки організації - речі, що відбуваються всередині це, речі, що відбуваються поза нею, миттєві відповіді, які насправді мають бути прийняті, - це, звичайно, живлення людини для прийняття рішень, для того, щоб усе це відбулося. Ось куди ми їдемо, наскільки я бачу.
Однією з речей, що є наслідком цього, є те, що рівень потокової програми йде добре. Це буде набагато більше, ніж ми бачимо зараз. Наразі ми збираємо низько вищий плід робити очевидні речі.
Так що все-таки такий висновок тут. Потокова аналітика колись є нішею, але вона стає мейнстрімом, і незабаром вона буде прийнята загалом.
З цим я поверну його Ребекці.
Ребекка Йозвяк: Дуже дякую, Робін. Чудова презентація, як завжди.
Ананд, ти наступний. Підлога ваша.
Ананд Венугопал: Фантастичний. Дякую.
Мене звуть Ананд Венугопал, і я керівник продукту StreamAnalytix. Це продукт, запропонований компанією Impetus Technologies, поза межами Лос-Гатоса, Каліфорнія.
Імпут насправді мав велику історію, коли був великим постачальником даних для великих підприємств. Таким чином, ми фактично провели ряд потокових впроваджень аналітики як компанія, що надає послуги, і ми дізналися багато уроків. Ми також здійснили перехід до того, щоб стати продуктовою компанією та компанією, орієнтованою на рішення, протягом останніх кількох років, і потокова аналітика очолює завдання перетворити Impetus в компанію, що значною мірою керується продуктами. Є кілька важливих, дуже-дуже ключових активів, які Impetus очистився завдяки нашому впливу на підприємства, і StreamAnalytix є одним із них.
Ми 20 років в бізнесі, і це чудовий набір продуктів і послуг, що робить нас величезною перевагою. І StreamAnalytix народився з усіх уроків, отриманих з наших перших п’яти чи шести реалізацій потоку.
Я торкнуся кількох речей, але аналітики, Дез і Робін, зробили фантастичну роботу в загальному висвітленні простору, тому я пропускаю багато контенту, який перекривається. Я, мабуть, поїду швидко. Ми бачимо, окрім справжніх потокових випадків, що використовують безліч просто прискорених пакетів, де на підприємствах є буквально дуже, дуже важливі пакетні процеси. Як бачите, весь цей цикл зондування події та аналізу та дії на ній фактично може зайняти тижні на великих підприємствах, і всі вони намагаються скоротити його на хвилини, а іноді і на секунди та мілісекунди. Тож будь-який швидший, ніж усі ці пакетні процеси, є кандидатами на придбання бізнесу, і це дуже добре, що значення даних різко зменшується з віком, тому більше значення є в початковій частині за секунди, що це щойно відбулося. В ідеалі, якщо ви могли передбачити, що буде, це найвище значення. Однак це залежить від точності. Наступне найвище значення - це коли він знаходиться саме там, коли це відбувається, ви можете проаналізувати його та відповісти. Звичайно, після цього значення різко зменшується, головний обмежувальний BI, який ми маємо.
Це цікаво. Ви можете очікувати різко наукової відповіді на те, чому потокова аналітика. У багатьох випадках ми бачимо, це те, що це зараз можливо і тому, що всі знають, що партія стара, партія нудна, а партія не крута. Зараз у всіх є достатня освіта про те, що можлива трансляція, і всі зараз мають Hadoop. Тепер у дистрибутивах Hadoop вбудована технологія потокової передачі, будь то "Шторм" або "Іскра", і, звичайно, черги, наприклад, Kafka тощо.
Підприємства, які ми бачимо, стрибають у це і починають експериментувати з цими справами, і ми бачимо дві широкі категорії. Один має щось спільне з аналітикою клієнтів та досвідом клієнтів, а другий - оперативною інформацією. Я дізнаюся про деякі деталі цього питання трохи пізніше. Цілий рівень обслуговування клієнтів та досвід роботи з клієнтами, і ми в компанії Impetus StreamAnalytix зробили це різними способами, це справді все справді, по-справжньому захоплюючи багатоканальну взаємодію споживача в режимі реального часу і надаючи їм дуже, дуже кон-чутливий досвід які сьогодні не поширені. Якщо ви переглядаєте в Інтернеті, на веб-сайті Банку Америки, ви досліджували деякі продукти, і ви просто зателефонували в кол-центр. Вони б сказали: "Ей Джо, я знаю, що ви досліджували деякі банківські продукти, хотіли б, щоб я вас заповнив?" Ви сьогодні цього не очікуєте, але це такий досвід, який справді можливий завдяки поточній аналітиці. У багатьох випадках це має величезну різницю, особливо якщо замовник почав досліджувати способи виходу зі свого договору з вами, переглянувши на Вашому веб-сайті застереження про дострокове припинення або умови дострокового припинення, а потім зателефонуйте, і Ви не можете прямо протистояти їм з цього приводу, але просто опосередковано роблять пропозицію про якусь першу акцію, оскільки система знає, що ця людина дивиться на дострокове припинення, і ви зробите цю пропозицію в цей момент, ви могли б дуже добре захистити цього замовника і захистити цей актив .
Це був би один приклад, плюс багато послуг для клієнтів - це дуже хороші приклади. Ми впроваджуємо сьогодні, знижує вартість в кол-центрі, а також забезпечує драматичні приємні враження від клієнтів. Dez зробив велику роботу в узагальненні деяких випадків використання. Ви можете зазирнути в цю діаграму пару хвилин. Я класифікував це як вертикаль, горизонталь та комбіновані області, IoT, мобільний додаток та кол-центр. Вони всі вертикалі та горизонталі. Це залежить від того, як ти на це дивишся. Підсумок, ми бачимо велику кількість горизонтальних застосувань, які є досить поширеними у галузях вертикалі, і є випадки конкретного вертикального використання, включаючи фінансові послуги, охорону здоров’я, телекомунікації, виробництво тощо. Якщо ви справді ставите собі запитання чи говорите собі що, «о, я не знаю, які існують випадки використання. Я не впевнений, чи справді є якась ділова цінність у потоковій аналітиці для моєї компанії або для нашого підприємства », - подумайте важко, подумайте двічі. Поговоріть з іншими людьми, оскільки є випадки використання, які сьогодні є у вашій компанії. Я дізнаюся про цінність бізнесу про те, як саме виходить цінність бізнесу.
У нижній частині піраміди тут ви маєте передбачуване технічне обслуговування, безпеку, захист від різання тощо. Ці випадки використання є захистом доходів та активів. Якби Target захищав їх порушення безпеки, яке траплялося протягом годин і тижнів, CIO міг би врятувати його роботу. Це може заощадити десятки або сотні мільйонів доларів і т. Д. Потокова аналітика в реальному часі дійсно допомагає захистити ці активи та захистити збитки. Це пряма додана вартість бізнесу саме там.
Наступна категорія стає вигіднішою, знижуючи ваші витрати та отримуючи більший дохід від поточної експлуатації. Це ефективність нинішнього підприємства. Це всі категорії випадків використання, які ми називаємо оперативною розвідкою в режимі реального часу, де ви глибоко розумієте, як поводиться мережа, як ведуть себе операції з клієнтами, як ведеться ваш бізнес-процес, і ви можете налаштувати. все це в режимі реального часу, тому що ви отримуєте зворотній зв'язок, ви отримуєте сповіщення. Ви отримуєте відхилення, відхилення в режимі реального часу, і ви можете швидко діяти і відокремлювати процес, який виходить за межі.
Ви потенційно також можете заощадити багато грошей на дорогих капітальних оновленнях та речах, які, на вашу думку, є необхідними, що може не знадобитися, якщо ви оптимізували послугу мережі. Ми чули про випадок, коли основний телекомунікаційний сервіс відклав 40-мільйонну модернізацію своєї мережевої інфраструктури, оскільки виявив, що у них є достатня потужність для управління поточним трафіком, що є оптимізацією та кращим виконанням інтелектуальної маршрутизації свого трафіку тощо. Це все можливо лише за допомогою деякої аналітики та механізму дій у реальному часі, яка діє на ці уявлення в режимі реального часу.
Наступний рівень доданої вартості - це розпродаж, перехресний продаж там, де є можливості отримати більше доходів та прибутку від поточних пропозицій. Це класичний приклад, про який багато хто з нас знає про те, що вони пережили там, де ви думаєте про своє життя, де сьогодні готові купити товар, який вам не пропонують. У багатьох, багатьох випадках це відбувається насправді. У вас на думці є речі, які вам подобається купувати, ви знаєте, що хочете купити, що у вас є список справ або щось таке, що вам сказала ваша дружина або якщо у вас немає дружини, але ви дуже хотіли купити і ви ходите по магазинах на веб-сайті або спілкуєтесь у магазині роздрібної торгівлі, у магазині просто немає конфесій, не має інтелекту для обчислення того, що вам може знадобитися. Отже, вони не захищають свій бізнес. Якщо поточну аналітику можна буде розгорнути, щоб дійсно зробити точні прогнози і які реально можливі на основі того, що найбільше відповідатиме цьому конкретному конфіденційності, у цього замовника на даний момент у цьому місці є багато розпродажів та перехресних продажів, і це знову приходить з поточна аналітика - можливість прийняти рішення щодо схильності до того, що цей клієнт, ймовірно, купить або відповість у той момент істини, коли є можливість. Ось чому я люблю ту картину, яку Дез показав з ведмедиком, щойно збирався їсти цю рибу. Це майже все.
Ми також вважаємо, що існує велика категорія кардинальних, трансформаційних змін на підприємстві, що пропонують абсолютно нові продукти та послуги просто на основі спостереження за поведінкою замовника, а все ґрунтується на спостереженні за поведінкою іншого підприємства. Якщо, скажімо, телекомунікаційна компанія або кабельна компанія дійсно дотримується моделей використання клієнтів у якому сегменті ринку він переглядає, яку програму в який час тощо, вони фактично закінчують створення продуктів та послуг, які майже просять бо якимось чином. Отже, вся концепція поведінки на багатьох екранах зараз, коли ми зараз майже сприймаємо це як належне, що ми можемо бачити вміст телевізора або кабелю в наших мобільних додатках. Деякі з цих прикладів виходять із тих нових продуктів та послуг, які пропонуються нам.
Я зрозумію, «Які міркування щодо архітектури потокової аналітики?» Ми намагаємось зробити це в кінцевому підсумку. Це архітектура лямбда, в якій ви змішуєте історичні дані та дані в режимі реального часу та бачите їх одночасно. Саме це дозволяє Sigma. Сьогодні всі ми маємо пакетну архітектуру та корпоративну картину. Ми вбираємось у якийсь стек BI та використання та додана архітектура Lambda. Оскільки швидкісний шар або потреба і Ламбда - це все злити ці два розуміння і бачити це комбінованим способом, насиченим способом, який поєднує в собі обоє розуміння.
Існує ще одна парадигма під назвою архітектура Kappa, яка пропонується там, де передбачається, що швидкісний шар є єдиним механізмом введення, який буде зберігатися в довгостроковій перспективі. Все пройде через цей шар швидкості. Існує навіть не буде офлайн механізм ETL. Все ETL відбудеться. Очищення, очищення даних, якісна ETL - все це відбуватиметься на дроті, адже майте на увазі, що всі дані народилися в режимі реального часу. У якийсь момент це був реальний час. Ми звикли ставити це на озера, на річках і океанах, потім робимо це на статичному аналізі, що ми забули, що дані народилися в якийсь момент реального часу.Всі дані насправді народжуються як подія в реальному часі, що сталася в момент часу, і більшість даних сьогодні на озері просто потрапили в базу даних для подальшого аналізу, і тепер ми маємо перевагу в архітектурі Lambda і Kappa бачачи його, аналізуючи його, попередньо обробляючи його і реагуючи на нього, коли він прибуде. Ось що дозволяють ці технології. Якщо ви дивитесь на це як на загальну картину, вона виглядає приблизно так, де всередині Hadoop, там вже є MPP та сховища даних.
Ми викладаємо це, оскільки важливо не просто говорити про нові технології на острові. Вони повинні інтегруватися. Вони повинні мати сенс у нинішньому кон'юнктурі підприємств, і як постачальники рішень, які обслуговують підприємства, ми дуже чутливі до цього. Ми допомагаємо підприємствам інтегрувати цілу справу. Ліва частина джерел даних подається як на верстви Hadoop, так і на сховища даних, а також на шар у режимі реального часу зверху, і кожен з цих об'єктів є запасними комп'ютерами, як ви можете бачити, а рівень споживання даних знаходиться праворуч сторона. Постійні зусилля спрямовані на те, щоб перемістити більшість дотримання, управління, безпеки, управління життєвим циклом тощо, що є сьогодні, всі вони були об'єднані в цю нову технологію.
Одне з речей, яке намагається зробити потокова аналітика, якщо подивитися на ландшафт сьогодні, то в ландшафті потокової технології багато що відбувається, і з точки зору корпоративного клієнта, є багато чого для розуміння. Є так багато, щоб не відставати. Ліворуч є механізми збору даних - NiFi, Logstash, Flume, Sqoop. Очевидно, я поставив заяву про відмову, сказавши, що це не вичерпно. Виходимо в черги, а потім надходимо в потокові двигуни з відкритим кодом - Storm, Spark Streaming, Samza, Flink, Apex, Heron. Напевно, чапля ще не є відкритим кодом. Я не впевнений, чи є, від. Потім ці потокові двигуни призводять до або підтримують компонент аналітичного додатка для налаштування, такий як комплексна обробка подій, машинне навчання, прогнозована аналітика, модуль оповіщення, потоковий ETL, фільтри статистичних операцій збагачення. Це все, що ми називаємо зараз операторами. Набір цих операторів, що з'єднуються разом, потенційно також може бути деяким звичаєм, який у значній мірі укладається, якщо це необхідно, стає програмою потокового передавання, яка працює на потоковому двигуні.
У рамках цього ланцюга компонентів вам також потрібно зберігати та індексувати дані у вашій улюбленій базі даних, улюбленому індексі. Можливо, вам також доведеться розповсюджувати кеш-пам'ять, що призводить до шару візуалізації даних у правій частині у верхній частині до комерційних товарів або продуктів з відкритим кодом, але в кінцевому підсумку вам потрібен якийсь продукт для візуалізації цих даних у режимі реального часу. Крім того, вам потрібно іноді малювати інші програми. Всі ми бачили, що значення, отримані лише завдяки дії, яку ви здійснюєте, зрозумієте, що дія буде тригером з аналітичного стека в інший стек додатків, який, можливо, змінився, це щось на стороні IVR, або запускає колл-центр вихідний дзвінок або щось подібне. Потрібно, щоб ці системи були інтегровані та якийсь механізм для вашого потокового кластера, щоб запускати інші програми, які надаються нижче за потоком даних.
Це загальний стек, який рухається зліва направо. Тоді у вас є сервісні шари, середній моніторинг, загальний рівень безпеки безпеки і т. Д. Переходьте до продуктів, які знаходяться там, у корпоративному просторі, які клієнти бачать, як дистрибуції Hadoop, у яких всі потокові, як я вже сказав, і є комерційні чи одиничні -доброякісні рішення, які, очевидно, є у наших конкурентів. У пейзажі є також багато інших, про які ми, можливо, тут не згадували.
Те, що ви там бачите, широко бачить корпоративний користувач. Як ви бачите, складний і швидко розвивається ландшафт технологій для обробки потоку. Ми повинні спростити вибір та їх користувацький досвід. Ми вважаємо, що підприємствам справді потрібна функціональна абстракція всього цього в простому у використанні інтерфейсі, який поєднує всі ці технології, що робить його дуже простим у використанні та не відкриває всіх рухомих частин і проблеми деградації, і результати діяльності, і питання забезпечення життєвого циклу для підприємства.
Абстракція функціоналу одна. Друга частина - це абстракція потокового двигуна. Потокові двигуни та домени з відкритим кодом з’являються раз на три, чотири чи шість місяців. Довго це була Буря. Самза підійшов, і тепер це іскрові потоки. Флінк піднімає голову, починаючи привертати увагу. Навіть дорожня карта Spark Streaming, вони створюють можливість потенційно використовувати інший двигун для чистої обробки подій, оскільки вони також розуміють, що Spark був розроблений для пакетної роботи, і вони роблять шлях у своєму баченні архітектури та їхній дорожній карті, щоб потенційно мати інший двигун для обробки потоку на додаток до поточного шаблону мікросерії в Spark Streaming.
Це реальність, з якою вам доведеться боротися, що еволюція буде багато. Вам справді потрібно захистити себе від цього потоку технологій. Тому що за замовчуванням вам доведеться вибрати один, а потім жити з ним, що не є оптимальним. Якщо ви дивитесь на це по-іншому, ви б’єтесь між собою: «добре, я повинен придбати власну платформу, де немає блокування, немає важелів відкритого коду, це може бути дуже високою вартістю і обмеженим гнучкість порівняно з усіма цими стеками з відкритим кодом, де ви повинні це зробити самостійно ». Як я вже сказав, це великі витрати та затримка виходу на ринок. Що ми говоримо, що StreamAnalytix - це один із прикладів чудової платформи, яка об'єднує корпоративний клас, надійний, єдиний постачальник, підтримується професійний сервіс - все те, що вам справді потрібно як підприємству, і сила гнучкості екосистеми з відкритим кодом де єдина платформа об'єднує їх - Ingest, CEP, аналітика, візуалізація та все це.
Це також робить дуже-дуже унікальну річ, яка об'єднує багато різних технологій двигунів під одним єдиним користувальницьким досвідом. Ми дійсно думаємо, що майбутнє - це можливість використовувати декілька потокових двигунів, оскільки різні випадки використання дійсно вимагають різних потокових архітектур. Як сказав Робін, існує цілий спектр затримок. Якщо ви справді говорите про рівень затримки в мілісекундах, десятки або навіть сотні мілісекунд, вам справді потрібна Шторм в цей час, поки не з’явиться ще один не менш зрілий продукт для меншої поблажливості або поблажливих часових рамків і затримок, можливо, через пару секунд, три, чотири, п’ять секунд, що діапазон, тоді ви можете використовувати іскрову трансляцію. Потенційно є й інші двигуни, які могли б робити і те, і інше. Підсумок, на великому підприємстві, будуть використовуватись випадки використання всіх видів. Ви дуже хочете, щоб у доступі та загальному користуванні було декілька двигунів з одним користувацьким досвідом, і саме це ми намагаємось створити в StreamAnalytix.
Просто швидкий огляд архітектури. Ми трохи переробимо це, але по суті, з лівого боку надходить безліч джерел даних - Kafka, RabbitMQ, Kinesis, ActiveMQ, усі ці джерела даних та черги, що надходять на платформу обробки потоків, де ви перейдіть до збирання програми, де ви можете перетягувати операторів, таких як ETL, усі речі, про які ми говорили. Внизу є кілька двигунів. На даний момент у нас є Storm and Spark Streaming - єдина в галузі та перша потокова платформа корпоративного класу, яка має багаторазову підтримку двигунів. Це дуже унікальна гнучкість, яку ми пропонуємо, крім усієї іншої гнучкості інформаційних панелей у режимі реального часу. Вбудований двигун CET. Ми маємо безперебійну інтеграцію з індексами Hadoop і NoSQL, індексами Solr і Apache. Ви можете приземлитися до своєї улюбленої бази даних незалежно від того, що це є, і дуже швидко створювати додатки, і швидко виходити на ринок, і залишатись в майбутньому. Це вся наша мантра в StreamAnalytix.
З цим я думаю, що закінчу свої зауваження. Не соромтеся звертатися до нас за додатковими запитаннями. Я хотів би, щоб слово було відкритим для запитань та запитань та обговорення на панелі.
Ребекка, до вас.
Ребекка Йозвяк: Чудово, добре. Дуже дякую. Дез і Робін, у вас є якісь запитання, перш ніж ми передамо їх питанням аудиторії?
Робін Блор: У мене питання. Я знову надію навушники, щоб ви могли мене почути. Одна з цікавих речей, якщо ви можете ласкаво сказати мені це, багато чого з того, що я бачив у просторі з відкритим кодом, виглядає тим, що я б сказав незрілим для мене. У певному сенсі, так, ви можете робити різні речі. Але схоже, що ми дивимось на програмне забезпечення в його першому чи другому випуску насправді, і я просто цікавився вашим досвідом організації, наскільки ви бачите незрілість середовища Hadoop як проблематичну чи це щось, що не робить ' не створювати занадто багато проблем?
Ананд Венугопал: Це реальність, Робін. Ви абсолютно праві. Незрілість не обов'язково знаходиться в області просто функціональної стійкості і речей, але, можливо, і деякі випадки цього. Але незрілість полягає більше в готовності до використання. Продукти з відкритим кодом, коли вони виходять, і навіть коли вони пропонуються дистрибуцією Hadoop, всі вони є безліччю різних здатних продуктів, компоненти просто збиті між собою. Вони не працюють спільно і не розроблені для безперебійного безперебійного користування, який, як Bank of America, Verizon або AT&T, розгортають програму потокової аналітики протягом декількох тижнів. Вони не створені для цього точно. Ось чому ми заходимо. Ми збираємо це разом і робимо його справді легким для розуміння, розгортання тощо.
Функціональна зрілість цього, я думаю, значною мірою є. Багато великих підприємств сьогодні використовують, наприклад, Storm. Багато великих підприємств сьогодні грають із Spark Streaming. У кожного з цих двигунів є свої обмеження в тому, що вони можуть робити, тому важливо знати, що можна, а що не можна робити з кожним двигуном, і немає сенсу ламати голову об стіну і говорити: вибрав іскрову стріму, і це не працює для мене в цій конкретній галузі ». Це не вийде. Будуть використовувати випадки, коли Spark Streaming стане найкращим варіантом, і будуть випадки використання, коли Spark Streaming може не працювати для вас. Ось чому вам дійсно потрібно кілька варіантів.
Робін Блор: Що ж, для більшості з них вам потрібно мати команди експертів. Тобто я навіть не знаю, з чого почати. Розумна співпраця кваліфікованих людей. Мене цікавить, як ви залучаєтеся до участі у роботі та як це відбувається. Це тому, що конкретна компанія працює за конкретною заявкою чи ви бачите щось таке, що я б назвав стратегічним прийняттям, коли вони хочуть, щоб ціла платформа робила багато речей.
Ананд Венугопал: Ми бачимо приклади обох, Робін. Деякі з перших десяти брендів, про які всі знають, збираються про це дуже стратегічно. Вони знають, що у них будуть різні випадки використання, тому вони оцінюють майданчики, які відповідають цій потребі, а це різноманітні випадки використання в декількох орендарях для розміщення на підприємстві. Є також окремі історії використання, які також починаються. У іпотечній компанії, над якою ми працюємо, є конкретний випадок моніторингу ділової активності, який ви не уявляєте як перший випадок використання, але це бізнес-рішення чи випадок використання, з яким вони придумали, а потім ми підключили точки до потокового передачі . Ми сказали: «Знаєте, що? Це чудовий випадок для потокової аналітики, і саме так ми можемо її реалізувати ". Ось так воно і починалося. Потім у цьому процесі вони отримують освіту і кажуть: "О, вау, якщо ми можемо це зробити, і якщо це загальна платформа, то ми можемо відокремити додаток, викласти їх у платформу і створити на цьому безліч різних додатків платформа ».
Робін Блор: Дез, у вас є запитання?
Ананд Венугопал: Dez, ймовірно, відключений.
Dez Blanchfield: Вибачення, німий. Я просто добре розмовляв. Дотримуючись оригінального спостереження за Робіном, ви абсолютно правильні. Я думаю, що зараз проблема полягає в тому, що підприємства мають екосистему та культурне та поведінкове середовище, де вільне програмне забезпечення з відкритим кодом - це те, що їм відомо, і вони здатні використовувати такі інструменти, як Firefox, як браузер, і він мав гідний термін експлуатації, поки він не стане стабільним і надійним. Але деякі з цих дуже великих платформ, які вони використовують, є фірмовими майновими платформами. Тож прийняття платформ із відкритим кодом - це не завжди те, що їм легко перейти в культурному чи емоційному плані. Я це бачив лише через прийняття невеликих програм, які були місцевими проектами, які просто грали з великими даними та аналітикою як основну концепцію. Я думаю, що одним із ключових завдань, я впевнений, що ви їх бачили зараз у всіх організаціях, є їхнє бажання отримати результат, але в той же час, коли одна їхня нога застрягла у старій банці, де вони могли просто придбати це у "Вставте великий бренд" Oracle, IBM та Microsoft. Ці нові та відомі бренди проходять через платформи Hadoop та навіть більше. Виходять більш захоплюючі бренди, завдяки яким є передові технології, такі як stream.
Які ти бесіди ви проходили або перерізали через це? Я знаю, що у нас сьогодні вранці масове відвідування, і одне, що я впевнений, на думці кожного це: «Як я прорізаю весь цей складний шар від борту до рівня управління, ой його занадто відкритий джерело і занадто кровоточить край? "Як проходять розмови, які ви ведете з клієнтами, і як ви прориваєтесь до того моменту, коли ви якось стримуєте ці типи страхів, щоб розглянути можливість подобатися StreamAnalytix?
Ананд Венугопал: Ми насправді вважаємо досить просто продати свою ціннісну пропозицію, оскільки клієнти, природно, рухаються до відкритого коду як кращого варіанту. Вони не просто відмовляються і говорять: «Гаразд, я зараз піду відкритим кодом». Вони насправді проходять дуже віддану оцінку основного продукту, скажімо, це IBM або типовий продукт, тому що у них є ці відносини продавців. Вони б не ставились до нас або до механізму відкритого коду проти цього продукту. Вони пройдуть через шість-вісім-дванадцять тижнів оцінки. Вони переконують себе в тому, що тут я бажаю певної міри продуктивності та стабільності, і тоді вони вирішують, кажучи: "О, ти знаєш що, я насправді можу це зробити".
Сьогодні, наприклад, у нас є головний telco першого рівня, який має потокову аналітику, що працює у виробництві поверх багатьох стеків, і вони оцінюють це проти іншого дуже-дуже великого відомого постачальника, і вони переконалися лише після того, як ми довели все продуктивність, стабільність і все це. Вони не сприймають це як належне. Вони виявили, що відкритий код є компетентним завдяки їхнім оцінкам, і вони розуміють, що, в гіршому випадку, "Можливо, є ті два випадки використання, які я, можливо, не можу зробити, але більшість випадків використання прискорення мого бізнесу сьогодні надзвичайно можливі з відкритим кодом стек ". І ми даємо можливість використовувати його. Тож саме тут є велике миле місце. Вони хотіли відкритого коду. Вони справді прагнуть вийти із ситуації, що замикається у постачальника, до якої вони звикли вже багато-багато років. Потім ми підходимо і кажемо: "Ви знаєте що, ми зробимо відкритий код набагато, набагато простішим і привітнішим для вас."
Dez Blanchfield: Я думаю, що інша проблема, яка виникає на підприємствах, полягає в тому, що вони приїжджають у традиційну діючу службу, вони часто є поколінням за деякими кровоточивими краями захоплюючих речей, про які ми говоримо тут, і я не маю на увазі це як негативний мінус. Просто реальність полягає в тому, що у них є покоління та шлях, щоб випустити те, що вони вважають стабільними платформами, пройти цикли та тестування та документацію, а також документацію та маркетинг та продажі. Якщо у тому типі, яким ви займаєтесь, я думаю, що мені цікаво подумати - це те, що, переглядаючи деякі ваші останні випуски минулої ночі, роблячи якусь дослідницьку роботу, ви отримали цю суміш зараз, де ви отримали компетенція з точки зору передового консультування та впровадження, але ви також отримали стек, в який можете скористатися. Я думаю, що саме тут депутати збираються боротись деякий час. Ми багато таких бачили, як і я на ринку. Вони часто знаходяться в тому, що я називаю вузлами наздоганяння, тоді як з того, що ви нам говорите, коли ви ведете ці розмови, а ви впроваджуєте їх.
Чи можете ви навести кілька прикладів деяких прикордонних вертикалей, які ви бачили ухваленими? Наприклад, існує дійсно таке ніке середовище, як ракетна наука та розміщення супутників у космосі та збирання даних з Марса. На планеті це робить лише кілька людей. Але є великі вертикалі, такі як сфера охорони здоров'я, наприклад, у галузі повітроплавання, судноплавстві та логістиці, у виробництві та машинобудуванні. Наведемо кілька прикладів більшого та більш широкого сектору промисловості, до якого ви були так далеко, що бачили насправді добре усиновлення в?
Ананд Венугопал: Telco - великий приклад.
Я просто збираюся швидко виправити свої слайди. Чи можете ви побачити слайд тут, тематичне дослідження 4?
Це випадок великих даних телекомунікаційних пристроїв, що приймають телевізори, і робити з ними кілька речей. Вони дивляться, що реально роблять клієнти в режимі реального часу. Вони дивляться, де трапляються помилки в режимі реального часу в телеприймачах. Вони намагаються повідомити про центр дзвінків, якщо цей клієнт зателефонував зараз, інформація про кодове посилання з приставки цього клієнта, інформація про квитки на обслуговування швидко корелює, чи є у конкретної клієнтської телевізори проблеми чи не раніше замовник вимовляє слово. Кожна кабельна компанія, кожен великий телекомунікаційний центр намагається це зробити. Вони передають дані телевізорів, аналізують в режимі реального часу, роблять аналітику кампаній, щоб вони могли розміщувати свої оголошення. Існує величезний випадок використання.
Як я вже сказав, це іпотечна компанія, яка знову є загальною схемою, коли великі системи беруть участь у обробці даних. Дані, що надходять через систему А в систему В до системи С, і це регульовані підприємства, яким все має бути узгоджено.Часто системи синхронізуються одна з одною, одна система говорить: "Я обробляю сто кредитів загальною вартістю 10 мільйонів доларів". Система каже: "Ні, я обробляю 110 позик деяких інших інша кількість ". Вони повинні вирішити це дуже швидко, оскільки вони насправді обробляють одні й ті самі дані та роблять різні інтерпретації.
Незалежно від того, чи це кредитна картка, обробка позики, бізнес-процес, чи це іпотечний бізнес-процес чи щось інше, ми допомагаємо їм здійснювати кореляцію та звірку в режимі реального часу, щоб ці бізнес-процеси не синхронізувалися. Це ще один цікавий випадок використання. Є головний урядовий підрядник США, який дивиться на DNS-трафік для виявлення аномалії. Вони побудували офлайн-модель навчання, і вони роблять бал за цією моделлю на трафіку в режимі реального часу. Деякі з цих цікавих випадків використання. Є велика авіакомпанія, яка дивиться на черги безпеки, і вони намагаються надати вам таку інформацію, що: "Ей, це ваша ворота для вашого літака для вашого польоту. Сьогодні черга TSA складає приблизно 45 хвилин проти двох годин проти чогось іншого. "Ви отримуєте це оновлення заздалегідь. Вони все ще працюють над цим. Цікавий випадок використання IoT, але чудовий випадок потокової аналітики, спрямований на досвід клієнтів.
Ребекка Йозвяк: Це Ребекка. Поки ви переглядаєте випадки використання, виникає велике запитання члена аудиторії, який задається питанням: "Чи є ці приклади, чи ці ініціативи рухаються з аналітичної сторони інформаційних систем вдома чи чи більше вони рухаються з бізнес, який має на увазі конкретні питання чи потреби? "
Ананд Венугопал: Я думаю, що ми бачимо приблизно 60 відсотків або близько того, від 50 відсотків до 55 відсотків, в основному дуже ініціативні, захоплені технологічними ініціативами, які випадково знають, які, можливо, є досить кмітливими і розуміють певні бізнес-вимоги, і, ймовірно, у них є один спонсор, який вони визначили, але ці це технологічні команди, які готуються до натиску випадків використання бізнесу, а потім, коли вони нарощують потенціал, вони знають, що можуть це зробити, а потім переходять до бізнесу та агресивно продають це. У 30 відсотках до 40 відсотків випадків ми бачимо, що бізнес вже має конкретний випадок використання, який благає про те, щоб надати можливість поточної аналітики.
Ребекка Йозвяк: Що має сенс. У мене є ще одне трохи більш технічне запитання від учасника аудиторії. Йому цікаво, чи підтримують ці системи як структуровані, так і неструктуровані потоки даних, як осади потоків або пости в режимі реального часу, чи потрібно її спочатку фільтрувати?
Ананд Венугопал: Продукти та технології, про які ми говоримо, дуже швидко підтримують як структуровані, так і неструктуровані дані. Їх можна налаштувати. Усі дані мають якусь структуру, будь то XML або що-небудь взагалі. Існує якась структура з точки зору того, що є подача часової позначки. Можливо, є ще одна крапка, яку потрібно проаналізувати, щоб ви могли ввести синтаксичний аналіз у потік для розбору структур даних. Якщо вона структурована, то ми просто скажемо системі: «Гаразд, якщо є значення, розділені комами, і перше - рядок, друге - дата». Отже, ми можемо ввести цю розвідку інтелекту в шари верхнього екрану і легко обробляти як структуровані, так і неструктуровані дані.
Ребекка Йозвяк: У мене є ще одне запитання від аудиторії. Я знаю, ми трохи пробігли вершину години. Цей учасник хоче знати, схоже, що потокове додавання в реальному часі може розвивати як потребу, так і можливість інтеграції назад у системи транзакцій, наприклад, у системи запобігання шахрайству. У такому випадку, чи потрібно трансакціонувати системи транзакцій, щоб вони підходили до цього?
Ананд Венугопал: Це злиття, правда? Це злиття систем транзакцій. Вони іноді стають джерелом даних, де ми аналізуємо транзакції в режимі реального часу, і в багатьох випадках, коли, скажімо, є прикладний потік, і тут я намагаюся показати статичний сайт пошуку даних, а потім у нашому випадку, де якась потокова передача даних і ви шукаєте статичну базу даних, як HBase або RDBMS, щоб збагатити потокові дані та статичні дані разом, щоб прийняти рішення або аналітичну інформацію.
Є ще одна велика галузева тенденція, яку ми також спостерігаємо - конвергенція OLAP та OLTP - і саме тому у вас є бази даних на зразок Kudu та бази даних пам'яті, що підтримують одночасно транзакції та аналітичну обробку. Шар обробки потоку буде повністю в пам'яті, і ми розглянемо або взаємодіємо з деякими з цих транзакційних баз даних.
Ребекка Йозвяк: Змішана навантаження була однією з останніх перешкод для стрибків, я думаю. Дез, Робін, у вас двох є ще питання?
Dez Blanchfield: Я збираюся перейти до останнього питання і завершити це, якщо ви не проти. Перший виклик, з яким організації, з якими я маю справу протягом останнього десятиліття або настільки веде до цього захоплюючого виклику потокової аналітики, перше, що вони, як правило, ставлять на стіл, коли ми розпочали розмову навколо цього виклику, - це де робити ми отримуємо набір навичок? Як ми перекваліфікуємо набір навичок і як ми отримуємо цю здатність внутрішньо? Після того, як Імпульс заходить у руку, провести нас через подорож, а потім здійснити як перший перший крок, і це має багато сенсу робити.
Але для середньої та великої організації, які речі ви бачите в даний момент, щоб підготуватися до цього, створити цю здатність внутрішньо, отримати що-небудь із простого словника навколо нього і що вони можуть робити з організації навколо переходу до подібного роду та переобладнання наявного технічного персоналу з ІТ від генерального директора, щоб вони могли самі це запустити, коли ви створили та впровадили його? Просто дуже коротко, які виклики і як вони вирішують, клієнти, з якими ви стикаєтесь, типи проблем, які вони знайшли, і як вони проходять через вирішення цієї перекваліфікації та набуття досвіду та знань, щоб підготуватися до цього і бути в змозі обходитись оперативно?
Ананд Венугопал: Часто невеликий набір людей, які намагаються вийти і придбати платформу потокової аналітичної аналітики, вже досить розумний, оскільки вони знають Hadoop, вони вже здобули свої навички Hadoop MapReduce, і тому що вони тісно співпрацюють з постачальником дистрибуції Hadoop, вони або знайомі. Все отримує, наприклад, Кафка. Вони щось роблять з цим, і Storm, або Spark потоки знаходяться у їх домені з відкритим кодом. Безумовно, люди знайомі з цим або будують навички навколо нього. Але це починається з невеликого набору людей, які є достатньо кваліфікованими та досить розумними. Вони відвідують конференції. Вони навчаються, і вони задають розумні запитання постачальникам, а в деяких випадках вони навчаються у продавців. Коли продавці приходять і представляють себе на першій зустрічі, вони можуть не знати речі, але вони перечитують разом, а потім починають грати з ним.
Ця маленька група людей є ядром, а потім вона починає зростати, і всі тепер розуміють, що перший випадок використання бізнесу стає функціональним. Тут починається хвиля, і ми побачили на саміті Spark минулого тижня, де велике підприємство, як Capital One, було там і в повному складі. Вони вибирали Спарк. Вони говорили про це. Вони багато навчають своїх людей у Spark, оскільки вони сприяють цьому також у багатьох випадках як користувач. Те саме ми бачимо з багатьма, багатьма великими підприємствами. Це починається з декількох невеликих наборів дуже розумних людей, а потім починається хвиля загальної освіти, і люди знають, що колись старший віце-президент або один раз старший директор вирівняється, і вони хочуть зробити ставку на цю річ, і слово обходить і всі вони починають підбирати ці навички.
Dez Blanchfield: Я впевнений, що ви також фантастично проводите час створення цих чемпіонів.
Ананд Венугопал: Так. Ми багато навчаємо, працюючи з початковими чемпіонами, і ми проводимо тренінгові курси, і багато, багато для наших великих клієнтів ми повернулися назад і провели хвилі та хвилі тренувань, щоб привести багато користувачів у фазу основної роботи, особливо на сайті Hadoop MapReduce. Ми виявили, що у великій компанії з кредитних карт, яка є нашим замовником, ми поставили принаймні, можливо, п’ять-вісім різних навчальних програм. У нас також є безкоштовні спільноти всіх цих продуктів, включаючи нашу, пісочницю, яку люди можуть завантажувати, звикати і також навчати себе.
Dez Blanchfield: Це все, що я маю для тебе сьогодні вранці. Дуже дякую. Мені здається неймовірно цікавим переглядати типи моделей та використовувати кейси, які ви сьогодні отримали для нас. Дякую.
Ананд Венугопал: Чудово. Дуже дякую людям.
Ребекка Йозвяк: Дякуємо всім за приєднання до нас у цій трансляції Hot Technologies. Це було захоплююче почути від Дез Бланчфілд, доктора Робіна Блура та від компанії Impetus Technologies, Ананда Венугопала. Дякую присутнім. Дякую спікерам і дякую аудиторії. У нас є ще один Hot Technologies в наступному місяці, тому шукайте це. Ви завжди можете знайти наш вміст в архіві на сайті Insideanalysis.com. Ми також розміщуємо багато вмісту на SlideShare та кілька цікавих біт на YouTube.
Це все, шановні. Ще раз дякую і приємного дня. Бувай.