Point Of Sale (POS) is one of the hotly contested areas of startups. While many feel that point of sale should shift from the desktop/kiosk based Windows machine to something a bit more funky (iOS and Android, think AirPOS) there is a legacy of hundreds of thousands of kiosks out there in the field.

One of the major headaches for POS vendors is updating the software on the kiosk. The majority is build on Windows, run locally and using local storage. Only recently the advent of broadband connectivity means that stock updates and deployments can happen as required.

Updates are tiresome especially when you have large numbers of kiosks deployed within a store.

With web based POS this isn’t really much of an issue as the software is essentially a SaaS implementation. iOS and Android update their own operating systems via their own ecosystems primarily but this then puts emphasis on the user to update their own and not the vendor to monitor measure deployments across the site. This can become an issue from a customer support point of view when there are multiple versions of the software in use across the retail field.

Hadoop 2 and YARN

Most people think of Hadoop as the BigData thing, crunching volumes of data and spitting out the answers. For Hadoop 1.x this was true, with the advent of Hadoop 2.x it’s not so much the case now.

The differences between Hadoop version 1 and version 2 is vast and it all boils down to the YARN element performing resource management control. This means that Hadoop is no longer about crunch data in the MapReduce paradigm but more a cluster control tool where the YARN element (Yet Another Resource Negotiator) can play a key role in deploying software across the whole cluster.

One Master, Many Slaves

The diagram below shows six POS kiosks in operation. Traditionally updates would happen manually or via some remote software like TeamViewer, remotely copying the files in and restarting the POS application on the kiosk. Introducing Hadoop 2.x into the mix changes the landscape slightly. The Hadoop master is on another server, this could be within the same data centre, or within the control of the POS company for example. The POS kiosks now become slaves to the Hadoop master.

In Hadoop terms every POS kiosk becomes a Node with a Container. With YARN we can make a deployment to all the kiosks at the same time. Ultimately YARN isn’t concerned about what it is running, just that it can be published to the required containers across the available nodes.  The software required for the POS would be stored on the master’s HDFS or a the master local filesystem. When the YARN client is run it’s then copied across to the addressable nodes.

This means the master deployment of the updated software only need happen once. Then it’s up to YARN to distribute the software to the other kiosks and get it started. The beauty of this means that the output and error logs are stored on the master server so they are all in one place.

Taking It Further

As YARN acts as our resource manager it’s also easier to carry data functions, heartbeat monitoring (no one likes a POS kiosk that’s down, you can’t sell) and end of day functions with the data stored on the master. From there it would be a fairly trivial task to perform some batch Hadoop jobs on the day’s trading data. Insight comes quick then the nodes are connected together.