Trang 1
Relational Data ProcessingFall 2019 on MapReduce Vassilis Christophides christop@csd.uoc.gr http://www.csd.uoc.gr/~hy562 University of Crete, Fall 2019 1 Peta-scale Data Analysis Fall 2019 4.6 30 billion RFID tags today billion 12+ TBs of tweet data (1.3B in 2005) camera every day phones world wide 100s of millions of of GPS enabled ? TBs devices sold data every day annually 25+ TBs of 2+ log data every day generated by a new billion user being added every sec. for 3 years people on 4 billion views/day 76 million smart the Web meters in 2009… by end YouTube is the 2nd most used 2011 search engine next to Google 200M by 2014 © 2014 IBM Corporation 2 1 1
Trang 2
Big Data Analysis Fall 2019 A lot of these datasets have some structure Query logs Point-of-sale records User data (e.g., demographics) … How do we perform data analysis at scale? Relational databases and SQL MapReduce (Hadoop) 3 Relational Databases vs. MapReduce Fall 2019 Relational databases: Multipurpose: analysis and transactions; batch and interactive Data integrity via ACID transactions Lots of tools in software ecosystem (for ingesting, reporting, etc.) Supports SQL (and SQL integration, e.g., JDBC) Automatic SQL query optimization MapReduce (Hadoop): Designed for large clusters, fault tolerant Data is accessed in “native format” Supports many query languages Programmers retain control over performance 4 2 2
Trang 3
Parallel Computation & Data Size Matters!Fall 2019 5 Parallel Relational Databases Fall 2019 vs. MapReduce Shared-nothing architecture for parallel processing Parallel relational databases Schema on “write” Failures are relatively infrequent “Possessive” of data Mostly proprietary MapReduce Schema on “read” Failures are relatively common In situ data processing Open source Hadoop NextGen (YARN) architecture 6 3 3
Trang 4
MapReduce: A Major Step Backwards?Fall 2019 MapReduce is a step backward in database access Separation of the schema from the application is good Sharing across multiple MR programs is difficult Declarative access languages are good Does not requires highly-skilled programmers MapReduce is poor implementation Brute force and only brute force no indexes: Wasteful access to unnecessary data Don’t need 1000 nodes to process petabytes Parallel DBs do it in fewer than 100 nodes MapReduce is missing features Bulk loader, indexing, updates, transactions... No support for JOINs: Requires multiple MR phases for the analysis Agrawal et al., VLDB 2010 Tutorial 7 Map Reduce vs Parallel DBMS Fall 2019 Parallel DBMS MapReduce Schema Support Not out of the box Indexing Not out of the box Imperative Programming Model Declarative (C/C++, Java, …) (SQL) Extensions through Pig and Hive Optimizations (Compression, Query Not out of the box Optimization) Flexibility Not out of the box Fault Tolerance Coarse grained techniques [Pavlo et al., SIGMOD 2009, Stonebraker et al., CACM 2010, …] 8 4 4
Trang 5
Database Workloads Fall 2019 OLTP (online transaction processing) Typical applications: e-commerce, banking, airline reservations User facing: real-time, low latency, highly-concurrent Tasks: relatively small set of “standard” transactional queries Data access pattern: random reads, updates, writes (involving relatively small amounts of data) OLAP (online analytical processing) Typical applications: business intelligence, data mining Back-end processing: batch workloads, less concurrency Tasks: complex analytical queries, often ad hoc Data access pattern: table scans, large amounts of data involved per query 9 One Database or Two? Fall 2019 Downsides of co-existing OLTP Solution: separate databases and OLAP workloads User-facing OLTP database for high- Poor memory management volume transactions Conflicting data access patterns Data warehouse for OLAP workloads Variable latency How do we connect the two? 10 5 5
Trang 6
OLTP/OLAP Integration Fall 2019 ETL OLTP (Extract, Transform, Load) OLAP OLTP database for user-facing transactions Retain records of all activity Periodic ETL (e.g., nightly) Extract-Transform-Load (ETL) Extract records from source Transform: clean data, check integrity, aggregate, etc. Load into OLAP database OLAP database for data warehousing Business intelligence: reporting, ad hoc queries, data mining, etc. Feedback to improve OLTP services 11 OLTP/OLAP Architecture: Hadoop? Fall 2019 What about here? ETL (Extract, Transform, Load) OLTP OLAP Hadoop here? 12 6 6
Trang 7
OLTP/OLAP/Hadoop Architecture Fall 2019 ETL (Extract, Transform, Load) OLTP Hadoop OLAP Why does this make sense? 13 ETL Bottleneck Fall 2019 Reporting is often a nightly task: ETL is often slow (see next picture)! What happens if processing 24 h of data takes longer than 24 h? Often, with noisy datasets, ETL is the analysis! ETL necessarily involves brute force data scans: L, then E and T? Hadoop is perfect: Most likely, you already have some data warehousing solution Ingest is limited by speed of HDFS Scales out with more nodes Massively parallel and much cheaper than parallel databases Ability to use any processing tool ETL is a batch process anyway! 14 7 7
Trang 8
A Closer Look at ETL Fall 2019 15 Fall 2019 MapReduce Algorithms for Processing Relational Data 16 8 8
Trang 9
Secondary Sorting Fall 2019 MapReduce sorts input to reducers by key Values are arbitrarily ordered What if want to sort value also? E.g., k → (v1, R), (v3, R), (v4, R), (v8, R)… Solution 1: Buffer values in memory, then sort Why is this a bad idea? Solution 2: “Value-to-key conversion”: extends the key with part of the value Let execution framework do the sorting Preserve state across multiple key-value pairs to handle processing Anything else we need to do? 18 Value-to-Key Conversion Fall 2019 Before k → (v1, R), (v4, R), (v8, R), (v3, R)… Values arrive in arbitrary order… After (k, v1) → (v1, R) Values arrive in sorted order… (k, v3) → (v3, R) Process by preserving state across multiple keys! (k, v4) → (v4, R) (k, v8) → (v8, R) … Default comparator, group comparator, and Partitioner has to be tuned to use the appropriate part of the key 19 9 9
Trang 10
Working Scenario Fall 2019 Two tables: User demographics (gender, age, income, etc.) User page visits (URL, time spent, etc.) Analyses we might want to perform: Statistics on demographic characteristics Statistics on page visits Statistics on page visits by URL Statistics on page visits by demographic characteristic … 20 Relational Algebra Fall 2019 www.mathcs.emory.edu/~cheung/Courses/377/Syllabus/4-RelAlg/intro.html21 10 10
Trang 11
Projection Fall 2019 R1 R1 R2 R2 R3 R3 R4 π S (R) R4 R5 R5 22 Projection in MapReduce Fall 2019 Easy! Map over tuples, emit new tuples with the projected attributes For each tuple t in R, construct a tuple t’ by eliminating those components whose attributes are not in S, emit a key/value pair (t’, t’) No reducers (reducers are the identity function), unless for regrouping or resorting tuples the Reduce operation performs duplicate elimination Alternatively: perform in reducer, after some other processing Basically limited by HDFS streaming speeds Speed of encoding/decoding tuples becomes important Relational databases take advantage of compression Semi-structured data? No problem! 23 11 11
Trang 12
Selection Fall 2019 R1 R2 R1 R3 R3 R4 σ C (R) R5 24 Selection in MapReduce Fall 2019 Easy! Map over tuples, emit only tuples that meet selection criteria For each tuple t in R, check if t satisfies C and If so, emit a key/value pair (t, t) No reducers (reducers are the identity function), unless for regrouping or resorting tuples Alternatively: perform in reducer, after some other processing Basically limited by HDFS streaming speeds: Speed of encoding/decoding tuples becomes important Relational databases take advantage of compression Semistructured data? No problem! 25 12 12
Trang 13
Set Operations in Map Reduce Fall 2019 R(X,Y) ⋃ S(Y,Z) Map: for each tuple t either in R or in S, emit (t,t) Reduce: either receive (t,[t,t]) or (t,[t]) Always emit (t,t) We perform duplicate elimination R(X,Y) ⋂ S(Y,Z) Map: for each tuple t either in R or in S, emit (t,t) Reduce: either receive (t,[t,t]) or (t,[t]) Emit (t,t) in the former case and nothing (t, NULL) in the latter R(X,Y) - S(Y,Z) Map: for each tuple t either in R or in S, emit (t, R or S) Reduce: receive (t,[R]) or (t,[S]) or (t,[R,S]) Emit (t,t) only when received (t,[R]) otherwise nothing (t, NULL) 26 Group by… Aggregation Fall 2019 Example: What is the average time spent per URL? In SQL: SELECT url, AVG(time) FROM visits GROUP BY url In MapReduce: Let R(A, B, C) be a relation to which we apply γA,θ(B)(R) The map operation prepares the grouping (e.g., emit time, keyed by url) The grouping is done by the framework The reducer computes the aggregation (e.g. average) Eventually, optimize with combiners Simplifying assumptions: one grouping attribute and one aggregation function 27 13 13
Trang 14
Relational Joins Fall 2019 R1 S1 R2 S2 R3 S3 R4 S4 R S R1 S2 R2 S4 R3 S1 R4 S3 28 Types of Relationships Fall 2019 Many-to-Many One-to-Many One-to-One 29 14 14
Trang 15
Join Algorithms in MapReduce Fall 2019 “Join” usually just means equi-join, but we also want to support other join predicates Hadoop has some built-in join support, but our goal is to understand important algorithm design principles Algorithms Reduce-side join Map-side join In-memory join Striped variant Memcached variant 30 Re-Partition Join Fall 2019 Relation S Relation R Different join keys Reducers perform Reducer 1 Reducer 2 Reducer N the actual join Shuffling and sorting Shuffling and Sorting Phase over the network - Each mapper processes one block (split) Mapper 1 Mapper2 Mapper3 MapperM - Each mapper produces the join key and the record pairs HDFS stores data blocks 31 (Replicas are not shown) 31 15 15
Trang 16
Reduce-side Join Fall 2019 Basic idea: group by join key Execution framework brings together tuples sharing the same key Similar to a “sort-merge join” in the database terminology A map function Receives a record in R and S Emits its join attribute value as a key and the record as a value A reduce function Receives each join attribute value with its records from R and S Perform actual join between the records in R and S Two variants 1-to-1 joins 1-to-many and many-to-many joins 32 Reduce-side Join: 1-to-1 Fall 2019 Map keys values R1 R1 R4 R4 S2 S2 S3 S3 Reduce keys values R1 S2 S3 R4 Note: no guarantee if R is going to come first or S! 33 16 16
Trang 17
Reduce-side Join: 1-to-Many Fall 2019 Map keys values R1 R1 S2 S2 S3 S3 S9 S9 Reduce keys values R1 S2 S3 … What’s the problem? R is the one side, S is the many 34 Fall 2019 Reduce-side Join: Value-to-Key Conversion In reducer… Buffer all values in memory, pick out the tuple from R, and then cross it with every tuple from S to perform the join keys values R1 New key encountered: hold in memory S2 Cross with records from other set S3 S9 R4 New key encountered: hold in memory Cross with records from other set S3 S7 www.inkling.com/read/hadoop-definitive-guide-tom-white-3rd/chapter-8/example-8-9 35 17 17
Trang 18
Reduce-side Join: Many-to-Many Fall 2019 In reducer… keys values R1 R5 Hold in memory R8 S2 Cross with records from other set S3 S9 What’s the problem? R is the smaller dataset 36 Map-side Join: Basic Idea Fall 2019 What are the limitations of reduce-side joins? Both relations are transferred over the network Assume two datasets are sorted by the join key: R1 S2 R2 S4 R4 S3 R3 S1 A sequential scan through both relations to join: called a “sort-merge join” in database terminology 37 18 18
Trang 19
Map-side Join: Parallel Scans Fall 2019 If datasets are sorted by join key, join can be accomplished by a scan over both relations https://logicalread.com/oracle-11g-sort-merge-joins-mc02/ 38 Map-side Join: Parallel Scans Fall 2019 How can we accomplish this in parallel? Partition and sort both relations in the same manner In MapReduce: Map over one relation, read from other corresponding partition No reducers necessary (unless to repartition or resort) Consistently partitioned relations: realistic to expect? Depends on the workflow For ad hoc data analysis, reduce-side are more general, although less efficient 39 19 19
Trang 20
In-Memory Join: Variants Fall 2019 Basic idea: load one dataset into memory, stream over other dataset Works if R << S and R fits into memory Called a “hash join” in database terminology 40 Broadcast/Replication Join Fall 2019 Relation S Relation R Different join keys Load one dataset into memory, stream over Mapper 1 Mapper 2 Mapper 3 Mapper N other dataset Distribute the smaller 41 relation to all nodes 41 20 20
Hiển thị 20 trang đầu. Tải tài liệu để xem đầy đủ.
Bình luận (0)
Chưa có bình luận nào. Hãy là người đầu tiên!