Der Schlüssel zur Qualität von Big Data Analytics: Unterschiedliches Verständnis - TechWise Episode 4 Transcript

Autor: Roger Morrison
Erstelldatum: 17 September 2021
Aktualisierungsdatum: 21 Juni 2024
Anonim
Der Schlüssel zur Qualität von Big Data Analytics: Unterschiedliches Verständnis - TechWise Episode 4 Transcript - Technologie
Der Schlüssel zur Qualität von Big Data Analytics: Unterschiedliches Verständnis - TechWise Episode 4 Transcript - Technologie

Inhalt


Quelle: Jakub Jirsak / Dreamstime.com

Wegbringen:

Gastgeber Eric Kavanagh diskutiert mit Branchenexperten über Big-Data-Analysen.

Eric: Meine Damen und Herren, es ist das Ende des Jahres 2014 - zumindest fast. Es ist unser letzter Webcast des Jahres, Leute! Willkommen bei TechWise! Ja in der Tat! Ich heiße Eric Kavanagh. Ich werde Ihr Moderator für einen großartigen Webcast sein, Leute. Ich bin wirklich sehr aufgeregt. Wir haben zwei großartige Analysten online und zwei großartige Unternehmen - echte Innovatoren in diesem gesamten Big-Data-Ökosystem. Und wir werden über den Schlüssel zur Big-Data-Analyse sprechen, wenn es darum geht, Unterschiede zu verstehen. Also, lasst uns weitermachen und direkt eintauchen, Leute.


Wir haben mehrere Moderatoren. Wie Sie sehen, haben Sie es ganz oben. Mike Ferguson ruft aus Großbritannien an, wo er besondere Privilegien erhalten musste, um so spät in seinem Bürogebäude zu bleiben. So spät ist es für ihn. Wir haben Dr. Robin Bloor, unseren eigenen Chefanalysten hier bei der Bloor-Gruppe. Und wir haben George Corugedo, CEO und Mitbegründer von RedPoint Global, und Keith Renison, Senior Solutions Architect vom SAS Institute. Das sind fantastische Unternehmen, Leute. Dies sind Unternehmen, die wirklich innovativ sind. Und wir werden uns mit einigen der guten Dinge befassen, die derzeit in der ganzen Welt der Big Data geschehen. Und seien wir ehrlich, die kleinen Daten sind nicht verschwunden. Lassen Sie mich dazu meine Zusammenfassung hier geben.



Es gibt also einen alten französischen Ausdruck: "Je mehr Dinge sich ändern, desto mehr bleiben sie gleich." Und seien wir hier ein paar Fakten gegenübergestellt: Big Data wird die Probleme von Small Data nicht lösen. Kleine Unternehmensdaten sind immer noch da draußen. Es ist immer noch überall. Es ist der Treibstoff für den Betrieb der heutigen Informationswirtschaft. Und Big Data bietet ein Kompliment zu diesen sogenannten kleinen Unternehmensdaten, ersetzt jedoch keine kleinen Daten. Es wird immer noch da sein. Ich mag viele Dinge in Bezug auf Big Data, insbesondere Dinge wie maschinengenerierte Daten.


Und heute werden wir wahrscheinlich ein wenig über Social-Media-Daten sprechen, was ebenfalls sehr mächtig ist. Und wenn Sie zum Beispiel darüber nachdenken, wie sich das Geschäft durch soziale Netzwerke verändert hat, denken Sie an drei kurze Websites:, LinkedIn und. Denken Sie daran, dass vor fünf Jahren noch niemand so etwas gemacht hat. ist heutzutage ein absoluter Moloch. ist natürlich riesig. Es ist gigantisch. Und dann ist LinkedIn der De-facto-Standard für Unternehmensnetzwerke und -kommunikation. Diese Websites sind gewaltig und werden einige bahnbrechende Funktionen wiederbeleben, um die darin enthaltenen Daten nutzen zu können. Es wird vielen Organisationen wirklich viel Gutes bringen - zumindest denjenigen, die es nutzen.



Keine Bugs, kein Stress - Ihre schrittweise Anleitung zur Erstellung lebensverändernder Software, ohne Ihr Leben zu zerstören

Sie können Ihre Programmierkenntnisse nicht verbessern, wenn sich niemand um die Softwarequalität kümmert.

Governance - Governance ist also immer noch wichtig. Auch hier macht Big Data die Notwendigkeit von Governance nicht zunichte. Ganz ehrlich, es gibt eine ganz neue Notwendigkeit, sich auf die Steuerung der Welt der Big Data zu konzentrieren. Wie stellen Sie sicher, dass Ihre Verfahren und Richtlinien vorhanden sind? dass die richtigen Leute Zugang zu den richtigen Daten bekommen; Haben Sie Kontakte, haben Sie eine Abstammung? Sie wissen tatsächlich, woher die Daten kommen, was damit passiert ist. Und das ändert sich.


Ich bin ehrlich gesagt sehr beeindruckt von dem, was ich in dieser neuen Welt gesehen habe, als ich das Hadoop-Ökosystem nutzte, das natürlich weit mehr als nur Speicherplatz in Bezug auf Funktionalität ist. Hadoop ist auch eine Rechenmaschine. Und das Unternehmen muss herausfinden, wie es diese Rechenleistung und Parallelverarbeitungsfähigkeit nutzen kann. Sie werden wirklich, wirklich coole Dinge machen. Das werden wir heute erfahren.


Die andere Sache, über die Dr. Bloor in der jüngsten Vergangenheit gesprochen hat, ist, dass die Innovationswelle noch nicht vorbei ist. Wir haben natürlich viel Aufmerksamkeit bei Hadoop gesehen. Wir haben Unternehmen wie Cloudera und Hortonworks gesehen, die wirklich Wellen geschlagen haben. Und sie entwickeln Partnerschaften mit Unternehmen, die heute bereit sind, ganz offen. Und sie entwickeln Partnerschaften mit vielen Leuten. Aber die Innovationswelle ist noch nicht vorbei. Es gibt weitere Projekte, die aus der Apache Foundation hervorgehen und nicht nur den Endpunkt, sondern auch die Infrastruktur selbst verändern.


Diese ganze Entwicklung von YARN - einem weiteren Ressourcen-Verhandlungspartner - ist also wirklich wie ein Betriebssystem für Big Data. Und es ist eine große Sache. Wir werden also lernen, wie dies auch die Dinge verändert. Also, nur ein paar offensichtliche Ratschläge, seien Sie vorsichtig, wenn es um langfristige Verträge geht, wissen Sie, Fünf- und Zehnjahresverträge werden die Welle sein, der Weg, der mir scheint. Sie wollen um jeden Preis das Einschließen vermeiden. Wir werden heute mehr darüber erfahren.


Unser erster Analyst spricht heute - unser erster Sprecher des gesamten Programms ist Mike Ferguson, der aus Großbritannien anruft. Damit werde ich Ihnen die Schlüssel geben, Mike, und Sie können sie wegnehmen. Mike Ferguson, der Boden gehört dir.


Mike, bist du da? Sie könnten stumm geschaltet sein. Ich höre ihn nicht. Wir müssen ihn vielleicht zurückrufen. Und wir springen direkt zu Robin Bloors Folien. Robin, ich rangiere hier gegen den armen Mike Ferguson. Ich werde für eine Sekunde gehen.


Bist du das, Mike? Kannst Du uns hören? Nein. Ich denke, wir müssen zuerst mit Robin weitermachen. Also, warte eine Sekunde, Leute. Ich werde hier in ein paar Minuten auch einige Links zu den Folien ziehen. Lassen Sie mich also Robin Bloor die Schlüssel geben. Robin, du kannst zuerst anstatt Mike gehen und ich rufe gleich Mike an.


Robin: Okay.


Eric: Moment mal, Rob. Lass mich weitermachen und dein Dia hier hochbringen, Rob. Es wird eine Sekunde dauern.


Robin: Okay.


Eric: Ja. Sie können hier jedoch darüber sprechen, womit wir es zu tun haben, wenn es um Governance geht. Ich weiß, dass Sie über Governance sprechen werden. Dies wird in der Regel im Zusammenhang mit kleinen Unternehmensdaten berücksichtigt. Also, jetzt habe ich die Rutsche hoch, Robin. Bewegen Sie nichts. Und los geht's. Der Boden gehört dir. Nimm es weg.


Robin: Okay. Ja. Ich meine, na ja, wir haben uns im Voraus geeinigt, Mike würde über die analytische Seite sprechen, und ich werde über die Governance-Seite sprechen. Bis zu einem gewissen Grad folgt die Governance der Analyse in dem Sinne, dass dies ein Grund ist, warum Sie Big Data betreiben, und der Grund, warum Sie die gesamte Software für die Analyse zusammenstellen, ist, dass hier der Wert liegt.


Es gibt ein Problem. Und das Problem ist, dass die Daten gewirrt werden müssen. Die Daten müssen gemarshallt werden. Die Daten müssen so zusammengeführt und verwaltet werden, dass die Analysen mit vollem Vertrauen durchgeführt werden können. Ich dachte also, ich würde darüber reden, was die Governance-Seite der Gleichung ist. Ich denke, die Sache, die man wirklich sagen muss, ist, dass Governance bereits ein Thema war. Governance war bereits ein Thema, und es beginnt, ein Thema im gesamten Data Warehouse-Spiel zu werden.


Was tatsächlich passiert ist, ist ein viel größeres Problem. Und der Grund, warum es ein viel größeres Problem geworden ist, sowie mehr Daten, aber ich meine, das sind wirklich die Gründe. Die Anzahl der Datenquellen hat sich dramatisch erhöht. Bisher wurden die von uns zur Verfügung gestellten Datenquellen im Großen und Ganzen von den Datenquellen des Data Warehouse definiert. Das Data Warehouse wird normalerweise von RTP-Systemen gespeist. Es sind nur wenige externe Daten möglich, nicht viele.


Jetzt sind wir in eine Welt gegangen, in der, wie Sie wissen, gerade ein Datenmarkt entsteht und daher Daten gehandelt werden. Sie haben bereits eine Menge verschiedener Streaming-Datenquellen, die Sie tatsächlich in die Organisation einbringen können. Wir haben Social-Media-Daten, die sie genommen haben, sozusagen auf eigene Rechnung. Ich meine, ein großer Teil des Wertes in den sozialen Medien ist tatsächlich die Information, die sie aggregieren und die sie den Menschen zur Verfügung stellen können.


Wir haben auch die Entdeckung gemacht, dass es sie schon gegeben hat. Wir hatten diese Protokolldateien bereits zu Beginn von Splunk. Und bald wurde klar, dass eine Protokolldatei einen Wert hat. Es gab also Daten innerhalb der Organisation, die es gab - die wir als neue Datenquellen sowie als externe Quellen bezeichnen konnten. Das ist eine Sache. Und das bedeutet wirklich, dass, wie auch immer die Regeln für die Verwaltung der Daten vorher ausgearbeitet wurden, diese auf die eine oder andere Weise erweitert werden müssen und weiterhin erweitert werden müssen, um die Daten tatsächlich zu verwalten Daten. Aber wir fangen jetzt an, uns auf die eine oder andere Weise zu versammeln.


