TL;DR
- 场景：大数据实时数仓架构设计、数据湖与数据仓库选型、MySQL到Hive数据同步挑战
- 结论：Kappa架构通过批流合一降低运维成本，Flink替代Spark成为实时计算首选，binlog采集是MySQL数据实时同步的关键技术
- 产出：掌握Lambda/Kappa架构差异，理解数据湖与数据仓库适用场景，了解binlog实时同步方案及其优势
版本矩阵
| 功能 | 状态 | 说明 |
|---|---|---|
| Lambda架构 | ✅ 已验证 | 批处理层+速度层分离，需维护两套代码 |
| Kappa架构 | ✅ 已验证 | 批流合一，Flink流计算统一处理 |
| Flink流计算 | ✅ 已验证 | 批流合一特性，活跃开源社区 |
| Apache Druid存储 | ✅ 已验证 | 高查询效率，适合实时明细层 |
| binlog数据同步 | ✅ 已验证 | 解决MySQL压力与数据延迟问题 |
| Kafka消息队列 | ✅ 已验证 | 数据湖与实时处理共用链路 |
思想铺垫
大数据数据仓库的架构：
- 离线大数据架构：HDFS 存储、Hive、MR、Spark 进行离线计算的传统大数据架构
- Lambda 架构：在离线大数据的架构的基础上增加新链路用于实时数据处理，需要维护离线处理和实时处理两套代码
- Kappa 架构：批流合一，离线处理和实时处理整合成一套代码，运维成本小，这就是 Flink 火的原因，Kappa 架构已经称为数据仓库架构的新趋势
- 计算框架选型：Storm、Flink 等实时计算框架，强烈推荐 Flink，批流合一的特性及活跃的开源社区，有逐渐替代 Spark 的趋势
- 数据存储选型：首先考虑查询效率，其次是插入、更新等问题，可选择 Apache Druid，不过在数据更新上存在缺陷，选型时注意该问题频繁更新的数据建议不要采用该方案。当然存储技术这块需要具体问题具体分析，不同场景在的 HBase、Redis 都是可选项。
- 实时数仓分层：为了更好统一管理数据，实时数据仓可采用离线数仓的数据模型进行分层处理，可以分为实时明细写入 Druid 等查询效率高的存储方便的下游使用，轻度汇总对数据进行汇总分析后供下游使用
- 数据流转方案：实时数仓的数据源可以为 Kafka 消息队列，这样可以做到队列中的数据即可以写入数据湖或者数据仓库用于批量分析，也可以实时处理，下游可以写入数据集市供业务使用。
数据湖
那什么是数据湖呢？其实数据湖就是一个集中存储数据库，用于存储所有结构化和非结构化数据。数据湖可以用其原生格式存储任何类型的点点滴滴的数据，这是没有大小限制。数据湖的开发主要为了处理大数据量，擅长处理非结构化数据。 我们通常会将所有数据移动到数据湖中不进行转换。数据湖中每个数据元素都会分配一个唯一的标识符，并对其进行标记，以后可通过查询找到该元素。这样做技术能够方便我们更好的存储数据。
数据仓库
那么什么是数据仓库呢？数据仓库是位于多个数据库上的大容量存储库。它的作用是存储大量的结构化数据，并能进行频繁和可重复的分析。通常情况下，数据仓库用于汇集来自各种结构化源的数据以进行分析，通常用于商业分析的目的。（注意：一些数据仓库也可以处理非结构化数据，这个不是我们的重点）。
两者差异
那么数据湖和数据仓库之间的主要差异是什么呢？在存储方面上，数据湖中数据为非结构化的，所有数据都保持原始形式。存储所有数据，并且仅在分析时进行转换。数据仓库就是数据通常从事物系统中提取。 在将数据加载到数据仓库之前，会对数据进行清理与转换，在数据抓取数据湖就是捕获半结构化和非结构化数据。而数据仓库则是捕获结构化数据并将按模式组织。数据湖的目的就是数据湖非常适合深入分析的非结构化数据。数据科学家可能会用具体预测建模和统计分析等功能的高级分析工具。 通常是在存储数据之后定义架构，使用较少的初始工作并提供更大的灵活性。在数据仓库中存储数据之前定义架构，这需要你清理和规范化数据，这意味着架构的灵活性要低不少。
其实数据仓库和数据湖是我们都需要的地方，数据仓库非常适用于业务实践中常见的可重复报告。当我们执行不太直接的分析时，数据湖就很有作用。
Lambda架构
Nathan Marz 针对通用的，可扩展和容错的数据处理架构提出了术语 Lambda Architeture。它是一种皆在通过利用批处理和流处理这两者的优势来处理大量数据的数据处理架构。
图层
从宏观角度看，它的处理流程如下：
所有进入系统的数据都被分配到批处理层和速度层进行处理，批处理层管理主要数据集（一个不可变的，仅可扩展的原始数据集）并预先计算批处理视图。服务层对批处理视图进行索引，以便可以在低延迟的情况下进行点对点查询。速度层只处理最近的数据，任何传入的查询都必须通过合并来自批量视图和实时视图的结果来得到结果。
实现
有多种实现 Lambda 体系结构的方法，因为它对于每一个层的底层解决方案都是不可知的，每一层都需要底层实现特定的功能，这可能有助于做出更好的选择并避免过度的决定：
- 批处理层：一次写入，批量读取多次
- 服务层：随机读取，不随机写入，批量计算和批量写入
- 速度层：随机读取，随机写入，增量计算
Kappa 架构
正如前面提到的，Lambda Architecture 有其优点也有缺点，人们也划分为支持者和反对者两派。Kappa 架构是 LinkedIn 的 Jay Kreps 结合实际经验和个人体会，针对 Lambda 架构进行深剖析，分析其优点和缺点并采用的替代方案。 Lambda 架构的一个很明显的问题是需要维护两套分别跑在批处理和实时计算系统上面的代码，而且这两套代码得产出一模一样的结果。因此对于设计这类系统的人来讲，要面对的问题是：为什么我们不能改进流计算系统让它处理这些问题？为什么不能让流系统解决数据全量处理得问题？流计算天然得分布式特性注定其扩展比较好，能否加大并发量来处理海量的历史数据？ 基于这种考虑，Jay 提出了 Kappa 这种替代方案，Kappa 简化了 Lambda 架构，Kappa 架构系统是删除了批处理系统的架构，要取代批处理，数据只需要通过流式传输系统快速提供。
那如何流计算系统对全量数据进行重新计算，步骤如下：
- 用 Kafka 或类似的分布式队列保存数据，需要几天数据量就保存几天
- 当需要全量计算时，重新起一个流式计算实例，从头开始读取数据进行处理，并输出到一个结果存储中。
- 当新的实例完成后，停止老的流计算实例，并把老的结果删除。
和 Lambda 架构相比，在 Kappa 架构下，只有在有必要的时候才会对历史数据进行重复计算，并且实时计算和批处理过程使用的是同一份代码。或许有些人会质疑流式处理对于历史数据的高吞吐力会力不从心，但是这可以通过控制新实例的并发数进行改善。
Kappa 核心思想
Kappa 架构的核心思想包括以下三点：
- 用 Kafka 或者类似的分布式队列系统保存数据，你需要几天的数据量就保存几天
- 当需要全量重新计算时，重新启动一个流计算实例，从头开始读取数据进行处理，并输出到一个新的结果存储中。
- 当新的实例做完之后，停止老的流计算实例，并把老的结果也删除。
在数据仓库建模中，未经过任何加工处理的原始业务层数据，我们称之为：ODS（Opreational Data Source）数据。在互联网企业中，常见的 ODS 数据有业务日志数据（Log）和业务 DB 数据两类，对于业务 DB 数据来说，从 MySQL 等关系型数据库的业务数据进行采集，然后导入到 Hive 中，是进行数据仓库生产的重要环节。
如何准确、高效的把 MySQL 数据同步到 Hive 中
一般常用的解决方案是批量取并 Load 加载，直接连 MySQL 取查询表中的数据，然后存到本地作为中间存储，最后把文件 Load 到 Hive 表中。 这种方案虽然简单，但是随着业务的发展，问题也逐渐显露：
- 性能瓶颈：随着业务规模增长，Select From MySQL - Save To LocalFile - Load To Hive 这种数据花费的时间越来越长，无法满足下游数仓生产的时间要求
- 直接从 MySQL 中 Select 大量数据，对 MySQL 的影响非常大，容易造成慢查询，影响业务上的正常服务。
- 由于 Hive 本身的语法不支持更新、删除等 SQL 原语（高版本 Hive 支持，但是需要分桶+ORC存储格式），对于 MySQL 中发生 Update/Delete 的数据无法很好的进行支持。
为了彻底解决这些问题，我们逐步实时 binlog 采集进行实时处理，binlog 是 MySQL的二进制日志，记录了 MySQL 中发生的所有数据的变化，MySQL 集群自身的主从同步就是基于 binlog 做的。
错误速查卡
| 症状 | 根因 | 定位 | 修复 |
|---|---|---|---|
| Select From MySQL耗时长 | 业务规模增长导致数据量增大 | 查看MySQL慢查询日志 | 改用binlog采集方案 |
| MySQL从库延迟高 | 直接SELECT大量数据造成主库负载 | show slave status查看延迟 | binlog采集减少源库压力 |
| Hive无法支持Update/Delete | Hive本身语法限制（高版本需分桶+ORC） | 检查Hive版本和表存储格式 | 使用高版本Hive并配置分桶+ORC |
| 批处理与实时结果不一致 | Lambda架构维护两套代码逻辑差异 | 对比两套代码输出 | 迁移至Kappa架构统一代码 |
| 流计算处理历史数据延迟 | 单实例并发不足 | 监控Flink任务吞吐量 | 增加并发数或分片处理 |