Revolutions

A modern database interface for R

At the useR! conference last month, Jim Hester gave a talk about two packages that provide a modern database interface for R. Those packages are the odbc package (developed by Jim and other members of the RStudio team), and the DBI package (developed by Kirill Müller with support from the R Consortium).

To communicate with databases, a common protocol is ODBC. ODBC is an open, cross-platform standard for interfacing with databases, whatever the database software and variant of the SQL language it implements. R has long had the RODBC package created by Brian Ripley, but the new odbc package provides an updated alternative.

The odbc package is a from-the-ground-up implementation of an ODBC interface for R that provides native support for additional data types (including dates, timestamps, raw binary, and 64-bit integers) and parameterized queries. The odbc package provides connections with any ODBC-compliant database, and has been comprehensively tested on SQL Server, PostgreSQL and MySQL. Benchmarks show that it's also somewhat faster than RODBC: 3.2 times faster for reads, and 1.9 times faster for writes.

With the odbc package (and the DBI package, which provides low-level connectivity to the database), you create a database connection like this:

con <- dbConnect( ... ) # provide server, username, password

With the connection established, you can the use functions like dbListTables (get a list of tables in the database), dbReadTable (return the data from a table), and dbGetQuery (execute a SQL query in the database, and return the results). That's pretty standard stuff. But the real power comes in being able to use high-level functions from the dplyr package and have the data processing run in the database, instead of in the local R session.

When the dbplyr package is installed, you can create a "tibble" from a database connection, like this:

salesdata <- tbl(con, "ussales")

It doesn't matter how big the ussales table is, because no data is brought into R until you perform an operation on the salesdata object. For example, you can use a dplyr pipe to get the first 20 records from the state of California, like this:

tabledata %>% filter(state == "CA") %>% head(20)

Behind the scenes, this creates a SQL query (which you can inspect with the show_query function, if you like) to move the computation from within R to the database. This process works for all the dplyr verbs: filter becomes WHERE, left_join becomes LEFT JOIN, group_by becomes BY, etc. In every case (including the example above) all the filtering happens in the database, and only 20 rows of data are actually returned to R. 

You can see all of this in action in Jim's talk embedded below. (Jim's slides are also available here.) In the demo starting at the 8:20 mark, Jim connects to SQL Server (here running in a VM on his laptop, in non-demo situations more likely to be on a remote machine). You'll then see him query tables on the database, and perform dplyr operations on the data in the process. You'll even get a lesson on the importance of sanitizing user inputs to prevent SQL injection, and a solution based on parameterized queries. 

The odbc package is built on top of the DBI package, which provides a low-level interface to databases and some of the functions used in Jim's demo above. The DBI package has been around for a while, but has recently undergone a major upgrade thanks to Kirill Müller and funding from the R Consortium. If you're interested in the implementation of the DBI package and how it's evolving, check out Kirill's talk from useR! 2017: Improving DBI.

The odbc and DBI packages are available on CRAN now. To use them with your database, you'll also need an ODBC driver installed on the local machine. Most likely you already have one (Windows includes an ODBC driver compatible with SQL Server, for example), but if not RStudio provides a useful guide to finding ODBC drivers (which also come bundled with commercial RStudio products). 

Channel9: odbc - A modern database interface

The R6 Class System

R is an object-oriented language with several object-orientation systems. There's the original (and still widely-used) S3 class system based on the "class" attribute. There's the somewhat stricter, signature-based S4 class system. There are reference classes (also called R5), which provide R objects with multiple references without duplicating data in memory. And now there's the R6 class system, implemented as an R package by Winston Chang,

