Los archivos planos vuelven al futuro - Parte 1
Summary
- Embedded software application developers frequently adopt flat files because they are incredibly simple, highly reliable, and free.
- While standard flat files are great for isolated devices, they struggle to natively handle the advanced requirements of modern AI.
- As data ecosystems expand, the opportunity cost of building custom management features over simple flat files continues to grow.
Por qué los desarrolladores de aplicaciones de software integrado optaron por los archivos planos
Recently, my colleague here in Actian Product Marketing, Pradeep Bhanot, wrote a great blog on data historians in which he called for their retirement in favor of more modern databases to support time-series data processing and analytics. But, in some ways, historians are not as historic as one of the most entrenched embedded data management solutions: the flat file. In fact, I suspect that the use of flat files is far more prevalent than the use of databases or historians as a means of embedded data management. It’s hard to prove because analysts don’t track it as a separate category of data management solutions the way they do databases or say cloud data warehouses. But the reality is that they are out there; we encounter customers in our installed base as well as prospects who are actively using flat files – and not just in their older designs.
¿Por qué se generalizó tanto el uso de archivos planos en primer lugar?
Si eres desarrollador y estás escribiendo código para recopilar datos de tecnología operativa procedentes de sensores y otros sistemas periféricos, probablemente estés programando en C, C++, C# o algún otro lenguaje de programación que te permita acceder directamente a los datos recibidos de los dispositivos. Por ejemplo, en los viejos tiempos, cuando yo era ingeniero, utilizaba las instrucciones inp() y outp() (o, para delatar mi edad, una serie de registros a los que se accedía en ensamblador; ¡ay, creo que estoy sufriendo un trastorno de estrés postraumático!). Rápidamente te das cuenta de que necesitas un lugar y una forma de almacenar los datos de manera más permanente que la asignación de memoria temporal dentro de tu programa. La vía más fácil es un archivo. Al fin y al cabo, es el enfoque más sencillo y casi todo el mundo que asiste a alguna clase de programación o aprende por su cuenta sabe utilizar el sistema de archivos.
Los archivos planos eran «suficientes» para la gestión tradicional de datos integrados
Aunque lo anterior explica por qué existe la posibilidad de adoptarlos, no detalla por qué los archivos planos eran una buena solución en aquella época. Permíteme darte un par de razones clave por las que resultaban adecuados:
1. El «silo de las cosas» implicaba que toda la recopilación de datos se realizaba a nivel local
Los sistemas de archivos almacenan datos de forma local, lo cual resultaba más que suficiente para la mayoría de las aplicaciones con datos integrados en el perímetro, ya que estaban destinadas exclusivamente al uso local. No existía la necesidad de datos adicionales procedentes de flujos de datos paralelos, y mucho menos de fusionarlos con otros tipos de datos y compartirlos a través de redes. Por lo tanto, los sistemas de archivos independientes sin transferencia de datos por red eran suficientes. Las preocupaciones relativas a la transmisión de datos o al proceso de extracción, transformación y carga (ETL) a algún otro sistema no suponían un obstáculo importante.
2. No había tantos datos, ni tanto procesamiento de datos, ni tantos análisis
Hasta hace poco, la mayor parte de la tecnología operativa contaba con recursos informáticos muy limitados: microcontroladores de 32 o 16 bits, menos de un MB de DRAM y una memoria flash o EPROM reducida, etc. Si no conoces estos términos, piénsalo así: son como el Oldsmobile de tu padre. Con los recursos limitados disponibles, la mayor parte del software se utilizaba para controlar directamente el dispositivo en relación con un proceso específico, y los datos recopilados servían principalmente para respaldar ese proceso, no para la instrumentación del mismo ni para realizar análisis que informaran sobre las operaciones actuales o futuras de dicho proceso.
3. Son mis datos, soy el único que los usa, así que déjame en paz
Software development specs? Comments, who needs comments? OT Developers are often the only parties using the software they develop, and the data generated by their code is seen generally only by them and possibly a few experts in test validation on one end and service and support on the other end. Again, because the data was generated by them and for them, the need to share that data with a business analyst or data scientist back at headquarters, let alone a line of business, would have seemed a bit far-fetched. Traditional IT and cybersecurity professionals in the data center would not be asked nor feel the need to force themselves into these projects.
Respetemos el legado, pero avancemos hacia el futuro
I get it; I used to be one of these OT engineers myself, as I alluded to above. There are some advantages if you’re a software developer to starting with file systems but, with the increasingly hyperconnected world for edge devices today – aka IoT, far more resources, heck I can get a Raspberry Pi for less than a fancy real pie, and the need to share data to push business agility, innovation, and make OT more responsive and less expensive, there is a need for change. In the next installment in this series, we’ll talk about why OT software developers are loath to let go of their flat file systems and move to modern edge data management systems.
Actian is the industry leader in operational data warehouse and edge data management solutions for modern businesses. With a complete set of solutions to help you manage data on-premises, in the cloud, and at the edge with Mobile and IoT. Actian can help you develop the technical foundation needed to support true business agility. To learn more, visit www.actian.com.
Stay connected
Data insights delivered to you.
(i.e. sales@..., support@...)
