点一下关注吧非常感谢持续更新----------------------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 对接* 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 或者类似的分布式队列系统保存数据你需要几天的数据量就保存几天* 当需要全量重新计算时重新启动一个流计算实例从头开始读取数据进行处理并输出到一个新的结果存储中。* 当新的实例做完之后停止老的流计算实例并把老的结果也删除。在数据仓库建模中未经过任何加工处理的原始业务层数据我们称之为ODSOpreational 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 做的。