Apache Spark Interview Questions

1. What is Spark?

Apache Spark is a fast, easy-to-use and flexible data processing framework. It has an advanced execution engine supporting cyclic data  flow and in-memory computing. Spark can run on Hadoop, standalone or in the cloud and is capable of accessing diverse data sources including HDFS, HBase, Cassandra and others. 

2. Key features of Spark.

• Allows Integration with Hadoop and files included in HDFS.
• Spark has an interactive language shell as it has an independent Scala (the language in which Spark is written) interpreter.
• Spark consists of RDD’s (Resilient Distributed Datasets), which can be cached across computing nodes in a cluster.
• Spark supports multiple analytic tools that are used for interactive query analysis , real-time analysis and graph 

3. What is an RDD?

RDD is the acronym for Resilient Distribution Datasets – a fault-tolerant collection of operational elements that run parallel. The partitioned data in RDD is immutable and distributed. There are primarily two types of RDD:

1. Parallelized Collections : The existing RDD’s running parallel with one another.
2. Hadoop datasets : perform function on each file record in HDFS or other storage system

4. What are Partitions? 

As the name suggests, partition is a smaller and logical division of data  similar to ‘split’ in MapReduce. Partitioning is the process to derive logical units of data to speed up the processing process. Everything in Spark is a partitioned RDD.

5. What kind of operations RDD support?

• Transformations.
• Actions

6. What do you understand by Transformations in Spark?

Transformations are functions applied on RDD, resulting into another RDD. It does not execute until an action occurs. map() and filer() are examples of transformations, where the former applies the function passed to it on each element of RDD and results into another RDD. The filter() creates a new RDD by selecting elements form current RDD that pass function argument.

7. What are Actions in Spark ?

An action helps in bringing back the data from RDD to the local machine. An action’s execution is the result of all previously created transformations. reduce() is an action that implements the function passed again and again until one value if left. take() action takes all the values from RDD to local node.

8. Define functions of SparkCore?

Serving as the base engine, SparkCore performs various important functions like memory management, monitoring jobs, fault-tolerance, job scheduling and interaction with storage systems.

9. What is RDD Lineage?

Spark does not support data replication in the memory and thus, if any data is lost, it is rebuild using RDD lineage. RDD lineage is a process that reconstructs lost data partitions. The best is that RDD always remembers how to build from other datasets.

10. What is Spark Driver?

Spark Driver is the program that runs on the master node of the machine and declares transformations and actions on data RDDs. In simple terms, driver in Spark creates SparkContext, connected to a given Spark Master.
The driver also delivers the RDD graphs to Master, where the standalone cluster manager runs.

11. What is Hive on Spark?

Hive contains significant support for Apache Spark, wherein Hive execution is configured to Spark:

hive> set spark.home=/location/to/sparkHome;hive> set hive.execution.engine=spark;

Hive on Spark supports Spark on yarn mode by default.

12. Name commonly-used Spark Ecosystems.

• Spark SQL (Shark)- for developers.
• Spark Streaming for processing live data streams.
• GraphX for generating and computing graphs.
• MLlib (Machine Learning Algorithms).
• SparkR to promote R Programming in Spark engine.

13. What is Spark Streaming ?

Spark supports stream processing – an extension to the Spark API , allowing stream processing of live data streams. The data from different sources like Flume, HDFS is streamed and finally processed to file systems, live dashboards and databases. It is similar to batch processing as the input data is divided into streams like batches.

14. What is Spark SQL?

SQL Spark, better known as Shark is a novel module introduced in Spark to work with structured data and perform structured data processing. Through this module, Spark executes relational SQL queries on the data. The core of the component supports an altogether different RDD called SchemaRDD, composed of rows objects and schema objects defining data type of each column in the row. It is similar to a table in relational database.

15. What is a Parquet file?

Parquet is a columnar format file supported by many other data processing systems. Spark SQL performs both read and write operations with Parquet file and consider it be one of the best big data analytics format so far.

16. What file systems Spark support?

• Hadoop Distributed File System (HDFS).  Learn more about HDFS in these Top Interview questions.
• Local File system.
• S3

17. What is Yarn?

Similar to Hadoop, Yarn is one of the key features in Spark, providing a central and resource management platform to deliver scalable operations across the cluster . Running Spark on Yarn necessitates a binary distribution of Spar as built on Yarn support.

