小米数据中台树立通常赋能业务增长！

首先引见下小米开售数仓，包括开展历程、开售数仓定义、数据失掉经常使用、开售数仓的内容和规模。

在 2019 年前，小米的中国区、国际部等业务数据团队在启动独立的数仓树立，这个期间是烟囱式的开发。随着业务飞速开展，在团体技术委 ABC（AI、Big>

小米的开售数仓全体上就是寄存整个公司开售数据的仓库，包括了订复数据、物流数据、门店数据、用户行为数据及商品数据，并依照维度建模和规范启动树立的高效数据汇合。

上图是开售数仓的场景图，数据关键来自于两个局部，一是在线业务数据，关键是订单系统、商品中心（小米的一切商品启动控制的中央）、门店系统（线下门店启动控制的中央）、售后系统和进销存系统。同时也有一些日志采集数据，经过开售数仓的处置，划分为不同的主题启动树立。开售数仓全体会启动元数据控制，目的是做到全域的元数据控制。最高层是数据运行层，包括团体数据看板、三区运营的看板、实时大屏、大促战报和数据开掘。

开售数仓数据的失掉关键经过以下三种方式：

数仓的经常使用方式有多种，包括传统的离线 Hive、数据湖 Iceberg、实时信息队列 Talos、OLAP 引擎、即时查问等。

开售数仓的目的是为公司提供准确好用的开售数据。在区域方面，蕴含世界的业务；在品类方面，蕴含手机、笔记本、大家电、生态链等；在渠道方面，蕴含小米网、商城、米家、三方平台等。咱们的日单量在千万级别，每天会处置上亿条日志数据。

在启动数仓树立时，首先是梳理业务，找到外围业务逻辑，对业务环节启动意识和了解，并在数据库中找到关系的数据表。在此基础上，站在更高维度对业务流和数据流启动汇总和分类，划分好主题域，便于后续的控制。而后启动理想表和维表的梳理，借助数据百科启动目的梳理，以详细的业务为外围，目的与维度等同关键。接上去对数仓启动建模，依照维度建模方式组织数据，在这个环节中须要留意分层和规范。最后就是物理成功，这个环节重点关注的是开发规范、交付物、品质等

接上去引见数仓分层方式。数仓分层最底层是 ODS 层，它是贴源数据，与业务数据坚持分歧。在 ODS 之上是 DW 层，DW 层可以细分为两层。一层是 DWD 基础数据，关键做荡涤和规范化，不对数仓团队外部放开经常使用。另一层是 DWM 层通用数据。基于 DWD 的数据做关联和聚合，会将外围的逻辑成功放在这一层，用于优化公共数据的复用性，可以放开给外部团队经常使用。数仓中还有 DIM 层（维度层），DM 层（宽表层），ADS 层（运行数据层），以及 TMP 层（寄存暂时表）

在数仓建模环节中，须要遵照以下一些基本的建模准则：高内聚低耦合，公共逻辑高层，老本与性能平衡、分歧性、数据可回滚。

1. 高内聚低耦合

将业务相近的数据设计为一个逻辑模型或许物理模型。例如订单有很多起源，包括小米商城、小米网、有品商城以及三方数据等。在 DW 层会整合为同一个订单表，同时会对一些缺失字段启动自动处置，保障一切起源的数据最终在 DW 层是一致的，从而成功高内聚。订单和物流被划定为不同的主题，以缩小其耦合度。

2. 公共逻辑下沉

前面引见数仓分层时，指出公共逻辑要尽量放在 DWM 层处置，对下游经常使用方尽量屏蔽复杂的业务逻辑，从而做到口径一致。例如在订单处置环节中，会有很多有效的订单，识别有效订单的外围逻辑在 DWM 层，这样下游业务方就可以间接经常使用。

3. 老本与性能平衡

必定的数据冗余，只管或许带来老本参与，但查问性能可以失掉提高。例如在区域维表设计中，针对国度、省份、市区、区县，经过一个区域层级字段将其分类，只管数据是冗余的，但用户经常使用起来会比拟繁难，并且查问更极速。

在数仓建模环节中，要保障字段含意和命名规范是一致的，这样可以降落了解和经常使用的老本。

要保障数据可回滚，在不同期间去口头数仓的调度，针对历史数据计算出的结果是分歧的。

那咱们是如何启动目的控制呢？在小米外部会经过 OSM 模型，依据公司的目的和战略，经过数仓中的度量值启动考核。