Und wenn wir diese Liste durchgehen, haben wir Streaming und die Geschwindigkeit des Eintreffens von Daten. Ich denke, einer der Gründe für die Popularität von Hadoop ist, dass damit eine Menge Daten erfasst werden können. Es kann auch die Geschwindigkeit der Daten erfassen, dh, wenn Sie sie nicht sofort verwenden müssen, handelt es sich um eine schöne parallele, riesige parallele Umgebung. Sie haben jedoch auch die Tatsache, dass derzeit eine ganze Reihe von Streaming-Analysen durchgeführt wird. Früher war nur der Bankensektor an Streaming-Anwendungen interessiert, jetzt ist er global ausgerichtet. Und jeder betrachtet Streaming-Anwendungen auf die eine oder andere Art und Weise, als potenzielles Mittel, um Wert aus Daten zu ziehen und Analysen für das Unternehmen durchzuführen.


Wir haben die unstrukturierten Daten. Die Statistik, die in der Regel Teil der nur 10% der weltweiten Daten war, befand sich in relationalen Datenbanken. Nun, einer der Hauptgründe dafür war, dass es größtenteils eigentlich unstrukturiert war und es war - ein Großteil davon war im Web zu finden, aber ziemlich verstreut über verschiedene Websites. Diese Daten haben sich auch als auswertbar und nutzbar erwiesen. Und mit dem Aufkommen der Symantec-Technologie, die sich allmählich in die Situation einschleicht, wird dies immer mehr.Es besteht also die Notwendigkeit, unstrukturierte Daten tatsächlich zu erfassen und zu verwalten. Dies bedeutet, dass sie viel größer sind als zuvor. Wir haben soziale Daten, die ich bereits erwähnt habe, aber das Wichtigste ist, dass diese wahrscheinlich bereinigt werden müssen.


Wir haben Daten zum Internet der Dinge. Das ist eine andere Situation. Es wird wahrscheinlich so viel davon geben, aber ein Großteil davon muss irgendwo in der Nähe des Ortes verteilt bleiben, an dem es ausgeführt wird. Aber Sie werden auch auf die eine oder andere Art und Weise die Analyse der Daten innerhalb des Unternehmens durchführen wollen. Das ist also noch ein weiterer Faktor. Und diese Daten werden anders strukturiert, weil sie wahrscheinlich - wahrscheinlich in JSON oder XML formatiert sind, so dass sie sich selbst deklarieren. Und nicht nur auf die eine oder andere Weise ziehen wir tatsächlich Daten ein und sind in der Lage, eine Art Schema für das Lesen dieser bestimmten Daten zu erstellen.


Wir haben das Provenienzproblem, und dies ist ein Analyseproblem. Die Ergebnisse einer Analyse, die Sie tatsächlich durchführen, können - wenn Sie möchten - nicht als gültig eingestuft werden, es sei denn, Sie kennen die Herkunft der Daten. Ich meine, das ist nur Professionalität in Bezug auf die Aktivität von Datenwissenschaftlern. Aber Sie wissen, um Daten zu erhalten, müssen wir die Daten tatsächlich verwalten und eine Notiz zu ihrer Herkunft machen.


Wir haben das Problem der Computerleistung und der Parallelen und alles, was dazu beiträgt, dass alles schneller geht. Das Problem ist, dass bestimmte Prozesse, die wir eingerichtet haben, für alles andere zu langsam sein können. Es kann also zu Geschwindigkeitsunterschieden kommen.


Wir haben das Aufkommen des maschinellen Lernens. Das maschinelle Lernen hat tatsächlich den Effekt, dass die Analytik ein anderes Spiel ist als zuvor. Aber Sie können es nur wirklich nutzen, wenn Sie die Kraft haben.


Wir haben die Tatsache, dass es neue analytische Workloads gibt. Wir haben eine Parallelwelt und einige analytische Algorithmen müssen parallel ausgeführt werden, um maximale Wirkung zu erzielen. Das eigentliche Problem besteht also darin, wie Sie die Daten tatsächlich auf die eine oder andere Weise verschieben und die Daten bereitstellen, wenn sie verfügbar sind. Und wo Sie die analytischen Workloads tatsächlich ausführen, weil Sie dies möglicherweise innerhalb der Datenbank tun. Sie können dies also in analytischen Anwendungen tun.


Es gibt also eine ganze Reihe von Governance-Herausforderungen. Was wir in diesem Jahr gemacht haben - die Forschung, die wir in diesem Jahr durchgeführt haben, drehte sich wirklich um Big-Data-Architektur. Und wenn wir tatsächlich versuchen, es zu verallgemeinern, sah die Schlussfolgerung, zu der wir gekommen sind - das Diagramm, das wir gefunden haben, ungefähr so ​​aus.


Darauf werde ich nicht näher eingehen, zumal Mike eine ganze Menge über die Datenarchitektur für Analysen tun wird. Ich mag es jedoch, wenn sich die Leute nur auf diesen unteren Bereich konzentrieren, in dem wir auf die eine oder andere Weise Daten zusammenstellen. Wir haben etwas, auf das ich verweisen möchte, nämlich die Datenraffinerie oder das Datenverarbeitungszentrum. Und hier findet die Governance statt. Wenn wir uns also irgendwie darauf konzentrieren, sieht es so aus. Sie wissen, es wird von Daten aus internen und externen Quellen gespeist. Der Hub sollte theoretisch alle generierten Daten aufnehmen. Es sollte entweder gestreamt und so verwaltet werden, wie es gestreamt wurde, wenn Sie Analysen und Streaming-Daten durchführen müssen, und dann an den Hub übergeben werden. Sonst kommt alles in die Nabe. Und es gibt eine Reihe von Dingen, die im Hub stattfinden. Darüber hinaus können im Hub keine bestimmten Analysen und SQL-Vorgänge ausgeführt werden. Sie benötigen jedoch auch eine Datenvirtualisierung in jeder Zelle, um Daten in andere Bereiche zu verschieben. Aber bevor dies geschieht, müssen Sie tatsächlich auf die eine oder andere Weise die Datenaufbereitung verfeinern. Sie können es Datenaufbereitung nennen. Es ist viel größer als das. Dies sind die Dinge, die ich denke, dass es beinhaltet.


Wir haben System- und Service-Management in gewissem Sinne, das dies der Hauptteil der Datenschicht ist. Dann müssen wir tatsächlich alle Systemverwaltungsaufwände, die wir bisher für das Management von Betriebssystemen unternommen haben, auf so ziemlich alle Betriebssysteme anwenden. Auf die eine oder andere Weise müssen wir jedoch auch andere Vorgänge überwachen, um sicherzustellen, dass diese verschiedenen Service-Levels eingehalten werden, da es zwangsläufig definierte Service-Levels oder jede Art von Analytics gibt, die als ausgeführt gelten, oder BI-Daten gehandelt werden.


Wir brauchen Leistungsüberwachung und -management. Wenn überhaupt, brauchen wir das, um zu wissen, welche weiteren Computerressourcen wir möglicherweise zu verschiedenen Zeitpunkten zuweisen müssen. Aber auch die Arbeitsbelastung ist hier tatsächlich sehr hoch, ziemlich komplex und konkurriert miteinander um Ressourcen. In diesem Bereich muss etwas ziemlich Raffiniertes getan werden.


Wir haben jetzt einen Datenlebenszyklus, den wir noch nie zuvor hatten. Der Deal hier ist wirklich über alles, dass wir vorher keine Daten gesammelt und weggeworfen haben. Wir haben in der Regel die benötigten Daten gesammelt und wahrscheinlich aufbewahrt und sie dann archiviert. Aber wir werden von nun an sehr viel tun, um Daten zu untersuchen. Und wenn Sie die Daten nicht möchten, lassen Sie uns sie vergraben. Die Datenlebenszyklen sind also je nach Situation unterschiedlich, werden aber auch eine sehr viel größere Datenaggregation sein. Sie wissen also, woher ein Aggregat stammt, was die… was die Quelle der Aggregation ist, und so weiter und so fort. Das ist alles notwendig.


Datenlinie verleiht natürlich. Ohne müssen Sie die Probleme kennen, also die Daten ... Wir müssen wissen, dass die Daten gültig sind, aber wie zuverlässig sie tatsächlich sind.


Wir haben auch eine Datenzuordnung, da viele Daten tatsächlich auf die eine oder andere Weise vorliegen werden. Und das ist, wenn Sie möchten, in gewissem Umfang bei MDM. Es ist jetzt nur viel komplizierter, denn wenn Sie eine Menge von Daten haben, die von JSON definiert wurden oder auf unserem XML-Schema beim Lesen basieren, müssen Sie auf die eine oder andere Weise sehr aktiv sein Datenmapping-Aktivität läuft.


Es gibt eine Metadatenverwaltungssituation, die mehr ist als MDM, da es auf die eine oder andere Weise erforderlich ist, das aufzubauen, was ich jetzt als eine Art Metadaten-Warehouse für alles ansehen möchte, woran Sie interessiert sind. Es gibt Metadaten Entdeckung, da einige der Daten nicht unbedingt ihre Metadaten deklariert haben und wir sie sofort verwenden möchten. Und dann gibt es Datenbereinigung, was eine große Sache ist, wie viele Dinge man dort tun kann. Und es gibt auch Datensicherheit. Alle diese Daten müssen auf einem akzeptablen Niveau gesichert werden, und das kann in bestimmten Fällen sogar bedeuten, dass beispielsweise viele Werte verschlüsselt werden.


Die gesamte Arbeitsbelastung ist also das Governance-Imperium. All dies muss auf die eine oder andere Weise zur gleichen Zeit oder vor unserer gesamten analytischen Tätigkeit geschehen. Dies ist eine große Anzahl von koordinierten Anwendungen. Es ist ein eigenständiges System. Und dann leiden diejenigen, die dies zu verschiedenen Zeitpunkten nicht tun, im weiteren Verlauf unter einem Mangel, da eine ganze Menge dieser Dinge nicht wirklich optional sind. Am Ende steigt die Entropie nur an, wenn Sie dies nicht tun.


In Bezug auf Datenanalyse und Governance würde ich also sagen, dass tatsächlich eine Hand die andere wäscht. Ohne Governance geraten Analytics und BI nicht rechtzeitig ins Wanken. Und ohne Analytics und BI wäre es sowieso nicht erforderlich, die Daten zu steuern. Die beiden Dinge gehen also wirklich Hand in Hand. Im Nahen Osten heißt es: "Eine Hand wäscht die andere." Und das ist eigentlich alles, was ich zu sagen habe. Ich hoffe - hoffentlich haben wir jetzt Mike zurück.


Eric: Das machen wir. Mike, ich nehme an, du bist da. Ich werde dein Dia nach oben schieben.


Mike: Das bin ich. Okay, kannst du mich hören?


