By Alibaba Cloud Messaging Team
In AI-driven data application scenarios, enterprises increasingly need a data foundation that simultaneously supports real-time consumption, historical accumulation, and multi-engine reuse. The combination of Kafka, the Iceberg open table format, and object storage is becoming an important direction for streaming data lake ingestion. However, the traditional approach that relies on external ETL jobs such as Flink and Spark also brings problems such as long pipelines, many system boundaries, and complex operations. Centering on the “Zero-ETL” trend, this article discusses why streaming data lake ingestion needs architectural subtraction, and, drawing on the practice of Kafka × Table Bucket, analyzes how a solution that shifts general-purpose lake-ingestion capabilities forward into the messaging and table-storage pipeline can reduce complexity while balancing real-time performance, consistency, schema evolution, CDC semantics, and open-ecosystem compatibility.
Over the past few years, the evolution path of enterprise data systems has become increasingly clear: from traditional offline data warehouses to real-time data warehouses, and then from “parallel streaming and batch” toward unified data lakes and open table formats. After entering the AI era, this trend has accelerated further—more and more data scenarios simultaneously demand both real-time processing and historical analysis.
Whether it is model training, feature engineering, and online inference, or business analytics, user insight, and risk-control auditing, enterprises need a data foundation that can both take in real-time data and accumulate long-term data assets. The former emphasizes low latency and continuous processing capability, while the latter emphasizes low cost, governability, and multi-engine reuse. When both types of capability must be achieved simultaneously on the same set of data, that data must complete ingestion, accumulation, and reuse over a shorter pipeline.
Against this backdrop, Kafka + Iceberg (open table format) + object storage has become a common architectural combination: Kafka takes in the continuously changing data stream, Iceberg organizes the data into governable, queryable, and evolvable tables, and object storage carries massive volumes of historical data while providing a low-cost, scalable storage foundation. Since AWS launched S3 Tables in 2024, the architectural direction centered on “streaming ingestion + open table format + object storage” has become even clearer.
Figure 1: Streaming ingestion, open table formats, and object storage are forming a new data-foundation combination
As the Lakehouse architecture becomes the mainstream paradigm in the big-data field, writing streaming data into open table formats (Iceberg / Delta Lake / Hudi) in real time or near real time has become a hard requirement. As the mainstream streaming-data bus, Kafka's integration capability with data lakes directly influences architectural choices. Judging from product evolution and user demand over the past two years, the real-time lake-ingestion field broadly exhibits four trends:
· Open format first: By virtue of its open metadata standard, multi-engine compatibility, and strong schema-evolution capability, Iceberg continues to see rising adoption in cross-cloud data lakes and open-ecosystem scenarios, and has become one of the core options among open table formats.
· Zero-ETL demand: More and more users tend to reduce data-movement steps, hoping that the messaging system can persist data into open table formats more directly, so as to lower architectural complexity and latency.
· Deepening storage-compute separation: Whether for the Kafka storage layer or the data-lake storage layer, storage-compute separation has become a core architectural evolution direction for reducing cost and improving efficiency.
· Going serverless: Making stream processing and messaging services serverless lowers the operations barrier, and the pay-as-you-go billing model has become the first choice for many small and medium-sized enterprises and new businesses.
From a competitive-landscape perspective, the current Kafka lake-ingestion market can be divided into three major camps, with clear differences in technical approach and commercial orientation:
From an architectural-philosophy standpoint, the native-integration camp is closer to the Zero-ETL — shifting general-purpose lake-ingestion capabilities forward to a position closer to the main messaging pipeline. But this also places higher demands on openness and neutrality: it must be compatible with the open ecosystem like the Connector camp, while avoiding being locked into a single format or a single engine like the ecosystem-platform camp. This is exactly the question that the Kafka × Table Bucket path discussed later focuses on answering.
In fact, the real difficulty does not lie in “whether Kafka can write data into tables,” but in “whether the writing can be done stably, efficiently, and at low cost.”
On the one hand, real-time data is inherently continuous and fragmented; if the write strategy is unreasonable, it easily leads to small files, partition imbalance, metadata bloat, write amplification, and compaction pressure. On the other hand, upstream field changes, type changes, and CDC semantics collide with the table format's requirements for schema, consistency, and transactions—how schema evolves, how Update / Delete is expressed, and how to recover after a write failure are all critical issues in production environments.
From the perspective of practical value, the reason this class of solutions attracts continued attention is that it simultaneously addresses three real-world demands: reducing overall construction and operations costs through a cloud-native architecture; bringing real-time ingestion and long-term analysis closer to a “stream-lake unified” mode of collaboration; and, while preserving users' data sovereignty over their own object storage, leveraging managed capabilities to reduce the burden of small-file governance, schema evolution, and pipeline maintenance.
This also means that the core proposition of streaming data lake ingestion is changing: it is no longer “whether to adopt this technology combination,” but “whether pipeline complexity can be converged through architectural subtraction, shifting general-purpose lake-ingestion capabilities forward into platform capabilities as much as possible.”Judging from the current evolution direction, the answer is becoming increasingly clear — real-time lake ingestion is saying goodbye to external ETL.
If the first part answered “why do architectural subtraction,” then this part answers: in the real-time lake-ingestion pipeline, what is actually removed.
The traditional streaming data lake-ingestion path is usually: Kafka → Flink / Spark Streaming → open table → object storage. This pipeline is already fairly mature and remains an effective solution in scenarios that require complex cleansing, real-time aggregation, stateful computation, and multi-stream correlation.
The problem is that not all scenarios need a complete external compute pipeline. In many cases, what enterprises really need to solve is writing the data continuously arriving in Kafka into queryable, manageable tables in a stable and continuous manner. If maintaining Flink or Spark Streaming jobs is only for completing this step, it means additionally taking on three types of system complexity:
· Increased system boundaries: Data flows out of Kafka and is then consumed, transformed, written, and committed by external tasks, crossing at least one independent runtime and one independent scheduling system in between. The longer the pipeline, the larger the failure surface, and the more complex the recovery path.
· Duplicated implementation of general-purpose capabilities: Message decoding, schema mapping, offset management, transaction commit, small-file control, and failure recovery are essentially common engineering problems in real-time lake ingestion, yet they often need to be implemented and maintained separately in each ETL job.
· Continuously rising platform costs: To support these lake-ingestion tasks, enterprises must also maintain additional stream-computing clusters, monitoring systems, release processes, and troubleshooting mechanisms. As the number of pipelines grows, this portion of cost keeps accumulating.
Figure 2: Illustration of an integrated Zero-ETL solution for streaming data lake ingestion
Therefore, what “Zero-ETL” truly removes is not data processing itself, but the general-purpose lake-ingestion capabilities that originally had to be repeatedly borne by external jobs:
· an extra layer of data-movement pipeline;
· a batch of repeatedly implemented engineering logic;
· a portion of operations complexity unrelated to business value.
Figure 3: Capability differences between the traditional external ETL pipeline and the built-in lake-ingestion solution
From this perspective, “Zero-ETL” is more like a change in architectural thinking: rather than continuing to assemble pipelines through external systems, it is about converging general-purpose lake-ingestion capabilities as much as possible into built-in infrastructure capabilities. For users, such capabilities are closer to a “zero-code, configuration-takes-effect-immediately” delivery model, and no longer exist in the form of standalone ETL tasks.
If the core of “Zero-ETL” is converging general-purpose lake-ingestion capabilities into platform capabilities, then the key to Kafka × Table Bucket is making the path “from message to table”shorter and more stable.
Here, Table Bucket can be understood as the table-hosting capability on top of object storage. It does not simply write files into object storage; rather, it organizes, manages, and serves data in the form of tables, so that the data retains the low-cost, scalable characteristics of object storage while also possessing structured capabilities oriented toward computation and governance.
Logically, this kind of Zero-ETL lake-ingestion path can usually be divided into three layers:
Compared with the traditional three-stage architecture of “Kafka → external ETL → table,” the biggest change is:a portion of the general-purpose lake-ingestion logic that originally relied on external jobs is shifted forward into a pipeline closer to Kafka.
Furthermore, the transformation engine and table-writing capability can run in an embedded manner within an execution pipeline closer to the Broker, reducing the complexity brought by network round-trips, independent scheduling, and extra ETL clusters. In some implementations, the transformation of data from Kafka partitions to Iceberg tables can be completed within the same process, and the sync task can also be bound to the Broker's lifecycle, so that resource scheduling and fault recovery converge within the same system.
Figure 4: Overall architecture of Kafka × Table Bucket's Zero-ETL lake ingestion
From being written into Kafka to becoming queryable by downstream compute engines, a message passes through three key stages.
Stage 1: Record Transformation
After a message enters Kafka, it is first transformed into a structured object suitable for table writing. This process is usually carried out by a component such as RecordProcessor, including Key / Value deserialization, Transform-chain processing, and record assembly. It supports multiple Converters such as String, Avro Registry, and Protobuf, and can also use transform chains such as Flatten and Debezium to expand nested structures or unpack CDC events. Finally, the Key, Value, and Headers, together with meta-information such as topic, partition, offset, and timestamp, are consolidated into a complete structured record.
Stage 2: Schema Awareness and Evolution
Before actually writing into the table, the system needs to compare the schema of the current record with the schema of the target table. If a compatible change is detected—such as adding an optional field, changing a required field to optional, or promoting a type upward (int → long, float → double)—it can first flush the current batch, then apply the new schema and continue writing. In this way, common schema changes no longer need to rely entirely on manual intervention.
Stage 3: Iceberg Writing and Transaction Commit
After transformation and schema processing are complete, the data is written into columnar files on object storage according to the target table and partitioning strategy:
· Append mode: uses PartitionedWriter/UnpartitionedWriter to append data directly;
· Upsert mode: generates both DataFiles (data files) and DeleteFiles (deletion-marker files) at the same time, supporting the three CDC operations Insert/Update/Delete.
When a file reaches a set threshold (for example, a configurable target size such as 64MB), it automatically switches to a new file to reduce the risk of overly fragmented files. Finally, a new Snapshot is generated through an atomic table-level transaction commit, giving downstream consumers a consistent, visible view of the data.
Figure 5: The end-to-end write path from Kafka messages to object-storage tables
For real-time lake ingestion to be truly usable, the measure is not only “whether data can be written in,” but also whether stable consistency and recoverability can be maintained under low-latency requirements. Especially in distributed environments, the coordination among data writing, metadata commit, progress management, and failover often determines whether the pipeline can run stably over the long term.
A more ideal approach is to keep key state cohesive within the main pipeline, rather than relying on an external KV store or other external state systems. For example, maintaining lake-ingestion progress within the Kafka Leader metadata can reduce system coupling and lower the risk of inconsistency. Paired with this is a more lightweight high-availability mechanism: during node switchover or scale-out, new nodes can take over sync tasks more quickly.
The specific capabilities manifest in several aspects:
· Storage-compute separation × lightweight HA: After compute and data persistence are decoupled, the compute layer breaks free from the constraints of the heavyweight ISR protocol and instead adopts a lightweight HA scheme. Follower Replicas serve only as compute hot standbys, retaining minimal metadata and handling minimal change requests; new nodes can take over quickly during failover and elastic scale-out.
· Dual-path sync alleviates the latency-throughput trade-off in lake-ingestion scenarios: The core contradiction of real-time lake ingestion lies in commit frequency—frequent commits have low latency but high metadata and flush overhead; batched commits have high throughput but sacrifice freshness. This kind of solution splits the sync pipeline into two paths: incremental pre-sync continuously performs data reading, transformation, and file writing during the gaps between commits; when strong-consistency sync is triggered, only a small incremental amount needs to be committed to complete the Iceberg transaction, thereby improving latency and throughput in the same direction.
· Offers two architectural modes, embedded and standalone: The embedded mode can achieve lower resource overhead, but running in the same process increases GC pressure and may potentially affect message send/receive latency; the standalone mode has higher resource cost, but thanks to process isolation, it reduces interference with the core send/receive pipeline. The dual-mode design aims to precisely match the functional demands and workload characteristics of different customers.
· Lake-ingestion progress kept cohesive in Leader metadata: Lake-ingestion progress is maintained directly in the Kafka Leader metadata, completely removing the dependency on external systems such as an external KV store, ensuring strong consistency while eliminating inter-system coupling.
Figure 6: Low latency and strong consistency are not contradictory; the key lies in how state is converged
Schema inconsistency is one of the most common problems in the Kafka lake-ingestion pipeline, and also one of the most likely to cause operational burden. A more reasonable approach is to converge common compatible changes into system capabilities:
Figure 7: Shifting high-frequency schema changes forward into platform capabilities
The small-file problem is one of the most common performance hazards in real-time lake ingestion. Real-time data arrives continuously and in a scattered manner; if writing lacks control, it easily produces a large number of small files in object storage, which in turn brings chain-reaction problems such as metadata bloat, slower query planning, and increased compaction pressure. Therefore, small-file governance cannot rely solely on post-hoc compaction, but should minimize problems as much as possible during the write phase.
A more complete approach is to adopt a multi-layer progressive governance mechanism that governs at both the upstream (pre-write) and downstream (post-write) levels simultaneously:
Typically, L1 ~ L3 are completed on the lake-ingestion engine side, while L4 is handled by background offline compaction.
Figure 8: Small-file governance requires combining upstream control with downstream consolidation
A reasonable partitioning strategy directly affects whether subsequent queries can effectively prune the data range, reducing full-table scans and useless I/O. This kind of solution typically supports seven mainstream partitioning methods: direct field partitioning, Year / Month / Day / Hour time partitioning, Bucket partitioning, and Truncate partitioning, and it supports multi-dimensional combined partitioning.
# Example: two-dimensional partitioning by region + day
partition_by: "region, day(timestamp)"
# Example: hash bucketing for high-cardinality IDs
partition_by: "bucket(user_id, 10)"
# Example: grouping by email prefixpartition_by: "truncate(email, 5)"Strategies like bucket(user_id, 10) or truncate(email, 5) are more suitable for high-cardinality or prefix-grouping scenarios.
Figure 9: Partition design determines query-pruning efficiency and long-term data organization
For scenarios such as database change synchronization, real-time lake ingestion is not just about appending new data; it also needs to handle state changes such as Insert, Update, and Delete. If the platform can directly recognize these semantics and map them to table-level Upsert or Delete, then the tables on object storage can present the current business state closer to real time.
# Typical configuration for CDC lake ingestion
transforms: debezium_unwrap
write_mode: upsert
table_format: iceberg-v2This kind of capability is usually adapted to CDC tools such as Debezium, automatically unpacking change events, and, with the help of Iceberg's Equality Delete mechanism, generating the corresponding data files and deletion markers, which are automatically merged into the latest view at read time.
Figure 10: CDC events can be directly mapped to table-level update semantics
For a Zero-ETL solution to become an infrastructure capability, besides having a shorter pipeline, it must also possess good open compatibility—not only being able to write data in, but also being able to integrate smoothly into the enterprise's existing data ecosystem. Such solutions usually need to be compatible with multiple Catalog interfaces:
· Iceberg REST Catalog: the mainstream standard of the open ecosystem;
· OSS Tables-compatible Catalog: for S3 Tables migration scenarios.
Looking further downstream, when table capabilities are built on open interfaces and open formats, different compute and query engines such as Spark, Trino, Flink, and DuckDB can all perform analysis and processing around the same copy of data.
Once the above capabilities are combined, the value of Kafka × Table Bucket is not just technical feasibility, but also its degree of fit with today's data infrastructure. What truly deserves attention is not merely that it removes one ETL job, but that it reconverges real-time lake-ingestion capabilities from the protocol layer to the storage layer.
What this kind of integrated architecture first changes is the long-standing separation between “stream” and “table.” In the traditional model, Kafka takes in streaming data and Iceberg organizes analytical tables, while an external ETL system is needed in between to complete format conversion, schema alignment, and commit control; in the integrated architecture, these capabilities are embedded as much as possible into positions closer to the main pipeline.
Specifically, it brings three changes:
· Automatic stream-batch conversion: writing data is lake ingestion; it natively supports both stream reads and batch reads, with no need to maintain two separate code paths.
· Schema self-adaptation: automatically perceives and handles upstream schema changes, supporting ADD_FIELD, MAKE_OPTIONAL, PROMOTE_TYPE , and recursive evolution of nested structures, significantly reducing manual intervention.
· In-process bound scheduling: the transformation engine is inlined within the Broker process, with deep collaboration between compute and storage, improving data freshness while shortening the pipeline. Compared with traditional external ETL tasks, this approach makes it easier to converge data visibility to the minute level, and under suitable conditions it can further approach the second level.
Figure 11: The convergence of capabilities from protocol to storage is the core value of this kind of architecture
The second value of this kind of architecture lies in completing, in a lighter-weight manner, the general-purpose lake-ingestion tasks that originally relied on external ETL jobs.
On the one hand, the lightweight Zero-ETL architecture directly connects the Kafka streaming protocol with the Iceberg table format, reducing the development and operations costs brought by intermediate task chains such as Flink / Spark Streaming. On the other hand, relying on managed capabilities, users get closer to a “zero-code, one-click enablement, configuration-takes-effect-immediately” usage model, significantly shortening the delivery cycle of the lake-ingestion pipeline.
More importantly, around stability and cost, this kind of architecture usually builds in a whole set of optimization mechanisms:
· Multi-layer small-file governance: from in-memory buffer merging, 32MB micro-batch processing, and 64MB target file size to background compaction, controlling file-organization quality in a layered manner.
· Lower TCO: through a cloud-native architecture and storage-compute collaboration, it reduces the overall cost brought by extra compute pipelines and duplicated system construction; in general-purpose real-time lake-ingestion scenarios, the cost structure is closer to the binary combination of “Kafka + object storage” rather than the triple cost of “Kafka + ETL + object storage.”
· More stable production performance: through progress cohesion, lightweight HA, transaction commit, and managed recovery mechanisms, it improves the pipeline's stability during failover and continuous operation.
As can be seen from the comparison in the table above, the Zero-ETL solution significantly simplifies the architecture in general-purpose lake-ingestion scenarios; only when window aggregation, multi-stream joins, or complex stateful computation are involved does it still require a dedicated stream-computing engine to work alongside it.
Beyond the aforementioned value, whether this kind of solution can become an infrastructure capability also depends on whether it can cover enough real-world scenarios. Judging from its current capabilities, it already possesses fairly strong generality:
· Multi-format compatibility: supports multiple serialization formats such as Avro, Protobuf, and String, adapting to mainstream data-production scenarios.
· Full CDC support: natively integrates Debezium unpacking, supports the three operation types Insert / Update / Delete, and is suitable for real-time synchronization from database to data lake.
· Flexible partitioning strategy: supports seven partitioning methods and multi-dimensional combinations, covering typical analytical scenarios such as logs, user profiles, and IoT devices.
· Multi-Catalog adaptation: Catalogs such as REST and OSS Tables can be connected directly, making it easier to integrate into the existing technology ecosystem.
Of course, one also needs to keep a clear-headed judgment about its boundaries. Zero-ETL is well suited to solving general problems such as“stably accumulating streaming data into tables,” but this does not mean that complex stream-computing engines will be replaced. If the business scenario requires window aggregation, multi-stream joins, dimension-table lookups, complex event processing, or large-scale state management, then Flink and Spark Streaming remain irreplaceable; whereas Zero-ETL is better at solving “how to let real-time data accumulate more naturally into tables on the lake.”
In this sense, the two are not in a simple replacement relationship, but rather a more reasonable division of labor: complex computation is handed to dedicated stream-computing engines, general-purpose lake ingestion is handed to built-in platform capabilities, and long-term data-asset accumulation is handed to object storage and open tables.This division of labor is itself a form of architectural subtraction.
Not all scenarios need the same lake-ingestion approach. But from a practical-deployment standpoint, four types of scenarios benefit first from the Zero-ETL path of Kafka × Table Bucket.
Figure 12: Typical scenarios for Zero-ETL lake ingestion
Logs are one of the most typical kinds of streaming data. Application logs, access logs, security logs, and system logs are usually first collected into Kafka via tools such as Filebeat / FluentBit, then consumed by different systems. If this data can be written directly into tables on object storage by day or by business dimension, downstream consumers can query it directly through engines such as Trino and Spark, retaining real-time ingestion capability while also being better suited for long-term retention and analysis.
partition_by: "day(timestamp), service_name"
write_mode: append
target_file_size: 64MBThe common characteristics of such scenarios are continuous writes, relatively stable query dimensions, and long retention periods, which makes them very well suited to being accumulated directly into tables through a shorter pipeline.
Database change synchronization is one of the most representative scenarios for Zero-ETL. After change events from MySQL Binlog or PostgreSQL WAL are written into Kafka via tools such as Debezium, if the platform can recognize the three CDC semantics of Insert, Update, and Delete and map them to Upsert or Delete on object-storage tables, then the tables in the data lake not only store a stream of change events but can also present the current business state closer to real time.
In terms of implementation, such scenarios usually enable a mode similar to debezium_unwrap + upsert, mapping it to a combination of data files and deletion-marker files.
For such scenarios, the key value is not just“writing the changes in,” but preserving primary-key semantics, deletion semantics, and a queryable current view as much as possible during the lake-ingestion phase.
IoT and event-tracking data usually share four common characteristics: high throughput, many sources, frequently changing fields, and strong demand for historical retention. Such scenarios can easily drag a platform into a state of “more and more pipelines, heavier and heavier jobs.” If general-purpose lake-ingestion capabilities are converged between Kafka and Table Bucket, and object storage is then used to carry massive volumes of historical data, it becomes possible to better balance real-time ingestion, cost control, and long-term analysis needs.
# Combined partitioning for high-throughput, time-series scenarios
partition_by: "bucket(device_id, 50), day(timestamp)"Downstream, one can use Spark for large-scale analysis or DuckDB for lightweight queries.
During model training, one needs to simultaneously manage massive volumes of road-test images, video clips, and point-cloud data, along with the corresponding annotation metadata. In the past, unstructured data was stored in object storage, structured metadata was stored in a database, and vector retrieval relied on a separate vector database; these three types of data were scattered across different systems, making data association and version rollback extremely difficult.
Relying on Alibaba Cloud OSS's complete object + vector + table data-storage system, raw road-test data is written into OSS object buckets, embeddings and recall indexes land in OSS vector buckets, and the vehicle annotation information and sensor metadata collected in real time by Kafka are written into OSS Table Buckets via the lake-ingestion capability. The three types of bucket data share the same set of accounts, permissions, and auditing systems; the screening of training samples and version rollback can be completed on a single platform, improving data-preparation efficiency several-fold and laying a solid foundation for rapid model iteration.
Zero-ETL is easily understood as a functional concept, as if it means data no longer needs to be transformed, or that all processing will converge into a single pipeline. But from the perspective of data-infrastructure evolution, the problem it really aims to solve is more specific: it is not about letting data pass through without processing, but about keeping those high-frequency, general-purpose, recurring lake-ingestion capabilities from having to be repeatedly built on external systems.
This is especially important when it comes to streaming data lake ingestion. What enterprises face is not a one-off project, but an infrastructure pipeline that runs over the long term, continuously expands, and constantly evolves. As long as there are too many system boundaries, overly long processing paths, and overly scattered state management, complexity will gradually surface as scale grows.
Therefore, what Kafka × Table Bucket represents is not just “writing data into tables on object storage,” but using a shorter path to converge, as much as possible, general-purpose capabilities such as message ingestion, format conversion, schema adaptation, CDC processing, transaction commit, and file organization, making real-time lake ingestion closer to a platform-native capability rather than the assembled result of a batch of external tasks.
What this reflects is a more general trend in data architecture in the AI era: data pipelines become shorter, data assets become more open, table capabilities and storage capabilities move closer together, and platform capabilities become as cohesive as possible rather than continuously expanding outward.
In this sense, a truly mature “Zero-ETL” reduces not just a segment of processing, but a layer of continuously accumulating system complexity. This is precisely the change in the next stage of data infrastructure that most deserves attention.
In the foreseeable next stage, this kind of capability will continue to evolve along three directions:
· richer Transforms and more intelligent operations capabilities;
· further integration with query, compute, and governance systems;
· continued adaptation to the evolution of open table formats such as Iceberg, and compatibility with more new formats oriented toward AI scenarios.
About the Implementation
The Kafka × Table Bucket Zero-ETL lake-ingestion capability discussed in this article is now implemented on Alibaba Cloud ApsaraMQ for Kafka × OSS Tables, where it has completed preliminary practical validation and has already been opened for invitational beta testing.
Without introducing additional ETL jobs, users can persist the Kafka Table Topic into OSS Table Bucket in the Iceberg open table format, and connect with the open ecosystem such as Spark, Trino, Flink, and DuckDB through the Iceberg REST Catalog. The capabilities mentioned in this article—multi-layer small-file governance, adaptive schema evolution, CDC Upsert, and multi-Catalog compatibility—have also been implemented in this solution.
774 posts | 60 followers
FollowAlibaba Cloud Native Community - July 14, 2026
Justin See - June 19, 2026
Apache Flink Community - July 28, 2025
Apache Flink Community - August 21, 2025
Apache Flink Community - April 25, 2025
Apache Flink Community - November 21, 2025
774 posts | 60 followers
Follow
Message Queue for Apache Kafka
A fully-managed Apache Kafka service to help you quickly build data pipelines for your big data analytics.
Learn More
Big Data Consulting for Data Technology Solution
Alibaba Cloud provides big data consulting services to help enterprises leverage advanced data technology.
Learn More
Big Data Consulting Services for Retail Solution
Alibaba Cloud experts provide retailers with a lightweight and customized big data consulting service to help you assess your big data maturity and plan your big data journey.
Learn More
ApsaraMQ for RocketMQ
ApsaraMQ for RocketMQ is a distributed message queue service that supports reliable message-based asynchronous communication among microservices, distributed systems, and serverless applications.
Learn MoreMore Posts by Alibaba Cloud Native Community