A readout to a client's leadership team
Case study

PingThings cut grid analytics compute cost 90% and queries to seconds

Cloud query costs on petabytes of grid sensor data were high enough to break the unit economics of the business.

PingThings · Operations

90%lower monthly compute cost after leaving EMR

The workflow before

PingThings streams synchrophasor (PMU) data from the electric grid, 30 to 120 readings per second per sensor, into its PredictiveGrid service. On AWS EMR, a single analytic query cost $200 to $500 and took 30 to 40 minutes. Customer contracts were losing money, and engineers spent their time on infrastructure workarounds instead of the product.

What we built

We moved the time-series workload off EMR onto the Berkeley Tree Database (BTrDB), a store built for high-rate sensor data, running on custom on-premise Hadoop and Spark clusters sized for this workload. Queries that took 30 to 40 minutes now return in seconds.

Kafka streams PMU data in, Spark processes the stream, BTrDB stores the time series with 10x or more compression, and PostgreSQL holds the metadata.

We added TensorFlow models that clean the raw sensor data and flag grid disturbances, and an API layer for customer applications. The 36 week program ended with customer workloads migrated and compute cost down 90%.

Before and after

MeasureBeforeAfter
Analytic query time30 to 40 minutesSeconds
Compute costBaseline on AWS EMR90% lower
Storage footprintUncompressed time series10x or more smaller
Infrastructure paybackn/aAbout 6 months

What's next

With fast, cheap access to years of grid history, PingThings can run more models on it: equipment failure prediction and disturbance classification moving from analysis into the alerts utilities act on.

ShareLinkedInEmail

Ingestion: Kafka receives high-rate PMU streams; Spark jobs on Hadoop (HDFS, YARN) clean and enrich the data. BTrDB stores time series in a tree structure built for fast time-range queries with delta-encoded compression and versioning for corrections.

Serving: PostgreSQL holds sensor and asset metadata; REST and WebSocket APIs expose data to customer applications; Jupyter supports analysis.

ML and operations: TensorFlow models handle data cleaning and anomaly detection. Applications run on Kubernetes, monitored with Prometheus and Grafana. BTrDB was chosen after benchmarking against InfluxDB and TimescaleDB.

Next step

Let's build the case study we tell next.