Eric: Ja, ich kann dich hören. Du klingst wundervoll. Also, lassen Sie mich vorstellen ... Los geht's. Und du bist jetzt der Moderator. Nimm es weg.


Mike: Okay, danke! Guten Morgen, guten Nachmittag, guten Abend euch allen da draußen. Vergib den Schluckauf am Anfang. Aus irgendeinem Grund habe ich mich stumm geschaltet und kann alle sehen, aber sie konnten mich nicht hören.


In Ordung. Ich möchte also schnell über das Big-Data-Analyse-Ökosystem sprechen. Wenn Sie mir in dieser oder einer späteren Sitzung Fragen stellen möchten, können Sie mich hier über meine Kontaktdaten erreichen. Wie gesagt, mitten in der Nacht hier in Großbritannien.


Nun, lassen Sie mich zu dem kommen, worüber ich sprechen möchte. In den letzten Jahren sind alle Arten von Daten aufgetaucht, die Unternehmen jetzt analysieren möchten - von Clickstream-Daten über das Verständnis von Online-Verhalten bis hin zu Social-Media-Daten, über die Eric auf der Konferenz sprach Beginn des Programms hier. Ich denke, Robin erwähnte JSON, BSON, XML - also halbstrukturierte Daten, die sich selbst beschreiben. Natürlich haben wir auch eine Menge anderer Dinge - alles von unstrukturierten Daten, Protokollen der IT-Infrastruktur bis hin zu Sensordaten. All diese relativ neuen Datenquellen, an denen sich Unternehmen inzwischen interessiert haben, weil sie wertvolle Erkenntnisse enthalten, die möglicherweise unser Wissen vertiefen könnten.


Das bedeutet im Grunde genommen, dass die analytische Landschaft über das traditionelle Data Warehousing hinausgegangen ist. Wir strukturieren Daten immer noch in die Welt einer Kombination aus strukturierten und multistrukturierten Daten, wobei die multistrukturierten Daten in vielen Fällen von innerhalb oder außerhalb des Unternehmens stammen können. Und als Ergebnis dieser neuen Datentypen und neuen Anforderungen an die Analyse sind neue analytische Workloads entstanden - angefangen von der Analyse von Daten in Bewegung, die die traditionelle Data-Warehousing-Architektur in gewisser Weise auf den Kopf stellen Integrieren Sie in traditionellen Kreisen Daten, bereinigen Sie sie, transformieren Sie sie, speichern Sie sie und analysieren Sie sie. Bei der Analyse von Daten in Bewegung erfassen wir die Daten, integrieren sie, bereiten sie auf, indem wir sie analysieren und dann speichern. Daher werden Daten analysiert, bevor sie irgendwo gespeichert werden.


Wir analysieren strukturierte Daten komplex, vielleicht für die Modellentwicklung, die statistische und die prädiktive Modellentwicklung. Dies ist für einige Leute in einem traditionellen Data-Warehousing-Bereich nichts Neues. Wir haben eine explorative Analyse der Modelldaten. Das ist die Menge an strukturierten Daten. Wir haben neue Workloads in Form von Diagrammanalysen, zu denen für meine Kunden im Finanzdienstleistungsbereich Betrug gehört. Dazu gehört auch die Cybersicherheit. Dazu gehören natürlich soziale Netzwerke, die Influencer und ähnliches verstehen. Ich habe es sogar im Management gemeistert, habe einige Jahre Graphanalyse hinter mir.


Wir haben die Data-Warehouse-Optimierung oder das Auslagern der ETL-Verarbeitung, die eher eine Art IT-Anwendungsfall darstellt. Der CIO könnte dies finanzieren. Und sogar das Archivieren von Daten und Data Warehouses, um sie in Dingen wie Hadoop online zu halten. Alle diese neuen analytischen Workloads haben der analytischen Landschaft neue Plattformen, neue Speicherplattformen hinzugefügt. Anstatt nur herkömmliche Data Warehouses oder Data Marts zu haben, haben wir jetzt Hadoop. Wir haben NoSQL-Datenbanken, z. B. Graphendatenbanken, die häufig für analytische Workloads verwendet werden. Natürlich können wir jetzt sowohl in Hadoop selbst als auch in NoSQL-Graph-DBMSs eine Graphanalyse durchführen. Wir haben Streaming-Analysen, die Robin erwähnt hat. Und wir haben - wenn Sie möchten - die Möglichkeit, Modelle auch auf analytischen Data-Warehouse-Geräten zu erstellen. All dies hat die analytische Landschaft jedoch kompliziert, da jetzt mehrere Plattformen benötigt werden. Und ich denke, die Herausforderung für jedes Geschäft mit einem Front-Office oder Back-Office oder Finanzen, Beschaffung, Personal und einer Art von Operationen ist es, herauszufinden, welche analytischen Projekte mit einer traditionellen Data-Warehousing-Szene verbunden sind. Und wenn Sie wissen, dass mit diesen neuen Big-Data-Plattformen analytische Projekte verbunden sind und wo sie ausgeführt werden sollen, wissen Sie, welche analytische Arbeitslast erforderlich ist, ohne jedoch das Geschäft in dem Sinne aus den Augen zu verlieren, dass es sich um eine Kombination aus großen Projekten handelt Datenanalyseprojekte und traditionelle Big-Data-Warehousing-Projekte, die zusammen benötigt werden, um den Kunden oder das Geschäft, das Risiko, die Finanzen oder die Nachhaltigkeit zu stärken. Und deshalb möchten wir, dass all dies mit unseren strategischen Geschäftsprioritäten in Einklang gebracht wird. Wir bleiben auf dem richtigen Weg, um die Nadeln einzudrücken, die eingedrückt werden müssen, um die Geschäftsleistung zu verbessern und die Kosten zu senken. Sie wissen, um Risiken usw. für unser gesamtes Unternehmen zu verringern. Es ist also nicht so, dass das eine das andere durch Big Data und traditionelles ersetzt. Es wird beides zusammen verwendet. Und das verändert die Architektur dramatisch.


Ich habe hier also eine relativ neue Architektur, die ich mit meinen Kunden verwenden werde. Wie Sie unten sehen können, gibt es eine Vielzahl von Datenquellen, die nicht mehr nur strukturiert sind. Einige von ihnen streamen Live-Daten wie Sensoren, Marktdaten usw. Es könnten sogar Live-Clickstream-Daten sein. Es könnten Live-Video-Streaming-Daten sein. Es musste also nicht strukturiert werden. Wir können also Datenströme verarbeiten, um automatische Aktionen in Echtzeit durchzuführen, und alle relevanten Daten können gefiltert und an ein Enterprise Information Management-Tool übergeben werden, mit dem analytische Datenspeicher aufgefüllt werden können. Sofern Sie hier nichts in der Mischung sehen können, verfügen wir jetzt über traditionelle Data Warehousing-, Hadoop- und NoSQL-Datenbanken. Wir haben auch Stammdatenmanagement im Mix. Dies erhöht den Druck auf die gesamte Tool-Suite für die Datenverwaltung, da nicht nur diese Datenspeicher gefüllt, sondern auch Daten zwischen ihnen verschoben werden müssen.


Darüber hinaus müssen wir die Zugriffstools vereinfachen. Wir können uns nicht einfach an den Benutzer wenden und sagen: "Holen Sie sich all diese Datenspeicher, halten Sie diese APIs bereit - Ihr Problem." Sie müssen lediglich den Zugriff vereinfachen. In den gestrichelten Linien sehen Sie also, dass die Datenvirtualisierung und -optimierung die Komplexität der Speicherung mehrerer Daten verdeckt. Versuchen Sie, den Endbenutzern den Zugriff darauf zu erleichtern. Darüber hinaus gibt es natürlich eine Reihe von Tools - alles von traditionellen BI-Tools, die an der Spitze des Data Warehouses angefangen haben und sich schrittweise nach links in Ihrem Diagramm bewegen, um sich mit Hadoops zu verbinden und dann NoSQL-Datenbanken der Welt.


Wir haben eine Suche, die das Leben von strukturierten und nicht strukturierten Daten, die häufig in Hadoop gespeichert werden, neu belebt. Wir haben benutzerdefinierte Analyseanwendungen für eine Hadoop-Plattform mit MapReduce, z. B. das Spark-Framework. Wir verfügen über Tools zur Grafikanalyse, mit denen Sie sich auf sehr spezifische Workloads konzentrieren können. Daher sind eine Reihe von Tools und der Datenfluss auch komplexer. Es ist nicht mehr nur eine Einbahnstraße im Data Warehouse. Jetzt sind es natürlich Stammdaten.


Wir haben neue Datenquellen, die entweder in NoSQL erfasst werden, oder Datenspeicher wie MongoDB, wie Cassandra, wie HBase. Wir haben Daten erhalten, die direkt in Hadoop zur Analyse und Datenaufbereitung gebracht werden. Wir haben neue Erkenntnisse aus Hadoop und den Data Warehouses. Wir haben ein Archiv aus den Data Warehouses in Hadoop. Jetzt haben wir Daten-Feeds, die alle NoSQL-Datenbanken und Data Marts betreffen. Was Sie hier sehen können, ist, dass im Datenmanagement viel mehr Aktivitäten stattfinden. Dies bedeutet, dass die Datenverwaltungssoftware erheblich unter Druck gerät. Es ist nicht mehr nur eine Einbahnstraße. Es handelt sich um eine bidirektionale Datenübertragung. Es sind viel mehr Aktivitäten im Gange, und daher ist die Skalierbarkeit sowohl in Bezug auf das Datenmanagement-Tool als auch in Bezug auf die Datenquelle wichtig.


Diese Grafik geht also auf die Architektur zurück, die ich vorhin erwähnt habe. Es zeigt Ihnen die verschiedenen analytischen Workloads, die in verschiedenen Teilen dieser Architektur ausgeführt werden. Ganz unten links gibt es Echtzeit-Streaming und die Stream-Verarbeitung wird für Daten ausgeführt, die aus einem beliebigen Live-Datenspeicher stammen. Es findet eine Klassenanalyse für NoSQL-Graphendatenbanken statt. Es kann auch auf Hadoop passieren. Mit dem Spark-Framework zum Beispiel und GraphX ​​haben wir eine investigative Analyse und die Datenraffinerie, über die Robin auf Hadoop gesprochen hat. Wir haben immer noch traditionelle Workloads und Data Warehousing, wissen Sie, Power-User, die statistische und prädiktive Modelle erstellen, möglicherweise auf Data-Warehouse-Appliances. Wir versuchen immer noch, den Zugriff auf all dies zu vereinfachen, um es den Endbenutzern zu erleichtern.


