When it comes to serverless computing, many people immediately associate it with some popular and exciting terms such as “elastic scaling,” “scale-to-zero,” and “pay-as-you-go.” Nowadays, with the popularity of public cloud, we hear about new serverless computing products being introduced almost every now and then. At the same time, many well-known cloud service products, such as AWS Aurora, AWS Redshift, Databricks, etc., have also launched their serverless versions. Serverless computing quickly became the focus in the industry, with both startups and large-scale enterprises exploring the possibilities of launching serverless products. Even in the highly anticipated field of large-language models (LLM), there has been a lot of discussion about serverless machine learning platforms.

Undoubtedly, the concept of serverless computing is very appealing. It precisely addresses the pain points of users. After all, hardly any company wants to spend too much effort on managing operations and no company wants to pay high fees for basic services. However, having a good concept alone is not enough. For any product to be widely adopted and implemented, it ultimately depends on whether it can meet the interests and needs of both buyers and sellers.

In this article, I will delve into serverless technology from both a business and technical perspective, hoping to bring a more comprehensive understanding to everyone.

Software Services in the Market

Although the concept of cloud computing has become widely known, not all companies are willing to embrace cloud services. Due to various reasons, different companies have their own views on using cloud services, and many companies cannot even access cloud platforms, let alone use cloud services, due to regulatory and risk control requirements. Before discussing serverless computing in detail, let’s talk about the types of software services available in the market.

Let’s start with the on-premises deployment model. On-premises deployment refers to customers directly deploying software services on their own servers or data centers. In this deployment model, enterprises have 100% complete control over their data and software services, providing them with a high level of data security assurance. Of course, having control over data security also means that companies are responsible for their own security. The drawbacks of on-premises deployment are also obvious, namely the high costs of deployment and maintenance. Companies not only need to purchase a large number of servers, but also figure out how to install the desired software on their own servers. If there are failures or upgrades needed, companies may need frequent communication with suppliers and even on-site support from them.

The emergence of cloud is to solve the pain points of on-prem deployment. In the cloud, the default mode is fully managed mode, also known as public SaaS. Fully managed mode means that customers use software services provided by vendors on the public cloud. In this case, the software used by the company and its own data will be stored in the cloud. This mode almost eliminates the pressure for software operation and maintenance for the enterprise, but it also means that the enterprise may face a series of security and privacy issues. After all, as the software vendor has the permission to manage the software, in theory (although it is almost impossible in practice), the vendor can access the user’s data. In the event of data leaks and other situations, the consequences can be unimaginable.

To address the concerns of enterprises about the security of fully-managed mode, many vendors are beginning to offer private SaaS, also known as Bring Your Own Cloud (BYOC) mode. Literally, it may be a bit difficult to understand. But simply put, it can be imagined as a way for enterprises to achieve on-prem deployment in the cloud era. The BYOC mode requires the customer company to already have an account with a cloud service provider (such as AWS, GCP, etc.), and the software vendor will deploy the software in the customer’s cloud account. This way, the ownership of the data is completely controlled by the enterprise, and the vendor only has access to the control platform of the customer’s system. This significantly limits the vendor’s access to data, thereby reducing the risk of data leakage. Of course, the BYOC mode also presents various requirements for the vendor in terms of operation and maintenance, which we will not discuss further here.

The last mode is what we want to focus on today, namely serverless. Serverless can be seen as an extension of the fully-managed mode. In this mode, all services are deployed by the vendor in the cloud, and the customers simply use these services without worrying about the backend operation and maintenance work. In other words, users no longer need to consider how much computing resources and storage resources they have used, they only need to pay for the services they use.

Take a database system as an example. For the cloud database service in the fully-managed mode, users need to know how many machines their cloud database actually occupies, how many CPUs, and how much memory is used. For the serverless cloud database, users no longer need to know these resources, they can just directly use it, and after using it, the cloud database vendor will charge according to the amount of resources consumed.

The greatest advantage of the serverless mode is convenience, which may also save users a lot of costs. At the same time, serverless allows users to worry less about underlying details and theoretically achieve automatic elastic scaling based on workload. However, depending on the implementation, serverless may bring potential performance and security risks, which require users to carefully evaluate before using. We will discuss this in detail in the next paragraph.

Some vendors, even though their core services are not sold as serverless, allow users to serverlessize some of their workloads. There are two classic examples. Database vendor Databricks only sells services in BYOC mode, but they still allow users to use serverless services to accelerate some queries. This mode is also used in AWS Redshift. Although Redshift is in fully managed mode, if users want to accelerate a specific query, they can use the concurrency scaling feature to obtain resources from the shared resource pool for elastic computation.

Approach to Implementing Serverless

For users, serverless is a highly abstracted layer: as long as users are unaware of the underlying deployment and operational modes, it appears as serverless from their perspective. Serverless can be implemented in various ways, and these approaches can affect performance, security, cost, and other aspects. The two most popular implementation methods are the container-based mode and the multitenancy-based mode.

The simplest way to implement serverless is to use Kubernetes on the cloud to orchestrate containers and handle resource isolation at the container level. This implementation method is essentially similar to traditional fully-managed approaches, but from the user’s perspective, they no longer need to be concerned with the underlying details. Although this serverless implementation does not require consideration of resource isolation at the lower level, it places high demands on product encapsulation and automated operations and maintenance. With users no longer needing to manage resources, serverless service providers need to dynamically allocate resources based on user workloads. If true on-demand resource allocation can be achieved, significant cost savings can be achieved for users. However, dynamic scaling itself poses many challenges, and resource scheduling based on runtime conditions is even more difficult. If the implementation is not ideal, it can lead to resource wastage and even service downtime due to resource shortages.

The multi-tenant mode is another classic approach to implementing serverless. Some well-known OLTP database vendors provide serverless services based on this architecture. This architecture requires the database itself to handle resource isolation between multiple tenants directly at the database system level. In terms of service provisioning, it can be seen as the vendor opening a large instance where different users share resources within the same instance. This implementation method places high demands on resource control and isolation at the system kernel level, but it achieves efficient resource utilization. After all, compared to container-based implementations, the multi-tenant mode allows different users to share the same resources instead of individually managing resources for each user. The multi-tenant mode is theoretically the most efficient way to utilize resources.

How Customers Think?

When considering the selection of software systems, everything starts with the needs and expectations of the users.

For users who can only accept on-prem deployment, the real work begins after signing a contract with the software vendor. Customers may need to assemble a dedicated technical team to deploy and manage the system to ensure smooth operation within their internal network. If you are familiar with early IBM and Oracle services, you should know that customers need to configure professionals for software setups. For software vendors, each customer’s environment is unique, so highly customized services need to be provided. This undoubtedly increases the workload and costs for both sides.

Transitioning to cloud services simplifies the entire process. The cloud provides unparalleled convenience and elasticity, eliminating the hassle of purchasing and maintaining hardware for customers and allowing them to adjust service scales flexibly based on actual needs. In order to achieve this level of convenience and elasticity, cloud service providers have standardized everything and built trust with users through standardization.

