Apache Drill
             Design proposal from
              OpenDremel team


Camuel Gilyadov & Constantine Peresypkin,
Email: Camuel@BigDataCraft.com
OpenDremel Story: 2010

• Camuel Gilyadov started Dremel implementation on
  summer 2010 named OpenDremel.
• David Gruzman joined the effort a few months later
  followed by Constantine Peresypkin.
• There wasn’t a comprehensive design or architecture.
  The goal was to get hierarchal-columnar transformation
  working smoothly and in strict accordance to the
  Dremel paper. Several working implementations are
  published by us under Apache License.
• Hong San was hired as first full-timer to speedup the
  development. Metaxa milestone was set.
OpenDremel Story: 2011
• OpenDremel early design was found too naive, mainly due to
  Java underperformance in inner number-crunching loops.
• After fierce brainstorming, project was restarted from scratch
  under new name Dazo. With Dazo, query plan is an arbitrary
  piece of executable native code with Java frontend.
• From now on we got inspiration from BigQuery as opposed to
  from Dremel paper.
• We decided to use Google NaCl as sandboxing technology to
  isolate queries as well as meter resource consumption. The new
  sandbox was named ZeroVM.
• As for storage we decided to use OpenStack Swift.
OpenDremel Story: 2012

• Four people full-time, several others part time, we still
  don’t have fully integrated version but we are satisfied
  with what we have achieved and convinced that the
  decisions behind Dazo were correct.
• We believe ZeroVM could be a disruptive technology in
  itself revolutionizing BigData@Cloud space.
• We are excited by Apache Drill initiative and hope to be
  useful for it.
Design Tenet #1

• Apache Drill must support multi-tenant semantics
  internally and not to be run in guest VMs altogether.
• It should be inspired by BigQuery and not only by
  Dremel/PowerDrill/Tenzing papers.
• It is not practical to setup a dedicated cloud (billed
  hourly) just to be able to run a query for a few seconds.
• The codebase must be clearly divided into trusted part
  and untrusted part. Trusted part must be kept to
  absolute minimum and must be peer-reviewed, secured,
  audited and metered.
Design Tenet #2

• Apache Drill must be extremely flexible and
  customizable.
• Schema-on-read concept must be supported.
  Imperative high-performance parser code must be
  possible to be embedded into the query.
• SQL is no longer enough. New query languages must
  be easily added as plug-ins or as user-defined-functions
  (UDF).
• Additionally various data-formats must be supported
  like column-stores, row-stores, PAX, RCFiles and etc.
Design Tenet #2 (cont.)

• We suggest that query plan format will be relaxed to
  arbitrary distributed executable code and data
  format relaxed to arbitrary opaque BLOB.
• This way new query languages and new data formats
  could be easily supported without changing backend.
• As added benefit backend becomes generic lightweight
  homogeneous compute-storage cloud.
• Such approach exhibits good separation of control.
  Cloud operator controls an bills for generic
  infrastructure and the query engine is left completely in
  the control of the tenant/user.
Design Tenet #3

• Apache Drill requests/queries must be hyper-elastic
  meaning capability to exploit compute capacity of
  thousands of servers for short duration of just a few
  seconds. No resources must be kept spinning per user
  between queries or when idle.
• Traditional VMs are too heavyweight for that.
  Container approach such as OpenVZ/LXC and etc. are
  not secure enough in multi-tenancy context.
• We suggest making sandboxing pluggable and
  supporting ZeroVM ( developed for OpenDremel ) and
  LXC (is fine for private clouds) to begin with.
Design Tenet #4

•   Apache Drill must be efficient.
•   Value-per-byte is extremely low with BigData.
•   Overhead in the inner loop must be kept to minimum.
•   Java was found inefficient for general number
    crunching (such as data compression). The main
    problem with Java is that GC overhead is unavoidable
    for the whole data corpus being scanned. We went so
    far as to keep all data in byte arrays and auto-generate
    transformation code and it still underperformed and
    code complexity went through the roof.
Suggested Architecture
Browser / Client    Single-Tenant            Multi-Tenant
                      Frontend                Backend
                      running inside      scale-out object store
                   traditional guest VM    and in-situ compute


                         JVM


  Query                  Query
                        Compiler




    Custom
 executable job
OpenDremel/Dazo
   Two separate       We call it Metaxa         We call it Zwift
 unfinished jQuery     (historic reasons)      (Swift + ZeroVM)
apps & cmdline app    BQL Parser, unfinished
 with no particular    compiler based on         Alpha Quality
    codenames           Apache Velocity


                             JVM


  Query                      Query
                            Compiler




     Custom
  executable job
What is Swift?




“Swift is a highly available, distributed,
eventually consistent object/blob store.
Organizations can use Swift to store
lots of data efficiently, safely, and
cheaply.”
Haven’t got it?



Swift is THE open-source
   implementation of
        Amazon S3
What is ZeroVM?




Highly-secure, low-overhead, low-latency container-style
virtualization based on Google Native Client project. The
critical security code is transferred verbatim from Chrome
Browser project and therefore is as secure as Chrome
Browser. More info: http://ZeroVM.org and
http://news.ycombinator.com/item?id=3746222
ZeroVM highlights

1.   Disposable VM per request
2.   HyperElasticity per request
3.   Embeddable into everything
4.   High-performance (x86/ARM)
5.   Erlang inspired clustering
6.   Written in pure C, not deps
Haven’t got it?


ZeroVM to Virtualization
        is what
SQLite is to Databases
Where is the code?

• OpenDremel (1st generation design):
   – http://code.google.com/p/dremel/source/browse?repo=dremel
   – http://code.google.com/p/dremel/source/browse?repo=metaxa

