ApexProposal

Abstract

Apex is an enterprise grade native YARN big data-in-motion platform that unifies stream processing as well as batch processing. Apex processes big data in-motion in a highly scalable, highly performant, fault tolerant, stateful, secure, distributed, and an easily operable way. It provides a simple API that enables users to write or re-use generic Java code, thereby lowering the expertise needed to write big data applications.

Functional and operational specifications are separated. Apex is designed in a way to enable users to write their own code (aka user defined functions) as is and leave all operability to the platform. The API is very simple and is designed to allow users to drop in their code as is. The platform mainly deals with operability and treats functional code as a black box. Operability includes fault tolerance, scalability, security, ease of use, metrics api, webservices, etc. In other words there is no separation of UDF (user defined functions), as all functional code is UDF. This frees users to focus on functional development, and lets platform provide operability support. The same code runs as is with different operability attributes. The data-in-motion architecture of Apex unifies stream as well as batch processing in a single platform. Since Apex is a native YARN application, it leverages all the components of YARN without duplication. Apex was developed with YARN in mind and has no overlapping components/functionality with YARN.

The Apex platform is supplemented by project Malhar, which is a library of operators that implement common business logic functions needed by customers who want to quickly develop applications. These operators provide access to HDFS, S3, NFS, FTP, and other file systems; Kafka, ActiveMQ, RabbitMQ, JMS, and other message systems; MySql, Cassandra, MongoDB, Redis, HBase, CouchDB and other databases along with JDBC connectors. The Malhar library also includes a host of other common business logic patterns that help users to significantly reduce the time it takes to go into production. Ease of integration with all other big data technologies is one of the primary missions of Malhar.

Proposal

The goal of this proposal is to establish the core engine of DataTorrent RTS product as an Apache Software Foundation (ASF) project in order to build a vibrant, diverse, and self-governed open source community around the technology. DataTorrent will continue to sell management tools, application building tools, easy to use big data applications, and custom high end business logic operators. This proposal covers the Apex source code (written in Java), Apex documentation and other materials currently available on https://github.com/DataTorrent/Apex. This proposal also covers the Malhar source code (written in Java), Malhar documentation, and other materials currently available on https://github.com/DataTorrent/Malhar. We have done a trademark check on the name Apex, and have concluded that the Apex name is likely to be a suitable project name.

Background

DataTorrent RTS is a mature and robust product developed as a native YARN application. RTS 1.0 was launched in summer of 2014; RTS 2.0 was launched in Jan 2015. Both were well received by customers. RTS 3.0 was launched at end of July 2015. RTS is among the first enterprise grade platform that was developed from the ground up as native YARN application. DataTorrent RTS is currently maintained by engineers as a closed source project. Even though the engineers behind RTS are experienced software engineers and are knowledge leaders in data-in-motion platforms, they have had little exposure to the open source governance process. Customers are currently running applications based on DataTorrent RTS in production.

Rationale

Big data applications written for non-Hadoop platforms typically require major rewrites to get them to work with Hadoop. This rewriting creates a significant bottleneck in terms of resources (expertise) which in turn jeopardizes the viability of such an endeavour. It is hard enough to acquire big data expertise, demanding additional expertise to do a major code conversion makes it a very hard problem for projects to successfully migrate to Hadoop. Also, due to the batch processing nature of Hadoop’s MapReduce paradigm, users often have to wait tens of minutes to see results and act on them due to various delays in data flow. DataTorrent’s RTS data-in-motion architecture is designed to address this problem. It enables even the non big data developer to write code and operate it in a scalable, fault tolerant manner. The big data-in-motion architecture of DataTorrent’s RTS enables ease of integration into current enterprise infrastructure. This goal was achieved by keeping the API simple and empowering users to put in the connector code as is (or with minimal changes).

Malhar is a manifestation of this reality, and we or the customer engineers were able to create these connectors within a day or so if not within a week. Connectors include those to integrate with message bus(es), file systems, databases, other protocols, and more continue to be added. Over a period of time we expect users to simply pick a connector that already exists in Malhar and quickly begin integrating with their current enterprise infrastructure. Within the data-in-motion architecture a stream application is one with connector(s) to say Kafka, JMS, or Flume; while a batch application is one with connector(s) to HDFS, HBase, FTP, NFS, S3n etc. This allows usage of the platform for both stream as well as batch processing with same business logic. Complete separation of user written application code from all operational aspects of the system, as well as support code for YARN, significantly expands the potential use cases that can migrate to use Hadoop.