If we list all four modes – on-prem deployment, BYOC mode, fully managed mode, and serverless mode – we can see that users consider convenience, elasticity, performance, security, and price when making choices.

In terms of convenience, on-prem deployment is highly inconvenient as it requires users to purchase and configure hardware in addition to software. BYOC mode offers moderate convenience as users need to maintain their own cloud accounts and perform lightweight operations. Fully managed mode provides high convenience as users only need to select the specifications of the service. Serverless mode offers extremely high convenience as users may not even need to select specifications and can fully use pay-as-you-go pricing.
In terms of elasticity, on-prem deployment lacks flexibility as users generally need to purchase specific machines to install the corresponding software. Both BYOC and fully managed modes can achieve elasticity in the cloud, but in BYOC mode, as the data plane is on the user’s side, there may be certain limitations on dynamic resource allocation and release based on technical and policy considerations. Fully managed mode and serverless mode have almost no limitations regarding elasticity and can achieve high elasticity.
In terms of performance, the multi-tenant implementation of serverless, which requires multiple users to share storage and compute resources, may cause performance interference, potentially placing it at a disadvantage compared to dedicated modes. In the other implementation methods, each user has their own independent computing and storage resources, ensuring high-performance guarantees.
In terms of security, on-prem deployment mode does not have many security risks. BYOC mode provides high security because data is stored on the user’s side. Fully managed mode and container-based serverless mode clearly have certain security risks. The multi-tenant serverless mode has relatively higher security risks because the data access is not physically isolated.
In terms of price, on-prem deployment costs are quite high as users need to invest in hardware and software purchases as well as require maintenance teams. From the vendor’s perspective, BYOC and fully managed modes generally maintain consistent pricing models, resulting in minimal price differences. Serverless mode, due to its ability to dynamically adjust resource usage based on user loads and resource sharing, achieves significant cost reduction. Considering these five aspects, we can conclude that small companies may be more inclined to sacrifice certain performance and security aspects to reduce costs and gain convenience and elasticity. On the other hand, large enterprises, considering their large user bases and data assets, would prioritize performance and security.

How Vendors Think?

For software service providers, the ultimate goal is profitability. From a business perspective, regardless of the services provided, vendors aim to maximize profits. When we examine the table from the previous section, we can see that if profitability is desired from serverless services, the provided services must have broad appeal and market demand. This is not only because the average revenue per user from serverless services may be lower than other types of services, but also because providing serverless services entails higher costs for vendors than traditional fully managed or BYOC modes.

We can imagine that one of the core selling points of serverless is elasticity. To ensure users can obtain the necessary resources at any time and enjoy instant startup experiences, vendors generally need to maintain a certain number of ready resources, often referred to as “warm pools.” The cost of maintaining these ready resources must be covered by the vendors themselves. In contrast, if only fully managed services or BYOC modes are sold, the cost of basic resources is borne by users, and the revenue earned by vendors consists of software service fees above the basic costs.

Of course, if a serverless service has a large number of users, compared to traditional cloud services, software vendors will discover more opportunities for profitability. They can increase revenue in various ways, such as resource sharing, metadata node sharing, or overbooking. Overbooking is based on the simple fact that although users may reserve a large amount of resources, a portion of them may not fully utilize their quotas in practice. This provides an opportunity for vendors to sell more resources.

The above diagram illustrates the differences in business models between serverless and traditional hosting services.

This diagram describes the differences in the business models between serverless and traditional hosting services. In the case of traditional hosting mode, the ratio of costs to revenue for vendors is relatively fixed and increases linearly with the number of customers. In the case of serverless, when there are only a few customers, vendors are generally operating at a loss, and profitability is only possible when the number of customers reaches a certain scale. However, unlike traditional hosting services, when the number of customers increases, the profit margin for vendors may increase significantly, resulting in super-linear growth. This may be why the serverless story is highly sought after in the venture capital circle.

However, it is easy to imagine that not all software is suitable for serverless services. From the perspective of market acceptance, only widely accepted technologies have the potential to truly profit from serverless. Additionally, since serverless services have a large number of users, the likelihood of encountering online failures is increased. Therefore, generally speaking, serverless services are suitable for commercializing systems that are already mature and well-established, such as MySQL, PostgreSQL, etc., as it significantly reduces the chances of system failures.

Case Study: Providing Serverless Stream Processing

Since I have been involved in the development and commercialization of stream processing systems, I often think about how to provide cloud services like RisingWave as serverless solutions to users. Streaming databases, such as RisingWave, are relatively unique compared to traditional databases, making them suitable as a case study for discussing how to achieve serverless.

Let’s start by considering the user’s perspective. As mentioned earlier, users often consider convenience, elasticity, performance, security, and price when using different service modes. From the perspectives of convenience, security, and price, streaming databases do not have much difference. However, from the perspectives of elasticity and performance, the differentiation of streaming databases becomes apparent. The core concept of streaming databases is materialized views, which represent continuous incremental calculations on data streams. Data streams may experience significant changes over time, making elasticity crucial. Moreover, since stream processing involves continuous calculations, and users may be highly sensitive to the freshness of the calculation results, the system needs to maintain high performance. From the table presented earlier in this article, we can see that the multi-tenant serverless mode, due to resource sharing, may result in performance interference, making it potentially unsuitable for stream processing. Therefore, the more reliable approach to achieve serverless for stream processing systems should be through container-based implementations. However, as mentioned earlier, container-based serverless implementations require efficient resource allocation based on user loads, which is not easy to achieve. Considering the user base, it is safe to say that stream processing technology has not yet reached the level of popularity like PostgreSQL and MySQL, making it challenging to achieve super-linear growth.

In conclusion, considering the needs of both customers and vendors, we can draw a conclusion: stream processing system vendors are currently facing difficulties in maximizing profits through serverless services.

Of course, this situation may change over time. In the field of event streaming and messaging systems, companies such as Redpanda and StreamNative (Apache Pulsar) are considering the possibility of providing serverless services. Redpanda’s serverless services will be launched soon, and StreamNative’s commercialized Apache Pulsar supports multi-tenancy capabilities at the kernel level, making it a matter of time before serverless mode is provided. Recently, we also saw the emergence of Upstash, a new vendor that provides serverless Kafka service. RisingWave, the stream processing company, will soon launch its serverless RisingWave service in the upcoming months, making it possible for everyone to access the new technology.

In the fast-evolving field of real-time analytics, many stream processing engines have emerged over the past decade. Notable examples include Apache Storm, Apache Flink, and Apache Samza. These engines have become widely accepted in various enterprises, providing substantial support for real-time processing and analytical applications.

In the last few years, a new and intriguing innovation has surfaced: streaming databases. Starting with early solutions like PipelineDB, conceived as a PostgreSQL plugin, followed by Confluent's KsqlDB designed for Kafka, and the more recent open-source RisingWave—a distributed SQL streaming database—these systems have steadily climbed the ladder of acceptance and popularity.

The question arises: Can stream processing engines and streaming databases be used interchangeably? This article sheds light on their respective design principles and explores these fascinating technologies' distinctions, similarities, use cases, and potential future trajectories.

Design Principles

