Having done various predictive maintenance scenarios over the course of 3 years, I noticed two common pitfalls. First, the lack of business understanding and the cost of being right vs the cost of being wrong (I will write about that later). Second, the idea of a single model that can predict it all, under all conditions, no matter what. The latter I often see when working novice Data Scientist. They will spend most of their time re-training their model to get their perfect F1 or accuracy metric instead of knowing when to stop and re-think strategy. This problem gets even more severe when you deal with very imbalanced datasets.

Why does this matter?

Each device and each sensor will have its unique data footprint with its noise distribution. If your pool is sufficiently large, you will be able to detect generic trends and make generalised predictions. However, you might have lost the subtle differences between machines and thus lost predictive powers. Maybe if you performed some clustering analyses ab-initio you could have decided that 3 or 5 models would have served your problem much better. Or perhaps if you just already know if your data is an anomaly you can drive business value.

What could be a solution?

As always, there is no single best solution out there. There will still be a trade-off to get a model generalised sufficiently to bring to production. What I did observe so-far, at several customers, is that a combination of weak-learners is outperforming most of these highly specialised models. This effect is often even stronger when we take these “weak” models into field trials and or production. Odds are, your training data never was complete, and thus you instead have the flexibility to deal with this incompleteness by having weak, but multiple, models.

One of the great new features that AzureSMR is enabling is the read and write access to Azure Blog Storage. This is happening in a similar manner as is the case for when you use Python.

Shameless copy from the README:

In order to access Storage Blobs you need to have a key. Use azureSAGetKey() to get a Key or alternatively supply your own key. When you provide your own key you no longer need to use azureAuthenticate() since the API uses a diferent authentication approach.

sKey <- AzureSAGetKey(sc, resourceGroup = "Analytics", storageAccount = "analyticsfiles")
To list containers in a storage account use azureListContainers()

azListContainers(sc, storageAccount = "analyticsfiles", containers = "Test")
To list blobs in a container use azureListStorageBlobs()

azureListStorageBlobs(sc, storageAccount = "analyticsfiles", container = "test")
To Write a Blobs use azurePutBlob()

AzurePutBlob(sc, StorageAccount = "analyticsfiles", container = "test",
contents = "Hello World",
blob = "HELLO")
To read a blob in a container use azureGetBlob()

azureGetBlob(sc, storageAccount = "analyticsfiles", container = "test",
blob="HELLO",
type="text")