Gobblin is a universal ingestion framework. It's goal is to pull data from any source into an arbitrary data store. One major use case for Gobblin is pulling data into Hadoop. Gobblin can pull data from file systems, SQL stores, and data that is exposed by a REST API. See the Gobblin Home page for more information.
Gobblin currently only supports Java 6 and up.
The machine that Gobblin is built on must have Java installed, and the
$JAVA_HOME environment variable must be set.
Gobblin can run on both Hadoop 1.x and Hadoop 2.x. By default, Gobblin compiles against Hadoop 1.2.1, and can compiled against Hadoop 2.3.0 by running
./gradlew -PuseHadoop2 clean build.
Check out the [Deployment](Gobblin Deployment) page for information on how to run and schedule Gobblin jobs. Check out the [Configuration](Configuration Properties Glossary) page for information on how to set proper configuration properties for a job.
Sqoop main focus bulk import and export of data from relational databases to HDFS, it lacks the ETL functionality of data cleansing, data transformation, and data quality checks that Gobblin provides. Gobblin is also capable of pulling from any data source (e.g. file systems, RDMS, REST APIs).
Gobblin currently uses Hadoop map tasks as a container for running Gobblin tasks. Each map task runs 1 or more Gobblin workunits, and the progress of each workunit is not hooked into the progress of each map task. Even though the Hadoop job reports 100% completion, Gobblin is still doing work. See the [Gobblin Deployment](Gobblin Deployment) page for more information.
Gobblin takes all WorkUnits created by the Source class and serializes each one into a file on Hadoop. These files are read by each map task, and are deserialized into Gobblin Tasks. These Tasks are then run by the map-task. The reason the job stalls is that Gobblin is writing all these files to HDFS, which can take a while especially if there are a lot of tasks to run. See the [Gobblin Deployment](Gobblin Deployment) page for more information.
This error typically occurs due to Hadoop version conflict issues. If Gobblin is compiled against a specific Hadoop version, but then deployed on a different Hadoop version or installation, this error may be thrown. For example, if you simply compile Gobblin using
./gradlew clean build -PuseHadoop2, but deploy Gobblin to a cluster with CDH installed, you may hit this error.
It is important to realize that the the
gobblin-dist.tar.gz file produced by
./gradlew clean build will include all the Hadoop jar dependencies; and if one follows the MR deployment guide, Gobblin will be launched with these dependencies on the classpath.
To fix this take the following steps:
HADOOP_CLASSPATHis set and points to a directory containing the Hadoop libraries for the cluster
Cloudera Distributed Hadoop (often abbreviated as CDH) is a popular Hadoop distribution. Typically, when running Gobblin on a CDH cluster it is recommended that one also compile Gobblin against the same CDH version. Not doing so may cause unexpected runtime behavior. To compile against a specific CDH version simply use the
hadoopVersion parameter. For example, to compile against version
./gradlew clean build -PuseHadoop2 -PhadoopVersion=2.5.0-cdh5.3.0.
IOException: Not all tasks running in mapper attempt_id completed successfully
This exception usually just means that a Hadoop Map Task running Gobblin Tasks threw some exception. Unfortunately, the exception isn't truly indicative of the underlying problem, all it is really saying is that something went wrong in the Gobblin Task. Each Hadoop Map Task has its own log file and it is often easiest to look at the logs of the Map Task when debugging this problem. There are multiple ways to do this, but one of the easiest ways is to execute
yarn logs -applicationId <application ID> [OPTIONS]
-x test to build the project without running the tests; this will make the exception go away. If one needs to run the tests then make sure Java Cryptography Extension is installed.
Say I want to add
oozie-core-4.2.0.jar as a dependency to the
gobblin-scheduler subproject. I would first open the file
build.gradle and add the following entry to the
Then in the
gobblin-scheduler/build.gradle file I would add the following line to the dependency block:
Often times, one may have important artifacts stored in a local or private Maven repository. As of 01/21/2016 Gobblin only pulls artifacts from the following Maven Repositories: Maven Central, Conjars, and Cloudera.
In order to add another Maven Repository modify the
defaultEnvironment.gradle file and the new repository using the same pattern as the existing ones.