Der Erfolg dieses gesamten Setups ist also mehr als nur die analytische Seite. Sie wissen, wir können die Analyseplattformen einrichten, aber wenn wir Daten mit hoher Geschwindigkeit und großem Datenvolumen auf der Skala nicht erfassen und erfassen können, gibt es nicht viel Sinn. Wissen Sie, ich habe nichts zu analysieren. Für den Erfolg der Big-Data-Analyse sind daher betriebliche Systeme erforderlich, um skaliert werden zu können. Das heißt, neue Transaktionen unterstützen zu können, wissen Sie, Spitzen. Sie wissen, dass alle nicht transaktionsbezogenen Daten, die dort erfasst werden, sehr, sehr hohe Eintreffraten für Hochgeschwindigkeitsdaten wie Sensoren oder Eingaben aufweisen können. Wir müssen in der Lage sein, all das zu bewerkstelligen - um diese Art von Daten zu erfassen und zur Analyse einzubringen. Wir müssen auch die Analyse selbst skalieren und den Zugriff auf die bereits erwähnten Daten vereinfachen. Und dann binde das zusammen. Wissen Sie, wir müssen in der Lage sein, diese operativen Systeme zu verfeinern, um eine geschlossene Schleife zu erhalten.


Wenn Sie also die betriebliche Seite des Hauses skalieren, um Daten zu erfassen, können Sie in die Welt der NoSQL-Datenbank einsteigen. Ich meine, hier sehen Sie fünf Kategorien von NoSQL-Datenbanken. Diese Kategorie wird nur als Kombination der anderen vier oben modelliert. Im Allgemeinen wissen Sie, welche Schlüsselwerte, gespeicherten Dokumente und Spaltenfamiliendatenbanken - die ersten drei dort - für die mehr Art von Transaktions- und Nicht-Transaktionsdaten verwendet werden.


Einige dieser Datenbanken unterstützen als Eigenschaften; einige von ihnen nicht. Sie wissen jedoch, dass wir die Einführung solcher Anwendungen sehen, um diese Art von Anwendungen zu skalieren. Und so haben wir uns zum Beispiel von Mitarbeitern verabschiedet, die Transaktionen über Tastaturen eingeben, und sind nun zu Kunden und Massen über neuartige Geräte gegangen, um dies zu tun. Wir haben einen enormen Anstieg der Zahl der Transaktionen festgestellt, die in Unternehmen getätigt werden. Dazu müssen wir Transaktionsanwendungen skalieren.


Im Allgemeinen kann dies für NewSQL-Datenbanken wie die hier gezeigten relationalen Datenbanken NuoDB und VoltDB durchgeführt werden. Oder einige der NoSQL-Datenbanken, die möglicherweise ACID-Eigenschaften unterstützen, die die Transaktionsverarbeitung gewährleisten können, sind möglicherweise aktiv. Dies gilt auch für nicht-transaktionale Daten, wie z. B. Warenkorbdaten vor einer Transaktion, bevor Leute etwas kaufen, Sensordaten, wie Sie wissen, da ich einen Sensorwert zwischen Hunderten von Millionen von Sensorwerten verliere. Es ist keine große Sache. Klicks, wissen Sie, in der Clickstream-Welt - wenn ich einen Klick verwende, ist das keine große Sache.Wissen Sie, wir müssen dort nicht unbedingt über ACID-Eigenschaften verfügen, und hier kamen häufig NoSQL-Datenbanken ins Spiel, nämlich die Fähigkeit, diese neuen Arten von Daten in sehr hohem Umfang und in genauem Umfang zu verarbeiten.


Gleichzeitig möchten wir, dass die Analysen skaliert werden. Wenn Sie also die Daten aus den Datenspeichern auf die Analyseplattformen ziehen, wird dies nicht mehr gehackt, da die Daten zu groß sind. Was wir wirklich wollen, ist, die Analyse in die andere Richtung in das Enterprise Data Warehouse in Hadoop zu verschieben, in die Stream-Verarbeitung, um die Analyse in die Daten zu verschieben. Nur weil jemand sagt, dass es sich um eine Datenbankanalyse oder eine Hadoop-Analyse handelt, bedeutet dies nicht zwangsläufig, dass die Analysen parallel ausgeführt werden. Um ehrlich zu sein, müssen die Analysen parallel ausgeführt werden, wenn Sie in diese neuen, massiv parallel skalierbaren Technologien wie Hadoop, wie die Data Warehouse-Appliances und so weiter, wie die Clustered Stream Processing Engines, investieren möchten.


Das ist also nur die Kasse. Wissen Sie, wenn wir Analysen haben, mit denen wir Kunden, Vorgänge, Risiken usw. vorhersagen können, möchten wir, dass sie parallel und nicht nur auf der Plattform ausgeführt werden. Wir wollen beides. Und das liegt daran, dass Technologie wie diese neuen visuellen Erkennungstools wie SAS ist. Es ist tatsächlich einer unserer Sponsoren hier.


Was die Leute wollen, ist zumindest, die in Hadoop und dann in der Datenbankanalyse auszunutzen. Und wir möchten, dass diese parallel ausgeführt werden, um die Leistung zu erzielen, die für ein so hohes Datenvolumen erforderlich ist. Gleichzeitig versuchen wir, den Zugriff auf all dies zu vereinfachen. SQL ist jetzt wieder auf der Tagesordnung. Sie wissen, SQL ist - SQL auf Hadoop ist gerade heiß. Ich verfolge es gerade in 19 SQL- und Hadoop-Initiativen. Wie Sie sehen, können wir auf verschiedene Weise auf diese Daten zugreifen, sodass wir beim direkten Zugriff auf SQL in Hadoop selbst SQL-Anweisungen für einen Suchindex verwenden können. Wie Sie wissen, haben einige der Suchanbieter in diesem Bereich SQL-Zugriff auf analytische relationale Datenbanken, die Excel-Tabellen für Hadoop enthalten.


Wir können nun SQL-Zugriff auf einen Datenvirtualisierungsserver haben, der wiederum mit einem Data Warehouse auf Hadoop verbunden werden kann. Ich beginne gerade, die Entstehung des SQL-Zugriffs auf Live-Streaming-Daten zu beobachten. Der SQL-Zugriff auf all dies nimmt also rasant zu. Ein Teil der Herausforderung liegt darin, dass der SQL-Zugriff dort vermarktet wird. Die Frage ist, kann SQL mit komplexen Daten umgehen? Und das ist nicht unbedingt einfach. Hier treten alle möglichen Komplikationen auf, einschließlich der Tatsache, dass JSON-Daten verschachtelt sein können. Wir können Schemavariantensätze haben. Der erste Datensatz hat also ein Schema. Der zweite Datensatz hat ein anderes Schema. Diese Dinge unterscheiden sich sehr von dem, was in einer relationalen Welt passiert.


Wir müssen uns also fragen, um welche Art von Daten es sich handelt, die wir analysieren möchten, und welche Art von analytischen Merkmalen es gibt. Ist es, wissen Sie, Panel, das Sie tun möchten? Ist es maschinelles Lernen? Ist es eine Graphanalyse? Können Sie das von SQL aus tun? Wissen Sie, ist das von SQL aus aufrufbar? Wie viele gleichzeitige Benutzer haben wir dies getan? Wir haben Hunderte von Nutzern gleichzeitig. Ist das bei komplexen Daten möglich? All diese Dinge sind Schlüsselfragen. Also habe ich hier eine Liste von ein paar gemacht, über die Sie nach meinem Dafürhalten nachdenken sollten. Wissen Sie, welche Dateiformate? Um welche Datentypen handelt es sich? Welche Art von Analysefunktionen können wir aus SQL aufrufen, um auf komplexe Daten zuzugreifen? Und Art der Funktionen laufen parallel. Ich meine, sie müssen parallel laufen, wenn wir das skalieren können. Und kann ich heute in Hadoop Daten außerhalb von Hadoop verknüpfen, oder ist das nicht möglich? Und was mache ich mit all diesen verschiedenen Arten von Abfrage-Workloads?


Und wie wir sehen werden, gibt es nach dem, was ich gesehen habe, viele Unterschiede zwischen der SQL- und der Hadoop-Distribution. Dies sind alles diejenigen, die ich verfolge. Übrigens, das ist reines SQL auf Hadoop. Dies beinhaltet noch nicht einmal die Datenvirtualisierung. Und so viel da draußen und viel Raum für Konsolidierung, was meiner Meinung nach im nächsten Jahr, ungefähr achtzehn Monaten, passieren wird. Aber es eröffnet auch eine andere Sache, nämlich, dass ich in Hadoop möglicherweise mehrere SQL-Engines auf denselben Daten haben kann. Und das ist etwas, was Sie in einer Beziehung nicht tun können.


Das bedeutet natürlich, dass Sie dann wissen müssen, welche Art von Abfragearbeit ich ausführe. Sollte ich das auf einer bestimmten SQL-on-Hadoop-Initiative stapelweise ausführen? Soll ich interaktive Abfrage-Workloads über eine andere SQL-On-Hadoop-Initiative usw. ausführen, damit ich weiß, zu welcher eine Verbindung hergestellt werden soll? Idealerweise sollten wir das natürlich nicht tun. Wir hätten einfach eine Frage dazu stellen sollen. Wissen Sie, einige Optimierer finden heraus, wie es am besten geht. Aber meiner Meinung nach sind wir noch nicht vollständig da.


Die oben erwähnte Datenvirtualisierung spielt jedoch auch eine wichtige Rolle bei der Vereinfachung des Zugriffs auf mehrere Datenspeicher. Und wenn wir neue Erkenntnisse über Hadoop gewinnen, ist es sicherlich plausibel, dass wir diese Data-to-Data- und traditionellen Data-Warehouses beispielsweise durch Datenvirtualisierung verbinden, ohne die Daten zwangsläufig von Hadoop in herkömmliche Data-Warehouses zu verschieben. Das können Sie natürlich auch. Es ist auch plausibel, wenn ich Daten aus herkömmlichen Data Warehouses in Hadoop archiviere. Ich kann immer noch darauf zugreifen und es wieder mit dem Material verbinden, das sich in unserem Data Warehouse für die Datenvirtualisierung befindet. Daher denke ich, dass die Datenvirtualisierung in dieser Gesamtarchitektur eine große Zukunft hat und den Zugriff auf alle diese Datenspeicher vereinfacht.


Und um nicht zu vergessen, dass wir bei der Erstellung dieser neuen Erkenntnisse, sei es auf relationalen oder NoSQL-Systemen, diese Erkenntnisse immer noch in unsere Abläufe einfließen lassen möchten, damit wir den Wert des Gefundenen maximieren können Nutzen Sie dies für effektivere und zeitnahere Entscheidungen in diesem Umfeld, um unser Geschäft zu optimieren.


Zum Abschluss brauchen wir also, wissen Sie, neue Datenquellen. Wir haben neue Plattformen mit einer komplizierteren Architektur, wenn Sie dies möchten. Und Hadoop wird sehr, sehr wichtig, genug für die Datenvorbereitung für unsere flüssigen Sandkästen, für die Archivabfrage, das Archivieren aus dem Data Warehouse, das Datenmanagement, das über das Data Warehousing hinausgeht und das Verwalten von Daten auf all diesen Plattformen sowie für neue Tools Sie können Daten in diesen Umgebungen analysieren und darauf zugreifen, skalierbare Technologien für eine bessere Datenaufnahme verwenden und die Analyse skalieren, indem sie auf die Plattformen übertragen werden, um sie paralleler zu gestalten. Und dann hoffentlich auch, um den Zugriff auf alles zu vereinfachen, indem das aufkommende SQL über den Haufen geworfen wird. Auf diese Weise erhalten Sie eine Vorstellung davon, wohin wir unterwegs sind. Damit gehe ich zurück zu Eric, oder?


