My clients at StreamBase are coming out with a new product line called LiveView, and I agreed they could launch it via this blog. Key points about StreamBase LiveView Version 1.0 include:
- LiveView is a business intelligence and alerting suite built on/in the rest of StreamBase’s technology, meant to operate on streaming data.
- LiveView is positioned by StreamBase as having a true push event-driven architecture rather than pull/poll.
- StreamBase LiveView is designed to query in-memory data and then have the results change in real time as the data set changes.
- The LiveView user interface is a rapidly changing work in progress.
- LiveView has other Version 1 limitations as well
- LiveView is targeted squarely at StreamBase’s financial trading core market until some of the Version 1 limitations are lifted.
The basic StreamBase LiveView pipeline goes something like:
- Data comes into the system via multiple streams.
- Transformations upon data arrival can include but are not limited to:
- Joins to reference data.
- Joins to other streams.
- The streams (transformed or perhaps otherwise) are output to tables …
- … which are continuously updated as more data streams through.
- The data in the resulting table can be consumed:
- Via LiveView-provided BI capabilities.
- Via an API.
When wearing my vendor consultant hat, I warmly encourage StreamBase to emphasize the lack of a batch step anywhere in this process. As an analyst, however, I’m more restrained about a claim like “We uniquely free you from batch.” I agree that avoiding batch jobs is a Very Nice Thing. But you also are spared most batch-cycle processing if you stream updates from your short-request database to an analytic DBMS, e.g. via some kind of near-real-time replication.
That said, the push-versus-pull continuous filtering part of the StreamBase LiveView story seems pretty real. I think having sub-second display updates is cool in all sorts of BI use cases, and seriously useful in some number of them. While I don’t have a clear opinion as to whether the StreamBase approach offers huge performance advantages for that kind of latency over “pull” alternatives, my guess is in the direction of “yes”.
Version 1 limitations on StreamBase LiveView include:
- You consume data one table at a time, with no possibility of a join after the data has originally been put into a LiveView table.
- While LiveView in principle offers rich alerting potential, you get at it via an API rather than much in the way of alerting-specific tools.
- The first LiveView UI StreamBase put together looks a lot like 1980s stock quote machines. The next one it added looks a lot like Panopticon. Much cool-looking enhancement remains to be done.
One competitive (non)-note: This all sounds something like what TIBCO has been pushing for years, but in fact I don’t have much knowledge of TIBCO’s efforts in the area. I had a meeting set up to learn about it some time ago, but it got canceled because TIBCO’s PR people:
- Didn’t want to let any kind of meeting happen without them, even though a serious CTO-type representative seemed happy to talk, but also …
- … didn’t want to work at dinner time.
I haven’t had substantive contact with TIBCO since.