BI Platform Practice at Xiaomi: Evolution, Architecture, and Future Directions
This article details Xiaomi's multi‑year journey in building a group‑wide Business Intelligence platform, covering its historical evolution, technical challenges in performance, modeling, visualization and permissions, the current four‑layer architecture, and future plans to make the platform more business‑centric and simpler.
Introduction: The talk shares Xiaomi’s experience in building and evolving its Business Intelligence (BI) platform, covering four parts: the platform’s development history, exploration and practice of construction, current product architecture, and future plans.
Development Evolution: Before 2019, Xiaomi’s businesses built independent theme‑based BI solutions. In 2020, with the establishment of the Big Data department, a unified data middle‑platform was created, integrating multiple products and improving data collection and warehousing. By 2021 the platform matured, supporting massive dashboard demands and executive‑level views with mobile and IM integration. In 2022 the platform became enterprise‑wide, extending from internet‑centric use cases to R&D‑production‑finance domains, prompting a redesign of the underlying architecture and a focus on simplifying data consumption.
Construction Challenges and Practices: Four major difficulties are highlighted—performance, modeling, visualization, and permission management. Achieving sub‑second response times requires careful data volume control, OLAP engine selection, and query optimization. Modeling complexities arise from ambiguous responsibilities between data processing and modeling layers, especially for cumulative metrics. Visualization faces a “bottomless pit” of custom dashboard requirements, while permission systems must align fine‑grained data and UI controls with organizational structures.
Technical Choices: Early data sources were MySQL and Doris; Hive support proved slow. The platform experimented with engines—initially Kylin, then Kudu (costly), and finally Doris for wide‑table joins, later adding Presto for Hive queries. Data volume reduction, query scheduling, and extensive SQL tuning were employed to improve performance. Modeling shifted from pure SQL to MDX to better handle complex KPI calculations while retaining SQL compatibility.
Product Architecture: The current architecture consists of four layers—Data Source (offline Hive/Iceberg, online MySQL/Doris/SAP HANA, files), Semantic Model (metadata, metrics, functions, acceleration), Capability (visualization, data encyclopedia, intelligent analysis such as anomaly detection and root‑cause), and Scenario (dashboards on PC/mobile, reports, and intelligent bots). Permissions are managed centrally, covering data resources, feature resources, and RBAC linking users, roles, and assets.
Future Directions: Xiaomi aims to make the platform more business‑oriented and simpler. Emphasis will be on supporting diverse industry needs, reducing the end‑to‑end data consumption chain, and introducing interactive, AI‑driven features such as data robots and smart alerts to move from static reporting to data intelligence.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
DataFunSummit
Official account of the DataFun community, dedicated to sharing big data and AI industry summit news and speaker talks, with regular downloadable resource packs.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
