Retour vers le futur pour les fichiers plats - Partie 1
Résumé
- Les développeurs d'applications Embarqué ont souvent recours aux fichiers plats, car ceux-ci sont extrêmement simples, très fiables et gratuits.
- Si les fichiers plats classiques conviennent parfaitement aux appareils isolés, ils peinent à prendre en charge de manière native les exigences avancées de l'IA moderne.
- À mesure que les écosystèmes de données prennent de l'ampleur, le coût d'opportunité lié à la mise en place de fonctionnalités de gestion sur mesure par rapport à de simples fichiers plats ne cesse d'augmenter.
Pourquoi les développeurs d'applications Embarqué ont adopté les fichiers plats
Récemment, mon collègue du service Marketing produit d’Actian, Pradeep Bhanot, a rédigé un excellent article de blog sur les systèmes d’archivage de données, dans lequel il préconisait leur abandon au profit de bases de données plus modernes, support au traitement et support l’analyse des données support . Mais, d’une certaine manière, les historiens ne sont pas aussi « historiques » que l’une desgestion des données Embarqué les plus ancrées : le fichier plat. En fait, je soupçonne que l’utilisation des fichiers plats est bien plus répandue que celle des bases de données ou des historiens comme moyen degestion des données Embarqué . C’est difficile à prouver, car les analystes ne la suivent pas comme une catégorie distincte de gestion des données , contrairement aux bases de données ou aux entrepôts de données dans le cloud, par exemple. Mais la réalité est qu’ils existent bel et bien ; nous rencontrons des clients parmi notre base installée ainsi que des prospects qui utilisent activement des fichiers plats – et pas seulement dans leurs anciennes architectures.
Pourquoi a-t-on assisté à cette adoption massive des fichiers plats au départ ?
Si vous êtes développeur et que vous écrivez du code pour collecter des données de technologie opérationnelle à partir de capteurs et d'autres systèmes périphériques, vous écrivez probablement votre code en C, C++, C# ou dans un autre langage de programmation qui vous donne un accès direct aux données provenant des appareils. Par exemple, à l’époque où j’étais ingénieur, j’utilisais des instructions inp() et outp() (ou, pour vraiment me trahir, une série de registres adressés en langage assembleur… aïe, je crois que je suis en train de faire un cauchemar). Vous vous rendez rapidement compte que vous avez besoin d’un endroit et d’un moyen de stocker les données de manière plus permanente que l’allocation de mémoire temporaire au sein de votre programme. La solution la plus simple est un fichier. Après tout, c’est l’approche la plus simple et presque tous ceux qui suivent des cours de programmation ou qui apprennent par eux-mêmes savent utiliser le système de fichiers.
Les fichiers plats étaient « suffisants » pourgestion des données traditionnellegestion des données Embarqué
Si ce qui précède explique pourquoi vous avez la possibilité de les adopter, cela ne précise pas pour autant pourquoi les fichiers plats constituaient une bonne solution à l'époque. Permettez-moi de vous donner quelques raisons essentielles pour lesquelles ils étaient tout à fait adaptés :
1. Le « silo » des objets impliquait que toute la collecte de données se faisait localement
Les systèmes de fichiers stockent les données localement, ce qui était amplement suffisant pour la plupartEmbarqué en périphérie, car celles-ci étaient destinées exclusivement à un usage local. Il n'y avait pas besoin de données supplémentaires provenant de flux de données parallèles, et encore moins de données fusionnées avec d'autres types de données et partagées sur des réseaux. Ainsi, des systèmes de fichiers autonomes, sans transfert de données en réseau, suffisaient amplement. Les préoccupations liées à streaming ou aux opérations d'extraction, de transformation et de chargement (ETL) vers un autre système ne constituaient pas un obstacle majeur.
2. Il n'y avait pas tant que ça de données, de traitement de données ou d'analyses
Jusqu’à récemment, la plupart des technologies opérationnelles disposaient de ressources de calcul très limitées : microcontrôleurs 32 bits ou 16 bits, moins d’un Mo de DRAM, et une mémoire flash ou EPROM restreinte, etc. Si ces termes ne vous disent rien, disons-le ainsi : ce sont les Oldsmobile de votre père. Avec des ressources limitées, la plupart des logiciels servaient à contrôler directement l'appareil dans le cadre d'un processus spécifique, et les données collectées servaient principalement à support processus, et non à l'instrumenter ou à fournir des analyses pour éclairer les opérations actuelles ou futures de ce processus.
3. Ce sont mes données, je suis le seul à les utiliser, alors fichez-moi la paix
Cahiers des charges de développement logiciel ? Des commentaires ? Mais qui a besoin de commentaires ? Hors sujet : les développeurs sont souvent les seuls à utiliser les logiciels qu’ils développent, et les données générées par leur code ne sont généralement consultées que par eux-mêmes et, éventuellement, par quelques experts en validation des tests d’un côté, et par les équipes de service et support l’autre. Là encore, comme ces données étaient générées par eux et pour eux, la nécessité de les partager avec un analyste métier ou un data scientist au siège, sans parler d’un métier spécifique, aurait semblé un peu tirée par les cheveux. On ne demanderait pas aux professionnels traditionnels de l’informatique et de la cybersécurité du centre de données de s’impliquer dans ces projets, et ceux-ci ne ressentiraient d’ailleurs pas le besoin de s’y forcer.
Respecter l'héritage, mais aller de l'avant
Je comprends ; j'ai moi-même fait partie de ces ingénieurs OT, comme je l'ai évoqué plus haut. En tant que développeur logiciel, il y a certes certains avantages à commencer par les systèmes de fichiers, mais avec le monde de plus en plus hyperconnecté des appareils en périphérie d’aujourd’hui – autrement dit l’IoT –, des ressources bien plus abondantes (bon sang, je peux m’offrir un Raspberry Pi pour moins cher qu’une vraie tarte raffinée), et la nécessité de partager des données pour favoriser l’agilité métier, l’innovation et rendre l’OT plus réactive et moins coûteuse, un changement s’impose. Dans le prochain volet de cette série, nous aborderons les raisons pour lesquelles les développeurs de logiciels OT sont réticents à abandonner leurs systèmes de fichiers plats pour adopter gestion des données modernes gestion des données en périphérie.
Actian est le leader du secteur gestion des données de data warehouse opérationnel et gestion des données en périphérie destinées aux entreprises modernes. Grâce à une gamme complète de solutions vous aidant à gérer vos données sur site, dans le cloud et en périphérie via les appareils mobiles et l'IoT, Actian peut vous aider à mettre en place les fondements techniques nécessaires pour support une support agilité métier. Pour en savoir plus, rendez-vous sur www.actian.com.