This document discusses Pinterest's data architecture and the Singer logging infrastructure. It provides details on: 1) Pinterest's large and growing data volumes including over 30 billion pins and petabytes of data ingested daily. 2) The Singer logging infrastructure which decouples applications from log repositories using simple logging agents and provides at-least-once delivery with adaptive processing intervals. 3) The key components of Singer including log streams, processors, readers, writers, and its pluggable architecture.

2. Krishna Gade
Data Engineering Manager
Discover Pinterest
Big Data and Apache Mesos

3. Connor Doyle
Mesosphere
Roger Wang
Pinterest
Bernardo Gomez Palacio
Guavus

4. Pinterest is a data product.

5. A/B Experimentation
Promoted Pins
Product Insights
Spam Control Related Pins
Home Feed
Search Quality
DATA

6. Numbers
• > 30 billion Pins
• 10 billion messages-a-day logged to Kafka
• 10 petabytes of data in S3
• Ingest 20 terabytes of new data each day
• Petabyte-a-day processed in Hadoop
• 6 Hadoop clusters of 3000 nodes in AWS
• Over 100 regular users running over 2,000 jobs each day

7. 4x Data Growth

8. Data Architecture Overview
pins
repins, likes
impressions
Kafka
App
Storm
HadoopSinger
HBase
Redshift
Insights
Features

9. Roadmap
• Switch to Kafka 0.8 for all data streams
• Invest in scalable stream processing for realtime insights and products
• Migrate to a robust Hadoop 2.0 platform
• Experiment with Spark esp., for machine learning
• Unified batch and stream compute framework

10. Roger Wang
Software Engineer
Singer
A High-Performance Logging Infrastructure

11. Logging Infrastructure before Singer
Storm
kafka
agentkafka
agent
Host
Kafka
Consumer
S3
Kafka
copier
Kafka Cluster
Hadoop
cluster

12. Logging Infrastructure with Singer
Logging infrastructure with Singer
Storm
kafka
agentkafka
agent
Host
singer
agent
Kafka
Consumer
S3Secor
Kafka Cluster
Hadoop
cluster

13. Singer Logging Agent
•Simple logging mechanism for applications
• Decouple applications from log repository
• Existing applications that logs to disk
•Isolate applications from Singer agent failure
•Isolate applications from log repository failure
• Avoid internal buffering and log loss
•Better resource usage
• Connection consolidation
• Flexible batching

14. Singer Features
•At-least-once delivery
•Configurable adaptive log latency by periodical tailing
•Dynamically discover new log streams
•Dynamically pick up new log configuration
•Pluggable log stream reader
•Pluggable log stream writer
•Rich set of stats via Ostrich

15. Singer Architecture
LogStream
monitor
Configuration
watcher
Reader Writer
Log
repository
Reader Writer
Reader Writer
Reader Writer
Log configuration
LogStream processors
A - 1
A -2
B - 1
C - 1

16. Singer Concepts and Components
•LogStream/LogFile
•LogPosition
•LogStreamMonitor
•LogStreamProcessor
•LogStreamReader/LogFileReader
•LogStreamWriter

17. Log Stream Monitor
LogStream
monitor
Log Stream A-1 Processor Stats
Log Stream B-1 Processor Stats
Log Stream B-2
LogStream Registrar
empty log stream Processor Stats
Periodic Task

18. Log Stream Processor
Reader
Writer
Commit position
Refresh
LogStream
EOS
next
batch
update stats
calculate next processing time
schedule next processing cycle
Abort on exception
No Yes
Load position
and seek reader
Abort on exception
Process batch
Abort on exception
Processing a batch

19. Adaptive Log Processing Interval
No message
next cycle =
min(MaxInterval, 2*current interval)
> 1 messages
next cycle = MinInterval
[MinInterval, MaxInterval]

20. Pluggable Log Stream Reader
LogFileReader LogMessage with LogPosition
LogMessage: {key: <binary>; timestamp: <timestamp>; message: <binary>}
LogPosition: inode + byte offset

21. Log Message
Envelope thrift message passed between Reader and Writer:
key binary Uninterpreted binary used to co-locate
message. Examples are: session id so
that all log entries in the session are on
the same partition. No seder cost.
timestamp nanosecs
message binary Uninterpreted binary data. Examples are:
Text log line, thrift message or file path.
No serder cost.

22. Log Position
● Caching can give wrong byte offset
● Implement a generic buffered Java InputStream which tracks byte offsets
● Restrictions: Reader should not cache or read-ahead.
LogFile inode next log file to read from
byteOffset byte offset from head of file next byte to read from the
file

23. Log Rotation
log log.1 log.2 log.4log.3 log.6log.5 log.7
log log.1 log.2 log.4log.3 log.6log.5 log.7
1. Using inode to identify log file.
2. Check inode<->filename mapping when open file by name.
10 12 1413 1615 1711
12 1413 1615111018

24. Duplicate inodes
log log.1 log.2 log.4log.3 log.6log.5 log.7
log log.1 log.2 log.4log.3 log.6log.5 log.7
10 12 1413 1615 1711
12 1413 1615111018
Skip the cycle to wait for log rotation.

25. Log File Reader Caveats
Corrupted block Partial LogMessage
Log File Reader kept open between processing cycle to avoid file
opening cost

26. Pluggable Log Stream Writer
•Writer interprets LogMessage
•Examples:
• Log archiver interpret the message as file path
• Kafka writer create Kafka message without deserialize the content in the envelope.

27. Log Configuration
Puppet master
Watcher
Restart Singer on change
puppet
agent

28. Singer Deployment
•Debian package: part of base image?
•Dynamic configuration update through Puppet
•Resource footprint enformed
•Rich stats exported through Ostrich to OpenTSD

29. Alternatives
•Scribe
•Logstash
•…

30. What’s next?
•Resilient file format so that we can skip corrupted blocks
•Pluggable log processing policy