Stream processing engines and databases serve critical functions in data stream processing. Yet, they differ notably in their design principles, particularly in user interaction interfaces and data storage options. Before diving into their unique characteristics, a clear understanding of the historical backdrop that gave rise to these technologies is needed.

The Evolution of Stream Processing Engines

Database systems have been under exploration for over six decades, while computing engines—encompassing both batch and stream processing—are relatively recent innovations. The journey into modern stream processing began in 2004 with the release of Google's MapReduce paper.

MapReduce aimed to optimize resource utilization across networks of commodity machines striving for peak performance. This lofty goal led to the introduction of an elegant low-level programming interface with two principal functions: Map and Reduce. Such a design granted seasoned programmers direct access to these core functions, allowing them to implement specific business logic, control program parallelism, and manage other intricate details on their own.

What set MapReduce apart was its exclusive focus on processing, relegating data storage to external systems like remote distributed file systems. This division resulted in a unique architecture that continues to influence today's stream processing engines and sets the stage for understanding the vital differences and synergies with streaming databases.

To successfully utilize MapReduce inside a company, three critical prerequisites were essential:

The company must possess a substantial volume of data and relevant business scenarios internally;
The company must have access to a sufficient number of commodity machines;
The company must employ a cadre of skilled software engineers.

These three conditions were a high bar for most companies when MapReduce was introduced in 2004. It wasn't until after 2010, with the explosion of social networks and mobile internet, that the first condition began to be satisfied. This shift led major companies to turn their attention to stream processing technology, investing heavily to meet the second and third prerequisites. This investment marked the golden age of development for stream processing engines, which began around 2010. During this period, a slew of exceptional stream processing engines emerged, including Apache Storm, Apache Samza, Apache Flink, among others.

These emergent stream processing engines fully embraced the core principles of the MapReduce design pattern, specifically:

exposing low-level programming interfaces to users;
relinquishing control over data storage.

This design was aptly tailored to the big data era. Usually, technology companies requiring substantial data processing had their own data centers and specialized engineering teams. What these companies needed were improved performance and more adaptable programming paradigms. Coupled with their specialized engineering teams, they could typically deploy distributed file systems to handle vast data storage.

However, the landscape began to shift with the remarkable advancements in cloud computing technology post-2015. More companies, even those without extensive technical backgrounds, desired access to stream processing technology. In response to this demand, stream processing engines embraced SQL, a concise and universally recognized programming language. This adaptation opened the doors for a broader audience to reap the benefits of stream processing technology. As a result, today's leading stream processing engines offer a tiered approach to user interaction, providing low-level programming interfaces such as Java and Scala and more accessible high-level SQL programming interfaces.

User Interaction Interfaces

Modern stream processing engines offer both low-level programming interfaces, such as Java and Scala, and higher-level interfaces, like SQL and Python. These interfaces expose various system runtime details, such as parallelism, allowing users to control more nuanced aspects of their applications. On the other side, streaming databases primarily feature SQL interfaces, simplifying runtime complexities. Some even provide User-Defined Functions (UDFs) in languages like Python and Java to enhance expressive capabilities. This divergence in user interaction interfaces leads to two principal balancing acts.

1. Balance Between Flexibility and Ease of Use

Proficient programmers benefit from the considerable expressive capabilities offered by low-level interfaces such as Java and Scala. As Turing-complete languages, Java, Scala, and similar languages theoretically empower users to articulate any logic. For companies with pre-existing Java and Scala libraries, this is particularly advantageous.

However, due to its complexity, this approach may deter those unfamiliar with Java or Scala. Mastering a system's custom API can be time-consuming and demanding, even for technical users.

Streamlining ease of use through higher-level SQL interfaces in streaming databases addresses some usability challenges, but two main obstacles remain. First is the completeness of SQL support, which includes more than simple DML (Data Manipulation Language) statements. Users often require complex DDL (Data Definition Language) operations like creating or deleting roles, users, indexes, and more. Second is the support for the broader SQL ecosystem, requiring additional effort, such as compatibility with management tools like DBeaver or pgAdmin.

Low-level interfaces give technically-focused users more flexibility, while SQL interfaces of streaming databases are tailored for business-focused users, emphasizing ease of use.

2. Balance Between Flexibility and Performance

The availability of low-level programming interfaces allows users to optimize system performance using prior knowledge. Those with deep programming expertise and business logic comprehension often achieve superb performance through low-level interfaces. The flip side is that this may require companies to invest more in building their engineering teams.

Contrastingly, hierarchical stream processing engines might face performance drawbacks when using high-level programming interfaces. Encapsulation leads to performance overhead, and the more encapsulation layers there are, the worse the performance. Intermediate layers in stream processing engines can cause the underlying design to be oblivious to the higher-level logic, leading to performance loss. In comparison, streaming databases solely offering SQL interfaces and optimization capabilities can reach higher performance levels.

In conclusion, stream processing engines with low-level interfaces allow technically-focused users to exploit their expertise for performance benefits. Conversely, streaming databases that provide SQL interfaces are tailored to serve business-focused users, often achieving higher performance bounds without requiring intricate technical expertise.

Data Storage

Apart from user interaction interfaces, the most significant difference between stream processing engines and streaming databases is whether the system stores data. In stream processing, the presence or absence of data storage directly affects various aspects of the system, such as performance, fault recovery, scalability, and use cases.

In a stream processing engine, data input and output typically occur in external systems, such as remote distributed file systems like HDFS. In contrast, a streaming database not only possesses computational capabilities but also includes data storage capabilities. This means it can do at least two things: 1) store inputs, and 2) store outputs.

On the data input side, storing data yields significant performance benefits. Consider a scenario where a naive stream processing engine joins a data stream from a message queue (like Kafka) with a table stored in a remote database (like MySQL). Suppose a stream processing engine lacks data storage; a significant problem arises whenever a new data item enters the stream. In that case, the engine must fetch data from the remote database before performing calculations. This approach was adopted by the earliest distributed stream processing engines. Its advantage is that it simplifies the system architecture, but the drawback is a sharp decrease in performance. Accessing data across different systems clearly causes high latency, and introducing high-latency operations in latency-sensitive stream processing engines results in performance degradation.

Storing (or caching) data directly within the stream processing system helps to avoid cross-system data access, thereby improving performance. In a streaming database, which is a stream processing system with built-in storage capabilities, a user can directly replicate the table into the streaming database if they need to join a data stream from a message queue with a table from a remote database. This way, all access becomes internal operations, leading to efficient processing. Of course, this is a simplified example. In real-world scenarios, challenges such as large or dynamically changing tables in the remote database may arise, which we won't delve into here.

On the output side, storing output results can offer substantial benefits. To summarize, there are roughly four key advantages:

