It depends.
It is not a good idea to blindly always write an interface + a class that implements the interface, just because someone says it is good practice to always do that. That leads to unnecessary extra code. Always make sure that there is a good reason for any design decision you make - and "just because it is good practice" is often not really a good reason.
But often it is a good idea, for example when you want to keep the API and its implementation separate, and you want code that uses the class only depend on the API (= the interface) and not any particular implementation of the API; or if you want to have different implementations of the API, as you mention yourself, for example one that does analytics using Storm and another one that does it using Spark, and you want to be able to easily switch between the two (without needing to change all the code that is using the API).
It can also help with automatic testing - when you write tests for a class that depends on other classes, if you split those other classes in an interface + class, then you can easily create a mock implementation of the interface to use for testing classes that depend on that interface. Testing tools like
Mockito make it really easy to automatically generate mock implementations of interfaces.