新兴数据仓库计划与实践手册：从分层架构到实际应用（二） ...

本手册将分为三部分发布，以帮助读者逐步深入理解数据仓库的计划与实践。

• 第一部分先容数据仓库的整体架构概述；
  
• 第二部分深入讨论ETL在数仓中的应用理论，ODS层的具体实现与应用；
  
• 第三部分将围绕DW数据仓库层、ADS层和数据仓库的整体趋势展开；
  

通过这样的结构，您可以系统地学习每一条理的内容和计划原则。

前情提要：《新兴数据仓库计划与实践手册：从分层架构到实际应用（一）》https://mp.weixin.qq.com/s/_iYSM0sT_NOysducbxEJhg
数仓分层下的ETL

在不同数据条理、以及源系统到数据仓库之间的ETL（Extraction、Transformation、Loading）是数据仓库建设的核心，负责将分散在不同源系统的异构数据抽取到暂时中间层，经过洗濯、转换、集成后加载至数据仓库或数据集市。

通常，ETL规则的计划和执行在数据仓库实施中占据了60%到80%的工作量。而随着数据量的增加和非结构化数据和实时处理需求的增加，ETL架构也逐步被镌汰演变为EtLT架构 参见文章：《ELT已死，EtLT才是当代数据处理架构的终点!》  以更好地顺应多样化的数据源和实时场景。
数据抽取（Extraction）

数据抽取负责将原始数据从各源系统中获取。传统的抽取方式包罗初始化加载与定期革新。初始化加载用于建立维表和毕竟表，将初始数据导入到数据仓库中；数据革新则负责在源数据变更时追加或更新数据仓库内容。常见的革新方式有定时使命和触发器。
在处理非结构化数据（如API接口数据、XML文件）和Binlog数据时，抽取步调会更加复杂。
比如，需要通过交互接口（如HTTP API、SaaS API）获取非结构化数据，并对数据库的变更日志（Binlog）进行解析（如Oracle CDC、AWS RDS CDC、MongoDB CDC）。
这些数据在抽取后，通常需转换为仓库兼容的内存格式，以便后续的处理和集成，比方，将多种源数据统一转为WhaleTunnel/SeaTunnel格式供处理引擎使用。
轻量级转化/数据洗濯（transform/Cleaning）

数据洗濯和轻量级转化是为消除原始数据中的二义性、重复性、不完整性或不符合业务规则的数据。
洗濯过程可以去除无效数据，确保数据的一致性和准确性。轻量级洗濯会数据格式化为数据仓库所需的标准格式。不同源系统的数据字段定名或数据格式每每不一致（如A表的字段名为id，而B表为ids），转换过程将统一这些定名和格式，构建一致的数据字典。
一般来说，这一步不会进行复杂的业务逻辑处理，以避免对后续升级和扩展带来依赖。对于复杂的业务逻辑，通常建议在数据仓库内通过SQL或存储过程处理，而不是依赖于外部洗濯工具。
这样可以提高系统的机动性，避免过多依赖特定工具带来的维护本钱。
比方，在WhaleTunnel/SeaTunnel当中利用界面/脚本进行轻量级别数据洗濯，增加字段、修改数据类型、修改字段名称、过滤不需要的数据等。
数据加载（Loading）

在加载阶段，经过洗濯和转换的数据会以批量加载（Bulkload）或直接写入的方式存入目标存储系统（如HDFS、Doris、Hive、Hudi、Iceberg、Greenplum等），为数据集市提供基础。
大多数公司会将加载使命整合到内部数据平台和调理平台中（如Apache DolphinScheduler或WhaleScheduler），并封装大数据集群（如Hadoop、Spark、SeaTunnel、Hive等）以提供统一的利用接口。
数据平台可以基于权限控制，为不同用户群体提供不同的利用权限，便于管理与维护。在Load的时候，也只管不使用JDBC模式，由于大量数据加载时候insert/update会形成系统瓶颈，比方，WhaleTunnel/SeaTunnel是全部内存转化成高速加载的，不会把中间数据存储在磁盘或数据库当中，同时在Load时候接纳高速数据API Bulk Load方式，效率数倍于JDBC模式。
通常，为了优化使命调理，大公司会将数据仓库划分为不同层级，设立分层，建立不同的工作量/项目进行管理，而不会全面用一个DAG 管理全部的使命。这样，日常的数千乃至上万条定时使命可以按不同数据仓库条理/业务部门和小组进行维护，通过权限、优先级或依赖关系分层执行，提升调理的管理效率和稳定性。
数据转换（Transformation）

