数据仓库技术选型方案文档

关联博客：
数据仓库技术选型方案文档
Flink CDC MySQL数据同步到Doris表同步配置生成工具类
新版报表系统（明细报表、看板、数据大屏）方案&介绍

数据仓库技术选型

近期项目组在由我负责搭建数仓，做了一些预研，最后成功搭建，顺便把文档分享出来。

背景

现状

现状架构

三种查询方式，积木报表里SQL直连MySQL连表查询，积木报表走API链接报表服务内接口，XXLJob定时生产报表数据

目标架构

通常数仓的架构如下

关键词
ODS：贴源数据层；通过离线/实时方式同步集成到数仓中的业务数据；最贴近业务数据；减少对业务数据库影响
DWS：数据明细层；对ODS层数据做一定程度的清洗和汇总
DWM：中间数据层；对明细数据按照维度做初步汇总
DWS层：数据服务层，各个业务主题的宽表
DIM：维度层
ADS层：数据应用层；保存结果数据；最贴近应用层

业务反馈&痛点问题：

1. 报表系统“慢”：页面卡死，空白
2. 服务不可用：readonly库资源占用100%、report服务挂掉
3. 频繁需要开发人工接入：因为以上原因，不得不线下辅助导出（耗时、低效、频繁被打断）
4. 报表开发周期长，可维护性差

原因分析

1. 跨库、联表、多表查询；慢sql；复杂sql
2. 未区分业务数据、报表数据概念：实时查询业务数据源，缺少报表数据存储&计算的过程
3. 积木报表使用场景错误：仅适合数据应用层展示|小数据量场景
4. 实时性要求较高
5. OLTP和OLAP：数据分析环节缺失

技术选型

1. 方向概念分层：数据集成，数据存储，数据计算，数据展示/应用
2. 引入外部组件：如ETL工具，数仓工具
3. 区分离线数据&实时数据
4. 报表数据计算前置：准实时

数仓类型比较

离线数仓

离线数仓的主要特点是其处理的数据是离线的，‌即数据以T+1的形式计算好后放在那里，数据的处理和分析通常是在批处理模式下进行的。

实时数仓

在某些场景中，数据的价值随着时间的推移而逐渐减少。所以在传统大数据离线数仓的基础上，逐渐对数据的实时性提出了更高的要求。

于是随之诞生了大数据实时数仓，并且衍生出了两种技术架构Lambda和Kappa。

Lambda 架构

数据从底层的数据源开始，经过Kafka、Flume等数据组件进行收集，然后分成两条线进行计算：

• 一条线是进入流式计算平台（例如 Storm、Flink或者SparkStreaming），去计算实时的一些指标；
• 另一条线进入批量数据处理离线计算平台（例如Mapreduce、Hive，Spark SQL），去计算T+1的相关业务指标，这些指标需要隔日才能看见。

Kappa架构

Kafka的创始人Jay Kreps认为在很多场景下，维护一套Lambda架构的大数据处理平台时耗力，于是提出在某些场景下，没有必要维护一个批处理层，直接使用一个流处理层即可满足需求，即下图所示的Kappa架构：

相同点

• 数据集成

都需要从多个数据源提取、转换和加载数据（ETL/ELT）。
都需要处理数据清洗、去重和规范化，以保证数据的一致性和准确性。

• 数据建模

都需要进行数据建模，设计数据仓库的星型或雪花模型，定义事实表和维度表。
都需要进行数据架构设计，以优化数据存储和查询性能。

• 数据存储

都需要考虑数据存储的高效性和可扩展性，选择合适的存储方案和技术。
都需要对历史数据进行管理和归档，以保证数据仓库的长久有效性。

不同点

• 数据刷新频率

离线数据仓库：通常按批次定期（例如每天、每周）进行数据更新和加载，数据处理有一定的延迟。
实时数据仓库：数据实时或近实时地更新和加载，支持低延迟的数据处理和查询。

• 技术架构

离线数据仓库：通常依赖传统的批处理架构，使用ETL工具在固定时间窗口内处理数据。
实时数据仓库：需要支持流数据处理的架构，可能使用Kafka、Apache Flink、Apache Storm等技术，进行持续的数据流处理和实时分析。

• 性能要求

