Move Fast and Meet Deadlines: Fine-grained Real-time Stream Processing with Cameo

[pentium3]

https://www.usenix.org/conference/nsdi21/presentation/xu

[pentium3]

Problem and motivation

what is the problem this paper is solving?

• Goal: try to keep high resource utilization (without over-provisioning), ensure performance isolation (among multiple users/jobs), and guarantee performance(latency in this work).

why is it important/challenging?

• Streaming jobs are often dynamic/unpredictable.
• Resources are shared among multiple users (multi-tenant).
• Different users/applications have different expectations (ops/latency).

---

Main ideas and insights

describe the paper gist in 1-2 sentences

• The paper propose Cameo, a fine-grained operative scheduling for stream processing. It is built on virtual actor framework Orleans.
• Cameo could dynamically calculates and propagates priorities of events(user latency targets and query semantics). Cameo provision resources to each operator based solely on its immediate need(deadline).

see page25

---

Solution description

Scheduling Policy: calculate the priority of a message for given policy

• Data driven: prioritize the processing of messages based on their information, like the deadline remaining or processing time for each message, etc. Use LLF scheduling policy, which means prioritize messages which have the least laxity (i.e. flexibility). [ch4]
• Calculating Message Deadline: analyze the topology/query (semantic) dataflow graph. [ch4.2]
• Estimate frontier time (all frontier progresses become available at all sources) [ch4.3]

Scheduling Mechanism:

• user jobs -> dataflow plans -> ordinance actors -> each machine. use priority-based scheduler within each machine. [ch5]
• [ch5.1] 1st layer: context converter. in streaming runtime, use customed scheduling strategy to generate priority of each msg
• [ch5.2] 2nd layer: Cameo scheduler. inside actor framework, dynamically order msg based on msg priority.

---

Important results

describe the experimental setup and summarize the main results

1. single tenant [ch6.1]. FIFO vs default Orleans vs Cameo. improves query latency 3x
2. token mechanism [ch5.3 Fig6].
3. multi tenant, varying environmental parameters [ch6.2] improves query latency 4x. [Fig8(a), (b)]
4. compare different scheduling policy inside Cameo [ch6.3]
5. scheduling overhead of Cameo [Fig12, 13]. less than 6.4%

---

Limitations and opportunities for improvement

when doesn't it work? what assumptions does the paper make and when are they valid?

• need user-defined latency requirement(diff kind of applications have diff latency requirement. see page12)
  • scheduling without such requirement?
• only compared with FIFO and default Orleans(baseline system). Should compare with more related work (eg: event based sys VS flink).
  • From the author: "Event based architecture (as offered by Orleans) give us easy access to control execution orders of messages. The key innovation by Cameo is to provide the performance target -awareness while performing message scheduling."
• paper writing is a little hard to follow...

---

Closely related work

list of main competitors and how they differ

There are many papers about stream processing scheduling.

The main difference might be that Cameo is built on Event based architecture.

---

Follow-up research ideas

• serverless
• how will their policy work in slot-based sys work? [overhead/improvement]
• infer priority automatically
• consider the same requirements in slot-based sys

---

[pentium3]

summary

key problem

workload

xxxxx

optimization goal

xxxxx

configurations to tune

xxxxx

scenario

xxxxx

technique

xxxxx

dynamic workload?

xxxxx

multi-tenant?

xxxxx

implementation

xxxxx

Problem and motivation

what is the problem this paper is solving?
why is it important?
why is it challenging?

Main ideas and insights

describe the paper gist in 1-2 sentences
what is important to remember? What did we learn?

Solution description

explain how the solution work

Important results

describe the experimental setup
summarize the main results

Limitations and opportunities for improvement

when doesn't it work?
what assumptions does the paper make and when are they valid?

Closely related work

list of main competitors and how they differ

Follow-up research ideas (Optional)

If you were to base your next research project on this paper, what would you do?
Propose concrete ways to achieve one or more of the following:

Build a better (faster, more efficient, more user-friendly...) system to solve the same problem
Solve a generalization of the problem
Address one of the work's limitations
Solve the same problem in a different context
Solve the problem in a much larger scale
Apply the paper's methods to a different (but similar) problem
Solve a new problem created by this work