October 24, 2012

Introduction to Cirro

Stuart Frost, of DATAllegro fame, has started a small family of companies, and they’ve become my clients sort of as a group. The first one that I’m choosing to write about is Cirro, for which the basics are:

Data federation stories are often hard to understand because, until you drill down, they implausibly sound as if they do anything for everybody. That said, it’s reasonable to think of Cirro as a layer between Hadoop and your BI tool that:

In both cases, Cirro is calling on your data management software for help, RDBMS or Hadoop as the case may be.

More precisely, Cirro’s approach is:

While you can get a Cirro result set into Excel if that meets your needs, Cirro also is partnering with Tableau for real business intelligence capabilities.

I view the proposition for Cirro as Hadoop-centric; if your problem is merely that you’re trying to combine information from a multitude of analytic RDBMS, there are many other solutions you could try. Indeed, Cirro is one of the examples I had in mind when I wrote last week that:

One theme of the season is BI over Hadoop. I have at least 5 clients claiming they’re uniquely positioned to support that (most of whom partner with a 6th client, Tableau)

That said, if an enterprise owns Cirro for other reasons, there’s something to be said for a desktop capability — the Excel-based tool — that lets you fetch and somewhat massage data in a simple and straightforward way.

Comments

5 Responses to “Introduction to Cirro”

  1. Rob Klopp on October 24th, 2012 11:12 am

    Hiya,

    I think that there are several others doing this? Business Objects has a database federation layer that joins across Hadoop and any other ODBC target (full disclosure… I work for SAP). I believe that Composite Software offers the same.

    With that said… database federation at the query level has been tried many times and never worked particularly well… performance is poor when the lowest granularity of a query plan is a query. These products ultimately lose to products with deeper integration (like Platfora in your previous post).

  2. Curt Monash on October 24th, 2012 11:37 am

    Rob,

    Where does BOBJ execute the queries? I’d be surprised if the strategy were the same as Cirro’s.

    Anyhow, the trick for a federation product is finding enough use cases that match what it’s good at. Cohera, if I recall correctly, ultimately turned into a product-catalog builder, which was very different from the original conception. Cirro needs to find tasks both big enough and also small enough that its performance profile looks good.

  3. kelly on October 31st, 2012 9:36 pm

    You are correct about Cohera’s eventually being positioned (and sold to PeopleSoft for integration with their Ariba-competitor, eProcurement) as a catalog builder. It isn’t clear to me how Cirro is conceptually different from Cohera, aside from Hadoop integration.

  4. Curt Monash on November 1st, 2012 2:37 am

    IIRC, a big part of the original Cohera story was routing around WAN node failures. The motivating example was a battlefield, where servers could be literally blown up.

  5. The point of predicate pushdown | DBMS 2 : DataBase Management System Services on July 15th, 2014 9:52 am

    […] independent products — e.g. Cirro — Oracle Big Data SQL federates SQL queries only across Oracle offerings, such as the Oracle […]

Leave a Reply




Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.