2

I am considering various technologies for data warehousing and business intelligence, and have come upon this radical tool called Hadoop. Hadoop doesn't seem to be exactly built for BI purposes, but there are references of it having potential in this field. ( http://www.infoworld.com/d/data-explosion/hadoop-pitched-business-intelligence-488).

However little information I have got from the internet, my gut tells me that hadoop can become a disruptive technology in the space of traditional BI solutions. There really is sparse information regarding this topic, and hence I wanted to gather all the Guru's thoughts here on the potential of Hadoop as a BI tool as compared to traditional backend BI infrastructure like Oracle Exadata, vertica etc. For starters, I would like to ask the following question -

  • Design Considerations - How would designing a BI solution with Hadoop be different from traditional tools? I know it should be different, as I read one cannot create schemas in Hadoop. I also read that a major advantage will be the complete elimination of ETL tools for Hadoop (is this true?) Do we need Hadoop + pig + mahout to get a BI solution??

Thanks & Regards!

Edit - Breaking down into multiple questions. Will start with the one i think most imp.

Jai
  • 3,549
  • 3
  • 23
  • 31

4 Answers4

2

Hadoop is very well suited for storing colossal files that can represent fact tables. These tables can be partitioned by placing individual files representing the table into separate directories. Hive understands such file structures and allows to query them like partitioned tables. You can phrase your BI questions to the Hadoop data in the form of SQL queries via Hive, but you will still need to write and run an occasional MapReduce job.

Olaf
  • 6,249
  • 1
  • 19
  • 37
2

Hadoop is a great tool to be part of a BI solution. It is not, itself, a BI solution. What Hadoop does is takes in Data_A and outputs Data_B. Whatever is needed for Bi but is not in a useful form can be processed using MapReduce and output a useful form of the data. Be it CSV, HIVE, HBase, MSSQL or anything else used to view data.

I believe Hadoop is supposed to be the ETL tool. That's what we are using it for. We process gigs of log files every hour and store it in Hive and do daily aggregations that are loading into a MSSQL server and viewed through a visualization layer.

The major design considerations I've run against are:
- Data Flexibility: Do you want your users to view pre-aggregated data or have the flexibility to adjust the query and look at the data how they want
- Speed: How long do you want your users to wait for the data? Hive (for example) is slow. It takes minutes to generate results, even on fairly small data sets. The larger the data traversed the longer it will take to generate a result.
- Visualization: What type of visualization do you want to use? Do you want to custom build a lot of pieces or be able to use something off the shelf? What restraints and flexibility are needed for your visualization? How flexible and changeable does the visualization need to be?

hth

Update: As a response to @Bhat's comment asking about lack of visualization...
The lack of a visualization tool that would allow us to effectively utilize the data stored in HBase was a major factor in re-evaluating our solution. We stored the raw data in Hive, and pre-aggregated the data and stored it HBase. To utilize this we were going to have to write a custom connector (did this part) and visualization layer. We looked at what we would be able to produce and what is commercially available, and went the commercial route.
We still use Hadoop as our ETL tool for processing our weblogs, it's fantastic for that. We just send the ETL'd raw data to a commercial big data database that will take the place of both Hive and HBase in our design.

Hadoop doesn't really compare to MSSQL or other data warehouse storage. Hadoop doesn't do any storage (ignoring the HDFS), it does processing of data. Running MapReduces (which Hive does) is going to be slower than MSSQL (or such).

QuinnG
  • 6,346
  • 2
  • 39
  • 47
  • That is interesting. Thanks. Was unavailability of a visualization tool a big reason for not using the raw output of Hadoop and hence, use it as an ETL tool? Will Hadoop always be slow as compared to MSSQL data or warehouses? – Jai Jun 21 '11 at 08:50
  • 2
    The speed question really depends on a lot of things. The latency involved in starting a MapReduce job is relatively high, so that even the simplest Hive query (for example) will not be instant if it has to start a MapReduce job. If you have terabytes of data, though, something like MSSQL is not going to scale very well, whereas Hadoop/Hive will (by adding machines). Still, Hive lacks good support in a few areas like indexes. Something like Vertica or Teradata might perform better, but those are $$$. – ajduff574 Jun 22 '11 at 15:24
  • @ajduff574:The speed is the 'easiest' aspect to modify using Hadoop/Hive, just throw more machines at it. :) We are switching from the HStack to using Hadoop/Vertica/Tableau for the 3 reasons listed above. – QuinnG Jun 22 '11 at 15:26
  • You make important considerations. Will be evaluating Pentaho's hadoop BI solution for now. Seems to be a lot of scope for improvement to use Hadoop as a BI solution out of the box. But I like the new developments! – Jai Jun 22 '11 at 15:58
0

We are creating a comparison matrix for BI tools for Big Data / Hadoop http://hadoopilluminated.com/hadoop_book/BI_Tools_For_Hadoop.html

It is work in progress and would love any input.

(disclaimer : I am the author of this online book)

Sujee Maniyam
  • 1,093
  • 1
  • 9
  • 15
0

From business perspective, you should consider Hadoop if you have a lot of low-value data. There are many cases when RDBMS / MPP solutions are not cost effective. You also should consider Hadoop as a serious option if your data is not structured (HTMLs for example).

David Gruzman
  • 7,900
  • 1
  • 28
  • 30