无忧搬家数据以前很多都是数仓同学从业务库负责接入数据至ods层，然后就由各个下游分析师取ods贴源层数据然后进行取数计算分析，数仓这边缺乏沉淀公共层数据，从而有以下问题：
直接从ods贴源层取数据，业务研发侧一改造则下游链路级联影响改动很大
各数据分析下游从源头贴源层就直接各自依赖计算，数据链路十分零散不好管理
贴源层数据与业务侧保持一致，存在业务侧数据质量问题导致污染各数据下游风险
数据指标缺乏公共层沉淀，各下游数据分析重复计算资源浪费
基于以上的背景，为提高数据的易用性和复用性、减少数据冗余、提高数据产出效率，数仓开发这边协同调研并结合下游BI需求，搭建无忧搬家主题域公共层数仓模型，包含无忧搬家订单主题、无忧搬家小哥主题等等，现在无忧搬家主题域沉淀了数仓公共层以后，以上问题可以得到有效缓解，下游能依赖数仓公共层(dwb&dws) 的任务则直接优先依赖使用该层级表，这样可以做到：
尽可能地屏蔽业务侧改造对下游的直接影响，提升下游数据分析的稳定性
提效BI同学和运营同学的数据分析需求，提升数据的易用性和复用性、提高数据链路产出效率
公共层表沉淀了核心基础字段供下游使用，公共通用的基础指标和字段避免了下游重复计算
承担起数据质量保障环节，在关键核心表设计 大禹 数据治理平台监控规则告警及熔断机制
收敛了数据任务分散情况，优化数据链路，构建良好的血缘关系和数据架构
讲完上面的背景和解决方案，接下来就来分享下无忧搬家数仓建设的实际落地过程，数仓建设这个对于数仓开发工程师来说是必备的能力，比如当你面临着一个新业务的开启，就需要从0到1开始搭建数据仓库或者数据集市，这时候就要考虑数据如何组织和设计才能使下游数据分析团队提效以及增强数仓模型的健壮性。
数据仓库具有面向主题的特性，那么就会有主题的概念，同时，数仓建设是遵循纵向分层开发，横向划分主题域设计，遵循以下这个架构图，我们就可以以类似二维图清晰地定位出数据，这也从宏观上体现了数据资产中的数据组织。
数仓开发是承上对接业务研发侧&承下对接数据分析侧，在数仓建设前期要对上游业务过程和对下游数据分析指标体系有所了解和熟知，然后拉齐上下游沟通数据口径和梳理设计数仓表搭建。
无忧搬家的整体的业务流程
先是邀约部门针对获取到的已有线索，邀约感兴趣成为平台搬家小哥的成员，然后来到货拉拉各城市的培训点进行面试，然后注册认证并交保证金成为我们平台的一位搬家小哥，搬家小哥也会有角色，比如小哥队长和小哥队员等，成为搬家小哥后就可以开始接单和做单了，当然搬家小哥由于各种原因也可以从平台退保证金之后退出平台，这是搬家小哥的大致业务过程。对于用户而言，下无忧搬家单其实跟下货运单无过多差别，货运单跟无忧搬家单的区别就在于后者会提供搬运服务且参与对象多了搬家小哥这个主体。
数仓主题域：主题域通常是联系较为紧密的数据主题的集合，根据业务需求分析的视角进行划分抽象归类。
划分方法：主题域划分的方法一般有几种
要么按照业务过程来划分，一个业务过程抽象出一个主题域，比如业务系统中的商品、交易、物流等
要么按照业务部门来划分，一个业务部门抽象出一个主题域，比如中台部门、业务运营部门、供应链部门等
要么按照业务系统来划分，一个业务系统抽象出一个主题域，比如搬家系统、erp系统 等
无忧搬家业务的数仓建设项目，是一个面向搬家业务部门级的数据集市，因为其业务特性和定位，无忧搬家是公司业务中一个独立的业务线，所对应的业务系统和数据库也是跟其他系统独立开的，比如无忧搬家订单数据没有整合到货运交易订单中，以及搬家小哥这个角色在货运整体业务线中也不存在该实体，那么这时候采用上面第3点划分方法，在已有企业级数仓中，按照业务系统来划分，新增一个无忧搬家主题域，就不会在建设过程中出现一些‘扯皮’操作，出现数据边界归属问题。
小结：主题域的划分一般比较谨慎，一旦定下来了避免频繁变动，虽然数仓建设是迭代建设的，不能保证一次性初始化好，但我们的主题域划分和主题划分要尽可能地涵盖企业的所有业务，以及在新业务进来时能够无影响地被包含进来和可扩展主题域和主题，企业级数仓做主题划分和主题域划分，建议还是要站在全局的视角来看，然后先划分出主题域，再接着在主题域里面划分出各个主题，比如几个核心大域，货运交易订单域、货运用户域、货运司机域。
数仓主题：是在较高层次上将企业生产上的各个系统中某一分析对象的数据进行整合、归类并分析的一种范围，属于一个抽象概念，简单点说每一个主题对应一个宏观分析领域。
划分方法：说白了主要就是要识别出分析对象主体，比如上面的主题域划分完了后就产生一个搬家主题域，如果把搬家分析作为一个分析领域，那么‘搬家分析’所涉及到的主要分析对象就有用户、订单、搬运工 等，则数仓的主题就可以划分为订单主题、搬运工主题 等下游数据分析师关注度高的数据主题聚焦分析。
即业务过程和维度，组建成的矩阵。
输出总线矩阵
数仓分层的每一层建设都有其专属的职责和侧重点，数仓分层设计很重要，但如何分层以及命名其实没有固定的标准，各层之前的职责在各行业和公司也各有理解和应用，我建议是无需深究概念，不追究千篇一律都一致，但要知其各层主要职责划分和按公司内部约定好的规范应用遵守。
货拉拉的数仓分层设计
「ODS贴源数据层」：主要同步业务库数据与其保持一致，不做数据清洗动作
「DWD明细数据层」：存储各个单一业务过程的明细数据，采用表视图方式，对ODS层数据清洗数据清洗和数仓规范化，降低存储成本，并给上下游留下了改造兼容的缓冲层
「DWB基础宽表层」：此层主要采用宽表思路，用来做主题基础明细宽表，面向主题把不同业务过程的DWD明细表和视图关联起来做数据横向整合，结合下游数据指标分析做打标签化，沉淀指标复杂口径逻辑
「DWS轻度汇总层」：存放同主题业务下的通用汇总数据，这一层通常是抽象出一些通用指标和原子指标，会涉及复杂的数据逻辑计算而得出一些公共通用指标
无忧搬家主题域的模型表分层设计架构图
健壮性评估
当后续搬家主题域业务新增，还可以轻松地扩展出其他主题，毕竟按照上面的划分法，搬家的数据基本都划分在搬家主题域，剩下的就是搬家有新业务进来时扩展新主题或包含进已有主题。
模型表开发举例讲解
表名：无忧搬家订单费用基础宽表
设计：把dwd费用明细表，纵表打横成为横表(宽表) ，屏蔽各个type费用项对应的映射关系取值，统一由数仓来做解析，提升下游对费用明细数据的易用性。
做法：收敛粒度到order_id每笔订单，对应各自的费用项，并处理出一个各费用项的拼接标识去重数组，使得下游使用时可以区分出这笔订单到底是没有这个费用项还是这笔费用项本来值就为0。
优势：提升了数据易用性，收敛了数据量。
传统数据开发流程中，往往是大数据调度平台线上执行脚本代码后，大数据集群计算再写入数据表，我们只根据数据任务的执行状态(成功or失败)来判断数据任务是否成功产出，但数据质量却没有得到保障，比如数据任务执行成功但数据未写入，比如字段数据错位，比如不合理的数据空值插入等等各种数据质量问题，所以我们有必要增加一个环节-数据质量监控 ，辅助我们做到故障升级前及时感知，故障升级后快速定位。
监控规则设计思路 & 实践
以下思路最终形成的实现逻辑借助大数据内部自研数据治理平台-大禹 来配置监控规则及时感知业务数据以及熔断数据质量避免污染传递下游。
表数据量波动监控
监控数据量波动情况有助于我们识别出暴涨暴跌场景。
比如：全量表数据量一般只可能大于上一天数据量，跌了or等于都可能代表着数据异常了。
表字段枚举值值域监控
枚举值值域监控主要针对的是业务侧改动场景，改动频率不高但设计这类监控可以让我们及时感知到业务侧的数据变动调整。
比如：主订单表的order_status主订单状态枚举值 和 搬运订单表的order_status搬运订单状态枚举值，监控业务侧改动场景。
表核心指标异常监控
通过一些数据场景来监控数据是否异常。
比如：一般订单主表内每笔订单都会携带地理位置信息的addr_info字段json数组数据，通过对addr_info解析出来的地理位置信息数据设计null校值验，从而就能发现无忧搬家地理位置解析表的地理位置信息数据异常。
表多源join抽样监控
因为宽表层会有较多的join场景和字段很多，所以可以按每个join子查询抽样监控一两个关键指标。
自此无忧搬家主题域数据仓库建设目前已介绍完毕。无忧搬家主题域目前建设了无忧搬家订单主题&无忧搬家小哥主题，从依赖到 数仓 公共层(dwb&dws)下游链路来看：
目前就覆盖满足了下游数据分析团队的上千个数据分析任务，数据链路不再像以前各自分散不好管理，且 业务 改造也不会直接影响到 数据分析师 们的任务，由数仓公共层数据模型为其保障了数据质量，以更加良好的数据模型和数据架构赋能业务，助力货拉拉业务更好更快的向前发展。
当然，无忧搬家公共层模型现在还不算完善，这也不止无忧搬家业务线，货运业务线的其他主题域公共层模型也需要持续迭代升级，以及历史存量不规范和无效任务治理，数据质量监控设计还没完全覆盖，我们会在未来继续迭代，夯实数仓公共层模型，沉淀好数据资产。
