首次揭秘!小米大数据体系的建设与实践

本文涉及的产品
阿里云百炼推荐规格 ADB PostgreSQL,4核16GB 100GB 1个月
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
云原生数据仓库AnalyticDB MySQL版,基础版 8ACU 100GB 1个月
简介: 首次揭秘!小米大数据体系的建设与实践

前言


前段时间,很荣幸能参加云栖大会,并和大家分享一个议题,接下来我们来回顾一下


介绍


640.png

640.png

这次给大家带来的题目是《小米大数据运维管理体系的建设和实践》

今天整个分享分两部分,第一部分我们先来聊聊大数据运维数字化转型相关的内容 看看运维层面如何做到化繁为简,打造极致效率的;

紧接着第二部分,会给大家介绍一下小米大数据的技术架构 大家可以从中了解到小米怎样应对海量数据挑战的。


服务定位


640.png

为了帮助大家理解,我们先来简单聊一聊小米服务的架构

整个业务架构按照云计算的分层模型来说分为三层,依次是iass层、pass层、sass层

小米的iass层是一个混合云的现状,涉及IDC、公有云、网络等资源

小米的saas层不仅包含战略业务手机 * IOT * 汽车,还包括互联网、电商等数百个业务线

大数据作为pass层的一员,向下对接基础资源,向上承接业务的数据需求

提供离线报表、实时数仓等多种场景化能力

进一步帮助业务沉淀数据资产,提升整体数据效率

同时,大数据是的集团数字化底座,起到中流砥柱的作用


大数据服务架构


640.png

我们再来看下小米服务架构

整个小米的大数据服务是立足于x86和ecs之上的自下而上分为4层,依次是数据采集层、数据存储层、数据计算层、数据平台层

  • 数据采集层:主要使用自研的LCS和以Talos为代表的消息队列组合去实现的,这一块也会在后面的分享中展开讲述
  • 数据存储层:各类开源和自研存储引擎,包含我们的文件存储HDFS、KV存储HBase、对象存储Ceph等等;其中Pegasus是小米自研的,目前在apache已经开源。
  • 数据计算层:小米使用Yarn作为统一的资源管理,基于Yarn之上提供了批处理、流处理多种计算引擎,比如我们常见的MapReduce、Spark、Flink等;除此之外提供丰富的Olap引擎, 满足即席查询和检索需求。
  • 数据平台层:我们内部称之为数据工场,主要提供一站式的数据开发和数据管理能力

小米大数据业务发展非常迅速,已经覆盖国内海外多个区域

现已达到千+集群,数万节点的规模,在存储总量上已经近EB,计算任务30w/天


大数据运维转型挑战


640.png

如此数据规模,给服务运维带来了很多挑战,接下来,我们重点聊一聊

  • 运维成本高:传统运维方案和服务快速发展间的摩擦越来越多,导致运维成本呈熵增趋势,表现在质量、成本、效率各方面
  • 服务生命周期断层:大数据服务场景多、差异大,进一步增加了运维复杂度
  • 数据孤岛问题导致数据效率难以达到最佳状态
  • 运维层面呈经验型单核心发展,导致流程多落地难


轻舟整体能力结构


640.png

识别到问题后我们内部经过充分讨论,结合小米长期处于混合云的状态,发起了大数据运维中台-轻舟的整体规划

轻舟的主线是通过建设通用的基线能力、打造极致的垂域能力,来彻底贯通服务的生命周期

轻舟的整体能力结构是两能力+三中心

  • 基线能力层包含数据集市和发布中心,是整个运维管理体系的基础
  • 垂域能力层是贯穿服务的生命周期的,从服务的创建、运营到消亡,运营是我们日常工作花费时间精力最多的部分,包含服务升级迭代、机器管理、巡检管理等等

轻舟-一体化运维数据集市


640.png

在数据上为了解决孤岛问题,我们的解决方案是数据集成、架构解耦

通过构建大数据的一体化运维数据集市,收敛运维周边的所有数据,在数据源头和数据使用方之间做了一层解耦

在数据集市层我们制定了数据规范,将运维数据进行建模和分层处理

最后针对现有的数据源进行ETL调度,最终实现数据统一存储和使用

新的数据架构统一了运维数据体系,解决数据孤岛问题的同时,降低数据使用门槛,

目前整套数据体系已经应用到所有的大数据服务当中,真正做到了数出一孔

再有整个数据场景是闭环的,复杂度由O(n^2)变成O(n),并且核心数据分析逻辑可复用