离线数据仓库：性能需求相对较低，因为数据处理可以安排在非高峰期，批处理任务可以在夜间执行。
实时数据仓库：需要较高的性能和低延迟，以支持实时数据的高效处理和快速响应。

• 数据一致性

离线数据仓库：数据一致性较容易保证，因为数据在批处理过程中可以进行全面的校验和验证。
实时数据仓库：保证数据一致性较为复杂，因为需要在数据流动过程中进行一致性检查和事务处理。

• 复杂度和成本

离线数据仓库：实施和维护相对简单，成本较低，但难以满足实时分析需求。
实时数据仓库：实施和维护复杂度较高，成本也更高，但能够提供实时数据分析的能力。

应用场景

• 离线数据仓库：适用于报告、历史数据分析和数据挖掘等不需要实时性的场景。
• 实时数据仓库：适用于实时监控、实时决策支持和事件驱动的分析场景，如金融交易监控、网络安全检测等。

数仓重要组件对比选型

ETL 数据提取、转换、加载工具

ETL：Extract-Transform-Load（ETL）是一种常见的数据集成过程，用于从一个或多个数据源中提取数据，对数据进行转换和清洗，然后加载到目标数据存储中。

Kettle

Kettle看起来老旧，在线体验地址：http://39.105.231.205:8857/kettle

Dophin Scheduler

功能介绍地址：https://dolphinscheduler.apache.org/zh-cn/docs/3.2.1/guide/homepage

Hive

hive是基于Hadoop的一个数据仓库工具，用来进行数据提取、转化、加载，这是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。hive数据仓库工具能将结构化的数据文件映射为一张数据库表，并提供SQL查询功能，能将SQL语句转变成MapReduce任务来执行。Hive的优点是学习成本低，可以通过类似SQL语句实现快速MapReduce统计，使MapReduce变得更加简单，而不必开发专门的MapReduce应用程序。hive十分适合对数据仓库进行统计分析。

注意点：我们会需要修改数据

优点

1. 操作接口采用类SQL语法，用户只要熟悉SQL语法即可快速转化(简单、学习成本低、容易上手)；

2. 避免书写MapReduce，减少开发人员的学习成本以及维护成本；

3. 对于大量数据，Hive能够进行分布式处理，从而节省了数据的处理时间；

4. Hive支持用户自定义函数，用户可以根据自己的需求来实现自己的函数，从而提高了灵活性，能够更好的应对复杂业务。

缺点

1. 基于HQL的方式导致表达能力有限：首先Hive中迭代式算法无法表达；其次Hive不擅长数据挖掘，由于MapReduce数据处理流程的限制，效率更高的算法却无法实现。

2. Hive的效率比较低：首先Hive的执行延迟比较高，因此Hive常用离线分析，适用于对实时性要求不高的场合；其次HQL自动编译生成MapReduce作业，通常情况下不够智能化；然后，由于MapReduce本身的特点，导致Hive对小文件的处理不占优势。

3. Hive调优比较困难，粒度较粗。

4. Hive对于数据更新操作支持性不好：一般用Hive处理的是离线的历史数据，因此默认情况下Hive是不支持对数据进行修改的。而如果需要对数据进行修改(update、delete)，那么需要改变Hive中数据文件的存储格式，且此时效率非常非常低。

华为云数仓

功能介绍地址：华为云数仓功能概览
实际实验后，其实就相当于只提供了个GaussDB,底层是个PostgreSQL,还是对PG魔改了很多，不完全支持PG协议了，通用性比较差，也没有预期的全套数仓的能力，就是个数据库罢了。

实时计算

Spark

Apache Spark是专为大规模数据处理而设计的快速通用的计算引擎

Spark生态圈以Spark Core为核心，从HDFS、Amazon S3和HBase等读取数据，以MESOS、YARN和自身携带的Standalone为资源管理器调度Job完成应用程序的计算。应用程序来自于不同的组件，如Spark Shell/Spark Submit的批处理、Spark Streaming实时处理应用、SparkSQL查询、MLlib机器学习、GraphX图处理等等。

Spark Core是Spark框架最核心的部分，实现了Spark的基本功能，包括任务调度、内存管理、错误恢复与存储系统交互模块。

