CC00011.bdpositions——|Hadoop&实时数仓.V11|——|项目.v11|ODS层处理|Kappa架构|-CSDN博客

一、Kappa架构

### --- Kappa架构

~~~     正如前面提到的，Lambda Architecture有其优点和缺点，人们也划分成支持者和反对者两派。
~~~     Kappa 架构是LinkedIn的Jay Kreps结合实际经验和个人体会，
~~~     针对Lambda架构进行深度剖析，分析其优缺点并采用的替代方案。
~~~     Lambda 架构的一个很明显的问题是需要维护两套分别跑在批处理和实时计算系统上面的代码，
~~~     而且这两套代码得产出一模一样的结果。
~~~     因此对于设计这类系统的人来讲，要面对的问题是：
~~~     为什么我们不能改进流计算系统让它能处理这些问题？
~~~     为什么不能让流系统来解决数据全量处理的问题？
~~~     流计算天然的分布式特性注定其扩展性比较好，
~~~     能否加大并发量来处理海量的历史数据？基于种种问题的考虑，Jay提出了Kappa这种替代方案。
~~~     Kappa架构 简化了Lambda架构。Kappa架构系统是删除了批处理系统的架构。
~~~     要取代批处理，数据只需通过流式传输系统快速提供：

二、Kappa架构说明

### --- 那如何用流计算系统对全量数据进行重新计算，步骤如下：

~~~     用Kafka或类似的分布式队列保存数据，需要几天数据量就保存几天。
~~~     当需要全量计算时，重新起一个流计算实例，
~~~     从头开始读取数据进行处理，并输出到一个结果存储中。
~~~     当新的实例完成后，停止老的流计算实例，并把老的结果删除。
~~~     和Lambda架构相比，在Kappa架构下，只有在有必要的时候才会对历史数据进行重复计算，
~~~     并且实时计算和批处理过程使用的是同一份代码。
~~~     或许有些人会质疑流式处理对于历史数据的高吞吐量会力不从心，
~~~     但是这可以通过控制新实例的并发数进行改善。

### --- Kappa架构的核心思想包括以下三点：

~~~     用Kafka或者类似的分布式队列系统保存数据，你需要几天的数据量就保存几天。
~~~     当需要全量重新计算时，重新起一个流计算实例，
~~~     从头开始读取数据进行处理，并输出到一个新的结果存储中。
~~~     当新的实例做完后，停止老的流计算实例，并把老的一些结果删除。

### --- 数仓建模说明

~~~     在数据仓库建模中，未经任何加工处理的原始业务层数据，
~~~     我们称之为ODS(Operational Data Store)数据。
~~~     在互联网企业中，常见的ODS数据有业务日志数据(Log)和业务DB数据(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做的。