Slide 1

Slide 1 text

Mining Big Data Streams Better Algorithms or Faster Systems? 
 
 Gianmarco De Francisci Morales
 [email protected]
 @gdfm7

Slide 2

Slide 2 text

Vision Algorithms & Systems Distributed stream mining platform Development and collaboration framework
 for researchers Library of state-of-the-art algorithms
 for practitioners 2

Slide 3

Slide 3 text

Agenda SAMOA
 (Scalable Advanced Massive Online Analysis) VHT
 (Vertical Hoeffding Tree) PKG
 (Partial Key Grouping) 3 System Algorithm API

Slide 4

Slide 4 text

Visiting Scientist 
 @Aalto DMG Scientist @Yahoo Labs PPMC @ Apache SAMOA Committer @ Apache Pig Contributor for Hadoop, 
 Giraph, Storm, S4, Grafos.ml 4

Slide 5

Slide 5 text

What do I work on? Systems Distributed Mining News Streaming Grid Admin —2008 —2009 —2010 —2011 —2012 —2013 -—2014 -—2015 • IMT Lucca • M.Eng • Y!R Barcelona • PhD 5 PhD Student Postdoc Scientist

Slide 6

Slide 6 text

“Panta rhei”
 (everything flows) -Heraclitus 6

Slide 7

Slide 7 text

Importance$of$O •  As$spam$trends$change retrain$the$model$with Importance Example: spam detection in comments on Yahoo News Trends change in time Need to retrain model with new data 7

Slide 8

Slide 8 text

Stream Batch data is a snapshot of streaming data 8

Slide 9

Slide 9 text

Challenges Operational Need to rerun the pipeline and redeploy the model when new data arrives Paradigmatic New data lies in storage without generating new value until new model is retrained 9 Gather Clean Model Deploy

Slide 10

Slide 10 text

Present of big data Too big to handle 10

Slide 11

Slide 11 text

Future of big data Drinking from a firehose 11

Slide 12

Slide 12 text

Evolution of SPEs 12 —2003 —2004 —2005 —2006 —2008 —2010 —2011 —2013 Aurora STREAM Borealis SPC SPADE Storm S4 1st generation 2nd generation 3rd generation Abadi et al., “Aurora: a new model and architecture for data stream management,” VLDB Journal, 2003 Arasu et al., “STREAM: The Stanford Data Stream Management System,” Stanford InfoLab, 2004. Abadi et al., “The Design of the Borealis Stream Processing Engine,” in CIDR ’05 Amini et al., “SPC: A Distributed, Scalable Platform for Data Mining,” in DMSSP ’06 Gedik et al., “SPADE: The System S Declarative Stream Processing Engine,” in SIGMOD ’08 Neumeyer et al., “S4: Distributed Stream Computing Platform,” in ICDMW ’10 http://storm-project.net Samza http://samza.incubator.apache.org

Slide 13

Slide 13 text

Actor Model 13 PE PE Input Stream PEI PEI PEI PEI PEI Output Stream Event routing

Slide 14

Slide 14 text

Paradigm Shift 14 Gather Clean Model Deploy + =

Slide 15

Slide 15 text

Apache SAMOA Scalable Advanced Massive Online Analysis
 G. De Francisci Morales, A. Bifet
 JMLR 2015 15

Slide 16

Slide 16 text

Taxonomy 16 Data Mining Distributed Batch Hadoop Mahout Stream Storm, S4, Samza SAMOA Non Distributed Batch R, WEKA, … Stream MOA

Slide 17

Slide 17 text

What about Mahout? SAMOA = Mahout for streaming But… More than JBoA (just a bunch of algorithms) Provides a common platform Easy to port to new computing engines 17

Slide 18

Slide 18 text

Architecture 18 SA SAMOA%

Slide 19

Slide 19 text

Status Status 19 https://samoa.incubator.apache.org

Slide 20

Slide 20 text

Status Status Parallel algorithms 19 https://samoa.incubator.apache.org

Slide 21

Slide 21 text

Status Status Parallel algorithms Classification (Vertical Hoeffding Tree) 19 https://samoa.incubator.apache.org

Slide 22

Slide 22 text

