Винос: Ведуча Ребекка Йозвяк обговорює переваги каталогів даних з Дезом Бланчфілдом, Робіном Блором та Девідом Кроуфордом.
Ви повинні зареєструватися для цієї події, щоб переглянути відео. Зареєструйтесь, щоб переглянути відео.
Ребекка Йозвяк: Дами та панове, привіт, ласкаво просимо до Hot Technologies 2016 року. Сьогодні ми отримали "Сила навіювання: як каталог даних дає можливість аналітикам". подорожує світом, тому дякую за приєднання до нас. Цього року спекотно, в Техасі не просто спекотно, де я є, але все жарко. Виходить вибух всіляких нових технологій. У нас з'явився IoT, потокові дані, прийняття хмари, Hadoop продовжує дозрівати і бути прийнятим. У нас є автоматизація, машинне навчання, і все це, звичайно, підкреслюється даними. І підприємства стають все більше і більше даних, що рухаються з кожним днем. І звичайно, сенс у тому, щоб вести до знань, відкриттів і, знаєте, приймати кращі рішення. Але щоб дійсно отримати максимальну цінність від даних, до них потрібно легко отримати. Якщо ви тримаєте його в замкнутому або похованому або в мозку кількох людей на підприємстві, це не принесе багато користі для підприємства в цілому.
І я якось думав про каталогізацію даних і про роздуми з курсу бібліотек, куди ви давно пішли, якщо вам потрібно було щось знайти, якщо вам потрібно було вивчити тему чи шукати якусь інформацію, ви пішли до бібліотеки і, звичайно, ви зайшли до каталогу картки, або краб-леді, яка там працювала. Але також було весело блукати, якщо ви просто хотіли подивитися, і впевнені, що можете просто відкрити щось акуратне, ви можете дізнатися цікаві факти, яких ви не знали, але якщо вам дійсно потрібно було щось знайти, і ви знали, що шукаєте, вам потрібен каталог карт, і, звичайно, корпоративний еквівалент - це каталог даних, який може допомогти засвітити всі дані для наших користувачів, щоб збагатити, відкрити, поділитися, споживати і реально допомогти людям отримати швидше і легше передавати дані.
Отже, сьогодні ми отримали Дез Бланчфілд, наш власний науковець з даних, і у нас є доктор Робін Блор, наш власний головний аналітик, ми отримали Девіда Кроуфорда з Alation, який буде говорити про історію каталогізації даних своєї компанії, але спочатку ми підемо вести з Дез. Дез, я передаю м'яч тобі, а підлога твоя.
Dez Blanchfield: Дякую, дякую за те, що мене сьогодні взяли. Це питання, яке мене надзвичайно цікавить, адже майже в кожній організації, з якою я стикаюсь у своїй щоденній роботі, я знаходжу саме таку саму проблему, про яку ми дуже коротко говорили на попередній виставі, і це те, що Більшість організацій, які займаються бізнесом більше декількох років, мають безліч даних, похованих навколо організації, різних форматів, і насправді у мене є клієнти, які мають набори даних, які повертаються до Lotus Notes, баз даних, які все ще працюють у деяких випадків, як їх псевдомережі, і всі вони стикаються з цим викликом, як насправді знайти, де їхні дані, і як отримати доступ до них, кому надати доступ до них, коли надати доступ до них і як просто каталог та як дістати його до місця, де кожен може: A) бути в курсі того, що там, і що в ньому, і B), як отримати доступ до нього та використовувати його. І одна з найбільших проблем, звичайно, - це знайти, інша велика проблема - це знати, що там, і як отримати доступ до нього.
Я, можливо, знаю, що у мене є десятки баз даних, але я насправді не знаю, що там, або як дізнатися, що там, і так незмінно, як ми виявляємо зараз у даних попереднього показу, ти схильний ходити по всьому офісу і задайте питання, і кричите по кубічних стінах і намагайтеся розібратися, часто мій досвід, ви навіть можете виявити, що ви блукаєте на рецепції, в прийом і запитуєте, чи хтось знає, хто ви? збираюся йти поговорити. Досить часто це не завжди люди з інформаційних технологій, оскільки вони не знають про набір даних, тому що хтось їх просто створив, і це може бути щось просте, як - досить часто ми знаходимо проект такого типу, який стоїть в ІТ-середовищі і керівник проекту використав електронну таблицю з усіма речами, і вона отримала величезну кількість цінної інформації навколо активів і проти, а також імен, і якщо ви не знаєте цього проекту і не знаєте цієї людини, ви просто не можете знайти цю інформацію. Він просто недоступний, і ви повинні отримати цей оригінальний файл.
Існує фраза, яка накручується навколо даних щодо даних, і я не обов'язково з цим погоджуюся, але я думаю, що це милий маленький викид, і це те, що певна кількість людей думає, що дані - це нова олія, і я впевнений, що ми Зробимо це висвітлити і в деякому аспекті, пізніше сьогодні. Але я помітив, що, безумовно, є частиною цієї трансформації, це те, що організації підприємств, які навчилися оцінювати свої дані, отримали значну перевагу перед своїми конкурентами.
Близько п’яти-шести років тому IBM був цікавим документом, і вони опитували близько 4000 компаній тут, в Австралії, і вони взяли всю інформацію, всі дані про результати діяльності, всі дані про фінанси і склали їх у киплячу посудину, а потім відправив його в австралійську школу економіки, і вони насправді почали тут загальну тенденцію, і це було те, що компанії, які використовували технології, незмінно отримували таку конкурентну перевагу над своїми однолітками та конкурентами, що їх конкуренти майже ніколи не наздоганяють, і я думаю це вже зараз так, коли ми бачили те, що люди називають цифровою трансформацією, коли організації, які чітко придумали, як знайти отримані дані, зробити ці дані доступними та зробити їх доступними в дуже простому витратному матеріалі мода на організацію, не обов'язково завжди знаючи, чому організація може цього потребувати, і отримувати значну перевагу перед конкурентами.
У мене на цьому слайді є кілька прикладів, які ви можете побачити. Мій погляд, полягає в тому, що масштабні перешкоди майже в кожному галузевому секторі, на мою думку, зумовлені даними, і якщо сучасні тенденції є чим пройти, я вважаю, що ми дійсно тільки що отримали почалося тому, що коли давні бренди нарешті прокидаються, що це означає, і вступають у гру, вони збираються входити в гру оптом. Коли начебто великі роздрібні торговці, які мають гори даних, починають застосовувати історичний аналіз даних, якщо вони навіть знають, що вони існують, то деякі з онлайн-гравців збираються трохи зателефонувати.
Але з багатьма з цих марок, я маю на увазі, що у нас є Uber, яка є найбільшою компанією таксі в світі. Вони не мають жодних таксі, і що це робить їх магіями, які їх дані? Airbnb, найбільший постачальник послуг розміщення, у нас є WeChat, найбільша в світі телефонна компанія, але в них немає фактичної інфраструктури, ані телефонів, ані телефонних ліній. Alibaba, найбільший роздрібний продавець на планеті, але вони не володіють жодним інвентарем. , найбільша медіа-компанія на слові. Я думаю, що за останніми підрахунками у них зараз було 1,4 мільярда активних користувачів даних, що є вражаючим числом. Це не десь поблизу - я думаю, хтось стверджував, що чверть планети насправді є щодня там, і все ж ось постачальник контенту, який насправді не створює вміст, усі дані, які вони обслуговують, не створені ними, вони створені їх передплатники, і всі ми знаємо цю модель.
SocietyOne, про який ви можете чи не чули, це місцевий бренд. Я думаю, що в декількох країнах це банк, який фактично займається одноранговим кредитуванням, тобто іншими словами, у нього немає грошей. Все, що він робить - це керувати транзакціями, а дані розташовуються під ними. Netflix, ми всі з цим дуже і дуже знайомі. Тут є цікавий однолінійний. Коли Netflix був легально використаний в Австралії, коли він був офіційно оголошений, вам не потрібно було використовувати VPN, щоб дістатися до нього, багато людей у всьому світі прагнуть - якщо ви не можете дістатись до нього у вашій місцевості - коли Netfix був запущений в Австралії, він збільшив міжнародну пропускну спроможність наших інтернет-посилань на 40 відсотків, тому майже вдвічі скористався використанням Інтернету в Австралії за одну ніч, лише одним додатком, одним хмарним додатком, який не грає нічого, окрім даних. Це просто вражаюча статистика.
І ми, звичайно, всі знайомі з Apple і Google, але це найбільші програмні компанії на планеті, але вони насправді не пишуть програми. Що відповідає всім цим організаціям? Ну, це дані, і вони не потрапили туди, бо не знали, де їх дані, і не знали, як їх каталогізувати.
Зараз ми з’ясовуємо, що існує весь цей новий клас активів, який називають даними, і компанії прокидаються до нього. Але у них не завжди є інструменти та ноу-хау, і тому картувати всі ці дані, каталогізувати всі ці дані та робити їх доступними, але ми виявили, що компанії, які майже не мають фізичних активів, за рекордні терміни здобули високу ринкову цінність через цей новий клас активів даних. Як я вже казав, деякі старі гравці зараз прокидаються до цього і, безумовно, виводять його.
Я великий фанат приймати людей на невелику подорож, тож у вісімнадцяти сотнях, наприкінці вісімнадцяти сотень, і ви будете більш ніж знайомі з цим на ринку США, виявилося, що провести перепис щорічно або близько того, я думаю, що вони проводили їх кожні десять років, але якщо ви збираєтеся проводити перепис кожного року, то, можливо, вам знадобиться до восьми чи дев'яти років, щоб насправді зробити аналіз даних. Виявилося, що той набір даних потім залишився в скриньках місцями на папері, і майже ніхто їх не міг знайти. Вони просто продовжували викачувати ці звіти, але до фактичних даних було дуже важко дістатись, ми маємо подібну ситуацію з іншим світовим моментом, приблизно в 40-х роках, з другою світовою війною, і ця річ у Блечлі Парк Бомбе написана BOMBE , і це був масивний аналітичний інструмент для стискання чисельності, який проходив би через невеликі набори даних і знаходив у ньому сигнали, і використовувався для допомоги пролому кодів через Enigma.
Знову ж таки, це було по суті пристроєм, розробленим не для каталогізації, а для тегування та картографування даних, а також дозволяючи приймати шаблони та знаходити їх всередині наборів даних, в цьому випадку ламати коди, знаходити ключі та фрази та знаходити вони регулярно перебувають у наборах даних, і тому ми пройшли цей шлях пошуку речей у даних та просування до каталогізації даних.
А потім ці речі прийшли, ці масивні недорогі стелажі машин, просто позаштатні машини. І ми зробили кілька дуже цікавих речей, і одна з речей, яку ми зробили з ними, це те, що ми створили кластери з низькою вартістю, які могли б почати індексувати планету, і дуже відомі ці великі бренди, які приходять і відходять, але, мабуть, найпоширеніший дім Google бренд, про який ми всі чули - він стає фактичним дієсловом, і ви знаєте, що ви успішні, коли ваш бренд стає дієсловом. Але те, що Google навчив нас, не усвідомлюючи цього, можливо, у діловому світі, - це те, що вони змогли індексувати всю планету до певного рівня та каталогізувати дані, що були по всьому світу, і зробити їх доступними дуже просто, зручна форма у маленькій крихітній однорядковій формулі, веб-сторінка, на якій майже нічого немає, і ви вводите свій запит, він іде і знаходить його, оскільки вони вже обскакували планету, проіндексували її та зробили її доступною.
І те, що ми помітили, було: «Добре тримайтеся, ми цього не робимо в організаціях - чому це так? Чому це те, що у нас є організація, яка може скласти карту всієї планети та індексувати її, сканувати та індексувати її та робити її доступною, ми можемо її шукати, а потім натискати на предмет, щоб перейти та знайти її, як ми не зробили це всередині? "Отже, зараз у всьому світі існує безліч цих маленьких стелажів машин, які роблять це для інтрамереж і знаходять речі, але вони все ще просто стикаються з ідеєю вийти за рамки традиційної веб-сторінки, або файловий сервер.
Замість того, щоб зараз багато разів вводити цей каталог даних нового покоління, відкривати доступ до даних через нотатки пост-це та розмови з охолодженням води - насправді вже не є належним методом для виявлення та каталогізації даних, і насправді, я не думаю, що це коли-небудь було насправді . Ми більше не можемо вести цей виклик перед людьми, просто пропускаючи нотатки, публікуючи нотатки та спілкуючись у чаті. Ми добре і справді поза межами області, де цей підхід до наступного покоління каталогізації даних з'явився і минув. Ми повинні обіймати його. Якби це було простою проблемою, ми б її вже багато способами вирішили раніше, але я думаю, що це непроста проблема, лише індексація та виклик даних - це лише одна її частина, знаючи, що є в даних та створює метадані навколо того, що ми виявимо, а потім зробимо його доступним у легкій, споживчій формі, особливо для самообслуговування та аналітики. Проблема все ще вирішується, але багато частин головоломки за п’ять років добре і справді вирішені та доступні.
Як ми знаємо, люди, які каталогізують дані, - це рецепт невдач, тому що людська помилка - один із найбільших кошмарів, з якими ми стикаємося в обробці даних, і я регулярно розмовляю на цю тему, де, на мою думку, люди, заповнюючи паперові форми, мабуть, найбільший кошмар. ми маємо справу з великими даними та аналітикою, щоб постійно потрібно виправляти те, що вони роблять, навіть аж до простих речей, таких як дати та поля, що люди ставлять їх у неправильному форматі.
Але, як я вже говорив, ми бачили, що пошукові системи Інтернету щодня індексують світ, тому зараз ми робимо це на думці, що це можна зробити на наборах бізнес-даних у процесі відкриття, а інструменти та системи зараз легко доступні, як ви збираєтеся сьогодні дізнатися. Тож фокус, дійсно, на мій погляд, - це підбір правильних інструментів, найкращих інструментів для роботи. І ще більш доречно, щоб знайти потрібну частину, яка допоможе вам почати цей шлях. І я вважаю, що ми сьогодні будемо чути про це, але перш ніж це зробити, я перейду до свого коледжу, Робін Блор і почую його тему. Робін, чи можу я передати тобі?
Робін Блор: Так, звичайно, можна. Давайте подивимось, чи працює це, о, так. Гаразд, я їду з іншого напрямку, ніж Діз, але я опинюсь там же. Йдеться про підключення до даних, тому я просто думав, що я пройду реальність підключення до даних, по-справжньому.
Існує факт, що дані більш фрагментовані, ніж колись. Обсяг даних зростає феноменально, але насправді різні джерела даних також зростають з неймовірними темпами, і тому дані стають все більш фрагментарними. Але, зокрема, з прикладних програм для аналітики - але це не єдині програми - у нас є справді вагома причина підключитися до всіх цих даних, тому ми застрягли у важкому місці, ми застрягли у світі фрагментарних даних, і в даних є можливість, як називав її Dez, нове масло.
Щодо даних, ну, вона раніше жила на спінінг-диску, або у файлових системах, або в базах даних. Зараз він живе в набагато різноманітнішому середовищі, він живе у файлових системах, але він також живе в екземплярах Hadoop в наші дні, або навіть в Іскрах. Він живе в декількох видах баз даних. Не так давно ми наче стандартизували деяку реляційну базу даних, добре ви знаєте, що за останні п’ять років вийшло вікно, тому що є необхідність у базі даних документів, а в базі даних графів є потреба, так що ви знаєте, гра має змінився. Так він жив на спінінг-диску, але зараз він живе на SSD. Остання кількість SSD - безумовно, останній блок SSD виходить від Samsung - двадцять гігабайт, що величезна кількість. Тепер він живе в пам'яті, в тому сенсі, що основна копія даних може бути в пам'яті, а не на диску, ми не використовували для створення таких систем; ми робимо зараз. І живе в хмарі. Що означає, що він може жити в будь-якій з цих речей, у хмарі, вам не обов’язково знати, де він знаходиться в хмарі, у вас буде лише його адреса.
Просто Hadoop поки що не вдався до розширеного сховища даних. Ми сподівалися, що це стане розширюваним сховищем масштабних даних, і це просто стане однією файловою системою для всього, і це буде - веселки з’являться на небі, в основному, і єдинороги танцюють навколо, і нічого з цього не сталося. Це означає, що ми стикаємося з проблемою транспортування даних, а транспортування даних часом не виникає необхідності, але це також складно. Дані справді мають серйозну вагу, коли ви потрапили в багато терабайт даних, збираючи їх і перекидаючи, види затримок з’являються у вашій мережі або з’являються в різних місцях. Якщо ви хочете перенести дані навколо, час є важливим фактором. В даний час майже завжди існують певні обмеження щодо того, скільки часу у вас є, щоб отримати одну річ, одні дані з одного місця в інше. Раніше це було те, про що ми думали як пакетні вікна, коли машина була простоюча, і незалежно від того, скільки даних у вас було, ви можете просто кинути їх, і все вийде. Добре, що минуло, ми живемо в набагато більш реальному світі. Тому час є фактором. Як тільки ви хочете перемістити дані, тому якщо дані мають гравітацію, ви, ймовірно, не можете їх перемістити.
Управління даними є фактором у тому сенсі, що ви насправді маєте керувати всіма цими даними, ви цього не отримуєте безкоштовно, а реплікація може знадобитися для того, щоб насправді отримати дані, щоб виконати роботу, яку потрібно зробити, адже це може бути не бути там, де ви його поставили. У нього може бути недостатньо ресурсів для нормальної обробки даних. Таким чином, дані копіюються, а дані отримують більше, ніж ви могли б уявити. Я думаю, хтось давно сказав мені, що середній фрагмент даних повторюється щонайменше два з половиною рази. ESB або Kafka пропонують можливість передачі даних, але сьогодні вона потребує архітектури. Сьогодні вам дійсно потрібно подумати так чи інакше, про те, що насправді означає перекидати дані. Тому, як правило, бажано отримати доступ до даних там, де вони є, якщо, звичайно, ви зможете отримати необхідну ефективність, коли ви дійсно шукаєте дані, і це залежить від кон. Так що це все-таки складна ситуація. З точки зору запитів даних, ми раніше могли мислити з точки зору SQL, ми дійсно з'явилися зараз, ви знаєте, різні форми запитів, SQL так, але суміжні, також запити графіків, Spark - це лише один приклад ведення графіка , тому що також нам потрібно робити пошук, більше ніж ми колись, також здійснювати регулярний вигляд пошукових запитів, що є дійсно складним пошуком шаблонів, і справжнім узгодженням шаблону, всі ці речі насправді відриваються. І всі вони корисні, оскільки отримують вам те, що ви шукаєте, або можуть отримати вам те, що ви шукаєте.
Зараз запити поширюються на декілька даних, тому це не робилося завжди, і часто це вражає, якщо ви це робите. Отже, це залежить від обставин, але люди очікують, що зможуть запитувати дані з декількох джерел даних, тому федерація даних того чи іншого типу стає все більш актуальною. Віртуалізація даних, яка є різним способом цього, залежно від продуктивності, також є дуже поширеною. Запити даних - це фактично частина процесу, а не весь процес. Варто лише зазначити, що якщо ви насправді дивитесь на ефективність аналітики, реальна аналітика може зайняти набагато довше часу, ніж збір даних, адже це залежить від обставин, але запити даних є абсолютно необхідною необхідністю, якщо ви хочете робити будь-які вид аналітики на декілька джерел даних, і просто, ви насправді повинні мати можливості, що охоплюють.
Тож про каталоги.Каталоги існують з причини, принаймні, ми говоримо, що, знаєте, це, у нас є каталоги, і у нас є схеми в базах даних, і у нас є кожен каталог, і ми куди б ви не поїхали, ви знайдете одне місце, і тоді ви фактично виявимо, що існує якийсь каталог, а уніфікований глобальний каталог - така очевидно гарна ідея. Але дуже мало компаній мають таке. Я пам’ятаю, що в тому році, коли дві тисячі - рік, дві тисячі років, паніка - я пам’ятаю, що комуністи не могли навіть визначити, скільки у них виконуваних файлів, не маючи на увазі, скільки у них зберігалися різні сховища даних, і це, мабуть, так і зараз, ви знайте, що більшість компаній активно не знають у глобальному розумінні, які дані у них є. Але очевидно стає все більш необхідним мати глобальний каталог або, принаймні, мати глобальну картину того, що відбувається через зростання джерел даних та постійне зростання прикладних програм, і це особливо необхідно для аналітики, тому що ви також так чи інакше, і тут є інші проблеми, такі як родовід і проблеми з даними, і це потрібно для безпеки, багатьох аспектів управління даними, якщо ви дійсно не знаєте, які дані у вас є, думка, що ви збираєтесь керувати, це просто абсурдно. Отже, у тому, що всі дані якимось чином каталогізовано - це лише факт. Питання в тому, чи є каталог узгодженим, а власне, що з ним можна зробити. Тому я повернусь до Ребеки.
Ребекка Йозвяк: Гаразд, дякую Робін. Наступним ми отримали Девіда Крофорда з Алації, Девід. Я буду йти вперед і передавати м'яч тобі, і ти можеш забрати його.
Девід Крофорд: Дуже дякую. Я дуже ціную, що ви, хлопці, взяли мене на це шоу. Я думаю, що я розпочну це, тому я думаю, що моя роль тут полягає в тому, щоб взяти частину цієї теорії і побачити, як вона насправді застосовується, і результати, які ми можемо досягти у реальних клієнтів, і тому ви можете побачити декілька на слайді, я хочу поговорити про те, які результати ми зможемо побачити в аналітичних можливо покращеннях. Отже, щоб мотивувати дискусію, ми поговоримо про те, як вони туди потрапили. Тож мені пощастило, що я досить тісно співпрацюю з великою кількістю справді розумних людей, цих клієнтів, і я просто хочу зазначити декількох, хто зміг насправді виміряти, та поговорити про те, як наявність каталогу даних вплинула на їх аналітика робочий процес. І лише для того, щоб ненадовго залишитися на фронті, я думаю, що одне з речей, які ми бачимо, зміни - це вірші каталогів даних, попередні опосередковані рішення та один із способів, як відносини дійсно думають про рішення, які ми складаємо разом, - це починати з аналітиків і працювати назад. Скажімо, давайте зробимо це для забезпечення продуктивності аналітиків. На відміну від просто дотримання вимог, або на відміну від того, щоб просто мати інвентар, ми робимо інструмент, який робить аналітиків більш продуктивними.
Отже, коли я розмовляю з науковцем з даних фінансової компанії Square, там є хлопець Нік, який розповідав нам про те, як його, йому потрібні кілька годин, щоб знайти потрібний набір даних, щоб почати звіт, тепер він може зробіть це за лічені секунди, використовуючи пошук на ринковій частці, ми поговорили з їхнім організатором, який витягнув своїх аналітиків, які використовували Square, вибачте мене, використовував Alation, щоб дізнатися, що їх, які переваги вони побачили, і вони повідомили про 50 відсоткове підвищення продуктивності, і що, один з провідних рітейлерів у світі, eBay, у них є понад тисяча людей, які регулярно займаються SQL-аналізом, і я досить тісно співпрацюю з Деб Сайс, який є проектом Менеджер у своїй команді інструментів даних, і вона виявила, що коли запитуючі приймають Alation, приймають каталог, вони бачать подвійну швидкість написання нових запитів у базу даних.
Отже, це реальні результати, це люди, які насправді застосовують каталог у своїй організації, і я хочу ознайомити вас з тим, що потрібно для налаштування. Як каталог налагоджується в компанії, і, можливо, найголовніше, що потрібно сказати, - це те, що багато цього відбувається автоматично, тому Dez говорив про системи, дізнався про системи, і саме це робить сучасний каталог даних. Тож вони встановлюють Alation у своєму центрі обробки даних, а потім підключають його до різних джерел метаданих у своєму середовищі даних. Я трохи зупинюся на базах даних та BI-інструментах - з цих двох ми збираємося витягувати технічні метадані, а саме про те, що існує. Правильно, так які столи? Які звіти? Що таке визначення звіту? Таким чином, вони витягують ці технічні метадані, і сторінка каталогу автоматично створюється для кожного об'єкта всередині цих систем, а потім вони також витягують і шарують поверх цих технічних метаданих, вони шарують поверх даних про використання. Це в основному відбувається за допомогою читання журналів запитів із бази даних, і це справді цікаве джерело інформації. Отже, щоразу, коли аналітик пише запит, коли-небудь інструмент звітності, чи вирощується він вдома, чи не на полиці, чи інструмент звітності виконує запит з метою оновлення інформаційної панелі, коли додаток запускає запит, щоб вставити дані для роботи набір даних - усі ці речі фіксуються в журналах запитів бази даних. Чи є у вас каталог чи ні, вони записуються в журнал запитів із базою даних. Що може зробити каталог даних, а особливо те, що може зробити каталог Alations, - це прочитати ці журнали, задати запити всередині них та створити дійсно цікавий графік використання на основі цих журналів, і ми це введемо в гру для інформування майбутніх користувачів даних про те, як минулі користувачі даних ними користувались.
Отже, ми збираємо всі ці знання разом у каталог, і щоб зробити це справді справжнішим, це інтеграції, які вже розгорнуті у клієнтів, тож ми побачили Oracle, Teradata, Redshift, Vertica та купу інших реляційні бази даних. У світі Hadoop існує ряд SQL на Hadoop, подібні реляційні, мета-магазини на вершині файлової системи Hadoop, Impala, Tez, Presto і Hive; ми також спостерігали успіх у хмарних приватних постачальників Hadoop, таких як Altiscale, і ми також змогли підключитися до серверів Tableau, серверів MicroStrategy та індексувати там панелі інформаційних панелей, а також інтеграцію з інструментами діаграми з науковими даними, як Plotly.
Отже, ми підключаємося до всіх цих систем, ми підключали ці системи до клієнтів, ми втягували технічні метадані, ми втягували дані використання, і ми на зразок автоматично грунтували каталог даних, але таким чином ми централізовуйте знання, але просто централізуючи речі в каталозі даних, це не дає саме по собі справді чудове підвищення продуктивності, про яке ми говорили з eBay, Square та часткою ринку. Для цього нам насправді потрібно змінити спосіб мислення щодо передачі знань аналітикам. Одне з питань, яке вони задають, щоб підготуватися до цього, було "Як каталог насправді впливає на робочий процес аналітика?"
Це те, про що ми витрачаємо цілий день на роздуми, і щоб говорити про цю зміну в мисленні, про поштові стихи, про модель, я хотів зробити швидку аналогію тому, яким був світ до і після читання на Kindle. Тож це просто досвід, який можуть мати деякі з вас, коли ви читаєте фізичну книгу, ви натрапляєте на слово, ви не впевнені, що знаєте визначення цього слова дуже добре, ви можете, можливо, здогадатися про це, не дуже ймовірно, що ви збираєтеся піднятися з дивана, підійдіть до своєї книжкової полиці, знайдете свій словник, запиліть його і переверніть на потрібне місце в алфавітному переліку слів, щоб переконатися, що так, так, у вас це визначення було правильно, і ви знаєте нюанси його. Так це насправді не відбувається. Отже, ви купуєте додаток Kindle і починаєте там читати книги, і ви бачите слово, в якому ви не зовсім впевнені, і доторкаєтесь до цього слова. Раптом, прямо на цьому ж екрані, є словникове визначення цього слова з усіма його нюансами, різними прикладними звичаями, і ви трохи провести пальцем, і ви отримаєте статтю з Вікіпедії на цю тему, ви знову проведіть пальцем, ви отримуєте інструмент для перекладу, який може перекласти його на інші мови чи з інших мов, і раптом ваше знання мови є набагато багатшим, і це просто відбувається вражаюча кількість разів, порівняно з тим, коли вам довелося їхати і витягніть цей ресурс для себе.
І тому, що я збираюся стверджувати, це те, що робочий процес для аналітика та спосіб, який аналітик буде працювати з документацією даних, насправді дуже схожий на те, як читач буде взаємодіяти зі словником, чи то фізичним, чи то Kindle, і так, що ми, як ми дійсно бачили це підвищення продуктивності, - це не розсипати каталог, а підключити його до робочого процесу аналітика, і так, вони попросили мене зробити тут демонстрацію, і я хочу зробити так, щоб у центрі уваги цієї презентації. Але я просто хочу налаштувати контент для демонстрації. Коли ми думаємо про те, щоб передати знання користувачам, коли вони їм потрібні, ми вважаємо, що правильне місце для цього, місце, де вони проводять свій час і де вони роблять аналіз, - це інструмент запитів SQL. Місце, де ви пишете та запускаєте SQL запити. І тому ми створили його, і ми побудували його, і річ, що насправді відрізняється від інших інструментів запитів, - це глибока інтеграція з каталогом даних.
Тож наш інструмент запиту називається Alation Compose. Це веб-інструмент запитів, і я вам його покажу за секунду. Веб-інструмент запитів, який працює над усіма тими логотипами баз даних, які ви бачили на попередньому слайді. Зокрема, я намагаюся демонструвати те, як інформація про каталог надходить до користувачів. І це робиться за допомогою цих трьох різних способів. Це робиться через втручання, і ось, коли хтось, хто керує даними, або керуючий даними, або якийсь адміністратор, або менеджер, може сказати: "Я хочу впорядкувати вказівку чи попередження в робочий процес та переконайтесь, що він доставлений користувачам у потрібний час ». Отже, це втручання і добре це показує.
Розумні пропозиції - це спосіб, коли інструмент використовує всі свої узагальнені знання про каталог, щоб запропонувати предмети та частини запиту під час його написання. Найголовніше, що потрібно знати, це те, що він дійсно використовує журнал запитів, щоб зробити це, запропонувати речі на основі використання, а також знайти навіть частини запитів, які були написані раніше. І добре це покажіть.
А потім попередній перегляд. Попередній перегляд, коли ви вводите назву об'єкта, ми показуємо вам все, що знає каталог, або, принаймні, найбільш відповідні речі, які каталог знає про цей об’єкт. Отже, зразки даних, які раніше їх використовували, логічне ім'я та опис цього об’єкта, все з’являються до вас, поки ви пишете їх, не звертаючись до них.
Тож без зайвих розмов я потрапляю до демонстрації, і я просто зачекаю, поки він з’явиться. Що я вам тут покажу, - це інструмент запитів. Це виділений інтерфейс для запису SQL. Це окремий інтерфейс від каталогу, в певному сенсі. Дез і Робін поговорили про каталог, а я трохи перестрибував інтерфейс каталогу прямо, щоб його внести безпосередньо в обслуговування робочого процесу.
Я просто показую тут місце, де я можу набрати SQL, і внизу ви побачите, що у нас є якась інформація про об'єкти, на які посилаються. Тож я просто збираюся почати вводити запит, і я зупиняюсь, коли доїду до однієї з таких втручань. Так Хворому введіть "select", і я хочу рік. Я хочу ім'я. І я збираюся шукати деякі дані про зарплату. Отже, це набір даних про освіту. У ньому є інформація про вищі навчальні заклади, і я дивлюся на середню зарплату викладачів, яка знаходиться в одній із цих таблиць.
Тому я фактично набрав слово "зарплата". Це не зовсім в назві стовпця таким чином. Ми використовуємо як логічні метадані, так і фізичні метадані, щоб робити пропозиції. І що я хочу тут зазначити, це жовте поле, яке з’являється тут. У ній написано попередження про цю колонку. Я не шукав цього, я не брав клас про те, як правильно використовувати ці дані. Це дійшло до мене, і це, по суті, попередження про угоду про конфіденційність, що стосується цих даних. Отже, є деякі правила розкриття інформації. Якщо я збираюся запитати ці дані, я збираюсь брати дані з цієї таблиці, я повинен бути обережним, як я їх розкриваю. Тож у вас тут політика управління. Є деякі проблеми, пов'язані з дотриманням норм, що дозволяє набагато простіше виконувати цю політику, коли я знаю про неї в той момент, коли я переглядаю дані.
Тож я отримав те, що підходить до мене, і тоді я також збираюся подивитися на навчання. І ось ми бачимо, що попередні перегляди вступають у гру. У цій колоні навчання я бачу - це стовпець навчання на таблиці установи, а я бачу профіль цього. Alation йде і витягує зразки даних з таблиць, і в цьому випадку її показ показує мені щось цікаве. Він показує мені розподіл значень і показує мені, що нульове значення виявилося в вибірці в 45 разів і більше, ніж будь-яке інше значення. Тож у мене з’явилося певне відчуття, що ми можемо бракувати деяких даних.
Якщо я досвідчений аналітик, то це, можливо, вже є частиною мого робочого процесу. Особливо, якщо я особливо прискіпливий, де я б заздалегідь робив купу запитів з профілювання. Щоразу, коли я наближаюсь до нового фрагмента даних, я завжди замислююся про те, яким є наше покриття даних. Але якщо я новачок у аналізі даних, якщо я новачок у цьому наборі даних, я можу припустити, що якщо є стовпець, його заповнюють весь час. Або я можу припустити, що якщо його не заповнено, його не буде нульовим, його нульовим чи іншим подібним. Але в цьому випадку у нас багато нулів, і якби я робив середнє значення, вони, ймовірно, помиляться, якби я просто припускав, що ці нулі насправді дорівнюють нулю, а не відсутніх даних.
Але Alation, ввівши цей попередній перегляд у ваш робочий процес, начебто просить вас ознайомитися з цією інформацією та дає навіть деяким початківцям аналітикам шанс побачити, що тут щось помічає щодо цих даних. Отже, у нас є попередній перегляд.
Наступне, що я збираюся зробити, - це Я намагаюся дізнатися, з яких таблиць отримати цю інформацію. Тож тут ми бачимо розумні пропозиції. Продовжувався весь час, але, зокрема, тут я навіть нічого не набирав, окрім як він запропонував би мені, які таблиці я б хотів використовувати для цього запиту. І найголовніше, що потрібно знати про це, це те, що він користується статистикою використання. Так що в таких умовах, як, наприклад, eBay, де у вас є сотні тисяч таблиць в одній базі даних, інструмент, який може нанести удар по пшениці з пшениці, і використовувати ці статистичні дані, є дуже важливими для їх створення. пропозиції чогось варті.
Тож буде запропоновано цю таблицю. Переглядаючи попередній перегляд, ми фактично виділяємо три колонки, про які я вже згадував у своєму запиті. Тож я знаю, що його отримали три, але вона не має назви. Мені потрібно отримати ім'я, тому я збираюся зробити приєднання. Коли я роблю приєднання, я знову маю ці попередні перегляди, щоб допомогти мені знайти, де знаходиться таблиця з назвою. Тож я бачу, що цей має добре відформатоване, своєрідно написане з великої літери ім'я. Здається, для кожного закладу є один рядок із назвою, тому я збираюсь це схопити, і зараз мені потрібна умова приєднання.
І ось, ось що робить Alation - це знову озиратися на журнали запитів, бачачи попередні рази, що ці дві таблиці були об'єднані, і пропонує різні способи їх приєднання. Ще раз, є деяке втручання. Якщо я дивлюсь на один із них, то воно отримало попередження, яке показує мені, що це слід використовувати лише для сукупного аналізу. Це, ймовірно, призведе до неправильної речі, якщо ви намагаєтесь щось зробити через установу. Враховуючи це, ID OPE затверджений як належний спосіб з'єднання цих двох таблиць, якщо потрібно дані університетського рівня. Тож я це роблю, і це короткий запит, але я написав свій запит, не маючи обов’язково розуміння, що це за дані. Я ніколи насправді не дивився на ЕР-діаграму цього набору даних, але я знаю досить багато про ці дані вже тому, що відповідна інформація надходить до мене.
Таким чином, це своєрідні три способи, за допомогою яких каталог за допомогою інтегрованого інструменту запитів може безпосередньо впливати на робочий процес під час написання запитів. Але однією з інших переваг того, що інструмент запитів інтегровано до каталогу, є те, що, коли я закінчую запит і зберігаю його, я можу поставити назву на кшталт «Навчання в навчальному закладі та виплата факультету», і тут у мене є кнопка, що дозволяє мені просто опублікувати його в каталозі. Мені стає дуже просто годувати цю спину. Навіть якщо я не публікую його, він захоплюється як частина журналу запитів, але коли я публікую його, він фактично стає частиною шляху централізованого місця, де живе все знання даних.
Тож якщо я натискаю Пошук усіх запитів в Alation, мене приймуть - і тут ви побачите ще деякий інтерфейс каталогу - Мене взяли до спеціального пошуку запитів, який показує мені спосіб пошуку запитів у всій організації. І ви бачите, що мій нещодавно опублікований запит знаходиться вгорі. І дехто може помітити тут, коли ми записуємо запити, ми також захоплюємо авторів, і ми наче встановлюємо цей зв’язок між мною як автором та цими об'єктами даних, про які я зараз щось знаю. І я буду створений як експерт із цього запиту та цих об'єктів даних. Це дуже корисно, коли людям потрібно дізнатися про дані, тоді вони можуть знайти потрібну людину, про яку можна дізнатися. І якщо я насправді новачок у даних, чи я передовий аналітик - як передовий аналітик, я можу поглянути на це і побачити купу прикладів, які б почали мене починати з нового набору даних. Як хтось, хто може не відчувати надто розумної роботи з SQL, я можу знайти заздалегідь зроблені запити, це звіти, якими я можу скористатися.
Ось один Філ Мазанетт про середні бали SAT. Натисніть на це, і я отримаю якусь сторінку каталогу для самого запиту. У ньому йдеться про написану статтю, в якій посилається на цей запит, тому є деяка документація, яку я можу прочитати, якщо я хочу навчитися її використовувати. І я можу відкрити його в інструменті запитів, натиснувши кнопку Написати, і я можу просто запустити його тут, навіть не редагуючи. Насправді ви можете побачити трохи наших легких можливостей звітування, коли під час написання запиту ви можете вписати змінну шаблону, як ця, і це створить простий спосіб створити форму для виконання запиту на основі пара параметрів.
Так що я маю для демонстрації. Я збираюся повернутися до слайдів.Просто для підбору підсумків ми показали, як адміністратор, керуючий даними, може втручатися, розміщуючи попередження щодо об’єктів, які відображаються в інструменті запитів, як Alation використовує свої знання щодо використання об'єктів даних для створення розумних пропозицій, як це приносить в деталізації та інших порадах щодо поліпшення робочих процесів аналітиків, коли вони торкаються певних об'єктів, і як усі подібні подачі повертаються в каталог, коли запитуються нові запити.
Очевидно Im прес-секретар від імені компанії. Я збираюся сказати приємні речі про каталоги даних. Якщо ви хочете почути прямо від одного з наших клієнтів, Крісті Аллен із Safeway працює командою аналітиків і має дійсно прикольну історію про час, коли їй потрібно було по-справжньому побити годинник, щоб здійснити маркетинговий експеримент, і про те, як її все Команда використовувала Alation, щоб співпрацювати і дуже швидко розгортатися над цим проектом. Тож ви можете перейти за цим посиланням bit.ly, щоб перевірити цю історію, або якщо ви хочете трохи дізнатися про те, як Alation може внести каталог даних у вашу організацію, ми раді налаштувати персоналізовану демонстраційну версію. Дуже дякую.
Ребекка Йозвяк: Велике спасибі, Девіде. Я впевнений, що у Деза і Робіна є кілька питань, перш ніж я звернуся до аудиторії з питань і запитань. Дез, ти хочеш першим піти?
Dez Blanchfield: Зовсім. Мені подобається ідея цієї концепції опублікованих запитів і пов'язування її з джерелом створення. Я був давнім чемпіоном цієї ідеї власного магазину додатків, і я думаю, що це справді чудова основа, на якій потрібно будувати.
Я прийшов, щоб ознайомитись з деякими організаціями, які ви бачите, як це робите, і деякими історіями успіху, які вони могли б мати протягом усієї подорожі, не тільки використовувати ваш інструмент і платформу для пошуку даних, але і потім трансформувати свої внутрішні культурні та поведінкові риси навколо. Тепер, маючи такий власний магазин додатків, де ви начебто просто завантажуєте, концепцію, де вони не просто можуть їх знайти, але вони можуть насправді почати розвивати маленькі спільноти з власниками цих знань.
Девід Крофорд: Так, я думаю, що ми були здивовані. Ми віримо в цінність обміну запитами, як з мого минулого як менеджера по продуктах в Adtech, так і від усіх клієнтів, з якими ми говорили, але я все ще здивувався тому, як часто це одне з перших речей, про які говорять клієнти як про значення, яке вони отримують з Алації.
Я робив тестування інструменту запитів у одного з наших клієнтів під назвою Invoice2go, і у них був менеджер продукту, який був відносно новим, і вони сказали - він насправді сказав мені, не вимагаючи під час тестування користувача, "я фактично не буду писати SQL взагалі, за винятком того, що це полегшило Alation. "І звичайно, як прем'єр-міністр, я начебто йду:" Що ти маєш на увазі, як ми це зробили? "І він сказав:" Ну, справді це тільки тому, що я я можу увійти в систему, і я можу побачити всі ці існуючі запити ". Починати з пустого сланця з SQL - це надзвичайно важко, але змінити існуючий запит, де ви можете побачити результат, який вийшов, і ви можете сказати:" О , Мені просто потрібен цей додатковий стовпчик ", або" мені потрібно відфільтрувати його до певного діапазону дат ", це набагато простіше зробити.
Ми бачили подібні допоміжні ролі, як, наприклад, менеджери продуктів, можливо, люди, котрі починають брати участь у продажах, і які завжди хотіли вивчити SQL і почати підбирати його за допомогою цього каталогу. Ми також бачили, що багато компаній намагалися зробити щось із відкритим кодом. Я намагався створити такі речі всередині, де вони відстежують запити та роблять їх доступними, і є справді якісь складні проблеми дизайну, щоб зробити їх корисними. був внутрішній інструмент, який вони назвали HiPal, який охопив усі запити, написані на Hive, але те, що ви дізнаєтесь, це те, що якщо ви не підштовхуєте користувачів правильним чином, ви просто закінчите дуже довгий список відбір заяв. І як користувач, який намагається розібратися, чи запит корисний для мене, чи корисний для нього, якщо я просто перегляну довгий перелік вибраних висловлювань, мені знадобиться набагато більше часу, щоб отримати щось цінне там, ніж починаючи з нуля. Ми досить ретельно продумали, як скласти каталог запитів, який виводить потрібні речі на передній план і надає їх корисним чином.
Dez Blanchfield: Я думаю, що всі ми проходимо цю подорож від наймолодшого віку, аж до дорослого життя, багатьма способами. Купа технологій. Я, особисто я, пережив цю саму справжню річ, як, навчившись скорочувати код. Я б переглянув журнали, потім книги, і вивчив би певний рівень, і тоді мені потрібно було піти і насправді отримати ще якусь підготовку та освіту.
Але мимоволі я виявив, що навіть коли я йшов від викладання себе і читання журналів, читання книг і відбивання програм інших народів і переходу на курси по ньому, я все-таки закінчив вчитися стільки ж, як робити курси, як просто говорив з іншими люди, які мали певний досвід. І я думаю, що це цікаве відкриття, що тепер, коли ви доводите це до аналітики даних, в основному бачили ту саму паралель, що люди незмінно досить розумні.
Інша річ, яку я дуже хочу зрозуміти, це те, що на дуже високому рівні багато організацій збираються запитати: "Скільки часу потрібно, щоб дійти до цього пункту?". Який переломний момент часу, коли люди отримують вашу платформу встановлено, і вони почали відкривати типи інструментів? Наскільки швидко люди просто бачать, що ця річ перетворюється на справді негайний "а-ха" момент, коли вони розуміють, що вони навіть не турбуються про рентабельність інвестицій, оскільки її немає, але тепер вони насправді змінюють спосіб свого ведення бізнесу? І вони відкрили втрачене мистецтво, і вони сподіваються, що зможуть зробити щось справді, дуже цікаво.
Девід Крофорд: Так, я можу трохи торкнутися цього. Я думаю, що коли ми встановлюємо, що одна з приємних речей, одна з речей, що люблять у каталозі, безпосередньо пов’язаному з системами даних, - це те, що ви не починаєте пустувати там, де вам належить заповнити сторінку на сторінки. І це справді стосується попередніх рішень даних, де ви починаєте з порожнього інструменту, і вам потрібно почати створювати сторінку для всього, що ви хочете документувати.
Оскільки ми документуємо стільки речей автоматично, витягуючи метадані, по суті, протягом декількох днів після встановлення програмного забезпечення, ви можете мати в своєму інструменті уявлення про ваше середовище даних, яке становить щонайменше 80 відсотків. І тоді я думаю, що коли люди починають писати запити за допомогою інструменту, вони автоматично зберігаються назад у каталог, і вони також починають відображатися.
Я не хочу бути надто нетерплячим у заяві про це. Я думаю, що два тижні - це досить хороша консервативна оцінка, до місяця. За два тижні до місяця, консервативна оцінка дійсно обертається і відчуваєш, як ти отримуєш цінність від цього, як ти починаєш ділитися деякими знаннями та бути в змозі піти туди і дізнатися про свої дані.
Dez Blanchfield: Це дуже дивно, насправді, коли ти думаєш про це. Той факт, що деяким з великих платформ даних, які ви ефективно індексуєте та каталогізуєте, іноді потрібно до року, щоб належним чином впровадити та розгорнути та встановити.
Останнє запитання, яке я отримав до вас, перш ніж я передав Робіну Блору, - це з'єднувачі. Однією з речей, яка негайно вискакує на мене, є те, що ти, очевидно, розібрав увесь цей виклик. Тож є кілька питань просто дуже швидко. По-перше, як швидко реалізуються роз'єми? Очевидно, ви починаєте з найбільшої платформи, як-от Oracles і Teradatas і так далі і DB2. Але наскільки регулярно ви бачите нові роз'єми, і який час їх виконання потрібно? Я думаю, ти маєш для них стандартні рамки. І наскільки глибоко ти вникаєш у це? Наприклад, Oracles і IBM світу, і навіть Tereadata, а потім деякі більш популярні пізні платформи з відкритим кодом. Вони безпосередньо працюють з вами? Ви самі це відкриєте? Чи потрібно мати знання про ці платформи?
Як виглядає, як розробити роз'єм і наскільки глибоко ви залучитесь до цих партнерств, щоб забезпечити виявлення цих роз'ємів всього, що можливо?
Девід Крофорд: Так, звичайно, це чудове питання. Я думаю, що здебільшого ми можемо розробити роз’єми. Ми, звичайно, робили, коли ми були молодшими стартапами і не мали клієнтів. Ми можемо розвивати з'єднання, безумовно, не потребуючи внутрішнього доступу. Ми ніколи не отримуємо спеціального доступу до систем даних, які не є загальнодоступними та часто не потребують внутрішньої інформації. Ми користуємося послугами метаданих, доступними самими системами даних. Часто вони можуть бути досить складними і з ними важко працювати. Зокрема, я знаю SQL Server, яким чином вони керують журналом запитів, є декілька різних конфігурацій та щось, над чим вам дійсно потрібно працювати. Ви повинні зрозуміти нюанси, ручки та циферблати на ньому, щоб правильно їх налаштувати, і це те, над чим ми працюємо з клієнтами, оскільки ми це робили кілька разів раніше.
Але певною мірою - це їхні види доступних публічних API, або доступні публічні інтерфейси, якими ми користуємось. Ми маємо партнерські стосунки з декількома з цих компаній, і це здебільшого є підставою для сертифікації, щоб вони почували себе комфортно, кажучи, що ми працюємо, а також вони можуть надати нам ресурси для тестування, іноді - раннього доступу, можливо, до платформи, яка виходить, щоб переконатися, що ми працюємо над новими версіями.
Щоб перетворити нове з'єднання, я повторю, намагаючись бути консервативним, скажімо, від шести тижнів до двох місяців. Це залежить від того, наскільки вона схожа. Тож деякі з Postgre мають вигляд дуже схожий на Redshift. Redshift та Vertica діляться безліччю своїх деталей. Тож ми можемо скористатися цими речами. Але так, від шести тижнів до двох місяців було б справедливо.
У нас також є API, так що - ми вважаємо Alation також платформою метаданих, тож, якщо будь-які речі, недоступні для нас, щоб дістатись і автоматично захопити, є способи, щоб ви могли самостійно написати роз'єм і засунути його в нашу систему що все ще централізується в одній пошуковій системі.
Dez Blanchfield: Фантастичний. Я ціную це. Тож збиралися передати це Робіну, бо я впевнений, що у нього також є безліч питань. Робін?
Ребекка Йозвяк: Робін може бути без звуку.
Dez Blanchfield: Ви потрапили на глухий звук.
Робін Блор: Так, це правда. Вибачте, я проігнорував себе. Коли ви реалізуєте це, що це за процес? Мені цікаво, бо в багатьох місцях може бути багато даних. То як це працює?
Девід Крофорд: Так, звичайно. Ми вступаємо, спочатку це свого роду ІТ-процес, щоб переконатися, що наші сервери забезпечені, переконавшись, що мережеві з'єднання доступні, що порти відкриті, щоб ми могли фактично отримати доступ до систем. Всі вони часто знають, з яких систем хочуть почати. Знаючи всередині системи передачі даних, що - а іноді ми і справді їм допоможемо. Ну допоможіть їм пройти початковий перегляд журналу запитів, щоб зрозуміти, хто використовує, що і скільки користувачів у них в системі. Тож добре допоможіть дізнатися, де - вони часто, якщо у них є сотні чи тисячі людей, які можуть увійти до баз даних, вони насправді не знають, де вони входять, тому ми можемо дізнатися з журналів запитів, скільки унікальних облікових записів користувачів ви фактично входите в систему і виконуєте запити тут протягом місяця або близько того.
Тож ми можемо цим скористатися, але часто лише на найважливіших. Ми налаштовуємо їх, і тоді відбувається процес сказання: "Дайте пріоритет". Існує ряд видів діяльності, які можуть відбуватися паралельно. Я б зосередився на навчанні використання інструменту запиту. Як тільки люди починають використовувати інструмент запитів, насамперед, багато людей люблять той факт, що це лише єдиний інтерфейс для всіх їх різних систем. Вони також люблять те, що його веб-версія не передбачає встановлення, якщо вони цього не хочуть. З точки зору безпеки, їм подобається мати єдину точку входу, з точки зору мережі, між різновидом корпоративної ІТ-мережі та центром обробки даних, де живуть виробничі джерела даних. Отже, вони встановлюють Alation як інструмент запитів і починають використовувати Compose як точку доступу для всіх цих систем.
Отже, коли це трапиться, те, на чому ми зосереджуємось на навчанні, - це розуміння, які існують деякі відмінності між веб-інструментом або серверним інструментом запитів від одного, який ви маєте на своєму робочому столі, та деякі нюанси його використання. І в той же час, що добре намагатися зробити, це визначити найцінніші дані, знову скориставшись інформацією журналу запитів і сказавши: «Ей, ви можете зайти і допомогти людям зрозуміти це. Давайте почнемо публікувати репрезентативні запити на цих таблицях ». Це іноді найефективніший спосіб швидко змусити людей розкручуватися. Давайте переглянемо власну історію запитів, опублікуємо ці речі, щоб вони відображалися як перші запити. Коли люди переглядають сторінку таблиці, вони можуть бачити всі запити, які торкалися цієї таблиці, і вони можуть починати звідти. А потім давайте почнемо додавати заголовки та описи до цих об’єктів, щоб їх було легше знаходити та шукати, щоб ви знали деякі нюанси того, як ним користуватися.
Ми переконуємося, що ми ретельно вивчаємо журнал запитів, щоб ми могли генерувати походження. Одне з тих, що ми робимо, - це переглядати журнал запитів у часи, коли дані переміщуються з однієї таблиці в іншу, і це дозволяє нам ставити одне з найбільш часто заданих питань щодо таблиці даних, звідки це взялося? Як я їй довіряю? І тому, що ми можемо показати, це не тільки з яких інших таблиць, з яких вона вийшла, але і як вона трансформувалася по дорозі. Знову ж таки, це працює на основі журналу запитів.
Таким чином, ми переконуємося, що ці речі налаштовані і набирали в систему рядки, і націлювали на найцінніші та найвищою мірою використані фрагменти метаданих, які ми можемо встановити на сторінках таблиці, так що під час пошуку, ви знаходите щось корисне.
Робін Блор: Добре. Інше питання - це багато запитань від аудиторії, тому я не хочу займати тут занадто багато часу - інше питання, яке спадає на думку, це лише больові моменти. Багато програмного забезпечення, купленого через те, що люди так чи інакше мають труднощі. То що спільна больова точка, яка веде людей до Алації?
Девід Крофорд: Так. Я думаю, що їх небагато, але я думаю, що одним із тих, кого ми чуємо досить часто, є аналітик на борту. "Мені потрібно буде найняти 10, 20, 30 людей найближчим часом, яким доведеться отримувати нові дані з цих даних, як вони будуть швидко розвиватися?" Тож аналітик на борту - це те, з чим ми неодмінно вирішуємось. Терес також просто позбавляє старших аналітиків витрачати весь свій час на відповіді на запитання інших людей щодо даних. Це теж дуже часто. І те, і інше - це проблеми освіти.
І тоді я б сказав, що ми бачимо, що люди приймають Alation, коли вони хочуть створити абсолютно нове середовище даних для того, щоб хтось працював. Вони хочуть рекламувати та продавати це внутрішнє, щоб люди могли ним скористатися. Тоді зробити Alation передовою до цього нового аналітичного середовища дуже привабливо. У нього потрапила документація, вона отримала єдину точку ознайомлення з - єдиною точкою доступу до систем, і так, це ще одне місце, куди люди приїдуть до нас.
Робін Блор: Гаразд, я передам вас до Ребеки, тому що аудиторія намагається дістатися до вас.
Ребекка Йозвяк: Так, у нас тут дуже багато справжніх питань аудиторії. А Давид, цей був поставлений саме вам. Це від того, хто, мабуть, має певний досвід роботи з людьми, який неправильно запитує, і він каже, що чим більше ми надаємо користувачам, тим важче керувати відповідальним використанням обчислювальних ресурсів. То чи можете ви захищатися від поширення помилкових, але поширених запитів?
Девід Крофорд: Так, я бачу це питання. Це велике запитання - таке ми отримуємо досить часто. Я бачив біль у попередніх компаніях, де потрібно навчати користувачів. Наприклад, "Це таблиця журналів, її журнали повертаються роками. Якщо ви збираєтесь написати запит у цю таблицю, вам дійсно доведеться обмежити дату ». Так, наприклад, це навчання, яке я пройшов у попередній компанії, перш ніж мені було надано доступ до бази даних.
У нас є кілька способів вирішити це. Я б сказав, що я думаю, що дані журналу запитів справді унікально цінні для їх вирішення. Це дає ще одне уявлення про те, що база даних робить внутрішньо зі своїм планувальником запитів. І що ми робимо, це одне з таких втручань - у нас є ручні втручання, які я показав, і це корисно, правда? Так, наприклад, при певному приєднанні, ви можете сказати: "Давайте знеструмлюємо це". У ньому буде великий червоний прапор, коли він відображається у розумній пропозиції. Тож ось один із способів намагатися дістатись до людей.
Інша річ, яку ми робимо, - це автоматизовано під час виконання втручань. Thatll насправді використовує дерево розбору запиту, перш ніж ми його запустимо, щоб побачити, чи включає він певний фільтр або пару інших речей, які ми також робимо там. Але одна з найцінніших і найпростіших, що пояснюється, - це включає фільтр? Отож, як у тому прикладі, який я щойно подав, у цій таблиці журналів, якщо ви збираєтеся запитувати його, повинен бути діапазон дат, ви можете вказати на сторінці таблиці, що вам призначено застосувати цей фільтр діапазону дат. Якщо хтось спробує запустити запит, який не включає цей фільтр, він насправді зупинить їх з великим попередженням, і він скаже: "Ви, ймовірно, повинні додати у свій запит деякий SQL, схожий на це". Вони можуть продовжувати, якщо хочуть . Насправді вони не забороняли їм повністю використовувати його - його запит теж повинен був, зрештою, виконувати запити. Але ми ставимо перед ними досить великий бар'єр, і ми даємо їм пропозицію, конкретну застосовну пропозицію, щоб змінити запит, щоб покращити їхню ефективність.
Ми також це робимо автоматично в деяких випадках, знову ж таки спостерігаючи за журналом запитів. Якщо ми бачимо, що деякі дійсно великі відсотки запитів у цій таблиці користуються певним фільтром або певним пунктом приєднання, то насправді це з’являється. Добре сприяти цьому до втручання. Насправді це сталося зі мною на внутрішньому наборі даних. У нас є дані клієнтів і у нас є ідентифікатори користувачів, але ідентифікатор користувача встановлений, оскільки його тип - ми маємо ідентифікатори користувачів у кожного клієнта. Це не унікально, тому вам доведеться поєднати його з ідентифікатором клієнта, щоб отримати унікальний ключ з'єднання.І я писав запит, і я спробував щось проаналізувати, і він з’явився, і сказав: «Ей, всі інші, здається, приєднуються до цих таблиць і з ідентифікатором клієнта, і з ідентифікатором користувача. Ви впевнені, що не хочете цього робити? "І це насправді заважало мені робити некоректний аналіз. Таким чином, це працює як для точності аналізу, так і для продуктивності. Отже, таким чином ми приймаємо цю проблему.
Ребекка Йозвяк: Мені це здасться ефективним. Ви сказали, що не будете обов'язково перешкоджати людям забирати ресурси, але навчите їх тому, що те, що вони роблять, може бути не найкращим, правда?
Девід Крофорд: Ми завжди вважаємо, що користувачі не є злісними - дайте їм найкращі наміри - і ми намагаємось бути таким чином відкритим.
Ребекка Йозвяк: Добре. Ось ще одне питання: «Яка різниця між менеджером каталогу, як, наприклад, від вашого рішення, та інструментом MDM? Або він насправді покладається на інший принцип, розширюючи вибір таблиць запитів, тоді як MDM зробить це автоматично, але з тим самим основним принципом збирання метаданих ".
Девід Крофорд: Так, я думаю, що, дивлячись на традиційні рішення МДМ, головна відмінність - філософська. Все про те, хто такий користувач. Такий, як я сказав на початку своєї презентації: Алація, я думаю, що коли ми були засновані, ми були засновані з метою дати аналітикам можливість робити більшу інформацію, швидше їх виробляти, бути точнішими в розумінні того, що вони виробляти. Я не думаю, що це колись було метою традиційного рішення МДМ. Ці рішення, як правило, орієнтовані на людей, яким необхідно складати звіти про те, які дані були захоплені до ДМС або внутрішньо для будь-якого іншого типу аудиту. Іноді це може дозволити аналітикам, але частіше, якщо він буде дозволити практикуючим практикам у своїй роботі, більше шансів включити архітектора даних, як DBA.
Якщо ви думаєте про речі з точки зору аналітика, саме тоді ви починаєте створювати інструмент запитів, який MDV-інструмент ніколи не робив би. Це коли ти починаєш думати про ефективність та точність, а також розумієш, які дані стосуються потреб мого бізнесу. Все це - речі, які начебто попсуються в нашій свідомості, коли ми розробляємо інструмент. Це входить в наші алгоритми пошуку, вкладається в макет сторінок каталогу та можливість внести знання з усієї організації. Це полягає в тому, що ми побудували інструмент запитів і що ми вбудували каталог безпосередньо в нього, тому я думаю, що це насправді випливає з цього. З яким користувачем ви спочатку пам’ятаєте?
Ребекка Йозвяк: Добре, добре. Це справді допомогло пояснити це. хто вмирав, щоб отримати сховище за архів, тому що йому довелося виїхати, але він дуже хотів, щоб його питання відповів. Він сказав, що на початку згадувалося, що існує кілька мов, але чи є SQL єдиною мовою, що використовується в компоненті Compose?
Девід Крофорд: Так, це правда. І одна з речей, яку я помітив, коли я був свідком вибуху різних типів баз даних, баз даних документів, баз даних графіків, ключових сховищ, - це те, що вони справді потужні для розробки додатків. Вони можуть обслуговувати конкретні потреби дійсно добре, кращими способами, ніж можуть реляційні бази даних.
Але коли ви повертаєте його до аналізу даних, коли ви повертаєтесь до нього - коли ви хочете надати цю інформацію людям, які збираються робити спеціальні звіти чи спеціальні копання даних, вони завжди повертаються до реляційних даних , принаймні, інтерфейс для людей. Частина цього лише тому, що SQL є мовою аналізу даних, так що для людей це означає і для інструментів, що інтегруються. Я думаю, що це причина того, що SQL на Hadoop настільки популярний і існує стільки спроб вирішити його, це тому, що в кінці дня це те, що люди знають. Напевно, є мільйони людей, які вміють писати SQL, і я б ризикнув не мільйони, які знають, як написати рамковий запит конвеєрного конвеєра Монго. І це стандартна мова, яка використовується для інтеграції на дуже широкому спектрі платформ. Тому все, що говориться, дуже рідко просили виходити за межі нього, оскільки саме цей інтерфейс використовується більшості аналітиків, і це місце, де ми зосередилися, особливо в Compose, і ми зосередилися на написанні SQL.
Я б сказав, що наукові дані - це місце, де вони працюють більше за все, і тому у нас виникають запитання щодо використання Pig або SAS. Це речі, з якими ми точно не розбираємося у Compose, і які ми хотіли б зафіксувати у каталозі. І я бачу також R та Python. У нас є декілька способів, за допомогою яких ми створили інтерфейси, за допомогою яких можна використовувати запити, написані в Alation всередині сценаріїв R та Python, тому, часто, коли ви є вченим-даними та працюєте на мові скриптів, ваші вихідні дані знаходяться у реляційних даних база даних. Ви починаєте з SQL запиту, а потім обробляєте його далі і створюєте графіки всередині R та Python. І ми створили пакети, які ви можете імпортувати в ті сценарії, які витягують запити або результати запиту від Alation, щоб ви могли там мати змішаний робочий процес.
Ребекка Йозвяк: Гаразд, чудово. Я знаю, що ми пробігаємо трохи повз вершину години, я просто збираюся задати ще один-два запитання. Я знаю, що ви говорили про всі різні системи, до яких можна підключитися, але що стосується даних, розміщених на зовнішньому рівні та даних, розміщених на внутрішньому рівні, чи можна їх спільно шукати у вашому єдиному представленні, на вашій єдиній платформі?
Девід Крофорд: Звичайно. Є кілька способів зробити це. Я маю на увазі, зовні я б хотів уявити, що я намагаюся думати про те, що це може означати. Це може означати базу даних, яку хтось розміщує для вас в AWS. Це може означати загальнодоступне джерело даних з data.gov. Ми підключаємося безпосередньо до баз даних, входячи так само, як і інша програма, з обліковим записом баз даних, і таким чином ми витягуємо метадані. Тож якщо у нас є обліковий запис і відкритий мережевий порт, ми можемо дістатись до нього. І тоді, коли у нас немає таких речей, у нас є щось, що називається віртуальним джерелом даних, що дозволяє вам по суті наштовхувати документацію, будь то автоматично, написавши власний роз'єм або заповнивши його, виконавши навіть як завантаження CSV, щоб документувати дані поряд із вашими внутрішніми даними. Це все поміщається в пошукову систему. Це стає посилається на статті та іншу документацію та бесіди всередині системи. Тож ми маємо справу, коли не можемо безпосередньо підключитися до системи.
Ребекка Йозвяк: Гаразд, це має сенс. Я просто розстрілюю ще одне питання до вас. Один учасник - це запитуючи: "Як слід перевіряти, перевіряти чи підтримувати вміст каталогу даних, як оновлення вихідних даних, як змінені вихідні дані тощо"
Девід Крофорд: Так, це питання ми отримуємо багато, і я думаю, що одна з речей, що ми - одна з наших філософій, як я вже сказав, ми не віримо, що користувачі шкідливі. Ми припускаємо, що вони намагаються внести найкращі знання. Вони не збираються заходити і навмисно вводять людей в оману щодо цих даних. Якщо це проблема у вашій організації, можливо, відносини не є правильним інструментом для вас. Але якщо ви приймаєте на себе добрі наміри з боку користувачів, то ми думаємо про це як про щось, де надходять оновлення, і тоді, як правило, ми робимо управителя, відповідаючи за кожен об'єкт даних або кожен розділ даних. І ми можемо сповістити цих управителів, коли будуть внесені зміни в метадані, і вони можуть обробляти це таким чином. Вони бачать оновлення, які надходять, перевіряють їх. Якщо вони не мають рації, вони можуть повернутися назад, змінити їх та повідомити, і, сподіваємось, навіть зв’язатися з користувачем, який надав інформацію та допоможе їм дізнатися.
Отже, це основний спосіб, коли ми думаємо про це. Це така пропозиція з боку натовпу та управління стюардами, тому у нас є певні можливості.
Ребекка Йозвяк: Так добре. І якщо ви можете просто повідомити людям, як найкраще розпочати роботу з Alation, і куди вони можуть піти конкретно, щоб отримати більше інформації. Я знаю, ви поділилися цим одним bit.ly. Це найкраще місце?
Девід Крофорд: Alation.com/learnmore Я думаю, що це прекрасний шлях. Щоб підписатися на демонстрацію, на сайті Alation.com є багато чудових ресурсів, довідки клієнтів та новини про наше рішення. Тому я думаю, що це чудове місце для початку. Ви також можете .
Ребекка Йозвяк: Гаразд, чудово. І я знаю, відвідувачі, вибачте, якщо я не потрапив на всі запитання сьогодні, але якщо ні, вони будуть переслані Девідові або його торговій команді чи комусь із Alation, тож вони напевно можуть допомогти відповісти на ваші запитання та допомогти зрозуміти, що таке Alation робить або що їм найкраще.
І з цим, люди, я піду підписати нас. Ви завжди можете знайти архіви на сайті InsideAnalysis.com. Ви також можете знайти його на Techopedia.com. Вони, як правило, оновлюються трохи швидше, тому обов'язково перевірте це. І сьогодні дуже дякую Девіду Крофорду, Дез Бланчфілду та Робіну Бор. Це була чудова трансляція. І з цим я прощаюсь. Спасибі, люди. Бувай.
Девід Крофорд: Дякую.