kafka-root.log 位于broker实例所在节点的路径：/var/log/Bigdata/kafka/broker下，该日志里面会统计每分钟kafka磁盘io的使用率，打印信息如下：可以通过Linux命令批量检查一个或者整个集群的io使用情况。         （1）查询一个broker节点的io使用情况，并且过滤掉0.0x的低磁盘使用率数据。登录到其中一个broker节点的后台目录/var/log/Bigdata/kafka/broker，执行以下命令cat kafka-root.* |   grep "Collect topic partition" | awk -F'is:' '{print $2}' | awk -F',' '{print $1}' | grep –v "0.0"（2） 查询整个集群所有broker节点的io使用情况，并且过滤掉0.0x的低磁盘使用率数据。通过前台将对应时间段的kafka日志全部收集回来在本地全部解压缩后，在根目录下全部查询，zgrep ioUsage ./根目录kafka的目录*/var/log/Bigdata/kafka/broker/kafka-root.* | grep "Collect topic partition" | awk -F'topic info' '{print $1}' | awk '{print $1 " " $2 " " $15}' | grep -v "0.0"例如：如下根目录下kafka的目录名称为n-kafka-* 那么命令为zgrep "ioUsage" ./n-kafka-*/var/log/Bigdata/kafka/broker/kafka-root.* | grep "Collect topic partition" | awk -F'topic info' '{print $1}' | awk '{print $1" "$2 " " $15}' | grep -v "0.0"得出的结果如下：如果以上的结果持续出现0.8~1.0的数值，说明磁盘io在80%~100%之间，磁盘可能存在异常注意：在8.0版本后ioUsage的数据信息被调整为了DEBUG，如果需要该数据需要手动调整broker节点的log4j日志。调整方式如下：1，登录到每个broker节点的/opt/huawei/Bigdata/FusionInsight_Current/*_*_Broker/etc目录下2，打开log4j.properties文件vim log4j.properties3，在最后一行追加log4j.logger.com.huawei.kafka.PartitionStatusMetrics=DEBUG,rootAppender

PR巡检是RAID卡的一个特性，它会周期性的定时巡检磁盘，对数据进行检查校验，以防出错，但是在巡检的时候会导致磁盘读写性能下降。Raid卡缓存写策略，建议使用WB模式，WB：在配置界面中一般体现为“Write Back”等字样。使用此策略后，需要向虚拟磁盘写数据时，会直接写入Cache中，当写入的数据积累到一定程度，RAID卡才将数据刷新到虚拟磁盘，这样不但实现了批量写入，而且提升了数据写入的速度。当控制器Cache收到所有的传输数据后，将给主机返回数据传输完成信号。要使用该策略，要求RAID卡支持数据掉电保护功能，且如果此时超级电容异常，可能导致数据丢失。WT：在配置界面中一般体现为“Write Through”等字样。使用此策略后，RAID卡向虚拟磁盘直接写入数据，不经过Cache。当磁盘子系统接收到所有传输数据后，控制器将给主机返回数据传输完成信号。此策略缺点是写入速度较低。排查方式：针对以上两种场景，均有明显的磁盘IO升高的情况，建议通过3.3章节对kafka-root.log进行检查。如果kafka集群的磁盘部署使用了raid5建议硬件侧关闭PR巡检。开启WB模式

数据压缩是kafka解决空间问题和超大数据问题关键场景，例如：当kafka的磁盘空间不足时，可以使用数据压缩，来节省磁盘空间的使用。当生产端需要向kafka集群发送大量的超大数据（大于1M的数据）时可以通过开启压缩模式来减少传输过程中带来的网络消耗。压缩模式开启有一定的要求，为什么会这样，先看kafka压缩的原理：Kafka服务端使用的topic最终压缩模式（由compression.type决定）为producer。这也就意味着，开启压缩后存在kafka中的数据类型其实本质就是一个压缩包。如下图：     图：客户端与kafka服务端版本一致的存储方式如果客户端与kafka服务端版本不一致会怎样？再看下面的图。                                             图：客户端与kafka服务端版本不一致的存储方式客户端使用的kafka-client-xxxx.jar版本要与服务端的版本不一致时，在kafka的服务端会出现，对数据的“解压缩，再压缩”的过程。这个流程会非常损耗CPU，并且可能会造成kafka的GC超时从而导致kafka集群性能下降。排查方式：如果节点CPU使用率超过80%，或者有kafka的GC时间超过阈值的告警。或者查看异常的broker节点的监控曲线：如果这个节点的GC时间长时间达到了秒级，说明GC不正常。给kafka进程打一个jstack，如果jstack中出现gzip, snappy,lz4,zstd，说明有开启压缩，例如开启了GZIP。解决方案：建议客户升级客户端，保持和服务端一致使用低版本客户端时，禁用压缩

kafka全部案例集合见维护宝典：https://support.huawei.com/hedex/hdx.do?docid=EDOC1100222546&lang=zh&idPath=22658044|22662728|22666212|22396131（FusionInsight HD&MRS租户面集群故障案例（6.5.X-8.X）->维护故障类->kafka->常见故障）kafka经典案例、总结、重大问题见下表：经典案例分类序号案例出现频次服务端性能问题1.1Kafka CPU使用率高排查思路及解决方案★★★★1.2异常鉴权信息量大导致集群性能下降（旧版本鉴权）★★1.3使用了与服务端版本不一致的客户端，并且开启了数据压缩★★★★1.4使用了raid方式部署，定期开启PR巡检，导致磁盘IO下降★★★★★topic异常2.1Kafka分区未同步★★★★★2.2Kafka过期数据未老化原因及解决方案★★2.3FusionInsight Kafka删除Topic失败原因及解决方案★★2.4FusionInsight Kafka创建Topic失败原因及解决方案★★★排查手段3.1如何根据strace信息定位异常连接的客户端★★3.2收集kafka-root.log查看每个broker节点的磁盘IO★★★★★3.3检测网络异常的通用方式★★★★★3.4Kafka集群性能的检测方式★★★★★3.5开启kafka-request.log日志，定位生产消费每个阶段的耗时★★★★★最佳实践4.1关于kafka的Producer的粘性分区的坑★★★

828选华为云，实惠更实用！研发与中间件专场全场3折起！ Redis、Kafka、数字资产链、软件开发平台，首购低至1.98元！ 下单抽FreeBuds耳机，满额送P50手机，助力企业转型云原生2.0！ 活动有效期至2022年9月16日，上云正当时！>点击这里，马上进入活动专场<

亲爱的开发者们，618年中钜惠来袭！参与试用，100%有礼！最高可得价值899元FreeBuds耳机，满额再送MateBook笔记本！>点击这里，马上进入活动专场<

什么是微认证？          华为云微认证是基于线上学习与在线实践，快速获得场景化技能提升的认证。微认证清单 - 大数据使用DLI Flink SQL进行电商实时业务数据分析开发     课程简介：电商通常有web,小程序等多种接入方式,为掌握其实时变化，需统计各平台的实时访问量、订单数等，从而针对性地调整营销策略。     课程结构：电商实时业务应用场景介绍8认识电商常用的实时业务特点及应用电商实业业务对应大数据技术组件的原理47了解实现电商网站数据实时计算的相关大数据技术特性及原理华为云实时流计算Flink及解决方案7掌握华为云实时流计算Flink及解决方案及相应应用华为云实战案例15掌握华为云实时流计算Flink验流程及开发思路     1、电商实时业务应用场景介绍          电商从2009年发展至今,当前线上购物无疑是最火热的购物方式,而电商平台则又可以以多种方式接入,例如通过web方式访问、通过app的方式访问、通过微信小程序的方式访问等等。电商平台则需要每天统计各平台的实时访问数据量、订单数、访问人数等等          指标,从而能在显示大屏上实时展示相关数据,方便及时了解数据变化,有针对性地调整营销策略。这些高效快捷地统计指标是如何获得的呢?这是我们这次课程及实验所需要理解学习的          当前有很多电商的大数据平台会将每个商品的订单信息实时写入Kafka中,这些信息包括订单ID、订单生成的渠道(即web方式、app方式等)、订单时间、订单金额、折扣后实际支付金额、支付时间、用户ID、用户姓名、订单地区ID等信息。          针对业务场景,我们在大数据分析业务需要做的,就是根据当前可以获取到的业务数据,实时统计每种渠道的相关指标,输出存储到数据库中,并进行大屏展示。     2、电商实时业务对应大数据技术组件的原理        （1）流计算                概述         流式计算就像汽车过收费站,每一个车在通过闸口时都要收费。流式计算中每个实时产生的数据都要被实时的处理。        流计算秉承一个基本理念,即数据的价值随着时间的流逝而降低,如用户点击流。因此,当事件出现时就应该立即进行处理,而不是缓存起来进行离线处理。为了及时处理流数据,就需要一个低延迟、可扩展、高可靠的处理引擎。                应用场景                主要框架       Kafka        Kafka是最初由Linkedin公司开发,是一个分布式、分区的、多副本的、多订阅者,基于zookeepert办调的分布式日志系统。       主要应用场景是:日志收集系统和消息系统。        分布式消息传递基于可靠的消息队列,在客户端应用和消息系统之间异步传递消息。有两种主要的消息传递模式:点对点传递模式、发布-订阅模式。大部分的消息系统选用发布-订阅模式。       Kafka就是一种发布-订阅模式。 Spark                Spark简介          2009年诞生于美国加州大学伯克利分校AMP实验室。          Apache Spark是一种基于内存的快速、通用、可扩展的大数据计算引擎。          Spark 是一站式解决方案，集批处理（Spark Core ）、实时流处理（Spark Streaming ）、交互式查询（Spark SQL ）、图计算（GraphX ）与机器学习（MLLib ）于一体。                  Spark应用场景           批处理可用于ETL (抽取、转换、加载)。          机器学习可用于自动判断淘宝的买家评论是好评还是差评。          交互式分析可用于查询Hive数据仓库。          流处理可用于页面点击流分析，推荐系统，舆情分析等实时业务。                 Spark架构                Spark特点                       SparkStreaming          Spark Streaming的基本原理是将实时输入数据流以时间片（秒级）为单位进行拆分，然后经Spark引擎以类似批处理的方式处理每个时间片数据。        Flink华为云数据可视化DLI          产品概述数据湖探索(Data Lake Insight,简称DLI)是完全兼容Apache Spark和Apache Flink生态,实现批流一体的Serverless大数据计算分析服务。DLI支持多模引擎,企业仅需使用SQL或程序就可轻松完成异构数据源的批处理、流处理、内存计算、机器学习等,挖掘和探索数据价值。          特点          应用场景：电商行业数据可视化          概述            广义:指一切能够把抽象、枯燥或难以理解的内容,包括看似毫无意义的数据、信息、知识等以一种容易理解的视觉方式展示出来的技术。            狭义:利用计算机图形学和图像处理技术,将数据转换为图形或图像在屏幕上显示出来,并进行各种交互处理的理论、方法和技术。          发展          工具        华为云数据可视化DLV          概述         数据可视化(Data Lake Visualization,简称DLV)是一站式数据可视化开发平台,适配云上云下多种数据源,提供丰富多样的2D、3D可视化组件,采用拖搜式自由布局。          特点          应用场景：某企业安全态势感知     3、华为云实时流计算Flink及解决方案        基于实时流计算的可视化解决方案        解决方案应用场景之智慧城市          智慧城市是通过对大量实时数据的监控、采集和处理,为复杂问题做出快速响应。智慧城市涉及范围很广,智慧城市建设主要包括政务、交通、企业、民生等方面。         解决方案应用场景之实时推荐          根据用户行为数据(包含历史数据和实时数据),通过构建的推荐模型对用户行为秒级调整并生成对应的推荐列表,分钟级更新候选集。          实时推荐主要包括广告推荐、商品推荐、视频推荐、游戏推荐等。     动手实验：         流程介绍 实验单独学习链接：华为云原生大数据serverless服务DLI_在线课程_华为云开发者学堂_云计算培训-华为云 (huaweicloud.com)

未通过然后特还挺好

**一、背景** Kafka中的数据持久化到磁盘上时会写log文件，为了快速访问到指定offset和timestamp的消息，同步会创建两个index文件，而这中index文件是稀疏文件，都是预分配一定大小，那么对于小资源、小数据量的环境下，index文件会占用一定磁盘空间，因此需要优化，以更充分利用磁盘空间。 **二、调优分析** 1、Kafka持久化数据文件如下：  一个index文件默认大小为10M，由log.index.size.max.bytes参数控制决定，offset的index和timeindex两个文件会占用20M 2、而index文件中存的索引条数，由参数log.segment.bytes和log.index.interval.bytesh决定，log.segment.bytes默认1G，索引间隔默认是4K。 3、offset索引和timestamp索引是一一对应的；且单条索引大小：offset索引是8字节；timestamp索引是12字节。插入索引代码如下：  offsetIndex插入：  timestamp索引插入：  4、综上信息，当log.segment.bytes和log.index.interval.bytes固定的时候，索引文件大小配置log.index.size.max.bytes可按照如下公式进行配置： **log.index.size.max.bytes >= log.segment.bytes/ log.index.interval.bytes * 12**

分布式消息服务 Kafka可以支持公网访问么？公网如何接入的？