Eric: Okay, das ist fantastisch. Und Leute, ich muss sagen, zwischen dem, was Sie gerade von Robin und Mike bekommen haben, ist es wahrscheinlich so umfassend und prägnant im Überblick über die gesamte Landschaft, wie Sie es irgendwo finden werden. Lassen Sie mich zuerst George Corugedo in die Warteschlange stellen. Und da ist es. Lassen Sie mich dies für eine kurze Sekunde nehmen. Okay, George, ich werde dir gleich die Schlüssel geben und sie wegnehmen. Der Boden gehört dir.


George: Großartig! Vielen Dank, Eric, und vielen Dank, Rob und Mike. Das waren großartige Informationen und viele, denen wir zustimmen. Zurück zu Robins Diskussion, denn es ist kein Zufall, dass RedPoint und SAS hier sind. Bei RedPoint konzentrieren wir uns wirklich auf die Datenseite, auf die Governance, die Verarbeitung der Daten und die Vorbereitung für den Einsatz in der Analytik. Lassen Sie mich einfach durch diese beiden Folien stapfen. Und sprechen Sie wirklich über Robins Argumente zu MDM und wie wichtig und nützlich Hadoop in der Welt des MDM und der Datenqualität sein kann.


Weißt du, Robin hat ein bisschen darüber gesprochen, wie das mit der Enterprise-Data-Warehouse-Welt zusammenhängt, und ich komme - weißt du, ich habe einige Jahre bei Accenture verbracht. Und was dort interessant war, ist, wie oft wir in Unternehmen gehen mussten, um herauszufinden, was mit dem Data Warehouse zu tun ist, das im Grunde aufgegeben wurde. Und vieles geschah, weil das Data-Warehouse-Team seinen Build nicht wirklich an den Geschäftsbenutzern oder den Verbrauchern der Daten ausrichtete. Oder es dauerte so verdammt lange, dass sich zu dem Zeitpunkt, an dem sie das Ding gebaut haben, die geschäftliche Nutzung oder die geschäftlichen Gründe dafür entwickelt hatten.


Ich freue mich riesig über die Idee, Hadoop für das Stammdatenmanagement, für die Datenqualität und für die Datenaufbereitung zu verwenden, und denke, dass Sie jederzeit zu den atomaren Daten in a zurückkehren können Hadoop Data Lake, Data Reservoir, Data Repository, Hub oder was auch immer für ein Summenformular Sie verwenden möchten. Aber weil Sie immer diese atomaren Daten behalten, haben Sie immer die Möglichkeit, sich mit den Geschäftsbenutzern neu auszurichten. Denn als Analyst - weil ich meine Karriere als Statistiker begonnen habe - ist nichts schlimmer als, wie Sie wissen, Enterprise Data Warehouses, die sich hervorragend für die Erstellung von Berichten eignen, aber wenn Sie wirklich prädiktive Analysen durchführen möchten, sind sie es wirklich nicht so nützlich, denn was Sie wirklich wollen, sind die granularen Verhaltensdaten, die irgendwie im Data Warehouse zusammengefasst und aggregiert wurden. Ich denke also, das ist wirklich ein wichtiges Merkmal, und das ist eine Sache, bei der ich der Meinung bin, dass ich Robin widersprechen könnte, wenn ich persönlich Daten so lange wie möglich im Datensee oder im Datenhub belasse, weil so lange wie möglich Daten sind da und es ist sauber, Sie können sie aus einer Richtung, einer anderen Richtung betrachten. Sie können es mit anderen Daten zusammenführen. Sie haben immer die Möglichkeit, darauf zurückzukommen und sich neu zu strukturieren und sich dann mit einer Geschäftseinheit und dem Bedarf, den diese Einheit haben könnte, neu auszurichten.


Eine andere interessante Sache ist, dass wir sehen, dass das alles direkt in Hadoop ankommt, da es eine so leistungsstarke Computerplattform ist, die viel von der Arbeitslast hat, über die wir gesprochen haben. Und während Mike, glaube ich, über all die verschiedenen Technologien sprach, die es in der Welt gibt - in dieser Art von Big-Data-Ökosystem sind wir der Meinung, dass der Hadoop wirklich das Arbeitstier ist, um diesen großen Umfang bei der rechenintensiven Verarbeitung zu erreichen Stammdaten und Datenqualität erfordern. Denn wenn Sie es dort tun können, wissen Sie, ist dies schon die reine Wirtschaftlichkeit des Verschiebens von Daten aus Ihren teuren Datenbanken in wirtschaftliche Datenbanken, die im Moment in großen Unternehmen einen so großen Teil der Akzeptanz ausmacht.


Nun gibt es natürlich einige Herausforderungen, oder? Es gibt Herausforderungen rund um die Technologien. Viele von ihnen sind sehr unreif. Ich würde sagen, weißt du, ich weiß nicht, wie viele, aber einige der Technologien, die Mike erwähnt hat, sind immer noch auf Nullpunkt-Releases, oder? Diese Technologien sind also sehr jung, sehr unausgereift und noch codebasiert. Und das ist eine echte Herausforderung für Unternehmen. Und wir konzentrieren uns wirklich auf die Lösung von Problemen auf Unternehmensebene. Wir sind der Meinung, dass es einen anderen Weg geben muss, und das ist, was wir vorschlagen, ein anderer Weg, um einige der Dinge, die bei der Verwendung einiger dieser gerade entstehenden Technologien anfallen, zu erledigen.


Das andere interessante Problem, das bereits erwähnt wurde, ist, dass bei Daten, die Sie in einer Hadoop-Umgebung eines beliebigen Typs erfassen, in der Regel das Schema beim Lesen und nicht das Schema beim Schreiben verwendet wird mit einigen ausnahmen. Und diese Lektüre wird viel von Statistikern gemacht. Daher müssen die Statistiker über Tools verfügen, mit denen sie die Daten für Analysezwecke ordnungsgemäß strukturieren können, da sie letztendlich in irgendeiner Form strukturiert sein müssen, um einige zu sehen oder eine Frage zu beantworten Ein Unternehmen, eine Art von Geschäft, schafft Geschäftswert.


Wir haben also eine sehr breit angelegte und ausgereifte EPL-, ELT-Datenqualitäts-Hauptschlüssel- und Verwaltungsanwendung. Es ist seit vielen, vielen Jahren auf dem Markt. Und es verfügt über die gesamte Funktionalität oder einen Großteil der Funktionalität, die Robin in diesem Kreisdiagramm aufgelistet hat - von der reinen Rohdatenerfassung in einer Vielzahl von Formaten und XML-Strukturen und so weiter bis hin zur Möglichkeit, die gesamte Bereinigung durchzuführen Vervollständigung der Daten, die Korrektur der Daten, die georäumlichen Kernbits der Daten. Das wird heutzutage mit dem Internet der Dinge immer wichtiger. Wissen Sie, es gibt eine Geografie, die mit vielem von dem, was wir tun, oder mit vielem von diesen Daten zusammenhängt. Das Parsing, das Tokenisieren, das Bereinigen, das Korrigieren, das Formatieren, das Strukturieren usw. wird auf unserer Plattform durchgeführt.


Und dann und vielleicht denken wir am wichtigsten an die Idee der Deduplizierung. Wenn Sie sich eine Definition des Stammdatenmanagements ansehen, ist der Kern dessen Deduplizierung. Sie können Entitäten über verschiedene Datenquellen hinweg identifizieren und dann einen Stammsatz für diese Entität erstellen. Und diese Entität könnte eine Person sein. Die Entität könnte zum Beispiel ein Teil eines Flugzeugs sein. Die Entität könnte ein Lebensmittel sein, wie wir es für einen unserer Health Club-Kunden getan haben. Für sie haben wir eine Master-Food-Datenbank erstellt. Also, mit welchen Entitäten wir auch arbeiten - und natürlich gibt es zunehmend Menschen und deren Stellvertreter, die Dinge wie soziale Handles oder Konten sind, welche Geräte auch immer mit Menschen verbunden sind, manche Dinge wie Autos und Telefone und was auch immer Sie sich vorstellen können.


Wissen Sie, wir arbeiten mit einem Kunden zusammen, der alle möglichen Sensoren für Sportbekleidung verwendet. Die Daten kommen also aus jeder Richtung. Und auf die eine oder andere Weise ist es eine Reflektion oder Repräsentation der Kerneinheit. Und in zunehmendem Maße geht es um Personen und die Fähigkeit, die Beziehungen zwischen all diesen Datenquellen und deren Beziehung zu dieser Kernentität zu identifizieren und diese Kernentität dann über einen längeren Zeitraum hinweg zu verfolgen, sodass Sie die Änderungen zwischen dieser Entität analysieren und nachvollziehen können und all diese anderen Elemente, die in diesen Darstellungen dieser Entität enthalten sind, sind beispielsweise für die Langzeit- und Längsschnittanalyse von Menschen von entscheidender Bedeutung. Und das ist wirklich einer der wirklich wichtigen Vorteile, die Big Data uns meines Erachtens auf lange Sicht ein viel besseres Verständnis der Menschen verschaffen kann, und das Verständnis des Betrugs und des Verhaltens der Menschen, wenn sie sich über welche Geräte usw. verhalten .


Also, lassen Sie mich hier schnell durchgehen. Eric erwähnte YARN. Weißt du, ich werfe das nur für eine kleine Sekunde ein, denn während YARN - die Leute über YARN reden. Ich denke, es gibt immer noch viel Unwissenheit über YARN. Und nicht viele Leute wirklich - es gibt immer noch viele Missverständnisse über YARN. Tatsache ist, dass Sie YARN nutzen können, um Hadoop als Ihre Skalierungsplattform zu verwenden, wenn Ihre Anwendung auf die richtige Art und Weise aufgebaut wurde und Sie die richtige Ebene oder Parallelisierung in Ihrer Anwendungsarchitektur haben. Genau das haben wir getan.


Sie wollen noch einmal auf einige der Definitionen rund um YARN hinweisen. Für uns hat das, was YARN wirklich ist, es uns und anderen Organisationen ermöglicht, Peers zu MapReduce und Spark und all den anderen Tools zu werden, die es gibt. Fakt ist jedoch, dass unsere Anwendungen optimierten Code direkt in YARN in Hadoop treiben. Und es gibt einen wirklich interessanten Kommentar, den Mike erwähnt hat, weil die Frage zu Analytics und unseren Analytics, nur weil sie im Cluster sind, wirklich parallel laufen. Sie können die gleiche Frage zu vielen Datenqualitäts-Tools stellen, die es gibt.


