|
| 1 | +--- |
| 2 | +layout: global |
| 3 | +title: Spark Streaming Kinesis Receiver |
| 4 | +--- |
| 5 | + |
| 6 | +### Kinesis |
| 7 | +Build notes: |
| 8 | +<li>Spark supports a Kinesis Streaming Receiver which is not included in the default build due to licensing restrictions.</li> |
| 9 | +<li>_**Note that by embedding this library you will include [ASL](https://aws.amazon.com/asl/)-licensed code in your Spark package**_.</li> |
| 10 | +<li>The Spark Kinesis Streaming Receiver source code, examples, tests, and artifacts live in $SPARK_HOME/extras/kinesis-asl.</li> |
| 11 | +<li>To build with Kinesis, you must run the maven or sbt builds with -Pkinesis-asl`.</li> |
| 12 | +<li>Applications will need to link to the 'spark-streaming-kinesis-asl` artifact.</li> |
| 13 | + |
| 14 | +Kinesis examples notes: |
| 15 | +<li>To build the Kinesis examples, you must run the maven or sbt builds with -Pkinesis-asl`.</li> |
| 16 | +<li>These examples automatically determine the number of local threads and KinesisReceivers to spin up based on the number of shards for the stream.</li> |
| 17 | +<li>KinesisWordCountProducerASL will generate random data to put onto the Kinesis stream for testing.</li> |
| 18 | +<li>Checkpointing is disabled (no checkpoint dir is set). The examples as written will not recover from a driver failure.</li> |
| 19 | + |
| 20 | +Deployment and runtime notes: |
| 21 | +<li>A single KinesisReceiver can process many shards of a stream.</li> |
| 22 | +<li>Each shard of a stream is processed by one or more KinesisReceiver's managed by the Kinesis Client Library (KCL) Worker.</li> |
| 23 | +<li>You never need more KinesisReceivers than the number of shards in your stream.</li> |
| 24 | +<li>You can horizontally scale the receiving by creating more KinesisReceiver/DStreams (up to the number of shards for a given stream)</li> |
| 25 | +<li>The Kinesis libraries must be present on all worker nodes, as they will need access to the Kinesis Client Library.</li> |
| 26 | +<li>This code uses the DefaultAWSCredentialsProviderChain and searches for credentials in the following order of precedence:<br/> |
| 27 | + 1) Environment Variables - AWS_ACCESS_KEY_ID and AWS_SECRET_KEY<br/> |
| 28 | + 2) Java System Properties - aws.accessKeyId and aws.secretKey<br/> |
| 29 | + 3) Credential profiles file - default location (~/.aws/credentials) shared by all AWS SDKs<br/> |
| 30 | + 4) Instance profile credentials - delivered through the Amazon EC2 metadata service<br/> |
| 31 | +</li> |
| 32 | +<li>You need to setup a Kinesis stream with 1 or more shards per the following:<br/> |
| 33 | + http://docs.aws.amazon.com/kinesis/latest/dev/step-one-create-stream.html</li> |
| 34 | +<li>Valid Kinesis endpoint urls can be found here: Valid endpoint urls: http://docs.aws.amazon.com/general/latest/gr/rande.html#ak_region</li> |
| 35 | +<li>When you first start up the KinesisReceiver, the Kinesis Client Library (KCL) needs ~30s to establish connectivity with the AWS Kinesis service, |
| 36 | +retrieve any checkpoint data, and negotiate with other KCL's reading from the same stream.</li> |
| 37 | +<li>Be careful when changing the app name. Kinesis maintains a mapping table in DynamoDB based on this app name (http://docs.aws.amazon.com/kinesis/latest/dev/kinesis-record-processor-implementation-app.html#kinesis-record-processor-initialization). |
| 38 | +Changing the app name could lead to Kinesis errors as only 1 logical application can process a stream. In order to start fresh, |
| 39 | +it's always best to delete the DynamoDB table that matches your app name. This DynamoDB table lives in us-east-1 regardless of the Kinesis endpoint URL.</li> |
| 40 | + |
| 41 | +Failure recovery notes: |
| 42 | +<li>The combination of Spark Streaming and Kinesis creates 3 different checkpoints as follows:<br/> |
| 43 | + 1) RDD data checkpoint (Spark Streaming) - frequency is configurable with DStream.checkpoint(Duration)<br/> |
| 44 | + 2) RDD metadata checkpoint (Spark Streaming) - frequency is every DStream batch<br/> |
| 45 | + 3) Kinesis checkpointing (Kinesis) - frequency is controlled by the developer calling ICheckpointer.checkpoint() directly<br/> |
| 46 | +</li> |
| 47 | +<li>Checkpointing too frequently will cause excess load on the AWS checkpoint storage layer and may lead to AWS throttling</li> |
| 48 | +<li>Upon startup, a KinesisReceiver will begin processing records with sequence numbers greater than the last checkpoint sequence number recorded per shard.</li> |
| 49 | +<li>If no checkpoint info exists, the worker will start either from the oldest record available (InitialPositionInStream.TRIM_HORIZON) |
| 50 | +or from the tip/latest (InitialPostitionInStream.LATEST). This is configurable.</li> |
| 51 | +<li>When pulling from the stream tip (InitialPositionInStream.LATEST), only new stream data will be picked up after the KinesisReceiver starts.</li> |
| 52 | +<li>InitialPositionInStream.LATEST could lead to missed records if data is added to the stream while no KinesisReceivers are running.</li> |
| 53 | +<li>In production, you'll want to switch to InitialPositionInStream.TRIM_HORIZON which will read up to 24 hours (Kinesis limit) of previous stream data |
| 54 | +depending on the checkpoint frequency.</li> |
| 55 | +<li>InitialPositionInStream.TRIM_HORIZON may lead to duplicate processing of records depending on the checkpoint frequency.</li> |
| 56 | +<li>Record processing should be idempotent when possible.</li> |
| 57 | +<li>Failed or latent KinesisReceivers will be detected and automatically shutdown/load-balanced by the KCL.</li> |
| 58 | +<li>If possible, explicitly shutdown the worker if a failure occurs in order to trigger the final checkpoint.</li> |
0 commit comments