Welcome!

Recurring Revenue Authors: Elizabeth White, Liz McMillan, Pat Romanski, Yeshim Deniz, Zakia Bouachraoui

Related Topics: @DXWorldExpo, Recurring Revenue, @CloudExpo, Apache, SDN Journal

@DXWorldExpo: Blog Post

MySQL and Oracle into Hadoop By @Continuent | @CloudExpo [#BigData]

Underlying all the decisions of what part of Hadoop will use the data is how the data is stored

Replicating from MySQL and Oracle into Hadoop

The notion of a database silo - that is, a single database that contains everything and operates in isolation - is a rapidly fading concept in most companies. Many use multiple databases to take advantage of the different range of functionality, from their transactional store, to caching and session stores using NoSQL and, more recently, the transfer of information into analytical stores such as Hadoop.

This raises a problem when it comes to moving the data about. There are many different solutions available if all you want to do is move some data between systems through import and export. These are clumsy solutions, they can be scripted, but more usually you want to provide a regular stream of changes into Hadoop so that you can process and analyze the data as quickly as possible. In this article, we'll examine the traditional dump and load solutions and look at a solution that enables real-time replication of data from MySQL and Oracle into Hadoop.

Hadoop Imports
Ignoring just for the moment where the data will come from, before we start doing any kind of import into Hadoop you need to think about how the data will be used and accessed on the Hadoop side. The temptation is to ignore the destination format and information, but this can lead to long-term problems in terms of understanding the data and processing it effectively.

Underlying all the decisions of what part of Hadoop will use the data is how the data is stored. Within Hadoop, data is written into the HDFS file system. HDFS stores data across your Hadoop cluster by first dividing up the file by the configured block size, and second by providing replicas of these blocks across the cluster. These replicas serve two purposes:

  • They enable faster and more easily distributed processing. With multiple copies, there are multiple nodes that can process the local copy of the data without having to copy it around the cluster at the time of processing.
  • They provide high availability, by allowing a single node in the cluster to fail without you losing access to the data it stores.

Ultimately this leads to the first key parameter for data loading into Hadoop - larger files are better. The larger the file, the more blocks it will be divided into, the more it will be distributed. Ergo, the faster it will be to process across the cluster as multiple nodes are able to work on each block individually.

When it comes to the actual file format, in most cases, Hadoop is designed to work with fairly basic textual data. Rather than the complicated binary formats that traditional databases use, Hadoop is just as happy to process CSV or JSON-based information.

One of the many benefits of Hadoop and the HDFS system is that the distributed nature makes it easy to parse and understand a variety of formats. In general, you are better off writing to a simpler format, such as CSV, that can then be parsed and used by multiple higher-level interfaces, like Hive or Impala. This sounds counter-intuitive, but native binary representations when processed in a distributed fashion often complicate the process of ingesting the data.

So with that in mind, we can generate some simple data to be loaded into Hadoop from our traditional database environment by generating a simple CSV file.

Simple Export
There are many different ways in which you can generate CSV files in both Oracle and MySQL. In both solutions you can normally do a dump of the information from a table, or from the output of a query, into a CSV file.

For example, with MySQL you can use the SELECT INTO SQL statement:

mysql> SELECT title, subtitle, servings, description into OUTFILE  'data.csv' FIELDS TERMINATED BY ',' FROM recipes t;

Within Oracle, use the SPOOL method within sqlplus, or manually combine the columns together. Alternatively, there are numerous solutions and tools for reading SQL data and generating CSV.

Once you've generated the file, the easiest way to get the data into HDFS is to copy the information from the generated file into HDFS using the hadoop command-line tool.

For example:

$ hadoop fs -copyFromLocal data.csv /user/

The problem with this approach is what do you do the next time you want to export the data? Do you export the whole batch, or just the changed records? And how do you identify the changed information, and more importantly merge that back once it's in HDFS. More importantly, all you have is the raw data; to use it, for example, within Hive and perform queries on the information, requires manually generating the DDL. Let's try a different tool, Sqoop.

Using Sqoop
Sqoop is a standard part of Hadoop and uses JDBC to access remote databases of a variety of types and then transfers the information across into Hadoop. The way it does this is actually not vastly different from the manual export process provided above; it runs the equivalent of a 'SELECT * FROM TABLE' and then writes the generated information into HDFS for you.

There are some differences. For one, Sqoop will do this in parallel for you. For example, if you have 20 nodes in your Hadoop cluster, Sqoop will fire up 20 processes that first identify and split up the extraction, and then give each node the range of records to be extracted. When moving millions of rows of data, it is obviously more efficient to be doing this in parallel, providing your server is capable of handling the load.

Using Sqoop is simple, you supply the JDBC connectivity information while logged in to your Hadoop cluster, and effectively suck the data across:

$ sqoop import-all-tables --connect jdbc:mysql://192.168.0.240/cheffy
\-username=cheffy

This process will create a file within HDFS with the extracted data:

$ hadoop fs -ls access_log
Found 6 items
-rw-r--r--   3 cloudera cloudera          0 2013-08-15 09:37 access_log/_SUCCESS
drwxr-xr-x   - cloudera cloudera          0 2013-08-15 09:37 access_log/_logs
-rw-r--r--   3 cloudera cloudera   36313694 2013-08-15 09:37 access_log/part-m-00000
-rw-r--r--   3 cloudera cloudera   36442312 2013-08-15 09:37 access_log/part-m-00001
-rw-r--r--   3 cloudera cloudera   36797470 2013-08-15 09:37 access_log/part-m-00002
-rw-r--r--   3 cloudera cloudera   36321038 2013-08-15 09:37 access_log/part-m-00003

Sqoop itself is quite flexible, for example you can read data from a variety of sources, and write that out to files in various formats, including generating DDL for use within Hive.

Sqoop also supports incremental loads; this is achieved by either using a known auto-incrementing ID that can be used as the change identifier, or by changing your DDL to provide a date time or other column to help identify the last export and new data. For example, using an auto-increment:

$ sqoop import --connect jdbc:mysql://192.168.0.240/hadoop --username root \
--table chicago --check-column id --incremental append --last-value=2168224

The problem with Sqoop is that not everybody wants to change their DDL or auto-increment data. Meanwhile, the problem with both manual and Sqoop based exports is that performing a query, even a limiting one, has the effect of removing data from your memory cache, which may ultimately affect the performance of the application running on the source database. This is not a situation you want.

Furthermore, automating the process, either with direct imports or Sqoop is not as straightforward as it seems either.

Real-Time Replication
A better solution is to replicate the information in real-time using a tool such as Tungsten Replicator. There are methods built into both MySQL and Oracle for effectively extracting the data:

  • MySQL provides the binary log, which contains a simple sequential list of all the changes to the database. These can be statement based or row based, or a mixture.
  • Oracle provides multiple tools, but Tungsten Replicator is designed to work the Change Data Capture (CDC) system to extract row-based information from the database changes.

By reading the row-based changes out of the source database, Tungsten Replicator can formulate this information into CSV. A simple diagram explains the basic process.

This effectively replaces both the manual and Sqoop-based processes with an automated, and constant, stream of data from the source database into Hadoop using HDFS. The exact sequence is:

  • Data is read from the source database, using the binary log or CDC information. This data is already in row format and each table should have a primary key.
  • The row-based changes are stored within the THL format, which consists of the raw ROW data and metadata, such as the column names, primary key and indexing information, and any reformatting required, such as changing the ENUM or SET data types into equivalent strings. THL also associates a unique transaction ID with each block of committed data.
  • The THL data is transferred over to the slave replicator, which is running within the Hadoop cluster.
  • The slave replicator generates a CSV file per table containing a configurable number of rows or within a specific time limit, providing a regular stream of data. The CSV data itself consists of an operation type (insert, or delete, with updates represented as a delete of the original data and an insert of the new data), the sequence number, the primary key information, and the raw row data itself. The reason for this format is how it is used on the other side.
  • The CSV is then copied into the HDFS file system.

This actually only gets the raw change information from the source database and out into HDFS.

This is an important distinction from the manual export and Sqoop processes; Tungsten Replicator effectively stores a CSV version of the change log information.

To turn that change data into we need to materialize the change data into a table that looks like the original table from where the data was generated. The materialization process is actually very simple; within Hadoop we can write a map-reduce script that does the following:

  • Orders all the changes by primary key and transaction ID
  • Ignores any row that is a delete
  • Generates a row for each row marked as an insert, picking the 'last' row (by transaction id) from the list of available rows


This is perhaps clearer in the diagram below, where the change log on the left is translated into the two rows of actual data on the right.

The materialization process needs to be run on every table, and because of the way it works with relation to the idempotency of the primary key information for each row, it can be used both to merge with the current dataset, with data that has previously been provisioned by a using the manual process or Sqoop, and previous executions of the tool on the data. Once the changes have been migrated, the actual change data can be removed.

Using the Change Data
Since you've moved the change data over, another option, rather than generating carbon copy tables, is to actually use the change data. You can, for example, process the information and look at the same transaction data over time or provide a sample of what your data looked like at a specific time. For example, in a sales environment, you might use this to examine the cost and relative sales for products over time when their prices changed.

Summary
There are many solutions available for moving data, and indeed getting data into Hadoop is altogether complicated, but there are benefits and pitfalls to the solutions available. Both manual and Sqoop-based solutions tend to be network and resource heavy, and designed to duplicate data from one side to the other.

The right solution needs to provide the ability to analyze the transactional data in a completely different fashion that may provide additional depth and breadth from your existing transactional data store.

 

Manual via CSV

Sqoop

Tungsten Replicator

Process

Manual/Scripted

Manual/Scripted

Fully automated

Incremental Loading

Possible with DDL changes

Requires DDL changes

Fully supported

Latency

Full-load

Intermittent

Real-time

Extraction Requirements

Full table scan

Full and partial table scans

Low-impact binlog scan

More Stories By MC Brown

MC Brown is director of product management at Continuent, a leading provider of database clustering and replication, enabling enterprises to run business-critical applications on cost-effective open source software. To learn more, contact Continuent at [email protected] or visit http://www.continuent.com.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


IoT & Smart Cities Stories
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments t...
If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...