Die meisten Qualitätswerkzeuge müssen entweder die Daten herausholen oder sie müssen den Code einspielen. In vielen Fällen handelt es sich um einen einzelnen Datenstrom, der aufgrund der Art und Weise verarbeitet wird, wie Sie ihn benötigen Vergleichen Sie Datensätze, manchmal in Datenqualität Art von Aktivitäten. Tatsache ist, dass wir durch die Verwendung von YARN die Parallelisierung wirklich nutzen konnten.


Und nur um Ihnen einen schnellen Überblick zu geben, denn es wird ein weiterer Kommentar dazu abgegeben, wie wichtig es ist, traditionelle Datenbanken, neue Datenbanken usw., die wir implementieren oder außerhalb des Clusters installieren, erweitern zu können. Und wir übertragen unsere Binärdateien direkt in den Ressourcenmanager YARN. Und das, und dann verteilt YARN es über die Knoten im Cluster. Und was das bedeutet, ist, dass YARN - wir erlauben YARN, seine Arbeit zu verwalten und zu erledigen, dh herauszufinden, wo sich die Daten befinden, und die Arbeit zu den Daten zu führen, den Code zu den Daten und die Daten nicht zu verschieben. Wenn Sie Datenqualitäts-Tools hören, die Ihnen die beste Vorgehensweise bieten, ist es, die Daten aus Hadoop zu entfernen und um Ihr Leben zu rennen, da dies einfach nicht der Fall ist. Sie möchten die Arbeit auf die Daten übertragen. Und genau das macht YARN zuerst. Es führt unsere Binärdateien zu den Knoten, auf denen sich die Daten befinden.


Und da wir nicht zum Cluster gehören, können wir auch auf alle traditionellen und relationalen Datenbanken zugreifen, sodass Jobs, die zu 100% Client-Server sind, auf einer traditionellen Datenbank, 100% Hadoop- oder Hybrid-Jobs, die über den Hadoop-Client-Server laufen, ausgeführt werden können , Oracle, Teradata - was auch immer Sie wollen und alles im selben Job, weil diese eine Implementierung auf beide Seiten der Welt zugreifen kann.


Und dann, wenn wir auf die ganze Idee der Entstehungsgeschichte der Werkzeuge zurückkommen, sehen Sie hier, dass dies nur eine einfache Darstellung ist. Und wir versuchen, die Welt zu vereinfachen. Das erreichen wir, indem wir HDFS mit einer breiten Palette von Funktionen ausstatten… und dies nicht, weil wir versuchen, alle innovativen Technologien zu eliminieren. Unternehmen brauchen nur Stabilität und sie mögen keine codebasierten Lösungen. Daher möchten wir Unternehmen eine vertraute, wiederholbare und konsistente Anwendungsumgebung bieten, mit der sie Daten auf sehr vorhersehbare Weise erstellen und verarbeiten können.


Schnell ist dies die Art von Auswirkung, die wir mit unserer Anwendung erhalten. Sie sehen MapReduce vs. Pig vs. RedPoint - keine Codezeilen in RedPoint. Sechs Stunden Entwicklungszeit bei MapReduce, drei Stunden Entwicklungszeit bei Pig und 15 Minuten Entwicklungszeit bei RedPoint. Und hier haben wir wirklich einen enormen Einfluss. Die Bearbeitungszeit ist auch schneller, aber die Personalzeit, die Personalproduktivitätszeit, ist signifikant erhöht.


Und meine letzte Folie hier, ich möchte auf diese Idee zurückkommen, da wir es uns zur Aufgabe gemacht haben, einen Datensee, einen Datenhub oder eine Datenraffinerie als zentralen Punkt für die Aufnahme zu verwenden. Kann dieser Idee nicht mehr zustimmen. Derzeit führen wir Gespräche mit zahlreichen Chief Data Officers der wichtigsten globalen Banken. Dies ist die Architektur der Wahl.Die Datenerfassung aus allen Quellen übernimmt die Datenqualitätsverarbeitung und das Stammdatenmanagement innerhalb des Datensees. Anschließend werden die Daten dorthin übertragen, wo sie zur Unterstützung von Anwendungen und zur Unterstützung von BI benötigt werden. Und wenn Sie über Analysen in BI verfügen, können diese direkt im Data Lake ausgeführt werden. Umso besser, dass sie sofort gestartet werden können. Aber sehr an Bord mit dieser Idee. Bei dieser Topologie handelt es sich um eine Topologie, bei der wir feststellen, dass sie auf dem Markt viel Anklang findet. Und das ist es.


Eric: Okay, gut. Gehen wir gleich hier weiter. Ich werde es Keith geben. Und, Keith, du hast ungefähr 10, 12 Minuten Zeit, um das Haus hier zu rocken. Wir haben in diesen Shows ein bisschen länger gebraucht. Und dafür haben wir 70 Minuten geworben. Klicken Sie einfach irgendwo auf diese Folie und verwenden Sie den Abwärtspfeil, um sie zu entfernen.


Keith: Sicher. Kein Problem, Eric. Ich schätze es. Ich werde nur ein paar Themen zu SAS behandeln und mich dann mit Technologiearchitekturen befassen, bei denen SAS mit der Big-Data-Welt in Konflikt gerät. In all diesen Dingen gibt es viel zu erklären. Wir könnten Stunden damit verbringen, sie detailliert durchzuarbeiten, aber zehn Minuten - Sie sollten in der Lage sein, nur einen kurzen Überblick darüber zu erhalten, wo SAS Analytics-, Datenmanagement- und Business Intelligence-Technologien in diese Big-Data-Welt gebracht hat.


Zunächst ein wenig über SAS. Wenn Sie mit dieser Organisation nicht vertraut sind, führen wir seit 38 Jahren fortschrittliche Analysen, Business Intelligence und Datenmanagement nicht nur mit großen Datenmengen, sondern auch mit kleinen Datenmengen und Datenmengen durch. Wir haben einen riesigen Kundenstamm, rund 75.000 Standorte auf der ganzen Welt, und arbeiten mit einigen der führenden Organisationen zusammen. Wir sind eine private Organisation mit ca. 13.000 Mitarbeitern und einem Umsatz von 3 Milliarden US-Dollar. Und das Wichtigste ist, dass wir traditionell seit langem einen erheblichen Teil unseres Umsatzes in unsere F & E-Organisation reinvestieren. Dies hat wirklich dazu geführt, dass viele dieser erstaunlichen Technologien und Plattformen, die Sie nutzen, zum Tragen gekommen sind. ' Wir werden heute sehen.


Also werde ich direkt in diese wirklich beängstigenden Architekturdiagramme springen. Wir werden in meinen Folien von links nach rechts arbeiten. Es gibt also vertraute Dinge, die Sie in dieser Plattform sehen werden. Auf der linken Seite alle Datenquellen, von denen wir sprechen, die in diese Big-Data-Plattformen aufgenommen werden. Und dann haben Sie diese Big-Data-Plattform.


Ich habe dort nicht nur das Wort Hadoop an die erste Stelle gesetzt, denn letztendlich geht es bei den Beispielen, die ich heute geben werde, speziell um alle Technologien, mit denen wir diese Big-Data-Plattformen verbinden. Hadoop ist zufällig eine der Lösungen, bei denen wir einige der robustesten Bereitstellungsoptionen haben, aber wir überschneiden uns auch ziemlich und haben eine Menge dieser Technologien für einige Zeit mit einigen unserer anderen Enterprise Data Warehouse-Partner wie Teradata entwickelt. Oracle, Pivotal und dergleichen. Daher kann ich nicht im Detail darlegen, welche Technologien auf welcher Plattform unterstützt werden, aber ich kann Ihnen nur versichern, dass alle, die ich heute beschreibe, größtenteils nur Hadoop sind und eine große Anzahl von ihnen sich mit anderen Technologiepartnern überschneidet wir haben. So groß ist die Plattform, die dort sitzt.


Im nächsten rechts haben wir unseren SAS LASR Analytic Server. Im Wesentlichen handelt es sich hierbei um einen massiv parallelen Speicheranalyseanwendungsserver. Wir sind uns sicher, dass es sich nicht um eine In-Memory-Datenbank handelt. Es wurde von Grund auf neu entwickelt. Es handelt sich nicht um die Abfrage-Engine, sondern um eine massiv parallele Bearbeitung von Analyseanfragen. Das sind also die Dienstschlüsselanwendungen, die Sie dort auf der rechten Seite sehen.


Wir werden uns ein wenig damit befassen, wie die Leute diese Dinge einsetzen. Aber im Wesentlichen ist die Anwendung - sehen Sie dort - die erste unsere SAS-Hochleistungsanalyse. Das wird so sein - ich verwende viele unserer vorhandenen Technologien und Plattformen wie Enterprise Miner oder nur eine SAS und mache nicht nur Multithreading mit einigen der Algorithmen, die wir in die Tools eingebaut haben, für die wir gearbeitet haben Jahre, sondern auch massiv parallel zu diesen. Um die Daten von dieser Big-Data-Plattform in den Speicherbereich auf diesen LASR Analytic Server zu verschieben, damit wir analytische Algorithmen ausführen können - Sie wissen, eine Menge des neuen maschinellen Lernens, neuronale Netze, zufällige Waldregressionen, solche Dinge - wieder sitzen die Daten im Speicher. Wenn Sie also diesen bestimmten MapReduce-Paradigmenengpass beseitigen, bei dem wir ihn auf diese Plattformen übertragen, ist dies nicht die Art und Weise, wie Sie analytische Arbeiten ausführen möchten. Wir möchten also in der Lage sein, die Daten einmal in den Speicherbereich zu heben und sie zu durchlaufen, wissen Sie, manchmal tausende Male. Das ist also das Konzept der Verwendung dieses leistungsstarken analytischen LASR-Servers.


Wir auch - die anderen Anwendungen darunter, die visuelle Analyse, die es uns ermöglicht, diese Daten im Speicher zu speichern und eine größere Population mit denselben Daten zu versorgen. So können Menschen Big Data erkunden. Bevor wir unsere Modellentwicklungsarbeiten durchführen, untersuchen wir Daten, lernen sie kennen, führen Korrelationen durch, prognostizieren oder zeichnen Entscheidungsbäume auf - diese Art von Dingen - aber auf sehr visuelle, interaktive Weise für Daten, die sich im Speicher befinden Plattform. Dies kommt auch unserer BI-Community zugute, da es eine sehr breite Anwenderbasis gibt, die diese Plattform für Standardaufzeichnungen nutzen kann.


Im nächsten Schritt ziehen wir dann in Dienst. Und unseren Statistikern und Analytikern zu helfen, diese Art von Ad-hoc-Modellierung mit im Speicher abgelegten Daten durchzuführen, die aus der visuellen Analyse und Erkundung in unserer Anwendung für visuelle Statistiken entfernt wurden. Dies ist eine Gelegenheit für die Benutzer, Statistiken nicht in Stapeln auszuführen, durch die sie früher iteriert haben, sondern die Modelle auszuführen und die Ergebnisse anzuzeigen. So kann das Modell ausgeführt werden, um die Ergebnisse zu sehen. Dies geschieht durch visuelles Ziehen und Ablegen in die interaktive statistische Modellierung. Auf diese Weise können unsere Statistiker und Datenwissenschaftler einen Großteil dieser frühen visuellen Erkundungsstatistikarbeiten durchführen.


