Zawartość
Źródło: Jakub Jirsak / Dreamstime.com
Na wynos:
Prowadzący Eric Kavanagh omawia analizy dużych zbiorów danych z ekspertami branżowymi.
Eric: Panie i panowie, to koniec 2014 roku - przynajmniej prawie. To nasz ostatni webcast roku, ludzie! Witamy w TechWise! W rzeczy samej! Nazywam się Eric Kavanagh. Będę waszym moderatorem wspaniałego webcastu, ludzie. Jestem bardzo podekscytowana. Mamy dwóch wspaniałych analityków online i dwie świetne firmy - prawdziwych innowatorów w całym ekosystemie dużych zbiorów danych. Będziemy rozmawiać o tym, że kluczem do analizy dużych zbiorów danych jest zrozumienie różnicy. Więc chodźmy i zanurzmy się, ludzie.
Mamy kilku prezenterów. Jak widać, naprawdę jest Twój. Mike Ferguson dzwoni z Wielkiej Brytanii, gdzie musiał uzyskać specjalne przywileje, aby zostać w swoim biurowcu tak późno. Tak późno jest dla niego. Mamy doktora Robina Bloora, naszego własnego głównego analityka w Bloor Group. Będziemy mieć George'a Corugedo, CEO i współzałożyciela RedPoint Global, oraz Keitha Renisona, Senior Architect Architect z SAS Institute. To fantastyczne firmy, ludzie. Są to firmy, które są naprawdę innowacyjne. I zagłębimy się w dobre rzeczy z tego, co dzieje się teraz w całym świecie dużych zbiorów danych. I spójrzmy prawdzie w oczy, małe dane nie zniknęły. I do tego pozwólcie, że przedstawię moje streszczenie tutaj.
Tak więc istnieje stare francuskie wyrażenie: „Im bardziej rzeczy się zmieniają, tym bardziej pozostają takie same”. Spójrzmy teraz na kilka faktów - duże zbiory danych nie rozwiążą problemów małych danych. Małe korporacyjne dane wciąż tam są. Wciąż jest wszędzie. To paliwo operacyjne dla dzisiejszej gospodarki informacyjnej. A duże zbiory danych stanowią komplement dla tych tak zwanych małych danych korporacyjnych, ale nie zastępują małych danych. Nadal będzie w pobliżu. Lubię wiele rzeczy o dużych danych, szczególnie takich jak dane generowane maszynowo.
A dzisiaj prawdopodobnie porozmawiamy trochę o danych w mediach społecznościowych, które są również bardzo przydatne. A jeśli na przykład pomyślisz o tym, jak społeczność zmieniła biznes, pomyśl o trzech szybkich witrynach tutaj: LinkedIn i. Pomyśl o tym, że pięć lat temu nikt nie robił takich rzeczy. jest absolutną żonglerką w dzisiejszych czasach. oczywiście jest ogromny. Jest olbrzymi. LinkedIn jest de facto standardem sieci korporacyjnych i komunikacji. Witryny te są ogromne i aby móc wykorzystać zawarte w nich dane, ożywi niektóre funkcje zmieniające grę. To naprawdę przyniesie wiele korzyści wielu organizacjom - przynajmniej tym, które z nich korzystają.
Bez błędów, bez stresu - Twój przewodnik krok po kroku do tworzenia oprogramowania zmieniającego życie bez niszczenia życia
Nie możesz poprawić swoich umiejętności programistycznych, gdy nikt nie dba o jakość oprogramowania.
Zatem zarządzanie - zarządzanie wciąż ma znaczenie. Ponownie duże zbiory danych nie niwelują potrzeby zarządzania. Szczerze mówiąc, istnieje zupełnie nowa potrzeba skupienia się na zarządzaniu światem dużych zbiorów danych. W jaki sposób upewniasz się, że masz swoje procedury i zasady; że odpowiednie osoby uzyskują dostęp do właściwych danych; że masz kontakty, masz tu rodowód? W rzeczywistości wiesz, skąd pochodzą dane, co się z nimi stało. I to wszystko się zmienia.
Jestem pod wielkim wrażeniem tego, co zobaczyłem w tym nowym świecie, wykorzystując ekosystem Hadoop, który pod względem funkcjonalności jest czymś znacznie więcej niż pamięcią masową. Hadoop to także silnik obliczeniowy. A firma musi dowiedzieć się, jak wykorzystać tę moc obliczeniową, tę zdolność przetwarzania równoległego. Będą robić naprawdę fajne rzeczy. Dowiemy się o tym dzisiaj.
Inną rzeczą, o której należy wspomnieć, o czym dr Bloor mówił w niedawnej przeszłości, jest to, że fala innowacji się nie skończyła. Widzieliśmy więc dużo uwagi wokół Hadoop. Widzieliśmy takie firmy jak Cloudera i Hortonworks, wiesz, naprawdę robiące fale. I szczerze mówiąc rozwijają partnerstwa z firmami na telefon. I rozwijają współpracę z wieloma ludźmi. Ale fala innowacji się nie skończyła. Z Fundacji Apache powstaje coraz więcej projektów, które zmieniają nie tylko punkt końcowy, jeśli chcesz - aplikacje, z których ludzie korzystają - ale samą infrastrukturę.
Cały ten rozwój YARN - kolejnego negocjatora zasobów - naprawdę przypomina system operacyjny dla dużych zbiorów danych. I to jest wielka, wielka sprawa. Zatem dowiemy się, jak to również zmienia rzeczy. Tak więc, kilka drobnych oczywistych rad tutaj, uważaj na długie kontrakty naprzód, wiesz, pięcio-, dziesięcioletnie kontrakty będą falą, ścieżką, która wydaje mi się. Będziesz chciał uniknąć blokady za wszelką cenę. Dowiemy się o tym wszystkim dzisiaj.
Tak więc naszym pierwszym analitykiem przemawiającym dzisiaj - naszym pierwszym mówcą całego programu jest Mike Ferguson, dzwoniący z Wielkiej Brytanii. Dzięki temu dam ci klucze, Mike, i pozwolę ci je zabrać. Mike Ferguson, podłoga jest twoja.
Mike, jesteś tam? Możesz być wyciszony. Nie słyszę go. Być może będziemy musieli do niego oddzwonić. A my przejdziemy prosto do slajdów Robin Bloor. Robin, zajmę tutaj pozycję biednego Mike'a Fergusona. Pójdę na chwilę.
Czy to ty, Mike? Możesz nas usłyszeć? Nie Myślę, że najpierw musimy iść naprzód i iść z Robinem. Więc poczekajcie, ludzie. W ciągu kilku minut również ściągnę tutaj linki do slajdów. W związku z tym daję klucze Robin Bloor. Robin, możesz iść pierwszy zamiast Mike'a, a ja zadzwonię do Mike'a za sekundę.
Robin: Dobra.
Eric: Poczekaj, Rob. Pozwól, że pójdę naprzód i przygotuję ci slajd, Rob. To zajmie chwilę.
Robin: Dobra.
Eric: Tak. Możesz tu jednak porozmawiać o tym, z czym mamy do czynienia, jeśli chodzi o zarządzanie. Wiem, że porozmawiasz o zarządzaniu. Zazwyczaj myśli się o tym w kontekście małych danych korporacyjnych. Więc teraz mam slajd, Robin. Nic nie ruszaj. I proszę bardzo. Podłoga jest twoja. Zabierz to.
Robin: Dobra. Tak. To znaczy, cóż, wcześniej ustaliliśmy, że Mike będzie mówił o stronie analitycznej, a ja o stronie zarządzania. Do pewnego stopnia zarządzanie postępuje zgodnie z analizami w tym sensie, że jest to powód, dla którego robisz duże zbiory danych, a powodem, dla którego gromadzisz całe oprogramowanie do analizy, jest właśnie ta wartość.
Jest problem. Problem polega na tym, że dane muszą być przekłamane. Dane muszą zostać zebrane. Dane muszą być zebrane i zarządzane w sposób umożliwiający przeprowadzenie analizy z pełnym zaufaniem - tak mi się wydaje. Pomyślałem więc, że porozmawiam o stronie równania dotyczącej zarządzania. Myślę, że tak naprawdę trzeba powiedzieć, że zarządzanie było już problemem. Zarządzanie było już problemem i zaczyna być problemem w całej grze w hurtowni danych.
To, co się faktycznie wydarzyło, jest przekształcone w znacznie większy problem. I powód, dla którego zamienił się w znacznie większy problem, a także więcej danych, ale to są naprawdę powody. Liczba źródeł danych dramatycznie wzrosła. Wcześniej źródła danych, które mieliśmy, były zasadniczo definiowane przez wszystko, co zasilało hurtownię danych. Hurtownia danych byłaby zwykle zasilana przez systemy RTP. Możliwe jest trochę zewnętrznych danych, niewiele.
Teraz przeszliśmy do świata, w którym, jak wiesz, właśnie powstaje rynek danych, a zatem będzie handel danymi. Masz już mnóstwo różnych źródeł strumieniowego przesyłania danych, które możesz faktycznie wprowadzić do organizacji. Mamy dane z mediów społecznościowych, które je zabrały, że tak powiem, zdjęte na własny rachunek. Mam na myśli, że ogromna część wartości w serwisach społecznościowych to tak naprawdę informacje, które agregują, a zatem mogą udostępniać je ludziom.
Odkryliśmy też, no wiesz, jakby już istnieli. Mieliśmy już te pliki dziennika, wraz z pojawieniem się Splunk. I wkrótce stało się oczywiste, że w pliku dziennika jest wartość. Tak więc w organizacji istniały dane - które moglibyśmy nazwać nowymi źródłami danych, a także źródłami zewnętrznymi. To jedno. A to naprawdę oznacza, że niezależnie od zasad zarządzania danymi, które mieliśmy wcześniej, będą musiały zostać rozszerzone, w taki czy inny sposób, i będą musiały zostać rozszerzone, aby faktycznie rządzić dane. Ale teraz zaczynamy się gromadzić w taki czy inny sposób.
I w dół tej listy mamy streaming i szybkość dostarczania danych. Myślę, że jednym z powodów popularności Hadoop jest to, że można go właściwie wykorzystać do przechwytywania dużej ilości danych. Może także przyjmować prędkość danych, że jeśli nie trzeba jej natychmiast używać, jest to ładne równoległe, ogromne równoległe środowisko. Ale masz również fakt, że teraz odbywa się spora liczba analiz strumieniowych. Kiedyś były to tylko sektory bankowe, które były zainteresowane aplikacjami do przesyłania strumieniowego, ale teraz stały się jakby globalne. I wszyscy patrzą na aplikacje strumieniowe w taki czy inny sposób, potencjalny sposób czerpania wartości z danych i przeprowadzania analiz dla organizacji.
Mamy nieustrukturyzowane dane. Statystyka, zwykle stanowiąca część tylko 10% danych na świecie, znajdowała się w relacyjnych bazach danych. Jednym z głównych powodów tego był fakt, że w rzeczywistości był on nieuporządkowany i był - znaczna część tego była dostępna w Internecie, ale prawie rozrzucona po różnych stronach internetowych. Dane te okazały się również możliwe do przeanalizowania, a także przydatne. Wraz z pojawieniem się technologii Symantec, która stopniowo wkrada się w sytuację, staje się coraz bardziej.Tak więc istnieje potrzeba gromadzenia danych nieuporządkowanych i zarządzania nimi, a to oznacza, że są znacznie większe niż wcześniej. Mamy dane społecznościowe, o których już wspomniałem, ale najważniejsze jest to, że prawdopodobnie trzeba je wyczyścić.
Mamy dane Internetu rzeczy. To rodzaj innego rodzaju sytuacji. Prawdopodobnie będzie ich dużo, ale wiele z nich będzie musiało pozostać rozprowadzonych gdzieś w pobliżu miejsca, w którym prowadzi. Ale będziesz także chciał, w ten czy inny sposób, przyciągnąć go, aby przeprowadzić analizę danych w organizacji. To dodaje kolejny czynnik. I te dane będą miały inną strukturę, ponieważ prawdopodobnie - będą prawdopodobnie sformatowane w JSON lub XML, aby się zadeklarować. I nie tylko, w taki czy inny sposób, że w rzeczywistości pobieramy dane i jesteśmy w stanie wykonać pewien schemat podczas odczytu tego konkretnego elementu danych.
Mamy problem pochodzenia, a jest to problem analityczny. Wyniki jakiejkolwiek analizy, którą przeprowadzasz, naprawdę nie mogą być - jeśli chcesz - zatwierdzone, uznane za ważne, chyba że znasz pochodzenie danych. Chodzi mi o to, że jest to po prostu profesjonalizm pod względem aktywności naukowców danych. Ale wiesz, aby uzyskać pochodzenie danych, oznacza to, że faktycznie musimy zarządzać danymi i przechowywać notatkę na temat ich pochodzenia.
Mamy problem z zasilaniem komputera i podobieństwami, a wszystko to przyspiesza. Problem polega na tym, że oczywiście niektóre procesy, które wprowadziliśmy, mogą być zbyt wolne dla wszystkich innych. Możliwe są niedopasowania prędkości.
Mamy nadejście uczenia maszynowego. Uczenie maszynowe powoduje, że analityka jest inną grą niż była wcześniej. Ale naprawdę możesz go używać tylko wtedy, gdy masz moc.
Dostaliśmy fakt nowych obciążeń analitycznych. Mamy równoległy świat i niektóre algorytmy analityczne muszą być wykonywane równolegle, aby uzyskać maksymalny efekt. Dlatego problem polega na tym, w jaki sposób faktycznie, w ten czy inny sposób, przepychasz dane, udostępniasz je, jeśli są dostępne. I gdzie faktycznie wykonujesz obciążenia analityczne, ponieważ możesz to robić w bazie danych. Być może robisz to w aplikacjach analitycznych.
Istnieje więc cała seria wyzwań związanych z zarządzaniem. To, co zrobiliśmy w tym roku - badania, które przeprowadziliśmy w tym roku, dotyczyły naprawdę architektury big data. A kiedy faktycznie próbujemy to uogólnić, wniosek, do którego doszliśmy - schemat, który wymyśliliśmy, wyglądał bardzo podobnie.
Nie zamierzam się tym zajmować, zwłaszcza, że Mike zrobi sporo na temat architektury danych dla celów analitycznych. Ale tak naprawdę lubię, żeby ludzie po prostu się skupiali na tym dolnym obszarze, w którym w taki czy inny sposób gromadzimy dane. Mamy coś, o czym chciałbym się odnieść, to rafineria danych lub centrum przetwarzania danych. I tam właśnie odbywa się zarządzanie. Więc wiesz, jeśli w pewnym stopniu się skupimy, wygląda to tak. Wiesz, jest zasilany danymi ze źródeł wewnętrznych i zewnętrznych. Centrum powinno teoretycznie obejmować wszystkie generowane dane. Powinien być albo przesyłany strumieniowo i zarządzany, ponieważ jest przesyłany strumieniowo, jeśli potrzebujesz analiz i danych przesyłanych strumieniowo, a następnie przekazywany do centrum. W przeciwnym razie wszystko znajdzie się w centrum. I dzieje się wiele rzeczy - dzieje się to w centrum. I nie możesz mieć pewnej ilości analiz i SQL w centrum. Ale potrzebujesz także wirtualizacji danych w każdej komórce, aby przekazywać dane do innych obszarów. Ale zanim coś takiego się wydarzy, faktycznie musisz w ten czy inny sposób dopracować przygotowanie danych. Możesz to nazwać przygotowaniem danych. Jest znacznie większy. To są rzeczy, które moim zdaniem obejmują.
Mamy zarządzanie systemem i zarządzanie usługami, w pewnym sensie, że jest to główna część warstwy danych, wtedy faktycznie musimy zastosować wszystkie systemy zarządzające wysiłkiem zarządzania systemem operacyjnym, które tradycyjnie wkładaliśmy w prawie wszystkie systemy operacyjne. Ale musimy w ten czy inny sposób monitorować inne rzeczy, aby upewnić się, że te różne poziomy usług są spełnione, ponieważ muszą zostać zdefiniowane poziomy usług lub jakikolwiek rodzaj analizy jako działania, lub dane BI są być ściganym.
Potrzebujemy monitorowania wydajności i zarządzania. Jeśli jeszcze, potrzebujemy tego, aby wiedzieć, jakie dalsze zasoby komputerowe będziemy musieli alokować w różnych momentach. Ale w rzeczywistości jest tutaj naprawdę dużo pracy, dość skomplikowane i konkurujące ze sobą o zasoby. W tym obszarze należy zrobić coś bardzo zaawansowanego.
Mamy teraz cykl życia danych w sposób, którego nigdy wcześniej nie mieliśmy. Umowa naprawdę jest ponad wszystko, że nie zbieraliśmy danych i nie wyrzucaliśmy ich wcześniej. Zbieraliśmy potrzebne dane i prawdopodobnie je przechowywaliśmy, a następnie archiwizujemy. Ale okropnie dużo z tego, co będziemy robić odtąd, to badanie danych. A jeśli nie chcesz danych, zakopmy je. Tak więc cykle życia danych różnią się w zależności od sytuacji, ale będą też znacznie bardziej agregacją danych. Dlatego wiesz, wiedząc, skąd pochodzi agregat, z czego… jakie jest źródło agregacji itd. I tak dalej. To wszystko jest konieczne.
Linia danych oczywiście w naturalny sposób. Bez tego musisz znać problemy, więc dane… Musimy wiedzieć, że dane są prawidłowe, ale z tym, jak wiarygodne są w rzeczywistości.
Mamy również mapowanie danych, ponieważ tak naprawdę wiele danych będzie w ten czy inny sposób. I to, jeśli chcesz, dotyczy to do pewnego stopnia w MDM. Po prostu jest teraz o wiele bardziej skomplikowane, ponieważ gdy masz okropnie dużo danych zdefiniowanych przez JSON lub opartych na naszym schemacie XML podczas odczytu, będziesz musiał w ten czy inny sposób być bardzo aktywny trwa mapowanie danych.
Istnieje sytuacja zarządzania metadanymi, która jest czymś więcej niż MDM, ponieważ istnieje potrzeba, w taki czy inny sposób, zbudowania tego, co chciałbym teraz myśleć o czymś w rodzaju magazynu metadanych wszystkiego, co cię interesuje. Są metadane odkrycie, ponieważ niektóre dane niekoniecznie będą miały deklarowane metadane, a my chcemy je natychmiast wykorzystać. A potem jest czyszczenie danych, co jest ogromną rzeczą, jak szereg rzeczy, które można tam zrobić. A także bezpieczeństwo danych. Wszystkie te dane muszą być zabezpieczone do akceptowalnego poziomu, co może nawet oznaczać w niektórych przypadkach - na przykład szyfrowanie wielu wartości.
Całe to obciążenie pracą to tak naprawdę imperium rządów. Wszystko to, w taki czy inny sposób, musi odbywać się w tym samym czasie lub wcześniej, cała nasza działalność analityczna. Jest to duża liczba skoordynowanych aplikacji. Jest to system sam w sobie. A potem ci, którzy tego nie robią w różnych momentach, będą cierpieć na ich brak w miarę postępów, ponieważ okropna większość tych rzeczy nie jest tak naprawdę opcjonalna. Skończysz z rosnącą entropią, jeśli tego nie zrobisz.
Jeśli chodzi o analizę danych i zarządzanie nimi, powiedziałbym, że tak naprawdę jedna ręka myje drugą. Bez zarządzania, analityka i BI nie zmieniłyby się w czasie. Bez analiz i analiz biznesowych zarządzanie danymi nie byłoby potrzebne. Tak więc dwie rzeczy naprawdę idą w parze. Jak mówią na Bliskim Wschodzie: „Jedna ręka myje drugą”. I to właściwie wszystko, co muszę powiedzieć. Mam nadzieję - mam nadzieję, że teraz odzyskaliśmy Mike'a.
Eric: Robimy. Mike, zakładam, że tam jesteś. Popchnę twój slajd w górę.
Mike: Jestem. OK, słyszysz mnie?
Eric: Tak, słyszę cię. Brzmisz cudownie. Pozwólcie, że przedstawię… Proszę bardzo. A ty jesteś teraz prezenterem. Zabierz to.
Mike: Dobra, dziękuję! Dzień dobry, dzień dobry, dobry wieczór wszystkim z was. Na początku wybacz czkawkę. Z jakiegoś powodu zostałem wyciszony i widzę wszystkich, ale oni mnie nie słyszeli.
W porządku. Chcę więc szybko porozmawiać o ekosystemie analitycznym Big Data. Jeśli chcesz zadać mi pytanie, powiem, w tej sesji lub później, możesz mnie zdobyć, korzystając z moich danych kontaktowych tutaj. Jak powiedziałem, w środku nocy tutaj, w Wielkiej Brytanii.
Cóż, pozwól mi przejść do tego, o czym chcę rozmawiać. Wyraźnie widać, że w ciągu ostatnich kilku lat pojawiły się wszelkiego rodzaju nowo odkryte typy danych, które firmy chcą teraz analizować - od danych typu Clickstream po zrozumienie zachowań online, dane w mediach społecznościowych, o których mówił Eric na początek programu tutaj. Myślę, że Robin wspomniał o JSON, BSON, XML - a więc częściowo ustrukturyzowanych danych, które same się opisują. Oczywiście mamy też mnóstwo innych rzeczy - od nieustrukturyzowanych danych, dzienników infrastruktury IT, danych czujników. Wszystkie te stosunkowo nowe źródła danych, którymi interesują się teraz firmy, ponieważ zawierają cenny wgląd, który może potencjalnie pogłębić to, co wiemy.
Oznacza to w zasadzie, że krajobraz analityczny wykroczył poza tradycyjną hurtownię danych. Nadal konstruujemy dane w świecie kombinacji danych ustrukturyzowanych i wieloustrukturalnych, w których dane ustrukturyzowane mogą pochodzić z wewnątrz lub z zewnątrz przedsiębiorstwa w wielu przypadkach. W wyniku tych nowych typów danych i nowych potrzeb do analizy zauważyliśmy pojawienie się nowych obciążeń analitycznych - wszystko od analizy danych w ruchu, które odwracają tradycyjną architekturę hurtowni danych w pewnym sensie, tam gdzie my , w tradycyjnych kręgach integruj dane, czyść je, przekształcaj, przechowuj i analizuj. Ale analizując dane w ruchu, przechwytujemy je, integrujemy, przygotowujemy, analizując, a następnie przechowujemy. Tak więc trwa analiza danych, zanim zostaną one gdziekolwiek zapisane.
Kompleksowo analizujemy ustrukturyzowane dane, być może w celu opracowania modelu, opracowania statystycznego i predykcyjnego modelu, co nie jest niczym nowym dla niektórych osób w tradycyjnej przestrzeni do przechowywania danych. Mamy analizę eksploracyjną danych modelowych. To ilość ustrukturyzowanych danych. Mamy nowe obciążenia w postaci analizy graficznej, która dla moich klientów w usługach finansowych obejmuje takie rzeczy, jak oszustwa. Obejmuje również bezpieczeństwo cybernetyczne. Obejmuje to oczywiście sieci społecznościowe, rozumienie wpływowych osób i tego typu rzeczy. Nawet opanowałem to w zarządzaniu, ma kilka lat analizy grafów.
Mamy optymalizację hurtowni danych lub odciążenie przetwarzania ETL, co jest raczej rodzajem zastosowania IT, CIO może to sfinansować. A nawet archiwizowanie danych i hurtowni danych, aby zachować je online w takich rzeczach, jak Hadoop. Tak więc wszystkie te nowe obciążenia analityczne dodały nowe platformy, nowe platformy pamięci masowej, do krajobrazu analitycznego. Więc zamiast zwykłych hurtowni danych, centrów danych, mamy teraz Hadoop. Mamy bazy danych NoSQL, takie jak bazy danych grafów, które są często używane do obciążeń analitycznych. Oczywiście możemy teraz przeprowadzić analizę grafów na samym Hadoop, a także na DBMSach graficznych NoSQL. Mamy analizy strumieniowe, o których wspomniał Robin. I mamy - jeśli chcesz - budowanie modeli, być może również na urządzeniach do hurtowni danych analitycznych. Wszystko to jednak skomplikowało krajobraz analityczny, ponieważ obecnie potrzebnych jest wiele platform. Wydaje mi się, że wyzwaniem dla każdej firmy z front-office lub back-office lub finansami, zaopatrzeniem, HR i jakimś rodzajem operacji jest ustalenie, które projekty analityczne są związane z tradycyjną sceną hurtowni danych. A gdy już wiesz, że projekty analityczne są powiązane z tymi nowymi platformami big data i gdzie je uruchomić, wiesz, które obciążenie analityczne, ale nie tracąc z oczu biznesu w tym sensie, że - teraz zobaczysz, że jest to połączenie dużej projekty analityczne danych i tradycyjne projekty hurtowni dużych zbiorów danych, które razem są potrzebne do wzmocnienia wewnątrz klienta lub wokół operacji, wokół ryzyka, finansów lub stabilności. Dlatego chcemy, aby wszystkie te były zgodne z naszymi strategicznymi priorytetami biznesowymi, abyśmy byli na dobrej drodze, aby wbić igły, które należy wcisnąć, aby poprawić wydajność biznesową, aby obniżyć koszty, w celu zmniejszenia ryzyka itp. dla całej naszej firmy. Tak więc nie jest tak, że jedno tutaj zastępuje drugie dużym i tradycyjnym. Oba są używane razem. To dramatycznie zmienia architekturę.
Mam tutaj relatywnie nową architekturę, której będę używać z moimi klientami. I tak, jak widać teraz u dołu, szeroki zakres źródeł danych, nie tylko już uporządkowanych. Niektóre z nich przesyłają strumieniowo dane na żywo, takie jak czujniki, takie jak dane rynkowe, tego typu rzeczy. Mogą to być nawet bieżące dane kliknięcia. Mogą to być dane przesyłane strumieniowo na żywo. Więc to nie musiało być zorganizowane. Możemy więc przetwarzać strumienie tych danych, aby podejmować automatyczne działania w czasie rzeczywistym, a wszelkie dane, które są interesujące, można filtrować i przekazywać do narzędzi zarządzania informacjami w przedsiębiorstwie, które można wykorzystać do zapełnienia analitycznych magazynów danych. O ile nie widać tego w tym miksie, teraz mamy tradycyjne hurtownie danych, bazy danych Hadoop i NoSQL. W mieszance mamy również zarządzanie danymi podstawowymi. A to wywiera większą presję na cały zestaw narzędzi do zarządzania danymi, nie tylko w celu zapełniania tych magazynów danych, ale także przenoszenia danych między nimi.
Ponadto musimy uprościć narzędzia dostępu. Nie możemy po prostu zwrócić się do użytkownika i powiedzieć: „weź wszystkie te magazyny danych, trzymaj te interfejsy API - twój problem”. Musisz uprościć dostęp. I tak, jakby w kropkowanych liniach, zobaczysz, że wirtualizacja i optymalizacja danych w pewnym sensie ukrywają złożoność przechowywania wielu danych, spróbuj ułatwić użytkownikom końcowym dostęp do tego. Oczywiście, na górze jest szereg narzędzi - wszystko, od tradycyjnych narzędzi BI, które zaczęły się od początku w hurtowni danych, stopniowo przesuwając się w kierunku lewej części wykresu, aby połączyć się z Hadoops a następnie bazy danych NoSQL świata.
Mamy wyszukiwarkę, która zyskuje nowe życie, szczególnie wokół uporządkowanych, nieustrukturyzowanych danych, które często są przechowywane w Hadoop. Mamy niestandardowe aplikacje analityczne do wykonania na platformie Hadoop z MapReduce, na przykład platformą Spark. Mamy narzędzia analizy wykresów, które pozwalają skupić się na bardzo specyficznych obciążeniach. Tak więc szereg narzędzi i przepływ danych są również bardziej złożone. To już nie jest jednokierunkowa ulica w hurtowni danych. Oczywiście są to teraz dane podstawowe.
Nadchodzą nowe źródła danych, albo przechwytywane w NoSQL, wiesz, takie sklepy danych jak MongoDB, jak Cassandra, jak HBase. Dostarczamy dane bezpośrednio do Hadoop w celu ich analizy i przygotowania. Mamy nowe informacje o Hadoop i hurtowniach danych. Mamy archiwum wychodzące z hurtowni danych do Hadoop. Teraz mamy źródła danych do, no wiesz, wszystkich baz danych NoSQL i martsów danych. Widzimy tutaj, że zarządzanie danymi trwa znacznie więcej. A to oznacza, że wywiera znaczną presję na oprogramowanie do zarządzania danymi. To już nie jest tylko ulica jednokierunkowa. To dwukierunkowy przepływ danych. Trwa o wiele więcej aktywności, dlatego skalowalność jest ważna zarówno z przodu narzędzia do zarządzania danymi, jak i ze źródła danych.
Tak więc ta tabela wraca do architektury, o której wspomniałem przed chwilą. Pokazuje różne obciążenia analityczne działające w różnych częściach tej architektury. Coś w lewym dolnym rogu, masz transmisję strumieniową w czasie rzeczywistym, przetwarzanie strumieniowe danych przychodzących z, no wiesz, dowolnego rodzaju magazynu danych na żywo. Mamy analizę klas w bazach danych graficznych NoSQL. Może się również zdarzyć na Hadoop. Na przykład dzięki platformie Spark i GraphX mamy analizę dochodzeniową i rafinerię danych, o których Robin mówił o wydarzeniach na Hadoop. Wciąż trwają tradycyjne obciążenia i hurtownie danych, wiesz, zaawansowani użytkownicy budują modele statystyczne i predykcyjne, być może na urządzeniach hurtowni danych. Nadal staramy się uprościć dostęp do tego wszystkiego, aby ułatwić użytkownikom końcowym.
Tak więc sukces w całym tym zestawie jest czymś więcej niż tylko stroną analityczną. Wiesz, możemy wprowadzić platformy analityczne, ale jeśli nie możemy przechwytywać i przetwarzać danych o dużej prędkości i objętości na skali, nie ma większego sensu. Wiesz, nie mam nic do analizy. Tak więc sukces analizy dużych zbiorów danych wymaga skalowania systemów operacyjnych. Oznacza to, że aby móc obsługiwać nowe transakcje, wiesz, szczyty. Wiesz, wszelkie przechwytywane dane nietransakcyjne mogą być bardzo nowe, bardzo wysokie wskaźniki przybycia na danych o dużej prędkości, takich jak czujniki lub każde pobranie. Musimy być w stanie zaspokoić to wszystko - aby móc przechwycić tego rodzaju dane i wprowadzić je do analizy. Musimy również skalować same analizy, uprościć dostęp do danych, o których już wspomniałem. A potem zawiąż to. Wiesz, musimy być w stanie udoskonalić te systemy operacyjne, aby uzyskać zamkniętą pętlę.
Zatem skalowanie strony operacyjnej domu w celu przechwytywania danych przenosi świat bazy danych NoSQL. Mam tutaj na myśli pięć kategorii bazy danych NoSQL. Ta kategoria zostanie wymodelowana jako kombinacja pozostałych czterech powyżej. Zasadniczo, jego kluczowe wartości, przechowywane dokumenty i bazy danych rodzin kolumn - tam pierwsze trzy - które są w pewnym sensie wykorzystywane do bardziej transakcyjnych i nietransakcyjnych danych.
Niektóre bazy danych obsługujące jako właściwości; niektóre z nich nie. Niemniej jednak wiesz, że wprowadzamy takie, które umożliwiają skalowanie tego rodzaju aplikacji. I tak na przykład, ponieważ odeszliśmy od pracowników, którzy dokonują transakcji na klawiaturze, do klientów i mas używających nowatorskich urządzeń, aby to zrobić. Zauważyliśmy ogromny wzrost liczby transakcji zawieranych w przedsiębiorstwach. W tym celu musimy skalować aplikacje transakcyjne.
Ogólnie rzecz biorąc, można to zrobić na bazach danych NewSQL jako pokazanej tutaj relacyjnej bazie danych, takiej jak NuoDB i VoltDB. Lub niektóre bazy danych NoSQL, które być może obsługują właściwości ACID, które mogą gwarantować przetwarzanie transakcji, mogą być w grze. Odnosi się to również do danych nietransakcyjnych, takich jak dane koszyka zakupów przed transakcją, wiesz, zanim ludzie kupią rzeczy, dane czujnika, wiesz, ponieważ tracę odczyt czujnika wśród setek milionów odczytów czujnika. To nic wielkiego. Kliknięcia, wiesz, w świecie strumienia kliknięć - jeśli używam kliknięcia, to nic wielkiego.Tak więc, wiesz, niekoniecznie musimy mieć tam właściwości ACID, i tam często wchodzą bazy danych NoSQL, właśnie tam - ta zdolność do wykonywania bardzo wysokiego, właściwego przetwarzania na dużą skalę w celu przechwytywania tych nowych rodzajów danych.
Jednocześnie chcemy, aby analityka była skalowana. I tak wyciąganie danych z magazynów danych na platformy analityczne nie będzie już hakować, ponieważ dane są zbyt duże. Tak naprawdę chcemy przesunąć dane analityczne w drugą stronę, do hurtowni danych przedsiębiorstwa do Hadoop, do przetwarzania strumieniowego, aby móc przekazać dane analityczne do danych. Jednak fakt, że ktoś mówi, że jest to w analizie baz danych lub w analizie Hadoop, niekoniecznie oznacza, że analizy są wykonywane równolegle. I szczerze mówiąc, jeśli zamierzasz zainwestować w te nowe, masowo równoległe, skalowalne technologie, takie jak Hadoop, takie jak urządzenia hurtowni danych i tak dalej, takie jak klastrowe silniki przetwarzania strumieniowego, potrzebujemy równoległej analizy.
To tylko kasy. Wiesz, jeśli mamy dane analityczne, które pomagają przewidywać rzeczy dla klientów, operacji, ryzyka itp., Chcemy, aby działały równolegle, a nie tylko na platformie. Chcemy obu. A to dlatego, że wiesz, technologia jest podobna do tych nowych narzędzi do odkrywania wizualnego, takich jak SAS. To właściwie jeden z naszych sponsorów tutaj.
Jedną rzeczą, której ludzie chcą, jest przynajmniej wykorzystanie tych w Hadoop, a następnie w analizie baz danych. Chcemy, aby działały one równolegle, aby były w stanie zapewnić wymaganą wydajność na tak dużych ilościach danych. Jednocześnie staramy się uprościć dostęp do tego wszystkiego. Tak więc SQL jest teraz ponownie na porządku dziennym. Wiesz, SQL jest - SQL na Hadoop jest teraz gorący. Śledzę go teraz w 19 inicjatywach SQL i Hadoop. Dodatkowo, widzimy, możemy uzyskać te dane, wiesz, na wiele sposobów, aby bezpośrednio uzyskać dostęp do SQL na samym Hadoop, możemy przejść SQL do indeksu wyszukiwania. W ten sposób, jak wiesz, niektórzy dostawcy wyszukiwania w tej przestrzeni, możemy mieć dostęp SQL do analitycznych relacyjnych baz danych, które mają tabele Excel do Hadoop.
Możemy teraz mieć dostęp SQL do serwera wirtualizacji danych, który sam może być następnie podłączony do hurtowni danych w Hadoop. Już teraz zaczynam widzieć pojawienie się dostępu SQL do danych przesyłanych strumieniowo na żywo. Dostęp SQL do tego wszystkiego szybko rośnie. Wyzwanie polega na tym, że dostęp do SQL jest tam sprzedawany. Pytanie brzmi: czy SQL radzi sobie ze złożonymi danymi? I to niekoniecznie jest proste. Są tutaj różnego rodzaju komplikacje, w tym fakt, że dane JSON można zagnieżdżać. Możemy mieć rekordy wariantów schematu. Tak więc pierwszy rekord ma jeden schemat. Drugi rekord ma inny schemat. Te rzeczy bardzo różnią się od tego, co dzieje się w relacyjnym świecie.
Musimy więc zadawać pytania na temat tego, jakie dane próbujemy przeanalizować i jakie są cechy analityczne. Czy to wiesz panel, który chcesz zrobić? Czy to uczenie maszynowe? Czy to analiza graficzna? Czy możesz to zrobić z SQL? Wiesz, czy jest to możliwe do wywołania z SQL? Ilu użytkowników jednocześnie to robi? Wiesz, mamy setki jednoczesnych użytkowników. Czy to możliwe w przypadku złożonych danych? Wiesz, wszystkie te rzeczy są kluczowymi pytaniami. Tak więc stworzyłem listę kilku, które moim zdaniem powinieneś rozważyć. Wiesz, jakie formaty plików? O jakich typach danych mówimy? Jakie funkcje analityczne możemy wywołać z SQL, aby uzyskać dostęp do złożonych danych? I rodzaj funkcji działa równolegle. To znaczy, muszą działać równolegle, jeśli musimy mieć możliwość skalowania. Czy mogę dołączyć do danych w Hadoop dzisiaj poza nimi, czy to nie jest wykonalne? A co zrobię z tymi wszystkimi rodzajami obciążeń związanych z zapytaniami?
Jak zobaczymy, z tego, co widziałem, jest wiele różnic w dystrybucji SQL i Hadoop. Wszystkie te śledzę. A tak przy okazji, to czysty SQL na Hadoop. W tym momencie nie obejmuje to nawet wirtualizacji danych. I tak, dużo tam i dużo miejsca na konsolidację, co, jak sądzę, nastąpi w ciągu przyszłego roku, około osiemnastu miesięcy. Ale otwiera się również inna sprawa, a mianowicie mogę mieć potencjalnie wiele silników SQL na tych samych danych w Hadoop. I tego nie można zrobić w relacjach.
Oczywiście oznacza to, że musisz wiedzieć, jaki rodzaj zapytania jest uruchamiany? Czy powinienem uruchamiać to wsadowo na konkretnym SQL w ramach inicjatywy Hadoop? Czy powinienem uruchamiać interaktywne zadania zapytań poprzez inny SQL z inicjatywy Hadoop itp., Aby wiedzieć, z którym się połączyć? Oczywiście nie powinniśmy tego robić. Powinniśmy po prostu zadać pytanie. Wiesz, jakiś optymalizator wymyśla najlepszy sposób, aby to zrobić. Ale moim zdaniem jeszcze tam nie jesteśmy.
Niemniej jednak wirtualizacja danych, o której wspomniałem wcześniej, odgrywa bardzo ważną rolę w upraszczaniu dostępu do wielu magazynów danych. A jeśli stworzymy nowe informacje na temat Hadoop, z pewnością możemy połączyć te dane z danymi i tradycyjne hurtownie danych, na przykład poprzez wirtualizację danych, bez konieczności przenoszenia danych z Hadoop do tradycyjnych hurtowni danych. Oczywiście możesz to zrobić. Jest to również prawdopodobne, jeśli zarchiwizuję dane z tradycyjnych hurtowni danych w Hadoop. Nadal mogę się do tego przyłączyć i wrócić do tego, co jest w naszej hurtowni danych, do wirtualizacji danych. Myślę więc, że wirtualizacja danych ma wielką przyszłość w tej ogólnej architekturze i upraszcza dostęp do wszystkich tych magazynów danych.
I nie zapominajmy, że kiedy tworzymy te nowe spostrzeżenia, niezależnie od tego, czy są to systemy relacyjne, czy NoSQL, nadal chcemy przywrócić te spostrzeżenia z powrotem do naszych operacji, abyśmy mogli zmaksymalizować wartość tego, co znaleźliśmy, abyśmy mogli wykorzystaj to, aby podejmować bardziej skuteczne i terminowe decyzje w tym środowisku, aby zoptymalizować naszą działalność.
Podsumowując, widzę, że potrzebujemy nowych źródeł danych. Mamy do dyspozycji nowe platformy o bardziej skomplikowanej architekturze. A Hadoop staje się bardzo, bardzo ważny, wystarczający do przygotowania danych dla naszych płynnych piaskownic, kwerendy archiwum, archiwum z hurtowni danych, zarządzania danymi, rozszerzając skrzydła, by wyjść poza hurtownię danych do zarządzania danymi na wszystkich tych platformach i nowych narzędzi w stanie analizować i uzyskiwać dostęp do danych w tych środowiskach, mieć skalowalne technologie w celu lepszego przetwarzania danych oraz skalować analizy poprzez zepchnięcie ich na platformy, aby uczynić je bardziej równoległymi. A potem, miejmy nadzieję, również, aby uprościć dostęp do wszystkich z nich poprzez pojawiający się SQL. To daje wyobrażenie o tym, dokąd zmierzamy. W związku z tym wrócę do, jak sądzę, Erica, prawda?
Eric: Dobra, to fantastycznie. I ludzie, muszę powiedzieć, między tym, co właśnie dostałeś od Robina i Mike'a, jest to prawdopodobnie tak kompleksowe i zwięzłe w przeglądzie całego krajobrazu od patrzenia na to, co znajdziesz wszędzie. Pozwólcie, że pójdę pierwszy i ustawię się w kolejce do George'a Corugedo. I oto jest. Pozwól mi wziąć to na chwilę. W porządku, George, mam zamiar wręczyć ci klucze i zabrać je. Podłoga jest twoja.
George: Świetnie! Dziękuję bardzo, Eric, i dziękuję, Rob i Mike. To była świetna informacja i wiele rzeczy, z którymi się zgadzamy. Wracając do dyskusji Robina, ponieważ, wiesz, to nie przypadek, że RedPoint jest tutaj i SAS jest tutaj. Ponieważ RedPoint, naprawdę koncentrujemy się na stronie danych na zarządzaniu, przetwarzaniu danych i przygotowaniu do użycia w analityce. Pozwólcie, że przejdę przez te dwa slajdy. Naprawdę mów i rozumiem punkt Robina na temat MDM i tego, jak ważny jest on i jak użyteczny, moim zdaniem - i naszym zdaniem - Hadoop może być w świecie MDM i jakości danych.
Wiesz, Robin mówił trochę o tym, w jaki sposób jest to związane ze światem hurtowni danych przedsiębiorstwa, a ja przyszedłem - wiesz, spędziłem kilka lat w Accenture. Co ciekawe, ile razy musieliśmy wchodzić do firm i próbować dowiedzieć się, co zrobić z hurtownią danych, która w zasadzie została porzucona. I wiele z tego się wydarzyło, ponieważ zespół hurtowni danych tak naprawdę nie dostosował swojej wersji do użytkowników biznesowych lub konsumentów danych. Albo zajęło to tak dużo czasu, że do czasu, kiedy je zbudowali, ewolucja zastosowania biznesowego lub uzasadnienia biznesowego.
Jedną z rzeczy, o których myślę, jestem bardzo podekscytowany, pomysł użycia Hadoop do zarządzania danymi głównymi, do jakości danych i ich przygotowania, to fakt, że zawsze możesz wrócić do danych atomowych w Jezioro danych Hadoop lub rezerwuar danych, repozytorium danych, hub lub dowolna forma buzza, której chcesz użyć. Ponieważ jednak zawsze przechowujesz te dane atomowe, zawsze masz możliwość ponownego dopasowania się do użytkowników biznesowych. Ponieważ jako analityk - ponieważ faktycznie rozpocząłem swoją karierę jako statystyk - wiesz, nie ma nic gorszego niż, wiesz, hurtownie danych korporacyjnych są świetne do generowania raportów, ale jeśli chcesz naprawdę przewidywać analizy, są one tak naprawdę nie jest to przydatne, ponieważ tak naprawdę potrzebne są szczegółowe dane behawioralne, które w jakiś sposób zostały podsumowane i zagregowane w hurtowni danych. Myślę więc, że to naprawdę ważna cecha, i myślę, że mogę się nie zgodzić z Robinem, że osobiście zostawiłbym dane w jeziorze danych lub centrum danych tak długo, jak to możliwe, ponieważ tak długo, jak dane są tam i są czyste, możesz na nie patrzeć z jednego kierunku, z innego kierunku. Możesz połączyć to z innymi danymi. Zawsze masz okazję wrócić do niego i dokonać restrukturyzacji, a następnie dostosować się do jednostki biznesowej i potrzeby, jakie może mieć ta jednostka.
Jedną z ciekawszych rzeczy na ten temat jest to, że ponieważ jest to tak potężna platforma obliczeniowa, wiele obciążeń, o których mówiliśmy, widzimy, jak wszystko idzie prosto do Hadoop. I chociaż myślę, że Mike mówił o wszystkich różnych technologiach dostępnych w świecie - w tego rodzaju ekosystemie dużych zbiorów danych, uważamy, że Hadoop naprawdę jest koniem robiącym tak dużą skalę przy intensywnym obliczeniowo przetwarzaniu, że wymagają danych podstawowych i jakości danych. Ponieważ, jeśli potrafisz to zrobić, wiesz, po prostu czysta ekonomia przenoszenia danych z drogich baz danych do ekonomicznych baz danych, tak naprawdę powoduje to tak duże zainteresowanie obecnie w dużych przedsiębiorstwach.
Teraz oczywiście są pewne wyzwania, prawda? Technologie wiążą się z wyzwaniami. Wiele z nich jest bardzo niedojrzałych. Powiedziałbym, no wiesz, nie wiem ile, ale wiele technologii, o których wspomniał Mike, wciąż są dostępne w wydaniach „zero-point”, prawda? Tak więc technologie te są bardzo młode, bardzo niedojrzałe, wciąż oparte na kodzie. A to naprawdę stanowi wyzwanie dla przedsiębiorstw. I naprawdę koncentrujemy się na rozwiązywaniu problemów na poziomie przedsiębiorstwa. Dlatego uważamy, że musi istnieć inny sposób, a my proponujemy inny sposób radzenia sobie z niektórymi rzeczami przy użyciu niektórych z tych bardzo powstających technologii.
I tak, a następnie inny interesujący problem, o którym wspomniano wcześniej, a mianowicie, gdy masz dane, które przechwytujesz w środowisku Hadoop dowolnego typu, wiesz, zwykle jest to schemat podczas odczytu, a nie schemat podczas zapisu z pewnymi wyjątkami. I to czytanie, dużo jest robione przez statystyków. I tak, statystycy muszą mieć narzędzia, które pozwolą im odpowiednio ustrukturyzować dane do celów analitycznych, ponieważ na koniec dnia, aby dane były użyteczne, trzeba je ustrukturyzować w jakiejś formie, aby je zobaczyć, odpowiedzieć na pytanie lub firma, jakiś rodzaj firmy, tworzą wartość biznesową.
W tym momencie mamy bardzo szeroką i dojrzałą aplikację EPL, główny klucz jakości danych ELT i aplikację do zarządzania. Istnieje na rynku od wielu, wielu lat. I ma całą funkcjonalność lub większą część funkcjonalności, którą Robin wymienił na tym okrągłym wykresie - wszystko od czystego surowego przechwytywania danych w wielu różnych formatach i strukturach XML i tym podobnych, do możliwości wykonania całego czyszczenia, uzupełnianie danych, korekta danych, geoprzestrzenne bity rdzeniowe danych. To jest coraz ważniejsze w dzisiejszych czasach dzięki Internetowi rzeczy. Wiesz, istnieje geografia związana z dużą ilością tego, co robimy lub dużą ilością tych danych. I tak, wszystkie parsowanie, tokenizacja, czyszczenie, korekta, formatowanie, strukturyzacja itp. - wszystko to odbywa się na naszej platformie.
I wtedy, być może, najważniejszą rzeczą jest myśl o deduplikacji. Wiesz, jeśli spojrzysz na jakąkolwiek definicję zarządzania danymi podstawowymi, jej sednem jest deduplikacja. Jest w stanie zidentyfikować jednostki z różnych źródeł danych, a następnie utworzyć rekord główny dla tej jednostki. I tym bytem może być osoba. Istota może być na przykład częścią samolotu. Istota może być pokarmem, który zrobiliśmy dla jednego z naszych klientów klubu zdrowia. Stworzyliśmy dla nich główną bazę danych żywności. Tak więc, bez względu na to, z jakimi podmiotami współpracujemy - i oczywiście coraz częściej są ludzie i pełnomocnicy do ich tożsamości, takich jak uchwyty społecznościowe lub konta, niezależnie od urządzeń, które są powiązane z ludźmi, niektóre rzeczy, takie jak samochody i telefony i cokolwiek innego możesz sobie wyobrazić.
Wiesz, współpracujemy z klientem, który umieszcza różnego rodzaju czujniki w odzieży sportowej. Tak więc dane pochodzą z każdego kierunku. I w ten czy inny sposób jest odzwierciedleniem lub reprezentacją podstawowej istoty. Coraz częściej są to ludzie i zdolność do identyfikowania relacji między tymi wszystkimi źródłami danych oraz ich powiązania z tą podstawową jednostką, a następnie możliwość śledzenia tej podstawowej jednostki w czasie, abyś mógł analizować i zrozumieć zmiany między tą jednostką i wszystkie inne elementy, które są w reprezentacjach tego bytu, na przykład naprawdę krytyczne dla długoterminowej i podłużnej analizy ludzi. I to naprawdę jedna z naprawdę ważnych korzyści, które moim zdaniem mogą przynieść duże zbiory danych, to znacznie lepsze zrozumienie ludzi, i na dłuższą metę, zrozumienie oszustwa i tego, jak ludzie zachowują się, gdy zachowują się za pomocą jakich urządzeń itp. .
Pozwól mi więc szybko się tutaj przenieść. Eric wspomniał o YARN. Wiesz, wrzucam to na chwilę, bo podczas gdy YARN - ludzie mówią o YARN. Myślę, że wciąż jest dużo niewiedzy o YARN. I naprawdę niewiele osób - wciąż jest wiele nieporozumień na temat YARN. A faktem jest, że jeśli Twoja aplikacja została odpowiednio zaprojektowana i masz odpowiedni poziom lub równoległość w architekturze aplikacji, możesz skorzystać z YARN, aby użyć Hadoop jako platformy skalowania. I właśnie to zrobiliśmy.
Wiesz, jeszcze raz, aby wskazać niektóre definicje wokół YARN. Dla nas tak naprawdę to, czym jest YARN, pozwoliło nam i innym organizacjom stać się rówieśnikami MapReduce i Spark oraz wszystkich innych dostępnych narzędzi. Ale faktem jest, że nasze aplikacje wprowadzają zoptymalizowany kod bezpośrednio do YARN w Hadoop. I jest bardzo interesujący komentarz, o którym wspomniał Mike, ponieważ, wiesz, pytanie o analitykę i nasze analityki, tylko dlatego, że są w klastrze, czy naprawdę działają równolegle? Możesz zadać to samo pytanie na temat wielu dostępnych narzędzi do kontroli jakości danych.
Przez większość dnia narzędzia jakości, które tam są, albo muszą wyciągać dane, albo wpychają kod. W wielu przypadkach jest to pojedynczy strumień danych, który jest przetwarzany z powodu sposobu, w jaki musisz porównaj rekordy, czasem w działaniach o jakości danych. A faktem jest, że ponieważ używamy YARN, byliśmy w stanie naprawdę skorzystać z równoległości.
I po prostu, aby dać ci szybki przegląd, ponieważ pojawia się kolejny komentarz na temat znaczenia rozszerzenia tradycyjnych baz danych, nowych baz danych itp., Które wdrażamy lub instalujemy poza klastrem. Pchamy nasze pliki binarne bezpośrednio do menedżera zasobów, YARN. I to, a następnie YARN dystrybuuje go między węzłami w klastrze. I to polega na tym, że YARN - pozwalamy YARN zarządzać i wykonywać swoją pracę, która polega na ustaleniu, gdzie znajdują się dane, i przeniesieniu pracy do danych, kodu do danych i nie przenoszeniu danych. Kiedy słyszysz narzędzia do poprawy jakości danych i mówią ci, że najlepszą praktyką jest przenoszenie danych z Hadoop, bieganie przez całe życie, bo to nie tak. Chcesz zabrać pracę do danych. I tak właśnie robi YARN. Przenosi nasze pliki binarne do węzłów, w których znajdują się dane.
A także ponieważ jesteśmy poza klastrem, możemy również uzyskać dostęp do wszystkich tradycyjnych i relacyjnych baz danych, dzięki czemu możemy mieć zadania, które są w 100% serwerem klienta w tradycyjnej bazie danych, 100% Hadoop lub zadania hybrydowe, które przechodzą przez serwer klienta Hadoop , Oracle, Teradata - cokolwiek chcesz i wszystko w tej samej pracy, ponieważ ta jedna implementacja może uzyskać dostęp do obu stron świata.
A potem, wracając do całej idei powstawania narzędzi, widzicie tutaj, to tylko prosta reprezentacja. A my staramy się uprościć świat. Sposób, w jaki to robimy, polega na wprowadzeniu do HDFS bardzo szerokiego zestawu funkcji… Nie dzieje się tak dlatego, że staramy się wyeliminować wszystkie innowacyjne technologie. Po prostu przedsiębiorstwa potrzebują stabilności, a nie lubią rozwiązań opartych na kodzie. Dlatego staramy się zapewnić przedsiębiorstwom znane, powtarzalne, spójne środowisko aplikacji, które daje im możliwość budowania i przetwarzania danych w bardzo przewidywalny sposób.
Szybko taki wpływ uzyskujemy dzięki naszej aplikacji. Zobaczysz MapReduce vs. Pig vs. RedPoint - brak linii kodu w RedPoint. Sześć godzin rozwoju w MapReduce, trzy godziny rozwoju w Pig i 15 minut rozwoju w RedPoint. I tam naprawdę mamy ogromny wpływ. Czas przetwarzania jest również szybszy, ale czas ludzi, produktywność ludzi, znacznie się wydłuża.
I mój ostatni slajd tutaj, chcę wrócić do tego pomysłu, ponieważ jest to nasze podejście do korzystania z jeziora danych, centrum danych lub rafinerii danych jako centralnego punktu przyjmowania. Nie mogłem się bardziej zgodzić z tym pomysłem. Obecnie prowadzimy rozmowy z wieloma głównymi specjalistami ds. Danych głównych globalnych banków, i taka jest architektura z wyboru.Wchłanianie danych ze wszystkich źródeł wykonuje przetwarzanie jakości danych i zarządzanie danymi głównymi w jeziorze danych, a następnie wypycha dane tam, gdzie trzeba, do aplikacji wspierających, aby wspierać BI, cokolwiek to może być. A następnie, jeśli masz analitykę w BI, mogą one działać bezpośrednio w jeziorze danych, gdzie tym lepiej, można zacząć od razu. Ale bardzo na pokładzie tego pomysłu. Ta topologia tutaj jest taka, którą - odkrywamy - zyskuje dużą popularność na rynku. I to wszystko.
Eric: Dobra, dobrze. Przejdźmy tutaj. Pójdę naprzód i przekażę to Keithowi. I, Keith, masz około 10, 12 minut, żeby zakołysać tutaj domem. W tych programach zajęliśmy trochę czasu. I zareklamowaliśmy 70 minut na ten. Więc po prostu idź dalej i kliknij w dowolnym miejscu tego slajdu, użyj strzałki w dół i zabierz go.
Keith: Jasne. Nie ma problemu, Eric. Doceniam to. Zamierzam napisać kilka słów o SAS, potem przejdę do architektury technologii, w której SAS przecina się ze światem dużych zbiorów danych. W tych wszystkich sprawach jest wiele do wyjaśnienia. Moglibyśmy spędzić godziny na szczegółowej analizie, ale dziesięć minut - powinieneś być w stanie odejść, mając krótkie zrozumienie, gdzie SAS przeniósł technologie analityczne, zarządzania danymi i analizy biznesowej do tego świata dużych zbiorów danych.
Po pierwsze, trochę o SAS. Jeśli nie znasz tej organizacji, przez ostatnie 38 lat zajmowaliśmy się zaawansowaną analityką, analizą biznesową i zarządzaniem danymi z nie tylko dużych danych, ale także małych danych i bogactwa danych przez ostatnie 38 lat. Mamy ogromną liczbę istniejących klientów, około 75 000 witryn na całym świecie, współpracujących z niektórymi z najlepszych organizacji. Jesteśmy prywatną organizacją zatrudniającą około 13 000 pracowników i 3 miliardy dolarów przychodów. I tak naprawdę, myślę, że ważną częścią jest to, że tradycyjnie od dawna inwestujemy znaczne kwoty naszych dochodów z powrotem w naszą organizację badawczo-rozwojową, co naprawdę przyniosło wiele z tych niesamowitych technologii i platform, które Ty ” zobaczymy się dzisiaj.
Skoczę teraz do tych naprawdę przerażających schematów architektury. Na moich slajdach będziemy pracować od lewej do prawej. Są więc znane rzeczy, które zobaczycie na tej platformie. Po lewej stronie wszystkie źródła danych, o których mówimy, o przyjmowaniu na te platformy dużych zbiorów danych. A potem masz tę platformę dużych zbiorów danych.
Nie umieściłem tam słowa Hadoop na górze, ponieważ ostatecznie przykłady, które przedstawię dzisiaj, dotyczą w szczególności wszystkich technologii, w których łączymy się z tymi platformami dużych zbiorów danych. Hadoop jest po prostu jednym z tych, w których mamy jedne z najbardziej niezawodnych opcji wdrażania, ale także dość często się krzyżujemy i opracowaliśmy wiele z tych technologii od pewnego czasu z niektórymi naszymi innymi partnerami hurtowni danych, takimi jak Teradata, Oracle, Pivotal i tym podobne. Nie mogę więc wdawać się w szczegółowe informacje na temat obsługiwanych technologii na różnych platformach, ale zapewniam, że wszystkie te, które dziś opisuję, to głównie Hadoop i duża część z nich łączy się z innymi partnerami technologicznymi, którzy mamy. Mamy więc taką dużą platformę.
Następny, po prawej, mamy nasz serwer analityczny SAS LASR. Zasadniczo jest to zasadniczo równoległy serwer aplikacji analitycznych pamięci. Wyjaśnimy, że nie jest to baza danych w pamięci. Jest naprawdę zaprojektowany od podstaw. To nie jest silnik zapytań, ale zaprojektowany do obsługi żądań analitycznych na ogromną skalę w masowo równoległy sposób. To są kluczowe aplikacje serwisowe, które widzisz tam po prawej stronie.
Zajmiemy się bardziej, jak ludzie wdrażają te rzeczy. Ale w gruncie rzeczy ta aplikacja - czy widzisz ją - pierwsza, to nasza wysokowydajna analityka SAS. Tak się stanie - używam wielu naszych istniejących technologii i platform, takich jak Enterprise Miner lub po prostu SAS, i nie tylko wykonuję wielowątkowość z niektórymi algorytmami, które wbudowaliśmy w narzędzia, które stworzyliśmy dla lat, ale także masowo je równolegle. Tak więc, aby przenieść dane z tej platformy dużych zbiorów danych do przestrzeni pamięci na ten serwer LASR Analytic Server, abyśmy mogli wykonywać algorytmy analityczne - wiesz, dużo nowego uczenia maszynowego, sieci neuronowych, losowych regresji lasów, tego rodzaju rzeczy - znowu dane przechowywane w pamięci. Pozbycie się pewnego wąskiego gardła w paradygmacie MapReduce, gdzie przechodzimy do tych platform, to nie jest sposób, w jaki chcesz wykonywać prace analityczne. Chcemy więc móc jednorazowo przenieść dane do przestrzeni pamięci i iterować je, wiesz, czasami tysiące razy. Taka jest koncepcja wykorzystania tego wysokowydajnego analitycznego serwera LASR.
My także - inne aplikacje poniżej, analiza wizualna, która pozwala nam zachować te dane w pamięci i obsłużyć większą populację na tych samych danych. Pozwala to na eksplorację dużych zbiorów danych. Tak więc, zanim zaczniemy prace nad opracowaniem modelu, badamy dane, rozumiemy je, przeprowadzamy korelacje, wykonujemy prognozy lub trendy drzew decyzyjnych - tego rodzaju rzeczy - ale w bardzo wizualny, interaktywny sposób na danych, które siedzą w pamięci Platforma. Służy to również naszej społeczności BI, jeśli chodzi o posiadanie bardzo szerokiej bazy użytkowników, którzy mogą wejść na tę platformę, aby wykonywać standardowe rodzaje rejestrowania, które zobaczysz - które w zasadzie każdy, jak wiesz, sprzedawca BI.
Następnym krokiem jest przejście do usługi. Aby pomóc naszym statystykom i analitykom w przeprowadzeniu tego rodzaju modelowania ad hoc z danymi przechowywanymi w pamięci, usuniętymi z analizy wizualnej i eksploracji naszej aplikacji statystyk wizualnych. Jest to okazja dla ludzi do skorzystania, aby nie uruchamiać statystyk w partiach, które kiedyś były powtarzane, uruchamiać modele, widzieć wyniki. Tak, że można uruchomić model, zobacz wyniki. Ma to na celu przeciągnięcie i upuszczenie do interaktywnego modelowania statystycznego. Dzięki temu nasi statystycy i analitycy danych wykonują wiele z tych wczesnych eksploracyjnych badań statystycznych.
A potem nie zapomnieliśmy o naszych programistach - ludzie, którzy naprawdę chcą mieć możliwość odklejenia warstw interfejsu przeciwnego, to pisanie aplikacji i pisanie własnej bazy kodu w SAS. I to są nasze statystyki Hadoop w pamięci. I to jest - zasadniczo warstwa kodu, która pozwoliła nam na interakcję z tym analitycznym serwerem LASR w celu bezpośredniego wydawania poleceń i dostosowywania tych aplikacji na podstawie naszego żądania. To jest fragment analityczny.
Jak te rzeczy są konfigurowane… Ups, przepraszam chłopaki. No to jedziemy.
Tak więc możemy to zrobić na kilka sposobów. Jednym z nich jest robienie dużych zbiorów danych - w tym przypadku za pomocą Hadoop. I właśnie tam mamy ten serwer SAS LASR Analytic działający w oddzielnym klastrze maszyn zoptymalizowanych pod kątem trudnych analiz. Jest to dobrze umieszczone i zbliżone do platformy Big Data, co pozwala nam skalować ją oddzielnie od platformy Big Data. Widzimy więc ludzi, którzy robią to, gdy nie chcą mieć czegoś, co określam jako oprogramowanie wampirów, które pożera każdy z węzłów w klastrze Hadoop. I niekoniecznie skalują tę platformę big data odpowiednią do przeprowadzania dużych analiz w pamięci. Tak więc możesz mieć 120 węzłów ich klastra Hadoop, ale mogą one mieć 16 węzłów serwerów analitycznych zaprojektowanych do wykonywania tego rodzaju pracy.
Nadal możemy zachować tę równoległość z platformy dużych zbiorów danych, aby pobrać dane do pamięci. Tak więc to naprawdę jest używanie SAS z platformą Hadoop. Innym modelem spotkań jest zatem powiedzenie: no cóż, możemy również użyć tej platformy towarowej i pchnąć ją - zasadniczo uruchomić Analytyczny serwer LASR na platformach Hadoop. Właśnie tam jesteśmy… działasz na platformie Big Data. To także niektórzy z naszych innych dostawców urządzeń. To pozwoliło nam zasadniczo wykorzystać tę platformę towarową do wykonania tej pracy.
Widzimy to częściej w przypadku takich rzeczy, jak wysokowydajna analityka, w której jest to analiza jednorazowa lub jednorazowa, bardziej zorientowana wsadowo tam, gdzie jesteś - nie musisz koniecznie zajmować miejsca w pamięci w Hadoop Platforma. Jesteśmy bardzo elastyczni w tego rodzaju modelu wdrażania, zdecydowanie pracując z YARN w wielu przypadkach, aby mieć pewność, że gramy w dobre klastry.
Okej, więc to jest świat analityczny, żeby być czystym dzięki aplikacji analitycznej. Ale wspomniałem, że SAS od samego początku jest również platformą do zarządzania danymi. Są też rzeczy, które są odpowiednie, aby w razie potrzeby wprowadzić logikę na tę platformę. Jest kilka sposobów, w jakie to robimy. Jeden jest w świecie integracji danych, wykonywanie transformacji danych na danych może nie mieć sensu wyciąganie ich z powrotem, jak słyszeliśmy wcześniej, uruchamianie rutynowych procedur jakości danych. Chcemy zdecydowanie zepchnąć takie rzeczy jak procedury jakości danych na tę platformę. A potem takie rzeczy jak ocena modelu. Mam opracowany model. Nie chcę przepisać tej rzeczy w MapReduce i utrudnić mi i poświęcić czas na ponowne wykonanie tej pracy w natywnej platformie bazy danych.
Jeśli spojrzymy na przykład na nasz akcelerator oceniania dla Hadoop, który pozwala nam zasadniczo wziąć model i zsunąć logikę matematyczną SAS w dół na tę platformę Hadoop i wykonać ją tam, wykorzystując równoległość wewnątrz tej platformy dużych zbiorów danych. Następnie mamy nasz akcelerator kodu dla różnych platform, w tym Hadoop, co pozwala nam zasadniczo uruchamiać kod kroku danych SAS na platformie w sposób masowo równoległy - tak więc przeprowadzanie transformacji danych działa na platformie. A potem nasz akcelerator jakości danych SAS, który pozwala nam mieć wysokiej jakości bazę wiedzy, która może robić takie rzeczy, jak dopasowanie płci, kod dopasowania standaryzacji - wszystkie różne rzeczy dotyczące jakości danych, które słyszeliście już dzisiaj.
A potem, w ostatnim kawałku, jest moduł ładujący dane. Wiemy, że nasi użytkownicy biznesowi będą musieli nie móc pisać kodu, przeprowadzać transformacji danych na tych platformach dużych zbiorów danych. Data Loader to przyjemny GUI WYSIWYG, który pozwala nam łączyć te inne technologie razem. To jest jak kreator, który, powiedzmy, uruchamia zapytanie Hive lub procedurę jakości danych i nie musi w tym przypadku pisać kodu.
Ostatnią rzeczą, o której wspomnę, jest ten przód. Mamy - jak wspomniałem wcześniej - ogromną stopę SAS na świecie. I nie musimy koniecznie robić wszystkich platform, które są tam, aby natychmiast znaleźć się w tej przestrzeni. Tak więc zdecydowanie mamy istniejącą stopę użytkowników, którzy muszą gromadzić dane na tych platformach dużych zbiorów danych, takie jak pobieranie danych z Teradata i ponowne umieszczanie ich w Hadoop i odwrotnie. Uruchamianie modeli Wiem już, jak uruchomić na moich serwerach SAS, ale muszę uzyskać dane, które są teraz umieszczane na platformie Hadoop. Istnieje więc inna mała ikona o nazwie „z”, która pozwala nam łączyć się za pomocą naszych silników dostępu SAS - silników dostępu do Hadoop do Cloudera w Polach, do Teradata, do Greenplum do… I lista jest długa. To pozwala nam korzystać z naszych istniejących dojrzałych platform SAS, które już istnieją, aby pobierać dane z tych platform, wykonywać pracę, którą musimy wykonać, przekazywać wyniki z powrotem do tych obszarów.
Ostatnią rzeczą, o której wspomnę, jest to, że wszystkie te technologie są zarządzane według tych samych standardowych wspólnych metadanych. Mówimy więc o rozpoczęciu transformacji, regule jakości danych w pracy, przeniesieniu jej do pamięci, aby móc przeprowadzić analizę, opracować model w punktacji. Mamy tam cały analityczny styl życia, a jego cyklem życia rządzą wspólne metadane, zarządzanie, bezpieczeństwo i wszystkie rzeczy, o których dzisiaj mówiliśmy.
Podsumowując, są naprawdę trzy rzeczy, które należy zabrać. Jednym z nich jest to, że możemy traktować platformę danych tak jak każde inne źródło danych, wyciągając z nich dane, przekazując je, gdy jest to odpowiednie i wygodne. Możemy pracować z tymi platformami big data, wymieniając dane w specjalnie zaprojektowaną zaawansowaną platformę analityczną w pamięci. To jest serwer LASR.
Wreszcie, możemy wreszcie pracować bezpośrednio na tych platformach dużych zbiorów danych, wykorzystując ich możliwości przetwarzania dystrybucyjnego bez przenoszenia danych.
Eric: Cóż, to fantastyczne rzeczy, ludzie. Tak, to wspaniale! Przejdźmy więc do kilku pytań. Zwykle spędzamy na tych wydarzeniach około 70 minut lub nieco dłużej. Widzę więc, że nadal mamy świetną publiczność. George, chyba przekażę ci nasze pierwsze pytanie. Jeśli mówisz o wypychaniu binarnego dźwięku do Hadoop, myślę, że brzmi to tak, jakbyś naprawdę zoptymalizował przepływ obliczeniowy. I to jest cały klucz, aby móc wykonywać tego rodzaju zarządzanie danymi w czasie rzeczywistym, osiągnięcia w stylu jakości danych, ponieważ to jest wartość, którą chcesz uzyskać, prawda? Jeśli nie chcesz wracać do starego świata MDM, gdzie jest to bardzo uciążliwe i czasochłonne, a naprawdę musisz zmusić ludzi do działania w określony sposób, co prawie nigdy nie działa. Tak więc, co zrobiliście, skondensowaliście cykl tego, co było. Nazwijmy to dniami, tygodniami, a czasem nawet miesiącami, prawda? Czy o to chodzi?
George: Dokładnie tak, ponieważ skala, którą otrzymujemy, i wydajność, którą uzyskujemy z klastra, jest naprawdę oszałamiająca, jeśli chodzi o, po prostu zawsze jestem trochę niezdecydowany w kwestii testów porównawczych. Ale tylko dla rzędu wielkości, kiedy przeprowadzilibyśmy miliard, 1,2 miliarda rekordów i przeprowadzilibyśmy pełną standaryzację adresu - mówię, że maszyna HP średniego zasięgu - zajęłoby, no wiesz, osiem maszyn procesorowych, wiesz , 2 gigabajty pamięci RAM na rdzeń, wiesz, że uruchomienie zajęłoby 20 godzin. Możemy to zrobić za około osiem minut w klastrze 12-węzłowym. Skala przetwarzania, którą możemy teraz wykonać, jest tak radykalnie różna, że - i bardzo dobrze idzie z tym, że masz do dyspozycji wszystkie te dane. Przetwarzanie nie jest tak ryzykowne. Jeśli zrobiłeś to źle, możesz powtórzyć. Wiesz, masz czas. To naprawdę zmieniło skalę tego, gdzie tego rodzaju ryzyka naprawdę stały się prawdziwymi problemami biznesowymi dla ludzi, którzy próbowali obsługiwać rozwiązania MDM. Musisz mieć 30 osób za granicą, które zajmują się zarządzaniem danymi i tym podobne. I tak nadal musisz mieć to trochę, ale szybkość i skala, w jakiej możesz teraz je przetwarzać, naprawdę dają ci dużo więcej oddechu.
Eric: Tak, to naprawdę dobra uwaga. Uwielbiam ten komentarz. Masz więc czas, aby ponownie go wykonać. To fantastycznie.
George: Tak.
Eric: Cóż, zmienia to dynamikę, prawda? Zmienia to, jak myślisz o tym, co zamierzasz spróbować. To znaczy, pamiętam to 18 lat temu w branży robienia efektów specjalnych, ponieważ miałem w tym miejscu klienta. I naciskałbyś przyciski, żeby to wyrenderować, i wracałeś do domu. I wrócisz, może w sobotnie popołudnie, żeby zobaczyć, jak leci. Ale jeśli pomyliłeś się, było to bardzo, bardzo, bardzo bolesne. A teraz nie jest to prawie wcale - nie jest nawet blisko bycia tak bolesnym, więc masz okazję spróbować więcej rzeczy. Muszę powiedzieć, że to naprawdę bardzo dobra uwaga.
George: Dokładnie tak. Tak, a ty wysadzasz swoją dodatkową nogę. Wiesz, w dawnych czasach dostajesz połowę pracy i to się nie udaje, rozwaliłeś SOS. Otóż to.
Eric: Racja. I masz duże kłopoty, tak. Zgadza się.
George: Zgadza się. Zgadza się.
Eric: Keith, pozwól, że ci je przekażę. Pamiętam, jak przeprowadzałem wywiad z twoim CIL, Keithem Collinsem, myślę, że wróciłem, jak sądzę, w 2011 roku. I wiele mówił o kierunku, w którym SAS podąża, szczególnie w odniesieniu do współpracy z klientami w celu osadzenia analiz pochodzących z SAS w systemach operacyjnych. I oczywiście słyszeliśmy, jak Mike Ferguson mówił o znaczeniu pamiętania. Cały pomysł polega na tym, że chcesz mieć możliwość powiązania tego z twoimi operacjami. Nie chcesz analizy w próżni, odłączonej od przedsiębiorstwa. To nie ma żadnej wartości.
Jeśli potrzebujesz analizy, która może bezpośrednio wpłynąć i zoptymalizować operacje. A jeśli spojrzę wstecz - i muszę powiedzieć, pomyślałem, że to był dobry pomysł - z perspektywy czasu wydaje się to naprawdę, naprawdę sprytny pomysł. Zgaduję, że to prawdziwa zaleta. I oczywiście ta wspaniała spuścizna, ta ogromna baza instalacyjna oraz fakt, że koncentrowałeś się na osadzaniu tych analiz w systemach operacyjnych, co oznacza, że teraz - i oczywiście, zajmie to trochę pracy - jestem pewien, że „ ciężko nad tym pracowałem. Ale teraz możesz wykorzystać wszystkie te innowacje i naprawdę możesz pod względem operacjonalizacji tego wszystkiego z klientami. Czy to uczciwa ocena?
Keith: Tak, absolutnie. Chodzi o to, że masz pomysł projektowania decyzji lub nauk decyzyjnych, który jest, do pewnego stopnia, badawczy, naukowy. Chyba, że możesz wykonać inżynierię procesu, aby naprawdę… Jeśli myślisz o opracowaniu samochodu, masz projektantów, którzy tworzą ten piękny samochód, ale dopiero wtedy, gdy inżynierowie wprowadzą ten plan w życie i stworzą rzeczywisty opłacalny produkt przed tobą jest w stanie właściwie wszystko załatwić i właśnie to zrobiła SAS. Połączył ze sobą proces decyzyjny - proces decyzyjny z procesem inżynierii decyzyjnej, dzięki czemu rozmawiając o akceleratorach, a konkretnie akceleratorach punktacji, wiesz, jeśli weźmiesz opracowany model i będziesz mógł go wypchnąć do Teradata lub wypchnij go do Oracle lub Hadoop, przy zerowym przestoju na opracowanie modelu, na wdrożenie modelu. To klucz, ponieważ modele pogarszają się z czasem, dokładność tych modeli. Im dłużej trwa to, zanim je weźmiesz i wprowadzisz do produkcji, tym utrata dokładności modelu.
Drugim elementem jest to, że chcesz mieć możliwość monitorowania tego procesu i zarządzania nim w czasie. Chcesz wycofać modele, gdy się zestarzeją i będą niedokładne. Chcesz na to spojrzeć, sprawdzić ich dokładność w czasie i je odbudować. Tak więc mamy do dyspozycji narzędzia do zarządzania modelami, które naprawdę śledzą metadane wokół modelowanego procesu. A ludzie mówili, że modelowanie, wiesz, ten rodzaj koncepcji przypomina fabrykę modeli lub jakkolwiek chcesz to nazwać. Chodzi o to, że przetwarza metadane i zarządzanie. Właśnie w tym tkwią trzy wielkie rzeczy - pomagamy ludziom zarabiać pieniądze, oszczędzać pieniądze i trzymać ich z dala od więzienia.
Eric: Ten ostatni też jest dość duży. Chcę tego wszystkiego uniknąć. Porozmawiajmy o ...Zadaję jedno ostatnie pytanie, być może każdy z was może wskoczyć na to. Wydaje mi się, że heterogeniczność naszego świata będzie się zwiększać. Myślę, że zdecydowanie zobaczymy pewną krystalizację w środowiskach chmur hybrydowych. Niemniej jednak zobaczysz wielu głównych graczy. IBM nigdzie się nie wybiera. Oracle nigdzie się nie wybiera. SAP nigdzie się nie wybiera. I jest tak wielu innych dostawców, którzy są zaangażowani w tę grę.
Również po stronie operacyjnej, gdzie masz dosłownie tysiące różnych rodzajów aplikacji. I słyszałem - większość z was o tym mówi, ale myślę, że oboje zgodzilibyście się z tym, co mówiłem. Widzieliśmy teraz ten trend w kategoriach mocy obliczeniowej w silnikach analitycznych, architekturze. Firmy od lat mówią o tym, że mogą podłączyć się do innych silników i obsługiwać coś w rodzaju punktu koordynacyjnego. I zgaduję, George, dam ci to pierwszy. Wydaje mi się, że to się nie zmieni. Będziemy mieli to heterogeniczne środowisko, co oznacza, że istnieją takie elementy, jak CRM w czasie rzeczywistym, jakość danych i zarządzanie danymi. Będziesz musiał, jako sprzedawca, połączyć się z tymi wszystkimi różnymi narzędziami. I tego właśnie będą chcieli klienci. Nie będą chcieli czegoś, co byłoby w porządku z tymi narzędziami i nie tak dobrze z tymi narzędziami. Będą chcieli Szwajcarii MDM i CRM, prawda?
George: Zgadza się. I to jest interesujące, ponieważ bardzo to przyjęliśmy. Częściowo jest to historia, którą mieliśmy w kosmosie. Oczywiście pracowaliśmy już nad wszystkimi innymi bazami danych, Teradatami i częściami świata. A potem - w procesie implementacji, dokładnie tak, jak my to zrobiliśmy - po prostu masz taki zakres we wszystkich tych różnych bazach danych. Jedną z rzeczy, które uważam za interesujące, jest to, że mamy niektórych klientów, którzy są bardzo zainteresowani wyeliminowaniem wszystkich relacyjnych baz danych. I to jest interesujące. Wiesz, to znaczy w porządku. To interesujące. Ale po prostu nie widzę, żeby to się naprawdę działo na dużą skalę. Długo nie widzę. Myślę więc, że hybryda istnieje już od dłuższego czasu i po drugiej stronie naszej aplikacji, gdzie mamy naszą platformę do przesyłania wiadomości w naszej platformie zarządzania kampaniami. Właściwie to specjalnie go zaprojektowaliśmy. Teraz wypuściliśmy wersję, która to robi i która może teraz łączyć się z hybrydowym środowiskiem danych i wysyłać zapytania do Hadoop lub zapytania do dowolnej bazy danych, dowolnej analitycznej bazy danych. Myślę, że to tylko fala przyszłości. I zgadzam się, że wirtualizacja z pewnością odegra w tym dużą rolę, ale my po prostu - przechodzimy od razu do danych we wszystkich naszych aplikacjach.
Eric: Dobra, świetnie. I, Keith, przekażę ci to. Co sądzisz o heterogenicznym świecie, przed którym stoimy, zachowując się jak stopa?
Keith: Tak, to naprawdę fascynujące. Myślę, że znajdujemy więcej - nie tylko w dziedzinie zarządzania danymi - ale tak naprawdę fascynująca jest otwarta baza danych analitycznych. Widzimy więc organizacje takie lub technologie takie jak Spark, a także osoby używające Pythona i R oraz wszystkich innych technologii open source. Myślę, że może to być do pewnego stopnia interpretowane jako konflikt lub zagrożenie. Ale w rzeczywistości mamy wspaniałe komplementy ze wszystkimi technologiami typu open source. Po pierwsze, działamy na platformach open source, na miłość boską.
Ale także, podobnie jak możliwość zintegrowania, na przykład, modelu R z paradygmatem SAS, pozwala ci korzystać z tego, co najlepsze z obu światów, prawda? Na przykład wiemy, że niektóre eksperymentalne rzeczy w świecie akademickim i niektóre prace związane z opracowywaniem modelu są nadzwyczajne i bardzo pomocne w procesie tworzenia modelu. Ale jeśli możesz połączyć to z rodzajem narzędzia klasy produkcyjnej, robi to dużo czyszczenia i jakości, a także sprawdzania i upewniania się, że dane poddawane modelowi są poprawnie przygotowane, więc nie zawiedzie na egzekucji. A potem możliwość robienia rzeczy takich jak mistrzowskie modele pretendentów z modelami open source. To są rzeczy, które chcemy włączyć, i jako część tego naprawdę heterogenicznego ekosystemu wszystkich tych technologii. Tak, więc jest więcej - dla nas chodzi bardziej o zastosowanie tych technologii i poszukiwanie komplementów.
Eric: Cóż, to były fantastyczne rzeczy, ludzie. Przebyliśmy tu trochę czasu, ale chcielibyśmy uzyskać jak najwięcej pytań. Dzisiaj prześlemy plik pytań i odpowiedzi do naszych prezenterów. Tak więc, jeśli na którekolwiek z zadanych pytań nie zostanie udzielona odpowiedź, upewnimy się, że otrzyma odpowiedź. I ludzie, to podsumowuje rok 2014. Pozdrawiam naprawdę w DM Radio jutro i w przyszłym tygodniu, a potem wszystko jest skończone i jest to przerwa wakacyjna.
Ogromne podziękowania dla was wszystkich za poświęcony czas i uwagę, za przeglądanie tych wszystkich wspaniałych webcastów. Mamy wspaniały rok w kolejce do 2015 roku. Wkrótce się z tobą porozmawiamy. Dzięki jeszcze raz. Wiec ... Trzymaj sie. PA pa.