例如 2023 年的目的是手机出货量要到达 X 万台，关系战略是要设计好产品，提高用户购置；同时严控品质，缩小品质疑问带来的影响。基于目的和战略，在开售数仓中经过两个度量值来权衡，一是手机妥投数量，这个数值要尽或许高；二是手机售前进货数量，反应品质状况。

目的消费是基于 Hive 离线数据、MySQL 在线数据、剖析数据启动建模，树立语义模型，再启动查看认证，颁布到团体目的库，与数据百科启动联动。在目的消费侧，用户可以经过数据百科启动查问目的口径概略、抢先血统、维度等，数据百科与公司的 OA 工具启动联通，提高目的易用性和经常使用效率。

小米的开售数仓驳回的是 Lambda 架构。 开售数据是团体数仓中的外围之一，外部关注度高。假设是流处置，局部状况下不可到达百分之百的准确性，因此须要经过批处置，去保障 T+1 数据的准确性。在批处置层经常使用 Spark 加 Hive 去处置离线数据。在流式处置层，经常使用 Flink 加信息队列 Talos。在 DW 和 DM 层，会经过 Hologres 启动维表的减速查问。最终再把这两局部数据启动联结，提供应下游业务方经常使用。

咱们在处置开售实时数据中，会遇到各样的疑问，这里引见下实时数据流形态过时疑问的处置方法。在实时数据中，开售订单关键分两局部。第一局部是订单理想表，第二局部是订单明细理想表。订单中一切的形态变卦都体如今订单理想表，而订单明细数据在第一次性创立之后，就不会再出现变动。大家都知道，实时计算信息队列的保留期间是有限度的，通常会设置一个期间周期。Flink 也有计算形态的保留期间，在必定期间周期后计算形态会过时，须要留意的是，由于订单明细不再变动，假设一些订单主表的两次形态变动期间大于形态过时期间，这时刻开售关系目的是失准的。

通常中是经过引入一个离线流，在订单和订单明细上各自去识别这局部过时数据，经过一个离线数据的信息队列，与原始的实时数据流启动兼并，去重后下发到下游启动处置，大幅度提高同类场景下数据准确性。

然而这样会引发另外一个疑问，即批处置思想方式带来的物流目的意外。

以物流场景为例，一些国际业务在商品出货后，由于距离较远或许报关审批等流程，会造成局部货物或许三个月后才出现一个形态变卦。物流主表记载物流形态的变卦，物流明细表以及离线的补充物流明细表会启动兼并操作，之后对这两局部启动去重，去重后的结果再与物流主表启动关联，而后下发启动其余的处置逻辑。这是一个典型的离线处置思想。上述处置方法疏忽了一个关键的环节，即 Flink 中算子 state 的保留机制。

在补离线流的时刻，由于补充离线义务自身也须要调度期间，造成数据或许不可及时精准的补出来，为了准确的补充离线数据，会多补充一局部数据。在 RANK 算子下发时，多补的这一局部数据，会造成实时流中的明细数据不过时，即离线数据流跟实时数据流启动兼并和排序操作会使实时数据中的原始流过时期间进一步延伸，不会下发对应的明细数据到 join 算子。实践处置是经过应用 Flink 中的处置期间，依照物理明细表的业务联结主键下发最后一条数据，关键的处置思绪就是深化了解实时计算环节，防止受离线开发思想影响。

接上去引见一下基于 Iceberg 的存储批流一体打算。

关键是将离线处置中的 Hive 和实时处置中的 Talos 所有换成 Iceberg 去处置。选用 Iceberg 的要素是其对结构化和非结构化数据都有很好的支持。小米有一些非结构化的三方数据以及一些跟谷歌协作的 BQ 埋点日志，这些数据比拟复杂，把这些数据存储在 Iceberg 中会比拟繁难。Iceberg 支持事务写，在其变卦环节中，不影响下游业务读取数据，这方面 Hive 是做不到的。另外小米计算平台团队经过 merge into 语法，成功了对 Iceberg 数据的高效修正，使得离线和实时可以高效地相互融合。

但这个打算也存在无余之处，由于 Iceberg 的事务提交依赖 Commit，然而在实时写入中每次 Commit 的速度会依赖 Checkpoint 设置的时长，所以不可做到秒级别的实时。

上方引见开售数仓才干层，即数仓经过必定的树立和更新，逐渐积淀上去的一些公共才干。

首先是一致的数据架构。准实时数据需求是基于 Iceberg 的分钟级流批一体处置打算；在实时方面，是基于 Flink + Talos 的秒级处置打算及离线批处置打算。