1）提供了有向无环图（DAG）的分布式并行计算框架，并提供了Cache机制来支持多次迭代计算或者数据共享，大大减少了迭代计算之间读取数据的开销。

2）Spark中引入的RDD是分布在多个计算节点上的只读对象集合，这些集合是弹性的，如果数据集一部分丢失，则可根据“血统”进行重建，保证高容错性。

3）移动计算而非移动数据，RDD Partition可以就近读取分布式文件系统中的数据块到各个节点内存中进行计算

特点

1、运行速度快：支持在内存中对数据进行迭代计算

2、易用性好：支持Scala、Java、Python等语言的编写，语法简洁

3、通用性强：Spark生态圈包含丰富组件

4、随处运行：Spark具有很强的适应性，可以访问不同的数据源

Flink

flink是一个分布式，高性能，随时可用的以及准确的流处理计算框架，

flink可以对无界数据（流处理）和有界数据（批处理）进行有状态计算（flink天生支持状态计算）的分布式，高性能的计算框架。

特性

flink流处理和批处理

流处理：无界，实时性有要求，只需对经过程序的每条数据进行处理

批处理：有界，持久，需要对全部数据进行访问处理；

spark vs flink

spark：spark生态中是把所有的计算都当做批处理，spark streaming中流处理本质上也是批处理（micro batch）;

flink：flink中是把批处理（有界数据集的处理）看成是一个特殊的流处理场景；flink中所有计算都是流式计算；

Dinky（Flink管理平台）

为 Apache Flink 深度定制的新一代实时计算平台，提供敏捷的 Flink SQL, Flink Jar 作业开发、部署及监控能力，助力实时计算高效应用。

• 核心功能

1. 沉浸式 FlinkSQL 和 SQL 的数据开发平台：自动提示补全、语法高亮、语句美化、语法校验、调试执行、执行计划、MetaStore、血缘分析、版本对比等
2. 支持多版本的 FlinkSQL 作业各种提交方式：Local、Standalone、Yarn/Kubernetes Session、Yarn Per-Job、Yarn/Kubernetes Application
3. 支持 Apache Flink 所有原生及扩展的 Connector、UDF、CDC 等
4. 支持 FlinkSQL 语法增强：兼容 Apache Flink SQL、表值聚合函数、全局变量、执行环境、语句合并、整库同步、共享会话等
5. 支持易扩展的 SQL 作业：ClickHouse、Doris、Hive、Mysql、Oracle、Phoenix、PostgreSql、SqlServer 等
6. 支持 FlinkCDC（Source 合并）整库实时入仓入湖
7. 支持实时调试预览 Table 和 ChangeLog 数据及 Charts 图形展示
8. 支持 Flink 元数据、数据源元数据查询及管理
9. 支持实时任务运维：上线下线、作业信息、集群信息、作业快照、异常信息、数据地图、数据探查、历史版本、报警记录等
10. 支持作为多版本 FlinkSQL Server 以及 OpenApi 的能力
11. 支持易扩展的实时作业报警及报警组：钉钉、微信企业号、飞书、邮箱等
12. 支持完全托管的 SavePoint/CheckPoint 启动及触发机制：最近一次、最早一次、指定一次等
13. 支持多种资源管理：集群实例、集群配置、Jar、数据源、报警组、报警实例、文档、用户、系统配置等

• 核心优势