• Dazo (2nd generation design):
   – https://github.com/Dazo-org
Thanks
Camuel Gilyadov,
Email: Camuel@BigDataCraft.com

Apache Drill (ver. 0.1, check ver. 0.2)

  • 1.
    Apache Drill Design proposal from OpenDremel team Camuel Gilyadov & Constantine Peresypkin, Email: Camuel@BigDataCraft.com
  • 2.
    OpenDremel Story: 2010 •Camuel Gilyadov started Dremel implementation on summer 2010 named OpenDremel. • David Gruzman joined the effort a few months later followed by Constantine Peresypkin. • There wasn’t a comprehensive design or architecture. The goal was to get hierarchal-columnar transformation working smoothly and in strict accordance to the Dremel paper. Several working implementations are published by us under Apache License. • Hong San was hired as first full-timer to speedup the development. Metaxa milestone was set.
  • 3.
    OpenDremel Story: 2011 •OpenDremel early design was found too naive, mainly due to Java underperformance in inner number-crunching loops. • After fierce brainstorming, project was restarted from scratch under new name Dazo. With Dazo, query plan is an arbitrary piece of executable native code with Java frontend. • From now on we got inspiration from BigQuery as opposed to from Dremel paper. • We decided to use Google NaCl as sandboxing technology to isolate queries as well as meter resource consumption. The new sandbox was named ZeroVM. • As for storage we decided to use OpenStack Swift.
  • 4.
    OpenDremel Story: 2012 •Four people full-time, several others part time, we still don’t have fully integrated version but we are satisfied with what we have achieved and convinced that the decisions behind Dazo were correct. • We believe ZeroVM could be a disruptive technology in itself revolutionizing BigData@Cloud space. • We are excited by Apache Drill initiative and hope to be useful for it.
  • 5.
    Design Tenet #1 •Apache Drill must support multi-tenant semantics internally and not to be run in guest VMs altogether. • It should be inspired by BigQuery and not only by Dremel/PowerDrill/Tenzing papers. • It is not practical to setup a dedicated cloud (billed hourly) just to be able to run a query for a few seconds. • The codebase must be clearly divided into trusted part and untrusted part. Trusted part must be kept to absolute minimum and must be peer-reviewed, secured, audited and metered.
  • 6.
    Design Tenet #2 •Apache Drill must be extremely flexible and customizable. • Schema-on-read concept must be supported. Imperative high-performance parser code must be possible to be embedded into the query. • SQL is no longer enough. New query languages must be easily added as plug-ins or as user-defined-functions (UDF). • Additionally various data-formats must be supported like column-stores, row-stores, PAX, RCFiles and etc.
  • 7.
    Design Tenet #2(cont.) • We suggest that query plan format will be relaxed to arbitrary distributed executable code and data format relaxed to arbitrary opaque BLOB. • This way new query languages and new data formats could be easily supported without changing backend. • As added benefit backend becomes generic lightweight homogeneous compute-storage cloud. • Such approach exhibits good separation of control. Cloud operator controls an bills for generic infrastructure and the query engine is left completely in the control of the tenant/user.
  • 8.
    Design Tenet #3 •Apache Drill requests/queries must be hyper-elastic meaning capability to exploit compute capacity of thousands of servers for short duration of just a few seconds. No resources must be kept spinning per user between queries or when idle. • Traditional VMs are too heavyweight for that. Container approach such as OpenVZ/LXC and etc. are not secure enough in multi-tenancy context. • We suggest making sandboxing pluggable and supporting ZeroVM ( developed for OpenDremel ) and LXC (is fine for private clouds) to begin with.
  • 9.
    Design Tenet #4 • Apache Drill must be efficient. • Value-per-byte is extremely low with BigData. • Overhead in the inner loop must be kept to minimum. • Java was found inefficient for general number crunching (such as data compression). The main problem with Java is that GC overhead is unavoidable for the whole data corpus being scanned. We went so far as to keep all data in byte arrays and auto-generate transformation code and it still underperformed and code complexity went through the roof.
  • 10.
    Suggested Architecture Browser /Client Single-Tenant Multi-Tenant Frontend Backend running inside scale-out object store traditional guest VM and in-situ compute JVM Query Query Compiler Custom executable job
  • 11.
    OpenDremel/Dazo Two separate We call it Metaxa We call it Zwift unfinished jQuery (historic reasons) (Swift + ZeroVM) apps & cmdline app BQL Parser, unfinished with no particular compiler based on Alpha Quality codenames Apache Velocity JVM Query Query Compiler Custom executable job
  • 12.
    What is Swift? “Swiftis a highly available, distributed, eventually consistent object/blob store. Organizations can use Swift to store lots of data efficiently, safely, and cheaply.”
  • 13.
    Haven’t got it? Swiftis THE open-source implementation of Amazon S3
  • 14.
    What is ZeroVM? Highly-secure,low-overhead, low-latency container-style virtualization based on Google Native Client project. The critical security code is transferred verbatim from Chrome Browser project and therefore is as secure as Chrome Browser. More info: http://ZeroVM.org and http://news.ycombinator.com/item?id=3746222
  • 15.
    ZeroVM highlights 1. Disposable VM per request 2. HyperElasticity per request 3. Embeddable into everything 4. High-performance (x86/ARM) 5. Erlang inspired clustering 6. Written in pure C, not deps
  • 16.
    Haven’t got it? ZeroVMto Virtualization is what SQLite is to Databases
  • 17.
    Where is thecode? • OpenDremel (1st generation design): – http://code.google.com/p/dremel/source/browse?repo=dremel – http://code.google.com/p/dremel/source/browse?repo=metaxa • Dazo (2nd generation design): – https://github.com/Dazo-org
  • 18.