18. List the functions of Spark SQL.?

Spark SQL is capable of:

• Loading data from a variety of structured sources.
• Querying data using SQL statements, both inside a Spark program and from external tools that connect to Spark SQL through standard database connectors (JDBC/ODBC). For instance, using business intelligence tools like Tableau. Get to know more about Tableau in this Tableau Tutorial.
• Providing rich integration between SQL and regular Python/Java/Scala code, including the ability to join RDDs and SQL tables, expose custom functions in SQL, and more.

19. What are benefits of Spark over MapReduce?

• Due to the availability of in-memory processing, Spark implements the processing around 10-100x faster than Hadoop MapReduce. MapReduce makes use of persistence storage for any of the data processing tasks.
• Unlike Hadoop, Spark provides in-built libraries to perform multiple tasks form the same core like batch processing, Steaming, Machine learning, Interactive SQL queries. However, Hadoop only supports batch processing.
• Hadoop is highly disk-dependent whereas Spark promotes caching and in-memory data storage.
• Spark is capable of performing computations multiple times on the same dataset. This is called iterative computation while there is no iterative computing implemented by Hadoop.

Read more in this blog about the comparison of Spark and MapReduce.

20. What is Spark Executor?
When SparkContext connect to a cluster manager, it acquires an Executor on nodes in the cluster. Executors are Spark processes that run computations and store the data on the worker node. The final tasks by SparkContext are transferred to executors for their execution.

21. Name types of Cluster Managers in Spark.

The Spark framework supports three major types of Cluster Managers:

1. Standalone : a basic manager to set up a cluster.
2. Apache Mesos : generalized/commonly-used cluster manager, also runs Hadoop MapReduce and other applications.
3. Yarn : responsible for resource management in Hadoop

22. What do you understand by worker node?

Worker node refers to any node that can run the application code in a cluster.

23. Do you need to install Spark on all nodes of Yarn cluster while running Spark on Yarn?

No because Spark runs on top of Yarn.

Handling data with changing schema on Hadoop

User data often is unpredictable, even when we can predict a change coming our way we need to prepare for that. Make changes in our environment to accept the incoming change, accommodate and absorb. 

With that being a fact of life, our design should allow for those changes to happen.  With the structured data warehouses gone (well, mostly), Hadoop based data stores are the norm these days, and would be default in future not so distant.  By definition, Hadoop allows all kinds of data to be stored on the cluster and happily provides various tools to process such data.

However, with different types of data out there on cluster, any given tool would need to "know" what data that is? How to read it, interpret it and process it. That would have been relatively straightforward with the data schema being static, as in, a file comes in from source A, with a certain format, and that’s about it. You can define programs/structures to work with it. 

What if the source system decides to alter the data set schema, add a few columns, and change some column ordering, perhaps data type too, what then? Would our program reading that dataset on Hadoop cluster still work as it? No.. It won’t .. Because it would also require change to reflect the same changes sent from source.

Assume that you did those changes too. So, now our program is version 2, able to handle the dataset sent by source (v2 as well). What about the older data lying around on Hadoop cluster (v1, with old schema)? How is that dataset going to used/usable?  What if that data was used by hive tables, would you have two (or more) set of tables? 

What if that data was exposed to some analytical programs, through R or similar? I am sure we won’t want to rewrite/test the whole solutions just because source system decided to change something?

And this scenario is not purely hypothetical, it happens around us, more often than not, just that we deal with it in our own patchwork styles, or solutions varying on a case to case basis.

Here I propose a somewhat generic solution, one that might work for all, well, nearly all use cases.

Avro is a data serialization system, wherein the schema is built into the file itself. As a result, programs reading the data-file doesn’t have to bother with interpreting the data file through external schema.

Avro was designed by Doug Cutting for similar reasons, as a tool that is language and schema independent and therefore unrelated tools/technologies can deal with data files.

That being said, is not a silver bullet in itself, but it handles the schema change fairly nicely.

Basically, you store the data on hdfs in Avro formatted files. For that, Avro schema needs to be created, which is fairly straightforward json structured file, indicating the record structure. Take a look at an example here - 

{"namespace": "myExample.avro",  "type": "record",  "name": "User",  "fields": [      {"name": "name", "type": "string"},      {"name": "age",  "type": ["int", "null"]},      {"name": "address", "type": ["string", "null"]}  ] }

