引言我们在实践中提供一些参考。这是一个日志相关的项目，负责收集、处理、存储、查询京东卖家相关操作的日志。这里称为“卖家日志”。在日常的开发过程中，你可能对日志这个词并不陌生，比如Log4j、slf4j等，这些都是经常遇到的。这些日志工具通常用于记录代码的运行状态。当系统出现问题时，可以及时查看登录。定位问题，以便快速解决问题。今天说的“卖家日志”与普通日志略有不同。“卖家日志”用于记录卖家对系统各项功能的操作情况。修改价格后，系统会记录日志。系统中的部分信息可以提供给商家和运营人员，让商家知道自己做了哪些操作，也让运营商更了解商家。管理。此外，它还可以帮助找到日志中找不到的信息，从而帮助开发者解决问题。接下来说一下业务场景。业务场景中有很多业务系统，比如订单、商品等系统。以前，每个人都记录自己的日志，记录的方式多种多样，格式也各不相同。这对商家和运营商来说非常重要。据说很头疼。没有运营商查询日志的平台。每次出现问题，只需要半天时间就可以找到对应的开发团队，让他们配合，找出问题所在。而且有时候效果不是很好。在这样的情况下，“卖家日志”应运而生，为商户、运营、开发提供统一的日志平台。所有团队的日志都可以通过申请权限访问这个平台，运营和商户都存在问题。遇到问题可以第一时间自己找日志解决，而不是盲目找人解决。以上日志的总体设计是“卖家日志”系统的总体流程图。对于处理日志的业务，写了一个日志客户端，提供给各个组的调用，也用到了kafka+Strom的流计算。对于日志查询这块，我首先想到的是ES，因为ES是一个分布式的文件检索系统，可以根据日志的内容提供丰富的检索功能。对于冷日志的存储，使用了存储量更大的工具——HBase，也可以根据一些基本条件来查找日志。流程：日志客户端-Kafka集群-Strom消费-ES-HBase-...技术要点Kafka：一个高吞吐量的分布式发布订阅消息系统，可以处理消费级网站所有的action流数据，说起来就是通俗易懂，Kafka可以理解为一个消息队列。Storm：Storm是一个开源的分布式实时大数据处理框架。是实时的，可以理解为专门用来处理流式实时数据的东西。ElasticSearch：ES是一个基于Lucene的搜索服务器。它是一个分布式文件检索系统。提供高效的检索，支持多种检索条件，使用非常方便。HBase：HBase是一种高可靠、高性能、面向列、可扩展的分布式存储系统，适用于结构化存储。底层依赖于Hadoop的HDFS。使用HBase技术，可以在廉价的PCServer存储集群上搭建大规模的架构。日志客户端日志客户端为各个系统提供了统一的API，类似于Log4j等日志工具，访问起来方便简洁，与普通的日志写入无异。这里需要提到的一点是客户端的日志处理过程。用下图来说明：你可能会疑惑，为什么不直接写到Kafka呢？接下来做个对比，直接写到本地fast，还是写到KafkaFast？显然，在本地写是很快的。因为在写日志的时候，想要达到的效果就是尽量不影响业务，能够更快的处理。对于日志的后期处理，只需要在后台开几个固定的线程，这样即使业务无关也能感知，不会浪费资源。另外，磁盘的放置方式也为日志数据不丢失提供了保障。另外这里本地数据的存储和读取使用了NIO的内存映射，数据的写入和读取得到了进一步的完善，使得业务日志可以快速写入磁盘，也可以快速读取并发送到Kafka，从而也是一个优势。为什么要用Kafka首先介绍一下Kafka。Kafka是一个高吞吐量的分布式发布-订阅消息系统，可以处理消费级网站中的所有动作流数据。Kafka可以理解为一个消息队列。具体的可以上网搜索。Kafka的主要应用场景：连续消息：为了从大数据中提取有用的数据，任何数据丢失都会影响生成的结果。Kafka提供复杂度为O(1)的磁盘结构来存储数据，即使是TB级数据也提供恒定时间性能和高吞吐量：Kafka采用通用硬件支持每秒百万级的吞吐量分布式：明确支持分区消息，通过Kafka服务器集群和消费机分发消费，维护各个分区有序支持多种语言：Java、.net、PHP、ruby、Python实时性：生产者线程产生的消息可以立即被生产者消费消费者线程，这个特性和事件驱动系统类似Kafka的优点：主要用来解决百万级数据中生产者和消费者之间的数据传输问题。它可以将一份数据提供给多个接收者，在两个系统隔离的情况下做不同的处理，当他们不能通信的时候，如果想让他们通信，需要重建其中一个项目，而Kafka实现了生产者和消费者的无缝连接通过上面对Kafka的应用场景和优势的描述，如果你了解业务，可以去“卖家日志”的场景，可以理解为什么用的技术是Kafka。因为Kafka速度快，适合做流处理，可以把burst转成流畅的stream，供Strom处理。因为日志是不规则的，就像水的流动一样，永远是连续不断的，不一定是顺畅的。Kafka的一些特性非常适合“卖家日志”的业务。另外，Kafka作为一个高吞吐量的分布式发布订阅消息系统，可以有多个生产者和消费者，这也是“卖家的日志”。”统一接入和后期多样化处理提供了强有力的保障。如下图所示：Storm的应用日志是一个数据流，是不规则的、不稳定的。处理这些不规则、不稳定的数据，最好的处理方式是什么？经过讨论，最终采用了Kafka+Storm来处理这些日志数据。为什么要用Storm？Storm是一个免费、开源、分布式、高容错的实时计算系统。Storm让连续流计算变得简单。Kafka可以转换突发数据源源不断，源源不断地推送给Storm，Storm消费、处理，最后入库。Storm处理这部分的过程如下图所示：从上图可以看出，Storm整个处理日志的过程有两次，一次是验证是否有效，封装成一个对象和交给下一个Bolt和insertBolt负责把数据放入数据库。这样的过程看起来比较清晰。关于数据存储的处理数据存储，用ES存储热数据，冷数据，也就是很久以前的数据，用HBase存储和备份。你为什么要这样做？日志数据采用什么样的存储直接影响查询。之前的想法是直接把能抗量的数据存储在HBase上，但是对于各种条件的查询，HBase显然不符合要求，所以经过审查，决定使用分布式检索系统进行存储，即弹性搜索。那你可能会问：为什么要用HBase？因为ES是检索系统，不适合存储大量数据。随着数据量的增加，ES的查询性能会逐渐下降，而且日志需要保存一年，每天的数据量是600到7亿条数据，所以对于ES来说，很难抗拒，不断的加机器也不是什么好办法。经过讨论，我们寻找了一种更能存储数据的东西来存储长期不用的日志数据，并且可以提供简单的检索。最后我们选择了HBase，将最近两个月的数据放在ES中，为用户提供多条件检索，两个月前的数据存储在HBase中，提供简单的检索功能，因为两个多月前的日志还不算大，无法查看。具体数据流向如下图所示：随着数据量的增加，对服务的要求也越来越高。即使存储的数据冷热分离，查询也很繁忙，而且随着数据量的增加，插入次数越来越慢。而且对于申请的kafka集群来说，这么多client显然无法处理每天这么大的输入量，所以仔细梳理了日志的业务流程。解决方案经过不断的讨论和架构审查，我想出了一个更好的解决方案，就是将日志数据的业务分离出来。提取了几个日志量比较大的业务，比如订单，商品。新申请新订单新商品的Kafka集群和ES集群。其他业务保持不变。订单日志、商品日志与其他日志分离，分别使用Kafka和ES、HBase集群。通过业务的分离，性能得到了明显的提升，数据的业务分类也方便了日志数据的管理，达到了相互独立的状态。未来对于HBase的数据，也计划将其推入大数据集市，提供给不同部门进行数据分析。
