Liste de contrôle pour la migration des fichiers plats des développeurs de logiciels Embarqué
Voici le dernier volet de la série d'articles que j'ai consacrés à l'utilisation persistante des fichiers plats et aux raisons pour lesquelles ceux-ci ne constituent plus une solution viable pour l'avenir. Le premier volet portait surles fichiers plats et expliquait pourquoi les développeurs d'applications Embarqué les ont si facilement adoptés. Dans le deuxième volet, j'ai ensuite examinéles raisons pour lesquelles Embarqué sont réticents à utiliser des bases de données. Le troisième volet s'est penché sur les raisons pour lesquelles les développeurs s'accrochent aux systèmes de fichiers plats.
Pour ce dernier volet, je me suis rendu compte que l'argumentaire en faveur de l'abandon des fichiers plats devait probablement être présenté de manière plus normative. C'est pourquoi, en collaboration avec notre responsable de l'ingénierie, Desmond Tan, nous avons dressé une liste de raisons qui ne portent pas vraiment sur ce que vous utilisez actuellement ni sur ce que vous devriez utiliser en théorie. Elle se concentre plutôt sur les besoins concrets qui justifieraient l’abandon des fichiers plats. Cette liste reflète l’évolution des cas d’utilisation Embarqué pour gestion des données les domaines du mobile, de l’IoT et des équipements intelligents complexes. Elle tient également compte de ce que nos clients nous confient lors de réunions privées concernant leurs défis ainsi que leurs exigences commerciales et produit.
Sur la base de ces informations, voici les huit principales exigences pour gestion des données moderne gestion des données en périphérie :
1. La persistance des données locales et l'évolution de son utilisation
En général, les données stockées localement dans des fichiers plats servaient de mémoire tampon pour les opérations immédiates sur les données propres à l'appareil en question. De plus, ces données étaient évaluées sans référence de base établie de longue date mais continuellement actualisée. Cependant, la nécessité de combiner les données provenant de plusieurs appareils et sources, ainsi que l'utilisation de données historiques comme référence de base pour tout, du simple rapport signal/bruit à l'inférence par apprentissage automatique, signifie que gestion des données opérations complexes qui alimentent le traitement et l'analyse des données locales dépasse les fonctionnalités de base fournies par les systèmes de fichiers.
2. Support plusieurs environnements d'exploitation avec un format de stockage unique
Qu'il s'agisse de la conception de produits, des portefeuilles de technologies opérationnelles ou support informatique support divisions opérationnelles, toute une série de systèmes, situés à la périphérie et au sein même de l'entreprise, doivent échanger des données entre différents systèmes d'exploitation, allant d'Android/iOS à Windows/Linux, en passant par les environnements virtualisés dans le cloud. Un format de stockage unique permettrait de réduire considérablement les délais et les coûts d'intégration, tout en renforçant la sécurité.
3. gestion des données Support tous les rôles impliqués dans le traitement et l'analyse des données
Différents rôles devront tirer parti de l'accès à l'Edge gestion des données à distance et localement sur cette gamme de plateformes sous-jacentes plateformes différents mécanismes d'accès, notamment l'interface CLI, la programmation et les langages de script. Il y a probablement matière à une discussion plus approfondie sur les raisons pour lesquelles ce sujet mérite un article de blog à part entière.
4. Traiter le Big Data en périphérie
Petit quiz : quels sont les quatre « V » du Big Data? Oui, vous pourriez tous les citer même si on vous réveillait en plein sommeil (pour ceux d’entre vous qui refusent de quitter ce merveilleux rêve : Volume, Variété, Vitesse et Valeur). Tout comme Hadoop a constitué une première étape au niveau de l'entreprise pour répondre au besoin d'un réservoir commun pour le Big Data, il faut un équivalent à la périphérie. Et, comme pour la dernière exigence, il faudrait un article de blog entier pour discuter plus en détail de la séparation par rapport aux fichiers plats. Pour l'instant, le principal enseignement concret à retenir est que vous devez être capable de support types de données, y compris JSON, BLOB et les données structurées traditionnelles, dans une seule base de données.
5. Partager les données entre les environnements OT, cloud et informatiques traditionnels
partage des données pouvoir prendre en charge les scénarios de communication entre appareils et entre appareils et passerelles dans les environnements OT, ainsi que les scénarios de type « Edge-to-Cloud » et « Cloud-to-Data Center » pour les environnements distants et les succursales au niveau de l'interface Edge-to-Cloud. En d'autres termes, vous avez besoin d'une plateforme unique pour les architectures client, peer-to-peer, client-serveur et Internet/Intranet.
6. Fonctionner en mode autonome en cas de coupure de connexion
Même si l'Edge semble globalement évoluer vers un état d'hyperconnectivité, il ne faut pas en conclure à tort que cela supprime ou réduit la nécessité de pouvoir traiter et analyser les données localement. Dans de nombreuses applications de technologie opérationnelle, une approche exclusivement web est irréalisable. Par exemple, dans le cas de véhicules autonomes, le traitement et la prise de décision basés sur des signaux vidéo et lidar pour déterminer où diriger la voiture, à quelle vitesse et avec quelle accélération – ou décélération – ne peuvent pas être gérés par le cloud ; la latence à elle seule entraînerait des accidents. Dans d’autres cas, la commodité ou la facilité d’utilisation peuvent être la raison pour laquelle vous choisissez de gérer les opérations localement. Imaginons que vous ayez des milliers d'albums localement dans votre bibliothèque iTunes et que vous souhaitiez rechercher une chanson à partir de ses paroles lors de votre vol de quatorze heures entre San Francisco et New Delhi.
7. Gérer la collecte de données multicanaux à haut débit
Bon nombre des signaux fondamentaux collectés ne changeront pas à mesure que nous évoluerons vers un monde plus connecté et automatisé ; la pression, le volume et la température en sont trois excellents exemples. Cependant, comme mentionné plus haut, les flux vidéo – qu’il s’agisse de reconnaissance faciale ou de vision industrielle – se généralisent et offrent des résolutions et des fréquences d’images bien plus élevées – pensez à la 4K UHD à 120 Hz. Les signaux lidar ont également été évoqués plus haut. À une époque, j’étais ingénieur et je concevais des systèmes de radar laser. Même à l’époque, je pouvais facilement collecter 400 Mo de données par jour, prenant des décisions en quelques millisecondes pour chaque ensemble de signaux lidar collectés. Je pourrais citer exemple après exemple. Le fait est qu’avec le traitement et l’analyse modernes des données en périphérie, où l’on atteint plusieurs téraoctets par jour et où les données sont à la fois traitées immédiatement et récupérées en partie ou en totalité pour un traitement supplémentaire ultérieur, tous ces scénarios deviendront monnaie courante.
8. Tirer parti des composants complémentaires prêts à l'emploi de l'écosystème
Il va sans dire que ceux qui utilisent des fichiers plats sont probablement du genre à tout faire eux-mêmes, y compris pour d'autres aspects de leurs solutions. Abandonner les fichiers plats permettra d'optimiser la productivité en leur ouvrant la voie à des solutions prêtes à l'emploi pour analytique avancée, les outils de reporting et de visualisation, ainsi que plateformes.
En résumé, si vous êtes confronté à l'une ou plusieurs de ces exigences, vous devriez sérieusement envisager de passer des fichiers plats à une architecture unique, évolutif et sécurisée, capable de gérer déploiement le développement multiplateformes, et qui vous offre la puissance nécessaire pour support multitude de traitements de données avancés et cas d'usages analytiques. Les fichiers plats ne suffisent tout simplement plus, mon ami.
Restez connecté
Des informations exploitables à votre disposition.
(par exemple, sales@..., support)
