Skip to main content

Distributed data processing with Apache Flink

A new distributed engine named Apache Flink has been making its presence felt in the Hadoop ecosystem primarily due to its faster processing and expressive coding capabilities. To get a better idea on Apache Flink design and integration, HadoopSphere caught up with PMC chair Stephan Ewen and asked him more about the product. This is the first part of the interaction with Ewen where we ask him on technical aspects of Apache Flink.

How does Apache Flink work?


Flink is a distributed engine for batch and stream data processing. Its design draws inspiration from MapReduce, MPP databases, and general dataflow systems. Flink can work completely independent of existing technologies like Hadoop, but can run on top of HDFS and YARN.

Developers write Flink applications in fluent APIs in Java or Scala, based on parallel collections (data sets / data streams). The APIs are designed to feel familiar for people who know Hadoop, Apache Spark, Google Dataflow or SQL. For the latter, Flink adds a twist of SQL-style syntax to the API, with richer data types (beyond key/value pairs) whose fields can be used like attributes in SQL. Flink’s APIs also contain dedicated constructs for iterative programs, to support graph processing and machine learning efficiently.

Rather than executing the programs directly, Flink transforms them into a parallel data flow - a graph of parallel operators and data streams between those operators. The parallel data flow is executed on a Flink cluster, consisting of distributed worker processes, much like a Hadoop cluster.

Flink’s runtime is designed with both efficiency and robustness in mind, integrating various techniques in a unique blend of data pipelining, custom memory management, native iterations, and a specialized serialization framework. The runtime is able to exploit the benefits of in-memory processing, while being robust and efficient with memory and shuffles.

For batch programs, Flink additionally applies a series of optimizations while transforming the user programs to parallel data flow, using techniques from SQL databases, applied to Java/Scala programs. The optimizations are designed to reduce data shuffling or sorting, or automatically cache constant data sets in memory, for iterative programs.

What are the integration options available with Apache Flink?


Unlike MapReduce programs, Flink programs are embedded into regular Java/Scala programs, making them more flexible in interacting with other programs and data sources.

As an example, it is possible to define a program that starts with some HDFS files and joins in a SQL (JDBC) data source. Inside the same program, one can switch from the functional data set API to a graph processing paradigm (vertex centric) to define some computations, and then switch back to the functional paradigm for some the next steps. 

The Flink community is also currently working on integrating SQL statements into the functional API.





Stephan Ewen is committer and Vice President of Apache Flink and co-founder and CTO of data Artisans, a Berlin-based company that is developing and contributing to Apache Flink. Before founding data Artisans, Stephan was leading the development of Flink since the early days of the project (then called Stratosphere). Stephan holds a PhD in Computer Science from the University of Technology, Berlin, and has been with IBM Research and Microsoft Research in the course of several internships.

Comments

Popular posts from this blog

Technical deep dive into Apache Tajo

Over the past few months, a new Hadoop based warehouse called Apache Tajo has been making the buzz. We tried to do a technical deep dive in the topic and reached out to PMC chair Hyunsik Choi. Apache Tajo is an Apache top level project since March 2014 and supports SQL standards. It has a powerful distributed processing architecture which is not based on MapReduce. To get more sense on Tajo's claims for providing a distributed, fault-tolerant, low-latency and high throughput SQL engine, we asked a few questions to Choi. This Q&A is published in a two part article series on hadoopsphere.com. Read below to get a better idea on Apache Tajo.
How does Apache Tajo work? As you may already know, Tajo does not use MapReduce and has its own distributed processing framework which is flexible and specialized to relational processing. Since its storage manager is pluggable, Tajo can access data sets stored in various storages , such as HDFS, Amazon S3, Openstack Swift or local file system. …

In-memory data model with Apache Gora

Open source in-memory data model and persistence for big data framework Apache Gora™ version 0.3, was released in May 2013. The 0.3 release offers significant improvements and changes to a number of modules including a number of bug fixes. However, what may be of significant interest to the DynamoDB community will be the addition of a gora-dynamodb datastore for mapping and persisting objects to Amazon's DynamoDB. Additionally the release includes various improvements to the gora-core and gora-cassandra modules as well as a new Web Services API implementation which enables users to extend Gora to any cloud storage platform of their choice. This 2-part post provides commentary on all of the above and a whole lot more, expanding to cover where Gora fits in within the NoSQL and Big Data space, the development challenges and features which have been baked into Gora 0.3 and finally what we have on the road map for the 0.4 development drive.
Introducing Apache Gora Although there are var…

Data deduplication tactics with HDFS and MapReduce

As the amount of data continues to grow exponentially, there has been increased focus on stored data reduction methods. Data compression, single instance store and data deduplication are among the common techniques employed for stored data reduction.
Deduplication often refers to elimination of redundant subfiles (also known as chunks, blocks, or extents). Unlike compression, data is not changed and eliminates storage capacity for identical data. Data deduplication offers significant advantage in terms of reduction in storage, network bandwidth and promises increased scalability.
From a simplistic use case perspective, we can see application in removing duplicates in Call Detail Record (CDR) for a Telecom carrier. Similarly, we may apply the technique to optimize on network traffic carrying the same data packets.
Some of the common methods for data deduplication in storage architecture include hashing, binary comparison and delta differencing. In this post, we focus on how MapReduce and…