Data Acquisition. The reference Big Data stack

Transcription

1 Università degli Studi di Roma Tor Vergata Dipartimento di Ingegneria Civile e Ingegneria Informatica Data Acquisition Corso di Sistemi e Architetture per Big Data A.A. 2016/17 Valeria Cardellini The reference Big Data stack High-level Interfaces Data Processing Data Storage Resource Management Support / Integration Valeria Cardellini - SABD 2016/17 1

2 Data acquisition How to collect data from various data sources into storage layer? Distributed file system, NoSQL database for batch analysis How to connect data sources to streams or in-memory processing frameworks? Data stream processing frameworks for real-time analysis Valeria Cardellini - SABD 2016/17 2 Driving factors Source type Batch data sources: files, logs, RDBMS, Real-time data sources: sensors, IoT systems, social media feeds, stock market feeds, Velocity How fast data is generated? How frequently data varies? Real-time or streaming data require low latency and low overhead Ingestion mechanism Depends on data consumers Pull: pub/sub, message queue Push: framework pushes data to sinks Valeria Cardellini - SABD 2016/17 3

3 Architecture choices Message queue system (MQS) ActiveMQ RabbitMQ Amazon SQS Publish-subscribe system (pub-sub) Kafka Pulsar by Yahoo! Redis NATS Valeria Cardellini - SABD 2016/17 4 Initial use case Mainly used in the data processing pipelines for data ingestion or aggregation Envisioned mainly to be used at the beginning or end of a data processing pipeline Example Incoming data from various sensors Ingest this data into a streaming system for realtime analytics or a distributed file system for batch analytics Valeria Cardellini - SABD 2016/17 5

4 Queue message pattern Allows for persistent asynchronous communication How can a service and its consumers accommodate isolated failures and avoid unnecessarily locking resources? Principles Loose coupling Service statelessness Services minimize resource consumption by deferring the management of state information when necessary Valeria Cardellini - SABD 2016/17 6 Queue message pattern A sends a message to B B issues a response message back to A Valeria Cardellini - SABD 2016/17 7

5 Message queue API Basic interface to a queue in a MQS: put: nonblocking send Append a message to a specified queue get: blocking receive Block untile the specified queue is nonempty and remove the first message Variations: allow searching for a specific message in the queue, e.g., using a matching pattern poll: nonblocking receive Check a specified queue for message and remove the first Never block notify: nonblocking receive Install a handler (callback function) to be automatically called when a message is put into the specified queue Valeria Cardellini SABD 2016/17 8 Publish/subscribe pattern Valeria Cardellini - SABD 2016/17 9

6 Publish/subscribe pattern A sibling of message queue pattern but further generalizes it by delivering a message to multiple consumers Message queue: delivers messages to only one receiver, i.e., one-to-one communication Pub/sub channel: delivers messages to multiple receivers, i.e., one-to-many communication Some frameworks (e.g., RabbitMQ, Kafka, NATS) support both patterns Valeria Cardellini - SABD 2016/17 10 Pub/sub API Calls that capture the core of any pub/sub system: publish(event): to publish an event Events can be of any data type supported by the given implementation languages and may also contain meta-data subscribe(filter expr, notify_cb, expiry) sub handle: to subscribe to an event Takes a filter expression, a reference to a notify callback for event delivery, and an expiry time for the subscription registration. Returns a subscription handle unsubscribe(sub handle) notify_cb(sub_handle, event): called by the pub/sub system to deliver a matching event Valeria Cardellini SABD 2016/17 11

7 Apache Kafka General-purpose, distributed pub/sub system Allows to implement either message queue or pub/sub pattern Originally developed in 2010 by LinkedIn Written in Scala Horizontally scalable Fault-tolerant At least-once delivery Source: Kafka: A Distributed Messaging System for Log Processing, 2011 Valeria Cardellini SABD 2016/17 12 Kafka at a glance Kafka maintains feeds of messages in categories called topics Producers: publish messages to a Kafka topic Consumers: subscribe to topics and process the feed of published message Kafka cluster: distributed log of data over serves known as brokers Brokers rely on Apache Zookeeper for coordination Valeria Cardellini SABD 2016/17 13