So why yet another class system for R? As Winston explains in his useR!2017 talk embedded below, the S3 and S4 class systems are functional object-oriented systems, where class methods are separate from objects, and objects are not mutable (that is, they can't be modified directly by methods; you have to assign modified values to the object directly). The R6 system, by contrast, is an encapsulated object oriented system akin to those in Java or C++, where objects contain methods in addition to data, and those methods can modify objects directly. 

The big advantage of R6 is that it makes it much easier to implement some common data structures in a user-friendly manner. For example, to implement a stack "pop" operation in S3 or S4 you have to do something like this:

x <- topval(mystack)
mystack <- remove_top(mystack)

In R6, the implementation is much simpler to use:

x <- mystack$pop()

That single statement both returns the top value (as x) from the stack mystack, but also modifies the stack in the process (minus the popped element).

Despite being first released over 3 years ago, the R6 isn't widely known. It is widely used, however: it's used to manage session state in Shiny and mrsdeploy, to manage database connections in dplyr, and to represent system processes in the processx package. In fact, the R6 package is the most downloaded CRAN package, according according to Rdocumentation Trends.

The R6 package is available on CRAN, and it also comes pre-installed in Microsoft R. If you'd like to start using R6, the vignette Introduction to R6 Classes is a great place to start. You can also check out the development of R6 at the R6 Github repository.

Syberia: A development framework for R code in production

Putting R code into production generally involves orchestrating the execution of a series of R scripts. Even if much of the application logic is encoded into R packages, a run-time environment typically involves scripts to ingest and prepare data, run the application logic, validate the results, and operationalize the output. Managing those scripts, especially in the face of working with multiple R versions, can be a pain — and worse, very complex scripts are difficult to understand and reuse for future applications.

That's where Syberia comes in: an open-source framework created by Robert Krzyzanowski and other engineers at the consumer lending company Avant. There, Syberia has been used by more than 30 developers to build a production data modeling system. In fact, building production R systems was the motivating tenet of Syberia: 

Developing classifiers using the Syberia modeling engine follows one primary tenet: development equals production. When a web developer experiments with a new website layout or feature, they are targeting a production system. After they are satisfied with their work, they push a button and deploy the code base so it is live and others can interact with it.

Feature engineering and statistical modeling ... should belong to the same class of work. When an architect designs a skyscraper their work has to be translated to reality through a construction team by replaying the design using a physical medium. This is the current industry standard for machine learning: prototype the model in one language, typically a Python or R "notebook," and then write it in a "solid production-ready" language so it can survive the harsh winds of the real world.

This is wrong.

In much the same way that ggplot2 is a completely different way of thinking about R graphics, Syberia is a completely different way of thinking about R scripts. It's also similarly difficult to get your head around at first, but once you do, it reveals itself as an elegant and customizable way of managing complex and interconnected R code — and a much better solution than simply source-ing an 800-line R script.

At its core, Syberia defines a set of conventions for defining the steps in a data-analysis workflow, and specifying them with a collection (in real-world projects, a large collection) of small R scripts in a standardized folder structure. Collectively, these define the complete data analysis process, which you can execute with a simple R command: run. To make modifying and maintaining this codebase (which you'd typically manage in a source-code control system) easier, Syberia is designed to isolate dependencies between filew. For example, rather than specifying a file name and format (say, "data.csv") in a script that reads data, you'd instead define "adapters" to read and write data in the adapters/adapters.R script:

# ./adapters/csv.R
read <- function(key) {
  read.csv(file.path("/some/path", paste0(key, ".csv")))
}

write <- function(value, key) {
  write.csv(value, file.path("/some/path", paste0(key, ".csv")))
}

Syberia will then use those "read" and "write" adapters to connect with your data. That way, when you later decide to source the data from a database, you can just write new adapters rather than trying to find the lines dealing with data I/O in a massive script. (This also helps avoid conflicts when working in a large code-base with multiple developers.) Syberia defines similar "patterns" for data preparation (including feature generation), statistical modeling, and testing; the "run" function conceptually synthesizes the entire codebase into a single R script to run.

Syberia also encourages you to break up your process into a series of distinct steps, each of which can be run (and tested) independently. It also has a make-like feature, in that results from intermediate steps are cached, and do not need to be re-run each time unless their dependencies have been modified.

Syberia can also be used to associate specific R versions with scripts, or even other R engines like Microsoft R. I was extremely impressed when during a 30-minute-break at the R/Finance conference last month, Robert was able to sketch out a Syberia implementation of a modeling process using the RevoScaleR library. In fact Robert's talk from the conference, embedded below, provides a nice introduction to Syberia.

Syberia is available now under the open-source MIT license. (Note: git is required to install Syberia.) To get started with Syberia check out the documentation, which is available at the Syberia website linked below.

Syberia: The development framework for R

Interfacing with APIs using R: the basics

While R (and its package ecosystem) provides a wealth of functions for querying and analyzing data, in our cloud-enabled world there's now a plethora of online services with APIs you can use to augment R's capabilities. Many of these APIs use a RESTful interface, which means you will typically send/receive data encoded in the JSON format using HTTP commands.

Fortunately, as Steph Locke explains in her most recent R Quick tip, the process is pretty simple using R:

1. Obtain an authentication key for using the service 
2. Find the URL of the API service you wish to use
3. Convert your input data to JSON format using toJSON in the jsonlite package
4. Send your data to the API service using the POST function in the httr package. Include your API key using the add_headers function
5. Extract your results from the API response using the fromJSON function

Steph provides an example of detecting text language using the Microsoft Cognitive Services Text Analytics API, but that basic recipe should work for most APIs. (API keys for other Microsoft Cognitive Services APIs for vision, speech, language, knowledge and search are also available for free use with your Github account.) There many APIs available for use around the web, and this list of public APIs maintained by Abhishek Banthia is also a useful resource.

Locke Data: R Quick tip: Microsoft Cognitive Services’ Text Analytics API

 

 

New features in the checkpoint package, version 0.4.0

by Andrie de Vries

In 2014 we introduced the checkpoint package for reproducible research. This package makes it easy to use R package versions that existed on CRAN at a given date in the past, and to use varying package versions with different projects. Previous blog posts include:

• Introducing the Reproducible R Toolkit and the checkpoint package
• An update to the checkpoint package
• New features in checkpoint v0.3.15 now on CRAN

On April 12, 2017, we published version 0.4.0 of checkpoint to CRAN.

The checkpoint() function enables reproducible research by managing your R package versions. These packages are downloaded into a local .checkpoint folder. If you use checkpoint() for many projects, these local packages can consume some storage space, and this update introduces functions to manage your snapshots. In this post I review:

• Managing local archives:
  • checkpointArchives(): list checkpoint archives on disk.
  • checkpointRemove(): remove checkpoint archive from disk.
  • getAccessDate(): returns the date the snapshot was last accessed.
• Other:
  • unCheckpoint(): reset .libPaths to the user library to undo the effect of checkpoint().

Setting up an example project

For illustration, set up a script referencing a single package:

library(MASS)
hist(islands)
truehist(islands)

Next, create the checkpoint:

dir.create(file.path(tempdir(), ".checkpoint"), recursive = TRUE)
## Create a checkpoint by specifying a snapshot date
library(checkpoint)
checkpoint("2015-04-26", project = tempdir(), checkpointLocation = tempdir())

Working with checkpoint archive snapshots

You can query the available snapshots on disk using the checkpointArchives() function. This returns a vector of snapshot folders.

# List checkpoint archives on disk.
checkpointArchives(tempdir())

## [1] "2015-04-26"

You can get the full paths by including the argument full.names=TRUE:

checkpointArchives(tempdir(), full.names = TRUE)

## [1] "C:/Users/adevries/AppData/Local/Temp/RtmpcnciXd/.checkpoint/2015-04-26"

Working with access dates

Every time you use checkpoint() the function places a small marker in the snapshot archive with the access date. In this way you can track when was the last time you actually used the snapshot archive.

# Returns the date the snapshot was last accessed.
getAccessDate(tempdir())

## C:/Users/adevries/AppData/Local/Temp/RtmpcnciXd/.checkpoint/2015-04-26 
##                                                           "2017-04-12"

Removing a snapshot from local disk

Since the date of last access is tracked, you can use this to manage your checkpoint archives. The function checkpointRemove() will delete archives from disk. You can use this function in multiple ways. For example, specify a specific archive to remove:

# Remove singe checkpoint archive from disk.
checkpointRemove("2015-04-26")

You can also remove a range of snapshot archives older (or more recent) than a snapshot date

# Remove range of checkpoint archives from disk.
checkpointRemove("2015-04-26", allSinceSnapshot = TRUE)
checkpointRemove("2015-04-26", allUntilSnapshot =  = TRUE)

Finally, you can remove all snapshot archives that have not been accessed since a given date:

# Remove snapshot archives that have not been used recently
checkpointRemove("2015-04-26", notUsedSince = TRUE)

Reading the checkpoint log file

One of the side effects of checkpoint() is to create a log file that contains information about packages that get downloaded, as well as the download size. This file is stored in the checkpoint root folder, and is a csv file with column names, so you can read this with your favourite R function or other tools.

dir(file.path(tempdir(), ".checkpoint"))

## [1] "2015-04-26"         "checkpoint_log.csv" "R-3.3.3"

Inspect the log file:

log_file 

##             timestamp snapshotDate  pkg   bytes
## 1 2017-04-12 15:05:12   2015-04-26 MASS 1084392

Resetting the checkpoint

In older versions of checkpoint() the only way to reset the effect of checkpoint() was to restart your R session. In v0.3.20 and above, you can use the function unCheckpoint(). This will reset your .libPaths to the user folder.

.libPaths()

## [1] "C:/Users/adevries/AppData/Local/Temp/RtmpcnciXd/.checkpoint/2015-04-26/lib/x86_64-w64-mingw32/3.3.3"
## [2] "C:/Users/adevries/AppData/Local/Temp/RtmpcnciXd/.checkpoint/R-3.3.3"                                
## [3] "C:/R/R-33~1.3/library"

Now use `unCheckpoint()` to reset your library paths

# Note this is still experimental
unCheckpoint()
.libPaths()

## [1] "C:\\Users\\adevries\\Documents\\R\\win-library"
## [2] "C:/R/R-33~1.3/library"

How to obtain and use checkpoint

Version 0.4.0 of the checkpoint package is available on CRAN now, so you can install it with:

install.packages("checkpoint", repos="https://cloud.r-project.org")

The above command works both for CRAN R, and also for Microsoft R Open (which comes bundled with an older version of checkpoint). For more information on checkpoint, see the vignette Using checkpoint for reproducible research.

Running your R code on Azure with mrsdeploy

by John-Mark Agosta, data scientist manager at Microsoft

Let’s say you’ve built a model in R that is larger than you can conveniently run locally, and you want to take advantage of Azure’s resources simply to run it on a larger machine. This blog explains how to provision and run an Azure virtual machine (VM) for this, using the mrsdeploy library that comes installed with Microsoft’s R Server. We will work specifically with the Unbuntu Linux version of the VM, so I you’ll need to be familiar with working with superuser privileges at the command line in Linux, and of course, familiar with R.

The fundamental architecture consists of your local machine as the client for which you create a server machine in the Cloud. You’ll set up a service on the remote machine — the one in the cloud. Once you do this, you needn’t interact directly with the remote machine; instead you issue commands to it and see the results returned at the client. This is one approach; there are many many ways this can be done in Azure, depending on your choice of language, reliance on coding, capabilities of the service, and complexity and scale of the task. A data scientist typically works first interactively to explore data on an individual machine, then puts the model thus built into production at scale, in this example, in the Cloud. The purpose of this posting is to clarify the deployment process, or as it is called, in a mouthful, operationalization. In short, using a VM running the mrsdeploy library in R Server lets you operationalize your code with little effort, at modest expense.

Alternatively, instead of setting up a service with R server, one unadvisedly could just provision a an bare virtual machine, and login into it as one would any remote machine with the manual encumbrance of having to work with multiple machines, load application software, and move data and code back and forth. But that’s what we avoid. The point of the Cloud is making large data and compute as much as possible like working on your local computer.

Deploying Microsoft R Server (MRS) on an Azure VM

Azure Marketplace offers a Linux VM (Ubuntu version 16.04) preconfigured with R Server 2016. Additionally the Linux VM with R Server comes with mrsdeploy, a new R package for establishing a remote session in a console application and for publishing and managing a web service written in R. In order to use the R Server’s deployment and operationalization features, one needs to configure R Server for operationalization after installation, to act as a deployment server and host analytic web services.

Alternately there are other Azure platforms for operationalization using R Server in the Marketplace, with other operating systems and platforms including HDInsight, Microsoft’s Hadoop offering. Or, equivalently one could use the Data Science VM available in the Marketplace, since it has a copy of R Server installed. Configuration of these platforms is similar to the example covered in this posting.

• Microsoft R Server 2016 (version 9.0.1) for Linux (CentOS version 7.2)
• R Server Enterprise
• R Server for HDInsight

Provisioning an R Server VM, as reference in the documentation, takes a few steps that are detailed here, which consist of configuring the VM and setting up the server account to authorize remote access. To set up the server you’ll use the system account you set up as a user of the Linux machine. The server account is used for client interaction with the R Server, and should not be confused with the Linux system account. This is a major difference with the Windows version of the R Server VM that uses Active Directory services for authentication.

Provisioning a machine from the Marketplace

You will want to do the install of a Unbuntu Marketplace VM with R server preinstalled. The best way to find it on portal.azure.com is to search for “r server”:

Book Review: Testing R Code

When it comes to getting things right in data science, most of the focus goes to the data and the statistical methodology used. But when a misplaced parenthesis can throw off your results entirely, ensuring correctness in your programming is just as important. A new book published by CRC Press, Testing R Code by Richard (Richie) Cotton, provides all the guidance you’ll need to write robust, correct code in the R language.

This is not a book exclusively for package developers: data science, after all, is a combination of programming and statistics, and this book provides lots of useful advice on helping to ensure the programming side of things is correct. The book suggests you begin by using the assertive package to provide alerts when your code runs off the rails. From there, you can move on to creating formal unit tests as you code, using the testthat package. There's also a wealth of useful advice for organizing and writing code that's more maintainable in the long run.

If you are a package developer, there's lots here for you too. There are detailed instructions on incorporating unit tests into your package, and how tests interact with version control and continuous integration systems. It also touches on advanced topics relevant to package authors, like debugging C or C++ code embedded via the Rcpp package. And there's more good advice, like how to write better error messages so your users can recover more easily when an error does occur.

Testing is a topic that doesn't get as much attention as it deserves in data science disciplines. One reason may be that it's a fairly dry topic, but Cotton does a good job in making the material engaging with practical examples and regular exercises (with answers in the appendix). Frequent (and often amusing) footnotes help make this an entertaining read (given the material) and hopefully will motivate you to make testing a standard (and early) part of your R programming process. 

Testing R Code is available from your favorite bookseller now, in hardback and electronic formats.

 

Git Gud with Git and R

If you're doing any kind of in-depth programming in the R language (say, creating a report in Rmarkdown, or developing a package) you might want to consider using a version-control system. And if you collaborate with another person (or a team) on the work, it makes things infinitely easier when it comes to coordinating changes. Amongst other benefits, a version-control system:

• Saves you from the worry of making irrevocable changes. Instead of keeping multiple versions of files around (are filenames like Report.Rmd; Report2.Rmd; Report-final.Rmd; Report-final-final.Rmd familiar?) you just keep the latest version of the file, knowing that the older versions are accessible should you need them.
• Keeps a remote backup of your files. If you accidentally delete a critical file, you can retrieve it. If your hard drive crashes, it's easy to restore the project.
• Makes it easy to work with others. Multiple people can work on the same file at the same time, and it's (relatively) easy to keep changes in sync.
• Relatedly, it makes it easy to get a collaborator. Even if your project is currently a solo effort, you may want to get help in the future, and a version-control system makes it easy to add project members. If it's an open-source project, you might even get contributions from people you don't know!

There are many version control systems out there, but a popular one is Git. You've possibly interacted with projects (especially R packages) managed under Git on Github, the online version of Git. And while you can get a fair bit done just with your browser and GitHub, the real power comes by installing Git on your desktop. Using git's command-line interface is a bear (here's a fake, but representative example of the documentation), but fortunately RStudio and RTVS provide interfaces that make things much easier. 

If you want to get started with Git and RStudio, Jenny Bryan has provided an excellent guide to setting up your system and using version control: Happy Git and Gitgub for the R User. The guide is quite long and detailed, but fear not: the pace is brisk, and provides everything you need to get going. During a two-hour workshop that Jenny presented at the RStudio conference, I was able to install Git for Windows, configure it with my GitHub credentials, connect it to RStudio, commit changes to an existing R package, and create and share my own repository. It's easier than you think! Just start with the link below, and work your way through the sections.

Jenny Bryan:  Happy Git and Gitgub for the R User

The Flexibility of Remote and Local R Workspaces

by Sean Wells, Senior Software Engineer, Microsoft

The mrsdeploy R package facilitates Remote Execution and Web Service interactions from your local R IDE command line against a remote Microsoft R Server instance. Both core features can be used independently of one another or combined to support different convenient workflows. These different workflows composed together can produce some creative R development and operationalization solutions.

mrsdeploy comes bundled with installations of Microsoft R Client and Microsoft R Server.

Before using any mrsdeploy API you must first authenticate against the R Server and before we authenticate we should become familiar with the different authentication approaches and their supported arguments. Currently, there are two ways to authenticate:

• remoteLogin() using an on premises Active Directory server on your network:

remoteLogin(
   endpoint, 
   session = TRUE, 
   diff = TRUE,
   commandline = TRUE, 
   username = NULL,
   password = NULL
)

• remoteLoginAAD() using Azure Active Directory in the cloud:

remoteLoginAAD(
   endpoint,
   authuri = NULL,
   tenantid = NULL,
   clientid = NULL,
   resource = NULL,
   session = TRUE,
   diff = TRUE,
   commandline = TRUE
)

Both APIs are equivalent in that they provide the means to authenticate against a Microsoft R Server instance. Take special note of the arguments session and commandline:

Argument	Description
session	If TRUE, create a remote session.
commandline	If TRUE, creates a REMOTE command line in the R console. REMOTE command line is used to interact with the remote R session. Parameter is only valid if session parameter is TRUE.

These two parameters are subtle yet can produce bold context switches from your local R workspace. Depending on their values, you can end up in one of three post authentication command line states in the R console:

State 1 - Remote Command Line

Authenticate, create a remote R session, and transition to the remote REPL command line. The default prompt REMOTE> indicates you are now interacting with your remote R session and are no longer in your local R environment:

# Taking the default arguments (session = TRUE, commandline = TRUE)
> remoteLogin("http://localhost:12800")
REMOTE>

State 2 - Local Command Line

Authenticate, create a remote R session, and remain in your local R environment:

> remoteLogin("http://localhost:12800", session = TRUE, commandline = FALSE)
>

State 3 - Local Command Line No remote session

Authenticate, do not create a remote R session, and remain in your local R environment:

> remoteLogin("http://localhost:12800", session = FALSE)
>

Now that we understand the different authentication scenarios and their arguments we can begin to compose them together with other supported functions. The mrsdeploy package provides many convenience functions to aid workflow from the R IDE command line. Listed below are a few that deal with context switching between your local and remote sessions post authentication:

Argument	Description
pause	When executed from the remote R session, returns the user to the local > command prompt.
resume	When executed from the local R session, returns the user to the REMOTE> command prompt, and sets a remote execution context.
putLocalObject	Puts an object from the workspace of the local R session and loads it into the workspace of the remote R session.

See the documentation for a full list of supported functions.

Expanding on State 1 as shown above, here we define an interactive authentication workflow that spans both our local and remote environments.

The same outcome can be achieved with State 2’s authentication workflow as it differs only in the R environment order. Here we start out in the local R session then move to the remote R session.

Finally, State 3’s workflow demonstrates authentication without a remote R session being created session = FALSE. This is useful if the intention is to only work with the Web Service functionality of the mrsdeploy package. Here we authenticate and remain confined within our local R session in order to publish and consume a service.

Note Web Service management can only occur locally. Attempting to use the service APIs during remote interaction REMOTE> will result in a error.

Feedback

I am interested in seeing what people build. If you have any feedback on the above approach or the mrsdeploy package in general, please leave a comment below.

Happy New Year!

How to call Cognitive Services APIs with R

Microsoft Cognitive Services is a set of cloud-based machine-intelligence APIs that you can use to extract structured data from complex sources (unstructured text, images, video and audio), and add "AI" type features to applications. A good example is the "Seeing AI" glasses in the video below: the image descriptions, emotion inference, and text recognition are all driven by Cognitive Services APIs.

You can call these APIs from any application, including R. Here are a few examples:

• In a blog post a few months back, I called the Face API from R to determine the apparent gender of programmers according to their GitHub avatar.
• The Economist used the Emotion API to track the emotions of the US presidential candidates during the debates.
• Shohbit at the Big Data Enthusiast blog used the Text Analytics API to chart the sentiment of tweets from the candidates.

There's no official R package (yet!) for calling Cognitive Services APIs. But since every Cognitive Service API is just a standard REST API, we can use the httr package to call the API. Input and output is standard JSON, which we can create and extract using the jsonlite package.

(There's also an independent R interface to the text APIs. And there are already Python SDKs for many of the services, including the Face API.)

Shohbit has also published a step-by-step guide to calling Cognitive Services APIs from R, with several examples of using the Text Analytics API. The details are at the link below. To get started, all you'll need is to register for a Cognitive Services API key. Rate-limited keys (more than enough to test out the service) are free, and you can register using your GitHub account.

Big Data Enthusiast: Microsoft Cognitive Services (Text Analytics API) in R