「ETL实战」搭建数仓，解决多源业务系统关联分析难题（定制化业务）

在大数据分析盛行的今天，关联分析作为数据挖掘和业务洞察的重要手段，受到了极大关注。然而，随着数据量的激增和源业务系统的复杂性增加，关联分析的性能问题逐渐成为了一个不可忽视的挑战。

本文将介绍借助ETL工具，如何搭建一个高效的离线数仓，以优化关联分析性能，并减轻对多个源业务系统的压力。同时，还将通过一个实际应用案例来进一步说明这种方案的实用性和效果。

第一部分	离线数仓
	为什么要建离线数仓
	一般怎么搭建？
第二部分	实战案例：家居定制化	场景 挑战 实战方案 实施效果 场景价值

离线数仓

离线数仓是一个用于存储、管理和处理大量历史数据的系统。与传统的在线业务系统不同，离线数仓更注重数据的批处理、分析和挖掘，而不是实时的数据读写操作。通过搭建一个高效的离线数仓，我们可以将大量的历史数据集中存储、统一处理，从而大大提高关联分析的效率。

为什么要建离线数仓

现在大部分公司信息化水平都提升很多，有着多个源业务系统（如：ERP、MES、金蝶），多个源库（MySQL、SQL Server、Oracle、达梦、MongoDB 等等）。

企业在多个系统进行关联分析时，以数据分析直连多个业务系统进行分析的方式，中间涉及大量数据抽取（读数据）、数据转换，不仅影响分析性能，同时对业务库造成很大性能压力，严重甚至会引发业务系统宕机。

最后，报表性能差，数据调用耗时耗力，领导不能及时掌握业务数据动态，一线部门决策迟滞，可能的历史数据损失也将使企业积累的数据资产流失。

这时，IT部门肯定是压力最大的，所以在选择数据运维、架构方式上就需要

“深谋远虑”——建个离线数仓，让业务系统读写分离，分担压力。

离线数仓一般怎么搭建？

1、数据源梳理：需要明确数据源，包括各个业务系统的数据表、字段、数据格式等，为后续的数据抽取、转换和加载（ETL）过程做好准备。

2、数据抽取：利用ETL工具（FineDataLink\kettle等），从各个源业务系统中抽取所需的数据。在数据抽取中，需注意数据的完整性、准确性和一致性。

3、数据转换：对抽取出来的数据进行清洗、转换和整合，以符合离线数仓的存储格式和关联分析的需求。数据转换过程中可能涉及字段的映射、数据类型的转换、空值的处理等。

4、数据加载：将转换后的数据加载到离线数仓中。根据数据的特点和关联分析的需求，选择合适的存储引擎和表结构，如分布式数据库、列式存储等。

5、数据校验：在数据加载完成后，需进行数据校验。通过对比源数据和离线数仓中的数据，检查数据是否一致、是否存在缺失或错误等情况。

话不多说，我们上案例

场景

X家居集团自创立以来，始终秉承“创新家居，品质生活”理念，致力于为消费者提供一站式、高品质的家居生活解决方案。作为行业内的领军企业，强势引领全屋定制、橱柜家具、厨房电器等多领域的协同发展，形成了一站式的现代家居产业链。

1. 业务库种类多：业务库多达十几个，数据库类型多，Oracle、MySQL、SQL Server
2. 信息化程度高，系统多：信息化系统覆盖前、后端。有下单- 拆单调度-订单调度等系统（分发给各基地生产-生成采集系统-物流发货系统）
3. 数据量大：数据量级覆盖百万级、千万级、十亿级别，一天大概100W条。

• 挑战

随着[定制化业务]的发展，橱柜部门与研发中心对多源业务系统的数据关联分析需求日益增加。

（橱柜部门需制作橱柜材料看板，关联花色、颜色、材料等属性及客户信息与维度表，形成宽表以支持BI分析。研发中心则通过BI看板展示板件材料信息，评估淘汰新增及属性欢迎度。)

然而，直连多源业务系统进行关联分析存在以下问题：

1、BI看板直连业务数据，加载更新速度慢：由于直接连接业务库获取数据，数据量庞大（约20-30亿条），导致BI看板数据加载和更新时间长达7-8小时，甚至有时直到第二天早上数据仍未更新完成。

