За вкъщи: Домакинът Ребека Йозвяк обсъжда предимствата на каталозите с данни с Дез Бланчфийлд, Робин Блур и Дейвид Крофорд.
Трябва да се регистрирате за това събитие, за да видите видеоклипа. Регистрирайте се, за да видите видеото.
Ребека Йозвяк: Дами и господа, привет и добре дошли в горещите технологии на 2016 г. Днес имаме „Силата на предложението: Как един каталог на данни дава възможност на анализаторите.“ Аз съм вашият домакин Ребека Йозвяк, попълняйки днес обичайния ни домакин Ерик Кавана, докато той пътува по света, така че благодаря, че се присъединихте към нас. Тази година е гореща, не е просто горещо в Тексас, където съм, но е горещо навсякъде. Избухва всякакъв вид нови технологии. Имаме IoT, поточни данни, приемане на облаци, Hadoop продължава да узрява и да се приема. Разполагаме с автоматизация, машинно обучение и всичко това е разбира се подчертано от данните. И предприятията стават все повече и повече данни, задвижвани от деня. И разбира се, смисълът на това е да доведе до знание и откриване и, разбирате ли, да вземете по-добри решения. Но за да получите наистина максимална стойност от данните, трябва да е лесно да стигнете. Ако го държите заключен или заровен или в мозъка на няколко души в предприятието, няма да донесе много добро за предприятието като цяло.
И аз мислех за каталогизиране на данни и мислене за разбира се библиотеки, където отдавна там отидохте, ако трябва да откриете нещо, ако трябва да проучите тема или да потърсите някаква информация, отидохте в библиотеката и, разбира се, отидохте в каталога на картичките или на краби дамата, която работеше там. Но също така беше забавно да се лутаме наоколо, ако просто искате да разгледате и сте сигурни, че просто ще откриете нещо изрядно, може да разберете някои интересни факти, които не сте знаели, но ако наистина трябва да откриете нещо, и знаехте какво търсите, имате нужда от каталога на картите и разбира се, фирменият еквивалент е каталог на данни, който може да помогне да осветите светлината на всички данни за нашите потребители, за да обогатят, открият, споделят, консумират и наистина да помогнат на хората да получат към данните по-бързо и по-лесно.
И така, днес ние имаме Дез Бланчфийлд, наш учен с данни, и ние имаме доктор Робин Блур, наш главен анализатор, ние имаме Дейвид Крофорд от Alation, който ще говори за историята на каталогизирането на данните на неговата компания, но първо ще продължим да поведе с Дез. Дез, предавам топката при теб и пода е твой.
Dez Blanchfield: Благодаря, благодаря, че ме прие днес. Това е въпрос, който ме интересува изключително много, тъй като почти всяка организация, на която се натъквам в ежедневната си работа, намирам точно същия въпрос, за който говорихме съвсем накратко в лентата за предварително шоу и това е това повечето организации, които работят повече от няколко години, имат множество данни, погребани около организацията, различни формати и всъщност имам клиенти, които имат набори от данни, които се връщат към Lotus Notes, бази данни, които все още работят в някои случаи като техен псевдосети и всички те се сблъскват с това предизвикателство да намерят къде точно са техните данни и как да получат достъп до тях, кой да им предостави достъп, кога да им предоставят достъп и как просто каталог и как да го стигнете до място, където всеки може: A) да сте наясно какво има и какво има в него, и B), как да получите достъп до него и да го използвате. И едно от най-големите предизвикателства, разбира се, е да го намериш, другото голямо предизвикателство е да знаеш какво има там и как да получиш достъп до него.
Възможно е да знам, че имам десетки бази данни, но всъщност не знам какво има там или как да разбера какво има там и така неизменно, както откриваме сега в данните преди показването, вие сте склонни да ходите из офиса и задавайте въпроси и викайте през кубичните стени и опитайте да разбера, често моят опит е, че дори може да откриете, че се скитате на рецепцията, на рецепцията и питате дали някой знае кой сте ' ще отида да поговорим. Доста често това не винаги е ИТ фолк, тъй като те не знаят за набора от данни, защото някой просто го е създал, и може да е нещо просто като - доста често ще намерим някакъв проект, който да стои в IT среда и ръководителят на проекта е използвал електронна таблица с всички неща и е получил огромно количество ценна информация около активи и минуси и имена, и освен ако не знаете този проект и не познавате този човек, просто не можете да намерите тази информация. Той просто не е наличен и трябва да се захванете с този оригинален файл.
Има една фраза, която е разпръсната наоколо по отношение на данните и не съм задължително съгласна с тях, но мисля, че това е малко сладко изхвърляне и това е, че определено количество хора смятат, че данните са новото масло и съм сигурен, че ние Ще покрия това и в някакъв аспект, по-късно днес. Но това, което забелязах и със сигурност е част от тази трансформация, е, че организации на предприятия, които са се научили да оценяват своите данни, са спечелили значително предимство пред своите конкуренти.
Преди около пет или шест години имаше интересен документ от IBM и те проучиха около 4000 компании тук, в Австралия, и взеха цялата информация, всички данни за резултатите, всички финансови данни и я събраха в кипящ съд и след това изпратиха го до Австралийското училище по икономика и те всъщност започнаха обща тенденция тук, а това беше, че компаниите, които се възползват от технологиите, неизменно получават толкова конкурентно предимство пред своите връстници и конкуренти, че техните конкуренти почти никога не ги догонват и мисля това е много така сега с данните, които видяхме това, което хората наричат дигитална трансформация, където организации, които ясно са измислили как да намерят данните, които имат, да направят тези данни достъпни и да ги направят достъпни в някои много лесни консумативи мода за организацията, без непременно винаги да знае защо организацията може да се нуждае от това и да спечели значително предимство пред конкурентите.
Имам няколко примера на този слайд, който можете да видите. Единственият ми ред е, че според мен мащабните смущения в почти всеки индустриален сектор се ръководят от данни и ако сегашните тенденции продължават да се случват, моето мнение е, че ние наистина наистина просто сме получили започна, защото когато дългогодишните марки най-накрая се събудят какво означава това и влязат в играта, те ще влязат в играта на едро. Когато вид на големите търговци на дребно, които имат планина от данни, започнат да прилагат исторически анализ на данните, ако дори знаят, че съществуват, тогава някои от онлайн играчите ще получат малко събуждане.
Но с много от повечето от тези марки искам да кажа, че имаме Uber, които са най-голямата таксиметрова компания в света. Те не притежават никакви таксита, така че какво ги прави вълшебни, какви са техните данни? Airbnb, най-големият доставчик на места за настаняване, имаме WeChat, най-голямата телефонна компания в света, но те нямат реална инфраструктура, нито телефони, нито телефонни линии. Alibaba, най-големият търговец на дребно на планетата, но те не притежават нито един от инвентара. , най-голямата медийна компания в думата. Мисля, че при последното броене те имаха 1,4 милиарда активни потребители на данни сега, което е умопомрачително число. Това не е никъде наблизо - мисля, че някой твърди, че една четвърт от планетата всъщност е там всеки ден, но въпреки това е доставчик на съдържание, който всъщност не създава съдържанието, всички данни, които обслужват, не са създадени от тях, а са създадени от тях абонати и всички познаваме този модел.
SocietyOne, за който може да сте чували или да не сте чували, това е местна марка, мисля, че в няколко държави това е банка, която всъщност прави партньорско кредитиране, така че с други думи, няма пари. Всичко, което прави, е да управлява транзакциите и данните са разположени под него. Netflix, всички сме много, много добре запознати с това. Тук има интересен еднолинейник Когато Netflix законно можеше да бъде използван в Австралия, когато беше официално обявено, не е трябвало да използвате VPN, за да стигнете до него, много хора по света са склонни - ако не можете да стигнете до него в местния си район - когато Netfix стартира в Австралия, той увеличи международната честотна лента на нашите интернет връзки с 40 процента, така че почти удвои използването на интернет в Австралия за една нощ, само с едно приложение, едно облачно хоствано приложение, което не играе нищо друго, освен да играе с данни. Това е просто умопомрачителна статистика.
И разбира се, всички сме запознати с Apple и Google, но това са най-големите софтуерни фирми на планетата, но всъщност те не пишат приложенията. Какво е съвместимото с всички тези организации? Е, това са данни и те не стигнаха до там, защото не знаеха къде са данните им и не знаеха как да ги катализират.
Това, което откриваме сега, е, че съществува този нов клас активи, наричан данни, и компаниите се събуждат от него. Но те винаги нямат инструменти и ноу-хау и затова да картографират всички тези данни, да катализират всички тези данни и да ги направят достъпни, но открихме, че компании с почти никакви физически активи са спечелили висока пазарна стойност за рекордно кратко време чрез този нов клас активи на данни. Както казах, някои от старите играчи се събуждат за това и със сигурност го извеждат.
Аз съм голям почитател да поемам хора на малко пътуване, така че в осемнадесетте стотици, края на осемнадесетте стотици и вие ще бъдете повече от запознати с това на американския пазар, се оказа, че за провеждане на преброяване всяка година или около това, мисля, че в този момент те са ги провеждали на всеки десет години, но ако ще провеждате преброяване всяка година, може да ви отнеме до осем или девет години, за да направите всъщност анализа на данните. Оказа се, че след това този набор от данни се оставя на кутии на места на хартия и почти никой не може да го намери. Те просто продължаваха да изпомпват тези доклади, но действителните данни бяха много трудни за достигане, имаме подобна ситуация и с друг важен световен момент, около 40-те години, с Втората световна война, и това нещо е Blechley Park Bombe, изписано BOMBE , и това беше масивен аналитичен инструмент за съкращаване на числата, който щеше да преминава през малки масиви данни и да намира сигнали в него и да се използва за подпомагане на пробиване на кодове чрез Enigma.
Това нещо отново беше по същество устройство, създадено, не много да каталогизира, но да маркира и картографира данни и дава възможност да се вземат модели и да ги намерят вътре в наборите от данни, в този случай разбийте кодове, намерете ключове и фрази и намерете те редовно в наборите от данни и затова преживяхме това пътуване да намерим нещата в данните и да водим към каталогизиране на данни.
И тогава се появиха тези неща, тези масивни нискотарифни стелажи с машини, просто нестандартни машини. И направихме няколко много интересни неща и едно от нещата, които направихме с тях е, че изградихме много ниски разходи, които биха могли да започнат да индексират планетата, и много известни са тези големи марки, които идват и си отиват, но вероятно Google е най-често срещаният дом марка, за която всички сме чували - тя се превръща в действителен глагол и знаете, че сте успешни, когато марката ви се превърне в глагол. Но това, което Google ни научи, без да го осъзнаваме, вероятно в света на бизнеса, е, че те успяха да индексират цялата планета до определено ниво и да катализират данните, които бяха по целия свят, и да ги направят достъпни за много лесно, удобна форма в малко мъничка едноредова формула, уеб страница с почти нищо върху нея и въвеждате заявката си, тя отива и я намира, защото те вече бяха обходили планетата, индексираха я и я направиха лесно достъпна.
И това, което забелязахме, беше: „Ама виси, не правим това в организации - защо е така? Защо имаме организация, която може да картографира цялата планета и да я индексира, обхожда и индексира и я предоставя на разположение, можем да я търсим и след това щракнете върху нещата, за да я намерите и да я намерите, как така не сте го направили вътрешно? "Така че сега има много от тези малки стелажи с машини, които правят това за интранети и намират неща, но те все още просто се справят с идеята да надхвърлят традиционната уеб страница, или файлов сървър.
Вместо сега да влезете в това следващо поколение каталог на данни по много начини, откриването на достъп до данни чрез бележки след това и разговори с охладител за вода всъщност вече не е подходящ метод за откриване и каталогизиране на данни и всъщност не мисля, че това наистина е било , Вече не можем да водим цялото това предизвикателство към хората, които просто правят бележки, публикуват бележки и чатят за него. Ние сме добре и наистина извън областта, в която този подход от следващото поколение към каталогизирането на данни се е появил и изчезнал. Трябва да го прегърнем. Ако това беше лесен проблем, ние вече щяхме да го разрешим по много начини по-рано, но мисля, че това не е лесен проблем, просто индексирането и извикването на данните е само една част от него, като знаем какво има в данните и изграждат метаданни около това, което откриваме, и след това го предоставяме в лесна, консумативна форма, особено за самообслужване и анализи. Все още проблемът се решава, но много части от пъзела за пет години са добре и наистина решени и налични.
Както знаем, хората, които катализират данни, са рецепта за провал, защото човешката грешка е един от най-големите кошмари, с които се справяме при обработката на данни, и аз редовно говоря по тази тема, където според мен хората, попълващи хартиени формуляри, вероятно са най-големият кошмар ние се занимаваме с големи данни и аналитични данни, като постоянно трябва да поправяме нещата, които правят, дори до прости неща като дати и полета, като хората го поставят в грешен формат.
Но както казах, виждаме интернет търсачките да индексират света всеки ден, така че сега го правим на идеята, че това може да се направи на набори от бизнес данни в процеса на откриване, а инструментите и системите вече са лесно достъпни, тъй като ще се запознаете днес. Така че, по мое мнение, трикът е да изберете правилните инструменти, най-добрите инструменти за работата. И по-подходящо отгоре на това, намирането на правилната част от нея, която да ви помогне да започнете по този път. И вярвам, че ще чуем за това днес, но преди да го направим, ще премина към колежа си Робин Блур и ще чуя неговото приемане по темата. Робин, мога ли да ти предам?
Robin Bloor: Да, със сигурност можете. Да видим дали това работи, о, да, това е така. Добре, идвам от различна посока от 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 инструментите - и от двете ще извлечем технически метаданни, за основно това, което съществува. Точно така, какви маси? Какви отчети? Какви са дефинициите на отчета? Така те извличат тези технически метаданни и автоматично се създава страница с каталог за всеки обект вътре в тези системи и след това те извличат и слой над тези технически метаданни, а отгоре използват данните за използването. Това се извършва предимно чрез четене на регистрационни файлове на заявки от базата данни и това е наистина интересен източник на информация. И така, всеки път, когато анализатор напише заявка, всеки път, когато инструмент за отчитане, дали се отглежда в домашни условия или извън рафта, дали инструментът за отчитане изпълнява заявка, за да актуализира таблото за управление, когато приложение изпълнява заявка за вмъкване на данни, за да работи набор от данни - всички тези неща се записват в дневниците на заявките за бази данни. Независимо дали имате каталог или не, те се записват в дневника на заявките с базата данни. Какво може да направи каталогът с данни и по-специално какво може да направи каталогът Alations, е да прочетете тези регистрационни файлове, да зададете заявките вътре в тях и да създадете наистина интересна графика за използване въз основа на тези регистрационни файлове и ние го въвеждаме в игра, за да информираме бъдещите потребители от данните за това как минали потребители на данните са го използвали.
И така, ние събираме всички тези знания заедно в каталог и само за да направим това истинско, това са интеграциите, които вече са внедрени в клиентите, така че видяхме 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 на публиката. Дез, искаш ли да отидеш първи?
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: Вие сте се заглушили.
Robin Bloor: Да бе. Съжалявам, заглуших се. Когато прилагате това, какъв е процесът? Любопитен съм, защото на много места може да има много данни. И така, как става това?
Дейвид Крофорд: Да, разбира се. Влизаме, първо като своеобразен ИТ процес, за да се уверим, че нашите сървъри са предвидени, като се уверим, че мрежовите връзки са налични, портовете са отворени, така че всъщност да имаме достъп до системите. Всички те често знаят с кои системи искат да започнат. Знаейки вътре в система за данни, която - а понякога и всъщност ще им помогнем. Ами помогнете им да направят първоначален преглед на техния дневник на запитванията, за да разберат кой използва какво и колко потребители имат в системата. Затова добре помогнете да разберете къде - те често, ако имат стотици или хиляди хора, които може да влизат в бази данни, всъщност не знаят къде влизат, така че можем да разберем от записите на запитването колко уникални потребителски акаунта правят всъщност сте влезли в системата и изпълнявате заявки тук след около месец.
Така че можем да се възползваме от това, но често само върху най-важните. Ние ги настройваме и след това има процес на казване: „Дайте приоритет“. Има набор от дейности, които могат да се случват паралелно. Бих се съсредоточил върху обучението за използване на инструмента за заявки. След като хората започнат да използват инструмента за запитвания, на първо място, много хора обичат факта, че е само единен интерфейс към всичките им различни системи. Те също така обичат факта, че неговата уеб-базирана, не включва инсталиране, ако те не искат. От гледна точка на сигурността те харесват да имат вид на една входна точка, от мрежова гледна точка, между вид на корпоративна ИТ мрежа и центъра за данни, където живеят производствените източници на данни. И така, те ще настроят Alation като инструмент за запитвания и започват да използват Compose като точка за достъп за всички тези системи.
Така че след като това се случи, това, което се фокусираме върху обучението, е да разберем какви са разликите между уеб-базиран или сървър-базиран инструмент за заявки спрямо един, който имате на вашия работен плот, и някои нюанси на използването му. И в същото време това, което добре се опитвате да направите, е да идентифицирате най-ценните данни, като отново се възползвате от информацията в дневника на заявките и казвате: „Ей, може би искате да влезете и да помогнете на хората да разберат това. Нека започнем да публикуваме представителни заявки на тези таблици. “Това понякога е най-ефективният начин да накарате хората да се въртят. Нека разгледаме собствената си история на заявките, публикуваме тези неща, така че да се показват като първите заявки. Когато хората гледат страница на таблицата, те могат да видят всички заявки, докоснали се до тази таблица, и могат да започнат от там. И тогава нека започнете да добавяте заглавия и описания към тези обекти, така че да бъдат по-лесни за намиране и търсене, така че да знаете някои от нюансите как да ги използвате.
Ние гарантираме, че ще разгледаме задълбочено журнала на запитванията, за да можем да генерираме родословие. Едно от нещата, които правим, е да погледнем през дневника на заявките в моменти, когато данните се преместват от една таблица в друга, и това ни позволява да поставим един от най-често задаваните въпроси за таблица с данни, откъде идва това? Как да му се доверя? И така, това, което можем да покажем, е не само от кои други таблици е дошло, но и как е трансформирана по пътя. Отново това е захранвано от дневника на заявките.
Така че ние се уверяваме, че тези неща са настроени и са влизали в родословие в системата и са насочени към най-ценните и най-силно използваните парчета метаданни, които можем да установим на страниците на таблицата, така че когато търсите, намирате нещо полезно.
Robin Bloor: Добре. Другият въпрос - има много въпроси от публиката, така че не искам да отделя прекалено много време тук - другият въпрос, който ми идва на ум, е само болката. Много софтуер, закупен, защото хората по един или друг начин изпитват затруднения с нещо. И така, какво е общата точка на болката, която води хората към Алацията?
Дейвид Крофорд: Да. Мисля, че има няколко, но мисля, че едно от тези, които чуваме доста често, е анализатор на борда. „Ще трябва да наемем 10, 20, 30 души в близко бъдеще, които ще трябва да представят нови данни от тези данни, как ще постигнат скорост?“ Така че анализаторът на борда е нещо, с което със сигурност се справяме. Терес просто облекчава старшите анализатори да прекарват цялото си време в отговор на въпроси от други хора относно данните. Това също е много често. И двете по същество са проблеми с образованието.
И тогава бих казал, че друго място, което виждаме, че хората приемат Alation, е когато искат да създадат съвсем нова среда за данни за някой, в който да работят. Те искат да рекламират и продават това вътрешно, за да могат хората да се възползват от тях. Тогава превръщането на Alation в предния край на тази нова аналитична среда е много привлекателно. В него има документацията, има един единствен пункт за въвеждане на - единна точка за достъп до системите и така това е друго място, където хората ще дойдат при нас.
Robin Bloor: Добре, ще ви предам на Ребека, защото публиката се опитва да стигне до вас.
Ребека Йозвяк: Да, тук имаме много наистина добри въпроси за публиката. А Дейвид, този беше специално за теб. Това е от някой, който очевидно има известен опит с хора, които злоупотребяват със заявки, и той казва, че колкото повече даваме на потребителите възможности, толкова по-трудно е да управляваме отговорното използване на изчислителните ресурси. Така че можете ли да се защитите срещу разпространението на заблудени, но често срещани фрази за заявки?
Дейвид Крофорд: Да, виждам този въпрос. Страхотен въпрос - един получаваме доста често. Сам видях болката в предишни компании, където трябва да обучите потребители. Например, „Това е регистрационна таблица, нейните дневници се връщат с години. Ако ще напишете заявка на тази таблица, наистина трябва да се ограничите по дата. ”Така, например, това е обучение, което преминах в предишна компания, преди да получат достъп до базата данни.
Имаме няколко начина, по които се опитваме да се справим с това. Бих казал, че мисля, че данните от дневника на заявките са наистина изключително ценни за справянето с тях. Той дава още една представа спрямо това, което базата данни прави вътрешно със своя планировчик на заявки. И това, което правим, е една от тези интервенции - имаме ръчните интервенции, които показах, и това е полезно, нали? Така че при конкретно присъединяване, например, можете да кажете: „Нека остаря това.“ Той ще има голям червен флаг, когато се появи в интелигентни предложения. Това е един от начините да се опитате да стигнете до хората.
Друго нещо, което правим, е автоматизирано при интервенции по време на изпълнение. Това всъщност използва дървото на анализа на заявката, преди да го изпълним, за да види, включва ли определен филтър или няколко други неща, които правим и там. Но един от най-ценните и най-простият за обяснение е, включва ли филтър? Подобно на онзи пример, който току-що дадох, тази таблица на дневника, ако ще я питате, трябва да има диапазон от дати, можете да посочите на страницата с таблицата там, че възлагате този филтър за диапазон от дати да се прилага. Ако някой се опита да изпълни заявка, която не включва този филтър, той всъщност ще ги спре с голямо предупреждение и той ще каже: „Вероятно трябва да добавите малко 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 качване, за да документирате данните наред с вашите вътрешни данни. Това се поставя в търсачката. Той става референтен вътре в статии и друга документация и разговори вътре в системата. Така че се справяме, когато не можем директно да се свържем със система.
Ребека Йозвяк: Добре, че има смисъл. Просто ще изстреля още един въпрос към вас. Един присъстващ е питайки, „Как трябва да се валидира, провери или поддържа съдържанието на каталога с данни, като актуализират изходните данни, както се променят изходните данни и т.н.“
Дейвид Крофорд: Да, това е въпрос, който получаваме много и мисля, че едно от нещата, които ние - една от нашите философии, както казах, не вярваме, че потребителите са злонамерени. Предполагаме, че те се опитват да дадат най-добрите знания. Те няма да влязат и умишлено подвеждат хората за данните. Ако това е проблем във вашата организация, може би Alations не е подходящият инструмент за вас. Но ако приемете добри намерения от страна на потребителите, тогава ние мислим за това като нещо къде, актуализациите идват и тогава обикновено това, което правим, е да поставим управител, отговарящ за всеки обект на данни или всеки раздел от данните. И можем да уведомяваме тези управители, когато са направени промени в метаданните и те могат да се справят по този начин. Те виждат, че актуализациите влизат, валидират ги. Ако не са прави, те могат да се върнат и да ги променят и информират, и да се надяваме дори да се свържат с потребителя, който е предоставил информацията и да им помогне да научат.
Това е основният начин, по който мислим да го правим. Този вид предложения от тълпата и управлението от стюардите, така че имаме някои възможности около това.
Ребека Йозвяк: Добре. И ако можете просто да уведомите хората как най-добре да започнат с Alation и къде могат да отидат конкретно, за да получат повече информация. Знам, че сте споделили този един bit.ly. Това ли е най-доброто място?
Дейвид Крофорд: Alation.com/learnmore Мисля, че това е чудесен начин. За да се регистрирате за демонстрация, сайтът Alation.com има много страхотни ресурси, бели документи на клиенти и новини за нашето решение. Така че мисля, че това е чудесно място за начало. Можете също .
Ребека Йозвяк: Добре, страхотно. Знам, присъстващи, съжалявам, ако не стигнах до всички въпроси днес, но ако не, те ще бъдат препратени на Дейвид или неговия екип по продажбите или някой от Alation, така че те определено могат да помогнат да отговорят на вашите въпроси и да помогнат да разберете какво Alation прави или какво правят най-добре.
И с това, хора, ще продължа и ще ни подпиша. Винаги можете да намерите архивите на InsideAnalysis.com. Можете да го намерите и на Techopedia.com. Те са склонни да се актуализират малко по-бързо, така че определено проверете това. И много благодаря на Дейвид Крофорд, Дез Бланчфийлд и Робин Бор днес. Беше страхотно уеб предаване. И с това, аз ви сбогувам. Благодаря, хора. Чао чао.
Дейвид Крофорд: Благодаря ти.