In recent years there has been an explosion of data all around us. The data comes in from a variety of sources, such as financial real-time systems, cell phone networks, sensor networks--RFID and IoT, and GPS. Commensurate with this dramatic increase in data, is a corresponding unquenchable thirst for analysis and insights. The natural question arises: how do we build systems that process and makes sense of this vast amount of data, in as close to real-time as possible? What patterns of software and systems should we look at?
Michael Stonebraker of database fame et al. offer some advice on what to consider in their paper: "The 8 requirements of real-time stream processing" published a decade ago. In the paper, the authors list eight guiding principles that high-volume low-latency systems should follow to be able to process vast amounts of data in near real-time.
First, the systems have to keep the data moving, and do straight-through processing with minimal to no writes to disk to achieve the low-latency desired. The authors compare passive (polling) systems versus active (event driven systems) and recommend the latter.
Second, the authors recommend supporting a high-level language--dubbed StreamSQL, with built-in extensible stream oriented primitives and operators to process the data instead of writing custom code in languages such as C++ and Java.
Third, the system has to handle stream imperfections such as delayed data, missing data, or out of order data, and have timeouts for potentially blocking data to ensure system liveness.
Fourth, the system has to integrate stored and streaming data, to be able to reprocess data when necessary.
Fifth, the system has to generate predictable outcomes and repeatable results, such as when it needs to reprocess data for recovery, or handling duplicate data.
Sixth, the systems have to guarantee data safety and availability, with uninterrupted fail-over between primary and backup systems ala "Tandem-style" computing.
Seventh, the system has to partition and scale applications automatically, between cores and across machines to be able to seamlessly handle any increase in load.
Finally, the system has to be quick, process and respond instantaneously to streaming data, which requires careful planning and coding to minimize boundary crossing, and maximize the ratio of useful work to computation overhead.
The authors examine common architectures that fulfill parts of the requirements they listed above including databases (DBMS), rule engines that are built on condition/action pairs, and stream processing engines. They present in tabular form where the systems excel at, and where they don't. The table leans toward using stream processing engines instead of DBMS which are not optimized for the task.
Despite being a decade old, the paper is still relevant, and referenced in the modern literature. Moreover, it is well written and a pleasure to read.
Michael Stonebraker of database fame et al. offer some advice on what to consider in their paper: "The 8 requirements of real-time stream processing" published a decade ago. In the paper, the authors list eight guiding principles that high-volume low-latency systems should follow to be able to process vast amounts of data in near real-time.
First, the systems have to keep the data moving, and do straight-through processing with minimal to no writes to disk to achieve the low-latency desired. The authors compare passive (polling) systems versus active (event driven systems) and recommend the latter.
Second, the authors recommend supporting a high-level language--dubbed StreamSQL, with built-in extensible stream oriented primitives and operators to process the data instead of writing custom code in languages such as C++ and Java.
Third, the system has to handle stream imperfections such as delayed data, missing data, or out of order data, and have timeouts for potentially blocking data to ensure system liveness.
Fourth, the system has to integrate stored and streaming data, to be able to reprocess data when necessary.
Fifth, the system has to generate predictable outcomes and repeatable results, such as when it needs to reprocess data for recovery, or handling duplicate data.
Sixth, the systems have to guarantee data safety and availability, with uninterrupted fail-over between primary and backup systems ala "Tandem-style" computing.
Seventh, the system has to partition and scale applications automatically, between cores and across machines to be able to seamlessly handle any increase in load.
Finally, the system has to be quick, process and respond instantaneously to streaming data, which requires careful planning and coding to minimize boundary crossing, and maximize the ratio of useful work to computation overhead.
The authors examine common architectures that fulfill parts of the requirements they listed above including databases (DBMS), rule engines that are built on condition/action pairs, and stream processing engines. They present in tabular form where the systems excel at, and where they don't. The table leans toward using stream processing engines instead of DBMS which are not optimized for the task.
Despite being a decade old, the paper is still relevant, and referenced in the modern literature. Moreover, it is well written and a pleasure to read.
Comments
Post a Comment