HUAWEI CLOUD DWS · MRS · DLI → STACKIT · ARCHITECTURE
Huawei DWS, MRS and DLI migration architecture
Huawei Cloud Data Warehouse Service, MapReduce Service and Data Lake Insight have no managed counterpart on STACKIT, so StackToIT classes them REDESIGN: the data and the queries move to a redesigned lakehouse or warehouse, and the jobs move to self-managed engines on SKE or to the lakehouse. In the example run, a DWS cluster, an MRS cluster and a DLI queue come out as three REDESIGN units, two with LOW confidence, each with its critical settings left to your architects. This page sets out four target designs, what the run can and cannot tell you about each, and how to choose per workload.
Four target designs
| Design | Where it fits | Trade-offs |
|---|---|---|
| A. Lakehouse on Object Storage with STACKIT Dremio | SQL analytics over files and relational sources, the role of DWS queries and DLI SQL. The Dremio documentation lists connectors for S3-compatible object storage, relational databases and NoSQL sources, and Iceberg and Delta Lake tables. | The provider marks the Dremio resource as an opt-in feature that may still change, and documents it for the eu01 region only. Queries are rewritten for a new engine. The run records that there is no generally available target resource yet. |
| B. Self-managed engines on SKE | Spark, Hive and Hadoop jobs from MRS and Spark jobs from DLI. The run names this route for MapReduce Service and Data Lake Insight. | Your team operates the engines and their upgrades. HDFS storage becomes object storage, which changes how jobs read and write. |
| C. Self-managed warehouse | A DWS workload that needs a dedicated warehouse engine. The run’s reason names a redesigned warehouse beside the lakehouse; it names no product, so the engine and whether you run it yourself are your choice. | Product choice, sizing and operations are yours. The DWS documentation states compatibility with SQL-92, SQL-99 and SQL:2003 syntax and interoperability with PostgreSQL, Oracle, Teradata and MySQL ecosystems, so dialect-specific SQL needs a test against the new engine. |
| D. Retain on Huawei Cloud for now | A workload whose data volume or SQL dependence makes a move premature. The STACKIT Migration Framework lists Retain among its strategies. | The dependency stays, and consumers on STACKIT read across clouds until the workload moves. |
Huawei Cloud services described from their documentation pages, STACKIT options from the Dremio documentation, the Terraform provider documentation and the run reasons, all read on 4 November 2026. No benchmark or price is implied.
A warehouse, a Hadoop cluster and a queue, assessed
A small Huawei Cloud data estate with eight resources, written for this page and assessed by StackToIT on 4 November 2026: DWS cluster with three nodes, MRS cluster with Hadoop, Spark and Hive, a DLI queue of 16 CU, a DLI database, an OBS bucket and the network. Left: three blocks of the input. Right: the result the run recorded for them, an excerpt of assessment.json with the values as the run wrote them (the target field is left out).
resource "huaweicloud_dws_cluster" "warehouse" {
name = "lake-dws"
version = "8.2.1"
node_type = "dws.m3.xlarge"
number_of_node = 3
availability_zone = "eu-west-101a"
user_name = "dbadmin"
user_pwd = var.dws_password
vpc_id = huaweicloud_vpc.main.id
network_id = huaweicloud_vpc_subnet.app.id
security_group_id = huaweicloud_networking_secgroup.app.id
volume {
type = "SSD"
capacity = 300
}
}
resource "huaweicloud_mrs_cluster" "batch" {
cluster_name = "lake-mrs"
cluster_version = "MRS 2.1.0"
cluster_type = 0
available_zone_id = "ae04cf9d61544df3806a3feeb401b204"
billing_type = 12
master_node_num = 2
core_node_num = 3
master_node_size = "c3.4xlarge.2.linux.bigdata"
core_node_size = "c3.xlarge.4.linux.bigdata"
volume_type = "SAS"
volume_size = 100
safe_mode = 0
cluster_admin_secret = var.mrs_admin_secret
vpc_id = huaweicloud_vpc.main.id
subnet_id = huaweicloud_vpc_subnet.app.id
component_list {
component_name = "Hadoop"
}
component_list {
component_name = "Spark"
}
component_list {
component_name = "Hive"
}
}
resource "huaweicloud_dli_queue" "etl" {
name = "lake-etl"
cu_count = 16
}[
{
"id": "huaweicloud_dws_cluster.warehouse",
"result": {
"class": "REDESIGN",
"confidence": "LOW",
"reason": "Data Warehouse Service has no managed counterpart. The data and queries move to a redesigned lakehouse or warehouse."
}
},
{
"id": "huaweicloud_mrs_cluster.batch",
"result": {
"class": "REDESIGN",
"confidence": "LOW",
"reason": "MapReduce Service and Data Lake Insight have no managed counterpart. Jobs move to self-managed engines on SKE, or to a redesigned lakehouse."
}
},
{
"id": "huaweicloud_dli_queue.etl",
"result": {
"class": "REDESIGN",
"confidence": "MEDIUM",
"reason": "MapReduce Service and Data Lake Insight have no managed counterpart. Jobs move to self-managed engines on SKE, or to a redesigned lakehouse."
}
}
]REDESIGN, with the reason
Data Warehouse Service has no managed counterpart; MapReduce Service and Data Lake Insight have none either. Each reason names the redesign rather than a copy.
LOW confidence twice
The DWS and MRS units are LOW, the DLI queue MEDIUM. Confidence says how sure the rule is about this unit’s configuration, not how hard the migration is.
Critical settings left to you
Twelve for DWS, sixteen for MRS and two for the DLI queue are listed in the architect report for your team, among them node type and node count for DWS and the administrator secret for MRS.
How the eight units come out
| Unit | Class and confidence | Wave and what it means |
|---|---|---|
| VPC, security group, OBS bucket | RECONFIGURE · MEDIUM | Wave 1. Network and Object Storage are the ordinary part: the bucket becomes an S3-API bucket on STACKIT. |
| VPC subnet | RECONFIGURE · MEDIUM | Wave 2. A STACKIT network with its own address range. |
| DLI queue | REDESIGN · MEDIUM | Wave 1. Jobs move to self-managed engines on SKE or to a redesigned lakehouse. |
| DLI database | MANUAL_REVIEW · LOW | Wave 1. Resource type not in the knowledge base catalogue of this build; nothing of it is assessed. |
| DWS cluster | REDESIGN · LOW | Wave 3. Data and queries move to a redesigned lakehouse or warehouse. |
| MRS cluster | REDESIGN · LOW | Wave 3. Same reason as the DLI queue. |
Classes, confidence and waves as the run decided them. The DWS and MRS units wait for the network in waves 1 and 2, but their data and jobs are a separate plan.
What the data file lists, and what it misses
Left: the stateful table of migration/data-movement.md for this run. It lists only the OBS bucket: the DWS tables, the HDFS data of the MRS cluster and the DLI database are not there, so add them to your own data plan. Right: a second, small run on the two newer resource types that the provider recommends or offers for MapReduce and for DLI compute pools. That probe input, written for this page, sets the attributes and node blocks the 1.100.0 provider schema marks as required; the result depends only on the resource type.
## Stateful source units
| Unit | Source service | Target service | Application | Mechanism | State | Data class | RPO | Downtime tolerance |
|---|---|---|---|---|---|---|---|---|
| huaweicloud_obs_bucket.raw | huaweicloud_obs_bucket | STACKIT Object Storage | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |[
{
"id": "huaweicloud_mapreduce_cluster.batch",
"result": {
"class": "MANUAL_REVIEW",
"confidence": "LOW",
"reason": "huaweicloud_mapreduce_cluster is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type)."
}
},
{
"id": "huaweicloud_dli_elastic_resource_pool.pool",
"result": {
"class": "MANUAL_REVIEW",
"confidence": "LOW",
"reason": "huaweicloud_dli_elastic_resource_pool is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type)."
}
}
]Only the bucket is listed
The data file lists the OBS bucket as the stateful unit. The tables inside DWS, the HDFS content of MRS and the DLI database are data too, and the run does not list them. Inventory them by hand.
Resource names matter
The provider documents huaweicloud_mrs_cluster as deprecated and recommends huaweicloud_mapreduce_cluster. In this build the older name is REDESIGN, while mapreduce_cluster and dli_elastic_resource_pool are unknown types and come out MANUAL_REVIEW with LOW confidence. Read the unknown ones as the same redesign.
How to decide, workload by workload
1. Move the storage first
Data in OBS becomes data in STACKIT Object Storage, a RECONFIGURE unit with an S3 API. Copy it, for example with rclone. Any lakehouse design needs the files there anyway.
2. Inventory what Terraform cannot show
List schemas, tables, row counts, query logs, scheduled jobs, HDFS paths and DLI databases. The three services hold different things: MRS is a Hadoop platform with Spark, Hive, Flink and Kafka components, DLI is a serverless Spark and Flink SQL service, DWS is an analytical SQL database whose storage-compute decoupled architecture keeps user data on OBS.
3. Sort workloads by shape
Interactive SQL, scheduled batch, streaming and ad hoc serverless queries do not need the same target. Streaming and Spark batch point to design B, warehouse SQL to A or C.
4. Prototype the hardest query
Take the slowest or most dialect-specific query of each workload and run it on the candidate engine with a real extract. Dialect and file-format surprises show up here, not in a diagram.
5. Plan copy and cutover per workload
Choose the data mechanism, the window and the order in which reporting tools repoint. The run sets no mechanism and gives no duration.
What the run does and does not decide
It decides the class
REDESIGN for DWS, MRS and the DLI queue, with the reason in assessment.json.
It names candidates
A lakehouse on Object Storage with STACKIT Dremio, or a self-managed warehouse. The Dremio resource is an opt-in provider feature that may still change, so the run records that no generally available target exists yet, as a blocker, and leaves class and confidence unchanged.
It does not size the target
Node counts, volumes and queue capacity are inputs for your design. The architect report lists twelve critical settings for the DWS cluster, sixteen for the MRS cluster and two for the DLI queue, and maps none of them.
It does not see the data
Sizes, change rates and downtime tolerance are not in the Terraform. They show as not known in the data file.
It does not pick the region
The provider documents Dremio for eu01 only, and the run records region availability of these targets as not established. Settle the region before the design.
It does not move anything
StackToIT never moves data or runs jobs. Every step is a manual step with an owner.
Questions about analytics workloads
Is there a managed STACKIT warehouse that replaces Huawei Cloud DWS?
The run states that DWS has no managed counterpart. STACKIT Dremio is the managed lakehouse candidate for SQL analytics over object storage, but it is a different engine, not a like-for-like warehouse, and the provider resource is an opt-in feature that may still change.
Why are two of the three units LOW confidence?
The architect report defines confidence as how sure the matched rule is about this unit's configuration. The run records LOW for DWS and MRS and MEDIUM for the DLI queue; the queue sets only a name and a CU count, the clusters set twelve and sixteen settings the rule cannot place. Effort is a separate question.
Do Spark and Hive jobs from MRS run unchanged on SKE?
Job code can often stay, but the platform around it does not: you run the engines, the storage moves from HDFS to object storage, and the cluster settings are rebuilt. Test with a real job before you commit.
What about a DLI queue with 16 CU?
The queue is compute capacity and class REDESIGN. What moves are the SQL and Spark applications that use it, and the databases and tables behind them. Size the replacement from those, not from the CU count.
Sources
Your next move: STACKIT.
Tell us about your estate. We show you what StackToIT delivers for it: target architecture, Terraform artifacts and a structured migration plan.