8 Kafka: topics Topic: a category to which the message is published For each topic, Kafka cluster maintains a partitioned log Log: append-only, totally-ordered sequence of records ordered by time Topics are split into a pre-defined number of partitions Each partition is replicated with some replication factor Why? CLI command to create a topic > bin/kafka-topics.sh --create --zookeeper localhost: replication-factor 1 --partitions 1 --topic test! Valeria Cardellini - SABD 2016/17 14 Kafka: partitions Valeria Cardellini - SABD 2016/17 15

9 Kafka: partitions Each partition is an ordered, numbered, immutable sequence of records that is continually appended to Like a commit log Each record is associated with a sequence ID number called offset Partitions are distributed across brokers Each partition is replicated for fault tolerance Valeria Cardellini - SABD 2016/17 16 Kafka: partitions Each partition is replicated across a configurable number of brokers Each partition has one leader broker and 0 or more followers The leader handles read and write requests Read from leader Write to leader A follower replicates the leader and acts as a backup Each broker is a leader fro some of it partitions and a follower for others to load balance ZooKeeper is used to keep the broker consistent Valeria Cardellini - SABD 2016/17 17

10 Kafka: producers Publish data to topics of their choice Also responsible for choosing which record to assign to which partition within the topic Round-robin or partitioned by keys Producers = data sources Run the producer > bin/kafka-console-producer.sh --broker-list localhost: topic test! This is a message! This is another message! Valeria Cardellini - SABD 2016/17 18 Kafka: consumers Valeria Cardellini - SABD 2016/17 Consumer Group: set of consumers sharing a common group ID A Consumer Group maps to a logical subscriber Each group consists of multiple consumers for scalability and fault tolerance Consumers use the offset to track which messages have been consumed Messages can be replayed using the offset Run the consumer > bin/kafka-console-consumer.sh --bootstrap-server localhost: topic test --from-beginning! 19

11 Kafka: ZooKeeper Kafka uses ZooKeeper to coordinate between the producers, consumers and brokers ZooKeeper stores metadata List of brokers List of consumers and their offsets List of producers ZooKeeper runs several algorithms for coordination between consumers and brokers Consumer registration algorithm Consumer rebalancing algorithm Allows all the consumers in a group to come into consensus on which consumer is consuming which partitions Valeria Cardellini - SABD 2016/17 20 Kafka design choices Push vs. pull model for consumers Push model Challenging for the broker to deal with diverse consumers as it controls the rate at which data is transferred Need to decide whether to send a message immediately or accumulate more data and send Pull model In case broker has no data, consumer may end up busy waiting for data to arrive Valeria Cardellini - SABD 2016/17 21

12 Kafka: ordering guarantees Messages sent by a producer to a particular topic partition will be appended in the order they are sent Consumer instance sees records in the order they are stored in the log Strong guarantees about ordering within a partition Total order over messages within a partition, not between different partitions in a topic Per-partition ordering combined with the ability to partition data by key is sufficient for most applications Valeria Cardellini - SABD 2016/17 22 Kafka: fault tolerance Replicates partitions for fault tolerance Kafka makes a message available for consumption only after all the followers acknowledge to the leader a successful write Implies that a message may not be immediately available for consumption Kafka retains messages for a configured period of time Messages can be replayed in the event that a consumer fails Valeria Cardellini - SABD 2016/17 23

13 Kafka: limitations Kafka follows the pattern of active-backup with the notion of leader partition replica and follower partition replicas Kafka only writes to filesystem page cache Reduced durability DistributedLog from Twitter claims to solve these issues Valeria Cardellini - SABD 2016/17 24 Kafka APIs Four core APIs Producer API: allows app to publish streams of records to one or more Kafka topics Consumer API: allows app to subscribe to one or more topics and process the stream of records produced to them Connector API: allows building and running reusable producers or consumers that connect Kafka topics to existing applications or data systems so to move large collections of data into and out of Kafka Valeria Cardellini - SABD 2016/17 25

