乐趣区

关于服务器:基于-Kafka-的实时数仓在搜索的实践应用

jiezi

一、概述

Apache Kafka 倒退至今，曾经是一个很成熟的音讯队列组件了，也是大数据生态圈中不可或缺的一员。Apache Kafka 社区十分的沉闷，通过社区成员一直的奉献代码和迭代我的项目，使得 Apache Kafka 性能越发丰盛、性能越发稳固，成为企业大数据技术架构解决方案中重要的一环。

Apache Kafka 作为一个热门音讯队列中间件，具备高效牢靠的音讯解决能力，且领有十分宽泛的应用领域。那么，明天就来聊一聊基于 Kafka 的实时数仓在搜寻的实际利用。

二、为什么须要 Kafka

在设计大数据技术架构之前，通常会做一些技术调研。咱们会去思考一下为什么须要 Kafka？怎么判断抉择的 Kafka 技术是否满足以后的技术要求？

2.1 晚期的数据架构

晚期的数据类型比较简单，业务架构也比较简单，就是将须要的数据存储下来。比方将游戏类的数据存储到数据库（MySQL、Oracle）。然而，随着业务的增量，存储的数据类型也随之减少了，而后咱们须要应用的大数据集群，利用数据仓库来将这些数据进行分类存储，如下图所示：

然而，数据仓库存储数据是有时延的，通常时延为 T +1。而当初的数据服务对象对时延要求均有很高的要求，例如物联网、微服务、挪动端 APP 等等，皆须要实时处理这些数据。

2.2 Kafka 的呈现

Kafka 的呈现，给日益增长的简单业务，提供了新的存储计划。将各种简单的业务数据对立存储到 Kafka 外面，而后在通过 Kafka 做数据分流。如下图所示：

这里，能够将视频、游戏、音乐等不同类型的数据对立存储到 Kafka 外面，而后在通过流解决对 Kafka 外面的数据做分流操作。例如，将数据存储到数据仓库、将计算的后果存储到 KV 做实时剖析等。

通常音讯零碎常见的有两种，它们别离是：

  • 音讯队列 ：队列消费者充当了工作组的角色，每条音讯记录只能传递给一个工作过程，从而无效的划分工作流程；
  • 生产 & 生产 ：消费者通常是相互独立的，每个消费者都能够取得每条音讯的正本。

这两种形式都是无效和实用的，通过音讯队列将工作内容离开，用于容错和扩大；生产和生产可能容许多租户，来使得零碎解耦。而 Apache Kafka 的长处之一在于它将音讯队列、生产和生产联合到了一个弱小的音讯零碎当中。

同时，Kafka 领有正确的音讯解决个性，次要体现在以下几个方面：

  • 可扩展性 ：当 Kafka 的性能（如存储、吞吐等）达到瓶颈时，能够通过程度扩大来晋升性能；
  • 实在存储 ：Kafka 的数据是实时落地在磁盘上的，不会因为集群重启或故障而失落数据；
  • 实时处理 ：可能集成支流的计算引擎（如 Flink、Spark 等），对数据进行实时处理；
  • 程序写入 ：磁盘程序 I/O 读写，跳过磁头“寻址”工夫，进步读写速度；
  • 内存映射 ：操作系统分页存储利用内存晋升 I/O 性能，实现文件到内存的映射，通过同步或者异步来管制 Flush；
  • 零拷贝 ：将磁盘文件的数据复制到“页面缓存”一次，而后将数据从“页面缓存”间接发送到网络；
  • 高效存储 ：Topic 和 Partition 拆为多个文件片段（Segment），定期清理有效文件。采纳稠密存储，距离若干字节建设一条索引，避免索引文件过大。

2.3 简略的利用场景

这里，咱们能够通过一个简略直观的利用场景，来理解 Kafka 的用处。

场景：如果用户 A 正在玩一款游戏，某一天用户 A 喜爱上了游戏外面的一款道具，打算购买，于是在当天 14:00 时充值了 10 元，在逛游戏商店时又喜爱上了另一款道具，于是在 14:30 时又充值了 30 元，接着在 15:00 时开始下单购买，破费了 20 元，残余金额为 20 元。那么，整个事件流，对应到库表外面的数据明细应该是如下图所示：

三、Kafka 解决了什么问题