Und dann haben wir unsere Codierer nicht vergessen - die Leute, die wirklich wollen, in der Lage sind, die gegenüberliegenden Schnittstellenebenen zu schälen, müssen Anwendungen schreiben und ihre eigene Codebasis in SAS schreiben. Und das sind unsere In-Memory-Statistiken für Hadoop. Und dies ist im Wesentlichen die Codeschicht, die es uns ermöglicht hat, mit diesem Analytic LASR-Server zu interagieren, um Befehle direkt auszugeben und diese Anwendungen basierend auf unserer Anfrage anzupassen. Das ist das analytische Stück.


Wie diese Dinge aufgebaut werden ... Ups, es tut mir leid Jungs. Na, bitte.


Es gibt also wirklich verschiedene Möglichkeiten, wie wir dies tun. Zum einen mit Big Data - in diesem Fall mit Hadoop. Und hier haben wir den SAS LASR Analytic Server, der in einem separaten Cluster von Computern ausgeführt wird, die für Hardcore-Analysen optimiert sind. Dies ist nett und nah an der Big-Data-Plattform eingebettet, sodass wir sie getrennt von der Big-Data-Plattform skalieren können. Wir sehen also, dass Leute dies tun, wenn sie nicht möchten, was ich als Vampir-Software bezeichne, die sich an jedem der Knoten in ihrem Hadoop-Cluster verzehrt. Und sie skalieren nicht unbedingt die Big-Data-Plattform, die für In-Memory-Analysen mit hohem Aufwand geeignet ist. Sie haben also möglicherweise 120 Knoten ihres Hadoop-Clusters, aber möglicherweise 16 Knoten von Analyseservern, die für diese Art von Arbeit ausgelegt sind.


Wir dürfen diese Parallelität von der Big-Data-Plattform beibehalten, um die Daten in den Speicher zu ziehen. Es ist also wirklich eine Verwendung von SAS mit der Hadoop-Plattform. Ein anderes Terminmodell ist, dass wir auch diese Commodity-Plattform verwenden und diese weiterentwickeln können - im Wesentlichen den Analytic LASR-Server auf den Hadoop-Plattformen ausführen. Hier sind wir also… Sie arbeiten auf der Big-Data-Plattform. Dies sind auch einige unserer anderen Gerätehersteller. Auf diese Weise konnten wir diese Warenplattform im Wesentlichen für diese Arbeit verwenden.


Wir sehen das öfter bei Dingen wie Hochleistungsanalysen, bei denen es sich um einen Single-Serving- oder Single-Use-Analyselauf handelt, bei denen es sich eher um eine chargenorientierte Analyse handelt - Sie möchten nicht unbedingt den Speicherplatz bei Hadoop belegen Plattform. Wir sind bei dieser Art von Bereitstellungsmodell sehr flexibel, insbesondere bei der Zusammenarbeit mit YARN in vielen dieser Fälle, um sicherzustellen, dass wir nette Cluster spielen.


Okay, das ist also die analytische Welt, um mit der analytischen Anwendung klar zu werden. Ich erwähnte jedoch, dass SAS am Anfang auch eine Datenverwaltungsplattform ist. Und es gibt Dinge, die angemessen sind, um die Logik gegebenenfalls auf diese Plattform zu übertragen. Es gibt also verschiedene Möglichkeiten, wie wir das tun. Zum einen ist es in der Welt der Datenintegration möglicherweise nicht sinnvoll, Daten bei der Datenumwandlung wieder herauszuholen, wie wir bereits gehört haben. Wir möchten auf jeden Fall Datenqualitätsroutinen auf diese Plattform übertragen. Und dann Dinge wie Model Scoring. Also habe ich mein Modell entwickelt. Ich möchte das Ding nicht in MapReduce umschreiben und es für mich schwierig und zeitaufwendig machen, diese Arbeit auf der nativen Datenbankplattform wiederherzustellen.


Wenn Sie sich zum Beispiel unseren Scoring Accelerator für Hadoop ansehen, können wir im Wesentlichen ein Modell nehmen und die mathematische SAS-Logik auf diese Hadoop-Plattform übertragen und dort ausführen, wobei wir die Parallelität dieser Big-Data-Plattform verwenden. Wir haben dann unseren Codebeschleuniger für verschiedene Plattformen, einschließlich Hadoop, der es uns ermöglicht, SAS-Datenschrittcode auf der Plattform im Wesentlichen parallel auszuführen - und so Datentransformationsarbeiten auf der Plattform auszuführen. Und dann unser SAS-Datenqualitätsbeschleuniger, der es uns ermöglicht, eine hochwertige Wissensbasis zu haben, die Dinge wie Gender Matching und Standardisierungs-Match-Code ausführen kann - all die verschiedenen Datenqualitäts-Dinge, die Sie bereits heute gehört haben.


Und als letztes gibt es noch den Data Loader. Wir wissen, dass unsere Geschäftsanwender in der Lage sein müssen, auf diesen Big-Data-Plattformen keinen Code schreiben und Daten umwandeln zu müssen. Data Loader ist eine nette WYSIWYG-GUI, mit der wir diese anderen Technologien zusammenfassen können. Es ist wie ein Durchgangsassistent, der beispielsweise eine Hive-Abfrage oder eine Datenqualitätsroutine ausführt und in diesem Fall keinen Code schreiben muss.


Das Letzte, was ich erwähne, ist dieses Vorderteil. Wir haben - wie ich bereits erwähnte - einen riesigen SAS-Fuß da draußen auf der Welt. Und das bedeutet, dass wir nicht unbedingt alle Plattformen, die es gibt, sofort in diesem Bereich einsetzen können. Es gibt also definitiv viele Benutzer, die auf diesen Big-Data-Plattformen Daten abrufen müssen, z. B. Teradata-Daten abrufen und in Hadoop zurückspeichern und umgekehrt. Ausführen der Modelle Ich kann bereits auf meinen SAS-Servern ausgeführt werden, benötige jedoch Daten, die jetzt auf der Hadoop-Plattform gespeichert werden. Da ist also dieses andere kleine Symbol mit dem Namen "from", mit dem wir uns über unsere SAS-Zugriffsmodule verbinden können - Zugriffsmodule nach Hadoop nach Cloudera in Pola, nach Teradata, nach Greenplum nach ... Und die Liste geht weiter. Auf diese Weise können wir unsere bereits vorhandenen ausgereiften SAS-Plattformen nutzen, um Daten von diesen Plattformen abzurufen, die erforderlichen Arbeiten auszuführen und die Ergebnisse in diese Bereiche zurückzuführen.


Das Letzte, was ich erwähnen möchte, ist, dass all diese Technologien, die Sie sehen, von denselben gemeinsamen Standardmetadaten gesteuert werden. Wir sprechen also davon, die Transformationsarbeit, die Datenqualitätsregel bei der Arbeit, in den Speicher zu verschieben, um Analysen durchführen zu können, und die Modellentwicklung beim Scoring. Wir haben den gesamten analytischen Lebensstil hinter uns, wobei der Lebenszyklus von gemeinsamen Metadaten, von Governance, von Sicherheit und von all den Dingen bestimmt wird, über die wir heute bereits gesprochen haben.


Also, nur eine Zusammenfassung, es gibt wirklich diese drei großen Dinge, die man mitnehmen muss. Zum einen können wir die Datenplattform wie jede andere Datenquelle behandeln, indem wir sie auslesen und an sie weiterleiten, wenn dies angemessen und bequem ist. Wir können mit diesen Big-Data-Plattformen arbeiten und die Daten in einer speziell entwickelten Plattform für erweiterte Analysen im Speicher auflisten. Das ist also der LASR-Server.


Und schließlich können wir direkt auf diesen Big-Data-Plattformen arbeiten und deren verteilte Verarbeitungsfunktionen nutzen, ohne die Daten zu verschieben.


Eric: Nun, das ist fantastisches Zeug, Leute. Ja, das ist großartig! Kommen wir also gleich zu einigen Fragen. Bei diesen Ereignissen gehen wir in der Regel etwa 70 Minuten oder ein bisschen länger. Ich sehe, wir haben immer noch ein tolles Publikum da draußen. George, ich schätze, ich werfe dir unsere erste Frage zu. Wenn Sie über das Pushen Ihres Binärsounds in Hadoop sprechen, scheint mir das, als hätten Sie den Rechenworkflow wirklich optimiert. Und das ist der ganze Schlüssel, um diese Art von Daten-Governance in Echtzeit und Errungenschaften im Stil der Datenqualität zu erzielen, denn das ist der Wert, den Sie erreichen möchten, oder? Wenn Sie nicht in die alte Welt von MDM zurückkehren möchten, in der es sehr umständlich und zeitaufwendig ist, und wenn Sie die Leute wirklich zu bestimmten Handlungen zwingen müssen, die so gut wie nie funktionieren. Sie haben also den Zyklus von dem, was war, verkürzt. Nennen wir es Tage, Wochen, manchmal sogar Monate bis zu Sekunden, oder? Ist es das, was los ist?


George: Das ist genau richtig, denn die Größe und Leistung eines Clusters ist wirklich erstaunlich, wenn man bedenkt, dass ich bei Benchmarks immer ein bisschen zögerlich bin. Aber nur für die Größenordnung, in der wir eine Milliarde, 1,2 Milliarden Datensätze ausführen und eine vollständige Adressstandardisierung durchführen würden - ich sage HP-Maschinen der Mittelklasse -, wären acht Prozessormaschinen erforderlich, wissen Sie , 2 GB RAM pro Core, wissen Sie, das würde 20 Stunden dauern. Wir können das in ungefähr acht Minuten auf einem 12-Knoten-Cluster tun. Daher ist der Umfang der Verarbeitung, die wir jetzt durchführen können, so dramatisch unterschiedlich - und das passt sehr gut zu der Vorstellung, dass Sie alle diese Daten zur Verfügung haben. Es ist also nicht so riskant, die Verarbeitung durchzuführen. Wenn Sie es falsch gemacht haben, können Sie es wiederholen. Du hast Zeit, weißt du? Es hat das Ausmaß geändert, in dem diese Art von Risiken zu echten geschäftlichen Problemen für Menschen wurden, die versuchten, MDM-Lösungen zu betreiben. Sie müssen 30 Offshore-Mitarbeiter für die Datenverwaltung und alles haben. Und so müssen Sie noch einiges davon haben, aber die Geschwindigkeit und der Umfang, in dem Sie es jetzt verarbeiten können, geben Ihnen wirklich viel mehr Freiraum zum Atmen.


Eric: Ja, das ist ein wirklich sehr guter Punkt. Ich liebe diesen Kommentar. Sie haben also die Zeit, es erneut zu wiederholen. Das ist fantastisch.


George: Ja.