Status Status Parallel algorithms Classification (Vertical Hoeffding Tree) Clustering (CluStream) 19 https://samoa.incubator.apache.org

Slide 23

Slide 23 text

Status Status Parallel algorithms Classification (Vertical Hoeffding Tree) Clustering (CluStream) Regression (Adaptive Model Rules) 19 https://samoa.incubator.apache.org

Slide 24

Slide 24 text

Status Status Parallel algorithms Classification (Vertical Hoeffding Tree) Clustering (CluStream) Regression (Adaptive Model Rules) Execution engines 19 https://samoa.incubator.apache.org

Slide 25

Slide 25 text

Is SAMOA useful for you? Only if you need to deal with: Large fast data Evolving process (model updates) What is happening now? Use feedback in real-time Adapt to changes faster 20

Slide 26

Slide 26 text

Advantages (operational) Avoid deploy cycle No need to choose update frequency No system downtime No complex backup/update procedures Program once, run everywhere Reuse existing computational infrastructure 21

Slide 27

Slide 27 text

Advantages (paradigmatic) Model freshness Immediate data value No stream/batch impedance mismatch 22

Slide 28

Slide 28 text

PE PE PEI PEI PEI PEI Groupings Key Grouping 
 (hashing) Shuffle Grouping
 (round-robin) All Grouping
 (broadcast) 23

Slide 29

Slide 29 text

PE PE PEI PEI PEI PEI Groupings Key Grouping 
 (hashing) Shuffle Grouping
 (round-robin) All Grouping
 (broadcast) 24

Slide 30

Slide 30 text

PE PE PEI PEI PEI PEI Groupings Key Grouping 
 (hashing) Shuffle Grouping
 (round-robin) All Grouping
 (broadcast) 24

Slide 31

Slide 31 text

PE PE PEI PEI PEI PEI Groupings Key Grouping 
 (hashing) Shuffle Grouping
 (round-robin) All Grouping
 (broadcast) 24

Slide 32

Slide 32 text

PE PE PEI PEI PEI PEI Groupings Key Grouping 
 (hashing) Shuffle Grouping
 (round-robin) All Grouping
 (broadcast) 25

Slide 33

Slide 33 text

PE PE PEI PEI PEI PEI Groupings Key Grouping 
 (hashing) Shuffle Grouping
 (round-robin) All Grouping
 (broadcast) 25

Slide 34

Slide 34 text

PE PE PEI PEI PEI PEI Groupings Key Grouping 
 (hashing) Shuffle Grouping
 (round-robin) All Grouping
 (broadcast) 25

Slide 35

Slide 35 text

PE PE PEI PEI PEI PEI Groupings Key Grouping 
 (hashing) Shuffle Grouping
 (round-robin) All Grouping
 (broadcast) 26

Slide 36

Slide 36 text

PE PE PEI PEI PEI PEI Groupings Key Grouping 
 (hashing) Shuffle Grouping
 (round-robin) All Grouping
 (broadcast) 26

Slide 37

Slide 37 text

PE PE PEI PEI PEI PEI Groupings Key Grouping 
 (hashing) Shuffle Grouping
 (round-robin) All Grouping
 (broadcast) 26

Slide 38

Slide 38 text

VHT Vertical Hoeffding Tree
 A. Murdopo, A. Bifet, G. De Francisci Morales, N. Kourtellis
 (under submission) 27

Slide 39

Slide 39 text

Decision Tree Nodes are tests on attributes Branches are possible outcomes Leafs are class assignments
 
 28 Class Instance Attributes Road Tested? Mileage? Age? No Yes High ✅ ❌ Low Old Recent ✅ ❌ Car deal?

Slide 40

Slide 40 text

Hoeffding Tree Sample of stream enough for near optimal decision Estimate merit of alternatives from prefix of stream Choose sample size based on statistical principles When to expand a leaf? Let x1 be the most informative attribute,
 x2 the second most informative one Hoeffding bound: split if 29 G ( x1, x2) > ✏ = r R 2 ln(1 / ) 2 n P. Domingos and G. Hulten, “Mining High-Speed Data Streams,” KDD ’00

Slide 41

Slide 41 text

Parallel Decision Trees 30

Slide 42

Slide 42 text

Parallel Decision Trees Which kind of parallelism? 30