1. 多兼容：基于 Apache Flink 源码二次开发，兼容官方 1.11~1.15 版本源码，也兼容用户自己的分支改进版。支持官方及其他扩展的 SQL Connector，如 ChunJun。支持 FlinkCDC 官方的 CDC SQL Connector。
2. 无侵入：Spring Boot 轻应用快速部署，不需要在任何 Flink 集群修改源码或添加额外插件，无感知连接和监控 Flink 集群。如果要使用 Flink MetaStore、整库同步等功能，则需要在 Flink lib 中添加对应的依赖包。
3. 无依赖：只需要 Mysql 数据库与 JDK1.8 环境，不依赖任何其他中间件，如 zookeeper、hadoop 等。
4. 易用性：Flink 多种执行模式无感知切换，支持 Flink 多版本切换，自动托管实时任务、恢复点、报警等， 自定义各种配置，持久化管理的 Flink Catalog (即 Flink MetaStore)。
5. 增强式：兼容且增强官方 FlinkSQL 语法，如 SQL 表值聚合函数、全局变量、CDC 整库同步、执行环境、 语句合并、共享会话等。
6. 易扩展：源码采用 SPI 插件化及各种设计模式支持用户快速扩展新功能，如连接器、数据源、报警方式、 Flink Catalog、CDC 整库同步、自定义 FlinkSQL 语法等。
7. 沉浸式：提供专业的 DataStudio 功能，支持全屏开发、自动提示与补全、语法高亮、语句美化、语法校验、 调试预览结果、全局变量、MetaStore、字段级血缘分析、元数据查询、FlinkSQL 生成等功能。
8. 一站式：提供从 FlinkSQL 开发调试到上线下线的运维监控及 SQL 的查询执行能力，使数仓建设及数据治理 一体化。
9. 易二开：源码后端基于 Spring Boot 框架开发，前端基于 React (Ant Design Pro) 开发，及其易扩展的设计， 易于企业进行定制化功能开发或集成到已有的开源或自建数据平台

获取数据变化

还有个seatunnel，搞了几天都没部署好，有坑，还有版本兼容问题，github上issue也没找到答案，寄

Canal

阿里巴巴 MySQL binlog 增量订阅&消费组件

Cannal Github

基于日志增量订阅和消费的业务包括

• 数据库镜像
• 数据库实时备份
• 索引构建和实时维护(拆分异构索引、倒排索引等)
• 业务 cache 刷新
• 带业务逻辑的增量数据处理

当前的 canal 支持源端 MySQL 版本包括 5.1.x , 5.5.x , 5.6.x , 5.7.x , 8.0.x

Flink CDC

Flink CDC 是 Flink 的子项目，是 Flink 的一组原连接器，用于 CDC 从不同数据库接收/更改数据，Flink CDC 将 Debezium 集成为引擎，异步或数据更改，因此 Flink CDC 可以充分使用和发挥 Debezium 的能力，并且可以无缝对接 Flink 使用其 SQL API 和 DataStream API 的能力，最终写入各种数据源。

• 核心优势

1. 简化实时数据集成：无须额外部署 Debezium、Canal、Kafka 等组件，运维成本大幅降低，链路稳定性提升。
2. 支持丰富的数据源：目前支持 MongoDB、Mysql、OceanBase、Oracle、Postgres、SQLServer、TiDB 数据源的 CDC。
3. 支持全量、增量订阅及自动切换：能进行全量与增量自动切换，支持 Exactly-once 语义，支持无锁并发读取，支持从检查点、保存点恢复， 断点续传，保证数据的准确性。
4. 无缝对接 Flink：无缝对接 Flink 生态，利用 Flink 众多 Source 及 Sink 能力，可发挥 Flink 双流、流维关联等能力。
5. 支持 FlinkSQL：支持 FlinkSQL 定义 Flink CDC 任务，进一步降低使用门槛与运维成本。

Kafka

MQ中转可选，用于承接mysql binlog数据变化->后续处理数据的消费者

Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统。

存储数据库

HBase

https://github.com/apache/hbase

https://hbase.apache.org/

HBase 是一个 NoSQL 数据库，数据存在 HDFS 上。HDFS 是文件系统，而 HBase 是数据库。HBase 可以以低成本来存储海量的数据，并且支持高并发写和实时查询，还有一个特点就是：存储数据的结构非常灵活。

与其他存储系统对比：

• MySQL 是单机的，没法存储大数据量的数据。
• Redis 是缓存数据库，所有的读写都在内存中，速度快。但 Redis 不适合存大量的数据，因为内存太贵了。
• Elasticsearch 是一个分布式的搜索引擎，主要用于检索。理论上 Elasticsearch 也是可以存储海量的数据，但是如果没有经常「检索」的需求，其实不必放到 Elasticsearch，数据写入 Elasticsearch 需要分词，会浪费资源。

HBase 里边也有表、行和列的概念。一行数据由一个行键和一个或多个相关的列以及它的值所组成。在 HBase 里边，定位一行数据会有一个唯一的值，这个叫做行键（RowKey），HBase 的列都得归属到列族（Column Family，列的属性类别）中。

我们再放点具体的值去看看，就更加容易看懂了：

ClickHouse

https://github.com/ClickHouse/ClickHouse

