Hive London - Apache Drill

Talk about Apache Drill at Hive London. Besides the explanation of how Drill works and where we are at the moment I contrast Drill with Hive and show how they differ and where they overlap.

Transcript

1. Apache  Drill   interac.ve,  ad-­‐hoc  query  for  large-­‐scale  datasets   Michael  Hausenblas,  Chief  Data  Engineer  EMEA,  MapR     Hive  London,  2013-­‐06-­‐28  
2. Which   workloads  do   you   encounter  in   your   environment?   hIp://www.flickr.com/photos/kevinomara/2866648330/  licensed  under  CC  BY-­‐NC-­‐ND  2.0  
3. Batch  processing   …  for  recurring  tasks  such  as  large-­‐scale  data  mining,  ETL   offloading/data-­‐warehousing  à  for  the  batch  layer  in  Lambda   architecture   Apache  Pig   Cascalog  
4. OLTP   …  user-­‐facing  eCommerce  transacWons,  real-­‐Wme  messaging  at   scale  (FB),  Wme-­‐series  processing,  etc.  à  for  the  serving  layer  in   Lambda  architecture  
5. Stream  processing   …  in  order  to  handle  stream  sources  such  as  social  media  feeds   or  sensor  data  (mobile  phones,  RFID,  weather  staWons,  etc.)  à   for  the  speed  layer  in  Lambda  architecture    
6. Search/InformaWon  Retrieval   …  retrieval  of  items  from  unstructured  documents  (plain   text,  etc.),  semi-­‐structured  data  formats  (JSON,  etc.),  as   well  as  data  stores  (MongoDB,  CouchDB,  etc.)  
7. hIp://www.flickr.com/photos/9479603@N02/4144121838/    licensed  under  CC  BY-­‐NC-­‐ND  2.0   But  what  about   interac.ve   ad-­‐hoc  query     at  scale?  
8. Impala InteracWve  Query  (?)   low-­‐latency  
9. Use  Case:  MarkeWng  Campaign   •  Jane,  a  markeWng  analyst   •  Determine  target  segments   •  Data  from  different  sources    
10. Use  Case:  LogisWcs   •  Supplier  tracking  and  performance   •  Queries   – Shipments  from  supplier  ‘ACM’  in  last  24h   – Shipments  in  region  ‘US’  not  from  ‘ACM’   SUPPLIER_ID   NAME   REGION   ACM   ACME  Corp   US   GAL   GotALot  Inc   US   BAP   Bits  and  Pieces  Ltd   Europe   ZUP   Zu  Pli   Asia   { "shipment": 100123, "supplier": "ACM", “timestamp": "2013-02-01", "description": ”first delivery today” }, { "shipment": 100124, "supplier": "BAP", "timestamp": "2013-02-02", "description": "hope you enjoy it” } …
11. Use  Case:  Crime  DetecWon   •  Online  purchases   •  Fraud,  bilking,  etc.   •  Batch-­‐generated  overview   •  Modes   – ExploraWve   – Alerts  
12. Requirements   •  Support  for  different  data  sources   •  Support  for  different  query  interfaces   •  Low-­‐latency/real-­‐Wme   •  Ad-­‐hoc  queries   •  Scalable,  reliable  
13. And now for something completely different …
14. Google’s  Dremel   hIp://research.google.com/pubs/pub36632.html       Sergey  Melnik,  Andrey  Gubarev,  Jing  Jing  Long,  Geoffrey  Romer,  Shiva  Shivakumar,  Ma@  Tolton,   Theo  Vassilakis,  Proc.  of  the  36th  Int'l  Conf  on  Very  Large  Data  Bases  (2010),  pp.  330-­‐339   Dremel is a scalable, interactive ad-hoc query system for analysis of read-only nested data. By combining multi-level execution trees and columnar data layout, it is capable of running aggregation queries over trillion-row tables in seconds. The system scales to thousands of CPUs and petabytes of data, and has thousands of users at Google. … “ “ Dremel is a scalable, interactive ad-hoc query system for analysis of read-only nested data. By combining multi-level execution trees and columnar data layout, it is capable of running aggregation queries over trillion-row tables in seconds. The system scales to thousands of CPUs and petabytes of data, and has thousands of users at Google. …
15. Google’s  Dremel   multi-level execution trees   columnar data layout  
16. Google’s  Dremel   nested data + schema   column-striped representation   map nested data to tables  
17. Google’s  Dremel   experiments: datasets & query performance  
18. Back to Apache Drill …
19. Apache  Drill–key  facts   •  Inspired  by  Google’s  Dremel   •  Standard  SQL  2003  support   •  Plug-­‐able  data  sources   •  Nested  data  is  a  first-­‐class  ciWzen   •  Schema  is  op.onal   •  Community  driven,  open,  100’s  involved  
20. High-­‐level  Architecture  
21. Principled  Query  ExecuWon   •  Source  query—what  we  want  to  do  (analyst   friendly)   •  Logical  Plan—  what  we  want  to  do  (language   agnosWc,  computer  friendly)   •  Physical  Plan—how  we  want  to  do  it  (the  best   way  we  can  tell)   •  Execu.on  Plan—where  we  want  to  do  it  
22. Principled  Query  ExecuWon   Source   Query   Parser   Logical   Plan   OpWmizer   Physical   Plan   ExecuWon   SQL  2003     DrQL   MongoQL   DSL   scanner  API   Topology   CF   etc.   query: [ { @id: "log", op: "sequence", do: [ { op: "scan", source: “logs” }, { op: "filter", condition: "x > 3” }, parser  API  
23. Wire-­‐level  Architecture   •  Each  node:  Drillbit  -­‐  maximize  data  locality   •  Co-­‐ordinaWon,  query  planning,  execuWon,  etc,  are  distributed   •  Any  node  can  act  as  endpoint  for  a  query—foreman   Storage   Process   Drillbit   node   Storage   Process   Drillbit   node   Storage   Process   Drillbit   node   Storage   Process   Drillbit   node  
24. Wire-­‐level  Architecture   •  Curator/Zookeeper  for  ephemeral  cluster  membership  info   •  Distributed  cache  (Hazelcast)  for  metadata,  locality   informaWon,  etc.   Curator/Zk   Distributed  Cache   Storage   Process   Drillbit   node   Storage   Process   Drillbit   node   Storage   Process   Drillbit   node   Storage   Process   Drillbit   node   Distributed  Cache   Distributed  Cache   Distributed  Cache  
25. Wire-­‐level  Architecture   •  OriginaWng  Drillbit  acts  as  foreman:  manages  query  execuWon,   scheduling,  locality  informaWon,  etc.   •  Streaming  data  communica.on  avoiding  SerDe   Curator/Zk   Distributed  Cache   Storage   Process   Drillbit   node   Storage   Process   Drillbit   node   Storage   Process   Drillbit   node   Storage   Process   Drillbit   node   Distributed  Cache   Distributed  Cache   Distributed  Cache  
26. Wire-­‐level  Architecture   Foreman  turns  into   root  of  the  mulW-­‐level   execuWon  tree,  leafs   acWvate  their  storage   engine  interface.   node   node   node   Curator/Zk  
27. On  the  shoulders  of  giants  …   •  Jackson  for  JSON  SerDe  for  metadata   •  Typesafe  HOCON  for  configuraWon  and  module  management   •  NeWy4  as  core  RPC  engine,  protobuf  for  communicaWon   •  Vanilla  Java,  Larray  and  NeWy  ByteBuf  for  off-­‐heap  large  data  structures   •  Hazelcast  for  distributed  cache   •  Neqlix  Curator  on  top  of  Zookeeper  for  service  registry   •  Op.q  for  SQL  parsing  and  cost  opWmizaWon   •  Parquet  (hIp://parquet.io)/  ORC     •  Janino  for  expression  compilaWon     •  ASM  for  ByteCode  manipulaWon   •  Yammer  Metrics  for  metrics   •  Guava  extensively   •  Carrot  HPC  for  primiWve  collecWons  
28. Key  features   •  Full  SQL  –  ANSI  SQL  2003   •  Nested  Data  as  first  class  ciWzen   •  OpWonal  Schema   •  Extensibility  Points  …  
29. Extensibility  Points   •  Source  query  à  parser  API   •  Custom  operators,  UDF  à  logical  plan   •  Serving  tree,  CF,  topology  à  physical  plan/opWmizer   •  Data  sources  &formats  à  scanner  API   Source   Query   Parser   Logical   Plan   OpWmizer   Physical   Plan   ExecuWon  
30. User  Interfaces   •  API—DrillClient     – Encapsulates  endpoint  discovery   – Supports  logical  and  physical  plan  submission,   query  cancellaWon,  query  status   – Supports  streaming  return  results   •  JDBC  driver,  converWng  JDBC  into  DrillClient   communicaWon.       •  REST  proxy  for  DrillClient  
31. User  Interfaces  
32. …  and  Hive?  
33. Apache  Hive   Apache  Drill   data  manipula.on   read  and  write   read-­‐only   query  language   HiveQL  +  UDF   flexible,  incl.  SQL2003,  MongoQL,   DSL  +  UDF   query  execu.on     MapReduce-­‐based1   Dremel-­‐based   storage  layer   HDFS,  HBase,  MongoDB2   flexible,  incl.  HDFS,  HBase,   MongoDB,  CouchDB,  MySQL,  etc.     columnar  file  formats   focus  on  ORC3   support  for  ORC  and  Parquet     nested  data   through  SerDe   built-­‐in,  first-­‐class  ciWzen   vectorized  execu.on   planned  extension,  status  see   HIVE-­‐4160   per  default,  in  development   schema-­‐level  info   Hive  Metastore   via  discovery;  support  for  Hive   Metastore  is  planned   1)  likely  to  change  with  SWnger   2)  via  hIps://github.com/mongodb/mongo-­‐hadoop     3)  based  on  arWcles  and  communicaWon  with  Owen  O'Malley  
34. LET’S  GET  OUR  HANDS  DIRTY…  
35. Basic  Demo   hIps://cwiki.apache.org/confluence/display/DRILL/Demo+HowTo     { "id": "0001", "type": "donut", ”ppu": 0.55, "batters": { "batter”: [ { "id": "1001", "type": "Regular" }, { "id": "1002", "type": "Chocolate" }, … data  source:  donuts.json   query:[ { op:"sequence", do:[ { op: "scan", ref: "donuts", source: "local-logs", selection: {data: "activity"} }, { op: "filter", expr: "donuts.ppu < 2.00" }, … logical  plan:  simple_plan.json   result:  out.json   { "sales" : 700.0, "typeCount" : 1, "quantity" : 700, "ppu" : 1.0 } { "sales" : 109.71, "typeCount" : 2, "quantity" : 159, "ppu" : 0.69 } { "sales" : 184.25, "typeCount" : 2, "quantity" : 335, "ppu" : 0.55 }
36. SELECT t.cf1.name as name, SUM(t.cf1.sales) as total_sales FROM m7://cluster1/sales t GROUP BY name ORDER BY by total_sales desc LIMIT 10;
37. sequence: [ { op: scan, storageengine: m7, selection: {table: sales}} { op: project, projections: [ {ref: name, expr: cf1.name}, {ref: sales, expr: cf1.sales}]} { op: segment, ref: by_name, exprs: [name]} { op: collapsingaggregate, target: by_name, carryovers: [name], aggregations: [{ref: total_sales, expr: sum(name)}]} { op: order, ordering: [{order: desc, expr: total_sales}]} { op: store, storageengine: screen} ]
38. { @id: 1, pop: m7scan, cluster: def, table: sales, cols: [cf1.name, cf2.name] } { @id: 2, op: hash-random-exchange, input: 1, expr: 1 } { @id: 3, op: sorting-hash-aggregate, input: 2, grouping: 1, aggr:[sum(2)], carry: [1], sort: ~agrr[0] } { @id: 4, op: screen, input: 4 }
39. ExecuWon  Plan   •  Break  physical  plan  into  fragments   •  Determine  quanWty  of  parallelizaWon  for  each   task  based  on  esWmated  costs   •  Assign  parWcular  nodes  based  on  affinity,  load   and  topology  
40. ExecuWon  Plan   node   node   node  
41. BE  A  PART  OF  IT!  
42. Status   •  Heavy  development  by  mulWple  organizaWons   •  Available   – Logical  plan  (ADSP)   – Reference  Interpreter   – SQL  parser   – Basic  demo   – Alpha  of  distributed  version  
43. Status   June/July  2013     •  HBase  storage  engine   •  MySQL  storage  engine   •  RESTful  interface/WebUI  client   •  Zero-­‐config  alpha  deployment  
44. ContribuWng   ContribuWons  appreciated—not  only  code  drops  …     •  Test  data  &  test  queries   •  Use  case  scenarios  (textual/SQL  queries)   •  DocumentaWon    
45. Kudos  to  …   •  Julian  Hyde,  Pentaho     •  Lisen  Mu,  XingCloud   •  Tim  Chen,  Microsox   •  Chris  Merrick,  RJMetrics     •  David  Alves,  UT  AusWn   •  Sree  Vaadi,  SSS   •  Srihari  Srinivasan,  ThoughtWorks   •  Alexandre  Beche,  CERN   •  Jason  Altekruse,  MapR   •  Ben  Becker,  MapR   •  Jacques  Nadeau,  MapR   •  Ted  Dunning,  MapR   •  …  
46. Engage!   •  Follow  @ApacheDrill  on  TwiIer   •  Sign  up  at  mailing  lists  (user  |  dev)     hIp://incubator.apache.org/drill/mailing-­‐lists.html       •  Standing  G+  hangouts  every  Tuesday  at  5pm  GMT   hIp://j.mp/apache-­‐drill-­‐hangouts     •  Keep  an  eye  on  hIp://drill-­‐user.org/