整个新的数据架构是以数据场景为中心,取代之前以人为中心


轻舟-发布中心


640.png


轻舟的发布中心,通过调度编排+低代码的模式,去灵活定义工作流

同时依托模版将SOP进行沉淀,将个人经验转化为组织能力

上图就是发布中心的工作流模版,我们将执行系统和自定义脚本抽象为操作池

在调度编排上定义了多种逻辑区域,如我们的单次执行区,循环区和异步执行区。

目前整套正在逐步推广到所有大数据服务中,并且在一些场景中实现了变更的无人值守,效率提升30%;

后续整个发布中心也会在现有基础上继续优化和迭代,打造全局互联互通,最终实现全流程自动化


轻舟-运营中心


640.png

在运营中心中,我们结合数据和混合ops的理念,重点解决协同、服务差异和经验化等多个核心痛点

目前整体的效果还是不错的,比如在机器故障处理上已经实现了全流程自动

覆盖了95%的大数据服务,年均自动化处理机器故障近万次

在容量管理上,通过数据趋势的分析,覆盖全场景的容量的检测,降低大量的人工介入

在巡检管理上,通过将风险量化打分,进一步固化了巡检标准和处理流程

此外还有环境管理、配置管理,这里由于时间关系,就不一一介绍了

目前整个运营中心还在持续建设和完善中


核心数据链路


640.png

接下来是第二部分,大数据的架构实践

小米的核心数据链路,是以消息队列Talos+接入转储这样的组合,作为数据总线去实现数据从端到端的打通

各类原始数据,通过Agent的采集方式,进入到消息队列中,同时也支持基于binlog的存量和增量采集

在转储层一般通过的统一transfer模块,将数据灌入其他大数据的存储引擎中,供进一步使用

目前小米半数以上的数据都是通过这套方案接入的

整套流程做了产品化的设计,用户可以基于平台可自由定义数据链路


实时+离线湖仓架构


640.png

小米在数仓这个方向上也经历了基于Hadoop的离线数仓、Kappa实时数仓、Lambda架构数仓的过程

最新的数仓体系是基于数据湖iceberg+flink+spark构建的离线+实时数仓

结合上面提到的,数据经过MQ,最终进入到数据湖当中

数仓的每一层之间通过spark或flink方式进行etl建设

同时小米的olap引擎经过改造可直接查询湖中数据

整个方案在性能上效果表现很好,相比历史架构,其复杂度更低

由于了数仓存储层的统一和ztsd压缩算法的升级,在存储上也有很大的优化


HDFS Tiering 冷热数据分层


640.png

上面提到的数据湖iceberg的底座也是基于HDFS的,这里我们聊聊HDFS 的数据架构实践

一般业界实现中,为了实现数据分层的目的,会使用固态盘、机械盘和高密度存储的方式

在小米内部实现中,为了进一步压缩成本,自研了一套HDFS Tering的架构,将冷数据直接上云管理

上面就是整体的架构图,可以看到后台会有一个mover程序自动的将HDFS冷数据的转储到阿里云OSS上

随后更新Namenode上的元数据,实现文件属性到block到对象的变化

同时对用户透明,在架构上增加了proxydn模块

目前整套方案,已经累计冷备了200+PB数据,数据成本降低80+%


Lindorm引入(一)


640.png

为了支撑小米IOT的战略,解决业务海量数据索引+事务的需求

小米历史是基于封装HBase Coprocessor实现的自研存储,我们内部称之为SDS

但随着数据规模不断上涨,暴露了很多架构问题,比如基于范围分片,failover时间慢,依赖链路多等等

同时无法支撑业务的时序数据需求;此外SDS在开发维护成本上也非常高昂


Lindorm引入(二)


640.png

经过我们选型后,阿里云的Lindorm是非常符合我们需求的,在图中我们可以看到

Lindorm兼容HBase、Hadoop等协议,提供了宽表引擎的同时,还提供了时序等多种引擎

与此同时结合多级混合存储、Serverless等多种特性,可以解决很多遗留问题

小米内部测试后性能还是蛮不错的,符合我们的整体需求


Lindorm引入(三)


640.png

选型完成后,如何低成本的由sds迁移到lindorm上也是一个至关重要的问题。

图中就是整体的迁移架构,我们为IDC到云间打通百G的网络链路

服务层面,SDS和Lindorm之间会提前建立好数据同步链路,保证SDS 和Lindorm都是最新数据

为了最小化业务改动成本,提供了sds proxy的组件