晚期为响应我的项目疾速上线，在服务器或者云服务器上部署一个 WebServer，为个人电脑或者移动用户提供拜访体验，而后后盾在对接一个数据库，为 Web 利用提供数据长久化以及数据查问，流程如下图所示：

然而，随着用户的迅速增长，用户所有的拜访都间接通过 SQL 数据库使得它不堪重负，数据库的压力也越来越大，不得不加上缓存服务以升高 SQL 数据库的荷载。

同时，为了了解用户行为，又开始收集日志并保留到 Hadoop 这样的大数据集群上做离线解决，并且把日志放在全文检索零碎（比方 ElasticSearch）中以便疾速定位问题。因为须要给投资方看业务情况，也须要把数据汇总到数据仓库（比方 Hive）中以便提供交互式报表。此时的零碎架构曾经具备肯定的复杂性了，未来可能还会退出实时模块以及内部数据交互。

实质上，这是一个数据集成问题。没有任何一个零碎可能解决所有的事件，所以业务数据依据不同用处，寄存在不同的零碎，比方归档、剖析、搜寻、缓存等。数据冗余自身没有任何问题，然而不同零碎之间太过简单的数据同步却是一种挑战。如下图所示：

而 Kafka 能够让适合的数据以适合的模式呈现在适合的中央。Kafka 的做法是提供音讯队列，让生产者向队列的开端增加数据，让多个消费者从队列外面顺次读取数据而后自行处理。如果说之前连贯的复杂度是 O(N^2)，那么当初复杂度升高到了 O(N)，扩大起来也不便多了，流程如下图所示：

四、Kafka 的实际利用

4.1 为什么须要建设实时数仓

4.1.1 目标

通常状况下，在大数据场景中，存储海量数据建设数据仓库个别都是离线数仓（时延 T +1），通过定时工作每天拉取增量数据，而后创立各个业务不同维度的数据，对外提供 T+1 的数据服务。计算和数据的实时性均比拟差，业务人员无奈依据本人的即时性需要获取几分钟之前的实时数据。数据自身的价值随着工夫的流逝会逐渐削弱，因而数据产生后必须尽快的达到用户的手中，实时数仓的建设需要由此而来。

4.1.2 指标

为了适应业务高速迭代的特点，剖析用户行为，开掘用户价值，进步用户留存，在实时数据可用性、可扩展性、易用性、以及准确性等方面提供更好的反对，因而须要建设实时数仓。次要指标蕴含如下所示：

  • 对立收敛数据进口：对立数据口径，缩小数据重复性建设；
  • 升高数据保护老本：晋升数据准确性、及时性，优化数据应用体验和老本；
  • 缩小数据应用老本：进步数据复用率，防止实时数据反复生产。

4.2 如何构建实时数仓为搜寻提供数据

以后实时数仓比拟支流的架构一般来说蕴含三个大的模块，它们别离是音讯队列、计算引擎、以及存储。联合上述对 Kafka 的综合剖析，联合搜寻的业务场景，引入 Kafka 作为音讯队列，复用大数据平台（BDSP）的能力作为计算引擎和存储，具体架构如下图所示：

4.3 流解决引擎抉择

目前业界比拟通用的流解决引擎次要有两种，它们别离是 Flink 和 Spark，那么如何抉择流解决引擎呢？咱们能够比照以下特色来决定抉择哪一种流解决引擎？

Flink 作为一款开源的大数据流式计算引擎，它同时反对流批一体，引入 Flink 作为实时数仓建设的流引擎的次要起因如下：

  • 高吞吐、低延时；
  • 灵便的流窗口；
  • 轻量级容错机制；
  • 流批一体

4.4 建设实时数仓遇到的问题

在建设初期，用于实时处理的 Kafka 集群规模较小，单个 Topic 的数据容量十分大，不同的实时工作都会生产同一个大数据量的 Topic，这样会导致 Kafka 集群的 I/O 压力十分的大。

因而，在应用的过程中会发现 Kafka 的压力十分大，经常出现延时、I/ O 能性能告警。因而，咱们采取了将大数据量的单 Topic 进行实时散发来解决这种问题，基于 Flink 设计了如下图所示的数据散发流程。

上述流程，随着业务类型和数据量的减少，又会面临新的问题：

  • 数据量减少，随着生产工作的减少，Kafka 集群 I/O 负载大时会影响生产；
  • 不必业务之间 Topic 的生产没有落地存储（比方 HDFS、HBase 存储等），会产生反复生产的状况；
  • 数据耦合度过高，迁徙数据和工作难度大。