14 Kafka APIs Streams API: allows app to act as a stream processor, transforming an input stream from one or more topics to an output stream to one or more output topics Can use Kafka Streams to process data in pipelines consisting of multiple stages Valeria Cardellini - SABD 2016/17 26 Client library JVM internal client Plus rich ecosystem of clients, among which: Sarama: Go library for Kafka Python library for Kafka - NodeJS client Valeria Cardellini - SABD 2016/17 27

15 LinkedIn Valeria Cardellini - SABD 2016/17 28 Netflix Netflix uses Kafka for data collection and buffering so that it can be used by downstream systems Valeria Cardellini - SABD 2016/17 29

16 Uber Uber uses Kafka for real-time business driven decisions Valeria Cardellini - SABD 2016/ Rome Tor CINI Smart City Challenge 17 Valeria Cardellini - SABD 2016/17 By M. Adriani, D. Magnanimi, M. Ponza, F. Rossi 31

17 Realtime data Facebook Data originated in mobile and web products is fed into Scribe, a distributed data transport system The realtime stream processing systems write to Scribe Source: Realtime Data Processing at Facebook, SIGMOD Valeria Cardellini - SABD 2016/17 32 Scribe Transport mechanism for sending data to batch and real-time systems at Facebook Persistent, distributed messaging system for collecting, aggregating and delivering high volumes of log data with a few seconds of latency and high throughput Data is organized by category Category = distinct stream of data All data is written to or read from a specific category Multiple buckets per scribe category Scribe bucket = basic processing unit for stream processing systems Scribe provides data durability by storing it in HDFS Scribe messages are stored and streams can be replayed by the same or different receivers for up to a few days Valeria Cardellini - SABD 2016/17 33

18 Messaging queues Can be used for push-pull messaging Producers push data to the queue Consumers pull data from the queue Message queue systems based on protocols: RabbitMQ Implements AMQP and relies on a broker-based architecture ZeroMQ High-throughput and lightweight messaging library No persistence Amazon SQS Valeria Cardellini - SABD 2016/17 34 Data collection systems Allow collecting, aggregating and moving data From various sources (server logs, social media, streaming sensor data, ) To a data store (distributed file system, NoSQL data store) Valeria Cardellini - SABD 2016/17 35

19 Apache Flume Distributed, reliable, and available service for efficiently collecting, aggregating, and moving large amounts of log data Robust and fault tolerant with tunable reliability mechanisms and failover and recovery mechanisms Suitable for online analytics Valeria Cardellini - SABD 2016/17 36 Flume architecture Valeria Cardellini - SABD 2016/17 37

20 Flume data flows Flume allows a user to build multi-hop flows where events travel through multiple agents before reaching the final destination Supports multiplexing the event flow to one or more destinations Multiple built-in sources and sinks (e.g., Avro) Valeria Cardellini - SABD 2016/17 38 Flume reliability Events are staged in a channel on each agent Events are then delivered to the next agent or terminal repository (e.g., HDFS) in the flow Events are removed from a channel only after they are stored in the channel of next agent or in the terminal repository Transactional approach to guarantee the reliable delivery of events Sources and sinks encapsulate in a transaction the storage/retrieval of the events placed in or provided by a transaction provided by the channel Valeria Cardellini - SABD 2016/17 39

21 Apache Sqoop Efficient tool to import bulk data from structured data stores such as RDBMS into Hadoop HDFS, HBase or Hive Also to export data from HDFS to RDBMS Valeria Cardellini - SABD 2016/17 40 Amazon IoT Cloud service for collecting data from IoT devices into AWS cloud Valeria Cardellini - SABD 2016/17 41

22 References Kreps et al., Kafka: a Distributed Messaging System for Log Processing, NetDB Apache Kafka documentation, Chen et al., Realtime Data Processing at Facebook, SIGMOD Apache Flume documentation, S. Hoffman, Apache Flume: Distributed Log Collection for Hadoop - Second Edition, Valeria Cardellini - SABD 2016/17 42