Simplify the data stack architecture: Instead of using separate stream processing engines for computation and separate storage systems for data storage and query responses, a single system like a streaming database can handle computation, storage, and query responses. This approach significantly simplifies the data stack and often results in cost savings.
Facilitate computation resource sharing: In stream processing engines, computation results are exported to external systems after consuming input data and performing calculations. This makes it challenging to reuse these results within the system directly. A streaming database with built-in storage can save computation results as materialized views internally, enabling other computations to access and reuse those resources directly.
Ensure data consistency: While stream processing engines can ensure exactly-once semantics for processing, they cannot guarantee result access consistency. Since stream processing engines don't have storage, calculation results must be imported into downstream storage systems. The upstream engine must output version information of the results to the downstream system to achieve consistent results visible to users in downstream systems. This puts the burden of ensuring consistency on the user. In contrast, a streaming database with storage can manage computation progress and result version information within the system, assuring users always see consistent results through multi-version control.
Enhance program interpretability: During program development, repeated modifications and verification of correctness are common. A common approach to verifying correctness is to obtain inputs and outputs and manually validate whether the calculation logic meets expectations. This practice is relatively straightforward in batch processing engines but more challenging in stream processing engines. In stream processing engines, where inputs and outputs are dynamically changing, and the engine lacks storage, verifying correctness requires traversing three systems: the upstream message source, the downstream result storage system, and the stream processing engine. Additionally, users must be aware of computation progress information, making it a complex task. Conversely, verifying correctness becomes relatively simple in a streaming database as the calculation results are also stored within the database. Users only need to obtain inputs from the upstream system (typically by directly fetching offsets from message queues like Kafka) and validate results within the single system. This significantly boosts development efficiency.

Of course, there's no such thing as a free lunch, and software development never offers a silver bullet. Compared to stream processing engines, streaming databases with storage brings many advantages in architecture, resource utilization, consistency, and user experience. However, what do we sacrifice in return?

One significant sacrifice is the complexity of software design. Recall the design of MapReduce. The concept of MapReduce stood out when giants like Oracle and IBM dominated the entire database market because they effectively used a simple model to enable large-scale parallel computing for technology companies with many ordinary computers. 

MapReduce directly subverted the storage and computation integration concept in databases, separating computation as an independent product. It enabled users to make computation scalable through programming. In other words, MapReduce achieved large-scale horizontal scalability through a simplified architecture, relying on the availability of highly skilled professional users.

However, when a system requires data storage, everything becomes more complex. To make such a system usable, developers must consider high availability, fault recovery, dynamic scaling, data consistency, and other challenges, each requiring intricate design and implementation. Fortunately, over the past decade, the theory and practice of large-scale databases and stream processing have significantly progressed. Hence, now is indeed a favorable time for the emergence of streaming databases.

Use Cases

While sharing similarities in their computational models, streaming processing engines and streaming databases still have nuances that lead to unique applications and functionalities. These technologies overlap significantly in their applications but diverge in their end-user focus.

Stream processing engines are generally more aligned with machine-centric operations, lacking data storage capabilities and often requiring integration with downstream systems for computation result consumption. In contrast, streaming databases cater more to human interaction, offering storage and random query support, thus enabling direct human engagement.

The dichotomy between machines and humans is evident in their preferences—machines demand high-performance processing of hardcoded programs, while humans favor a more interactive and user-friendly experience. This inherent divergence leads to a differentiation in functionality, user experience, and other aspects between stream processing engines and streaming databases.

In sum, the commonalities in application scenarios between these technologies are nuanced by the specific focus on end users and interaction modes, resulting in distinct features within each system.

A Step Back in History or the Current Trend of the Era?

Databases and computing engines often reflect two divergent philosophies in design, evidenced by their distinct scholarly contributions and industry evolution.

In academics, computing engine papers typically find their home in system conferences like OSDI, SOSP, and EuroSys, while database-centric works frequent SIGMOD and VLDB conferences. This division was famously highlighted by the 2008 critique "MapReduce: A major step backwards" by David DeWitt and Michael Stonebraker. He argued that MapReduce was historically regressive and needed more innovation relative to databases.

In the realm of stream processing, the question arises: Which philosophy represents a historical regression, and which embodies the current era's trend? I assess that both stream processing engines and streaming databases will coexist and continue evolving for at least the next 3-5 years.

Stream processing engines, emphasizing extreme performance and flexibility, cater to technically proficient users. On the other hand, streaming databases balance elegance in user experience with high performance and fine internal implementation. The mutual integration trend between these philosophies enhances both sides, with computing engines adopting SQL interfaces to boost user experience and databases leveraging UDF capabilities to increase programming adaptability.

Predicting the Future of Stream Processing

Looking back at history, we find that the concept of streaming databases was already proposed and implemented more than 20 years ago. For example, the aforementioned Aurora system is already a streaming database. However, streaming databases are not as popular as stream processing systems. History moves in a spiral pattern.

The big data era witnessed the trend of separating stream processing from databases and overthrowing the monopoly of the three giants: Oracle, IBM, and Microsoft. More recently, in the cloud era starting around 2012, in the field of batch processing systems, we are witnessing systems such as Redshift, Snowflake, and Clickhouse bring the "computing engine" back to the "database".

Now it is time to bring stream processing back into databases, which is the core idea behind modern streaming databases such as RisingWave and Materialize. But why now? We analyze it in detail in this section.

With over two decades of development, stream processing remains in its infancy concerning commercial adoption, particularly compared to its batch processing counterpart. However, the industry has reached a consensus on the direction of stream processing. Both stream processing engines and streaming databases concur on the necessity of supporting both stream and batch processing. The primary differentiation lies in harmoniously integrating these two distinct computing models. Essentially, the notion of "unified stream and batch processing" has become a shared understanding within the field.

There are generally three methodologies for accomplishing this unification:

The Single Engine Approach

This strategy involves employing the same computing engine to manage both stream processing and batch processing functionalities. Its advantage is that it offers a relatively straightforward implementation plan and a more cohesive user experience. However, since stream processing and batch processing entail significant differences in implementation aspects like optimization and computation methods, distinct handling of each is often necessary to achieve peak performance.

2. The Dual Engine Approach

Under this approach, stream processing and batch processing are configured separately as two unique system engines. While it allows for specific optimization of each, it also necessitates considerable engineering resources, high levels of collaboration, and stringent priority management within the engineering team. The need to align and make both parts work seamlessly can be a considerable challenge.

3. The Sewn-Together System Approach

This third approach involves repurposing existing systems instead of constructing a new, ideal system to provide a unified user experience. Although it seems to be the least engineering-intensive method, delivering a seamless user experience can be highly challenging. Existing market systems vary in support interfaces, and even when they employ SQL, different dialects might be used. Shielding users from these inconsistencies becomes a core issue. Additionally, orchestrating multiple systems to function, interact, and remain cognizant of each other introduces complex engineering challenges.

The last decade witnessed the rapid growth of stream processing technology. My first exposure to stream processing was in 2012. At that time, I was fortunate to be an intern at Microsoft Research Asia, working on a distributed stream processing system that can distribute at a large scale. Then, I continued my research and development on stream processing and database systems at the National University of Singapore, Carnegie Mellon University, IBM Almaden Research Center, and AWS Redshift. Most recently, I founded a startup called RisingWave Labs, developing a distributed SQL streaming database.