create external  table ex_users (name     String ,  age     int , address     String) stored as AVRO location '/apps/data/hive/ex_users.tbl';

When files are saved as Avro formatted files, information from the schema is built into them, in plain text, and is parse-able for programs like hive and others to interpret the rest of the file.

For this to work, the tool has to rely on Avro. Look at this hive table definition - 

With the clause "Stored as Avro" we are basically telling hive to match the columns defined in hive with columns in Avro fi

les in that hdfs location and use whatever columns map to hive definition.

  

Avro is compressible, split-able and stores data in binary format, providing some additional features.

When this Avro formatted file is exposed to programs like hive, they don’t have to worry about changes in schema, since they rely on the schema information in the file header. If the hive / R schema asks for 5 columns, but the file only has 3 of them (with names as matching criteria and not order/position of columns), those matching columns are project to the consuming tool, and the rest is ignored. 

Similarly, if the tool asks for data that is not present in a certain data file (remember our example v2 file with additional column as against v1), the column that is not present is reported as null.

Now, look at the following data file (new avro schema - after source system decided to change)

{"namespace": "myExample.avro", "type": "record", "name": "User", "fields": [     {"name": "name", "type": "string"},     {"name": "age",  "type": ["int", "null"]},       {"name": "salary",  "type": ["float", "null"]},     {"name": "address", "type": ["string", "null"]} ]}

And the corresponding hive table definition - 

create external  table ex_users (name     String ,  age     int , address     String, salary float)stored as AVROlocation '/apps/data/hive/ex_users.tbl';

For this table definition, its not a problem to query and report a data file in old schema (v1) wherein the column salary is not present. it would simply know from the avro schema definition in that header that the file doenst have that column, and it would gladly report that as null.

On the other hand, in the new structure has a different order of columns, which is also fine for hive/avro combination since the schema definition helps match up the columns and report the right content in right columns. 

Similar analogies can be derived for other data consumers who need to interpret the schemas for data files on hdfs.

In comparison to some other storage formats, we do lose some points on the performance scale, but for the use case, where schema is changing and we want to be able to handle the changes with little or no effort, this is a better fit than many others.

Hadoop - Small Files vs Big Files

Credits- https://blogs.msdn.microsoft.com/cindygross/2015/05/04/hadoop-likes-big-files/

One of the frequently overlooked yet essential best practices for Hadoop is to prefer fewer, bigger files over more, smaller files. How small is too small and how many is too many? How do you stitch together all those small Internet of Things files into files "big enough" for Hadoop to process efficiently?

The Problem

One performance best practice for Hadoop is to have fewer large files as opposed to large numbers of small files. A related best practice is to not partition “too much”. Part of the reason for not over-partitioning is that it generally leads to larger numbers of smaller files.

Too small is smaller than HDFS block size (chunk size), or realistically small is something less than several times larger than chunk size. A very, very rough rule of thumb is files should be at least 1GB each and no more than maybe around 10,000-ish files per table. These numbers, especially the maximum total number of files per table, vary depending on many factors. However, it gives you a reference point. The 1GB is based on multiples of the chunk size while the 2nd is honestly a bit of a guess based on a typical small cluster.

Why Is It Important?

One reason for this recommendation is that Hadoop’s name node service keep track of all the files and where the internal chunks of the individual files are. The more files it has to track the more memory it needs on the head node and the longer it takes to build a job execution plan. The number and size of files also affects how memory is used on each node.

Let’s say your chunk size is 256MB. That’s the maximum size of each piece of the file that Hadoop will store per node. So if you have 10 nodes and a single 1GB file it would be split into 4 chunks of 256MB each and stored on 4 of those nodes (I’m ignoring the replication factor for this discussion). If you have 1000 files that are 1MB each (still a total data size of ~1GB) then every one of those files is a separate chunk and 1000 chunks are spread across those 10 nodes. NOTE: In Azure and WASB this happens somewhat differently behind the scenes – the data isn’t physically chunked up when initially stored but rather chunked up at the time a job runs.

With the single 1GB file the name node has 5 things to keep track of – the logical file plus the 4 physical chunks and their associated physical locations. With 1000 smaller files the name node has to track the logical file plus 1000 physical chunks and their physical locations. That uses more memory and results in more work when the head node service uses the file location information to build out the plan for how it will split out any Hadoop job into tasks across the many nodes. When we’re talking about systems that often have TBs or PBs of data the difference between small and large files can add up quickly.