Eric: Nun, es verändert die Dynamik, oder? Es ändert sich, wie Sie über das nachdenken, was Sie versuchen werden. Ich meine, ich erinnere mich, dass ich vor 18 Jahren in der Branche Spezialeffekte gemacht habe, weil ich einen Kunden hatte, der in diesem Bereich tätig war. Und du würdest die Knöpfe drücken, um es zu rendern, und du würdest nach Hause gehen. Und Sie würden vielleicht am Samstagnachmittag zurückkommen, um zu sehen, wie es lief. Aber wenn Sie sich geirrt haben, war das sehr, sehr, sehr schmerzhaft. Und jetzt ist es nicht annähernd so weit - es ist nicht annähernd so schmerzhaft, dass Sie die Möglichkeit haben, mehr zu probieren. Ich muss sagen, ich denke, das ist ein wirklich sehr guter Punkt.


George: Das ist genau richtig. Ja, und du bläst dein Extrabein. Weißt du, du hast in den alten Zeiten die Hälfte eines Jobs hinter dir und es schlägt fehl, du hast dein SOS durchgebrannt. Das ist es.


Eric: Richtig. Und du hast große Probleme, ja. Stimmt.


George: Das stimmt. Stimmt.


Eric: Keith, lass mich dir einen rüberwerfen. Ich erinnere mich an ein Interview mit Ihrem CIL, Keith Collins, ich glaube, damals, glaube ich, 2011 vielleicht. Und er sprach viel über die Richtung, die SAS speziell in Bezug auf die Zusammenarbeit mit Kunden eingeschlagen hat, um die von SAS abgeleiteten Analysen in betriebliche Systeme einzubetten. Und natürlich haben wir Mike Ferguson über die Wichtigkeit des Erinnerns sprechen hören. Die ganze Idee hier ist, dass Sie dieses Zeug in Ihre Operationen einbinden können möchten. Sie möchten keine Analyse in einem Vakuum durchführen, das nicht mit dem Unternehmen verbunden ist. Das ist überhaupt kein Wert.


Wenn Sie Analysen wünschen, die sich direkt auf die Abläufe auswirken und diese optimieren können. Und wenn ich zurückblicke - und ich muss sagen, dass ich es damals für eine gute Idee hielt -, scheint es im Nachhinein eine wirklich, wirklich kluge Idee zu sein. Und ich vermute, das ist ein echter Vorteil, den ihr habt. Und natürlich, dieses großartige Erbe, diese riesige Installationsbasis und die Tatsache, dass Sie sich darauf konzentriert haben, diese Analysen in betriebliche Systeme einzubetten. Ich habe ziemlich hart daran gearbeitet. Aber jetzt können Sie all diese neuen Innovationen nutzen und sind wirklich in der Lage, all diese Dinge mit Ihren Kunden zu operationalisieren. Ist das eine faire Einschätzung?


Keith: Ja, absolut. Das Konzept ist, dass Sie diese Vorstellung von Entscheidungsdesign oder Entscheidungswissenschaften haben, die, wie Sie wissen, zu einem gewissen Grad explorativ und wissenschaftlich sind. Es sei denn, Sie können den Prozess so weit entwickeln, dass wirklich ... Wenn Sie über die Entwicklung eines Autos nachdenken, haben Sie Designer, die dieses schöne Auto herstellen, aber erst, wenn die Ingenieure diesen Plan in die Tat umsetzen und vor Ihnen ein realisierbares Produkt herstellen können tatsächlich Dinge in Position bringen, und das ist im Wesentlichen, was SAS getan hat. Es hat den Entscheidungsentwurfsprozess mit dem Entscheidungsentwurfsprozess zusammengeführt, sodass Sie, wenn Sie über die Beschleuniger, die Scoring-Beschleuniger, sprechen, genau wissen, ob Sie ein von Ihnen entwickeltes Modell nehmen und es herausdrücken können an Teradata oder an Oracle oder an Hadoop, ohne Ausfallzeit für die Modellentwicklung und für die Modellbereitstellung. Dies ist der Schlüssel, da Modelle mit der Zeit die Genauigkeit dieser Modelle beeinträchtigen. Je länger Sie brauchen, um das Produkt in Produktion zu bringen, desto geringer ist die Genauigkeit des Modells.


Das andere ist, dass Sie diesen Prozess im Laufe der Zeit überwachen und verwalten möchten. Sie möchten Modelle ablehnen, wenn sie alt und ungenau sind. Sie möchten es sich ansehen, die Genauigkeit im Laufe der Zeit überprüfen und sie neu erstellen. Und so haben wir Modellverwaltungstools, die auch darüber hinausgehen und die Metadaten rund um den modellierten Prozess wirklich nachverfolgen. Und die Leute haben gesagt, das Modellieren ist wie eine Modellfabrik oder wie auch immer man es nennen will. Die Sache ist, dass Metadaten und Management in den Prozess einbezogen werden, und hier treffen wir die drei großen Dinge: Wir helfen Menschen, Geld zu verdienen, Geld zu sparen und sie aus dem Gefängnis herauszuhalten.


Eric: Der letzte ist auch ziemlich groß. Ich versuche das alles zu vermeiden. Reden wir also über ...Ich gebe noch eine letzte Frage, vielleicht können Sie beide darauf zugreifen. Die Heterogenität unserer Welt wird meiner Meinung nach nur zunehmen. Ich denke, wir werden definitiv eine gewisse Kristallisation in hybriden Cloud-Umgebungen sehen. Trotzdem werden viele der wichtigsten Akteure hier bleiben. IBM geht nirgendwo hin. Oracle geht nirgendwo hin. SAP geht nirgendwo hin. Und es gibt so viele andere Anbieter, die an diesem Spiel beteiligt sind.


Auf der operativen Seite gibt es buchstäblich Tausende und Abertausende verschiedener Arten von Anwendungen. Und ich habe gehört - die meisten von Ihnen sprechen darüber, aber ich denke, Sie würden beide dem zustimmen, was ich gesagt habe. Wir haben diesen Trend jetzt nur in Bezug auf die Rechenleistung in analytischen Engines und der Architektur gesehen. Unternehmen sprechen seit Jahren davon, dass sie die anderen Engines da draußen nutzen und eine Art Orchestrierungspunkt warten können. Und ich denke, George, ich werfe es zuerst zu dir. Mir scheint, das wird sich nicht ändern. Wir werden diese heterogene Umgebung haben, was bedeutet, dass es Dinge wie Echtzeit-CRM, Datenqualität und Daten-Governance gibt. Als Anbieter müssen Sie mit all diesen verschiedenen Tools kommunizieren. Und das wollen die Kunden. Sie werden nicht wollen, dass etwas mit diesen Werkzeugen gut läuft und mit diesen Werkzeugen nicht so gut. Sie wollen die Schweiz von MDM und CRM, oder?


George: Das stimmt. Und es ist interessant, weil wir das sehr begrüßt haben. Ein Teil davon ist die Geschichte, die wir im Weltraum hatten. Und offensichtlich arbeiteten wir bereits an allen anderen Datenbanken, den Teradaten und den Stücken der Welt. Und dann haben Sie die - im Implementierungsprozess genau so, wie wir es gemacht haben - Spanne über all diese verschiedenen Datenbanken hinweg. Eines der Dinge, die ich interessant finde, ist, dass wir einige Clients haben, die nur darauf aus sind, alle relationalen Datenbanken zu entfernen. Und das ist interessant. Weißt du, ich meine, es ist in Ordnung. Es ist interessant. Aber ich sehe es nicht wirklich in großem Umfang. Ich sehe es schon lange nicht mehr. Ich denke also, Hybrid ist schon lange hier und auf der anderen Seite unserer Anwendung haben wir unsere Messaging-Plattform in unserer Kampagnenmanagement-Plattform. Wir haben es tatsächlich speziell entworfen. Jetzt haben wir eine Version veröffentlicht, die dies ermöglicht und jetzt eine Verbindung mit der Hybriddatenumgebung herstellt und Hadoop abfragt oder jede Datenbank abfragt, jede Analysedatenbank. Ich denke, das ist nur die Welle der Zukunft. Ich bin damit einverstanden, dass die Virtualisierung sicherlich eine große Rolle spielen wird, aber wir tun es einfach - wir greifen direkt auf die Daten aller unserer Anwendungen zu.


Eric: Okay, großartig. Und, Keith, ich werfe es zu dir rüber. Was denkst du über die heterogene Welt, in der wir als eine Art Fuß auftreten?


Keith: Ja, es ist wirklich faszinierend. Ich denke, was wir mehr finden - nicht nur im Datenmanagement -, sondern was im Moment wirklich fasziniert, ist die Open-Source-Natur der Analytics-Basis. Wir sehen also Organisationen wie oder Technologien wie Spark, und Leute, die Python und R und all diese anderen Open-Source-Technologien verwenden. Ich denke, es könnte bis zu einem gewissen Grad als eine Art Konflikt oder Bedrohung interpretiert werden. In Wirklichkeit haben wir einige wirklich wunderbare Komplimente mit all diesen Open-Source-Technologien. Ich meine, zum einen arbeiten wir auf Open-Source-Plattformen, um Gottes willen.


Aber auch wenn Sie beispielsweise ein R-Modell in ein SAS-Paradigma integrieren können, können Sie das Beste aus beiden Welten nutzen, oder? Wir wissen also, dass einige der experimentellen Dinge in der akademischen Welt und einige der Modellentwicklungsarbeiten außergewöhnlich und im Modellentwicklungsprozess sehr hilfreich sind. Aber auch, wenn Sie das mit einem Werkzeug der Produktionsklasse kombinieren könnten, würde es einen großen Teil der Bereinigung und Qualität übernehmen und prüfen und sicherstellen, dass die Daten, die in das Modell eingegeben werden, korrekt aufbereitet wurden, damit es nicht versagt bei der Ausführung. Und dann in der Lage zu sein, Dinge wie Champion-Herausforderermodelle mit Open-Source-Modellen zu machen. Dies sind die Dinge, die wir ermöglichen wollen und die Teil dieses wirklich heterogenen Ökosystems all dieser Technologien sind. Ja, es geht mehr - für uns geht es mehr darum, diese Technologien zu nutzen und nach Komplimenten zu suchen.


Eric: Nun, das war fantastisch, Leute. Wir sind hier ein bisschen lang gegangen, möchten aber so viele Fragen wie möglich beantworten. Wir werden die Q & A-Datei heute an unsere Moderatoren weiterleiten. Wenn eine von Ihnen gestellte Frage nicht beantwortet wurde, stellen wir sicher, dass sie beantwortet wird. Und Leute, damit ist 2014 Schluss. Mit freundlichen Grüßen morgen und in der nächsten Woche beim DM-Radio. Dann ist alles erledigt und es ist eine Ferienpause.


Vielen Dank an euch alle für eure Zeit und Aufmerksamkeit, dass ihr all diese wundervollen Webcasts durchgespielt habt. Wir haben ein großartiges Jahr für 2015 vor uns. Und wir werden uns bald mit Ihnen unterhalten, Leute. Danke noch einmal. Wir werden aufpassen. Tschüss.