Author: Erin LeDell
Contact: erin@h2o.ai
This tutorial steps through a quick introduction to H2O's R API. The goal of this tutorial is to introduce through a complete example H2O's capabilities from R.
Most of the functionality for R's data.frame is exactly the same syntax for an H2OFrame, so if you are comfortable with R, data frame manipulation will come naturally to you in H2O. The modeling syntax in the H2O R API may also remind you of other machine learning packages in R.
References: H2O R API documentation, the H2O Documentation landing page and H2O general documentation.
This tutorial assumes you have R installed. The h2o R package has a few dependencies which can be installed using CRAN. The packages that are required (which also have their own dependencies) can be installed in R as follows:
pkgs <- c("methods","statmod","stats","graphics","RCurl","jsonlite","tools","utils")
for (pkg in pkgs) {
if (! (pkg %in% rownames(installed.packages()))) { install.packages(pkg) }
}
Once the dependencies are installed, you can install H2O. We will use the latest stable version of the h2o R package, which at the time of writing is H2O v3.8.0.4 (aka "Tukey-4"). The latest stable version can be installed using the commands on the H2O R Installation page.
In [2]:
library(h2o)
# Start an H2O Cluster on your local machine
h2o.init(nthreads = -1) #nthreads = -1 uses all cores on your machine
If you already have an H2O cluster running that you'd like to connect to (for example, in a multi-node Hadoop environment), then you can specify the IP and port of that cluster as follows:
In [2]:
# This will not actually do anything since it's a fake IP address
# h2o.init(ip="123.45.67.89", port=54321)
The following code downloads a copy of the EEG Eye State dataset. All data is from one continuous EEG measurement with the Emotiv EEG Neuroheadset. The duration of the measurement was 117 seconds. The eye state was detected via a camera during the EEG measurement and added later manually to the file after analysing the video frames. '1' indicates the eye-closed and '0' the eye-open state. All values are in chronological order with the first measured value at the top of the data.
We can import the data directly into H2O using the import_file method in the Python API. The import path can be a URL, a local path, a path to an HDFS file, or a file on Amazon S3.
In [3]:
#csv_url <- "http://www.stat.berkeley.edu/~ledell/data/eeg_eyestate_splits.csv"
csv_url <- "https://h2o-public-test-data.s3.amazonaws.com/eeg_eyestate_splits.csv"
data <- h2o.importFile(csv_url)
In [4]:
dim(data)
Out[4]:
Now let's take a look at the top of the frame:
In [5]:
head(data)
Out[5]:
The first 14 columns are numeric values that represent EEG measurements from the headset. The "eyeDetection" column is the response. There is an additional column called "split" that was added (by me) in order to specify partitions of the data (so we can easily benchmark against other tools outside of H2O using the same splits). I randomly divided the dataset into three partitions: train (60%), valid (%20) and test (20%) and marked which split each row belongs to in the "split" column.
Let's take a look at the column names. The data contains derived features from the medical images of the tumors.
In [6]:
names(data)
Out[6]:
To select a subset of the columns to look at, typical R data.frame indexing applies:
In [9]:
columns <- c('AF3', 'eyeDetection', 'split')
head(data[columns])
Out[9]:
Now let's select a single column, for example -- the response column, and look at the data more closely:
In [10]:
y <- 'eyeDetection'
data[y]
Out[10]:
It looks like a binary response, but let's validate that assumption:
In [12]:
h2o.unique(data[y])
Out[12]:
If you don't specify the column types when you import the file, H2O makes a guess at what your column types are. If there are 0's and 1's in a column, H2O will automatically parse that as numeric by default.
Therefore, we should convert the response column to a more efficient "factor" representation (called "enum" in Java) -- in this case it is a categorial variable with two levels, 0 and 1. If the only column in my data that is categorical is the response, I typically don't bother specifying the column type during the parse, and instead use this one-liner to convert it aftewards:
In [14]:
data[y] <- as.factor(data[y])
Now we can check that there are two levels in our response column:
In [17]:
h2o.nlevels(data[y])
Out[17]:
We can query the categorical "levels" as well ('0' and '1' stand for "eye open" and "eye closed") to see what they are:
In [18]:
h2o.levels(data[y])
Out[18]:
We may want to check if there are any missing values, so let's look for NAs in our dataset. For all the supervised H2O algorithms, H2O will handle missing values automatically, so it's not a problem if we are missing certain feature values. However, it is always a good idea to check to make sure that you are not missing any of the training labels.
To figure out which, if any, values are missing, we can use the h2o.nacnt (NA count) method on any H2OFrame (or column). The columns in an H2O Frame are also H2O Frames themselves, so all the methods that apply to an H2OFrame also apply to a single column.
In [23]:
h2o.nacnt(data[y])
Out[23]:
Great, no missing labels. :-)
Out of curiosity, let's see if there is any missing data in any of the columsn of this frame:
In [24]:
h2o.nacnt(data)
Out[24]:
Each column returns a zero, so there are no missing values in any of the columns.
The next thing I may wonder about in a binary classification problem is the distribution of the response in the training data. Is one of the two outcomes under-represented in the training set? Many real datasets have what's called an "imbalanace" problem, where one of the classes has far fewer training examples than the other class. Let's take a look at the distribution:
In [25]:
h2o.table(data[y])
Out[25]:
Ok, the data is not exactly evenly distributed between the two classes -- there are more 0's than 1's in the dataset. However, this level of imbalance shouldn't be much of an issue for the machine learning algos. (We will revisit this later in the modeling section below).
Let's calculate the percentage that each class represents:
In [26]:
n <- nrow(data) # Total number of training samples
h2o.table(data[y])['Count']/n
Out[26]:
So far we have explored the original dataset (all rows). For the machine learning portion of this tutorial, we will break the dataset into three parts: a training set, validation set and a test set.
If you want H2O to do the splitting for you, you can use the split_frame method. However, we have explicit splits that we want (for reproducibility reasons), so we can just subset the Frame to get the partitions we want.
Subset the data H2O Frame on the "split" column:
In [28]:
train <- data[data['split']=="train",]
nrow(train)
Out[28]:
In [29]:
valid <- data[data['split']=="valid",]
nrow(valid)
Out[29]:
In [30]:
test <- data[data['split']=="test",]
nrow(test)
Out[30]:
In the steps above, we have already created the training set and validation set, so the next step is to specify the predictor set and response variable.
As with any machine learning algorithm, we need to specify the response and predictor columns in the training set.
The x argument should be a vector of predictor names in the training frame, and y specifies the response column. We have already set y <- "eyeDetector" above, but we still need to specify x.
In [32]:
names(train)
Out[32]:
In [35]:
x <- setdiff(names(train), c("eyeDetection", "split")) #Remove the 13th and 14th columns
x
Out[35]:
Now that we have specified x and y, we can train the GBM model using a few non-default model parameters. Since we are predicting a binary response, we set distribution = "bernoulli".
In [37]:
model <- h2o.gbm(x = x, y = y,
training_frame = train,
validation_frame = valid,
distribution = "bernoulli",
ntrees = 100,
max_depth = 4,
learn_rate = 0.1)
The type of results shown when you print a model, are determined by the following:
training_frame only, training_frame and validation_frame, or training_frame and nfolds)Below, we see a GBM Model Summary, as well as training and validation metrics since we supplied a validation_frame. Since this a binary classification task, we are shown the relevant performance metrics, which inclues: MSE, R^2, LogLoss, AUC and Gini. Also, we are shown a Confusion Matrix, where the threshold for classification is chosen automatically (by H2O) as the threshold which maximizes the F1 score.
The scoring history is also printed, which shows the performance metrics over some increment such as "number of trees" in the case of GBM and RF.
Lastly, for tree-based methods (GBM and RF), we also print variable importance.
In [38]:
print(model)
Once a model has been trained, you can also use it to make predictions on a test set. In the case above, we just ran the model once, so our validation set (passed as validation_frame), could have also served as a "test set." We technically have already created test set predictions and evaluated test set performance.
However, when performing model selection over a variety of model parameters, it is common for users to train a variety of models (using different parameters) using the training set, train, and a validation set, valid. Once the user selects the best model (based on validation set performance), the true test of model performance is performed by making a final set of predictions on the held-out (never been used before) test set, test.
You can use the model_performance method to generate predictions on a new dataset. The results are stored in an object of class, "H2OBinomialMetrics".
In [39]:
perf <- h2o.performance(model = model, newdata = test)
class(perf)
Out[39]:
Individual model performance metrics can be extracted using methods like r2, auc and mse. In the case of binary classification, we may be most interested in evaluating test set Area Under the ROC Curve (AUC).
In [40]:
h2o.r2(perf)
Out[40]:
In [41]:
h2o.auc(perf)
Out[41]:
In [42]:
h2o.mse(perf)
Out[42]:
To perform k-fold cross-validation, you use the same code as above, but you specify nfolds as an integer greater than 1, or add a "fold_column" to your H2O Frame which indicates a fold ID for each row.
Unless you have a specific reason to manually assign the observations to folds, you will find it easiest to simply use the nfolds argument.
When performing cross-validation, you can still pass a validation_frame, but you can also choose to use the original dataset that contains all the rows. We will cross-validate a model below using the original H2O Frame which is called data.
In [43]:
cvmodel <- h2o.gbm(x = x, y = y,
training_frame = train,
validation_frame = valid,
distribution = "bernoulli",
ntrees = 100,
max_depth = 4,
learn_rate = 0.1,
nfolds = 5)
This time around, we will simply pull the training and cross-validation metrics out of the model. To do so, you use the auc method again, and you can specify train or xval as TRUE to get the correct metric.
In [44]:
print(h2o.auc(cvmodel, train = TRUE))
print(h2o.auc(cvmodel, xval = TRUE))
One way of evaluting models with different parameters is to perform a grid search over a set of parameter values. For example, in GBM, here are three model parameters that may be useful to search over:
ntrees: Number of treesmax_depth: Maximum depth of a treelearn_rate: Learning rate in the GBMWe will define a grid as follows:
In [45]:
ntrees_opt <- c(5,50,100)
max_depth_opt <- c(2,3,5)
learn_rate_opt <- c(0.1,0.2)
hyper_params = list('ntrees' = ntrees_opt,
'max_depth' = max_depth_opt,
'learn_rate' = learn_rate_opt)
The h2o.grid function can be used to train a "H2OGrid" object for any of the H2O algorithms (specified by the "algorithm" argument.
In [52]:
gs <- h2o.grid(algorithm = "gbm",
grid_id = "eeg_demo_gbm_grid",
hyper_params = hyper_params,
x = x, y = y,
training_frame = train,
validation_frame = valid)
In [53]:
print(gs)
By default, grids of models will return the grid results sorted by (increasing) logloss on the validation set. However, if we are interested in sorting on another model performance metric, we can do that using the h2o.getGrid function as follows:
In [56]:
# print out the auc for all of the models
auc_table <- h2o.getGrid(grid_id = "eeg_demo_gbm_grid", sort_by = "auc", decreasing = TRUE)
print(auc_table)
The "best" model in terms of validation set AUC is listed first in auc_table.
In [71]:
best_model <- h2o.getModel(auc_table@model_ids[[1]])
h2o.auc(best_model, valid = TRUE) #Validation AUC for best model
Out[71]:
The last thing we may want to do is generate predictions on the test set using the "best" model, and evaluate the test set AUC.
In [72]:
best_perf <- h2o.performance(model = best_model, newdata = test)
h2o.auc(best_perf)
Out[72]:
The test set AUC is approximately 0.97. Not bad!!