前面讲大量数据通过实时和批量的方式进入数据仓库/数据湖当中，随着数据仓库性能的加强和SQL功能的扩展，目前已经不再流行使用ETL工具（比方Informatica、DataStage、Talend等）在数据仓库当再进行处理，而是直接利用SQL处理复杂的业务。
这样对于系统的移植、人员的管理、以及后续升级到DataOps流程支持敏捷开发都更加的方便。因此EtLT架构已经成为现在技术的主流架构。
目前的架构根本都在数据仓库的某些字段内容可能需要基于多个源字段的逻辑关系计算得出，可以誊写相应的SQL完成整体开发。当前，SQL、Python或Shell脚本是常用的转换工具，搭配调理工具（如DolphinScheduler或WhaleScheduler）可以高效管理数据转换使命流。
数仓分层的技术架构

数据中台的构建涉及多个方面，涵盖了大数据处理和管理的核心要素，在实际工作中通常包罗以下内容：
01 系统架构
以Hadoop和Spark等大数据组件为核心，构建高效的分布式架构，以支持数据的存储、计算和处理本事。
02 数据架构
通过顶层计划进行主题域划分，并接纳分层体系（如ODS-DW-ADS）来构造数据流向和结构条理，确保数据管理的机动性和顺应性。
03 数据建模
接纳维度建模方法，通过确定业务过程的粒度，构建合理的维度表和毕竟表，以便更高效地支持业务分析和查询需求。
04 数据管理
包罗对数据资产、元数据、数据质量、主数据和数据标准的全面管理，同时建立数据安全管理机制，确保数据的准确性、完整性和安全性。
05 辅助系统
包含使命调理、ETL处理以及监控等支撑系统，保障数据的高效处理和系统运行的稳定性。
06 数据服务
提供数据流派、数据查询、分析报表、可视化、呆板学习和数据发掘等服务，支持数据的多场景应用，以及数据交换、共享和下载功能。

数仓分层

在前面给大家粗略先容了数据仓库的分成概念，接下来给大家具体先容：数据仓库通常可以分为四个条理，但这一划分并不是固定的，不同公司可能会根据自身需求进行调整或重新定名。

ODS 贴源层

数据引入层（ODS，Operational Data Store），也称为数据基础层。这一层主要存放从源系统引入的原始数据，险些不做任何加工处理，目的是将基础数据直接同步到数据仓库中，便于后续的数据处理工作。

在结构上，ODS层的数据与源系统保持高度一致，是数据仓库的数据准备区。
在当代数据架构中，ODS层的数据获取方式逐步向CDC（Change Data Capture，变更数据捕捉）模式转变，尤其在数据湖和实时数据仓库的场景中。
新型的ETL工具已经可以支持源系统的DDL（数据定义语言）变更，这意味着当源系统的字段发生变革时，ODS层可以自动更新表结构，无需手动调整。
比方，WhaleTunnel这样的工具支持多种系统的DDL变更捕捉，包管了ODS层数据在数据仓库、数据湖或实时数据仓库中的一致性，不会由于源系统的改变而中断ETL流程。
ODS层的数据通常分为当前数据和汗青数据两部分：

• 当前数据表：用于存储近来需要处理的数据，保持最新的数据状态。
  
• 汗青数据表：保存已处理完的数据以备后续使用，一般保留3-6个月后整理，具体时间视项目需求而定。如果源系统的数据量较小，也可以选择更长时间的保存，乃至全量保存。
  

数据洗濯和规范化
只管ODS层主要作用在于数据引入，但并非完全不做处理。
此层通常会进行根本的数据洗濯，比方：

• 处理非常字段、规范化字段定名、统一时间格式
  
• 确保数据一致性，为后续数据处理和特征工程奠基基础
  