The other problem comes at the time that the data is read by a Hadoop job. When the job runs on each node it loads the files the task tracker identified for it to work with into memory on that local node (in WASB the chunking is done at this point). When there are more files to be read for the same amount of data it results in more work and slower execution time for each task within each job. Sometimes you will see hard errors when operating system limits are hit related to the number of open files. There is also more internal work involved in reading the larger number of files and combining the data.

Stitching

There are several options for stitching files together.

• Combine the files as they land using the code that moves the files. This is the most performant and efficient method in most cases.
• INSERT into new Hive tables (directories) which creates larger files under the covers. The output file size can be controlled with settings like hive.merge.smallfiles.avgsize and hive.merge.size.per.task.
• Use a combiner in Pig to load the many small files into bigger splits.
• Use the HDFS FileSystem Concat APIhttp://hadoop.apache.org/docs/current/api/org/apache/hadoop/fs/FileSystem.html#concat.
• Write custom stitching code and make it a JAR.
• Enable the Hadoop Archive (HAR). This is not very efficient for this scenario but I am including it for completeness.

There are several writeups out there that address the details of each of these methods so I won’t repeat them.

• Merging small files on HDInsight http://blogs.msdn.com/b/mostlytrue/archive/2014/04/10/merging-small-files-on-hdinsight.aspx which uses a Java MapReduce JAR https://github.com/mooso/smallfilesmerge.
• Quick Tip for Compressing Many Small Text Files within HDFS via Pighttp://dennyglee.com/2014/01/06/quick-tip-for-compressing-many-small-text-files-within-hdfs-via-pig/.
• FileCrush https://github.com/edwardcapriolo/filecrush.
• HDFS FileSystem Concat API
  • http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/WebHDFS.html#Concat_Files
  • http://hadoop.apache.org/docs/current/api/org/apache/hadoop/fs/FileSystem.html#concat
  • https://issues.apache.org/jira/browse/HDFS-222
• CombineFileInputFormat (splits)
  • This may not work with really large numbers of files and has to be used EVERY time a job is run.
  • http://www.ibm.com/developerworks/library/bd-hadoopcombine/index.html
  • Process Small Files on Hadoop Using CombineFileInputFormat (1)http://www.idryman.org/blog/2013/09/22/process-small-files-on-hadoop-using-combinefileinputformat-1/
• Dealing with Hadoop’s small files problem http://snowplowanalytics.com/blog/2013/05/30/dealing-with-hadoops-small-files-problem/  “aggregating with the small files first reduced total processing time from 2 hours 57 minutes to just 9 minutes – of which 3 minutes was the aggregation, and 4 minutes was running our actual Enrichment process. That’s a speedup of 1,867%.”
• The Small Files problem in Hadoop http://piglog4j.blogspot.com/2013/06/the-small-files-problem-in-hadoop.html
• Hadoop Archive: File Compaction for HDFS https://developer.yahoo.com/blogs/hadoop/hadoop-archive-file-compaction-hdfs-461.html
• The Small Files Problem http://blog.cloudera.com/blog/2009/02/the-small-files-problem/ “Reading through files in a HAR is no more efficient than reading through files in HDFS, and in fact may be slower since each HAR file access requires two index file reads as well as the data file read (see diagram). And although HAR files can be used as input to MapReduce, there is no special magic that allows maps to operate over all the files in the HAR co-resident on a HDFS block.”

The key here is to work with fewer, larger files as much as possible in Hadoop. The exact steps to get there will vary depending on your specific scenario.

Hadoop Meetup on the sidelines of Strata Hadoop Conference - Part 2

Read part 1 of this here

Day 2 of the meetup was equally exciting, if not better.  Lined up were talks from Qubit and Google, William Hill (a surprise for me - more later on that) and then PostCodeAnywhere, all very exciting from the synopsis.

Google & Qubit showcased basically a stream processing engine, with pluggable components, many of them can be written in different technologies and programming languages.

Of course Google Cloud Data flow is much more than just a stream processing engine, however, for real time data ingestion perspective, that feature is pretty significant.  

A completely managed system, it woks on the publish-subscribe (pub-sub) model.  As Reza put it, “pub-sub is not just data delivery mechanism, its used as a glue to hold the complete system together”.  Pluggable components is another differentiator for Google’s offering, in today’s demo they showcased bigtable as one of the consumers at the end.

