Zurück in die Zukunft für Flat Files - Teil 1
Warum Entwickler eingebettet auf Flatfiles umgestiegen sind
Vor kurzem hat mein Kollege hier im Produktmarketing bei Actian, Pradeep Bhanot, einen großartigen Blogbeitrag über Datenhistoriker verfasst, in dem er deren Ablösung durch modernere Datenbanken forderte, um die Verarbeitung und Analyse von Zeitreihendaten zu unterstützen. Doch in gewisser Weise sind Historien nicht so alt wie eine der am tiefsten verwurzelten eingebettet Datenmanagement : die Flatfile. Tatsächlich vermute ich, dass die Verwendung von Flatfiles als Mittel des eingebettet Datenmanagement weitaus verbreiteter ist als die von Datenbanken oder Historien. Das lässt sich schwer belegen, da Analysten dies nicht als separate Kategorie von Datenmanagement erfassen, wie sie es bei Datenbanken oder beispielsweise Cloud tun. Aber die Realität ist, dass es sie gibt; wir treffen sowohl bei unseren bestehenden Kunden als auch bei potenziellen Neukunden auf Anwender, die Flatfiles aktiv nutzen – und das nicht nur in ihren älteren Systemen.
Warum hat sich die Verwendung von Flatfiles überhaupt durchgesetzt?
Wenn Sie als Entwickler Code schreiben, um Daten aus der Betriebstechnik von Sensoren und anderen Edge-Systemen zu erfassen, verwenden Sie wahrscheinlich C, C++, C# oder eine andere Programmiersprache, die Ihnen direkten Zugriff auf die von den Geräten gelieferten Daten ermöglicht. Früher, als ich noch Ingenieur war, habe ich das zum Beispiel über inp()- und outp()-Anweisungen gemacht (oder, um mein Alter wirklich zu verraten, über eine Reihe von Registern, die in Assembler adressiert wurden – huch, ich glaube, ich bekomme gerade ein PTBS). Man merkt schnell, dass man einen Ort und eine Möglichkeit braucht, um die Daten dauerhafter zu speichern als in der temporären Speicherzuweisung innerhalb des Programms. Der Weg des geringsten Widerstands ist eine Datei. Schließlich ist das der einfachste Ansatz, und fast jeder, der einen Programmierkurs besucht oder sich das Programmieren selbst beibringt, kann das Dateisystem nutzen.
Flatfiles waren fürDatenmanagement traditionelle eingebettet Datenmanagement „gut genug“
Das oben Gesagte erklärt zwar, warum Sie die Möglichkeit zur Übernahme haben, geht aber nicht näher darauf ein, warum Flatfiles damals eine gute Lösung waren. Lassen Sie mich Ihnen einige wichtige Gründe nennen, warum sie gut genug waren:
1. Das „Silo of Things“ bedeutete, dass die gesamte Datenerfassung lokal erfolgte
Dateisysteme speichern Daten lokal, was füreingebettet meisteneingebettet am Netzwerkrand völlig ausreichte, da diese ausschließlich für den lokalen Gebrauch bestimmt waren. Es bestand kein Bedarf an zusätzlichen Daten aus parallelen Datenströmen, geschweige denn an der Zusammenführung mit anderen Datentypen und der gemeinsamen Nutzung über Netzwerke hinweg. Daher reichten eigenständige Dateisysteme ohne Netzwerkdatenübertragung völlig aus. Bedenken hinsichtlich Streaming oder des ETL-Prozesses (Extract, Transform, Load) in ein anderes System stellten kein wesentliches Hindernis dar.
2. Es gab nicht besonders viele Daten, Datenverarbeitung oder Analysen
Bis vor kurzem verfügte die meiste Betriebstechnik nur über sehr begrenzte Rechenressourcen: 32-Bit- oder 16-Bit-Mikrocontroller, weniger als 1 MB DRAM und begrenzter Flash- oder EPROM-Speicher usw. Falls Ihnen diese Begriffe nichts sagen: Stellen Sie sich das so vor, als wären es die Oldsmobile Ihres Vaters. Angesichts der begrenzten Ressourcen diente die meiste Software dazu, das Gerät im Rahmen eines bestimmten Prozesses direkt zu steuern, und die gesammelten Daten dienten hauptsächlich der Unterstützung dieses Prozesses, nicht der Instrumentierung des Prozesses oder der Analyse zur Optimierung des aktuellen oder zukünftigen Betriebs dieses Prozesses.
3. Es sind meine Daten, ich bin der Einzige, der sie nutzt, also lass mich in Ruhe
Softwareentwicklungsspezifikationen? Kommentare – wer braucht schon Kommentare? OT-Entwickler sind oft die einzigen, die die von ihnen entwickelte Software nutzen, und die durch ihren Code generierten Daten werden in der Regel nur von ihnen selbst sowie möglicherweise von einigen wenigen Experten in der Testvalidierung auf der einen Seite und im Service und Support auf der anderen Seite eingesehen. Da die Daten von ihnen und für sie generiert wurden, erschien es wiederum etwas weit hergeholt, diese Daten mit einem Business-Analysten oder Data-Scientist der Zentrale, geschweige denn Data-Scientist den Fachabteilungen, zu teilen. Traditionelle IT- und Cybersicherheitsfachleute im Rechenzentrum würden weder dazu aufgefordert werden noch das Bedürfnis verspüren, sich in diese Projekte einzubringen.
Das Erbe wertschätzen, aber den Blick auf die Zukunft richten
Ich verstehe das, ich war früher selbst einer dieser OT-Ingenieure, wie ich oben bereits angedeutet habe. Für Softwareentwickler hat der Einstieg mit Dateisystemen zwar einige Vorteile, doch angesichts der zunehmend vernetzten Welt der Edge-Geräte – auch bekannt als IoT –, der weitaus größeren Ressourcen (ich kann mir einen Raspberry Pi für weniger Geld als einen schicken echten Kuchen kaufen) und der Notwendigkeit, Daten auszutauschen, um die geschäftliche Agilität und Innovation voranzutreiben sowie OT reaktionsfähiger und kostengünstiger zu machen, ist ein Wandel erforderlich. Im nächsten Teil dieser Serie werden wir darüber sprechen, warum OT-Softwareentwickler sich so schwer tun, ihre flachen Dateisysteme aufzugeben und auf moderne Datenmanagement umzusteigen.
Actian ist der Branchenführer bei Datenmanagement operative Data Warehouses und Datenmanagement für moderne Unternehmen. Mit einem umfassenden Lösungsangebot, das Ihnen hilft, verwalten On-Premises, in der Cloud und am Netzwerkrand mithilfe von Mobilgeräten und IoT verwalten , unterstützt Actian Sie dabei, die technische Grundlage zu schaffen, die für echte geschäftliche Agilität erforderlich ist. Weitere Informationen finden Sie unter www.actian.com.
Bleiben Sie in Verbindung
Datenanalysen, die Ihnen geliefert werden.
(z. B. sales@..., support@...)
