От персонала на Техопедия, 22 юни 2016 г.
Отнемане: Домакинът Ребека Йозвяк обсъжда предимствата на каталозите с данни с Dez Blanchfield, Robin Bloor и David Crawford.
Трябва да се регистрирате за това събитие, за да видите видеоклипа. Регистрирайте се, за да видите видеото.
Ребека Йозвяк: Дами и господа, привет и добре дошли в горещите технологии на 2016 г. Днес ние имаме „Силата на предложението: Как един каталог на данни дава възможност на анализаторите.“ Аз съм вашият домакин Ребека Йозвяк, попълвайки обичайния ни домакин Ерик Kavanagh днес, докато пътува по света, така че ви благодаря, че се присъединихте към нас. Тази година е гореща, не е просто горещо в Тексас, където съм, но е горещо навсякъде. Избухва експлозия от всевъзможни нови технологии. Имаме IoT, стрийминг на данни, приемане на облаци, Hadoop продължава да узрява и да се приема. Разполагаме с автоматизация, машинно обучение и всичко това е разбира се подчертано от данните. И предприятията стават все повече и повече данни, задвижвани от деня. И разбира се, смисълът от това е да доведе до знание и откриване и, разбирате ли, да вземете по-добри решения. Но за да получите наистина максимална стойност от данните, трябва да е лесно да стигнете. Ако го държите затворен далеч или погребан или в мозъка на няколко души в предприятието, няма да донесе много полза за предприятието като цяло.
И аз мислех за каталогизиране на данни и мислене за разбира се библиотеки, където отдавна там отидохте, ако трябва да откриете нещо, ако трябва да проучите тема или да потърсите някаква информация, отидохте в библиотеката и, разбира се, отидохте в каталога на картичките или на краби дамата, която работеше там. Но също така беше забавно да се лутате наоколо, ако просто искате да погледнете и сте сигурни, че просто ще откриете нещо изрядно, може да разберете някои интересни факти, които не сте знаели, но ако наистина трябва да намерите нещо и знаехте какво търсите, имате нужда от картовия каталог и разбира се, фирменият еквивалент е каталог на данни, който може да помогне да осветява всички данни за нашите потребители, за да обогатяват, откриват, споделят, консумират и наистина помагат хората стигат до данните по-бързо и по-лесно.
И така, днес имаме Дез Бланчфийлд, наш учен с данни, и имаме доктор Робин Блур, наш главен анализатор, имаме Дейвид Крофорд от Alation, който ще говори за историята на каталога на данните на неговата компания, но първо ще водим с Дез. Дез, предавам топката при теб и пода е твой.
Дез Бланчфийлд: Благодаря, благодаря, че ме прие днес. Това е въпрос, който ме интересува изключително много, тъй като почти всяка организация, на която се натъквам в ежедневната си работа, намирам точно същия въпрос, за който говорихме съвсем накратко в лентата за предварително шоу и това е това повечето организации, които работят повече от няколко години, имат множество данни, погребани около организацията, различни формати и всъщност имам клиенти, които имат набори от данни, които се връщат към Lotus Notes, бази данни, които все още работят в някои случаи като техен псевдосети и всички те се сблъскват с това предизвикателство да намерят къде точно са техните данни и как да получат достъп до тях, кой да им предостави достъп, кога да им предоставят достъп и как просто каталог и как да го стигнете до място, където всеки може: A) да сте наясно какво има и какво има в него, и B), как да получите достъп до него и да го използвате. И едно от най-големите предизвикателства, разбира се, е да го намериш, другото голямо предизвикателство е да знаеш какво има там и как да получиш достъп до него.
Може би знам, че имам десетки бази данни, но всъщност не знам какво има там или как да разбера какво има там и така неизменно, както откриваме сега в данните преди показването, да се разхождам из офиса и да задавам въпроси и да крещя през кубичните стени и да пробвам и да разбера, често моят опит е, че дори може да откриете, че се скитате на рецепцията, на рецепцията и питате дали някой знае кой ще отидеш да говориш. Доста често това не винаги е ИТ фолк, тъй като те не знаят за набора от данни, защото някой просто го е създал, и може да е нещо просто като - доста често ще намерим някакъв проект, който да стои в IT среда и ръководителят на проекта е използвал електронна таблица с всички неща и е получил огромно количество ценна информация около активи и контекст и имена, и освен ако не знаете този проект и не познавате този човек, просто не можете да намерите тази информация. Просто не е налице и трябва да се захванете с този оригинален файл.
Има една фраза, която е разпръсната наоколо по отношение на данните и не е задължително да се съглася с тях, но мисля, че това е малко сладко изхвърляне и това е, че определено количество хора смятат, че данните са новото масло, и аз съм със сигурност ще покрием това и в някакъв аспект, по-късно днес. Но това, което забелязах и със сигурност е част от тази трансформация, е, че организации на предприятия, които са се научили да оценяват своите данни, са спечелили значително предимство пред своите конкуренти.
Преди около пет или шест години имаше интересен документ от IBM и те проучиха около 4000 компании тук, в Австралия, и взеха цялата информация, всички данни за резултатите, всички финансови данни и я събраха в кипящ съд и след това изпратиха го до Австралийското училище по икономика и те всъщност започнаха обща тенденция тук, а това беше, че компаниите, които се възползват от технологиите, неизменно получават толкова конкурентно предимство пред своите връстници и конкуренти, че техните конкуренти почти никога не ги настигат и мисля, това е много така сега с данните, които видяхме това, което хората наричат дигитална трансформация, където организации, които ясно са измислили как да намерят данните, които имат, да направят тези данни достъпни и да ги направят достъпни в някои много лесни консумативи мода за организацията, без непременно винаги да знае защо организацията може да се нуждае от това и да спечели значително предимство пред конкурентите.
Имам няколко примера на този слайд, който можете да видите. Единственият ми ред е, че според мен мащабните смущения в почти всеки индустриален сектор се ръководят от данни и ако сегашните тенденции продължават да се случват, моето мнение е, че ние наистина наистина просто сме получили започна, защото когато дългогодишните марки най-накрая се събудят какво означава това и влязат в играта, те ще влязат в играта на едро. Когато вид на големите търговци на дребно, които имат планина от данни, започнат да прилагат исторически анализ на данните, ако дори знаят, че съществуват, тогава някои от онлайн играчите ще получат малко събуждане.
Но с много от повечето от тези марки, искам да кажа, че имаме Uber, които са най-голямата таксиметрова компания в света. Те не притежават никакви таксита, така че какво ги прави вълшебни, какви са техните данни? Airbnb, най-големият доставчик на места за настаняване, имаме WeChat, най-голямата телефонна компания в света, но те нямат реална инфраструктура, нито телефони, нито телефонни линии. Alibaba, най-големият търговец на дребно на планетата, но те не притежават нито един от инвентара. Facebook, най-голямата медийна компания в думата. Мисля, че при последното броене те имаха 1, 4 милиарда активни потребители на данни сега, което е умопомрачително число. Не е никъде близо - мисля, че някой твърди, че една четвърт от планетата всъщност е там всеки ден, но въпреки това е доставчик на съдържание, който всъщност не създава съдържанието, всички данни, които обслужват, не са създадени от тях, а са създадени от техните абонати и всички познаваме този модел.
SocietyOne, за който може би или не сте чували, това е местна марка, мисля, че в няколко държави това е банка, която всъщност прави партньорско кредитиране, така че с други думи, няма пари. Всичко, което прави, е да управлява транзакциите и данните са разположени под него. Netflix, всички сме много, много добре запознати с това. Тук има интересен еднолинейник. Когато Netflix законно можеше да бъде използван в Австралия, когато беше официално обявено, не е трябвало да използвате VPN, за да стигнете до него, много хора по света са склонни - ако не можете да стигнете до него в местния си район - когато Netfix стартира в Австралия, той увеличи международната честотна лента на нашите интернет връзки с 40 процента, така че почти удвои използването на интернет в Австралия за една нощ, само с едно приложение, едно облачно хоствано приложение, което не прави нищо друго освен игра с данни. Това е просто умопомрачителна статистика.
И разбира се, всички сме запознати с Apple и Google, но това са най-големите софтуерни фирми на планетата, но всъщност те не пишат приложенията. Какво е съвместимото с всички тези организации? Е, това са данни и те не стигнаха до там, защото не знаеха къде са данните им и не знаеха как да ги катализират.
Това, което сега откриваме, е, че съществува този нов клас активи, наричан данни, и компаниите се събуждат от него. Но те не винаги разполагат с инструменти и ноу-хау и поради това да картографират всички тези данни, да катализират всички тези данни и да ги предоставят, но открихме, че компаниите с почти никакви физически активи не са получили висока пазарна стойност в записва време чрез този нов клас активи на данни. Както вече казах, някои от старите играчи се събуждат за това и със сигурност го извеждат.
Аз съм голям почитател да поемам хора на малко пътуване, така че в осемнадесетте стотици, края на осемнадесетте стотици и вие ще бъдете повече от запознати с това на американския пазар, се оказа, че за провеждане на преброяване всяка година или около това, мисля, че в този момент те са ги провеждали на всеки десет години, но ако ще провеждате преброяване всяка година, може да ви отнеме до осем или девет години, за да направите всъщност анализа на данните. Оказа се, че след това този набор от данни се оставя на кутии на места на хартия и почти никой не може да го намери. Те просто продължиха да изпомпват тези доклади, но действителните данни бяха много трудни за достигане, имаме подобна ситуация и с друг световно значим момент, около 40-те години, с Втората световна война, и това нещо е Blechley Park Bombe, изписано BOMBE, и това беше масивен аналитичен инструмент за съкращаване на числата, който щеше да преминава през малки масиви данни и да намира сигнали в него и да се използва за подпомагане на пробиване на кодове чрез Enigma.
Това нещо отново беше по същество устройство, създадено, не много да каталогизира, но да маркира и картографира данни и дава възможност да се вземат модели и да ги намерят вътре в наборите от данни, в този случай разбийте кодове, намерете ключове и фрази и намерете те редовно в наборите от данни и затова преживяхме това пътуване да намерим нещата в данните и да водим към каталогизиране на данни.
И тогава се появиха тези неща, тези масивни нискотарифни стелажи с машини, просто нестандартни машини. И направихме няколко много интересни неща и едно от нещата, които направихме с тях е, че изградихме много ниски разходи, които биха могли да започнат да индексират планетата, и много известни са тези големи марки, които идват и си отиват, но вероятно Google е най-често срещаният дом марка, за която всички сме чували - тя се превръща в действителен глагол и знаете, че сте успешни, когато марката ви се превърне в глагол. Но това, което Google ни научи, без да го осъзнаваме, вероятно в света на бизнеса, е, че те успяха да индексират цялата планета до определено ниво и да катализират данните, които бяха по целия свят, и да ги направят достъпни за много лесно, удобна форма в малко мъничка едноредова формула, уеб страница с почти нищо върху нея и въвеждате заявката си, тя отива и я намира, защото те вече бяха обходили планетата, индексираха я и я направиха лесно достъпна.
И това, което забелязахме, беше: „Е, оставете се, ние не правим това в организации - защо е така? Защо имаме организация, която може да картографира цялата планета и да я индексира, обхожда и индексира и я предоставя на разположение, можем да я търсим и след това щракнете върху нещата, за да я намерите и да я намерите, как така не са го правили вътрешно? "Така че сега има много от тези малки стелажи с машини, които правят това за интранети и намират неща, но те все още просто се справят с идеята да надхвърлят традиционната мрежа страница или файлов сървър.
Вместо сега да влезете в това следващо поколение каталог на данни по много начини, откриването на достъп до данни чрез бележки след него и разговори с охладител за вода всъщност вече не е подходящ метод за откриване и каталогизиране на данни, и всъщност не мисля, че никога наистина беше. Вече не можем да водим цялото това предизвикателство към хората, които просто правят бележки, публикуват бележки и чатят за него. Ние сме добре и наистина отвъд областта, в която този подход от следващото поколение към каталогизирането на данни се появи и изчезна. Трябва да го прегърнем. Ако това беше лесен проблем, вече щяхме да го разрешим по много начини по-рано, но мисля, че не е лесен проблем, само индексирането и извикването на данните е само една част от него, като знаем какво има в данните и изграждане на метаданни около това, което откриваме, и след това предоставянето им на разположение в лесна, консумативна форма, особено за самообслужване и анализи. Все още проблемът се решава, но много части от пъзела за пет години са добре и наистина решени и налични.
Както знаем, хората, които катализират данни, са рецепта за провал, защото човешката грешка е един от най-големите кошмари, с които се справяме при обработката на данни, и аз редовно говоря по тази тема, където според мен хората, попълващи хартиени формуляри, вероятно са най-големият кошмар ние се занимаваме с големи данни и аналитични данни, като постоянно трябва да поправяме нещата, които правят, дори до прости неща като дати и полета, като хората го поставят в грешен формат.
Но както казах, виждаме интернет търсачките да индексират света всеки ден, така че сега го правим на идеята, че това може да се направи на набори от бизнес данни в процеса на откриване, а инструментите и системите вече са лесно достъпни, тъй като ще се запознаете днес. Така че, по мое мнение, трикът е да изберете правилните инструменти, най-добрите инструменти за работата. И по-подходящо отгоре на това, намирането на правилната част от нея, която да ви помогне да започнете по този път. И вярвам, че днес ще чуем за това, но преди да го направим, ще премина към колежа си Робин Блур и ще чуя неговото приемане по темата. Робин, мога ли да ти предам?
Робин Блур: Да, със сигурност можеш. Нека да видим дали това работи, о, да, това е така. Добре, идвам от различна посока от Dez наистина, но ще свърша на същото място. Тук става въпрос за свързване с данни, така че просто мислех, че ще разгледам реалността на свързването с данни, точка по точка наистина.
Има факт, че данните са по-фрагментирани, отколкото досега. Обемът на данни нараства феноменално, но всъщност различните източници на данни също нарастват с невероятна скорост и следователно данните стават все по-фрагментирани. Но поради по-специално приложенията за анализи - но те не са единствените приложения - имаме наистина основателна причина да се свържем с всички тези данни, така че сме останали на трудно място, заседнали сме в свят на фрагментирани данни, и има възможност в данните, както го наричаше Dez, новото масло.
За данните, добре, че се използваше на въртящ се диск, или във файлови системи, или в бази данни. Сега той живее в много по-разнообразна среда, той живее във файлови системи, но също така живее в случаите на Hadoop в днешно време или дори в Spark случаи. Живее в множество видове база данни. Не толкова отдавна, ние стандартизирахме някаква релационна база данни, добре знаете, че излязоха през прозореца през последните пет години, защото има нужда от бази данни, и има нужда от графични бази данни, така че знаете, играта има променило. Така че живееше на въртящ се диск, но сега живее на SSD. Най-новото количество SSD - определено най-новото SSD устройство излиза от Samsung - двадесет гигабайта, което е огромно. Сега той живее в паметта, в смисъл, че основното копие на данни може да бъде в паметта, а не на диск, ние не използвахме за изграждането на такива системи; правим сега. И живее в облака. Което означава, че може да живее във всяко от тези неща, в облак, не е задължително да знаете къде е в облак, ще имате само неговия адрес.
Точно до момента, в който Hadoop се върна, не успя да се превърне в разширителен магазин за данни. Надявахме се, че той ще се превърне в разширяващ се мащабен мащаб на данни и просто ще се превърне в една файлова система за всичко и щеше - дъгите ще се появят на небето, а основно еднорозите ще танцуват наоколо и нищо от това не се случи. Което означава, че в крайна сметка имаме проблем с транспортирането на данни, а понякога няма нужда от транспорт на данни, но също така е и трудност. Данните наистина имат гравитация в наши дни, след като сте попаднали в мулти терабайти от данни, събирането им и хвърлянето им, вид причини да се появят латентности във вашата мрежа или да се появяват на различни места. Ако искате да транспортирате данни наоколо, времето е фактор. Понастоящем почти винаги има ограничения за това колко време разполагате, за да получите едно нещо, една информация от едно място на друго. Имаше нещо, което сме мислили за пакетни прозорци, когато машината е била бездействаща и без значение колко данни имате, можете просто да я хвърлите и всичко ще се получи. Ами това го няма, живеем в много по-свят в реално време. Следователно времето е фактор. Веднага щом искате да преместите данни, така че ако данните имат гравитация, вероятно не можете да ги преместите.
Управлението на данните е фактор в смисъл, че всъщност трябва да управлявате всички тези данни, не ги получавате безплатно и може да е необходимо репликиране, за да получите действително данните да вършат работата, която трябва да свърши, защото може да не е където и да сте го поставили. Възможно е да няма достатъчно ресурси, за да извърши нормалната обработка на данните. Така данните се репликират и данните се копират повече, отколкото бихте си представили. Мисля, че някой ми каза преди много време, че средният брой данни се възпроизвежда поне два пъти и половина. ESB или Kafka предлагат опция за поток от данни, но в днешно време тя изисква архитектура. В днешно време наистина трябва да мислите по един или друг начин, какво всъщност означава да хвърляте данните. Следователно обикновено е за предпочитане достъпът до данни там, където се намират, стига, разбира се, да можете да постигнете необходимата ефективност, когато действително отидете за данните и това зависи от контекста. Така че, така или иначе е трудна ситуация. По отношение на заявките за данни, ние бяхме в състояние да мислим по отношение на SQL, ние наистина се появи сега, знаете, различни форми на заявки, SQL да, но съседни, също графични заявки, Spark е само един пример за правим графика, защото също така трябва да направим търсене на текст, повече от всякога, също така да правите регекс тип търсения, което е наистина сложно търсене на модели и истинско съвпадение на шаблони, всички тези неща всъщност се размиват. И всички те са полезни, защото ви получават това, което търсите, или могат да ви получат това, което търсите.
Сега заявките обхващат множество данни, така че не винаги е било така и често работата е ужасяваща, ако го направите. Така че, зависи от обстоятелствата, но хората очакват да могат да заявяват данни от множество източници на данни, така че федерацията на данните от един или друг вид става все по-актуална. Виртуализацията на данни, която е различен начин за това, в зависимост от производителността, също е много често. Въпросите за данни всъщност са част от един процес, а не целият процес. Просто си струва да се отбележи, че ако всъщност гледате на ефективността на аналитиката, реалният анализ може да отнеме доста по-дълго от събирането на данни, защото това зависи от обстоятелствата, но заявките за данни са абсолютно необходима, ако искате да направите каквото и да било вид анализи на множество източници на данни, и то просто, наистина трябва да имате способности, които обхващат.
Така че за каталозите. Каталозите съществуват по някаква причина, поне ние казваме, че, знаете ли, това е, ние имаме директории и имаме схеми в бази данни, и ние имаме всеки каталог, и където и да отидете, ще намерите едно място и тогава всъщност открийте, че има някакъв каталог и унифицираният глобален каталог е толкова очевидно добра идея. Но много малко компании имат такова нещо. Спомням си, че през годината две хиляди - годината две хиляди паника - помня, че комунистите не можеха дори да определят колко изпълними файлове са имали, без значение колко различни хранилища на данни имаха, и вероятно сега е така, знаете, че повечето компании не знаят активно в глобален смисъл какви данни имат. Но очевидно става все по-необходимо всъщност да има глобален каталог или поне да има глобална картина на това, което се случва поради растежа на източниците на данни и непрекъснатия растеж на приложенията, и това е особено необходимо за анализа, защото вие също по един начин и тук има други проблеми като родословие и проблеми с данните и това е необходимо за сигурността, много аспекти от управлението на данните, ако наистина не знаете какви данни имате, идеята че ще управлявате това е просто абсурдно. Така че по този начин всички данни са каталогизирани по някакъв начин е просто факт. Въпросът е дали каталогът е съгласуван и всъщност какво можете да направите с него. Така че ще се върна към Ребека.
Ребека Йозвяк: Добре, благодаря Робин. На следващия път имаме David Crawford от Alation, David, аз ще продължа напред и ще ти предам топката, а ти можеш да я вземеш.
Дейвид Крофорд: Благодаря ви много. Наистина оценявам, момчета, че ме има в това шоу. Мисля, че ще започна това, така че мисля, че моята роля тук е да взема част от тази теория и да видим как тя се прилага в действителност, както и резултатите, които можем да постигнем при реални клиенти и така можете да видите няколко на слайда, искам да говоря за това какви резултати ще можем да видим в аналитичните евентуални подобрения. За да мотивираме дискусията, ще говорим как са стигнали до там. Така че имам късмета да работя доста тясно с много наистина интелигентни хора, тези клиенти, и просто искам да посоча няколко, които са успели да направят реално измерване, и да говоря за това как наличието на каталог на данни е повлияло на техния анализатор работния процес. И само за кратко да останем отпред, мисля, че едно от нещата, които виждаме промяна, със стихове от каталози на данни, предишни медиирани решения и един от начините, по които отношенията наистина мислят за решенията, които сме взели заедно, е да започнем от анализаторите и работите назад. Да кажем, нека направим това за активиране на производителността на анализаторите. За разлика от простото спазване или за разлика от това да разполагаме само с инвентаризация, ние правим инструмент, който прави анализаторите по-продуктивни.
И така, когато разговарям с учен с данни във фирмата за финансови услуги Square, има един човек, Ник, който ни разказваше как неговото, той отне няколко часа, за да намери правилния набор от данни, за да започне отчет, сега той може направете го за няколко секунди, използвайки търсене на пазарен дял, говорихме с техния технически директор, който извади анализаторите му, които използваха Square, извинете ме, използваше Alation, за да разбере какви са техните, какви ползи виждат и те отчитат 50 процентно повишаване на производителността и че един от най-добрите търговци на дребно в света, eBay, имат над хиляда хора, които правят SQL анализ редовно, и аз работя доста тясно с Deb Says там, кой е проектът мениджър в техния екип за инструменти за данни и тя откри, че когато заявките приемат Alation, приемат каталог, те виждат двойно по-бърза скорост на писане на нови заявки срещу базата данни.
Това са реални резултати, това са хора, които действително прилагат каталога в своята организация и искам да ви преведа какво е необходимо, за да се настроите. Как един каталог се установява във фирма и може би най-важното е да се каже, че много от тях се случват автоматично, така че Dez говори за системи, научава се за системи и точно това прави съвременният каталог с данни. Така че те инсталират Alation в своя център за данни и след това го свързват към различни източници на метаданни в тяхната среда за данни. Ще се съсредоточа малко върху базите данни и BI инструментите - и от двете ще извлечем технически метаданни, за основно това, което съществува. Точно така, какви маси? Какви отчети? Какви са дефинициите на отчета? Така те извличат тези технически метаданни и автоматично се създава страница с каталог за всеки обект вътре в тези системи и след това те извличат и слой над тези технически метаданни, а отгоре използват данните за използването. Това се извършва предимно чрез четене на регистрационни файлове на заявките от базата данни и това е наистина интересен източник на информация. И така, всеки път, когато анализатор напише заявка, всеки път, когато инструмент за отчитане, дали се отглежда в домашни условия или извън рафта, дали инструментът за отчитане изпълнява заявка, за да актуализира таблото за управление, когато приложението изпълнява заявка за вмъкване на данни за работа набор от данни - всички тези неща се записват в дневниците на заявките за бази данни. Независимо дали имате каталог или не, те се записват в дневника на заявките с базата данни. Какво може да направи каталогът на данни и по-специално какво може да направи каталогът на Alation, е да прочетете тези регистрационни файлове, да зададете заявките вътре в тях и да създадете наистина интересна графика за използване въз основа на тези регистрационни файлове и ние го въвеждаме в игра, за да информираме бъдещите потребители от данните за това как минали потребители на данните са го използвали.
И така, ние обединяваме всички тези знания заедно в каталог и само за да направим това истинско, това са интеграциите, които вече са внедрени при клиентите, така че видяхме Oracle, Teradata, Redshift, Vertica и още куп други релационни бази данни. В света на Hadoop има гама от SQL за Hadoop, нещо като релационни, мета магазини на върха на файловата система на Hadoop, Impala, Tez, Presto и Hive, ние също сме постигнали успех с облачни Hadoop частни доставчици като Altiscale, и ние също са успели да се свържат със сървърите на Tableau, MicroStrategy и индексират информационните табла там, както и интеграции с графични инструменти за научни данни като Plotly.
И така, ние се свързваме с всички тези системи, свързахме тези системи с клиенти, включихме техническите метаданни, изтеглихме данните за използването и някак си автоматично грундирахме каталога с данни, но по този начин ние централизиране на знанията, но само централизирането на нещата в каталог с данни, само по себе си не осигурява онези наистина чудесни повишения на производителността, за които говорихме с eBay, Square и пазарен дял. За да направим това, всъщност трябва да променим начина, по който мислим за предоставяне на знания на анализаторите. Един от въпросите, които те искат да подготвят за това, беше „Как каталогът действително влияе на работния процес на анализатора?“
Това е, за което прекарваме цял ден в мислене и за да говорим за тази промяна в мисленето, за push стихове за дърпащ модел, исках да направя бърза аналогия с това какъв беше светът преди и след като прочетох на Kindle. Така че това е просто преживяване, което някои от вас може да имат, когато четете физическа книга, попадате на дума, не сте сигурни, че знаете определението на тази дума супер добре, може би може да я познаете от контекста, а не толкова вероятно, че ще се качите от дивана, ще отидете до рафта си с книги, ще намерите речника си, ще го прахте и ще прехвърлите на правилното място в азбучния списък на думите, за да сте сигурни, че, да, вие сте имали това определение точно и знаете нюансите на него. Така че всъщност не се случва. Така че купувате приложението Kindle и започвате да четете книги там и виждате дума, за която не сте напълно сигурен и докосвате думата. Изведнъж, точно в същия този екран, е дефиницията на речника на думата с всичките нюанси, различни примерни употреби и прекарате пръст малко и получавате статия в Уикипедия по тази тема, прекарвате пръст отново, получавате инструмент за превод, който може да го преведе на други езици или от други езици, и изведнъж знанията ви за езика са толкова по-богати и това просто се случва поразителен брой пъти, в сравнение с това, когато трябваше да отидете и издърпайте този ресурс за себе си.
И така, това, което искам да споря, е, че работният процес за анализатор и начинът, по който анализаторът ще се справи с документацията за данни, всъщност е много подобен на това как четецът ще взаимодейства с речника, независимо дали е физически, или въпреки че Kindle и така какво ние, начинът, по който наистина видяхме това повишаване на производителността, не е разпръскването на каталога, а свързването му с работния процес на анализатора и така, те ме помолиха да направя демонстрация тук и аз искам да направят това фокусът на тази презентация. Но просто искам да настроя контекста за демонстрацията. Когато мислим да избутаме знанията за данни към потребителите, когато им трябват, ние смятаме, че подходящото място за това, мястото, където прекарват времето си и където правят анализа, е инструмент за SQL заявки. Място, където пишете и изпълнявате SQL заявки. И така ние изградихме такъв и го изградихме и нещото, което наистина е различно в него от другите инструменти за заявки, е дълбоката му интеграция с каталога с данни.
Така че нашият инструмент за заявки се нарича Alation Compose. Това е уеб-базиран инструмент за заявки и ще ви го покажа след секунда. Уеб базиран инструмент за заявки, който работи във всички онези лога на базата данни, които видяхте на предишния слайд. Това, което ще се опитам да демонстрирам по-специално, е начинът, по който информацията от каталога стига до потребителите. И го прави по тези три различни начина. Това става чрез интервенции и там някой, който е управител на данни, стюард на данни или някакъв администратор по някакъв начин или мениджър, може да каже: „Искам да подредя нещо с бележка или предупреждение в работния процес и се уверете, че е доставен на потребителите в точното време. ”Така че това е интервенция и ние ще покажем това.
Интелигентните предложения са начин, при който инструментът използва всичките си обобщени познания за каталога, за да предлага обекти и части от заявка, докато го пишете. Най-важното нещо, което трябва да знаете там, е, че наистина се възползва от дневника на заявките, за да направи това, да предложи неща, базирани на използване, както и да намери дори части от запитвания, които са били написани преди. И ще покажем това.
И след това визуализации. Прегледът е, докато пишете в името на обект, ние ви показваме всичко, което каталогът знае, или поне най-подходящите неща, които каталогът знае за този обект. Така че извадки от данните, които са го използвали преди, логическото име и описание на този обект, всички стигат до вас, докато го пишете, без да е необходимо да го търсите.
Така че без повече да говоря, ще стигна до демонстрацията и просто ще чакам да се появи. Това, което ще ви покажа тук, е инструментът за запитвания. Това е специален интерфейс за писане на SQL. Това е отделен интерфейс от каталога, в определен смисъл. Дез и Робин говориха за каталога и аз прескачам малко по интерфейса на каталога направо как се въвежда директно, за да обслужва работния процес.
Само показвам тук място, където мога да напиша SQL, а най-отдолу ще видите, че имаме някаква информация за обектите, които препращаме. Така че просто ще започна да пишете заявка и ще спра, когато стигна до една от тези интервенции. Така че ще напиша „изберете“ и искам годината. Искам името. И ще потърся някои данни за заплатите. Това е набор от данни за образованието. В него има информация за висшите учебни заведения и гледам средната заплата на преподавателите, която е в една от тези таблици.
Така че аз всъщност написах думата „заплата.“ Не е точно в името на колоната по този начин. Използваме както логическите метаданни, така и физическите метаданни, за да правим предложения. И това, което искам да отбележа тук, е тази жълта кутия, която се появява тук. Пише, че има предупреждение за тази колона. Не търсех това, не взех клас за правилното използване на тези данни. Дойде ми и случва се предупреждение за споразумение за конфиденциалност, свързано с тези данни. Така че има някои правила за разкриване. Ако ще питам тези данни, ще извадя данни от тази таблица, трябва да внимавам как да ги разкрия. Така че тук имате политика на управление. Има някои предизвикателства, свързани с спазването на изискванията, които улесняват много по-лесно спазването на тази политика, когато знам за нея в момента, в който гледам данните.
И така, това ми предстои, и тогава също ще гледам за обучение. И тук виждаме, че визуализациите влизат в игра. В тази колона за обучение виждам - в таблицата на институцията има колона за обучение и виждам профил на това. Alation върви и дърпа примерни данни от таблиците и в този случай ми показва нещо, което е доста интересно. Показва ми разпределението на стойностите и ми показва, че нулевата стойност се показва 45 пъти в извадката и повече от която и да е друга стойност. Така че имам някакъв смисъл, че може да ни липсват някои данни.
Ако съм напреднал анализатор, това може би вече е част от моя работен процес. Особено ако съм особено педантичен, където бих направил куп заявки за профилиране преди време. Винаги, когато се приближавам до нова информация, винаги мисля за това какво е покритието на нашите данни. Но ако съм нов за анализа на данните, ако съм нов за този набор от данни, може да предположа, че ако има колона, тя се попълва през цялото време. Или бих могъл да предположа, че ако не е попълнен, не е нула, е нищожен или нещо подобно. Но в този случай имаме много нули и ако направих средна стойност, те вероятно би сгрешили, ако просто предположих, че тези нули всъщност са нула, вместо липсващи данни.
Но Alation, въвеждайки тази визуализация във вашия работен процес, ви помоля да разгледате тази информация и дава шанс дори на някакви начинаещи анализатори да видят, че тук има какво да забележите за тези данни. Така че имаме този преглед.
Следващото нещо, което ще направя, е да се опитам да разбера от какви таблици да получа тази информация. Така че тук виждаме интелигентните предложения. Той върви непрекъснато, но по-специално тук, дори не съм въвел нищо, но ще ми предложи кои таблици бих искал да използвам за тази заявка. И най-важното нещо, което трябва да знаете за това е, че се възползва от статистиката за употреба. Така че в среда като например eBay, където имате стотици хиляди таблици в една база данни, разполагате с инструмент, който може да удари житото от плявата и да използвате тези статистически данни за употреба, е наистина важно за създаването на тези предложения струва нещо.
Така че ще ви предложа тази таблица. Когато гледам визуализацията, ние всъщност подчертаваме три от колоните, които споменах вече в моята заявка. Така че знам, че има три, но няма име. Трябва да получа името, така че ще направя присъединяване. Когато правя присъединяване, сега отново имам тези визуализации, които да ми помогнат да намеря, къде е таблицата с името. Така че виждам, че този има добре форматирано, вид правилно изписано с главни букви име. Изглежда, че има по един ред с име за всяка институция, така че ще взема това и сега ми трябва условие за присъединяване.
И така, тук това, което прави Alation, отново се връща към дневниците на заявките, виждайки предишни времена, че тези две таблици са били съединени, и предлага различни начини за тяхното присъединяване. Отново има някаква намеса. Ако погледна едно от тях, има предупреждение, което ми показва, че това трябва да се използва само за агрегиран анализ. Вероятно ще се получи грешно нещо, ако се опитвате да направите нещо чрез институцията по институция. Като има предвид, че този, с идентификатора на OPE е утвърден като правилен начин за присъединяване към тези две таблици, ако искате данни на университетско ниво. Така че го правя и това е кратко запитване, но съм написал заявката си, без наистина да имам представа какви са данните. Никога не съм разглеждал ER диаграма на този набор от данни, но знам доста за тези данни, защото съответната информация идва при мен.
Така че това са един от трите начина, по които каталог може чрез интегриран инструмент за заявки да повлияе директно на работния процес, докато пишете заявки. Но едно от другите предимства на това, че инструментът за заявки е интегриран с каталог, е, че когато завърша заявката си и я запазя, мога да сложа заглавие като „Институция за обучение и факултетна заплата“ и тогава тук имам бутон, който ми позволява просто да го публикувам в каталога. Става ми много лесно да храня този гръб. Дори и да не го публикувам, той се улавя като част от дневника на заявките, но когато го публикувам, той всъщност става част от начина, по който централизираното място, където живеят всички знания за данни.
Така че, ако щракнете върху Търсене на всички заявки в Alation, ще бъда взета - и тук ще видите още малко от интерфейса на каталога - Ще бъда отведен до специализирано търсене на заявки, което ми показва начин да намеря заявки в цялата организация. И виждате, че моята току-що публикувана заявка е в горната част. И някои може да забележат тук при, когато улавяме заявките, ние също улавяме авторите и някак установяваме тази връзка между мен като автор и тези обекти на данните, за които сега знам нещо. И аз съм установен като експерт по това запитване и по тези обекти от данни. Това е наистина полезно, когато хората трябва да отидат да научат информация, тогава те могат да намерят подходящия човек, за когото да учат. И ако всъщност съм нов за данните, независимо дали съм напреднал анализатор - като напреднал анализатор, бих могъл да разгледам това и да видя куп примери, които биха ме накарали да започна на нов набор от данни. Като някой, който може да не се чувства супер разбиран със SQL, мога да намеря предварително направени заявки, които са отчети, от които мога да се възползвам.
Ето един от Фил Мазанет за средните SAT резултати. Кликнете върху това и аз получавам нещо като страница с каталог за самата заявка. Говори за статия, която беше написана, в която се споменава тази заявка, така че има някаква документация, която да прочета, ако искам да науча как да я използвам. И мога да го отворя в инструмента за заявки, като щракна върху бутона Съставяне, и мога просто да го пусна тук, без дори да го редактирам. И всъщност ще видите малко от нашите леки възможности за отчитане, където, когато пишете заявка, можете да пуснете в шаблонна променлива като тази и това създава прост начин да създадете форма за изпълнение на заявка въз основа на няколко параметъра.
Така че това имам за демонстрацията. Ще се върна към слайдовете. Само за да обобщим, показахме как администратор, управител на данни, може да се намеси, като поставя предупреждения за обекти, които се показват в инструмента за запитвания, как Alation използва знанията си за използването на обекти за данни, за да прави интелигентни предложения, как носи в профилирането и други съвети за подобряване на работните процеси на анализаторите, когато те докосват определени обекти, и как всички тези видове емисии обратно в каталога, когато се пишат нови заявки.
Очевидно съм говорител от името на компанията. Ще кажа хубави неща за каталозите с данни. Ако искате да чуете директно от един от нашите клиенти, Кристи Алън от Safeway ръководи екип от анализатори и има наистина страхотна история за време, когато тя трябваше наистина да бие часовника, за да се проведе маркетингов експеримент, и как цялата й екипът използва Alation, за да си сътрудничи и да се обърне наистина бързо в този проект. Така че можете да следвате тази връзка bit.ly, за да проверите тази история, или ако искате да чуете малко за това как Alation може да внесе каталог с данни във вашата организация, ще се радваме да настроим персонализирана демонстрация. Благодаря много.
Ребека Йозвяк: Много благодаря, Дейвид. Сигурен съм, че Дез и Робин имат няколко въпроса, преди да се обърна към Q&A на публиката. Дез, искаш ли да отидеш първи?
Дез Бланчфийлд: Абсолютно. Обичам идеята за тази концепция за публикувани заявки и свързването й с източника на създаването. Бил съм дългогодишен шампион на тази идея за вътрешен магазин за приложения и мисля, че това е наистина страхотна основа за изграждане на това.
Дойдох да се запозная с някои от организациите, които виждате да правите това, и някои от историите за успех, които биха могли да имат през цялото това пътуване, не само за използване на вашия инструмент и платформа за откриване на данните, но и след това трансформират вътрешните си културни и поведенчески черти наоколо. Сега като имате такъв собствен магазин за приложения, където просто изтегляте, концепцията, в която те не само могат да го намерят, но всъщност могат да започнат да развиват малки общности с пазителите на това знание.
Дейвид Крофорд: Да, мисля, че сме били изненадани. Вярваме в стойността на споделянето на заявки, както от миналото ми като продуктов мениджър в Adtech, така и от всички клиенти, с които сме говорили, но все още се изненадвам колко често това е едно от първите неща, които клиентите говорят за стойността, която изкарват от Алацията.
Правих някои потребителски тестове на инструмента за заявки при един от нашите клиенти, наречен Invoice2go, и те имаха продуктов мениджър, който беше сравнително нов, и те казаха - той всъщност ми каза, неуверен по време на потребителския тест: „Всъщност не бих да пиша SQL изобщо, освен че това става лесно от Alation. "И разбира се, като премиерът, аз някак си отивам, " Какво искаш да кажеш, как направихме това? "И той каза:" Е, наистина е просто защото мога да вляза и мога да видя всички тези съществуващи заявки. ”Започването с празен лист с SQL е невероятно трудно да се направи, но да промените съществуваща заявка, където можете да видите резултата, който е изведен и можете да кажете, „О, просто ми трябва тази допълнителна колона“ или „трябва да я филтрирам до определена гама от дати“, това е много по-лесно.
Виждали сме вид на тези спомагателни роли, като продуктови мениджъри, може би хора от търговските оператори, които започват да взимат и които винаги са искали да научат SQL и да започнат да го взимат с помощта на този каталог. Също така видяхме, че много компании са се опитали да направят вид на отворен код. Опитах се да изградя такива неща вътрешно, където те проследяват заявките и го предоставят, и има някои наистина трудни дизайнерски предизвикателства, за да ги направя полезни. Facebook има вътрешен инструмент, който те нарекоха HiPal, който улови всички запитвания, написани на Hive, но това, което разберете, е, че ако не подтикнете потребителите по правилния начин, просто завършвате с много дълъг списък от подбрани изявления. И като потребител, който се опитва да разбере дали дадена заявка е полезна за мен или дали е полезна, ако просто прегледам дълъг списък от подбрани изявления, ще ми отнеме много повече време, за да получа нещо ценно от там като се започне от нулата. Помислихме доста внимателно как да направим каталог на заявките, който да поднесе правилните неща отпред и да го предостави по полезен начин.
Дез Бланчфийлд: Мисля, че всички ние преминаваме през това пътуване от съвсем млада възраст, през зряла възраст, по много начини. Куп технологии. Аз лично лично съм преминал през същото това истинско нещо, като например да се науча да режа код. Бих минавал през списания и след това книги и щях да уча до определено ниво и тогава трябваше да отида и всъщност да получа още малко обучение и образование по него.
Но по невнимание открих, че дори когато тръгвах да преподавам себе си и да чета списания, да чета книги и да клъцвам програми на други хора и да ходя на курсове по него, все пак завърших да уча толкова много от правенето на курсовете, колкото просто говорех с други хора, които са имали някакъв опит. И мисля, че е интересно откритие, че сега, когато го донесете на анализа на данни, ние всъщност виждаме същия този паралел, че хората са неизменно доста умни.
Другото, което наистина искам да разбера, е, че на много високо ниво много организации ще попитат: „Колко време отнема да стигнем до тази точка?“ Какъв е моментът, в който хората стигат инсталирана е вашата платформа и те започнаха да откриват типовете инструменти? Колко бързо хората просто видят това нещо да се превърне в наистина незабавен „а-ха” момент, в който осъзнават, че дори не се притесняват от възвръщаемостта на инвестициите, защото е налице, но сега всъщност променят начина, по който правят бизнес ? И са открили изгубено изкуство и очакват, че могат да направят нещо наистина, наистина забавно с него.
Дейвид Крофорд: Да, мога да го докосна малко. Мисля, че когато се инсталираме, едно от хубавите неща, едно от нещата, които хората харесват в каталога, който е пряко свързан в системите за данни, е, че не започвате празно, където трябва да го попълните страница по страница. И това е нещо вярно за предишни решения за данни, където ще започнете с празен инструмент и трябва да започнете да създавате страница за всичко, което искате да документирате.
Тъй като ние документираме толкова много неща автоматично чрез извличане на метаданните, по същество в рамките на няколко дни след инсталирането на софтуера, можете да имате снимка на вашата среда за данни, която е поне 80 процента там в инструмента. И тогава мисля, че щом хората започнат да пишат заявки с инструмента, те автоматично се записват обратно в каталога и така ще започнат да се показват и.
Не искам да бъда прекалено нетърпелив да го заявя. Мисля, че две седмици е доста добра консервативна оценка, до месец. Две седмици до месец, консервативна оценка за това как наистина се обръщате и чувствате, че получавате стойност от това, като че ли започвате да споделяте някои знания и да можете да отидете там и да разберете нещата за вашите данни.
Дез Бланчфийлд: Всъщност е доста изумително, когато се замислите. Фактът, че някои от големите платформи за данни, които ефективно индексирате и каталогизирате, понякога ще отнемат понякога до година, за да внедрят и разгърнат и изправят правилно.
Последният въпрос, който имам за вас, преди да се предам на Робин Блур, е конектори. Едно от нещата, което веднага ми изскача, е, че очевидно сте подредили цялото това предизвикателство. Така че има няколко въпроса просто много бързо. Първо, колко бързо се внедряват конекторите? Очевидно започвате с най-голямата платформа, като Oracles и Teradatas и така нататък и DB2. Но колко редовно виждате, че новите конектори преминават и какво време за изпълнение те предприемат? Представям си, че имате стандартна рамка за тях. И колко дълбоко навлизате в тези? Например, Oracles и IBM на света и дори Tereadata, а след това и някои от по-популярните от късните платформи с отворен код. Работят ли директно с вас? Откривате ли го сами? Трябва ли да имате вътрешни знания за тези платформи?
Как изглежда да разработите конектор и колко дълбоко се включвате в тези партньорства, за да гарантирате, че тези конектори ще открият всичко, което е възможно?
Дейвид Крофорд: Да, разбира се, това е чудесен въпрос. Мисля, че в по-голямата си част можем да разработим конекторите. Със сигурност го правехме, когато бяхме по-млад стартъп и нямахме клиенти. Можем да развием връзките със сигурност, без да се нуждаем от вътрешен достъп. Никога не получаваме специален достъп до системите за данни, които не са обществено достъпни и често без да се нуждаем от вътрешна информация. Ние се възползваме от услугите за метаданни, достъпни от самите системи за данни. Често те могат да бъдат доста сложни и трудни за работа. По-специално знам SQL Server, начина, по който те управляват дневника на заявките, има няколко различни конфигурации и това е нещо, в което наистина трябва да работите. Трябва да разберете нюансите и копчетата и циферблатите по него, за да го настроите правилно и това е нещо, върху което работим с клиентите, тъй като сме го правили няколко пъти преди.
Но до известна степен това са публични API, които са налични или публични интерфейси, които са на разположение, които ние използваме. Имаме партньорства с няколко от тези компании, това е най-вече основание за сертифициране, така че да се чувстват удобно да казват, че работим, а също така те могат да ни предоставят ресурси за тестване, понякога ранен достъп може би до платформа, която излиза, за да се уверим, че работим върху новите версии.
За да завъртя нова връзка, бих казал отново, опитвайки се да бъда консервативен, да речем от шест седмици до два месеца. Зависи колко е подобно. Така че някои от Postgre изглеждат като вид много подобен на Redshift. Redshift и Vertica споделят много от своите детайли. Така че можем да се възползваме от тези неща. Но да, шест седмици до два месеца би било справедливо.
Имаме и API, така че - мислим и за Alation като за метаданни платформа, така че ако нещо не е на разположение, за да достигнем и автоматично да вземем, има начини да можете сами да напишете конектора и да го пъхнете в нашата система, така че че всичко все още се централизира в една търсачка.
Дез Бланчфийлд: Фантастичен. Оценявам това, че. Така че ще го предадем на Робин, защото съм сигурен, че и той има множество въпроси. Робин?
Ребека Йозвяк: Робин може да е на звука.
Дез Бланчфийлд: Вие се включихте на звука.
Робин Блур: Да, така е. Съжалявам, заглуших се. Когато прилагате това, какъв е процесът? Любопитна съм, защото на много места може да има много данни. И така, как става това?
Дейвид Крофорд: Да, разбира се. Влизаме, първо това е някакъв ИТ процес, за да се уверим, че сървърът ни е предвиден, като се уверим, че мрежовите връзки са налични, портовете са отворени, за да можем всъщност да имаме достъп до системите. Всички те често знаят с кои системи искат да започнат. Знаейки вътре в система за данни, която - а понякога и всъщност ще им помогнем. Ще им помогнем да направят първоначален преглед на дневника на запитванията си, за да разберат кой използва какво и колко потребители имат в системата. Така че ще помогнем да разберем къде - те често, ако имат стотици или хиляди хора, които може да влизат в бази данни, всъщност не знаят къде влизат, така че можем да разберем от регистрира заявка колко уникални потребителски акаунта всъщност имате влезли в системата и изпълнявате заявки тук след месец.
Така че можем да се възползваме от това, но често само върху най-важните. Ние ги настройваме и след това има процес на казване: „Да дадем приоритет“. Има редица дейности, които могат да се случват паралелно. Бих се съсредоточил върху обучението за използване на инструмента за заявки. След като хората започнат да използват инструмента за запитвания, на първо място, много хора обичат факта, че това е само единен интерфейс към всичките им различни системи. Те също така обичат факта, че е базиран на уеб, не включва инсталиране, ако не искат. От гледна точка на сигурността те харесват да имат вид на една входна точка, от мрежова гледна точка, между вид на корпоративна ИТ мрежа и центъра за данни, където живеят производствените източници на данни. И така, те ще настроят Alation като инструмент за запитване и ще започнат да използват Compose като точка за достъп за всички тези системи.
И така, след като това се случи, това, което се фокусираме върху обучението, е да разберем какви са разликите между уеб базиран или сървър базиран инструмент за заявки спрямо един, който бихте имали на вашия работен плот, и някои нюанси на използване че. И в същото време това, което ще се опитаме да направим, е да идентифицираме най-ценните данни, като отново се възползваме от информацията в дневника на заявките и казваме: „Ей, може би искате да влезете и да помогнете на хората да разберат това. Нека започнем да публикуваме представителни заявки на тези таблици. “Това понякога е най-ефективният начин много бързо да накараме хората. Нека да разгледаме собствената ви история на заявките, да публикуваме тези неща, така че да се показват като първите заявки. Когато хората гледат страница на таблицата, те могат да видят всички заявки, докоснали се до тази таблица, и могат да започнат от там. И тогава нека започнем да добавяме заглавия и описания към тези обекти, така че да бъдат по-лесни за намиране и търсене, така че да знаете някои от нюансите как да ги използвате.
Ние гарантираме, че ще разгледаме задълбочено журнала на запитванията, за да можем да генерираме родословие. Едно от нещата, които правим, е да погледнем през дневника на заявките в моменти, когато данните се преместват от една таблица в друга, и това ни позволява да поставим един от най-често задаваните въпроси за таблица с данни, откъде идва това? Как да му се доверя? И така, това, което можем да покажем, е не само от кои други таблици е дошло, но и как е трансформирана по пътя. Отново това е захранвано от дневника на заявките.
Така че ние се уверяваме, че тези неща са настроени и че навлизаме в системата и сме насочени към най-ценните и най-силно използваните парчета метаданни, които можем да установим на страниците на таблицата, така че когато търсите, намирате нещо полезно.
Робин Блур: Добре. Другият въпрос - има много въпроси от публиката, така че не искам да отделя прекалено много време тук - другият въпрос, който ми идва на ум, е само болката. Много софтуер е закупен, защото хората по един или друг начин изпитват затруднения с нещо. И така, каква е общата точка на болката, която води хората към Алацията?
Дейвид Крофорд: Да. Мисля, че има няколко, но мисля, че едно от тези, които чуваме доста често, е анализатор на борда. „Ще трябва да наема 10, 20, 30 души в близко бъдеще, които ще трябва да представят нови данни от тези данни, как ще достигнат скорост?“ Така че анализаторът на борда е нещо, което със сигурност справи. Има също така просто освобождаване на старшите аналитици да прекарват цялото си време в отговор на въпроси от други хора относно данните. Това също е много често. И двете по същество са проблеми с образованието.
И тогава бих казал, че друго място, което виждаме, че хората приемат Alation, е когато искат да създадат съвсем нова среда за данни за някой, в който да работят. Те искат да рекламират и продават това вътрешно, за да могат хората да се възползват от тях. Тогава превръщането на Alation в предния край на тази нова аналитична среда е много привлекателно. Има документация, има една точка за въвеждане на - единна точка за достъп до системите и това е друго място, където хората ще дойдат при нас.
Робин Блур: Добре, ще ви предам на Ребека, защото публиката се опитва да стигне до вас.
Ребека Йозвяк: Да, тук имаме много наистина добри въпроси на публиката. А Дейвид, този беше специално за теб. Това е от някой, който очевидно има известен опит с хора, които злоупотребяват с заявки и той казва, че колкото повече даваме на потребителите възможности, толкова по-трудно е да управляваме отговорното използване на изчислителните ресурси. Така че можете ли да се защитите срещу разпространението на заблудени, но често срещани фрази за заявки?
Дейвид Крофорд: Да, виждам този въпрос. Чудесен въпрос - един получаваме доста често. Самата болка съм виждала в предишни компании, където трябва да обучите потребители. Например, „Това е таблица с дневници, от години се връщат дневници. Ако ще напишете запитване на тази таблица, наистина трябва да ограничите по дата. ”Така че, например, това е обучение, което преминах в предишна компания, преди да получат достъп до базата данни.
Имаме няколко начина, по които се опитваме да се справим с това. Бих казал, че мисля, че данните от дневника на заявките са наистина изключително ценни за справянето с тях. Той дава още една представа спрямо това, което базата данни прави вътрешно със своя планировчик на заявки. И това, което правим, е една от тези интервенции - имаме ръчните интервенции, които показах, и това е полезно, нали? Така че при конкретно присъединяване, например, можете да кажете: „Нека да отнемем това“. Той ще има голям червен флаг, когато се появи в интелигентни предложения. Така че това е един начин да се опитате да стигнете до хората.
Друго нещо, което правим, е автоматизирано при интервенции по време на изпълнение. Това всъщност ще използва дървото на анализа на заявката, преди да го изпълним, за да види, включва ли определен филтър или няколко други неща, които също правим там. Но един от най-ценните и най-простият за обяснение е, включва ли филтър? Подобно на онзи пример, който току-що дадох, тази таблица на дневника, ако ще я питате, трябва да има период от време, можете да посочите на страницата на таблицата там, че давате мандат на този филтър за диапазон от време да се прилага. Ако някой се опита да стартира заявка, която не включва този филтър, той всъщност ще ги спре с голямо предупреждение и той ще каже: „Вероятно трябва да добавите SQL, който изглежда така, към вашата заявка.“ Те могат да продължат, ако те искат. Ние всъщност няма да им забраним напълно да го използват - това е и запитване, в края на деня трябва да изпълняват заявки. Но ние поставяме доста голяма бариера пред тях и им даваме предложение, конкретно приложимо предложение, за да модифицирате заявката, за да подобрите тяхната ефективност.
Всъщност също правим това автоматично в някои случаи, отново като наблюдаваме дневника на заявките. Ако видим, че някои наистина голям процент от запитвания в тази таблица се възползват от определен филтър или определена присъединителна клауза, тогава всъщност ще изскочим това. Ще промотираме това до интервенция. Всъщност ми се случи при вътрешен набор от данни. Имаме данни за клиенти и имаме потребителски идентификационни номера, но потребителските идентификационни номера са определени, тъй като това е нещо - ние имаме потребителски идентификационни номера на всеки клиент. Не е уникален, така че трябва да го сдвоите с клиентски идентификатор, за да получите уникален ключ за присъединяване. И аз пишех запитване и се опитах да анализирам нещо и то се появи и каза: „Ей, изглежда, че всички останали се присъединяват към тези таблици както с идентификатора на клиента, така и с идентификационния номер на потребителя. Сигурен ли си, че не искаш да правиш това? ”И всъщност ме спря да правя некоректен анализ. Така че работи както за точността на анализа, така и за представянето. Така че по този начин ние приемаме този проблем.
Ребека Йозвяк: Това ми се струва ефективно. Казахте, че не е задължително да блокирате хората да трупат ресурси, но по някакъв начин ги научете, че това, което правят, може да не е най-доброто, нали?
Дейвид Крофорд: Ние винаги приемаме, че потребителите не са злонамерени - дайте им най-добрите намерения - и се опитваме да бъдем доста отворени по този начин.
Ребека Йозвяк: Добре. Ето още един въпрос: „Каква е разликата между мениджъра на каталога, например с вашето решение, и MDM инструмента? Или всъщност разчита на различен принцип чрез разширяване на избора на таблиците за заявки, докато MDM ще го прави автоматично, но със същата основна принцип на събиране на метаданни. "
Дейвид Крофорд: Да, мисля, че когато разглеждам традиционните MDM решения, основната разлика е философска. Всичко е за това кой е потребителят. Така, както казах в началото на презентацията си: Алация, мисля, че когато бяхме основани, ние бяхме създадени с цел да дадем възможност на анализаторите да произвеждат повече прозрения, да ги произвеждат по-бързо, да бъдат по-точни в прозренията, които те произвеждат. Не мисля, че това някога е било целта на традиционното решение за MDM. Тези решения обикновено са насочени към хора, които трябва да представят отчети за това, какви данни са били заснети в ВКС или вътрешно за някакъв друг вид одит. Понякога може да даде възможност на анализаторите, но по-често, ако ще активира практикуващ в тяхната работа, е по-вероятно да активира архитект на данни като DBA.
Когато мислите за нещата от гледна точка на анализатор, тогава започвате да изграждате инструмент за запитвания, който MDM инструмент никога не би направил. Тогава започвате да мислите за ефективността, както и за точността, както и да разберете какви данни са свързани с нуждите на моя бизнес. Всички тези неща са неща, които се появяват в съзнанието ни, когато проектираме инструмента. Тя влиза в нашите алгоритми за търсене, влиза в оформлението на страниците с каталога и способността да се допринасят знания от цялата организация. Излиза в това, че ние изградихме инструмента за запитвания и че вградихме каталога директно в него, така че мисля, че наистина идва от това. Какъв потребител имате първо на ум?
Ребека Йозвяк: Добре, добре. Това наистина помогна да го обясня. който умираше да се хване за архивите, защото трябваше да напусне, но наистина искаше да му отговори на въпроса. Той каза, че е споменато в началото, че има няколко езика, но дали SQL е единственият език, използван в компонента Compose?
Дейвид Крофорд: Да, това е вярно. И едно от нещата, които забелязах, като вид бях свидетел на експлозията на различните видове бази данни, бази данни, документи, графични бази данни, ключови магазини за стойности, е, че те са наистина мощни за разработки на приложения. Те могат да обслужват конкретни нужди там много добре, по по-добри начини, отколкото релационните бази данни.
Но когато го върнете обратно към анализа на данните, когато го върнете обратно - когато искате да предоставите тази информация на хора, които ще правят ad hoc отчитане или ad hoc копаят в данните, те винаги се връщат към релационна връзка поне интерфейс за хората. Част от това е само защото SQL е lingua franca за анализ на данни, така че това означава, че за хората това е и за инструментите, които се интегрират. Мисля, че това е причината, поради която SQL в Hadoop е толкова популярен и има толкова много опити за решаването му, е защото в края на деня това знаят хората. Вероятно има милиони хора, които знаят как да пишат SQL, и бих се осмелил да не милиони, които знаят как да напишат рамково запитване на тръбопровод за агрегация на Монго. И че това е стандартен език, който се използва за интеграция в наистина голямо разнообразие от платформи. Така че всичко това говори, много рядко ни се иска да излизаме извън него, защото това е интерфейсът, който повечето анализатори използват и това е място, където се съсредоточихме, особено в Compose, че се съсредоточихме върху писането на SQL.
Бих казал, че науката за данни е мястото, където те се намират извън най-много и затова получаваме понякога въпроси относно използването на Pig или SAS. Това са неща, с които определено не се справяме в Compose и които бихме искали да заснемем в каталога. И виждам също R и Python. Има няколко начина, по които сме направили интерфейси, чрез които можете да използвате заявките, написани в Alation вътре в R и Python скриптове, така че, често когато сте учен с данни и работите на скриптов език, изходните данни са в релационна база данни. Започвате със SQL заявка и след това я обработвате допълнително и създавате графики вътре в R и Python. И ние направихме пакети, които можете да импортирате в онези скриптове, които издърпват заявките или резултатите от заявката от Alation, така че там можете да имате смесен работен процес.
Ребека Йозвяк: Добре, страхотно. Знам, че сме минали малко покрай върха на часа, просто ще задам още един или два въпроса. Знам, че сте говорили за всички различни системи, с които можете да се свържете, но що се отнася до външно хоствани данни и вътрешно хоствани данни, може ли заедно да се търси в единствения ви изглед, във вашата единствена платформа?
Дейвид Крофорд: Разбира се. Има няколко начина за това. Искам да кажа, външно домакин, бих си представил, опитвам се да помисля какво точно може да означава това. Това може да означава база данни, която някой хоства в AWS за вас. Това може да означава публичен източник на данни от data.gov. Свързваме се директно с бази данни, като влизаме точно като друго приложение с, с акаунт в бази данни и по този начин извличаме метаданните. Така че, ако имаме акаунт и имаме отворен мрежов порт, можем да стигнем до него. И тогава, когато нямаме тези неща, имаме нещо, наречено виртуален източник на данни, което ви позволява по същество да избутате документация, независимо дали автоматично, като напишете свой собствен конектор или като го попълните, като направите дори като CSV качване, да документирате данните заедно с вътрешните си данни. Това се поставя в търсачката. Той става референтен вътре в статии и друга документация и разговори вътре в системата. Така че се справяме, когато не можем директно да се свържем със система.
Ребека Йозвяк: Добре, това има смисъл. Просто ще изстрелям още един въпрос към вас. Един присъстващ е питайки, „Как трябва да се валидира, провери или поддържа съдържанието на каталога с данни, като актуализират изходните данни, както се променят изходните данни и т.н.“
Дейвид Крофорд: Да, това е въпрос, който получаваме много и мисля, че едно от нещата, които ние - една от нашите философии, както казах, не вярваме, че потребителите са злонамерени. Предполагаме, че те се опитват да дадат най-добрите знания. Те няма да влязат и умишлено подвеждат хората за данните. Ако това е проблем във вашата организация, може би Alation не е правилният инструмент за вас. Но ако приемете добри намерения от страна на потребителите, тогава ние мислим за това като нещо къде, актуализациите идват и тогава обикновено това, което правим, е да поставим управител, отговарящ за всеки обект на данни или всеки раздел от данните. И можем да уведомяваме тези управители, когато са направени промени в метаданните и те могат да се справят по този начин. Те виждат, че актуализациите влизат, валидират ги. Ако не са правилни, те могат да се върнат и да ги променят и информират и да се надяваме дори да се свържат с потребителя, който е предоставил информацията и да им помогне да научат.
Така че това е основният начин, по който мислим да го правим. Този вид предложения от тълпата и управлението от стюардите, така че имаме някои възможности около това.
Ребека Йозвяк: Добре, добре. И ако можете просто да уведомите хората как най-добре да започнат с Alation и къде могат да отидат конкретно, за да получат повече информация. Знам, че сте споделили този един bit.ly. Това ли е най-доброто място?
Дейвид Крофорд: Alation.com/learnmore Мисля, че това е чудесен начин. За да се регистрирате за демонстрация, сайтът Alation.com има много страхотни ресурси, бели документи на клиенти и новини за нашето решение. Така че мисля, че това е чудесно място за начало. Можете също да изпратите имейл.
Ребека Йозвяк: Добре, страхотно. Знам, присъстващи, съжалявам, ако не стигнах до всички въпроси днес, но ако не, те ще бъдат препратени на Дейвид или неговия екип по продажбите или някой от Alation, така че определено могат да помогнат да отговорят на вашите въпроси и да помогнат да разберете какво прави Алацията или какво правят най-добре.
И с това, хора, ще продължа и ще ни подпиша. Винаги можете да намерите архивите на InsideAnalysis.com. Можете да го намерите и на Techopedia.com. Те са склонни да се актуализират малко по-бързо, така че определено проверете това. И много благодаря на Дейвид Крофорд, Дез Бланчфийлд и Робин Бор днес. Беше страхотно излъчване по интернет. И с това ще се сбогувам. Благодаря, хора. Чао чао.
Дейвид Крофорд: Благодаря.