2023 marks my 11th year in the stream processing area. I never imagined that I could have been working in this field for over a decade, jumping out of my comfort zone and gradually shifting from pure research and engineering to exploring the path of commercialization. In a startup, the most exciting and challenging thing is to predict the future: we need to constantly evaluate the technology and business trend and predict the development direction of the industry based on our understanding and intuition. As a startup founder building next-generation stream processing systems, I am always optimistic yet humble in the market. I keep asking myself over and over again: Why do we need stream processing? Why do we need a streaming database? Can stream processing really replace batch processing? In this blog, I will combine my software development and customer engagement experiences to discuss stream processing and streaming databases' past, present, and future from a practitioner's perspective.

When Do We Really Need a Stream Processing System?

When talking about stream processing systems, people naturally think of some low-latency use cases: stock trading, fraud detection, ad monetization, etc. However, how exactly are stream processing systems used in these use cases? How low does the latency need to be when using a stream processing system? Why not use batch processing systems to solve the problems? In this section, I will answer these questions based on my experience.

Classic Stream Processing Scenarios

Regardless of the specific use case, stream processing systems are typically used in the following two scenarios: streaming ingestion and streaming analytics.

Streaming ingestion (ETL). Streaming ingestion provides the capability of continuously sending data from one set of systems to another. In many cases, users need to perform some transformation on the data during ingestion; hence, people sometimes use the terms "streaming ingestion" and "streaming ETL" interchangeably. When do we need streaming ingestion? Here’s an example. Let’s assume we are running an e-commerce website that uses an OLTP database (e.g., AWS Aurora, CockroachDB, TiDB, etc.) to support online transactions. To better analyze user behaviors, our website needs to track user events (e.g., ad clicks) and record these events into message queues (e.g., Kafka, Pulsar, Redpanda, etc.). To improve the sales strategy based on the most recent data, we have to continuously combine and ingest the transaction data and user behavior logs into a single data warehouse, such as Snowflake or Redshift, for deep analytics. Stream processing systems play a critical role in this case: data engineers use stream processing systems to clean the data, join the two streams, and move the joined results into the data warehouse in real-time. In real-world scenarios, data ingested into the stream processing systems typically come from OLTP databases, messaging queues, or storage systems. After stream processing, the results are most likely to be dumped back into these systems or inserted into data warehouses or data lakes. One thing worth noticing is that data seldom comes out from data warehouses and data lakes, as these systems are typically considered the “terminal” of the data. As few data warehouses and data lakes provide data change logs, capturing data changes from these systems can be very challenging.

Streaming analytics. You may have already heard of the term real-time analytics. Streaming analytics is similar to real-time analytics but more focused on data freshness over query latency (we will discuss this topic later in the blog). When performing streaming analytics, users are interested in continuously receiving fresh results over recent data (e.g., data generated within the last 30 minutes, 1 hour, or seven days). Just think of the stock market data. Users may be more interested in getting insights from the most recent data, and processing historical data, in this case may not bring too much value. In the streaming analytics scenario, data typically comes from OLTP databases, message queues, and storage systems. Results are usually ingested into a key-value store (such as Cassandra, DynamoDB, etc.) or a caching system (such as Redis, etc.) to support user-triggered requests. Some users may directly send stream processing results to the application layer, which is a typical pattern in alerting applications.

While batch processing systems can also support data ingestion and analysis, stream processing systems can reduce latency from days or hours to minutes or seconds. In many businesses, this can bring huge benefits. In the data ingestion scenario, reducing latency can allow users of downstream systems (such as data warehouses) to obtain the latest data promptly and process the latest data. In the data analytics scenario, the downstream system can see the latest data processing results in real time so that the results can be presented to users in a timely manner.

People may ask:

In the data ingestion (or ETL) scenario, wouldn’t it be enough for us to use an orchestration tool (such as Apache Airflow) to periodically trigger a batch processing system (such as Apache Spark) to do computations?
In the data analysis scenario, many real-time analysis systems (such as Clickhouse, Apache Pinot, Apache Doris, etc.) can analyze data online. Why do we need a stream processing system?

These two issues are worth exploring, and we discuss them in the last section.

User Expectations: How Low Does Latency Need to Be?

People are always talking about low-latency processing. But what “low latency” means? What are the users’ expectations of latencies? Seconds? Milliseconds Microseconds? The lower, the better, is it? We have interviewed hundreds of users who have adopted or are considering adopting processing technologies in their production. We find that most use cases require latencies ranging from hundreds of milliseconds to tens of minutes. Many data engineers told us, “After adapting stream processing systems, our computation latency has been reduced from days to minutes. We are very satisfied with this improvement and are not strongly motivated to reduce the latency further.” Ultra-low latency sounds appealing, but, unfortunately, there is not much use case to support it.

In some ultra-low-latency scenarios, general-purpose stream processing systems cannot meet the latency requirements. A typical ultra-low-latency scenario is high-frequency quantitative trading. Quantitative trading firms expect their systems to be able to respond to market fluctuations in microseconds and to buy and sell stocks or futures timely. To achieve this level of latency, many companies move their data centers to buildings physically closer to the stock exchange and carefully choose network providers to reduce any possible network delay. In this scenario, almost all trading firms build their own systems instead of adopting general-purpose stream processing systems such as Flink or RisingWave. This is not only because general-purpose stream processing systems often fail to meet the latency requirements but also because quantitative trading usually requires some specialized expressions, which are not well supported by general-purpose stream processing systems.

Another set of low-latency scenarios includes IoT (Internet of Things) and network monitoring. The latency requirement in these scenarios is usually on the millisecond level and can vary from a few milliseconds or hundreds of milliseconds. In such scenarios, general-purpose stream processing systems might be a good fit. However, in some use cases, it is still necessary to use specialized systems. A good example is autonomous vehicles. Autonomous vehicles are typically equipped with radar and sensors to monitor roadside conditions, speed, coordinates, driver behaviors (e.g., pedaling and braking), and other information. Such information may not be sent back to the data center due to privacy issues and network bandwidth constraints. Therefore, a common solution is directly deploying embedded computing devices on the vehicle for data processing.

Stream processing systems are primarily adopted in scenarios where latency falls into the range of hundreds of milliseconds to several minutes. These scenarios can cover ad recommendations, fraud detection, stock market dashboard, food delivery, etc. In these scenarios, lower latency might bring more value but is not considered critical. Let’s take the stock market dashboard as an example. Individual investors usually make trading decisions by staring at websites or mobile phones to watch stock fluctuations. Do these individual investors really need to react to market fluctuation within ten milliseconds? Not at all. Human eyes can process no more than 60 frames per second, which means a human cannot distinguish refreshes below 16 milliseconds. At the same time, humans’ reaction speed is at the second level, and even well-trained sprint athletes can only react at about 100-200 milliseconds. Therefore, for the stock market dashboard, which is solely for humans to get insights and make decisions, achieving less than 100-millisecond latency is unnecessary. General-purpose stream processing systems (such as Flink, RisingWave, etc.) can be a great fit in this scenario.

Not all scenarios require low-latency processing. Considering examples like hotel reservations and inventory management, a 30-minute delay won’t be a big issue. In these cases, users may consider using either stream processing systems or batch processing systems, and they should make the decision based on other factors, such as cost efficiency, flexibility, tech stack complexity, etc.

