It’s a sad but true fact: Most
data scientists spend 50-80% of their time cleaning and munging data and only a fraction of their time actually building predictive models.
This is most often true in a traditional stack, where most of this data munging consists of
writing lines upon lines of some flavor of SQL, leaving little time for model-building code in statistical programming languages such as
R. These long, cryptic SQL queries not only slow development time but also prevent useful collaboration on analytics projects, as contributors struggle to understand each others’ SQL code.
For example, in graduate school, I was on a project team where we used Oracle to store Twitter data. The kinds of queries my classmates and I were writing were unmaintainable and impossible to understand unless the author was sitting next to you. No one worked on the same queries together because they were so unwieldy.
This not only hindered our collaboration efforts but also slowed our progress on the project. If we had been using an appropriate data store (like
a graph database) we would have spent significantly less time pulling our hair out over the queries.
Why Today’s Data Is Different
This data-munging problem has persisted in the data science field because
data is becoming increasingly social and highly-connected.
Forcing this kind of interconnected data into an inherently tabular SQL database, where relationships are only abstract, leads to complicated schemas and overly complex queries. Yet, several NoSQL solutions – specifically in
the graph database space – exist to store today’s highly-connected data. That is,
data where relationships matter.
A lot of data analysis today is performed in the context of better understanding people’s behavior or needs, such as:
- How likely is this visitor to click on advertisement X?
- Which products should I recommend to this user?
- How are User A and User B connected?
People, as we know, are inherently social, so most of these questions can be answered by understanding the connections between people: User A is similar to User B, and we already know that User B likes this product, so let’s recommend this product to User A.
The Good News: Data-Munging No More
Data science doesn’t have to be 80% data munging. With the appropriate technology stack, a data scientist’s development process is seamless and short.
It’s time to
spend less time writing queries and more time building models by combining the flexibility of an open-source, NoSQL graph database with the maturity and breadth of R – an open-source statistical programming language.
The combination of Neo4j’s ability to store highly-connected, possibly-unstructured data and R’s functional, ad-hoc nature creates the ideal data analysis environment. You don’t have to spend an hour writing CREATE TABLE statements. You don’t have to spend all day on StackOverflow figuring out how to traverse a tree in SQL. Just
Cypher and go.
Learn More at OSCON 2015
At
my upcoming OSCON session we will walk through a project in which we analyze
#OSCON Twitter data in a reproducible, low-effort workflow without writing a single line of SQL.
For this highly-connected dataset we will use
Neo4j, an open-source graph database, to store and query the data while highlighting the advantages of
storing such data in a graph versus a relational schema. Finally, we will cover how to connect to Neo4j from an R environment for the purposes of performing common data science tasks, such as analysis, prediction and visualization.
Register for OSCON 2015 and learn more about my upcoming session here.
Want to dig deeper into graph databases for data science projects? Learn everything you need to know about graph technologies with the O’Reilly’s Graph Databases ebook. Click below to get your free copy of the definitive book on graph databases and your introduction to Neo4j.
It’s a sad but true fact: Most data scientists spend 50-80% of their time cleaning and munging data and only a fraction of their time actually building predictive models.
This is most often true in a traditional stack, where most of this data munging consists of writing lines upon lines of some flavor of SQL, leaving little time for model-building code in statistical programming languages such as R. These long, cryptic SQL queries not only slow development time but also prevent useful collaboration on analytics projects, as contributors struggle to understand each others’ SQL code.
For example, in graduate school, I was on a project team where we used Oracle to store Twitter data. The kinds of queries my classmates and I were writing were unmaintainable and impossible to understand unless the author was sitting next to you. No one worked on the same queries together because they were so unwieldy.
This not only hindered our collaboration efforts but also slowed our progress on the project. If we had been using an appropriate data store (like a graph database) we would have spent significantly less time pulling our hair out over the queries.