Slide 43

Slide 43 text

Parallel Decision Trees Which kind of parallelism? Task 30

Slide 44

Slide 44 text

Parallel Decision Trees Which kind of parallelism? Task Data 30 Data Attributes Instances

Slide 45

Slide 45 text

Parallel Decision Trees Which kind of parallelism? Task Data Horizontal 30 Data Attributes Instances

Slide 46

Slide 46 text

Parallel Decision Trees Which kind of parallelism? Task Data Horizontal Vertical 30 Data Attributes Instances

Slide 47

Slide 47 text

Horizontal Parallelism Y. Ben-Haim and E. Tom-Tov, “A Streaming Parallel Decision Tree Algorithm,” JMLR, vol. 11, pp. 849–872, 2010 31 Stats Stats Stats Stream Histograms Model Instances Model Updates 31

Slide 48

Slide 48 text

Horizontal Parallelism Y. Ben-Haim and E. Tom-Tov, “A Streaming Parallel Decision Tree Algorithm,” JMLR, vol. 11, pp. 849–872, 2010 31 Stats Stats Stats Stream Histograms Model Instances Model Updates 31

Slide 49

Slide 49 text

Horizontal Parallelism Y. Ben-Haim and E. Tom-Tov, “A Streaming Parallel Decision Tree Algorithm,” JMLR, vol. 11, pp. 849–872, 2010 31 Stats Stats Stats Stream Histograms Model Instances Model Updates 31

Slide 50

Slide 50 text

Horizontal Parallelism Y. Ben-Haim and E. Tom-Tov, “A Streaming Parallel Decision Tree Algorithm,” JMLR, vol. 11, pp. 849–872, 2010 31 Stats Stats Stats Stream Histograms Model Instances Model Updates 31

Slide 51

Slide 51 text

Horizontal Parallelism Y. Ben-Haim and E. Tom-Tov, “A Streaming Parallel Decision Tree Algorithm,” JMLR, vol. 11, pp. 849–872, 2010 31 Stats Stats Stats Stream Histograms Model Instances Model Updates 31

Slide 52

Slide 52 text

Horizontal Parallelism Y. Ben-Haim and E. Tom-Tov, “A Streaming Parallel Decision Tree Algorithm,” JMLR, vol. 11, pp. 849–872, 2010 31 Stats Stats Stats Stream Histograms Model Instances Model Updates 31

Slide 53

Slide 53 text

Horizontal Parallelism Y. Ben-Haim and E. Tom-Tov, “A Streaming Parallel Decision Tree Algorithm,” JMLR, vol. 11, pp. 849–872, 2010 31 Stats Stats Stats Stream Histograms Model Instances Model Updates 31

Slide 54

Slide 54 text

Horizontal Parallelism Y. Ben-Haim and E. Tom-Tov, “A Streaming Parallel Decision Tree Algorithm,” JMLR, vol. 11, pp. 849–872, 2010 31 Stats Stats Stats Stream Histograms Model Instances Model Updates Single attribute tracked in multiple node 31

Slide 55

Slide 55 text

Horizontal Parallelism Y. Ben-Haim and E. Tom-Tov, “A Streaming Parallel Decision Tree Algorithm,” JMLR, vol. 11, pp. 849–872, 2010 31 Stats Stats Stats Stream Histograms Model Instances Model Updates Aggregation to compute splits 31

Slide 56

Slide 56 text

Hoeffding Tree Profiling 32 Other 6% Split 24% Learn 70% CPU time for training
 100 nominal and 100 numeric attributes

Slide 57

Slide 57 text

Vertical Parallelism 33 Stats Stats Stats Stream Model Attributes Splits

Slide 58

Slide 58 text

Vertical Parallelism 33 Stats Stats Stats Stream Model Attributes Splits

Slide 59

Slide 59 text

Vertical Parallelism 33 Stats Stats Stats Stream Model Attributes Splits

Slide 60

Slide 60 text

Vertical Parallelism 33 Stats Stats Stats Stream Model Attributes Splits

Slide 61

Slide 61 text

Vertical Parallelism 33 Stats Stats Stats Stream Model Attributes Splits

Slide 62

Slide 62 text

Vertical Parallelism 33 Stats Stats Stats Stream Model Attributes Splits