Stream processing systems do not fit into scenarios with no latency requirements. These scenarios include machine learning model training, data science, and financial reporting. It is obvious that batch processing systems are more suitable for these scenarios. But it is worth noticing that people have started moving from batch to streaming in these cases. In fact, some companies have adopted stream processing systems to build their online machine-learning platforms.

Looking Back at (Forgotten) History

The previous section described the typical scenarios where stream processing systems fit. In this section, let's talk about the history of stream processing systems.

Apache Storm and Its Successors

For many experienced engineers, Apache Storm may be the first stream processing system they have ever used. Apache Storm is a distributed stream computing engine written in Clojure, a niche JVM-based language that many junior developers may not know. Storm was open-sourced by Twitter in 2011. In the big-data era dominated by Hadoop, the emergence of Storm blew many developers' minds in the data processing. Traditionally, the way users process data is to first import a large amount of data into HDFS, and then use batch computing engines such as Hadoop to analyze the data. With Storm, data could be processed on-the-fly, immediately after it flows into the system. With Storm, data processing latency was drastically reduced: Storm users were able to receive the latest results in just a few seconds, without waiting for hours or even days.

Apache Storm was groundbreaking at its time. However, the initial design of Storm was far from perfect. In fact, it lacked many basic functionalities that modern stream processing systems by default have to provide: state management, exactly-once semantics, dynamic scaling, SQL interface, etc. But it inspired many talented engineers to build next-generation stream processing systems. Just a few years after Storm emerged, many new stream processing systems were invented: Apache Spark Streaming, Apache Flink, Apache Samza, Apache Heron, Apache S4, and many more. Spark Streaming and Flink eventually stand out and become legends in the stream processing field.

History Before Apache Storm

If you think that the history of stream processing systems begins with the birth of Storm, you are probably wrong. In fact, stream processing systems have evolved for over two decades. Not surprisingly, the concept of stream processing originated from the database community. At the VLDB conference in 2002, a group of researchers from Brown and MIT published a paper titled "Monitoring Streams - A New Class of Data Management Applications", pointing out the demand for stream processing for the first time. In this paper, the authors proposed that to process streaming data, we should shift from the traditional "Human-Active, DBMS-Passive" processing mode and turn to the new "DBMS-Active, Human-Passive" mode. That is, instead of passively reacting to user-issued queries, the new class of database systems should trigger computation upon data arrival and actively push the results to the users. In academia, the earliest stream processing system was called Aurora. After that, Borealis, STREAM, and many other systems were born.

Just a few years after being studied in academia, stream processing technology was adopted by large enterprises. The top three database vendors, Oracle, IBM, and Microsoft, consecutively launched their stream processing solutions, which were known as Oracle CQL, IBM System S, and Microsoft SQLServer StreamInsight. Interestingly, instead of developing a standalone stream processing system, all these vendors have chosen to integrate stream processing functionality into their existing systems.

2002 to present: what has changed?

As mentioned above, stream processing technology was first introduced in academia, and soon adopted in the industry world. In the early days, stream processing was implemented as an integrated module inside commercial database systems. But since 2010, dozens of standalone stream processing systems have been built and adopted in tech companies. What caused this change? Well, one of the major factors is the birth and growth of the Hadoop-centric big data ecosystems. In those conventional commercial database systems, computation and storage modules were well integrated and encapsulated into the same system. While the design greatly simplified the system architecture, it also restricted these database systems from scaling in the distributed environment. Observing the limitation, big data systems were built, to offer high scalability that can span across dozens or hundreds of machines. The computation and the storage layers were divided into independent systems, and users can use low-level interfaces to determine the best configurations and strategies to scale out on their own. This design perfectly met the needs of a new batch of Internet companies, such as Twitter, LinkedIn, and Uber. The stream processing systems built at the time (notably Storm and Flink) tightly followed the design principle of those batch processing systems (notably Hadoop and Spark), and their high scalability and flexibility perfectly fit the needs of the big data engineers.

The Renaissance of Streaming Databases

Looking back at history, we find that the concept of streaming databases was already proposed and implemented more than 20 years ago. For example, the aforementioned Aurora system is already a streaming database. However, streaming databases are not as popular as stream processing systems. History moves in a spiral pattern. The big data era witnessed the trend of separating stream processing from databases and overthrowing the monopoly of the three giants: Oracle, IBM, and Microsoft. More recently, in the cloud era starting around 2012, in the field of batch processing systems, we are witnessing systems such as Redshift, Snowflake, and Clickhouse bring the "computing engine" back to the "database". Now it is time to bring stream processing back into databases, which is the core idea behind modern streaming databases such as RisingWave and Materialize. But why now? We analyze it in detail in this section.

The Story of PipelineDB and ksqlDB

Since Apache Storm was open-sourced in 2011, stream processing systems have entered the fast lane of development. But streaming databases didn't just disappear. There are still two streaming databases born in the era of big data and were popular at the time: PipelineDB and ksqlDB.

Although both PipelineDB and ksqlDB are streaming databases, their technical routes are quite different.

PipelineDB is entirely based on PostgreSQL. It is a PostgreSQL extension to process continuous queries. Once the user has installed PostgreSQL, they can install PipelineDB as a plugin. This design is very user-friendly since users can directly use PipelineDB without migrating their own PostgreSQL databases. The core selling point of PipelineDB is the real-time updated materialized view. After the user inserts data into PipelineDB, the latest results are reflected on the materialized view created by the user in real-time.
ksqlDB has chosen a different path. It is strongly coupled with Kafka. In ksqlDB, the intermediate results of the computation are stored in Kafka, and the communication between nodes also relies on Kafka. The advantages and disadvantages of this technical route are clear. The advantage is that mature components can be highly reused, greatly reducing development costs. The disadvantage is that ksqlDB is strongly bound with Kafka, which seriously lacks flexibility, and dramatically reduces the performance and scalability of the system.

Aside from technological routes, the two systems have much to do with each other commercially. PipelineDB was founded in 2013. Initially, the PipelineDB team joined Y Combinator, a well-known incubator in Silicon Valley, in 2014. On the other hand, ksqlDB was built by Confluent in 2016 (in fact, it was Kafka Stream first). Confluent is a commercial company founded by the original Apache Kafka team. At the time, ksqlDB was not receiving much attention outside the Kafka ecosystem due to its strong binding to Kafka and the lack of technical maturity. Nevertheless, both PipelineDB and ksqlDB were still inferior to Spark Streaming and Flink in terms of user recognition. In 2019, Confluent acquired PipelineDB, and PipelineDB stopped updating since then. Sounds familiar? Yes, more recently in January 2023, Confluent acquired Immerok, a Flink commercialization company founded by Flink core members, and announced with a high profile that it plans to launch a computing platform based on Flink SQL. PipelineDB and Immerok are important enhancements to the Kafka-centric real-time data stack and direct replacements of ksqlDB. This makes the future status of ksqlDB within Confluent foggier.

The Rise of Cloud-Native Streaming Databases