一些公司会选择在ODS层就进行初步的洗濯和过滤，而另一些则将更多的数据加工留在DWD层。
选择在哪里进行洗濯取决于企业的技术规范和需求。在实际开发中，大多数企业会在将数据存入ODS时进行根本处理，以淘汰后续工作量。
数据来源及存储策略计划

数据来源可按时间进行分区存储，通常以日为粒度，也有公司接纳年、月、日三级分区以优化存储效率。
数据在进入数据仓库进步行基础洗濯，如格式错误数据的剔除、关键信息缺失的过滤等，以包管数据质量。数据可分为实时和离线两种处理模式。
离线数据处理

离线数据通常通过定时使命（如每日批量使命）从业务系统或数据库中抽取。典型的日计算使命会在凌晨执行，通过SeaTunnel、DataX 或 WhaleTunnel从业务数据库提取数据，计算前一天的业务指标，并生成报表。
Hive、Spark常用于批量计算，计算结果存储于Hive、HBase、MySQL、Elasticsearch 或 Redis等系统中，供后续分析使用。
实时数据处理

实时数据源主要来自日志埋点数据或业务数据库，常用于实时推荐、用户画像等业务需求。
Spark Streaming 和 Flink负责实时计算，结果通常写入Elasticsearch、HBase 或 Redis。
实时数据源可利用WhaleTunnel监控MySQL的Binlog变革，将数据实时写入Kafka 或 HDFS。
数据来源

• 业务数据库：公司各业务系统生成的结构化数据。
  
• 日志数据：包罗用户举动日志和系统背景日志。埋点数据起首经由Nginx上报，再由Flume收集并存储在Kafka等消息队列中，随后由SeaTunnel或WhaleTunnel拉取至离线数据仓库（如HDFS）。
  
• 外部数据：包罗合作伙伴提供的数据或爬虫采集的数据，整合后用于补充业务分析。
  

数据存储策略（增量、全量、拉链）

在实际应用中，可根据需求选择增量、全量或拉链存储方式。
增量存储增量存储通常按天分区，以业务日期为分区字段，每日存储新增的业务数据。
比方，用户A在1月1日访问了店肆B，生成记载t1，并于1月2日访问店肆C，生成记载t2。增量存储会将t1存入1月1日的分区，将t2存入1月2日的分区。
如果用户A在1月1日购买商品B（生成t1记载）并在1月2日退货（更新t1记载），增量存储会将初始购买记载存于1月1日分区，退货更新后的记载则存于1月2日分区。

对于交易日志和举动日志等高频变更的数据表，增量存储能淘汰存储本钱和数据冗余。  下游分析需求一般只需聚合后的汇总数据，因此不需要恒久保存全量的汗青数据。

全量存储全量存储以日为分区，每个分区记载当天的完整业务数据快照。
比方，1月1日，卖家A发布了商品B和C，生成记载t1和t2。1月2日，卖家A下架商品B并上架商品D，此时商品B记载t1会更新，商品D生成新记载t3。
全量存储会在1月1日分区保存t1和t2，在1月2日分区保存更新后的t1、t2和t3。

• 对于数据量较小、变革缓慢的维度数据（如商品分类），全量存储能够包管数据完整性和易用性。
  
• 拉链存储拉链存储通过在表中增加开始时间（start_dt）和结束时间（end_dt）两个时间戳字段，记载每次数据变更，并以时间为分区字段。这种方式适用于记载全部变更数据的汗青快照，为分析数据演变过程提供支持。
  

目前WhaleTunnel已经支持了CDC、增量和全量数据抽取模式，也支持自定义插入规则，是用户使用的快速工具不错的选择！
结语

数据仓库的分层计划和模型方法为企业提供了强大的数据管理本事，不仅能够应对复杂的业务需求变革，还能在保障系统稳定性和数据质量的同时提升运营效率。
通过合理分层，数据仓库可以高效地存储、处理和分析数据，实现数据价值的最大化。
感谢您阅读本手册的每一部分，希望这些内容对您构建当代化数据仓库体系有所帮助。通过三部分的系统性讲解，相信您已经对数据仓库的四层架构及其应用有了更深的理解。请继续关注我们的更多技术分享，与我们一起探索数据驱动的将来。

本文由 白鲸开源 提供发布支持！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。