From my own knowledge of stream processing, which is not significant in anyway, i could relate to many similarities with IBM’s info sphere streams and some with apache kafka.  However, a question around comparisons with these sites remained unanswered from Google (though in very good spirit, in a chat with the speaker Reza later on, it came out as more of a philosophical question avoidance than anything else).

The william hill talk (by Peter Morgan, their head of engineering), was a genuine surprise, at least for me.  Perhaps due to my ignorance, due to which i didn't realize, their systems are far more sophisticated and load bearing than I would have imagined.  As an example, they process 160TB of data through their systems on a daily basis.

Including many complexities managed through their system are their main components, the betting engine, the settlement engine among others. 

William Hill supports an open API as well, enabling app developers to pick up data elements and innovate. However, for obvious reasons, very limited data is thrown open in the public domain.  Would that be a deterrent for app developers ? not having enough data ?   For example, if i would want to report in an app, who’s betting on a  certain game, cross referenced with geo location data .. I cant do that, since William hill doesn't publish demographic data.  I personally feel alright with it, there are possibilities that many of those data elements can be used in ways to influence the betting system itself, becoming counter-productive.

I would imagine their IT systems to be one of the top notch systems around the place, to be able to manage such data volumes, with such speeds and accuracy. Commendable job.  I would probably write exclusively on their architecture once i get my hands on the presentation slides (couple of days may be).

The talk from PostCodeAnywhere was more educative to me, personally.  Got to understand a bit about Markov Models, chains and how they can be used for machine Learning.  Very interesting stuff there too.

Apache Spark is being seen more and more as the tool to be perform analytics on the fly, specially on large volumes of data.  It would be very interesting to see how R and python analytical capabilities compare with what spark offers.

Speaking to another attendee today, it came out the people prefer to use R more and more for massaging and cleansing purposes, however, its not seen as fit for heavy lifting required for performing real analytic and/or predictive pieces. For these areas, people still prefer to use Python.

IBM’s bigR is a possible contender for the job, where they talk about having optimised R for a hadoop cluster and have enabled it to work on top of hdfs.  However, bigR is not open source and that could be its biggest challenge in adoption.

Hadoop Meetup on the sidelines of Strata Hadoop Conference - Part 1

Not being able to make it up to the Main conference (Strata Hadoop London 2015), the evening meet-ups were the consolation pieces of getting in touch as much as possible.

In my view, these conferences/events often help one to get to know about the recent developments in the space, mostly showcasing whats being done with a given technology, whats coming up (future developments, innovations) and people's experiences with the technology, both good (the famous savings use cases) and bad (challenges faced in achieving production readiness, if ever).

Last evening, on day 1 of the conference, I ended up attending one of the meet-ups.  It was particularly useful for me, for couple of reasons.

There was a talk on the new execution engine for hive, i.e. hive running on spark. Always keen on internal workings of a complex piece of software (or hardware for that matter), i was very happy to be able to listen in directly from the person responsible for much of development on hive.  I have an audio recording of the whole talk, though I am hopeful that the conference organizers shall put up the video on their website anyway.

When Phill talked about his experiences on getting hadoop on its feet and how they orchestrated hadoop as a PaaS within BT was something  insightful, (they seem to call it HaaS there).  it showed two things to me - architects' always have to "find the funding" for innovations and new tech to be brought in to the organization :) Also, Security on hadoop is "doable", as his use case proved to be.  There are reliable tools and solutions which can help achieve Enterprise level security for a hadoop cluster.

Another interesting talk was Dato's.  Dato is a machine learning/modelling tool, which claims to be fairly quick than many others, allows the data to be consumed in-place (like hadoop) and supports hdfs integration.  I am sure to follow up on Dato with the organization.  for me its one of the key problems of the future, where data is too much and the modelling algorithm has to be enabled to consume data for training sets in-place, since its just not practical to move tera/petabytes of data to where program is.  IBM BigR is doing something similar as well.

Finally, another interesting talk was from Big Data Boards team.  they talked about how they are building cluster hardware for hosting small hadoop clusters. Interesting proposition there, to have your own hadoop cluster running on a desk in a corner of your office.  no need of going over to the likes of aws for hosting the cluster.  They say that many universities etc are already using the clusters they made for real life experiments.  very interesting space for me.