将数据代理到lindorm上,最终实现业务迁移


大数据事件云图


640.png

这一页是最近一段时间参与的大数据相关的事件云图,由于时间关系,很遗憾不能展开说,感兴趣的老师可以线下沟通


往期热门笔记合集推荐:

  • HBase原理与实战笔记合集
  • MySQL实战笔记合集
  • Canal/Otter源码与实战笔记合集
  • Java实战技巧笔记合集
相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
目录
相关文章
|
3月前
|
SQL 分布式计算 运维
如何对付一个耗时6h+的ODPS任务:慢节点优化实践
本文描述了大数据处理任务(特别是涉及大量JOIN操作的任务)中遇到的性能瓶颈问题及其优化过程。
|
2月前
|
机器学习/深度学习 算法 搜索推荐
从理论到实践,Python算法复杂度分析一站式教程,助你轻松驾驭大数据挑战!
【10月更文挑战第4天】在大数据时代,算法效率至关重要。本文从理论入手,介绍时间复杂度和空间复杂度两个核心概念,并通过冒泡排序和快速排序的Python实现详细分析其复杂度。冒泡排序的时间复杂度为O(n^2),空间复杂度为O(1);快速排序平均时间复杂度为O(n log n),空间复杂度为O(log n)。文章还介绍了算法选择、分而治之及空间换时间等优化策略,帮助你在大数据挑战中游刃有余。
67 4
|
14天前
|
存储 消息中间件 分布式计算
Cisco WebEx 数据平台:统一 Trino、Pinot、Iceberg 及 Kyuubi,探索 Apache Doris 在 Cisco 的改造实践
Cisco WebEx 早期数据平台采用了多系统架构(包括 Trino、Pinot、Iceberg 、 Kyuubi 等),面临架构复杂、数据冗余存储、运维困难、资源利用率低、数据时效性差等问题。因此,引入 Apache Doris 替换了 Trino、Pinot 、 Iceberg 及 Kyuubi 技术栈,依赖于 Doris 的实时数据湖能力及高性能 OLAP 分析能力,统一数据湖仓及查询分析引擎,显著提升了查询性能及系统稳定性,同时实现资源成本降低 30%。
Cisco WebEx 数据平台:统一 Trino、Pinot、Iceberg 及 Kyuubi,探索 Apache Doris 在 Cisco 的改造实践
|
1月前
|
边缘计算 人工智能 搜索推荐
大数据与零售业:精准营销的实践
【10月更文挑战第31天】在信息化社会,大数据技术正成为推动零售业革新的重要驱动力。本文探讨了大数据在零售业中的应用,包括客户细分、个性化推荐、动态定价、营销自动化、预测性分析、忠诚度管理和社交网络洞察等方面,通过实际案例展示了大数据如何帮助商家洞悉消费者行为,优化决策,实现精准营销。同时,文章也讨论了大数据面临的挑战和未来展望。
|
2月前
|
SQL 消息中间件 分布式计算
大数据-143 - ClickHouse 集群 SQL 超详细实践记录!(一)
大数据-143 - ClickHouse 集群 SQL 超详细实践记录!(一)
88 0
|
2月前
|
SQL 大数据
大数据-143 - ClickHouse 集群 SQL 超详细实践记录!(二)
大数据-143 - ClickHouse 集群 SQL 超详细实践记录!(二)
66 0
|
2月前
|
SQL 消息中间件 分布式计算
大数据-130 - Flink CEP 详解 - CEP开发流程 与 案例实践:恶意登录检测实现
大数据-130 - Flink CEP 详解 - CEP开发流程 与 案例实践:恶意登录检测实现
53 0
|
4月前
|
分布式计算 搜索推荐 物联网
大数据及AI典型场景实践问题之通过KafKa+OTS+MaxCompute完成物联网系统技术重构如何解决
大数据及AI典型场景实践问题之通过KafKa+OTS+MaxCompute完成物联网系统技术重构如何解决
|
4月前
|
人工智能 分布式计算 架构师
大数据及AI典型场景实践问题之基于MaxCompute构建Noxmobi全球化精准营销系统如何解决
大数据及AI典型场景实践问题之基于MaxCompute构建Noxmobi全球化精准营销系统如何解决
|
4月前
|
人工智能 分布式计算 大数据
大数据及AI典型场景实践问题之“开发者藏经阁计划”的定义如何解决
大数据及AI典型场景实践问题之“开发者藏经阁计划”的定义如何解决