Slide 63

Slide 63 text

Vertical Parallelism 33 Stats Stats Stats Stream Model Attributes Splits

Slide 64

Slide 64 text

Vertical Parallelism 33 Stats Stats Stats Stream Model Attributes Splits

Slide 65

Slide 65 text

Vertical Parallelism 33 Stats Stats Stats Stream Model Attributes Splits

Slide 66

Slide 66 text

Vertical Parallelism 33 Single attribute tracked in single node Stats Stats Stats Stream Model Attributes Splits

Slide 67

Slide 67 text

Advantages of Vertical High number of attributes => high level of parallelism
 (e.g., documents) Vs task parallelism Parallelism observed immediately Vs horizontal parallelism Reduced memory usage (no model replication) Parallelized split computation 34

Slide 68

Slide 68 text

Vertical Hoeffding Tree 35 Control Split Result Source (n) Model (n) Stats (n) Evaluator (1) Instance Stream Shuffle Grouping Key Grouping All Grouping

Slide 69

Slide 69 text

Accuracy 36 No. Leaf Nodes VHT2 – tree-100 30 Very close and very high accuracy

Slide 70

Slide 70 text

Performance 37 35 0 50 100 150 200 250 MHT VHT2-par-3 Execution Time (seconds) Classifier Profiling Results for text-10000 with 100000 instances t_calc t_comm t_serial Throughput VHT2-par-3: 2631 inst/sec MHT : 507 inst/sec

Slide 71

Slide 71 text

PKG Partial Key Grouping
 M. A. Uddin Nasir, G. De Francisci Morales, D. Garcia-Soriano, N. Kourtellis, 
 M. Serafini, “The Power of Both Choices: Practical Load Balancing for Distributed Stream Processing Engines”, ICDE 2015 38

Slide 72

Slide 72 text

10-14 10-12 10-10 10-8 10-6 10-4 10-2 100 100 101 102 103 104 105 106 107 108 CCDF key frequency words in tweets wikipedia links Systems Challenges Skewed key distribution 39

Slide 73

Slide 73 text

Key Grouping and Skew 40 Source Source Worker Worker Worker Stream

Slide 74

Slide 74 text

Problem Statement Input stream of messages Load of worker Imbalance of the system Goal: partitioning function that minimizes imbalance 41 m = ht, k, vi Li(t) = |{h⌧, k, vi : P⌧ (k) = i ^ ⌧  t}| Pt : K ! N i 2 W I ( t ) = max i ( Li( t )) avg i ( Li( t )) , for i 2 W

Slide 75

Slide 75 text

Shuffle Grouping 42 Source Source Worker Worker Stream Aggr. Worker

Slide 76

Slide 76 text

