Consistency Analysis in Bloom: a CALM and Collected Approach Authors: Peter Alvaro, Neil Conway, Joseph M. Hellerstein, William R. Marczak Presented by: Hrishikesh Karve University at Buffalo - Fall Seminar 704

Agenda The Problem Some key definitions Solution Use Cases Conclusion

Problem Large Scale Distributed Systems – Is Consistency too expensive? “Eventually consistent” approaches are often a better choice, since temporary inconsistencies work out in most case But like lots of well-intentioned design maxims, it’s not so easy to translate into practice — all kinds of unavoidable tactical questions pop up

Some questions that need to be answered Exactly where in my multifaceted system is eventual consistency “good enough”? How do I know that my “mission-critical” software isn’t tainted by my “best effort” components? How do I maintain my design maxim as software evolves? For example, how can the junior programmer in year n of a project reason about whether their piece of the code maintains the system’s overall consistency requirements?

Can we write down the answers in an algorithm? Challenge: Write a program checker that will either “bless” your code’s inconsistency as provably acceptable, or identify the locations of unacceptable consistency bugs.

Some Key definitions Monotonicity –Adding an element to an input set may not revoke elements from the output set e.g.: programs expressible via selection, projections Easy to distribute Non-monotonicity— Adding an element to an input set may revoke a previously valid element of an output set e.g. :those that contain aggregation or negation operations counting requires waiting

Keep “CALM” and just Distribute CALM stands for “Consistency As Logical Monotonicity”. The idea is that the family of eventually consistent programs are exactly those that can be expressed in monotonic logic. CALM principle: the tight relationship between Consistency And Logical Monotonicity Monotonicity program guarantee eventual consistency under any interleaving of delivery and computation

Points of Co-ordination What if the program has non-monotonic operators can we distribute in that case? Where an analysis cannot guarantee monotonicity of a whole program, it can instead provide a conservative assessment of the points in the program where coordination may be required to ensure consistency The loci produced by a non-monotonicity analysis are the program’s points of order. A program with non-monotonicity can be made consistent by including coordination logic at its points of order.

Bloom-ing-tale Bloom is a declarative language which translates the CALM idea into useful program checker.Given a Bloom Program we can 1.bless programs as monotonic, and hence safe to run coordination-free 2.identify non-monotonic “Points of Order” in Bloom programs. These can be resolved by either of the following (which we intend to automate): 1.add coordination logic (e.g. quorum consensus) to enforce the ordering, or 2.augment the program to tag downstream data as “tainted” with potential inconsistency 3.Visualize the Points of Order in a dependency graph, to help programmers reason about restructuring their code for more efficient consistency enforcement.

Tale continues.. Bloom is purely declarative designed in the tradition of programming styles that are “disorderly” by nature. State is captured in unordered sets Computation is expressed in logic: an unordered set of declarative Mechanisms for imposing order are available when needed, but the programmer is provided with tools to evaluate the need for these mechanisms as special-case behaviors, rather than a default model The result is code that runs naturally on distributed machines with a minimum of coordination overhead.

Bloom is purely declarative The syntax of a program contains the full specification of its semantics. there is no need for the programmer to understand or reason about the behavior of the evaluation engine. Bloom is based on a formal temporal logic called Dedalus

State in Bloom

Operators in Bloom

BUD: BLOOM UNDER DEVELOPMENT Prototype version of Bloom embodied in an implementation called BUD It is a domain-specific subset of the popular Ruby scripting language and is evaluated by a stock Ruby interpreter via a Bud Ruby Class A Bud program is just a Ruby class definition. Bloom is a side-effect free language with no “mutable state”: if a fact is defined at a given timestep, its existence at that timestep cannot be refuted by any expression in the language

Predicate Dependency Graph

Use Case: Key Value Store

Use Case : Shopping Cart Type 1: “Destructive Shopping Cart” Adding or deleting items from the cart result in “destructive” updates i.e the value associated with the key is replaced by a new value Type 2: “ Disorderly Shopping Cart” Updates are monotonically accumulated in a set, and summed up only at checkout

Shopping Cart Code and Flow Diagram

Inference from Use Cases By providing the programmer with a set of abstractions that are predominantly order-independent, Bloom encourages a style of programming that minimizes coordination requirements Given a particular implementation with points of order, Bloom’s dataflow analysis can help a developer iteratively refine their program—either to “push back” the points to as late as possible in the dataflow

Work done at UB based on CALM principle Prof. Murat Demirbas though an analogue to the monotonicity property in the context of guarded-command languages. Monotonicity property corresponds to the guards being "stable" (closed under program actions) in a guarded-command program. If all guards of a program are stable, then the program is monotonic.

Conclusion CALM principle, which connects the notion of eventual consistency in distributed programming to theoretical foundations in database theory Conversion of theory to practice of software development via “disorderly” programming patterns, complemented with automatic analysis techniques for identifying and managing a program’s points of order in a principled way Bloom prototype as an example of a practically-minded disorderly and declarative programming language

Any Questions

Additional Slides

Toleration an alternative to Co-ordination Non-determinism can be resolved by introducing coordination. Coordination can be undesirable due to concerns like latency and availability Bloom’s point-of-order analysis can assist programmers with the task of tolerating inconsistency, rather than resolving it via coordination

Tolerance Semantics “Guesses”—facts that may not be true—may arise at the inputs to a program “memories”: a log of guesses that were sent outside the system When a background process detects an inconsistency in the results produced by fore ground system may arise at the inputs to a program (e.g., because a “guess” turns out to be mistaken), it can then take corrective action by generating “apologies”

How can we implement FT? making calculated“guesses,” storing appropriate “memories,” and generating the necessary “apologies”. Can lighten the burden on the programmer if these constructs are built using scaffolding