In recent years, many cloud-native systems have gradually surpassed and subverted their big data system counterparts. One of the most well-known examples is Snowflake. Snowflake brings cloud warehouses to the next level with its innovative architecture: separating storage and computing. It rapidly dominated the market that belonged to the data analytic systems (such as Impala) in the big data era. In the world of streaming databases, similar things are happening again. Cloud-based streaming databases like RisingWave, Materialize, DeltaStream, and TimePlus have emerged in recent years. Although there are differences in their commercial and technical routes, their general objective is the same: to provide users with streaming database services on the cloud. To achieve that objective, the focus is on designing an architecture that fully utilizes resources on the cloud to achieve unlimited horizontal scalability and supreme cost efficiency. With a solid technical route and a reasonable product positioning, I believe streaming databases will gradually take over the leading position of stream processing systems of the previous generation.

Stream Processing Systems and Streaming Databases

The trend of shifting toward “cloud-native” is unstoppable. Now the biggest question is: why would you build a "cloud-native streaming database" instead of a "cloud-native stream processing system"?

Some people may argue that it is the impact of SQL. One of the major changes brought about by cloud services is the popularization of data processing systems. In the era of big data, users are typically engineers familiar with programming languages for general-purpose application development such as Java. Whereas in the cloud era, cloud services are adopted by a large wider group of users beyond well-trained programmers. This urgently requires the system to provide a simple and easy-to-understand interface to benefit developers without programming knowledge. SQL, the standard query language, obviously meets the requirement. SQL is a declarative language solely for querying and manipulating data. It has been the industry standard for decades. The widespread use of SQL has accelerated the popularization of the concept of "databases" in data engineering and hence stream processing.

However, SQL is only an indirect factor, not a direct factor. The logic is simple: many stream computing engines (such as Flink and Spark Streaming) already provide SQL interfaces, but they are not streaming databases. Although the SQL interface of these systems differs from the SQL experience of traditional databases such as MySQL and PostgreSQL, it already proves that having SQL does not necessarily mean having a database.

The key difference between a "streaming database" and a "stream processing system" is that a streaming database has its own storage, while a stream processing system does not. The deeper insight is that streaming databases treat storage as a first-class citizen. Based on this insight, streaming databases meet the two most fundamental needs of users: being simple and easy to use. How is this done? We look at the following aspects.

Unifying data operation objects. In stream processing systems, the stream is the basic object to do operations, whereas in databases, the table is the basic object to do operations. In streaming databases, the concepts of stream and table are perfectly unified. Users no longer need to consider the difference between a stream and a table. Instead, a stream is simply a table of unbounded size, hence a stream can be processed, queried, and manipulated in the same fashion as doing these corresponding operations on a table in traditional databases.
Simplifying the data stack. Differing from stream processing systems, streaming databases have ownership of data. Users can directly store data in a database. After the user finishes processing the data through the streaming database, the processed result can be directly stored in the same system and accessed concurrently by different users. In stream processing systems that cannot store data, the results of any computation must be exported to an external downstream system, e.g., a key-value store or a cache system, before users can access them. That is to say, users can use a single streaming database system to replace the previous service combinations such as Flink+Cassandra/DynamoDB. Simplifying the user's data stack and reducing operation and maintenance costs are obviously what many companies expect.

Reducing external access overhead. The data sources of modern enterprises are diversified. When using a stream processing system, users often need to access data from external systems, like joining the data stream from Kafka with a table in MySQL. In a stream processing system, to access a MySQL table, a cross-system external call must be made. The performance cost of such calls is enormous regarding data-intensive computations. On the other hand, streaming databases have the ability to store data, therefore data in the external system can be stored (or cached) inside the streaming database. This greatly improves the overall performance by eliminating the costly external call.

Providing result interpretability and consistency guarantees. A major pain point of stream processing systems is the lack of interpretability and consistency guarantees for computational results. In Flink, different jobs run and output results to the downstream system continuously and independently. The different computational progress of different jobs in stream processing systems introduces the inconsistency between the results of different jobs received by the downstream system. Consider a simple example: the user submits two jobs to Flink, one is to find how many times the Tesla stock has been bought in the past ten minutes, and the other is to find how many times the stock has been sold in the past ten minutes. A downstream system receives continuous output from the two jobs. One may be the result at 8:10, and the other may be the result at 8:11. Furthermore, the inconsistency in the results cannot be traced. Seeing such a result, users are confused: they cannot judge whether the result is correct, and how it is generated and evolved. In streaming databases, with the ownership of the input and output data, the computing behavior of the system becomes observable, explainable, and strongly consistent from a theoretical point of view. For example, RisingWave is one of the systems that achieve these guarantees. All intermediate results of computations are stored in tables and stamped with timestamps, and all computational results can be stored in materialized views and traced through timestamps. In this way, the user can better understand the computational results by querying the historical intermediate results with a specific timestamp.
Deeply optimized execution plans. "Treating storage as a first-class citizen" means that the computing layer of streaming databases can perceive the storage layer. This perception opens new opportunities to optimize the computation and storage collectively. A great example is to share the intermediate state of stream processing better to save the resource overhead. We will not dive into the technical details of this topic, and we refer readers to our previous blog.

Design Principles for Cloud Native Streaming Databases

The biggest difference between cloud deployment and on-premise deployment is that the cloud can have unlimited and decoupled resources. In contrast, the on-premise deployment has only limited and coupled resources. What exactly does that mean?

First, users on the cloud no longer need to perceive the number of physical machines. While cluster users in the era of big data often only have limited physical machines.
Second, cloud vendors expose classified resources to users. They can directly purchase computing, storage, cache, or other resources separately according to their needs. In comparison, users for on-premise deployment can only request resources according to the number of machines.

The first difference causes a fundamental discrepancy in the design goals of big data and cloud-native systems. The goal of big data systems is to maximize system performance within limited resources, while the goal of cloud-native systems is to minimize cost overhead under unlimited resources. The second difference has caused a fundamental division in the implementation of the data system. The big data system achieves embarrassingly parallelism based on the shared-nothing architecture which couples storage with computing. In contrast, cloud-native systems realize on-demand scaling through the shared-storage architecture that separates storage and computing.

These design principles bring new challenges to cloud-native streaming databases. In streaming databases, the storage essentially stores the intermediate states in the computation. When intermediate states need to be separated from computing nodes and placed on persistent cloud storage services such as S3, the obvious challenge is that data access latency brought by S3 may greatly affect the latency of the stream processing system itself. Therefore, a cloud-native streaming database has to consider how to use the local storage of computing nodes and external storage (such as EBS, etc.) to cache data, to minimize the performance degradation caused by S3 access.

Stream Processing and Batch Processing: Replace or Coexist?

As stream processing technology can greatly reduce query latency, many people consider it a technology that can subvert batch processing. But an opposite view is that modern batch processing systems have been "upgraded" to real-time analytical systems that can generate results in milliseconds, the value of stream processing systems is limited. While I am extremely optimistic about the future of stream processing, I do not really think stream processing can fully replace batch processing. In my view, these two technologies will coexist and can complement each other in the long run.

Stream Processing Systems and Real-Time Analytical Systems

