三、小米整体架构模型演进
1、小米整体架构 – 离线架构1.0
离线架构的目标是设计出一个能满足离线数据分析的大数据架构，参考下图离线架构流程：
首先业务数据（比如订单、店铺数据）或者埋点（手机 app 后台）数据从通过canal 或 flume采集（或使用 lua 脚本）到数据，通过负载均衡均匀分发到kafka服务器上；
每天定点跑 spark 微批次任务获取数据并进行复杂业务处理最终落地到 Hive 离线数据仓库分为四层（ODS层， DWD层，DWS层，APP层）进行复杂的业务分析，或者 HBase 数据库进行明细数据的查询操作；
Hive 离线数据仓库进行复杂的业务处理之后将数据保存到关系型数据库中，比如MySQL中，提供对外查询访问 的接口；
最终将指标或者报表通过查询接口绑定前端界面或者 echarts 进行数据可视化。
2、Lambda 混合架构v2.0
Lambda 流批混合架构
Lambda 架构的目标是设计出一个能满足实时大数据系统关键特性的架构，包括有：高容错、低延时和可扩展等 。Lambda架构整合离线计算和实时计算，融合不可变性（ Immunability ），读写分离和复杂性隔离等一系列架构原则 。
Lambda 架构主要思想是将大数据系统架构分为多个层次，分别为批处理层，实时处理层，服务层等。
一般分为 BatchLayer 和 SpeedLayer，BatchLayer处理的是离线的全量数据，SpeedLayer处理是实时的增量 数据，BatchLayer 根据全体离线数据得到BatchView，BatchLayer处理的是全体数据集，SpeedLayer处理的数据是最近的增量数据流，SpeedLayer是增量而非重新计算，从而 SpeedLayer 是 BatchLayer 在实时性上的一个补充。
Lambda 架构的 servingLayer 用于相应用户的查询请求，合并生成的 BatchLayer和SpeedLayer的数据集到最终的数据集。
Lambda 架构的批处理部分存储一般使用 Hadoop 的 HDFS， 计算使用MapReduce离线计算；Hbase用于查询大 量的历史结果数据； 流处理部分采用增量数据处理 Structure Streaming 或 Flink Streaming 处理，存储增量 的结果一般会放到消息队列 kafka 中，内存数据库 redis 或者 分布式Mpp 数据库 clickhouse doris等。
Lambda 架构能够保障离线计算的准确性，但是对于运维来说增大了工作量，需要维护两套流程和批处理和流 处理计算框架。
3、小米架构 – lambda 架构v2.0
小米大数据平台 lambda 架构v2.0
小米 lambda 架构流程如下图所示:
数据采集
小米公司业务复杂，业务场景包括：广告、搜索推荐、用户画像、金融、信息流，OneData等场景；业务规模包括 1000+运行作业，20000+的CPU Core数，81+TB的内存数；业务数据（比如订单、店铺数据）或者埋点（手机 app 后台）数据从通过canal 或 flume采集（或使用 lua 脚本）到数据，通过负载均衡均匀分发到kafka服务器上；
数据分析和计算层
接着进行数据业务处理时，两条主线：
一条进行离线分析，spark从kafka中消费业务数据，基于业务口径进行数据的计算聚合并将数据落地到 HDFS 分布 式文件系统中，明细数据保存到 HBase中，用于即席查询；
对于传感器等物联网日志数据也会保存到 Crate.IO 分布式数据库中；
另外一条主线是 storm 实时分析 kafka 中的业务数据进行流计算，根据业务需求进行分析计算最终将结果保存到 HBase中；
同时对于时序有强相关性的数据单调递增的数据，比如根据订单时间、入库时间、采购时间、财务入账时间等业务 数据可以直接加载 kafka集群中的数据，实时聚合并将结果用于前端报表展现或者实时大屏看板的输出；
数据可视化平台
MPP数据库构建 OLAP服务的可视化平台，支持数据可视化，报表平台，如下图数鲸一站可视化平台中有某 汽车APP 用户城市占比分布饼图和热力图等展示。
4、小米架构 – kappa 流批一体架构v3.0
小米大数据平台 kappa 架构v3.0
数据采集
小米内部各个业务系统每一天都会生成大量的业务数据，这些数据中有些是实时的用于计算的，有的日志数据需要先保存到文件系统后续再进行分析和处理的，当然大多数还是以关系型数据会写入到MySQL数据库中，那么如何高 效的实现业务数据向大数据分析平台的数据抽取或同步，小米内部定制了 AgentSource。
此 AgentSource平台中重要的数据采集方式，主要支持6种接入方式，分别是文件传输、HTTP传输，TailDir传输，scribe传输，Thrift传输和OceanDir传输等。
从以上6种数据源采集数据到 Talos（类似于 kafka）消息队列，我们在这里使用 kafka 作为我们的消息队列 中间件。
数据存储层
在小米公司的整个大数据生态中，数据存储层涉及到方方面面的技术栈，使用 HDFS 离线分布式存储会保存维度 数据，主要存储历史数据，使用redis内存数据库主要存储热数据，Kudu主要存储历史数据用于数据仓库的计算分析 ,Hive数据仓库主要用于离线数据仓库的历史数据存储，HBase主要用于存储即席数据的数据和细粒度数据明细。
数据分析和计算层
计算层主要以 flink 流式计算框架对消息队列中的数据进行实时处理，实时部分会将数据保存到clickhouse数 据库或者 doris 数据库中，来保证数据的时效性；flink 还会将离线数据保存到 Hive 离线数据仓库中，计算，用 于与实时的数据的对数、补数等；除此之外部分业务也会基于 druid on kafka 对时间序列数据进行实时聚合操作落 地存储，为实时数据提供服务保障。
数据可视化平台层
当实时数据计算之后就需要对数据进行一站式可视化的展示，基于 echarts 和 BI 报表工具对数据进行实时展 现，当然也可能是 AB测试，为某些业务用户行为分析提供数据源等。小米的基于统一OLAP服务的可视化平台统称为 数鲸平台，提供一站式服务，BI工具、可视化、用户增长分析、移动应用统计、千亿级在线分析等可视化。
下图为小米公司架构数据流程逻辑图：
首先业务数据（比如订单、店铺数据）或者埋点（手机 app 后台）数据从通过 canal 或 flume采集（或使用 lua 脚本）到数据，通过负载均衡均匀分发到 kafka 服务器上；
DWD层：Flink 集群读取 kafka（小米自研的 talos 的消息队列）集群中的业务流数据，将明细数据打成大宽表 ，分别将数据保存到离线数据仓库 hive 中，实时的 clickhouse 数据库中，前者主要作为备份和数据质量保证（对 数、补数等），后者主要作为查询与分析的核心分析操作，维度数据保存在 redis 内存数据库中；
DWS层：数据汇总层，部分指标会通过Flink进行实时计算汇总至HBase中或Redis内存数据库中，提供对外接口供 大屏展现使用；其他的业务指标或者报表通过 clickhouse 物化视图等机制周期性汇总，最终生成折线图、柱状图、热力图等报表。同时明细数据也可以保存在 clickhouse 或 hbase 中，方便高级 BI 人员通过 zeppelin 等可视化工 具对订单、店铺、手机访问的日志的进行漏斗、留存、用户行为分析等灵活地 ad-hoc 查询，这个也是 clickhouse 远超于其他 OLAP引擎的强大的地方；
对于流数据还会将数据保存到 HBase 数据库中，phoenix on hbase 通过查询业务逻辑，对最终的结果数据进行落地保存；
同时保留了 druid on kafka，基于对时间序列强相关的数据进行实时的加载汇总处理；
最终使用 springcloud 提供最终的数据服务接口，结合echarts 或 fineReport报表平台工具用于展示最终的数据。
四、环境准备
1、软件清单
2、环境搭建
文章篇幅有限，此处略过，后续项目篇会详细每个软件的安装步骤
