+1 (binding) On 6 December 2013 14:12, Ashish <paliwalash...@gmail.com> wrote: > +1 (non-binding) > > > On Fri, Dec 6, 2013 at 3:13 AM, Stack <st...@duboce.net> wrote: > >> Discussion of the Phoenix proposal has settled since its original >> posting on November 7th. Feedback has been incorporated. >> >> Let us now move to a vote. >> >> Should Phoenix become an Apache incubator project? >> >> [] +1 Accept Phoenix into the Incubator >> [] +0 Don't care whether or which >> [] -1 Do not accept Phoenix into the Incubator because... >> >> The latest version of the proposal can be found here [1]. It is >> also posted below for your convenience. >> >> Let the vote run 72 hours. >> >> Thank you, >> St.Ack >> >> 1. https://wiki.apache.org/incubator/PhoenixProposal >> >> >> >> >> Abstract >> >> Phoenix is an open source SQL query engine for Apache HBase, a NoSQL data >> store. It is accessed as a JDBC driver and enables querying and managing >> HBase tables using SQL. >> >> Proposal >> >> Phoenix is an open source SQL skin over HBase delivered as a >> client-embedded JDBC driver targeting low latency queries over HBase data. >> Phoenix takes your SQL query, compiles it into a series of HBase scans, and >> orchestrates the running of those scans to produce regular JDBC result >> sets. The table metadata is stored in an HBase table and versioned, such >> that snapshot queries over prior versions will automatically use the >> correct schema. Direct use of the HBase API, along with coprocessors and >> custom filters, results in performance on the order of milliseconds for >> small queries, or seconds for tens of millions of rows. Phoenix interfaces >> with both Pig and Map-reduce for the input and output of data. >> >> Background >> >> Phoenix initially started as an internal project at Salesforce.com to >> efficiently analyze big data stored in HBase. It was open sourced on Github >> about a year ago in Jan 2013. Over time Phoenix, together with HBase as the >> storage tier, has begun to evolve into a general SQL database with support >> for metadata management, secondary indexes, joins, query optimization, and >> multi-tenancy. This is expected to continue as Phoenix implements a >> cost-based query optimizer and potentially transaction support, and >> surfaces new HBase security features such as encryption and cell-level >> security. Phoenix's developer community has also grown to include >> additional companies such as Intel, who have contributed join support to >> Phoenix, as well as Hortonworks, who are in the process of porting Phoenix >> to the 0.96 release of HBase. >> >> Rationale >> >> As usage and the number of contributors to Phoenix has grown, we have >> sought for a long-term home for the project, and we believe the Apache >> foundation would be a great fit. Joining Apache would ensure that tried and >> true processes and procedures are in place for the growing number of >> organizations interested in contributing to Phoenix. Phoenix is also a good >> fit for the Apache foundation: Phoenix already interoperates with several >> existing Apache projects (HBase, Hadoop, Pig, BigTop). The Phoenix team is >> familiar with the Apache process and and believes in the Apache mission - >> the team already includes multiple Apache committers. >> >> Initial Goals >> >> The initial goals will be to move the existing codebase to Apache and >> integrate with the Apache development process. Once this is accomplished, >> we plan for incremental development and releases that follow the Apache >> guidelines. >> >> Current Status >> >> Phoenix has undergone two major and three minor releases (1.0, 1.1, 1.2, >> 2.0, and 2.1) as well as many patch releases. Phoenix is being used in >> production by Salesforce.com as well as at other organizations. The Phoenix >> codebase is currently hosted at github.com, which will form the basis of >> the Apache git repository. >> >> Meritocracy >> >> The Phoenix project already operates on meritocratic principles. Phoenix >> has several developers from various organizations outside of Salesforce.com >> who have contributed major new features. While this process has remained >> mostly informal, as we do not have an official committer list, an implicit >> organization exists in which individuals who contribute major components >> act as maintainers for those modules. If accepted, the Phoenix project >> would include several of these participants as initial committers. We will >> work to identify all committers and PPMC members for the project and to >> operate under the ASF meritocratic principles. >> >> Community >> >> Acceptance into the Apache foundation would bolster the already strong user >> and developer community around Phoenix. That community includes many >> contributors from various other companies, and an active mailing list >> composed of hundreds of users. >> >> Core Developers >> >> The core developers of our project are listed in our contributors and >> initial PPMC below. Though many are employed at Salesforce.com, there is a >> representative cross sampling of other organizations including Intel, >> Hortonworks, and Cloudera. >> >> Alignment >> >> Our proposed Phoenix effort aligns closely with Apache HBase. The HBase >> project perimeter is denoted by a simple byte-array based Create, Read, >> Update, Delete and Scan APIs with no current plans to extend beyond this >> bounds. Phoenix complements this with a higher level API in SQL with which >> many are already familiar. At first glance, it may seem that Phoenix should >> just be folded into HBase as a new module. However, the focus of the two >> projects will be quite different, especially as Phoenix matures. With >> secondary indexing and joins just having been introduced into Phoenix, the >> next big frontier will be to implement a cost-based query optimizer. This >> is the heart-and-soul of most relational databases and can can take a >> lifetime to get right. >> >> HBase is focused on being a scalable data store agnostic to types and >> schema. Phoenix would layer typing, and relational facilities on top of >> this scalable store. By keeping Apache HBase and Phoenix separate, both may >> evolve independently and at different rates. Though the focus of the two >> projects is different, the relationship between them is very positive and >> mutually beneficial. New features in HBase will be leveraged in Phoenix as >> it makes sense to surface these in a SQL paradigm. In addition, Phoenix may >> drive new features in HBase, as evidenced by the new type system recently >> introduced into HBase. This will enable better interoperability between >> Apache Hive, standalone HBase uses case, and Phoenix by defining a standard >> serialization format. >> >> Phoenix can be divided into a front end and a back end. The front end is >> delivered as a JDBC driver and contains, among other things, the SQL parser >> and query planner. The front end is currently written for the HBase client >> API but could be extended to support other data stores in the Apache >> family. >> >> The back end is, currently, HBase specific components for pushing as much >> work to the server as possible. However, if there were sufficient interest >> to build them, contributions to Phoenix of new back ends for other data >> stores in the Apache family would be feasible. >> >> Other projects exists that perform SQL over HBase data (such as Apache >> Hive), however these products do not provide the same low latency query >> capabilities as Phoenix. Instead, they are more oriented around maximizing >> throughput for batched operations. Phoenix opens the door to a completely >> new set of use cases for Apache HBase that demand a more interactive user >> experience. >> >> There are also a number of related Apache projects and dependencies that >> are mentioned in the Relationships with Other Apache products section. >> >> Known Risks >> >> Orphaned Products >> >> Given the current level of investment in Phoenix - the risk of the project >> being abandoned is minimal. All current and planned HBase use cases at >> Salesforce.com go through Phoenix. In addition, both Intel and Hortonworks >> plan to include Phoenix in their distributions. Other companies have >> devoted significant internal infrastructure investment in Phoenix. >> >> Inexperience with Open Source >> >> Phoenix has existed as a healthy open source project for almost a year. >> During that time, James, Mujtaba, and others have successfully fostered an >> open-source community, attracting users and developers from a diverse group >> of companies including Intel, Intuit, Bloomberg, Tagged, and Hortonworks. >> Although neither are committers on other Apache projects, both James and >> Mujtaba have experience working with and contributing to other Apache >> projects. >> >> Homogenous Developers >> >> The initial list of committers includes developers from several >> institutions, including Salesforce, Intel, and Hortonworks. >> >> Reliance on Salaried Developers >> >> Like most open source projects, Phoenix receives substantial support from >> salaried developers. A large fraction of Phoenix development is supported >> by Salesforce.com. In addition, those working from within corporations and >> universities often devote “after hours” or spare time to the project. We >> will continue our efforts to ensure stewardship of the project to be >> independent of salaried developers. >> >> Relationship with Other Apache Products >> >> Although Phoenix provides a higher level abstraction than Apache HBase by >> hiding its client APIs, Phoenix relies on Apache HBase for both storing and >> retrieving data. It also inter-operates with Apache HBase by allowing >> existing data, not created by Phoenix, to be queried. In addition, both >> Apache Pig and Hadoop are supported for data input and output. Finally, the >> Phoenix is included and installable through Apache Bigtop and the build and >> test suite are run through Apache Maven. >> >> Phoenix offers an alternative query engine to Apache Hadoop (MapReduce). >> Unlike MapReduce, Phoenix is designed for lower-latency, OLTP, and >> interactive workloads. This makes the projects complimentary as users may >> run MapReduce and Phoenix side-by-side. >> >> We plan to increase the interoperability between Phoenix, Apache Hive, and >> standalone Apache HBase usage by standardizing on a new type system that >> has been introduced in the current major release of HBase. By all these >> products adopting this new serialization format, interoperability between >> them will take a big step forward. >> >> In addition, we plan to explore providing lower level APIs for other >> products such as Apache Drill to plug into when querying HBase data so that >> they get the performance benefits of using Phoenix. >> >> A Excessive Fascination with the Apache Brand >> >> Phoenix is already a healthy and relatively well known open source project. >> This proposal is not for the purpose of generating publicity. Rather, the >> primary benefits to joining Apache are those outlined in the Rationale >> section. >> >> Documentation >> >> Additional documentation on Phoenix may be found on its github website: >> >> Phoenix overview: >> https://github.com/forcedotcom/phoenix/blob/master/README.md >> >> Phoenix wiki: https://github.com/forcedotcom/phoenix/wiki >> >> Phoenix road map: https://github.com/forcedotcom/phoenix/wiki#roadmap >> >> Phoenix issue tracking: >> >> https://github.com/forcedotcom/phoenix/issues?direction=desc&sort=updated&state=open >> >> Phoenix codebase: https://github.com/forcedotcom/phoenix >> >> Phoenix SQL language reference: http://forcedotcom.github.io/phoenix/ >> >> Phoenix performance: >> >> https://github.com/forcedotcom/phoenix/wiki/Performance#phoenix-vs-related-products >> >> User group: https://groups.google.com/group/phoenix-hbase-user >> >> Initial Source >> >> The Phoenix codebase is currently hosted on Github: >> https://github.com/forcedotcom/phoenix. >> >> Source and Intellectual Property Submission Plan >> >> Currently, the Phoenix codebase is distributed under a BSD license. Upon >> entering Apache, the Phoenix license will be migrated to the Apache 2.0 >> License. >> >> External Dependencies >> >> Beyond relying on Apache HBase, Phoenix has the following external >> dependencies: >> >> ANTLR 3.5 (BSD license: http://www.antlr3.org/license.html) >> >> Sqlline 1.1.2 (BSD license: >> https://github.com/julianhyde/sqlline/blob/master/LICENSE) >> >> Open CSV 2.3 (Apache 2.0 license) >> >> Upon acceptance to the incubator, we would begin a thorough analysis of all >> transitive dependencies to verify this information and introduce license >> checking into the build and release process by integrating with Apache Rat. >> >> Required Resources >> >> Mailing list >> >> We will migrate the existing Phoenix mailing lists as follows: >> >> phoenix-hbase-u...@googlegroups.com --> us...@phoenix.incubator.apache.org >> >> phoenix-hbase-...@googlegroups.com --> d...@phoenix.incubator.apache.org >> >> priv...@phoenix.incubator.apache.org for IPMC members >> >> comm...@phoenix.incubator.apache.org >> >> The latter is to be consistent with the new PIAO naming scheme for >> podlings. >> >> Source control >> >> The Phoenix team would like to use Git for source control, due to our >> current use of Git. We request a writeable Git repo for Phoenix, and >> mirroring to be set up to Github through INFRA. >> >> Issue Tracking >> >> Phoenix currently uses the github issue tracking system associated with its >> github repo: >> >> https://github.com/forcedotcom/phoenix/issues?direction=desc&sort=updated&state=open >> . >> We will migrate to the Apache JIRA: >> http://issues.apache.org/jira/browse/PHOENIX >> >> Other Resources >> >> Jenkins/Hudson for builds and test running. >> Wiki for documentation purposes >> Blog to improve project dissemination >> >> Initial Committers >> >> James Taylor <jtaylor at salesforce dot com> >> >> Mujtaba Chohan <mchohan at salesforce dot com> >> >> Jesse Yates <jyates at apache dot org> >> >> Eli Levine <elevine at salesforce dot com> >> >> Simon Toens <stoens at salesforce dot com> >> >> Maryann Xue <wei.xue at intel dot com> >> >> Anoop Sam John <anoopsamjohn at apache dot org> >> >> Ramkrishna S Vasudevan <ramkrishna at apache dot org> >> >> Jeffrey Zhong <jeffreyz at apache dot org> >> >> Nick Dimiduk <ndimiduk at apache dot org> >> >> Affiliations >> >> The initial committers are from three organizations: Salesforce.com, Intel, >> and Hortonworks. >> >> James Taylor (Salesforce.com) >> Mujtaba Chohan (Salesforce.com) >> Jesse Yates (Salesforce.com) >> Eli Levine (Salesforce.com) >> Simon Toens (Salesforce.com) >> Maryann Xue (Intel) >> Anoop Sam John (Intel) >> Ramkrishna S Vasudevan (Intel) >> Jeffrey Zhong (Hortonworks) >> Nick Dimiduk (Hortonworks) >> >> Sponsors >> >> Champion >> >> Michael Stack >> >> Nominated Mentors >> >> Michael Stack >> Lars Hofhansl >> Andrew Purtell >> Devaraj Das >> Enis Soztutar >> Steven Noels >> >> Sponsoring Entity >> >> The Apache Incubator >> > > > > -- > thanks > ashish > > Blog: http://www.ashishpaliwal.com/blog > My Photo Galleries: http://www.pbase.com/ashishpaliwal
-- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