https://clickhouse.com/

ClickHouse是一款高性能、MPP架构、列式存储、具有完备DBMS功能的OLAP数据库。

ClickHouse可以在存储数据超过20万亿行的情况下，做到了90%的查询能够在1秒内返回。它基本能够满足各种数据分析类的场景，并且随着数据体量的增大，它与Spark、Impala、Kylin对比，优势也会变得越为明显。

ClickHouse适用于商业智能领域（BI），也能够被广泛应用于广告流量、Web、App流量、电信、金融、电子商务、信息安全、网络游戏、物联网等众多其他领域。应该说它适合的场景，就是OLAP。

ClickHouse不是万能的。它对于OLTP事务性操作的场景支持有限，它有以下几点不足。

• 不支持事务。
• 不擅长根据主键按行粒度进行查询（虽然支持），故不应该把ClickHouse当作Key-Value数据库使用。
• 不擅长按行删除数据（虽然支持）。

TiDB

https://cn.pingcap.com/

TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

与传统的单机数据库相比，TiDB 具有以下优势：

• 纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容
• 支持 SQL，对外暴露 MySQL 的网络协议，并兼容大多数 MySQL 的语法，在大多数场景下可以直接替换 MySQL
• 默认支持高可用，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明
• 支持 ACID 事务，对于一些有强一致需求的场景友好，例如：银行转账
• 具有丰富的工具链生态，覆盖数据迁移、同步、备份等多种场景

Doris

支持大部分MySQL语法，很不错，这个项目原本是百度内部使用的palo，贡献给阿帕奇基金会了

https://github.com/apache/doris

https://doris.apache.org/

Apache Doris 是一个基于 MPP 架构的高性能、实时的分析型数据库，以极速易用的特点被人们所熟知，仅需亚秒级响应时间即可返回海量数据下的查询结果，不仅可以支持高并发的点查询场景，也能支持高吞吐的复杂分析场景。

使用接口

Apache Doris 采用 MySQL 协议，高度兼容 MySQL 语法，支持标准 SQL，用户可以通过各类客户端工具来访问 Apache Doris，并支持与 BI 工具的无缝对接。Apache Doris 当前支持多种主流的 BI 产品，包括不限于 Smartbi、DataEase、FineBI、Tableau、Power BI、Apache Superset 等，只要支持 MySQL 协议的 BI 工具，Apache Doris 就可以作为数据源提供查询支持。

存储引擎

在存储引擎方面，Apache Doris 采用列式存储，按列进行数据的编码压缩和读取，能够实现极高的压缩比，同时减少大量非相关数据的扫描，从而更加有效利用 IO 和 CPU 资源。

Apache Doris 也支持比较丰富的索引结构，来减少数据的扫描：

• Sorted Compound Key Index，可以最多指定三个列组成复合排序键，通过该索引，能够有效进行数据裁剪，从而能够更好支持高并发的报表场景
• Min/Max Index：有效过滤数值类型的等值和范围查询
• BloomFilter Index：对高基数列的等值过滤裁剪非常有效
• Inverted Index：能够对任意字段实现快速检索

数据展示平台

积木

只支持sql、api作为数据源，原本是开源项目，做着做着做起来了闭源了~还把代码重命名成abcd之类的混淆了让你看不懂

飞致云DataEase

Github：https://github.com/dataease/dataease/

功能齐全，但是开源版本限制了数据集不能超过10W条，否则不可用，买企业版就没事，账户权限控制等功能是企业版的能力，价格适中，企业版最低档大概每月八百块钱，我们目前采购了这个产品。

最终方案

最后我们经过研究决定分两期进行，因为迫切需要改善目前大量数据下走原始连表查MySQL无法查询问题

一期：引入Doris2.1（数仓数据库）、Flink1.18、Flink CDC3.1.1（全量+增量数据同步）、DataEase（BI工具，展示数据）

二期：再引入ETL ，对一些维度建宽表供报表等查询使用,

一期改造后报表实时查询1秒内出结果，导出报表明细数据百万级（连表8张）基本在秒级完成，目前一期方案已实现，已经满足现状需要。

flink cdc安装过程中有坑，是依赖库问题，需要从github该项目拷贝下来下载需要的依赖再放进flink cdc的lib目录去。