Співробітники компанії «Техопедія», 24 лютого 2016 року
Винос: Ведуча Ребекка Йозвяк обговорює поточну аналітику з провідними фахівцями галузі.
На даний момент ви не ввійшли в систему. Будь ласка, увійдіть або зареєструйтесь, щоб переглянути відео.
Ребекка Йозвяк: Пані та панове, привіт і ласкаво просимо до Hot Technologies 2016! Сьогоднішня назва - “Запрягати людей, які отримують цінність бізнесу від Streaming Analytics”. Це Ребекка Йозвяк. Я другий, хто командує ведучим трансляції, коли наш дорогий Ерік Кавана не може бути тут, тому приємно бачити стільки з вас сьогодні там.
Цей епізод трохи відрізняється від наших інших. Ми якось поговорили про те, що спекотно, і звичайно, цей рік - гарячий. Останні кілька років були гарячими. Завжди виходять нові речі. Сьогодні ми говоримо про потокову аналітику. Потокова аналітика сама по собі нова. Звичайно потокові, центральні дані, дані RFID, це не обов'язково нові. Але в контексті архітектури даних ми десятиліттями так зосереджувалися на даних у спокої. Бази даних, файлові системи, сховища даних - все це переважно для пакетної обробки. Але тепер із зміною створення цінності за допомогою потокової передачі даних, емоцій даних, деякі називають це живими потоками, вони справді потребують потокової архітектури, а не даних спокійних архітектур, до яких ми звикли, і до яких потрібно бути здатними обробка швидкого прийому, в режимі реального часу або майже в режимі реального часу. Він повинен вміти обслуговувати не лише Інтернет речей, але Інтернет всього.
Звичайно, в ідеалі було б непогано, щоб дві архітектури жили поруч, одна рука мила іншу, так би мовити. Незважаючи на те, що дані про давні дні, дані за тижні, дані про роки, як і раніше, звичайно мають значення, історичну аналітику, аналіз тенденцій, це дані, які реалізуються в даний час, і саме тому поточна аналітика стала такою важливою.
Я сьогодні про це більше говорю. У нас є наш науковець Дез Бланчфілд, який зателефонував з Австралії. Зараз для нього рано вранці. У нас є наш головний аналітик, доктор Робін Блер. До нас приєднується Ананд Венугопал, керівник продукту StreamAnalytix в Impetus Technologies. Вони дійсно зосереджені на потоковому аналітичному аспекті цього простору.
З цим я збираюся йти вперед і передавати його Дезу.
Дез Бланшфілд: Дякую. Мені потрібно захопити контроль над екраном тут і попсувати вперед.
Ребекка Йозвяк: Ось ви.
Дез Бланчфілд: Поки ми захоплюємо слайди, дозвольте мені просто висвітлити основну тему.
Я буду тримати його досить високим рівнем, і я триматиму його приблизно 10 хвилин. Це дуже велика тема. Я брав участь у заході, де ми провели два-три дні, заглиблюючись у деталі, що таке обробка потоків, та поточні рамки, які ми розробляємо, і що має робити аналітика в цих потоках великого обсягу.
Ми збираємось лише роз’яснити, що ми маємо на увазі, використовуючи поточну аналітику, а потім поглибимося, чи можна отримати ділову цінність, оскільки це справді те, що шукають компанії. Вони хочуть, щоб люди пояснили їм дуже швидко і стисло, де я можу отримати значення, застосувавши якусь форму аналітики до наших потокових даних?
Що таке потокова аналітика?
Потокова аналітика дає організаціям можливість отримувати цінність із даних про великі та високі швидкості, які вони отримують через бізнес у різних формах у русі. Суттєва відмінність тут полягає в тому, що у нас була довга історія розробки аналітики та об'єктивів та переглядів даних, які ми обробляємо в спокої десятиліттями з моменту винайдення мейнфрейму. Помітна зміна парадигми, яку ми спостерігали протягом останніх трьох-п’яти років у тому, що ми називаємо “веб-шкалою”, - це проникнення в потоки даних, що надходять до нас в режимі реального часу або майже в реальному часі, а не просто обробка та пошук співвідношення подій або запускає події, але виконуючи справді детальну, глибоку аналітику в цих потоках. Це суттєвий перехід до того, що ми робили до цього, або збирати дані, вводити їх у якесь сховище, традиційно великі бази даних зараз, великі рамки великих даних, такі як платформа Hadoop, і виконувати обробку пакетного режиму на цьому і отримувати якесь прозріння.
Ми дуже швидко робимо це дуже швидко і пробуємо багато важкого заліза, але ми все-таки дійсно фіксуємо дані, зберігаємо їх, а потім дивимось на них і отримуємо якусь інформацію та аналітику. Перехід до виконання такої аналітики під час передачі даних був дуже новою та захоплюючою сферою зростання для типів речей, що відбуваються навколо великих даних. Він вимагає зовсім іншого підходу, щоб просто захопити, зберігати та обробляти та виконувати аналітику.
Одним з ключових рушій для зміни та зосередження уваги на аналітиці в потоці є те, що ви можете отримати значну цінність для бізнесу, отримуючи цю інформацію швидше і легше, коли дані надходять до вас, оскільки інформація стає доступною для бізнесу. Ідея робити обробку в кінці дня вже не актуальна в певних галузях. Ми хочемо, щоб ми могли робити аналітику на льоту. На кінець дня ми вже знаємо, що сталося, як це сталося, а не доходити до кінця дня та виконувати цілодобову партійну роботу та отримувати цю інформацію.
Потокова аналітика полягає в тому, щоб потрапити прямо в цей потік, тоді як потоки даних, як правило, є декількома потоками з дуже великими обсягами даних і даних, що надходять до нас в рух дуже, дуже швидко, і отримують розуміння або аналітику цих потоків, оскільки вони приходять до нас. щоб дозволити цьому виходити в спокої і виконувати аналітику на них.
Як я вже згадував, у нас десятиліття і десятиліття виконували те, що я називаю пакетною аналітикою. Я поставив тут дійсно класну картину. Це зображення джентльмена, що стоїть перед знущається комп’ютером, який було створено корпорацією RAND все життя тому, і саме так вони виглядали на комп'ютері в будинку. Цікавим є те, що навіть тоді вони мали цю концепцію всіх цих маленьких циферблатів, і ці циферблати представляли інформацію, що надходить з дому та обробляється в режимі реального часу і розповідає, що відбувається. Простий приклад - це набір барометричного тиску і температури, який ми можемо бачити, де ми бачимо, що відбувається в режимі реального часу. Але я думаю, що ще тоді, коли корпорація RAND зібрала цей маленький макет разом, вони насправді думали вже про обробку даних та проведення аналітики на ній, як це надходить у форматі потоку. Я не зовсім впевнений, чому вони поставили кермо на комп’ютер, але це досить круто.
З часу створення принтера ми мали уявлення про забір даних та проведення пакетної аналітики на них. Як я вже говорив із великим зрушенням зараз, і ми це бачили з подобається гравцям в Інтернеті, про яких ми всі знаємо, що це всі домашні бренди, такі як Twitter, Facebook та LinkedIn, та інтерактивна поведінка, яку ми маємо з тими соціальними платформи вимагають не просто захоплення, зберігання та обробки в пакетному режимі, але вони фактично фіксують та залучають аналітику на льоту з потоків даних, що надходять. Коли я щось щебечу, їм не тільки потрібно захопити та зберігати та робити щось пізніше, але й потрібно мати можливість негайно повернути його в мій потік і поділитися цим з іншими людьми, які йдуть за мною. Це модель пакетної обробки.
Чому ми пішли б по цьому маршруту? Чому організації вкладають час, зусилля та гроші, навіть розглядаючи завдання, спрямований на шлях поточної аналітики? Організації мають таке величезне бажання досягти підвищення продуктивності над своїми конкурентами у галузях, в яких вони перебувають, і збільшення продуктивності може бути швидко впроваджене за допомогою простої потокової аналітики, і це може початися з простого відстеження даних у реальному часі, що ми вже є знайомий з. У мене там невеликий скріншот Google Analytics. Це, мабуть, один із перших випадків, коли ми справді отримали практичну аналітику споживачів. Отже, коли люди відвідували ваш веб-сайт, і ви отримуєте кількість підрахунків звернень, за допомогою крихітного фрагмента JavaScript у нижній частині вашої веб-сторінки в HTML, вбудованому у ваш веб-сайт, ці маленькі коди робляться в реальному часі назад до Google, і вони були виконуючи аналітику на потоках даних, що надходять зі кожної сторінки на вашому веб-сайті, кожного об’єкта на вашому веб-сайті в режимі реального часу, і вони надсилають його вам на цій справді милій маленькій веб-сторінці на інформаційній панелі графіка в режимі реального часу, милі маленькі гістограми та лінійний графік, що показує X кількість людей, які історично потрапляють на вашу сторінку, але ось скільки їх зараз.
Як ви можете бачити на цьому скріншоті, він говорить про 25 зараз. Ось 25 людей зараз на той момент, коли цей знімок екрана був на цій сторінці. Це перший реальний шанс, який ми грали на інструменті аналізу споживачів. Я думаю, що багато людей насправді це зрозуміли. Вони просто зрозуміли силу знання того, що відбувається, і як вони можуть на це реагувати. Коли ми думаємо про масштаби авіоніки, літаки літають навколо, то лише в США 18700 внутрішніх рейсів на день. Я прочитав доповідь деякий час тому - це було близько шести-семи років тому - що кількість даних, що їх виробляли ці літаки, становила від 200 до 300 мегабайт у старій технічній моделі. У сучасних конструкціях літальних апаратів ці літаки виробляють близько 500 гігабайт даних або близько половини терабайт даних за один політ.
Коли ви дуже швидко зробите математику з верхньої частини голови, то 18 700 внутрішніх рейсів кожні 24 години тільки в повітряному просторі США, якщо всі сучасні літаки виробляють близько половини терабайт, це 43 до 44 петабайт даних, що надходять через це відбувається, поки літаки перебувають у повітрі. Це відбувається, коли вони приземляються, і вони роблять звалища даних. Ось тоді вони заходять у цех і мають повний дамп із інженерних команд, щоб подивитися на те, що відбувається в підшипниках, колесах та всередині двигунів. Деякі з цих даних мають бути оброблені в режимі реального часу, щоб вони могли приймати рішення, якщо виникає реальна проблема, поки літак знаходився в повітрі або поки він знаходиться на землі. Ви просто не можете цього зробити в пакетному режимі. В інших галузях, які ми бачимо там, серед фінансів, охорони здоров'я, виробництва та інженерії, вони також розглядають, як вони можуть отримати це нове розуміння того, що відбувається в режимі реального часу, на відміну від того, що просто зберігається в базах даних на термін.
Існує також така концепція поводження з даними, як те, що я називаю швидкопсувним товаром або швидкопсувним товаром - багато даних втрачають значення з часом. Це все частіше трапляється з додатками для мобільності та інструментами соціальних медіа, тому що те, що люди говорять, і що зараз в тренді - це те, на що ти хочеш відповісти. Коли ви думаєте про інші частини нашого життя з логістикою та доставкою їжі навколо, ми розуміємо поняття швидкопсувного товару в цьому сенсі. Але подумайте про дані, які проходять через вашу організацію, і про значення, яке вона має. Якщо хтось із вами зараз займається деяким бізнесом і ви можете спілкуватися з ними в режимі реального часу, ви не хочете чекати години, щоб дані могли бути захоплені і поміщені в систему на зразок Hadoop, а потім натисніть цю кнопку, не зможете зараз з цим впоратися, і ви хочете мати можливість це зробити на вимогу клієнта негайно. Зараз ви побачите, що зараз багато з'явиться, де люди говорять про наявність потоку даних у режимі реального часу, який може надати вам персоналізацію, і про налаштування персоналізації в системі, яку ви використовуєте, під свій індивідуальний досвід. Тому, наприклад, коли ви потрапляєте на такий інструмент, як інструмент пошуку Google, якщо я запитую, а ви виконуєте той самий запит, незмінно, ми не отримуємо абсолютно однакові дані. Ми отримуємо по суті те, що я називаю досвідом знаменитостей. Мене лікують одноразово. Я отримую власну особисту версію того, що відбувається в цих системах на основі профілів та даних, які вони зібрали на мене, і я мав змогу робити аналітику в режимі реального часу в потоці.
Ця ідея того, що дані є швидкопсувним товаром, є справжньою справою, і значення даних, що зменшуються з часом, - це те, з чим ми маємо мати справу сьогодні. Це не вчорашня річ. Мені подобається ця картина ведмедя, що хапає лосося, вистрибуючи з річки, тому що він дійсно малює саме те, що я бачу в потоковій аналітиці. Це ця масивна річка даних, що надходить до нас, вогонь, якщо хочете, а ведмідь сидить посеред річки. Він збирається виконувати аналітику в реальному часі щодо того, що відбувається навколо нього, таким чином, щоб він фактично міг розробити його здатність захоплювати рибу в повітрі. Це не так, як просто зануритися в потік і схопити його. Ця річ стрибає в повітрі, і їй потрібно бути в потрібному місці в потрібний час, щоб зловити цю рибу. Інакше він не снідає і не обідає.
Організація хоче зробити те ж саме зі своїми даними. Вони хочуть отримати цінність із того, що зараз перебуває в русі величезних обсягів даних. Вони хочуть провести аналітику цих даних і даних про високу швидкість, тому це не просто кількість даних, яка надходить до нас, але це швидкість, з якою вона надходить від цього. Наприклад, у безпеці - це всі ваші маршрутизатори, комутатори, сервери, брандмауери та всі події, що надходять із цих і десятків тисяч, якщо не сотень тисяч пристроїв, у деяких випадках - швидкопсувні дані. Коли ми думаємо про це в Інтернеті речей та промисловому Інтернеті, ми говоримо про мільйони, якщо не мільярди датчиків, і коли дані надходять через які проводить аналітику, ми зараз дивимось на складну обробку подій з порядком та швидкістю, якого ми ще ніколи не бачили, і нам сьогодні доводиться займатися цим. Нам потрібно будувати інструменти та системи навколо цього. Це справжній виклик для організацій, оскільки, з одного боку, у нас є дуже великі бренди, які роблять «Зробіть сам», випікайте їх самостійно, коли у них є можливість зробити це, набір навичок та інженерія. Але для пересічної організації це не так. У них немає наборів навичок. Вони не мають можливостей, ані часу, ані навіть грошей, щоб вкласти їх у з'ясування. Усі вони спрямовані на цю концепцію прийняття рішень у реальному часі.
Використовуйте випадки, які я натрапив, і вони знаходяться в кожному широкому спектрі кожного сектора, який ви можете собі уявити, люди сидять і звертають увагу і говорять: як ми можемо застосувати певну аналітику до наших даних потоку? Ми говоримо про веб-сервіси в масштабному масштабі. Існують традиційні платформи соціальних медіа та електронна пошта та роздрібний продаж в Інтернеті - наприклад, програми. Всі вони намагаються надати нам цей досвід знаменитості в реальному часі. Але коли ми переходимо до більшої кількості технологічних служб стеки, телефонних послуг, голосу та відео, я бачу людей, які гуляють навколо, роблячи FaceTime по телефонах. Це просто вибухає. Мені здається, що люди тримають телефон перед собою і розмовляють з відеопотоком друга, на відміну від того, щоб більше тримати його за вухо. Але вони знають, що можуть це зробити, і вони пристосувались і їм сподобався цей досвід. Розвиток цих додатків і платформ, які їх постачають, повинні виконувати аналітику в реальному часі на цьому трафіку та на профілях трафіку, щоб вони могли робити прості речі, такі як ідеально маршрутизувати це відео, щоб якість голосу в Відео, яке ви отримуєте, є адекватним, щоб отримати хороший досвід. Ви не можете пакетно обробляти такі дані. Це не зробить відеопотік у режимі реального часу функціональним сервісом.
У фінансових операціях виникає проблема управління. Не годиться дійти до кінця дня і дізнатися, що ти порушив закон, переміщуючи приватні дані по всьому місту. В Австралії у нас є дуже цікавий виклик, коли переміщення даних, пов’язаних з конфіденційністю, за межами берега - це ні-ні. Ви не можете брати мій PID, мої особисті особисті ідентифікаційні дані за кордон. В Австралії існують закони, які запобігають цьому. Зокрема, надаючи фінансові послуги, державні служби та агенції, вони повинні робити аналітику в реальному часі на своїх потоках даних та інструкцій зі мною, щоб переконатися, що те, що вони мені надають, не залишає берегів. Усі речі повинні залишатися на місцях. Вони повинні це зробити в режимі реального часу. Вони не можуть порушити закон і просити прощення пізніше. Виявлення шахрайства - це досить очевидний варіант, про який ми чуємо при операціях з кредитними картками. Але оскільки види трансакцій, які ми робимо у фінансових послугах, змінюються дуже, дуже швидко, є певні речі, які PayPal роблять першими зараз, щоб виявити шахрайство в режимі реального часу, коли гроші не переходять від однієї речі до іншої, але це фінансова операція між системами. Платформи для торгів на Ebay та виявлення шахрайства повинні здійснюватися в реальному часі в потоковому офісі.
Зараз існує тенденція до здійснення видобутку та перетворення навантажувальної активності в потоках, тому ми не хочемо фіксувати нічого, що йде в потік. Ми реально цього не можемо зробити. Люди дізналися, що дані люблять розбиватися дуже швидко, якщо ми все захопимо. Хитрість тепер полягає в тому, щоб виконувати аналітику на цих потоках і робити ETL на ній і просто фіксувати те, що вам потрібно, потенційно метадані, а потім задіяти прогностичну аналітику, де ми можемо реально потім розповісти, що відбудеться трохи далі вниз по шляхах того, що ми Щойно бачили у потоці на основі аналітики, яку ми виконували на цьому.
Постачальники енерго- та комунальних послуг відчувають таке масове прагнення споживачів до ціноутворення попиту. Я можу вирішити, що хочу придбати зелену енергію в один конкретний час доби, тому що я просто один вдома і не використовую багато пристроїв. Але якщо у мене буде вечеря, я, можливо, захочу ввімкнути всі свої пристрої, і я не хочу купувати дешеву електроенергію і чекати її доставки, але готовий заплатити більше витрат, щоб отримати цю потужність. Таке ціноутворення попиту, особливо на комунальні та енергетичні простори, вже відбулося. Наприклад, Uber - це класичний приклад того, що ви можете робити щодня, і все це залежить від ціноутворення попиту. Є кілька класичних прикладів того, що в Австралії люди отримують вартість проїзду в 10 000 доларів через велику потребу в новорічну ніч. Я впевнений, що вони вирішили це питання, але поточну аналітику виконували в режимі реального часу, перебуваючи в машині, розповідаючи, скільки я повинен заплатити.
Інтернет речей та потоки датчиків - ми лише подряпали поверхню, і ми справді просто провели основну розмову з цього питання, але ми побачимо цікавий зрух у тому, як технологія справляється з цим, тому що, коли ти говориш не майже тисячі чи десятки тисяч, але сотні тисяч і, можливо, мільярди пристроїв, що передаються вам, майже жоден з технологічних стеків, які ми зараз отримали, не розроблений з цим.
Є кілька дійсно гарячих тем, які ми побачимо навколо, як безпека та кібер-ризик. Вони є для нас дуже реальними викликами. В Інтернеті є дійсно акуратний інструмент під назвою "Північ", де ви можете сидіти і дивитися на веб-сторінці різні кібератаки, що відбуваються в режимі реального часу. Дивлячись на це, ти думаєш, «о, це приємна маленька веб-сторінка», але приблизно через п’ять хвилин там ти розумієш об’єм даних, які система робить аналітикою на всіх різних потоках усіх різних пристроїв у всьому світі. які подаються в них. Це починає заплутати розум того, як вони виконують це на краю запису по суті, і надає вам той простий маленький екран, який підкаже вам, на що або на щось інше нападає на нього в режимі реального часу та які типи атак. Але це дійсно акуратний маленький спосіб просто отримати гарний смак того, що аналітика потоку потенційно може зробити для вас у режимі реального часу, просто переглянувши цю сторінку та зрозумівши лише об’єм та завдання взяти потоки, обробляти аналітичні запити на їх і представляючи це в режимі реального часу.
Я думаю, що розмова, яку я маю на решті сесії, збирається вирішити всі ці типи речей з одним цікавим видом, з моєї точки зору, і це є завданням "Зроби сам". класичні єдинороги, які здатні дозволити собі будувати такі речі. У них є мільярди доларів для побудови цих інженерних команд та для побудови їх центрів обробки даних. Але 99, 9% організацій, які хочуть досягти цінності у своєму бізнесі потокової аналітики, їм потрібно отримати послугу, що не є звичайною. Їм потрібно купувати товар поза коробкою, і вони, як правило, потребують певної консалтингової послуги та професійної послуги, яка допоможе їм реалізувати її, і вони отримують цю цінність у бізнесі та продають її бізнесу як робоче рішення.
З цим я повернуся до вас, Ребекка, тому що я вважаю, що саме зараз ми розкриємо це детально.
Ребекка Йозвяк: Відмінно. Дуже дякую, Дез. Це чудова презентація.
Тепер я передаю м'яч Робіну. Відняти її.
Робін Блор: Гаразд. Через те, що Дез пішов на обробку струмкових струмків потоків, мені, здавалося, не було сенсу знову покривати це. Тож я просто займусь абсолютно стратегічним поглядом. Дивлячись майже з дуже високого рівня на те, що відбувається в пеклі, і позиціонувати його, тому що я думаю, що це може допомогти людям, особливо нам людям, які раніше не перебувають у таборах, що переробляють потоки на великих глибинах.
Обробка потоків тривала вже давно. Ми називали це CEP. До цього були системи в режимі реального часу. Оригінальні системи управління процесами насправді обробляли потоки інформації - звичайно, нічого не йшло так далеко, як зараз. Ця графіка, яку ви бачите на слайді тут; це фактично вказує на багато речей, але це вказує на вище та поза будь-чим іншим - на те, що тут існує спектр затримок, які з’являються в різних кольорах. Що насправді сталося з часу винайдення обчислювальних чи комерційних обчислень, які надійшли приблизно в 1960 році, - це все стало все швидше і швидше. Раніше ми могли залежати від того, як це насправді виходило, якщо тобі подобається хвилями, адже це так виглядає. Це фактично залежить від цього. Тому що все це рухалося законом Мура і закон Мура дав би нам коефіцієнт швидкості приблизно в десять разів протягом періоду близько шести років. Тоді, як насправді ми дійшли приблизно до 2013 року, це все зламалось, і ми раптом почали прискорюватися зі швидкістю, яку ми ніколи не бували, що дивно безпрецедентно. Ми отримували коефіцієнт приблизно десять у плані збільшення швидкості, а отже, скорочення затримки приблизно кожні шість років. За шість років приблизно з 2010 року ми отримали кратний принаймні тисячу. Три порядки, а не один.
Ось що відбувається, і тому галузь так чи інакше, здається, рухається з фантастичною швидкістю - адже це так. Щойно переглядаючи значення цієї графіки, часи відгуку насправді є в алгоритмічному масштабі вниз по вертикальній осі. Реальний час - швидкість роботи за комп’ютером, швидше, ніж люди. Інтерактивні часи помаранчеві. Саме тоді, коли ви взаємодієте з комп’ютером, саме там вам дуже потрібно від десятої до приблизно однієї секунди затримки. Вище є транзакція, де ми насправді думаємо про те, що ти робиш у комп’ютері, але якщо це вимкнеться приблизно за п’ятнадцять секунд, це стає нестерпним. Люди насправді просто не чекатимуть комп’ютера. Все робилося партійно. Багато речей, які були зроблені партією, зараз спускаються прямо в транзакційний простір, прямо в інтерактивний простір або навіть у простір реального часу. Якщо раніше хвилеподібний з дуже невеликими обсягами даних ми могли б зробити щось із цього, то тепер ми можемо зробити з дуже великими обсягами даних, використовуючи надзвичайно масштабоване середовище.
Таким чином, все це говорить, що це дійсно час транзакцій та інтерактивних людей. Надзвичайно багато того, що зараз робиться з потоками, - це інформувати людей про речі. Деякі з них проходять швидше, ніж це, і це добре інформує речі, так що це в реальному часі. Тоді ми беремо ліцензію просто кинутись, як камінь, що робить миттєву аналітику здійсненною і, до речі, цілком доступною. Справа не в тому, що швидкість знизилася, а вершина також просто впала. Мабуть, найбільший вплив у цьому серед усіх різних застосувань ви можете виконати з усією цією прогнозною аналітикою. Я розповім, чому через хвилину.
Це просто магазин обладнання. Ви отримали паралельне програмне забезпечення. Ми говоримо про 2004 рік. Масштабна архітектура, багатоядерні чіпи, збільшення пам’яті, настроюваний процесор. Тепер SSD накопичуються набагато швидше, ніж спінінг. Ви можете дуже сильно розпрощатися з диском на прощання. SSD також є в декількох ядрах, тому знову швидше і швидше. Незабаром, щоб з’явитися, ми отримали меморістор від HP. Ми отримали 3D XPoint від Intel та Micron. Обіцянка цих полягає в тому, що це змусить все це все швидше і швидше. Коли ви насправді думаєте про дві нові технології пам’яті, обидві з яких зроблять цілий фундаментальний невеликий шматок, окрема плата піде швидше, ми навіть не бачили її закінчення.
Технологія потоків, що є наступним повідомленням насправді, залишається тут. Тут має бути нова архітектура. Я маю на увазі, що Дез щось про це згадував у кількох пунктах у своїй презентації. Десятиліттями ми розглядали архітектуру як поєднання наборів даних і даних. Ми прагнули обробляти купи, і ми прагнули передавати дані між купами. Зараз ми в основному рухаємось до того, що ми називаємо архітектурою даних Lambda, яка поєднує обробку потоків даних із набором даних. Коли ви фактично обробляєте потік подій, що надходять проти історичних даних, як потік даних або купа даних, це я маю на увазі під архітектурою Lambda. Це в зародковому стані. Це лише частина картини. Якщо ви вважаєте щось таке складне, як Інтернет усього, про що також згадував Dez, ви насправді зрозумієте, що існують всілякі проблеми з розташуванням даних - рішення щодо того, що слід обробити в потоці.
Я дійсно говорю тут, що коли ми обробляли пакетно, ми фактично обробляли потоки. Ми просто не могли це зробити один за одним. Ми просто чекаємо, поки з’явиться велика купа речей, а потім обробляємо все це відразу. Ми переходимо до ситуації, коли насправді ми можемо обробляти речі в потоці. Якщо ми можемо обробити матеріали в потоці, то масиви даних, які ми маємо, стануть статичними даними, на які нам потрібно посилатися, щоб обробити дані в потоці.
Це приводить нас до цієї конкретної речі. Про це я вже згадував у деяких презентаціях з біологічною аналогією. Те, про що я хотів би, щоб ви подумали - це зараз ми люди. У нас є три різні мережі для прогнозування в режимі реального часу. Їх називають соматичними, вегетативними та ентеричними. Ентерик - це ваш шлунок. Вегетативна нервова система доглядає за бійкою та польотами. Він насправді доглядає за швидкими реакціями на навколишнє середовище. Соматичне, яке доглядає за переміщенням тіла. Це системи в режимі реального часу. Цікаве про це - або я думаю, якесь цікаве - чимало воно є більш передбачувальним, ніж ви могли б собі уявити. Це так, ніби ви насправді дивитесь на екран приблизно в 18 дюймах від свого обличчя. Все, що ви можете чітко бачити, все, що ваше тіло здатне чітко бачити, насправді - це прямокутник 8 × 10. Все, що знаходиться поза цим, насправді розмито, що стосується вашого тіла, але ваш розум фактично заповнює прогалини і робить його не розмитим. Ви зовсім не бачите розмиття. Ви це чітко бачите. Ваш розум насправді робить метод прогнозування потоку даних для того, щоб ви бачили цю чіткість. Це щось цікаве, але ви можете насправді подивитися на те, як функціонує нервова система, і на те, як нам вдається обійти і поводити себе розумно - принаймні, деякі з нас - розумно розумно і не натрапляючи на речі весь час.
Все це зроблено серією шкали нейронної аналітики всередині. Що відбудеться, це те, що в організаціях відбуватиметься така ж річ і збирається будувати такий самий предмет, і це буде обробка потоків, включаючи внутрішні потоки організації - речі, що відбуваються всередині це, речі, що відбуваються поза нею, миттєві відповіді, які насправді мають бути прийняті, - це, звичайно, живлення людини для прийняття рішень, для того, щоб усе це відбулося. Ось куди ми їдемо, наскільки я бачу.
Однією з речей, що є наслідком цього, є те, що рівень потокової програми йде добре. Там буде набагато більше, ніж ми бачимо зараз. Зараз ми збираємо низько вищий плід робити те, що очевидно.
Так що все-таки ось такий висновок. Потокова аналітика колись є нішею, але вона стає мейнстрімом, і незабаром вона буде прийнята загалом.
З цим я поверну його Ребекці.
Ребекка Йозв'як: Дуже дякую, Робін. Чудова презентація, як завжди.
Ананд, ти вже поруч. Підлога ваша.
Ананд Венугопал: Фантастичний. Дякую.
Мене звуть Ананд Венугопал, і я керівник продукту StreamAnalytix. Це продукт, який пропонують компанії Impetus Technologies з Лос-Гатоса, Каліфорнія.
Імпут насправді мав велику історію, коли був великим постачальником даних для великих підприємств. Таким чином, ми фактично провели ряд реалізацій потокової аналітики в якості сервісної компанії і ми дізналися багато уроків. Ми також здійснили перехід до того, щоб стати продуктовою компанією та компанією, орієнтованою на рішення, протягом останніх кількох років, і потокова аналітика очолює завдання перетворити Impetus в компанію, що значною мірою керується продуктами. Є кілька важливих, дуже-дуже ключових активів, які Impetus очистився завдяки нашому впливу на підприємства, і StreamAnalytix є одним із них.
Ми 20 років в бізнесі, і це чудовий набір продуктів і послуг, що робить нас величезною перевагою. І StreamAnalytix народився з усіх уроків, отриманих з наших перших п’яти чи шести реалізацій потоку.
Я торкнуся кількох речей, але аналітики, Дез і Робін, зробили фантастичну роботу з висвітлення загального простору, тому я буду пропускати багато контенту, який перекривається. Я, мабуть, швидко поїду. Ми бачимо, окрім справжніх потокових випадків, що використовують безліч просто прискорених пакетів, де на підприємствах є буквально дуже, дуже важливі пакетні процеси. Як бачите, весь цей цикл зондування події та аналізу та дії на ній фактично може зайняти тижні на великих підприємствах, і всі вони намагаються скоротити його на хвилини, а іноді і на секунди та мілісекунди. Тож будь-який швидший, ніж усі ці пакетні процеси, є кандидатами на придбання бізнесу, і це дуже добре, що значення даних різко зменшується з віком, тому чим більше значення є в початковій частині за секунди, що це щойно відбулося. В ідеалі, якщо ви могли передбачити, що буде, це найвище значення. Однак це залежить від точності. Наступне найвище значення - це коли він знаходиться саме там, коли це відбувається, ви можете проаналізувати його та відповісти. Звичайно, значення різко зменшується після цього, головного обмежувального BI, в якому ми знаходимося.
Це цікаво. Ви можете очікувати різко наукової відповіді на те, чому потокова аналітика. У багатьох випадках ми бачимо це тому, що зараз це можливо і тому, що всі знають, що партія стара, партія нудна, а партія не крута. Є достатня кількість освіти, яку зараз мали всі, про те, що можлива трансляція, і всі мають Hadoop зараз. Тепер у дистрибутивах Hadoop вбудована технологія потокової передачі, будь то Storm або Spark streaming та звичайно черги повідомлень, як-от 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. Напевно, чапля ще не є відкритим кодом. Я не впевнений, чи це так, з Twitter. Потім ці потокові двигуни призводять до або підтримують компонент аналітичного додатка для налаштування, такий як комплексна обробка подій, машинне навчання, прогнозована аналітика, модуль оповіщення, потоковий 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 Blanchfield: Вибачення, німий. Я просто добре розмовляв сам. Тільки слідуючи за оригінальним спостереженням за Робіном, ви абсолютно правильні. Я думаю, що зараз проблема полягає в тому, що підприємства мають екосистему та культурне та поведінкове середовище, де вільне програмне забезпечення з відкритим кодом - це те, що їм відомо, і вони здатні використовувати такі інструменти, як Firefox, як браузер, і він мав гідний термін експлуатації, поки він не стане стабільним і надійним. Але деякі з цих дуже великих платформ, які вони використовують, є фірмовими майновими платформами. Тож прийняття платформ із відкритим кодом - це не завжди те, що їм легко перейти в культурному чи емоційному плані. Я бачив це лише через прийняття невеликих програм, які були місцевими проектами, щоб просто грати з великими даними та аналітикою як основну концепцію. Я думаю, що одним із ключових завдань, я впевнений, що ви їх бачили зараз у всіх організаціях, є їхнє бажання отримати результат, але в той же час, коли одна їхня нога застрягла у старій банці, де вони могли просто придбати це у "Вставте великий бренд" Oracle, IBM та Microsoft. Ці нові та відомі бренди проходять через платформи Hadoop та навіть більше. Виходять більш захоплюючі бренди, завдяки яким є передові технології, такі як stream.
Які ти бесіди проходили та перебирали через це? Я знаю, що у нас сьогодні вранці масово відвідують, і одне, що я впевнений, на думці кожного це: «Як я прорізаю весь цей складний шар від борту до рівня управління, о, це занадто відкритий код і занадто кровоточить край? "Як проходять розмови, які ви ведете з клієнтами, і як ви прориваєтесь до того моменту, коли ви якось стримуєте ці види страхів, щоб розглянути можливість подобатися StreamAnalytix?
Ананд Венугопал: Ми насправді вважаємо досить просто продати свою ціннісну пропозицію, оскільки клієнти, природно, рухаються до відкритого коду як кращого варіанту. Вони не просто відмовляються і говорять: «Гаразд, я зараз піду відкритим кодом». Вони насправді проходять дуже віддану оцінку основного продукту, скажімо, це IBM або типовий продукт, тому що у них є ці відносини продавців. Вони б не ставились до нас або до відкритого коду з цим продуктом. Вони пройдуть через шість-вісім-дванадцять тижнів оцінки. Вони переконують себе в тому, що тут я бажаю певної міри продуктивності та стабільності, і тоді вони вирішують, кажучи: "О, ти знаєш що, я насправді можу це зробити".
Сьогодні, наприклад, у нас є головний telco першого рівня, який має потокову аналітику, що працює у виробництві поверх багатьох стеків, і вони оцінюють це проти іншого дуже-дуже великого відомого постачальника, і вони переконалися лише після того, як ми довели все продуктивність, стабільність і все це. Вони не сприймають це як належне. Вони виявили, що відкритий код є компетентним завдяки їхнім оцінкам, і вони розуміють, що, в гіршому випадку, "Можливо, є ті два випадки використання, які я, можливо, не можу зробити, але більшість випадків використання прискорення мого бізнесу сьогодні надзвичайно можливі з відкритим кодом стек ". І ми даємо можливість використовувати його. Отже, це велике солодке місце саме там. Вони хотіли відкритого коду. Вони справді прагнуть вийти із ситуації, що замикається у постачальника, до якої вони звикли вже багато-багато років. Потім ми приїжджаємо і кажемо: "Ви знаєте що, ми зробимо відкритий код набагато, набагато простішим і привітнішим для вас."
Дез Бланчфілд: Я думаю, що інша проблема, яку виявляють підприємства, полягає в тому, що вони приносять традиційну владу, вони часто є поколінням за деякими кровоточивими краями захоплюючих речей, про які ми говоримо тут, і я не маю на увазі, що це негативний незначний. Просто реальність полягає в тому, що у них є покоління і подорож, щоб випустити те, що вони вважають стабільними платформами для проходження, старі школи та інтеграцію циклів інтеграції та UATN, маркетингу та продажів. Якщо у тому типі, яким ви займаєтесь, я думаю, що мені цікаво подумати - це те, що, переглядаючи деякі ваші останні випуски минулої ночі, роблячи якусь дослідницьку роботу, ви отримали цю суміш зараз, де ви отримали компетенція з точки зору передового консультування та впровадження, але ви також отримали стек, в який можете скористатися. Я думаю, що саме тут депутати збираються боротись деякий час. Ми бачили багато таких, як я, на ринку. Вони часто знаходяться в тому, що я називаю вузлами наздоганяння, тоді як з того, що ви нам говорите, коли ви ведете ці розмови, і ви впроваджуєте їх.
Чи можете ви навести кілька прикладів деяких прикордонних вертикалей, які ви бачили усиновленням? Наприклад, існує дійсно таке ніке середовище, як ракетна наука та розміщення супутників у космосі та збирання даних з Марса. На планеті це робить лише кілька людей. Але є великі вертикалі, такі як сфера охорони здоров'я, наприклад, у галузі повітроплавання, судноплавстві та логістиці, у виробництві та машинобудуванні. Наведемо кілька прикладів більшого та більш широкого сектору промисловості, до якого ви були так далеко, що бачили насправді добре усиновлення в?
Ананд Венугопал: Telco - великий приклад.
Я просто збираюся швидко виправити свої слайди. Чи можете ви побачити слайд тут, тематичне дослідження 4?
Це випадок великих даних телекомунікаційних пристроїв, що приймають телевізори, і робити з ними кілька речей. Вони дивляться, що реально роблять клієнти в режимі реального часу. Вони дивляться, де трапляються помилки в режимі реального часу в телеприймачах. Вони намагаються повідомити про центр дзвінків, якщо цей клієнт зателефонував зараз, інформація про кодове посилання з приставки цього клієнта, інформація про квитки на обслуговування швидко корелює, чи є у конкретної клієнтської телевізори проблеми чи не раніше замовник вимовляє слово. Кожна кабельна компанія, кожен великий телекомунікаційний центр намагається це зробити. Вони передають дані телевізорів, аналізують в режимі реального часу, роблять аналітику кампаній, щоб вони могли розміщувати свої оголошення. Існує величезний випадок використання.
Як я вже говорив, є ця іпотечна компанія, яка знову є загальною схемою, коли великі системи беруть участь у обробці даних. Дані, що надходять через систему А в систему В до системи С, і це регульовані підприємства, яким все має бути узгоджено. Часто системи синхронізуються одна з одною, одна система говорить: "Я обробляю сто кредитів загальною вартістю 10 мільйонів доларів". Система каже: "Ні, я обробляю 110 позик деяких інших інша кількість ". Вони повинні вирішити це дуже швидко, оскільки вони насправді обробляють одні й ті самі дані та роблять різні інтерпретації.
Будь то кредитна картка, обробка позики, бізнес-процес, чи це іпотечний бізнес-процес чи щось інше, ми допомагаємо їм здійснювати кореляцію та звірку в режимі реального часу, щоб ці бізнес-процеси не синхронізувалися. Це ще один цікавий випадок використання. Є головний урядовий підрядник США, який дивиться на DNS-трафік для виявлення аномалії. Вони побудували офлайн-модель навчання, і вони роблять бал за цією моделлю на трафіку в режимі реального часу. Деякі з цих цікавих випадків використання. Є велика авіакомпанія, яка дивиться на черги безпеки, і вони намагаються надати вам таку інформацію, що: "Ей, це ваша брама для вашого літака для вашого польоту. Сьогодні черга TSA складає приблизно 45 хвилин проти двох годин проти чогось іншого. "Ви отримуєте це оновлення заздалегідь. Вони все ще працюють над цим. Цікавий випадок використання IoT, але чудовий випадок потокової аналітики, спрямований на досвід клієнтів.
Ребекка Йозвяк: Це Ребекка. Поки ви переглядаєте випадки використання, виникає велике запитання члена аудиторії, який задається питанням: "Чи є ці приклади, чи ці ініціативи рухаються з аналітичної сторони інформаційних систем вдома чи чи більше вони рухаються з бізнес, який має на увазі конкретні питання чи потреби? "
Ананд Венугопал: Я думаю, що ми бачимо приблизно 60 відсотків або близько того, 50 відсотків до 55 відсотків, в основному дуже ініціативні, захоплені технологічними ініціативами, які, як відомо, є досить кмітливими і розуміють певні вимоги бізнесу, і, ймовірно, у них є один спонсор, який вони Ідентифіковані, але це технологічні команди, що готуються до нападів випадків використання бізнесу, а потім, коли вони нарощують потенціал, вони знають, що можуть це зробити, а потім ведуть бізнес і агресивно продають це. У 30 відсотках до 40 відсотків випадків ми бачимо, що бізнес вже має конкретний випадок використання, який благає про те, щоб надати можливість поточної аналітики.
Ребекка Йозвяк: Це має сенс. У мене є ще одне трохи більш технічне запитання від учасника аудиторії. Йому цікаво, чи підтримують ці системи як структуровані, так і неструктуровані потоки даних, як відкладення потоків Twitter або публікації Facebook у режимі реального часу, чи потрібно її спочатку фільтрувати?
Ананд Венугопал: Продукти та технології, про які ми говоримо, дуже швидко підтримують як структуровані, так і неструктуровані дані. Їх можна налаштувати. Усі дані мають якусь структуру, будь то текст чи XML чи взагалі щось. Існує якась структура з точки зору того, що є подача часової позначки. Можливо, є ще одна крапка, яку потрібно проаналізувати, щоб ви могли ввести синтаксичний аналіз у потік для розбору структур даних. Якщо вона структурована, то ми просто скажемо системі: «Гаразд, якщо є значення, розділені комами, і перше - рядок, друге - дата». Отже, ми можемо ввести цю розвідку інтелекту в шари верхнього екрану і легко обробляти як структуровані, так і неструктуровані дані.
Ребекка Йозвяк: У мене є ще одне запитання від аудиторії. Я знаю, що ми трохи пробігли вершину години. Цей учасник хоче знати, схоже, що потокове додавання в реальному часі може розвивати як потребу, так і можливість інтеграції назад у системи транзакцій, наприклад, у системи запобігання шахрайству. У такому випадку, чи потрібно трансакціонувати системи транзакцій, щоб вони підходили до цього?
Ананд Венугопал: Це злиття, правда? Це злиття систем транзакцій. Вони іноді стають джерелом даних, де ми аналізуємо транзакції в режимі реального часу, і в багатьох випадках, коли, скажімо, є прикладний потік, і тут я намагаюся показати статичний сайт пошуку даних, а потім у нашому випадку, де якась потокова передача даних і ви шукаєте статичну базу даних, як HBase або RDBMS, щоб збагатити потокові дані та статичні дані разом, щоб прийняти рішення або аналітичну інформацію.
Ще одна велика галузева тенденція, яку ми також спостерігаємо - конвергенція OLAP та OLTP - і тому у вас є такі бази даних, як Kudu та бази даних в пам'яті, що підтримують одночасно транзакції та аналітичну обробку. Шар обробки потоку буде повністю в пам'яті, і ми розглянемо або взаємодіємо з деякими з цих транзакційних баз даних.
Ребекка Йозвяк: Змішана навантаження була однією з останніх перешкод для стрибка, я думаю. Дез, Робін, у вас двох є ще питання?
Дез Бланчфілд: Я збираюся заскочити на останнє запитання і завершити це, якщо ви не заперечуєте. Перший виклик, з яким організації, з якими я маю справу протягом останнього десятиліття або настільки веде до цього захоплюючого виклику потокової аналітики, перше, що вони, як правило, ставлять на стіл, коли ми розпочали розмову навколо цього виклику, - це де робити ми отримуємо набір навичок? Як ми перекваліфікуємо набір навичок і як ми отримуємо цю здатність внутрішньо? Після того, як Імпульс заходить у руку, провести нас через подорож, а потім здійснити як перший перший крок, і це має багато сенсу робити.
Але для середньої та великої організації, які речі ви бачите в даний момент, щоб підготуватися до цього, створити цю здатність внутрішньо, отримати що-небудь із простого основного словника навколо нього та яке повідомлення вони можуть робити організація навколо переходу до подібних рамок і переобладнання наявного технічного персоналу з ІТ від генерального директора, щоб вони могли самі це запустити, коли ви створили та впровадили його? Просто дуже коротко, які виклики і як вони вирішують, клієнти, з якими ви стикаєтесь, типи проблем, які вони знайшли, і як вони проходять через вирішення цієї перекваліфікації та набуття досвіду та знань, щоб підготуватися до цього і бути в змозі обходитись оперативно?
Ананд Венугопал: Часто невеликий набір людей, які намагаються вийти і придбати платформу потокової аналітичної аналітики, вже досить розумні, оскільки вони знають Hadoop, вони вже здобули свої навички Hadoop MapReduce, і тому що вони тісно співпрацюють з Hadoop постачальник дистрибуції, вони або знайомі. Все отримує, наприклад, Кафка. Вони щось роблять з цим, і Storm, або Spark потоки знаходяться у їх домені з відкритим кодом. Безумовно, люди знайомі з цим або будують навички навколо нього. Але це починається з невеликого набору людей, які є достатньо кваліфікованими та досить розумними. Вони відвідують конференції. Вони навчаються, і вони задають розумні запитання постачальникам, а в деяких випадках вони навчаються у продавців. Коли продавці приходять і представляють себе на першій зустрічі, вони можуть не знати речі, але вони перечитують разом, а потім починають грати з ним.
Ця маленька група людей є ядром, а потім вона починає зростати, і всі тепер розуміють, що перший випадок використання бізнесу стає функціональним. Тут починається хвиля, і ми побачили на саміті Spark минулого тижня, де велике підприємство, як Capital One, було там і в повному складі. Вони вибирали Спарк. Вони говорили про це. Вони багато навчають своїх людей у Spark, оскільки вони сприяють цьому також у багатьох випадках як користувач. Те саме ми бачимо з багатьма, багатьма великими підприємствами. Це починається з декількох невеликих наборів дуже розумних людей, а потім починається хвиля загальної освіти, і люди знають, що колись старший віце-президент або один раз старший директор вирівняється, і вони хочуть зробити ставку на цю річ, і слово обходить і всі вони починають підбирати ці навички.
Дез Бланшфілд: Я впевнений, що ви фантастично проводите час і для цих чемпіонів.
Ананд Венугопал: Так. Ми багато навчаємо, працюючи з початковими чемпіонами, і ми проводимо тренінгові курси, і багато, багато для наших великих клієнтів ми повернулися назад і провели хвилі та хвилі тренувань, щоб привести багато користувачів у фазу основної роботи, особливо на сайті Hadoop MapReduce. Ми виявили, що у великій компанії з кредитних карт, яка є нашим замовником, ми поставили принаймні, можливо, п’ять-вісім різних навчальних програм. У нас також є безкоштовні спільноти всіх цих продуктів, включаючи нашу, пісочницю, яку люди можуть завантажувати, звикати і також навчати себе.
Дез Бланчфілд: Це все, що я маю для вас сьогодні вранці. Велике спасибі. Мені здається неймовірно цікавим побачити типи моделей та випадки використання, які ви сьогодні отримали для нас. Дякую.
Ананд Венугопал: Чудово . Дуже дякую людям.
Ребекка Йозвяк: Дякуємо всім за те, що приєдналися до нас у цих трансляціях Hot Technologies. Це було захоплююче почути від Дез Бланчфілд, доктора Робіна Блура та від компанії Impetus Technologies, Ананда Венугопала. Дякую присутнім. Дякую спікерам і дякую аудиторії. У нас є ще один Hot Technologies в наступному місяці, тому шукайте це. Ви завжди можете знайти наш вміст в архіві на сайті Insideanalysis.com. Ми також розміщуємо багато вмісту на SlideShare та кілька цікавих біт на YouTube.
Це все, шановні. Ще раз дякую і приємного дня. Бувай.