At present, most batch processing systems, including Snowflake, Redshift, Clickhouse, etc., claim to be capable of doing real-time analytics on large-scale data. It naturally comes to a question that we raised in the first chapter: why do we need a stream processing system when there are already many real-time analytical systems? Because there is a fundamental difference in the definition of "real-time". In stream processing systems, a query is defined by the user in advance, and the query processing is driven by the data. In contrast, in real-time analytical systems, a query could be defined by the user at any time, and it is actually the users who drive the query processing. The "real-time" mentioned by stream processing systems means that the query results reflect the latest received data. In contrast, the "real-time" mentioned by real-time analytical systems refers to the low latency of random issued queries. To put it more clearly, stream processing systems emphasize the real-time nature of computational results, while real-time analytical systems emphasize the real-time nature of user interaction. For those scenarios that require high freshness of data results, such as a stock trading dashboard, advertising recommendations, or network anomaly detection, stream processing systems are the better choice. For scenarios with high requirements for user interactive experience, such as interactive custom reports or analyzing user behavior logs, real-time analysis systems suit better.

Some people may say that since real-time analytical systems can give real-time results to the queries sent by users, as long as the user keeps sending the same query to the real-time analysis system periodically, wouldn't it be possible to ensure the freshness of the results at all times and achieve the same effect as stream processing systems? There are two problems. The first is implementation complexity. A user is not a machine, and cannot stay in front of the computer and send queries continuously. To issue a query periodically, you must either write a program or use an operation and maintenance orchestration tool, such as Airflow, to send queries in a loop. Either way, it means that users need to pay extra costs to operate and maintain external systems or programs. The second and more fundamental problem is that the cost is too high. Real-time analytic systems perform computations on the whole dataset, while stream processing systems perform incremental computations. When it comes to a large volume of data, the high number of redundant computations carried out by real-time analytical systems results in a huge waste of resources. This is why we should never use an orchestration tool to trigger batch processing in real-time analytical systems regularly.

Stream Processing and Real-Time Materialized Views

Nowadays, many real-time analytical systems have implemented real-time materialized views. Since streaming databases also use materialized views to define stream processing inside its kernel, there is an argument that given an analytical system with real-time materialized views, we no longer need a separate stream processing system. I don't agree with this point of view. Consider the following reasons.

Competition for resources. The core problem to be solved by analytical databases is to process complex queries on large-scale data sets efficiently. In such systems, the positioning of materialized views is essentially no different from that of database indexes. They are both caches of computations. Creating real-time materialized views has two benefits: on the one hand, redundant computations over frequently used queries can be reduced; on the other hand, pre-computing shared subqueries of different queries can speed up query execution. Such positioning makes it almost impossible to update the materialized view in a timely manner. Actively updating the materialized view will inevitably seize computing and memory resources, hampering the timely responses to user queries. To prevent "putting the cart before the horse", almost all analytical databases adopt either a passive updating strategy (that is, need to be actively driven by users) or a delayed updating strategy (wait until the system is idle to update) for materialized views.
Correctness guarantee. The problem of resource competition can be solved easily by adding more computing nodes, however, the problem of guaranteeing correctness is much more non-trivial for real-time analysis systems. Batch processing systems process finite and bounded data, while stream processing systems process infinite and unbounded data. When processing unbounded data, data disorder may occur due to various reasons such as unstable network communication or different network latencies from different sources. Stream processing systems introduce the concept of watermarks to solve this problem. The output result is considered to be semantically correct when the out-of-order data are processed in a certain order. Outdated data will be abandoned when they pass a threshold called a watermark. However, real-time analytical systems lack the basic design of watermarks, which makes it impossible for them to deliver correct results as stream processing systems do. This correctness guarantee is crucial in various application scenarios such as risk control and advertising recommendations. A system without correctness guarantees on real-time data sources cannot replace stream processing systems.

Considerations Before Adopting Stream Processing

Stream processing is not a panacea, and neither can stream processing completely replace batch processing in all scenarios. Before adopting stream processing in your tech stack, you may want to evaluate the following aspects.

Flexibility. Stream processing requires users to predefine queries, to achieve continuous computation over streaming data. This requirement makes stream processing less flexible than batch processing, which can actively respond to user-triggered one-shot queries. As a result, stream processing is more suitable for scenarios where queries can be created before execution, while batch processing is more suitable for scenarios where frequent user interactions are required.
Expressiveness. Stream processing uses incremental computation to reduce redundant overhead. However, incremental computation also brings a major problem, that is, the system expressiveness is limited. The main reason is that not all computations can be handled incrementally. A simple example is calculating the median from a data sequence: no algorithm can find the exact median number incrementally without scanning the whole dataset. Keeping this in mind, you should evaluate if stream processing is suitable when handling some highly complex scenarios.
Computing costs. Stream processing can greatly reduce the cost of real-time computing. But this does not mean that stream processing can be more cost-effective than batch processing in all scenarios. In fact, in scenarios where result freshness is not critical, batch processing can save more cost. Just think of generating the quarterly financial report inside a company. Stream processing would be an overkill for this case. This is because to perform incremental computation, stream processing systems have to continuously maintain the internal computation state, which keeps consuming resources. In contrast, batch processing only performs computations when user requests arrive, and no additional resources will be spent on maintaining computation states.

Unifying Stream Processing and Batch Processing

Stream processing and batch processing have their pros and cons, and it is difficult to completely replace each other in many real-world scenarios. Many believe that stream processing and batch processing will coexist in the long run. Observing this, it is natural to consider unifying stream processing and batch processing using a single system. Many existing systems have explored this direction, including those well-known systems such as Flink and Spark. While the unified approach to stream and batch processing can fit into some scenarios, the reality is that, at least for now, most users still choose to adopt separate solutions for stream processing and batch processing, respectively. The reason is straightforward: integrating two different systems collectively not only addresses performance and stability concerns but also offers users the opportunity to achieve the best of both worlds.

At the current stage, RisingWave is more focused on stream processing, and users can leverage RisingWave connectors to integrate with mainstream batch processing systems. In the current RisingWave version, users can easily export data to systems such as Snowflake, Redshift, Spark, and ClickHouse. I feel optimistic about the future of a unified approach to batch and stream processing, and in the long run, RisingWave will also explore this direction. In fact, streaming databases are already unifying stream processing and batch processing: when new data flows into the streaming database, the streaming database performs stream processing, but when a user initiates ad-hoc queries, the streaming database performs batch processing.

Postscript

While I am proud of having been working in the stream processing domain for over a decade, I have to be honest and admit that I once thought there was not much room for growth in this area. I can hardly imagine how cloud computing changed everything and brought the stream processing system back to the center of the stage after 2020. Nowadays, more and more people are researching, developing, and adopting stream processing technology. I shared my thoughts on stream processing in this blog, and hope it will help. Everyone is welcome to join our community to discuss the future of stream processing.

About RisingWave

RisingWave is a distributed SQL streaming database in the cloud. It is an open-source system released under Apache 2.0 license.

Official website: risingwave.com

GitHub: risingwave.com/github

Slack community: risingwave.com/slack

Documentation: risingwave.dev