4.5 实时数仓计划进阶

目前，支流的实时数仓架构通常有 2 种，它们别离是 Lambda、Kappa。

4.5.1 Lambda

随着实时性需要的提出，为了疾速计算一些实时指标（比方，实时点击、曝光等），会在离线数仓大数据架构的根底上减少一个实时计算的链路，并对音讯队列实现数据起源的散失解决，通过生产音讯队列中的数据，用流计算引擎来实现指标的增量计算，并推送到上游的数据服务中去，由上游数据服务层实现离线和实时后果的汇总。具体流程如下：

4.5.2 Kappa

Kappa 架构只关怀流式计算，数据以流的形式写入到 Kafka，而后通过 Flink 这类实时计算引擎将计算结果寄存到数据服务层以供查问。能够看作是在 Lambda 架构的根底上简化了离线数仓的局部。具体流程如下：

在理论建设实时数仓的过程中，咱们联合这 2 种架构的思维来应用。实时数仓引入了相似于离线数仓的分层理念，次要是为了提供模型的复用率，同时也要思考易用性、一致性、以及计算的老本。

4.5.3 实时数仓分层

在进阶建设实时数仓时，分层架构的设计并不会像离线数仓那边简单，这是为了防止数据计算链路过长造成不必要的延时状况。具体流程图如下所示：

  • ODS 层 ：以 Kafka 作为音讯队列，将所有须要实时计算解决的数据放到对应的 Topic 进行解决；
  • DW 层 ：通过 Flink 实时生产 Topic 中的数据，而后通过数据清理、多维度关联（JOIN）等，将一些雷同维度的业务零碎、维表中的特色属性进行关联，提供数据易用性和复用性能力，最终失去实时明细数据；
  • DIM 层 ：用来存储关联的查问的维度信息，存储介质能够按需抉择，比方 HBase、Redis、MySQL 等；
  • DA 层 ：针对实时数据场景需要，进行高度聚合汇总，服务于 KV、BI 等场景。OLAP 剖析能够应用 ClickHouse，KV 能够抉择 HBase（若数据量较小，能够采纳 Redis）。

通过下面的流程，建设实时数仓分层时，确保了对实时计算要求比拟高的工作不会影响到 BI 报表、或者 KV 查问。然而，会有新的问题须要解决：

Kafka 实时数据如何点查？

生产工作异样时如何剖析？

4.5.4 Kafka 监控

针对这些问题，咱们调研和引入了 Kafka 监控零碎——Kafka Eagle（目前改名为 EFAK）。复用该监控零碎中比拟重要的维度监控性能。

Kafka Eagle 解决可能满足上诉两个维度的监控需要之外，还提供了一些日常比拟实用的性能，比方 Topic 记录查看、Topic 容量查看、生产和生产工作的速率、生产积压等。咱们采纳了 Kafka-Eagle 来作为对实时数仓的工作监控。Kafka-Eagle 零碎设计架构如下图所示：

Kafka-Eagle 是一款齐全开源的对 Kafka 集群及利用做全面监控的零碎，其外围由以下几个局部组成：

  • 数据采集 ：外围数据起源 JMX 和 API 获取；
  • 数据存储 ：反对 MySQL 和 Sqlite 存储；
  • 数据展现 ：消费者利用、图表趋势监控（包含集群状态、生产生产速率、生产积压等）、开发的分布式 KSQL 查问引擎，通过 KSQL 音讯查问；
  • 数据告警 ：反对罕用的 IM 告警（微信，钉钉，WebHook 等），同时邮件、短信、电话告警也一并反对。

局部预览截图如下：

1）Topic 最近 7 天写入量散布

默认展现所有 Topic 的每天写入总量散布，可抉择工夫维度、Topic 聚合维度，来查看写入量的散布状况，预览截图如下所示：

2）KSQL 查问 Topic 音讯记录

能够通过编写 SQL 语句，来查问（反对过滤条件）Topic 中的音讯记录，预览截图如下所示：

3）生产 Topic 积压详情

能够监控所有被生产的 Topic 的生产速率、生产积压等详情，预览截图如下所示：

五、参考资料

1.https://kafka.apache.org/documentation/

2.http://www.kafka-eagle.org/

3.https://github.com/smartloli/kafka-eagle

作者：vivo 互联网服务器团队 -Deng jie

退出移动版