数仓规范在数仓才干层中无足轻重。日常上班中十分注重详细的开发环节和规范，尤其是对一些新同窗，规范是必要且适用的。经过数仓开发和品质规范，会一致表命名方式、字段命名方式、数仓分层等，性能 DQC 关系的完整性校验、分歧性校验、空值率校验。

数据安保是数仓才干树立的一个关键方面。一是经过合规管控，一切的数据消费环节都严厉遵守国度的法律法规。在公司外部有品质部、隐衷委以及法务部会对一切环节启动监控。二是会启动安保分类，即依照数据的敏感度和关键性将数据启动分类。三是在权限控制方面，会严厉规范数据流程，在每个部门都会有对应的安保担任人来担任最终的安保校验。在审批环节中，会遵照权限最小的准则。外围研发人员和经常使用人员，签订数据隐秘协定。四是集群隔离，小米是一个国际化公司。在国外会将机房部署在外地，并且机房之间的数据明细是不准许传输的。对一些汇总的目的，经过安保担任人的审批之后，可以传回国际启动剖析。在欧洲的数据业务，会严厉遵守欧盟的 GDPR 条例。针对海外数据，会成立国际数据运营中心，本地开发部署和运维。

数仓才干树立的一个关键环节就是目的运行。详细的目的运行是数据百科，如下图右侧所示，数据百科中蕴含所有数据口径的形容、基础信息、维度的拆解和关系目的。在目的口径上会严厉指定权限审批的担任人，明白整个目的的概略。下游可以经过数据百科，极速了解关系目的。局部目的会和团体数据看板启动联动，提供应团体的控制者经常使用。

最后启动一下总结和展望。

经过几年的树立和运行，咱们曾经基本建成了离线开售数仓，公司的运营和控制层都在深度且宽泛的经常使用开售数仓数据。团队外部积淀了数据架构和数仓才干规范，会始终与业界启动交流学习，探求最佳通常案例。

开售数仓未来的两个趋向，一是数据的价值化，二是目的的实时化。由于目前公司处于极速开展的环节中，数据部门和业务须要更严密地结合，充沛开掘数据的价值，真正将数据的价值表现出来，去赋能业务，为公司带来业绩的增长。目前实时化是一个大的趋向，数据以及业务的变动，都须要及时表现出来，做到高实时性。

Q1：支付订单成功订单之后，或许会出现周期性退款的疑问，反常的 DWD 模型或 DWS 模型通常会存在多分区表，针对这种相似于多形态始终更新的表，例如有一段退款之后就会出现历史回溯修正 DWS 模型，小米是如何处置的？

A1：咱们是经过离线的方式去对数据准确性启动修正。在离线外面会跑全量数据，即每次跑的时刻是从 ODS 层采集到 DW 层的处置，以及 DM 层，每个分区外面都是全量数据。这一块计算会比拟重，用来处置形态经常变动的疑问。

Q2：数据权限普通存储在哪一层？

A2：咱们会有一个平台部门去担任全体的数据权限，咱们在每一层，从ODS到DWD、DWM都会有权限管控。

Q3：物流这块引入 Kudu 或许 Doris 可以吗？

A3：目前在部门外部 Kudu 是将要被交流的形态。由于 Kudu 是一个相对小众的产品，运维老本会比拟高。咱们正在用阿里的 Hologres 去代替 OLAP 引擎，包括Kudu 和 Doris。

目前在咱们的离线和实时数据消费中，会经常使用Doris去减速结果表，咱们会把一些两边结果或许最终的汇总数据存到 Doris 外面(关键是汇总数据)，之后应用 Doris 的 OLAP 才干去对查问启动减速。

Q4：DWM 是跨域的宽表吗？DWD 和 DWM 究竟哪个是明细层？

A4：咱们将 DWD 和 DWM 统称为 DW，都是明细层。DWD 关键是启动规范化，把或许不同的异构数据一致到 DWD 来。在这个环节中除了 ETL、布局化、规范化之外，不会启动特意复杂的操作。在 DWM 层咱们会加工一些公共的复杂的逻辑。DWM 层也是明细数据，是把多个 DWD 表做关联，生成的明细宽表。

Q5：DM 层以下的分层会提供应用户访问吗？

A5：咱们的 ODS、DWD 以及 TMP 层是不提供外部访问的，其它层基本都可以对外部提供读权限。DW 层例如 DWM 是可以提供应外部访问的。由于 DWM 曾经启动了逻辑的封装，用户经常使用 DWM 经过繁难的计算就能失掉咱们在 DM 中最终得出的目的。

Q6：维度目的是独自分开存储的吗？

A6：不是，咱们是存在一块的。