Hadoop and the Data Scientist

13,994 views

Published on

Published in: Technology, Business

Hadoop and the Data Scientist

  1. 1. Hadoop     and    the  Data  Scien/st 第2回NHNテクノロジーカンファレンス  (2012/08/18) Takahiro  Inoue  (@doryokujin)   Treasure  Data,  Inc.   Chief  Data  Scien/st
  2. 2. Introduc/on •  Takahiro  Inoue  (TwiFer:  @doryokujin  )  •  Majored  in  Mathema/cs  •  Chief  Data  Scien/st  @  Treasure-­‐Data  •  Leader  of  Japanese  MongoDB   Community,  Mongo  Masters  
  3. 3. Challenges  with   building  your  own   cloud  based  data   warehouse   Treasure Data High-Level Architecture Log Data Spread Sheets BI ToolsApplication Data Treasure Data Subscribe Data Warehouse SQL td-agent Operational 3rd Party Data Interface Analytics JDBC ODBC Databases Sensor DataWeb/Mobile Data CLI
  4. 4. Agenda:  Data  Scien/stの立場からのHadoop利用   〜4つの  Business  Goal  から考える〜       Hadoop  PlaVorm Our  Business  Goals   Monitoring BI  Tools Data  Analysis ML  /  Graph  Mining 思考フロー   1.  Goalの設定:  上記の4つのBusiness  Goalの内,どれを実行するか   2.  ツールの選択:  最適なツールの選択,その上で何を出すか(分析するか)の決定   3.  中間データ形式の選択:  ツールが使用するためのデータの構造・持ち方の検討   4.  Hadoopの活用:  3.  を(HDFS/S3上の)元データからどのようにして取ってくるか  
  5. 5. Intermediate   Business   What  Helps? Data  Insight Granularity Aggregator Batch  Process Data Interac/ve Goal Date,  Product  Category,  Area     Hive Database Monitoring Human  Decision PIG-­‐2167 Pig Cube BI  Tools User  Id MapReduce File  /  HDFS Data  Analysis Machine  Learning Mahout ML  /     Deep Small Auto Graph  Mining Hama/Giraph
  6. 6. Intermediate   Business   Aggregator Batch  Process Data Interac/ve Goal Hive Database Monitoring SQL-­‐like Query  Language Hadoop Google Cube BI  Tools Main     Topic Tenjing File  /  HDFS Data  Analysis Dremel Ad-­‐hoc  Queries PowerDrill BI  Tools
  7. 7. Why  Hive  is  Good  for  Data  Scien/st?   SQL-­‐style  Query  Language   –  ラーニングコストが低い   Monitoring –  情報が多い(実行したいクエリの例を入手しやすい)   –  Join,  Group  by,  Where  (Having)  の概念は馴染みやすい     JDBC/ODBC  Driver   –  大多数のBIツールがJDBC/ODBCに対応している   BI  Tools –  独自ツールでも接続できる可能性が増す   For  R/Excel/SPSS   –  解析に必要なデータセットを素早く得られる  Data  Analysis –  Hiveの出力データ構造と解析ツールの入力形式の親和性   –  入力データ抽出→解析→入力データ修正→…  のイテレーションが容易    
  8. 8. 1.  Monitoring  hRp://www.metricinsights.com/ hRp://www.geckoboard.com/   hRps://www.leUronic.com/ hRp://www.chartbeat.com/
  9. 9. Monitoring  Goal   –  毎日更新されるデータ  (KPI)  を素早く参照する   –  解析者に関わらず全てのユーザーが参照する   –  異常値やイベントなどの効果を素早く把握する   –  Smart  Phone  や  Tablet  からも参照する  Demand   –  異常検出機能,およびアラート機能を備えていること   –  チャートへのアノテーション機能を備えていること   –  チャートの一覧性・わかりやすさを重視していること   –  (任意の時間インターバルでの)データ自動更新機能を持っていること   –  素早く編集可能な互いに独立したパネル(ウィジェット)を持っていること   –  様々なデータベース・ファイル形式と接続できるコネクタを備えていること  
  10. 10. Monitoring  Intermediate  Data  Format    Very  Simple  Data  Format:  Tuple  or  Triplet   –  Tuple:      {  dateYme,  numeric  value  },   –  Triplet:  {  dateYme,  segment  name,  numeric  value  }   Database Hive  Query  (Ex.  Hourly  Sales  Segmented  by  Item  )   SELECT  date,  segment,  COUNT(disYnct  userid)   FROM  some_metric   Date Segment Value WHERE  1345262400  <=  Ymestamp   2012-­‐08-­‐18  13:00 Item  A $10,000 AND    Ymestamp  <  1345266000   2012-­‐08-­‐18  13:00 Item  B $8,000 2012-­‐08-­‐18  13:00 Item  C $6,000 GROUP  BY  segment   … … … 2012-­‐08-­‐18  14:00 Item  A $7000
  11. 11. Monitoring  Example:  Metricinsights   –  アラート・アノテーション機能   –  1つ1つのパネル(ウィジェット)にクエリを埋め込める   –  {  クエリ,  集計インターバル,  チャートタイプ,  データソース  }  指定のみで自動更新   –  ピボットテーブル,{  バブル,  ボックス,  ファンネル }  チャートにも対応    
  12. 12. 2.  Business  Intelligence  hRp://www.tableausoUware.com/ hRp://www.indicee.com/   hRp://www.gooddata.com/ hRp://www.birst.com/
  13. 13. Business  Intelligence  Goal   –  Overview  first,  zoom  and  filter,  then  details-­‐ondemand   –  様々の切り口・セグメントの組合せでデータを閲覧する   –  インタラクティブな操作でドリルダウンや軸の切り替えを行う   –  様々なチャートとテーブルを組合せた情報表現を行う   –  プレゼンに耐えうるクオリティの高いレポートを作成する    Demand     –  インタラクティブな操作が可能なこと   –  豊富なチャートライブラリ,ダッシュボードエディタの実装していること   –  最適化された中間データ構造(Data  Cubeなど)を備えていること   –  マウス操作によってデータの深堀りや切り口の切り替えが可能なこと   –  JDBC  /  ODBC  コネクタを初めとした様々なデータソースとの接続口を持つこと  
  14. 14. Business  Intelligence  Intermediate  Data  Format   –  Data  Cube: dimension,level-­‐of-­‐detail  を固定することで各dimension  を次元軸に,値を各セ ルに取ったData  Cubeを作成できる Ex.  Cube  for  (  Country,  Car  Name,  Year  ) Products     Date   Car  Name   Level Cell:   (  Prius,  Korea,  2005)     PRIUS   -­‐-­‐>  10,000 MARK  X   2007   FAIRLADY  Z   2006   Year     Level ROAD  STAR   2005   Loca/on   USA   Canada   Japan   Korea   Country   Level  
  15. 15. Business  Intelligence  Star  Schema  Dimension  tables   Fact  table  Loca/on   State   Date  Country   Hierarchy Month   Year  State   (level-of-detail) Car  Name   Month  City     Profit   Day   Sales  Products   Payroll  Company   Marke/ng  Car  Type   Inventory  Car  Name   Margin   ...   Hierarchy Car  
  16. 16. Business  Intelligence  Cube  Lacce  (Loca/on  +  Company)   Hive  Query   Algebraic  Measure:  f(x+y)  =  f(x)  +  f(y)     Most  Detailed <city,  car  name> (SUM,  STD_DEV)は,最下層のdimension の組合せ集計のみ保持しておけば,上位 階層は和をとる事で導出可能。 <state,  car  name> <city,  car  type> GRUP  BY          country,  state,  city,        company,  car_type,  car_name <country,  car  name> <state,  car  type> <city,  company> Holis/c  Measure   (TOP-­‐K,  MODE,  MEDIAN)は,全ての層で <*,  car  name> <country,  car  type> <state,  company> <city,  *> 集計を行う必要がある。 GROUP  BY          country,  state,  city,     <*,  car  type> <country,  company> <state,  *>      company,  car_type,  car_name   UNION  ALL   GROUP  BY          country,  state,  city,     <*,  company> <country,  *>      company,  car_type   …   UNION  ALL   <*,  *> GROUP  BY     Least  Detailed        country,  company   …  
  17. 17. Business  Intelligence   *  Date  Dimension  はツール側で自動的にlevelを考慮してくれる Intermediate  Data  Format   –  For  Algebraic  Measures   Algebraic   Most  Detailed  Dimensions Measures County State City Company Car  Type Car  Name Date Units Sales Most  Detailed  Dimensions   USA California San  Jones TOYOTA Sedan   Corolla   2012-­‐08-­‐15 36 $3,000 <city,  car  name> USA California Palo  Alto TOYOTA Sedan Alion 2012-­‐08-­‐15 24 $2,000 USA California Los  Altos NISSAN SUV X-­‐TRAIL 2012-­‐08-­‐16 100 $1,000 USA New  York ManhaRan NISSAN Sport FAIRLADY  Z 2012-­‐08-­‐16 64 $500 Canada Alberta Airdrie MAZDA Sport Road  Star 2012-­‐08-­‐15 4 $3,000 LocaYon  Hierarchy Products  Hierarchy Date  Hierarchy Holis/c   –  For  HolisYc  Measures  (tend  to  become  very  large  table)   Measure <city ,  car County State City Company Car  Type Car  Name Date Avg  of  Top  20  nam<sta e> te,  c USA California San  Jones TOYOTA Sedan   Corolla   2012-­‐08-­‐15 $3,600 ar  n<cou ame nty, > USA California ALL TOYOTA Sedan Alion 2012-­‐08-­‐15 $2,400  car   <*,  c nam eUSA > ALL ALL NISSAN SUV X-­‐TRAIL 2012-­‐08-­‐16 $1,000 ar  n<cou ame ntry > ALL ALL ALL NISSAN Sport FAIRLADY  Z 2012-­‐08-­‐16 $640 ,  car<cou  typ ntry eUSA > California San  Jones TOYOTA Sedan   ALL   2012-­‐08-­‐15 $3,600 ,  car  nam <cou e> USA California San  Jones TOYOTA ALL ALL 2012-­‐08-­‐15 $1,100 ntry ,  *> USA California San  Jones ALL ALL ALL 2012-­‐08-­‐15 $2,300 … … … … … … … … <*,  * > ALL ALL ALL ALL ALL ALL ALL $720
  18. 18. Business  Intelligence  Problem   –  Dimension  +  Level  の組合せによる (1)  計算量・(2)  レコード数の爆発に注意   –  HiveはCube生成のための関数群を持たないため,UNION  ALL  を多用するので (3)  SQLが長くなる   –  (4)Cubeが大きければBI側の操作も遅くなる   –  必要な Dimension,  Level  を適切に定義することは重要   –  BI  ツールは比較的高価なので,インフラ側のコストだけに気を取られないように  Solu/on  for  (1):  MR  CUBE     –  MapReduceを利用して効率良くHolisYc  MeasuresのCubeを求める方法   –  MR-­‐CUBE:  Distributed  Cube  MaterializaYon  on  HolisYc  Measures     –  MR  CUBEは次のポイントを抑えた  2-­‐phase  cube  materializaYon  algorithm:   1.   Par/ally  Algebraic  Measures  (Subset  of  HolisYc  Measures)  の導入   2.   Value  Par//oning  と Batch  Area  Iden/fica/on  テクニックの利用   –  Pig  にも実装提案。 MR-­‐Cube  implementaYon  (pig-­‐2831)  
  19. 19. Business  Intelligence   Polaris:  Visual  Abstrac/on   –  A  UI  for  exploraYon,  analysis  for  Data  Cube   –  A  formal  Language  for  specifying  queries  &  visualizaYons   Data   abstrac/on   VIsual  abstrac/on   hRp://www.graphics.stanford.edu/projects/polaris/infovis2002.ppt
  20. 20. Business  Intelligence  Example:  Tableau   –   大多数の企業の導入実績(Zynga,  Nokia,  eBay,  etc…)   –   Polaris:  Visual  AbstracYon  ⇔  Cube:  Data  AbstracYon   –   豊富なチャートライブラリとデータソースコネクタを持つ  
  21. 21. Business  Intelligence  Reference   –  2012  Gartner  Magic  Quadrant  Report   –  The  Forrester  Wave(TM):  Advanced  Data  VisualizaYon  (ADV)  Plavorms,  Q3  2012     Gartner  Magic  Quadrant  Report  
  22. 22. Google’s  Solu/on   Cube  OperaYon Tenjing Cube Dremel eries Ad-­‐ hoc  Qu BI  Tools PowerDrill
  23. 23. Tenjing:  SQL  Implementa/on  on  MR  Solu/on  for  (3):  Tenjing   –  Tenzing:  A  SQL  ImplementaYon  on  The  MapReduce  Framework   –  MapReduce  Enhancements   •  Worker  Pool:  (1)  master  watcher  /  (2)  master  pool  /  (3)  worker  pool   •  Streaming  &  In-­‐memory  Chaining:  中間データをGFSに保存せず,Streaming  でMR間をつなぐ   •  Sort  Avoidance:  Hash  Join  や  Hash  AggregaYon  などではSortしない   •  Block  Shuffle:  Row  SerializaYon,  DeserializaYon  の効率化   –  主にGoogle内の非エンジニアコミュニティが使用   –  1000  Users,  2  Data  Centers,  2000  Cores,  1.5PB  of  Compressed  Data   –  Hiveよりも進んだSQL  Extensionを実装:   1.  HASH  BASED  AGGREGATION   •  Reduce上でのsortが不要に  →  パフォーマンスの向上   2.  Analy/c  Func/ons   •  RANK,  LEAD,  LAG,  NTILE   3.  OLAP  Extensions   •  ROLLUP,  CUBE  →  Cubeの作成が容易に  
  24. 24. Dremel:  Interac/ve  Analysis  of  Large-­‐Scale  Datasets   message Document { required int64 DocId;Solu/on  for  (4):  Dremel   optional group Links { repeated int64 Backward; repeated int64 Forward; –  Dremel:  InteracYve  Analysis  of  Web-­‐Scale  Datasets   } repeated group Name { repeated group Language { –  Scalable,  InteracYve  Ad-­‐hoc  Query  System   required string Code; optional string Country; } –  Nested  Columnar  Storage   optional string Url; } •  各レコードをColumnar  Formatへ変換   } •  構造情報を保持するための2つの値:  (1)  RepeYYon  Levels  (2)  DefiniYon  Levels   –  SQL-­‐like  query  language   DocId: 10 Links •  Nested  Data  Support   Forward: 20 Forward: 40 •  MulY-­‐level  ExecuYon  Trees   Forward: 60 Name •  Read-­‐only  Ad-­‐hoc  Query   Language Code: en-us Country: usBig  Query   Language Code: en Url: http://A –  Hosted  Dremel  (Dremel  as  a  Service)   Name Url: http://B Name –  WHERE,  AggregaYon  FuncYons,  サブクエリ、中間テーブル作成,  部分 Language Code: en-gb 一致検索、部分的なJOIN(相手テーブルが数MB以下のもの)   Country: gb –  Google  Cloud  Storage  へのデータインポート   DocId: 20 Links •  Nested  Data  Format非対応   Backward: 10 Backward: 30 •  現状はCSVファイルのみ,スキーマ定義必須   Forward: 80 Name Url: http://C
  25. 25. PowerDrill:  Alterna/ve  Columnar  Storage  Solu/on  for  (4):  PowerDrill   –  Processing  a  Trillion  Cells  per  Mouse  Click   –  InteracYve  Ad-­‐hoc  Query  System  (Dremel  とは違ってNested構造は扱わない)   –  Google内ではInteracYveなWebUIを実現するために使用。(マウスのクリックによるド リルダウン操作が瞬時にSQLクエリに変換されPowerDrillを通じて瞬時に結果を返す)   –  AnalyYcsに関して,次の仮定に基づいた設計:   •  大量のデータをスキャンする必要はあるが,ほとんどのデータは使用されない   •  The  majority  of  queries  are  fairly  discriminaYve,  similar,  uniform  →  キャッシュが有効に使える   –  Composite  Range  ParYYoning:     •  データインポート時にデータを細かいChunkに分割   •  カラム毎に,値特定のために2つのdictを使用:  (1)  global-­‐dicYonary  /  (2)  chunk-­‐dicYonary   •  これらによってQuery実行時にChunkを読み込むかスキップするかを瞬時に判断   •  統計的に95%のChunkがスキップされる→瞬時に結果を返すことが可能   •  Chunk単位で圧縮してメモリーキャッシュして再利用  
  26. 26. 3.  Data  Analysis  hRp://www.r-­‐project.org/ hRp://www-­‐06.ibm.com/soUware/jp/analyYcs/spss/products/staYsYcs/   hRp://numpy.scipy.org/ hRp://www.gigawiz.com/
  27. 27. Data  Analysis  Goal   –  データを「見る」から「分析する」へ   –  CubeのDimensionのような粒度ではなく,UserIDやItemIDといった細かい粒度   –  様々な統計手法を用いて(実際に現場実行可能な)パターンやモデルを見出す   –  解析用データ「抽出」はHadoop(サーバー側),「分析」はR/Excel/SPSS(クライ アント)側で行う  Demand   –  シングルマシンで分析できる程度のデータ量に抑えること   (*時系列解析以外の分析は特定調査期間でのデータ取得になるのでデータ量 は全ユーザー数,全アイテム数に等しい→  高々数百万レコード程度)   –  Hadoop側に任せられる部分(抽出・データ前処理)とクライアント解析ツールで しかできない部分をうまく切り分けられること  
  28. 28. Data  Analysis  Example:  Survival  Analysis  For  Web  Service   –  ユーザーの「退会」というイベントが発生するまでの時間(生存時間)に関する分析   –  この分析によって以下のような事がわかる:   •  「入会からnヶ月後にはx%のユーザーが辞めてしまう」   •  「m1〜m2日目の間がユーザーの退会リスクが高い」   •  「セグメントAはBに比べて生存時間が長い(優良顧客である)」   –  特定の調査期間でイベントを観測できるユーザーと,観測できない(調 査以降も生存している:右側打ち切り)ユーザーの2種類のパターンが 存在。双方を考慮して,推定を行う必要がある  
  29. 29. Data  Analysis  Intermediate  Data  Format   Userid Time  To  Event  (Days) Flag  Event  Occurred Device(Segment  ) Country(Segment  ) 000001 12 1 Smart  Phone Japan 000002 36 0 PC USA 000003 120 0 Smart  Phone USA … … … … … 100000 1 1 PC Japan File  /  HDFS Hive  Query     SELECT  uid,  datediff(latest_login,  registered_day)  AS  Yme_to_event,                                  flag_event_occurred,  device,  country   …   FROM  …  #  event  occurred   UNION  ALL  …  #  !event  occurred  
  30. 30. Data  Analysis  R  Smaple  Code:    >  library(survival)  >  surv  <-­‐  read.csv("./survival.csv",  header=T)  >  my.surv  <-­‐Surv(surv$Yme_to_event,surv$flag_event_occurred)  >  my.fit  <-­‐  survfit(my.surv  ~  1)  >  summary(my.fit)  Call:  survfit(formula  =  my.surv  ~  1)      Yme  n.risk  n.event  survival    std.err  lower  95%  CI  upper  95%  CI          1    66028      32032      0.5149  0.001945              0.5111              0.5187          2    33996        3503      0.4618  0.001940              0.4580              0.4656          3    30444        1857      0.4336  0.001929              0.4299              0.4374          4    28540        1258      0.4145  0.001918              0.4108              0.4183  …  >  plot(my.fit,  main="Kaplan-­‐Meier  esYmate  with  95%  confidence  bounds",  xlab="Yme",  ylab="survival  funcYon”)  >  H.hat  <-­‐  -­‐log(my.fit$surv);  H.hat  <-­‐  c(H.hat,  H.hat[length(H.hat)])  >  h.sort.of  <-­‐  my.fit$n.event  /  my.fit$n.risk  >  H.Ylde  <-­‐  vector()  for(i  in  1:length(h.sort.of))  H.Ylde[i]  <-­‐  sum(h.sort.of[1:i])  >  H.Ylde  <-­‐  c(H.Ylde,  H.Ylde[length(H.Ylde)])  >  plot(c(my.fit$Yme,  250),  H.hat,  xlab=Yme,  ylab=cumulaYve  hazard’,main=comparingcumulaYve  hazards,  ylim=range(c(H.hat,  H.Ylde)),  type=s’)  >  points(c(my.fit$Yme,  250),  H.Ylde,  lty=2,  type=s’)  >  legend(locator(1),  c("H.hat","H.Ylde"),  lty=1:2)  
  31. 31. Kaplan-Meier estimate with 95% confidence bounds 1.0 ←図1.  生存関数曲線     0.8 •  期間0(登録日)で100%だった ユーザーが期間x後には何% 0.6survival function 生き残っているかを示す   0.4 •  この例では初めの1日目で 50%以上が退会してしまって 0.2 いることがわかる 0.0 0 50 100 150 200 250 time comparing cumulative hazards 3.5 図2.  累積ハザード曲線  →   3.0   •  どの期間において「退会する」 2.5 cumulative hazard リスクが大きいか(傾きが急な 2.0 部分)を示す累積曲線   1.5 •  この例では初日を急勾配とし て,初めの10日間はリスクが 1.0 H.hat 大きい H.tilde 0.5 0 50 100 150 200 250 time
  32. 32. まとめ   –  データを「見る」という目的にも Monitoring  Tool  と BI  Tool  が存在し,その特徴 は異なる(共通する部分も多い)   –  Hadoop側のBatch処理とBI  Tool側のAd-­‐hocな要請とのギャップをどう埋めるか   –  Ad-­‐hoc  Queryに関する今後の技術動向に注目   –  データを「見る」環境の構築構築は統計の専門家でなくても可能(「Data-­‐Driven 」な意思決定文化の構築が最も重要)   –  分析を行う際も「分析用データ抽出フェーズ(大規模集計)」と「分析フェーズ」 をうまく切り分ける     Offices:   -­‐  HQ:  Los  Altos,  CA   -­‐  Development  Center:  Tokyo,  Japan   Contact:   -­‐  taka@treasure-­‐data.com  

×