Proud - Cloudera Certified Developer for Apache Hadoop

I have not been a believer of certifications, that should be clear from the fact that even though I have been working with Informatica since 2002, I never tried their certification till 2011. And, same about Oracle, whose exam I have not yet attempted/planned/thought over. I used to think that the knowledge level will prevail anyway, whether or not an authority stamps on it.

However, I believe, I am changing, to a certain extent so to say.  It seems that I have come to accept the certifications' worth, and therefore, after the training provided by Cloudera, I picked up the opportunity and went through with the rigor of examination.

Fortunately, I came through.  And, as much as I try not to showcase it, its a great feeling.  Somehow, the knowledge is vindicated, that yes, this guy knows something about hadoop and you better listen to him, :) . Funny that one has to put a badge out there to be heard.

Well, all said and done, the certification is done, courtesy the employer, who sponsored the training and of course the examination coupon that came along.  I would like to thank our trainer from cloudera, Amandeep Khurana for his depth and breadth around all things hadoop.  As much as I knew about hadoop before going in the training, those 2.5 days added precious layers to my knowledge.  Thanks Amandeep.

hadoop/hive with tableu

It was in 2010 that  I had the first taste of hadoop/hive.  Back then I was still using hadoop 0.20 and was doing a proof of concept for a customer, who wanted to see if hadoop can be a solution for their problems.

Since then, I have been reading up and following the changes in the hadoop world, and tweaking things here and there with the home installation.   Today, I tried to mount hive on hadoop (without hbase, with hbase will be the next experiment) and see how can I get it playing nicely.

The experience is awesome as usual, and it reinforces my belief in the fact that hadoop ecosystem has a huge role to play in the computing industry of tomorrow.

The analytical capabilities of the volumes of data managed by the hadoop kind of system are ever increasing, therefore the interest from many instant BI players to provide access to the data behind hadoop.

One such player is the instant dashboard tool - Tableu.  They have announced that Tableu 7 will be able to read data directly from hive environments.  

In real life it was a bit of a challenge, but whats the fun if there is no challenge. In a nutshell, it does work. No doubt.  However, the kind of configuration that is required and administration can be tricky.

1. You have to install the hive driver (available from their website - http://www.tableausoftware.com/support/drivers)

2. you have to launch hive in a particular way, as a service. (hive --service hiverserver).  Also, hive on a pseudo cluster only allows one user connected (since the metadata store is single user on Derby).  as a result, if you are using Tableu connectivity, nothing else can access hive, not even a command line inerface.

3. Remember that each addition/change to the data set on tableu interface triggers a map-reduce job on the hive cluster/server.  And that, hadoop/hive are not really meant to be fast responsive systems.  Therefore, expect high delays in fulfilling your drag and drop requests.

4. There might/will be additional troubles in aggregating certain types of data, since the data types on hive might not be additive in the same way as front end expects them to be.

All in all, it wins me in the ease of use provided for accessing the data behind the hadoop environment, however, there are faster ways that already exist to achieve the same result.

Informatica & hadoop... solutions for future ?

Distributed computing using hadoop has taken the IT industry by a whirlwind in the last few years.  After getting almost "adopted" by yahoo, hadoop has progressed quite fast, and is now maturing slowly but steadily.

More and more enterprise solution providers are annoucing their support for the hadoop platform, hoping to get a pie of the big Data business chunk.  Its possibly a fair thing to expect that the leader in Data Integration business solutions space, Informatica has also announced a tie up with Cloudera, for porting Informatica platform to hadoop.

Though the exact details are yet to come out, the possibilities are endless.  With hadoop (and its inherent distributed computing based on map/reduce technology), informatica can actually think of processing big data in sustainable time frames.

For one my customers, I deal with about 200 million rows of data per day in one job.  Besides the issues with oracle in tuning the query etc, the informatica component itself consumes times in terms of hours.  With map reduce in place, I hope to get that in minutes, oracle issues notwithstanding.

Although word about hadoop is spreading quite fast, its adoption (from buzzword to actual usage in enterprise) is not as fast.  To aid their cause, Informatica and cloudera have started an interesting series of webinars, termed as "hadoop tuesdays".  Its free to join, and they get experts to talk about various related issues around hadoop and big data and informatica.  Its been very useful and informative so far.