Apex will enable Hadoop eco-system to migrate a lot more use cases. It will enable the Hadoop eco-system to deliver on a promise to rapidly transform current IT infrastructure. Apex will help in significantly increasing productization of big data projects. One of the main barometers of success in the Hadoop eco-system is significant reduction of time to market for big data applications migrating to Hadoop. We believe that Apex will be one of the platforms that will enable users to extract value from big data, by reducing time to market. This rapid innovation can be optimally achieved through a vibrant, diverse, self-governed community collectively innovating around Apex and the Malhar library, while at the same time cross-pollinating with various other big data platforms. ASF is an ideal place to meet this goal.

Initial Goals

Our initial goals are to bring Apex and Malhar repositories into the ASF, adapt internal engineering processes to open development, and foster a collaborative development model in accordance with the "Apache Way." DataTorrent plans to develop new functionality in an open, community-driven way. To get there, the existing internal build, test and release processes will be refactored to support open development. We already have an active user community on google groups that we intend to migrate to Apache.

Current Status

Currently, the project Apex code base is available under Apache 2.0 license (https://github.com/DataTorrent/Apex). Project Malhar code base is available under Apache 2.0 license (https://github.com/DataTorrent/Malhar). Project Malhar was open sourced 2 years ago which should make it easy for the project Malhar team to adapt to an open, collaborative, and meritocratic environment. Contributors of Malhar are employees of DataTorrent or have agreed to the shift to Apache. Project Apex, in contrast, was developed as a proprietary, closed-source product, but the internal engineering practices adopted by the development team were common to Malhar, and should lend themselves well to an open environment. DataTorrent plans to execute a software grant agreement as part of the launch of the incubation of Apex as an Apache project.

The DataTorrent team has always focused on building a robust end user community of paying and non-paying customers. We think that the existing community centered around the existing google groups mailing list should be relatively easy to transform into an Apache-style community including both users and developers.

Meritocracy

Our proposed list of initial committers include the current RTS R&D team, and our existing customers. This group will form a base for the broader community we will invite to collaborate on the codebase. We intend to radically expand the initial developer and user community by running the project in accordance with the "Apache Way". Users and new contributors will be treated with respect and welcomed. By participating in the community and providing quality patches/support that move the project forward, they will earn merit. They also will be encouraged to provide non-code contributions (documentation, events, presentations, community management, etc.) and will gain merit for doing so. Those with a proven support and quality track record will be encouraged to become committers.

Community

If Apex is accepted for incubation, the primary initial goal will be transitioning the core community towards embracing the Apache Way of project governance. We will solicit major existing contributors to become committers on the project from the start. It should be noted that the existing community is already more diverse in many ways than some top-level Apache projects. We expect that we can encourage even more diversity.

Core Developers

While a few core developers are skilled in working in openly governed Apache communities, most of the core developers are currently NOT affiliated with the ASF and would require new ICLAs before committing to the project. There would also be a learning curve associated with this on-boarding. Changing current development practices to be more open will be an important step.

Alignment

The following existing ASF projects provide related functionality as that provided by Apex and should be considered when reviewing Apex proposal:

Apache HadoopⓇ is a distributed storage and processing framework for very large datasets focusing primarily on batch processing for analytic purposes. Apex is a native YARN application. The Apex and Malhar roadmap includes plans to continue to leverage YARN, and help the YARN community develop the ability to support long running applications. Apex uses DFS interface of its core checkpoint/commit. Malhar has a large number of operators that leverage HDFS and other Apache projects. Our roadmap includes plans to continue to deepen the currently close integration with HDFS.

Apache HBase offers tabular data stored in Hadoop based on the Google Bigtable model. Malhar has HBase connectors to ease integration with HBase. Malhar roadmap includes plans to continue to enhance integration with Apache HBase.

Apache Kafka offers distributed and durable publish-subscribe messaging. Malhar integrates Kafka with Hadoop through feature rich connectors and supports ingest as well as analytical functions to incoming data. Raw data can be ingested from Kafka and results can be written to Kafka. Malhar roadmap includes plans to continue to enhance integration with Apache Kafka.

Apache Flume is a distributed, reliable, and available service for efficiently collecting, aggregating, and moving large amounts of log data. Malhar has Flume connectors to ease integration with Flume. These connectors ensures that ingestion with Flume is fault tolerant and thus can be done in real-time with the same SLA as Flume’s HDFS connectors. Malhar roadmap includes plans to continue to enhance integration with Apache Flume.

Apache Cassandra is a highly scalable, distributed key-value store that focuses on eventual consistency. Malhar has connectors to ease integration with Cassandra. Malhar roadmap includes plans to continue to enhance integration with Apache Cassandra.

Apache Accumulo is a distributed key-value store based on Google’s BigTable design. Malhar has connectors to ease integration with Accumulo. The Malhar roadmap includes plans to continue to enhance integration with Apache Accumulo.

Apache Tez is aimed at building an application framework which allows for a complex DAG of tasks for process data. The Apex and Malhar roadmaps include plans to integrate with Apache Tez but this is not currently supported.

Apache ActiveMQ and its sub project Apache Apollo offers a powerful message queue framework. Malhar has ActiveMQ connectors that ease integration with ActiveMQ.

Apache Spark is an engine for processing large datasets, typically in a Hadoop cluster. Malhar project makes it easy for users to integrate with Spark. The Malhar roadmap includes plans to continue to enhance integration with Apache Spark.

Apache Flink is an engine for scalable batch and stream data processing. Malhar project makes it easy for users to integrate with Flink. There is overlap in how Flink leverages data-in-motion architecture for both stream and batch processing, and it does subscribe to our thought process that data-in-motion can handle both stream and batch, meanwhile a batch only engine will find it harder to manage streams. We differ in terms of how we handle operability, user defined code, metrics, webservices etc. Apex is very operational oriented, while Flink has much more focus on functional elements. Malhar and rapid availability of common business logic is another differentiator. We believe both these approaches are valid and the community and innovation will gain by through cross pollination. We plan to integrate with Apache Flink via HDFS for now.

Apache Hive software facilitates querying and managing large datasets residing in distributed storage. Malhar project makes it easy for users to integrate with Apache Hive. The Malhar roadmap includes plans to continue to enhance integration with Apache Hive.

Apache Pig is a platform for analyzing large data sets. Pig consists of a high-level language for expressing data analysis programs, coupled with infrastructure for evaluating these programs. The Apex and Malhar roadmaps include plans to integrate with Apache Pig.

Apache Storm is a distributed realtime computation system. Malhar makes it easy for users to integrate with Apache Storm. We plan to integrate with Apache Storm via HDFS for now. Malhar roadmaps include plans to continue to support mechanism for integration with Apache Storm.

Apache Samza is a distributed stream processing framework. Malhar makes it easy for users to integrate with Apache Samza. We plan to integrate with Apache Samza via HDFS or Apache Kafka for now. Malhar roadmaps include plans to continue to support mechanism for integration with Apache Samza.

Apache Slider is a YARN application to deploy existing distributed applications on YARN, monitor them, and make them larger or smaller as desired even when the application is running. Once Slider matures, we will take a look at close integration of Apex with Slider.

Project Malhar and Apex are aligned to many more Apache projects and other open source projects as ease of integration with other technologies is one of the primary goals of this project. These include Apache Solr, ElasticSearch, MongoDB, Aerospike, ZeroMQ, CouchDB, CouchBase, MemCache, Redis, RabbitMQ, Apache Derby.

Known Risks

Development has been sponsored mostly by a single company (DataTorrent, Inc.) thus far and coordinated mainly by the core DataTorrent RTS and Malhar team, with active participation from our current customers.

For the project to fully transition to the Apache Way governance model, development must shift towards the merit-centric model of growing a community of contributors balanced with the needs for extreme stability and core implementation coherency.

The tools and development practices in place for the DataTorrent RTS and Malhar products are compatible with the ASF infrastructure and thus we do not anticipate any on-boarding pains. Migration from the current GitHub repository is also expected to be straightforward.

Orphaned products

DataTorrent is fully committed to DataTorrent Apex and Malhar and the product will continue to be based on the Apex project. Moreover, DataTorrent has a vested interest in making Apex succeed by driving its close integration with sister ASF projects. We expect this to further reduce the risk of orphaning the product.

Inexperience with Open Source

DataTorrent has embraced open source software by open sourcing Malhar project under Apache 2.0 license. The DataTorrent team includes veterans from the Yahoo! Hadoop team. Although some of the initial committers have not been developers on an entirely open source, community-driven project, we expect to bring to bear the open development practices of Malhar to the Apex project. Additionally, several ASF veterans agreed to mentor the project and are listed in this proposal. The project will rely on their guidance and collective wisdom to quickly transition the entire team of initial committers towards practicing the Apache Way. DataTorrent is also driving the Kafka on YARN (KOYA) initiative.

Homogeneous Developers

While most of the initial committers are employed by DataTorrent, we have already seen a healthy level of interest from our existing customers and partners. We intend to convert that interest directly into participation and will be investing in activities to recruit additional committers from other companies.

Reliance on Salaried Developers

Most of the contributors are paid to work in the Big Data space. While they might wander from their current employers, they are unlikely to venture far from their core expertises and thus will continue to be engaged with the project regardless of their current employers.

Relationships with Other Apache Products

As mentioned in the Alignment section, Apex may consider various degrees of integration and code exchange with Apache Hadoop (YARN and HDFS), Apache Kafka, Apache HBase, Apache Flume, Apache Cassandra, Apache Accumulo, Apache Tez, Apache Hive, Apache Pig, Apache Storm, Apache Samza, Apache Spark, Apache Slider. Given the success that the DataTorrent RTS product enjoyed, we expect integration points to be inside and outside the project. We look forward to collaborating with these communities as well as other communities under the Apache umbrella.

An Excessive Fascination with the Apache Brand

While we intend to leverage the Apache ‘branding’ when talking to other projects as testament of our project’s ‘neutrality’, we have no plans for making use of Apache brand in press releases nor posting billboards advertising acceptance of Apex into Apache Incubator.

Documentation

See documentation for the current state of the project documentation available as part of the GitHub repositories - https://github.com/DataTorrent/Apex; https://github.com/DataTorrent/Malhar. In addition a list of demos that serve as a how to guide are available at https://github.com/DataTorrent/Malhar/tree/master/demos

Initial Source

DataTorrent has released the source code for Apex under Apache 2.0 License at https://github.com/DataTorrent/Apex, and that of Malhar under Apache 2.0 licence at https://github.com/DataTorrent/Malhar. We encourage ASF community members interested in this proposal to download the source code, review it and try out the software.

Source and Intellectual Property Submission Plan

As soon as Apex is approved to join Apache Incubator, DataTorrent will execute a Software Grant Agreement and the source code will be transitioned onto ASF infrastructure. The code is already licensed under the Apache Software License, version 2.0. We know of no legal encumberments that would inhibit the transfer of source code to the ASF.

External Dependencies

All dependencies fall under the permissive licenses categories, or weak copy left (http://www.apache.org/legal/resolved.html#category-b). We intend to remove the dependencies on GPL licensed technologies on which APex or Malhar depend. These technologies are optional and have been marked as such.

Embedded dependencies (relocated):

None

Runtime dependencies:

activemq-client
ant
async-http-client
bval-jsr303
commons-beanutils
commons-codec
commons-lang3
commons-compiler
embassador
fastutil
guava
hadoop-common
hadoop-common-tests
hadoop-yarn-client
httpclient
jackson-core-asl
jackson-mapper-asl
javax.mail
jersey-apache-client4
jersey-client
jetty-servlet
jetty-websocket
jline
kryo
named-regexp
netlet
rhino (GPL 2.0, optional)
slf4j-api
slf4j-log4j12
validation-api
xbean-asm5-shaded
zip4j

Module or optional dependencies

accumulo-core
aerospike-client
amqp-client
aws-java-sdk-kinesis
cassandra-driver-core
couchbase-client
CouchbaseMock
elasticsearch
geoip-api (LGPL, optional)
hbase
hbase-client
hbase-server
hive-exec
hive-service
hiveunit
javax.mail-api
jedis
jms-api
jri (GPL, optional)
jriengine (LGPL, optional)
jruby (LGPL, optional)
jython (PSF License, optional)
jzmq (LGPL, optional)
kafka_2.10
lettuce (GPL, optional)
libthrift
Memcached-Java-Client
mongo-java-driver
mqtt-client
mysql-connector-java (GPL2, optional)
org.ektorp
rengine (LGPL, optional)
rome
solr-core
solr-solrj
spymemcached
sqlite4java
super-csv
twitter4j-core
twitter4j-stream
uadetector-resources
org.apache.servicemix.bundles.splunk

Build only dependencies:

None

Test only dependencies:

activemq-broker
activemq-kahadb-store
greenmail
hadoop-yarn-server-tests
hsqldb
janino
junit
MockFtpServer
mockito-all
testng

Cryptography N/A

Required Resources

Mailing lists

private@apex.incubator.apache.org (moderated subscriptions)
commits@apex.incubator.apache.org
dev@apex.incubator.apache.org

Git Repository

Issue Tracking

JIRA Project Apex (APEX_CORE) // If '_' is not allowed, use APEXCORE
JIRA Project Malhar (APEX_MALHAR) // If '_' is not allowed use APEXMALHAR

Other Resources

Means of setting up regular builds for apex-core on builds.apache.org
Means of setting up regular builds for apex-malhar on builds.apache.org

Rationale for Malhar and Apex having separate git and jira

We managed Malhar and Apex as two repos and two jiras on purpose. Both code bases are released under Apache 2.0 and are proposed for incubation. In terms of our vision to enable innovation around a native YARN data-in-motion that unifies stream processing as well as batch processing Malhar and Apex go hand in hand. Apex has base API that consists of java api (functional), and attributes (operability). Malhar is a manifestation of this api, but from user perspective, Malhar is itself an API to leverage business logic. Over past three years we have found that the cadence of release and api changes in Malhar is much rapid than Apex and it was operationally much easier to separate them into their own repos. Two repos will reflect clear separation of engine (Apex) and operators/business logic (Malhar). It will allow or independent release cycles (operator change independent of engine due to stable API). We however do not believe in two levels of committers. We believe there should be one community that works across both and innovates with ideas that Malhar and Apex combined provide the value proposition. We are proposing that Apache incubation process help us to foster development of one community (mailing list, committers), and a yet be ok with two repos. We are proposing that this be taken up during incubation. Community will learn if this works. The decision on whether to split them into two projects be taken after the learning curve during incubation.

Initial Committers

Roma Ahuja (rahuja at directv dot com)
Isha Arkatkar (isha at datatorrent dot com)
Raja Ali (raji at silverspringnet dot com)
Sunaina Chaudhary ( SChaudhary at directv dot com)
Bhupesh Chawda (bhupesh at datatorrent dot com)
Chaitanya Chelobu (chaitanya at datatorrent dot com)
Bright Chen (bright at datatorrent dot com)
Pradeep Dalvi (pradeep dot dalvi at datatorrent dot com)
Sandeep Deshmukh (sandeep at datatorrent dot com)
Yogi Devendra (yogi at datatorrent dot com)
Cem Ezberci (hasan dot ezberci at ge dot com)
Timothy Farkas (tim at datatorrent dot com)
Ilya Ganelin (ilya dot ganelin at capitalone dot com)
Vitthal Gogate (vitthal_gogate at yahoo dot com)
Parag Goradia (parag dot goradia at ge dot com)
Tushar Gosavi (tushar at datatorrent dot com)
Priyanka Gugale (priyanka at datatorrent dot com)
Gaurav Gupta (gaurav at datatorrent dot com)
Sandesh Hegde (sandesh at datatorrent dot com)
Siyuan Hua ( siyuan at datatorrent dot com)
Ajith Joseph (ajoseph at silverspring dot com)
Amol Kekre ( amol at datatorrent dot com)
Chinmay Kolhatkar ( chinmay at datatorrent dot com)
Pramod Immaneni ( pramod at datatorrent dot com)
Anuj Lal ( anuj dot lal at ge dot com)
Dongsu Lee (dlee3 at directv dot com)
Vitaly Li (blossom dot valley at gmail dot com)
Dean Lockgaard (dean at datatorrent dot com)
Rohan Mehta (rohan_mehta at apple dot com)
Adi Mishra (apmishra at directv dot com, adi dot mishra at gmail dot com)
Chetan Narsude (chetan at datatorrent dot com)
Darin Nee (dnee at silverspring dot com)
Alexander Parfenov (sasha at datatorrent dot com)
Andrew Perlitch (andy at datatorrent dot com)
Shubham Phatak (shubham at datatorrent dot com)
Ashwin Putta (ashwin at datatorrent dot com)
Rikin Shah (shah_rikin at yahoo dot com)
Luis Ramos (l dot ramos at ge dot com)
Munagala Ramanath (ram at datatorrent dot com)
Vlad Rozov (vlad dot rozov at datatorrent dot com)
Atri Sharma (atri dot jiit at gmail dot com)
Chandni Singh (chandni at datatorrent dot com)
Venkatesh Sivasubramanian (venkateshs at ge dot com)
Aniruddha Thombare (aniruddha at datatorrent dot com)
Jessica Wang (jessica at datatorrent dot com)
Thomas Weise (thomas at datatorrent dot com)
David Yan (david at datatorrent dot com)
Kevin Yang (yang dot k at ge dot com)
Brennon York (brennon dot york at capitalone dot com)

Affiliations

Apple: Vitaly Li, Rohan Mehta
Barclays: Atri Sharma
Class Software: Justin Mclean
CapitalOne: Ilya Ganelin, Brennon York
DataTorrent: everyone else on this proposal
Datachief: Rikin Shah
DirecTV: Roma Ahuja, Sunaina Chaudhary, Dongsu Lee, Adi Mishra
E8security: Vitthal Gogate
General Electric: Cem Ezberci, Parag Goradia, Anuj Lal, Luis Ramos, Venkatesh Sivasubramanian, Kevin Yang
Hortonworks: Alan Gates, Taylor Goetz, Chris Nauroth, Hitesh Shah
MapR: Ted Dunning
SilverSpring Networks: Raja Ali, Ajith Joseph, Darin Nee

Page tree