"Wenn ich ein Wort benutze", sagte Humpty Dumpty in einem eher spöttischen Ton, "dann bedeutet es genau das, was ich damit sagen will - nicht mehr und nicht weniger.
Die Frage ist", sagte Alice, "ob man Wörter so viele verschiedene Bedeutungen geben kann."
- Through The Looking GlassLewis Caroll
"Big Data", wie die meisten Schlagworte, hat viele sich teilweise überschneidende Definitionen hervorgebracht. (In der Tat ist der Autor der Meinung, dass Sammlungen von Definitionen genau wie Kuhherden und Krähenmorde einen eigenen Sammelbegriff brauchen. Er schlägt respektvoll "Meinung", wie in "eine Meinung von Definitionen", als die natürliche Wahl vor.) In diesem Beitrag geht es nicht darum, eine weitere Definition von Big Data hinzuzufügen. Es geht darum, die operativen und architektonischen Auswirkungen der Bezeichnung von etwas als Big Data zu betrachten.
Nehmen Sie also die Definition(en) Ihrer Wahl und eine repräsentative Auswahl Ihrer Daten und überlegen Sie sich Folgendes:
- Ist jeder Teil meiner Daten lebenswichtig? Wäre ich verärgert, wenn ein kleiner, zufälliger Prozentsatz einfach abwandert und zu Nicht-Daten wird?
- Benötige ich die traditionellen Garantien, die relationale Datenbanken traditionell bieten? (z. B. ACID und die Starrheit und Spezifität der Verbindungen zwischen Daten).
- Lassen sich aus der Gesamtheit der Daten Erkenntnisse gewinnen, die bei der Analyse nur einer Teilmenge nicht möglich sind?
- Sind meine Daten unstrukturiert? Werden sie von IoT-Geräten generiert? Werden sie durch Benutzeraktivitäten in Anwendungen oder Webdiensten generiert?
Beachten Sie das Fehlen von Fragen zu Volumen, Geschwindigkeit oder Vielfalt der Datensätze. Dies sind wichtige Überlegungen, aber es ist auch nützlich, sich Big Data als Paradigma vorzustellen, bei dem Sie bestimmte Kompromisse akzeptieren, die Sie traditionell nicht eingehen würden; alternativ können Sie sich Big Data als Ökosystem vorstellen, in dem bestimmte Lösungsmuster verwendet werden.
Stellen Sie sich zum Beispiel vor, Sie würden Finanztransaktionen abwickeln. Ihre Antworten auf die in (1) und (2) gestellten Fragen wären "Ja", "Extrem" und "Ja". Dieser Teil Ihres Systems muss wahrscheinlich eine traditionelle relationale Datenbank sein. Und warum? Nun, Big-Data-Architekturen sind in der Regel tolerant gegenüber einem gewissen Datenverlust. Schließlich haben Sie eine Menge Daten.
Auch wenn dies für Finanztransaktionen absurd erscheint, sollte man nicht vergessen, dass die meisten Big-Data-Technologien von "Web 2.0"-Unternehmen entwickelt wurden, die damit Probleme lösen wollten, mit denen sie konfrontiert waren. MapReduce (und damit Hadoop) wurde von Google verwendet, um das Web zu indizieren. Kafka half LinkedIn bei der Verarbeitung von Protokolldaten. In beiden Fällen ist die gelegentlich verlorene Daten nicht von Bedeutung.
Wenn Sie hingegen die Fragen zu (3) und (4) mit Ja beantwortet haben, verfügen Sie wahrscheinlich über Daten, die am besten mit Big-Data-Technologien verarbeitet werden. Hier haben Sie so viele Daten, dass kein einzelnes Stück besonders wichtig ist, sondern das Aggregat - und die Fähigkeit, das Aggregat zu analysieren - schon. Was Sie brauchen, ist eine einfach zu bedienende Möglichkeit, mit diesen Daten zu arbeiten.
Die SnapLogic Elastic Integration Platform verarbeitet kleine Daten, mittlere Daten, Big Data, Cloud-Daten, Batch-Daten oder Streaming-Daten - Im Grunde genommen verarbeitet sie Daten, unabhängig von den Adjektiven, die Sie auf sie anwenden möchten. Sie müssen sich nicht auf eine Größe für alle Ihre Daten festlegen. Der Vorteil eines Data Lake besteht darin, dass jeder Teil Ihrer Infrastruktur die Lösung nutzen kann, die für die jeweilige Anwendung am besten geeignet ist, wobei alle Teile nahtlos miteinander verbunden werden können. Wir können mit Ihnen zusammenarbeiten, um eine Gesamtarchitektur einzurichten, die Ihren heutigen Anforderungen entspricht und die für die Anforderungen von morgen skalierbar ist.