Existing Stream Partitioning Key Grouping Memory and communication efficient :) Load imbalance :( Shuffle Grouping Load balance :) Additional memory and aggregation phase :( 43

Slide 77

Slide 77 text

Solution 1: Rebalancing At regular intervals move keys around workers Issues How often? Which keys to move? Key migration not supported with Storm/Samza API Many large routing tables (consistency and state) Hard to implement 44

Slide 78

Slide 78 text

Solution 2: PoTC Balls and bins problem For each ball, pick two bins uniformly at random Put the ball in the least loaded one Issues Consensus and state to remember choice Load information in distributed system 45

Slide 79

Slide 79 text

Solution 3: PKG Fully distributed adaptation of PoTC, handles skew Consensus and state to remember choice Key splitting:
 assign each key independently with PoTC Load information in distributed system Local load estimation:
 estimate worker load locally at each source 46

Slide 80

Slide 80 text

Power of Both Choices 47 Source Source Worker Worker Stream Aggr. Worker

Slide 81

Slide 81 text

Throw m balls with k colors in n bins with d choices Ball = msg, bin = worker, color = key, choice = hash Necessary condition: Imbalance is Chromatic Balls and Bins 48 p1  d n I(m) = ( O m n · ln n ln ln n , if d = 1 O m n , if d 2

Slide 82

Slide 82 text

Comparison 49 Stream Grouping Pros Cons Key Grouping Memory efficient Load imbalance Shuffle Grouping Load balance Memory overhead Aggregation O(W) Partial Key Grouping Memory efficient Load balance Aggregation O(1)

Slide 83

Slide 83 text

Experimental Design What is the effect of key splitting? How does local estimation compare to a global oracle? How does PKG perform in a real system? Measures: imbalance, throughput, latency, memory Datasets: Twitter, Wikipedia, graphs, synthetic 50

Slide 84

Slide 84 text

Effect of Key Splitting 51 Average Imbalance 0% 1% 2% 3% 4% Number of workers 5 10 50 100 PKG Off-Greedy PoTC KG

Slide 85

Slide 85 text

Local vs Global 52 10-10 10-9 10-8 10-7 10-6 10-5 10-4 10-3 10-2 10-1 5 10 50 100 Fraction of Imbalance workers TW G L5 5 10 50 100 workers WP L10 5 10 50 100 workers CT L15 5 LN1 Fig. 2: Fraction of average imbalance with respect to total number of messages workers and number of sources. 5 10 50 100 workers W L5 5 10 50 100 workers WP L10 5 10 50 100 workers CT L15 5 LN1 L2 ction of average imbalance with respect to total number of messages fo d number of sources. 100 5 10 50 100 workers WP L10 5 10 50 100 workers CT L15 5 10 50 100 workers LN1 L20 rage imbalance with respect to total number of messages for each datas sources. 5 10 50 100 workers P L10 5 10 50 100 workers CT L15 5 10 50 100 workers LN1 L20 5 LN2 ance with respect to total number of messages for each dataset, for diffe 0 5 10 50 100 workers CT L15 5 10 50 100 workers LN1 L20 5 10 50 100 workers LN2 H ect to total number of messages for each dataset, for different number 10-10 10-9 10-8 10-7 10-6 10-5 10-4 10-3 10-2 10-1 5 10 50 100 workers TW G L5 5 10 50 100 workers WP L10 5 10 50 100 workers CT L15 g. 2: Fraction of average imbalance with respect to total number of mes rkers and number of sources. 10-10 10-9 10-8 10-7 10-6 10-5 10-4 10-3 10-2 10-1 5 10 50 100 Fraction of Imbalance workers TW G L5 5 10 50 100 workers WP L10 5 10 50 100 workers CT L15 Fig. 2: Fraction of average imbalance with respect to total number of m workers and number of sources.

Slide 86

Slide 86 text

Throughput vs Memory 53 0 200 400 600 800 1000 1200 1400 1600 0 0.2 0.4 0.6 0.8 1 Throughput (keys/s) (a) CPU delay (ms) PKG SG KG 1000 1100 1200 0 1.105 2.105 3.105 4.105 (b) Memory (counters) 10s 30s 60s 300s 300s 600s 600s PKG SG KG Fig. 5: (a) Throughput for PKG, SG and KG for different CPU delays. (b) Throughput for PKG and SG vs. average memory for different aggregation periods.

Slide 87

Slide 87 text

Latency 54 In the second experiment, we fix the CPU delay to 0.4ms per key, as it seems to be the limit of saturation for kg Table 4: Complete latency per message (ms) for di↵erent techniques, CPU delays and aggregation periods. CPU delay D (ms) Aggregation period T (s) D=0.1 D=0.5 D=1 T=10 T=30 T=60 pkg 3.81 6.24 11.01 6.93 6.79 6.47 sg 3.66 6.11 10.82 7.01 6.75 6.58 kg 3.65 9.82 19.35

Slide 88

Slide 88 text

Impact Open source https://github.com/gdfm/partial-key-grouping Integrated in Apache Storm 0.10 (STORM-632, STORM-637) Plan to integrate it in Samza 55

Slide 89

Slide 89 text

Conclusions Mining big data streams is an open field Needs collaboration between 
 algorithms and systems communities SAMOA: a platform for mining big data streams And for collaboration on distributed stream mining Algorithm-system co-design Promising future direction 56 System Algorithm API

Slide 90

Slide 90 text

Future Work Algorithms Lift assumptions of ideal systems Systems New primitives targeted to mining algorithms Impact Open-source involvement with ASF 57

Slide 91

Slide 91 text

Thanks! 58 https://samoa.incubator.apache.org @ApacheSAMOA @gdfm7 [email protected]