2、关联分析直连多系统，报表性能压力大：BI看板直接连接多个业务系统进行关联分析，不仅对分析性能产生负面影响，还对业务库造成巨大的性能压力，导致前端报表加载缓慢，重启更新代价高昂。

3、数据孤岛，打通成本高：关联分析所需的目标数据分散在多个业务系统（如订单系统、ERP等）中，存在数据孤岛问题。通过代码或人工导出数据的方式不仅时间人力成本高，而且难以维护。

实战

解决方案：搭建高效离线数仓

为了解决上述问题，IT部门经理决定采用一套基于FineDataLink（FDL）建设的高效离线数仓方案。该方案主要包括以下内容：

读写分离：采用数仓完成读写分离，将BI看板所需的高纬度汇总数据前置处理在数仓中完成，避免直接连接业务库。

数据同步：使用FDL进行批处理和流处理，从业务库获取数据并将其同步到数仓中。具体分层方式为：ODS层（原始数据层）- DW层（数据仓库层，包括DWD层-数据明细层和DWM层-数据汇总层）- ADS层（应用数据服务层）。

1、ODS层：制造中心将多个业务系统（如订单、物流和财务系统）数据进行实时同步，同时将业务数据做维度退化和清洗。

2、 DWD层： 制造中心 依据业务处理逻辑，对20-30张表做关联形成宽表。

后从DWD层中取数据，对不同维度做轻度汇总，汇总后数据量从20-30亿行降到8-9亿行。

3、DWM层：该层负责对数据进行更细致的汇总——橱柜部门匹配自定义的维度表，生成材料数量、面积等数据的BI看板。

4、ADS层：橱柜部门将制造中心的DWM层的板件信息，与客户定制化需求表进行匹配，汇总后数据量从8-9亿行降到约1亿行。

5、BI看板连接ADS层：最后，在BI里面根据不同的维度对轻度汇总表再做一层汇总，形成自助数据集

汇总后不同维度对应的数据集

数据降维：通过数仓的分层设计，对原始数据进行清洗、转换、整合和汇总等操作，将原始数据量从20-30亿行降至约1亿行，提高了数据分析的效率和准确性。

实施效果

通过搭建基于FDL的离线数仓并实施读写分离方案后，该家居集团取得了以下显著效果：

1、BI可视化报表的使用更稳定：由于数据量的大幅减少（从20-30亿行降至约1亿行）和数仓的高效处理，BI可视化报表的秒级呈现，使用更加稳定可靠。

2、数据的决策分析更有力：经过数仓处理和降维的数据质量更高，为橱柜部门和研发部门的决策分析提供了更加准确和有力的支持。

3、关联分析需求快速满足：数仓的读写分离和前置处理满足了橱柜部门和研发部门对关联分析的快速需求，为定制化业务的发展插上了腾飞的翅膀。

场景价值

解决多系统直连性能难题

基于FineDataLink（FDL），对接各个业务系统的数据，进行离线数仓的搭建。这种读写分离的操作，减轻了对业务系统的压力，同时提高了数据质量。

数出同源，及时准确

建立了统一的数据仓库，原始的20-30亿数据处理后，形成了约8亿数据，经过进一步汇总后，仅有约1亿数据用于BI展示。这不仅加快了BI看板（类似tableau）的展示速度，同时保证了数据一致性和准确性。

低代码、高可用、高可维护

通过整合多源异构数据，无需复杂代码或人工导出，降低了数据获取的成本和难度。同时，数仓的架构设计使得数据具有高可用性和高可维护性，为公司的业务发展提供了坚实的数据支持。

综上，借助ETL工具，搭建一个高效的离线数仓，以优化关联分析性能，能减轻对多个源业务系统的压力，预防宕机，提高报表、看板展示速度，帮助业务赋能。

希望本文的分享能帮到你~

文章推荐：

  扫盲系列（3）：数据仓库架构详解_cdm层-CSDN博客 

  扫盲系列（4）：数据仓库ETL流程和ETL工具推荐-CSDN博客

「ETL趋势」FDL数据中心库/表查看和调试功能上线、数据源新增支持MongoDB写入-CSDN博客

技术文档参考：FineDataLink文档