Eine eingebettet Softwareentwickler Flat File Migration Checkliste
Dies ist der letzte Teil meiner Blogreihe über die fortgesetzte Nutzung von Flatfiles und darüber, warum diese für den Einsatz in der Zukunft nicht mehr geeignet sind. Im ersten Teil ging es umFlatfiles und darum, warum Entwickler eingebettet diese bereitwillig übernommen haben. Im zweiten Teil habe ich dann erörtert,warum eingebettet zögern, Datenbanken zu nutzen. Im dritten Teil habe ich untersucht, warum Entwickler an Flatfile-Systemen festhalten.
Für diesen letzten Teil ist mir klar geworden, dass die Argumente für eine Abkehr von Flatfiles wahrscheinlich etwas konkreter formuliert werden müssen. Deshalb haben wir gemeinsam mit unserem Leiter der Entwicklungsabteilung, Desmond Tan, eine Liste von Gründen erstellt, bei denen es nicht darum geht, was Sie derzeit verwenden oder was Sie abstrakt gesehen verwenden sollten. Stattdessen konzentriert sie sich darauf, welche Ihrer tatsächlichen Anforderungen einen Wechsel weg von Flatfiles rechtfertigen würden. Diese Liste basiert auf den Anwendungsfällen, die sich unserer Einschätzung nach für eingebettet Datenmanagement den Bereichen Mobilgeräte, IoT und komplexe intelligente Geräte entwickeln. Sie spiegelt auch wider, was uns unsere Kunden in persönlichen Gesprächen über ihre Herausforderungen sowie ihre Geschäfts- und Produktanforderungen mitteilen.
Auf dieser Grundlage sind hier die acht wichtigsten Anforderungen an modernes Datenmanagement:
1. Lokale Datenspeicherung und ihre sich wandelnde Nutzung
Im Allgemeinen wurden lokal in Flatfiles gespeicherte Daten als Cache für sofortige Operationen mit Daten benötigt, die ausschließlich für das betreffende Gerät bestimmt waren. Zudem wurden diese Daten ohne eine seit Langem bestehende, aber kontinuierlich aktualisierte Referenzbasis ausgewertet. Die Notwendigkeit, Daten aus mehreren Geräten und Datenquellen zu kombinieren, sowie die Verwendung historischer Daten als Musterreferenzbasis für alles – vom einfachen Signal-Rausch-Verhältnis bis hin zu Maschinelles Lernen – bedeutet jedoch, dass der Bedarf an Datenmanagement komplexe Vorgänge, die die lokale Datenverarbeitung und -analyse versorgen, die rudimentären Funktionen von Dateisystemen übersteigt.
2. Unterstützung mehrerer Betriebssystemumgebungen mit einem einzigen Speicherformat
Über Produktdesigns, Portfolios für Betriebstechnologie und den IT-Support für Geschäftsbereiche hinweg müssen verschiedene Systeme am Netzwerkrand und im Unternehmensnetzwerk Daten über verschiedene Betriebssysteme hinweg austauschen – von Android/iOS über Windows/Linux bis hin zu Cloud Umgebungen. Ein einheitliches Speicherformat würde die Integrationszeit und -kosten erheblich reduzieren und zudem die Sicherheit verbessern.
3. Datenmanagement für alle an der Datenverarbeitung und -analyse beteiligten Rollen
Verschiedene Rollen müssen den Zugriff auf den Edge nutzen Datenmanagement -Plattform sowohl remote als auch lokal auf dieser Reihe von zugrunde liegenden Plattformen über verschiedene Zugriffsmechanismen nutzen, darunter CLI, Programmier- und Skriptsprachen. Es gibt wahrscheinlich eine dringend notwendige, ausführlichere Diskussion darüber, warum dies einen eigenen Blogbeitrag verdient.
4. Verarbeitung von Big Data Netzwerkrand
Kleiner Test: Was sind die vier „Vs“ bei Big Data – ja, ihr könnt sie alle nennen, selbst wenn ihr aus dem Tiefschlaf geweckt werdet (für diejenigen unter euch, die sich weigern, diesen wunderbaren Traum zu verlassen: Volume, Variety, Velocity und Value). So wie Hadoop auf Unternehmensebene ein erster Schritt war, um den Bedarf an einem gemeinsamen Speicher für Big Data zu decken, muss es auch am Edge ein Äquivalent geben. Und wie schon bei der letzten Anforderung wäre ein ganzer Blogbeitrag nötig, um die weitere Abgrenzung von Flatfiles zu erörtern. Vorerst lautet die wichtigste konkrete Erkenntnis: Man muss in der Lage sein, verschiedene Datentypen – darunter JSON, BLOB und traditionelle strukturierte Daten – in einer einzigen Datenbank zu unterstützen.
5. Datenaustausch zwischen OT-, Cloud klassischen IT-Umgebungen
Data sharing sowohl Szenarien von Gerät zu Gerät und von Gerät zu Gateway in OT-Umgebungen als auch von Edge zu Cloud Cloud Rechenzentrum für Remote- und Zweigstellenumgebungen an der Cloud zwischen Edge und Cloud unterstützen. Mit anderen Worten: Sie benötigen eine einzige Plattform für Client-, Peer-to-Peer-, Client-Server- sowie Internet-/Intranet-Architekturen.
6. Eigenständiger Betrieb bei Unterbrechungen der Internetverbindung
Auch wenn sich der Edge insgesamt in Richtung einer Hyperkonnektivität bewegt, sollte dies nicht fälschlicherweise so verstanden werden, dass die Notwendigkeit, Daten lokal zu verarbeiten und zu analysieren, damit entfällt oder abnimmt. In vielen Anwendungen der Betriebstechnik ist ein rein webbasierter Ansatz nicht praktikabel. Nehmen wir zum Beispiel autonome Fahrzeuge: Die Verarbeitung und Entscheidungsfindung auf der Grundlage von Video- und Lidar-Signalen, um zu bestimmen, wohin das Auto gelenkt werden soll, mit welcher Geschwindigkeit und Beschleunigung – oder Verzögerung – kann nicht von der Cloud übernommen werden; allein die Latenz würde Unfälle verursachen. In anderen Fällen können Komfort oder Benutzerfreundlichkeit der Grund dafür sein, dass Sie sich für eine lokale Abwicklung entscheiden. Angenommen, Sie haben Tausende von Alben lokal in Ihrer iTunes-Sammlung und möchten auf Ihrem vierzehnstündigen Flug von San Francisco nach Neu-Delhi nach einem Song anhand seines Textes suchen.
7. Verarbeitung von Hochgeschwindigkeits- und Mehrkanal-Datenerfassung
Viele der erfassten Kernsignale werden sich auch bei unserem Übergang zu einem stärker vernetzten und automatisierten Zustand nicht ändern; Druck, Volumen und Temperatur sind drei hervorragende Beispiele dafür. Wie oben bereits erwähnt, gewinnen jedoch Videostreams für alle möglichen Anwendungen – von der Gesichtserkennung bis hin zur industriellen Bildverarbeitung – zunehmend an Bedeutung und werden in weitaus höheren Auflösungen und Bildraten übertragen – man denke nur an 4K-UHD bei 120 Hz. Ebenfalls oben erwähnt wurden Lidar-Signale. Ich war einst Ingenieur und habe Laserradarsysteme gebaut. Selbst in den „dunklen Zeiten“ konnte ich problemlos 400 MB Daten pro Tag erfassen und innerhalb von Millisekunden Entscheidungen zu jedem erfassten Lidar-Signalsatz treffen. Ich könnte ein Beispiel nach dem anderen anführen. Der Punkt ist: Mit moderner Datenverarbeitung und -analyse am Netzwerkrand, bei der täglich mehrere Terabyte an Daten anfallen, die sowohl sofort verarbeitet als auch teilweise oder vollständig für eine spätere Weiterverarbeitung abgerufen werden – all diese Szenarien werden alltäglich sein.
8. Nutzung komplementärer Standardkomponenten des Ökosystems
Es versteht sich von selbst, dass diejenigen, die Flatfiles verwenden, wahrscheinlich auch in anderen Bereichen ihrer Lösungen eher auf Eigenleistungen setzen. Der Umstieg von Flatfiles wird die Produktivität optimieren, da er ihnen die Nutzung von Plug-and-Play-Lösungen für Advanced Analytics, Berichts- und Visualisierungstools sowie -plattformen ermöglicht.
Zusammenfassend lässt sich sagen: Wenn eine oder mehrere dieser Anforderungen auf Sie zutreffen, sollten Sie ernsthaft eine Umstellung von Flatfiles auf eine einheitliche, skalierbar und sichere Architektur in Betracht ziehen, die plattformübergreifende Deployment Entwicklung ermöglicht und Ihnen die nötige Leistungsfähigkeit bietet, um eine Vielzahl anspruchsvoller Analytics Use Cases Datenverarbeitung und Analytics Use Cases zu unterstützen. Flatfiles reichen einfach nicht mehr aus, mein Freund.
Bleiben Sie in Verbindung
Datenanalysen, die Ihnen geliefert werden.
(z. B. sales@..., support@...)
