点一下关注吧！！！非常感谢！！持续更新！！！
Java篇开始了！
- MyBatis 更新完毕
- 目前开始更新 Spring，一起深入浅出！
目前已经更新到了：
- Hadoop（已更完）
- HDFS（已更完）
- MapReduce（已更完）
- Hive（已更完）
- Flume（已更完）
- Sqoop（已更完）
- Zookeeper（已更完）
- HBase（已更完）
- Redis （已更完）
- Kafka（已更完）
- Spark（已更完）
- Flink（已更完）
- ClickHouse（已更完）
- Kudu（已更完）
- Druid（已更完）
- Kylin（已更完）
- Elasticsearch（已更完）
- DataX（已更完）
- Tez（已更完）
- 数据挖掘（已更完）
- Prometheus（已更完）
- Grafana（已更完）
- 离线数仓（已更完）
- 实时数仓（正在更新…）
章节内容
- 业务数据库表结构
- 交易订单、订单产品、产品分类、商家店铺、地域组织表
Canal 同步业务数据
环境准备
- Hadoop
- HBase
- Flink
- ClickHouse
- MySQL
- Canal
- Kafka
Canal 介绍
阿里巴巴 B2B 公司，由于业务的特性，卖家主要集中在国内，买家主要集中在国外，所以衍生出了杭州和美国异地机房的需求，从 2010 年开始，阿里系公司开始逐步的尝试基于数据库的日志解析，获取增量变更进行同步，由此衍生出了增量订阅、消费的业务。
Canal是用 Java 开发的基于数据库增量日志解析，提供增量数据订阅、消费的中间件。目前，Canal主要支持了 MySQL 的 Binlog 解析，解析完成后才利用 Canal Client 用来处理获得相关数据。（数据库同步需要案例的 otter 中间件，基于 Canal）。
Canal 的背景与初衷
在大规模互联网应用中，尤其是在像阿里巴巴这样的电商平台中，数据库的规模和复杂度通常非常高。为了提高数据的实时性和可用性，许多业务场景需要实时地同步数据库中的变化（如订单、用户数据等），并确保数据在多个系统之间一致。
Canal 的诞生，正是为了解决这一问题。通过 变更数据捕获（CDC） 技术，Canal 能够高效地监控并捕获数据库中的数据变动（如插入、更新、删除等操作），然后将这些变动实时同步到下游系统，如搜索引擎、数据仓库、缓存等。
Canal 的核心功能
变更数据捕获（CDC）
Canal 的核心功能是实现变更数据捕获，它通过 解析数据库日志（binlog） 的方式来获取数据库中的变化数据。Canal 支持 MySQL、PostgreSQL、Oracle 等数据库，并能够实时地捕获数据库的变化。
- 增量数据同步： 通过解析 binlog，Canal 能够识别出数据库的增量变化（插入、更新、删除等），并将这些变动同步到下游系统。
- 高效处理： Canal 对数据变更进行高效的捕获和同步，支持大规模的分布式部署，能够处理高并发、高吞吐量的场景。
数据同步
Canal 不仅可以捕获数据变动，还能将这些数据变动同步到其他系统。常见的应用场景包括：
- 同步到搜索引擎： 比如将 MySQL 中的数据变更实时同步到 Elasticsearch，以便提高检索的实时性。
- 同步到数据仓库： 实现 OLAP（联机分析处理）系统中的数据实时同步，比如将数据库变更同步到 Hadoop、ClickHouse 等大数据平台。
- 缓存同步： 数据库变动后，Canal 可以实时更新缓存（如 Redis），以确保缓存中的数据是最新的。
异构数据库支持
Canal 不仅支持 MySQL、PostgreSQL、Oracle 等传统关系型数据库，还支持通过扩展和插件的方式支持更多数据库的接入，适应不同数据库之间的同步需求。
数据解析与转换
Canal 允许对捕获到的数据进行解析和转换。用户可以基于 Canal 提供的 API，定制化处理从数据库中捕获的数据，比如数据格式的转换、过滤等。
Canal 的工作原理
Canal 的工作原理大致分为以下几个步骤：
- 连接数据库：Canal 会连接到源数据库，并获取该数据库的 binlog（对于 MySQL 来说是 binary log，其他数据库有类似机制）。binlog 记录了数据库的所有数据变动操作。
- 解析 binlog：Canal 会持续监听和解析数据库的 binlog 文件。每当有新的数据变动时，Canal 就会读取新的 binlog 并解析出具体的变更内容（插入、更新、删除等）。
- 数据处理：Canal 会将捕获到的变更数据通过数据解析处理，然后根据配置和需求将数据同步到下游系统（例如消息队列、缓存、搜索引擎、数据仓库等）。
- 持久化与监控：Canal 还提供了持久化机制，能够保存已经同步的数据状态，同时具备监控功能，能够及时检测到系统异常并进行告警处理。
Canal 的优势
- 实时性： Canal 可以非常快速地捕获到数据库中的变更，适用于需要实时数据同步的场景。
- 高吞吐量： 它可以处理大量的数据变更，适用于高并发、高吞吐量的场景。
- 灵活性： Canal 提供了丰富的扩展接口和插件支持，用户可以根据自己的需求进行定制化处理。
- 高可用性： Canal 支持分布式部署和高可用架构，可以在多节点之间实现负载均衡和故障切换，保证系统的稳定性。
Canal 的部署与使用
Canal 的部署和使用并不复杂，用户只需配置 Canal 与数据库的连接信息，并定义目标系统，Canal 就能开始实时捕获并同步数据。它支持 单机模式 和 集群模式，用户可以根据实际的吞吐量和可用性需求来选择不同的部署方式。
配置
用户需要配置以下内容：
- 数据库连接信息：包括数据库的 IP、端口、用户名、密码等。
- binlog 配置：指定要监听的 binlog 文件。
- 目标系统配置：配置将变更数据同步到哪个系统，例如 Kafka、Elasticsearch、Redis 等。
启动与监控
Canal 提供了简单的命令行工具来启动服务，并且可以通过 Web 界面或监控系统（如 Prometheus）对 Canal 的运行状态进行实时监控。
使用场景
原始场景
阿里 otter 中间件的一部分
- 数据同步： 实现不同数据库之间的数据同步，确保数据一致性。
- 实时数据仓库： 将源数据库的变更实时同步到数据仓库中，进行数据分析和报表展示。
- 实时搜索引擎更新： 将数据库的变更实时同步到搜索引擎中，提升搜索的实时性和准确性。
- 缓存更新： 在数据库发生变更时，及时更新缓存中的数据，避免缓存穿透和缓存不一致的问题。
更新缓存
拉链表
订单表，6 月 20 日有 3 条记录：
到 6 月 21 日，表中有 5 条记录：
到 6 月 22 日，表中有 6 条记录：
在数据仓库中设计历史拉链表保存该表
- dw_begin_date 表示该条记录的生命周期开始时间，dw_end_date 表示该条记录的生命周期结束时间
- dw_end_date = '9999-12-31’表示该条记录属于有效
- 如果查询有效记录则可以直接 where 9999-12-31
- 如果查询 2012-06-21 的历史快照，dw_begin_date <= ‘2012-06- 21’ and end_date >= ‘2012-06-21’
和原表在 6 月 21 日的记录完全一致，可以看出，这样的历史拉链表，技能满足历史数据的需求，又能很大程度的节省存储空间。
实时统计
抓去业务表的新增变化数据，用于实时统计。
