Pig II (11) (Tối ưu hóa và thực thi Pig II) (Tiếng Anh)

UN
Uni24h
0 téléchargements
19
0

Contenu du document

Page 2

Who Am I? • Pig committer and PMC Member • HCatalog committer and mentor • Member of ASF and Incubator PMC • Co-founder of Hortonworks • Author of Programming Pig from O’Reilly Photo credit: Steven Guarnaccia, The Three Little Pigs

Page 4

What Should We Optimize? • Minimize scans – Hadoop is still often I/O bound • Minimize total number of MR jobs • Minimize shuffle size and number of shuffles • Avoid spills to disk • Reduce or remove skew • For small jobs, minimize start-up time 4

Page 5

Pig Deployment No server, all optimization and planning done on the launching machine Job executes on cluster Pig resides on user machine or gateway Hadoop Cluster User machine

Page 6

Pig Guts (i.e. Pig Architecture), p. 1 Logical Plan Pig Latin Load A = LOAD ‘myfile’ AS (x, y, z); B = GROUP A by x; Group C = FILTER B by AST group > 0; D = FOREACH C GENERATE Filter group, COUNT(A); STORE D INTO ‘output’; Foreach Semantic Checks Store 6

Page 7

Pig Guts, p. 2 Logical Plan MapReduce Plan Load Load Map Filter Group Filter Rearrange Filter Rule Group based Reduce Foreach optimizations Foreach Package Store Store Foreach 7

Page 8

Pig Guts, p. 3 MapReduce Plan Map Filter Map Filter Rearrange Rearrange Combine Foreach Physical Reduce optimizations Package Reduce Package Foreach Foreach 8

Page 9

It would be really cool if… Map Map Reduce Reduce Map Map Reduce Reduce What’s the right join algorithm here? Map Even with statistics it would be hard to Reduce know. Need on the fly execution plan rewrites. 9

Page 10

Memory • Java + memory management = oil + water – Java types inefficient memory users (~4x disk size) – Very difficult to tell how much memory you are using • Originally tried to monitor memory use via MXBeans: FAIL! • Now estimate number of records we can hold in memory and spill when we exceed; allow user to tune guess 10

Page 11

Reducing Spills to Disk • Select Map size and io.sort.mb size such that 1 Map produces 1 Combiner • Would be nice if Pig did this automatically • Recent improvements: hash based aggregation in 0.10 11

Page 12

Skew • You are only as fast as your slowest reducer • Data often power law distributed, means one reducer gets 10x+ the data of others • Solution 1, use combiner whenever possible • Solution 2, break rule that all records for a given key go to one reducer; works for order by and join 12

Page 13

Reducing your Reducers • Whenever possible use algorithms that can be done with no reduce –Fragment-replicate join –Merge join –Collected group 13

Page 14

(De)serialization • Data moves between memory and disk often • Need to highly optimize, more work to be done here • Need to do lazy deserialization 14

Page 15

Faster Job Startup • Should be using the distributed cache for Pig jar and UDFs • For small jobs could use LocalJobRunner • Need to try Tenzing approach of having a few tasks spun up and waiting for small jobs 15

Page 16

Improved Execution Models Map Reduce This is unnecessary. Anything that can be Map done in this map can be pushed to the previous reduce. Need MR* Reduce 16

Page 17

Code Generation • Currently Pig physical operators are packaged in jar and pieced together on the backend to construct the data pipeline • Tenzing and others have tried generating code on the fly instead, have seen significant improvements • Downside, need javac on client machine 17

Page 18

Learn More • Read the online documentation: http://pig.apache.org/ • Programming Pig from O’Reilly Press • Join the mailing lists: – user@pig.apache.org for user questions – dev@pig.apache.com for developer issues • Follow me on Twitter, @alanfgates

Affichage des 18 premières pages. Téléchargez le document pour le voir en entier.

Commentaires (0)

Se connecter pour rejoindre la discussion

Aucun commentaire pour le moment. Soyez le premier !