10年大数据架构师：日访问百亿级，如何架构并优化日志系统？
发布时间：2022-09-27 12:50:46 所属栏目：大数据 来源：
导读： 日志数据是最常见的一种海量数据，以拥有大量用户群体的电商平台为例，双 11 大促活动期间，它们可能每小时的日志数量达到百亿规模，海量的日志数据暴增，随之给技术团队带来严峻的挑战。
本文将从海量日
本文将从海量日
|
日志数据是最常见的一种海量数据，以拥有大量用户群体的电商平台为例，双 11 大促活动期间，它们可能每小时的日志数量达到百亿规模，海量的日志数据暴增，随之给技术团队带来严峻的挑战。 本文将从海量日志系统在优化、部署、监控方向如何更适应业务的需求入手，重点从多种日志系统的架构设计对比；后续调优过程：横向扩展与纵向扩展，分集群，数据分治，重写数据链路等实际现象与问题展开。 日志系统架构基准 有过项目开发经验的朋友都知道：从平台的最初搭建到实现核心业务，都需要有日志平台为各种业务保驾护航。 大数据日知录 架构与算法_大数据架构师_大数据日知录 架构与算法 pdf 如上图所示，对于一个简单的日志应用场景，通常会准备 master/slave 两个应用。我们只需运行一个 Shell 脚本，便可查看是否存在错误信息。 随着业务复杂度的增加，应用场景也会变得复杂。虽然监控系统能够显示某台机器或者某个应用的错误。 然而在实际的生产环境中，由于实施了隔离，一旦在上图下侧的红框内某个应用出现了 Bug，则无法访问到其对应的日志，也就谈不上将日志取出了。 另外，有些深度依赖日志平台的应用，也可能在日志产生的时候就直接采集走，进而删除掉原始的日志文件。这些场景给我们日志系统的维护都带来了难度。 大数据日知录 架构与算法_大数据架构师_大数据日知录 架构与算法 pdf 参考 Logstash，一般会有两种日志业务流程： 大数据日知录 架构与算法 pdf_大数据架构师_大数据日知录 架构与算法 我们可以从实时性和错误分析两个维度来区分不同的日志数据场景： 实时，一般适用于我们常说的一级应用，如：直接面向用户的应用。我们可以自定义各类关键字，以方便在出现各种 error 或 exception 时，相关业务人员能够在第一时间被通知到。 准实时，一般适用于一些项目管理的平台，如：在需要填写工时的时候出现了宕机，但这并不影响工资的发放。 平台在几分钟后完成重启，我们可以再登录填写，该情况并不造成原则性的影响。因此，我们可以将其列为准实时的级别。 除了直接采集错误与异常，我们还需要进行分析。例如：仅知道某人的体重是没什么意义的，但是如果增加了性别和身高两个指标，那么我们就可以判断出此人的体重是否为标准体重。 也就是说：如果能给出多个指标，就可以对庞大的数据进行去噪，然后通过回归分析，让采集到的数据更有意义。 此外，我们还要不断地去还原数字的真实性。特别是对于实时的一级应用，我们要能快速地让用户明白他们所碰到现象的真实含义。 例如：商家在上架时错把商品的价格标签 100 元标成了 10 元。这会导致商品马上被抢购一空。 但是这种现象并非是业务的问题，很难被发现，因此我们只能通过日志数据进行逻辑分析，及时反馈以保证在几十秒之后将库存修改为零，从而有效地解决此问题。可见，在此应用场景中，实时分析就显得非常有用。 最后是追溯，我们需要在获取历史信息的同时，实现跨时间维度的对比与总结，那么追溯就能够在各种应用中发挥其关联性作用了。 大数据日知录 架构与算法_大数据架构师_大数据日知录 架构与算法 pdf 上述提及的各个要素都是我们管理日志的基准。如上图所示，我们的日志系统采用的是开源的 ELK 模式： 由于日志服务对于业务来说仅起到了维稳和保障的作用，而且我们需要实现快速、轻量的数据采集与传输，因此不应占用服务器太多资源。 在方式上我们采用的是插件模式，包括：input 插件、output 插件、以及中间负责传输过滤的插件。这些插件有着不同的规则和自己的格式，支持着各种安全性的传输。 日志系统优化思路 大数据架构师_大数据日知录 架构与算法 pdf_大数据日知录 架构与算法 有了上述日志的架构，我们针对各种实际的应用场景，进一步提出了四个方面的优化思路： 基础优化 内存：如何分配内存、垃圾回收、增加缓存和锁。 网络：网络传输序列化、增加压缩、策略、散列、不同协议与格式。 CPU：用多线程提高利用率和负载。 此处利用率和负载是两个不同的概念： 磁盘：尝试通过文件合并，减少碎片文件的产生，并减少寻道次数。同时在系统级别，通过修改设置，关闭各种无用的服务。 平台扩展 做加减法，或称替代方案：无论是互联网应用，还是日常应用，我们在查询时都增加了分布式缓存，以有效提升查询的效率。另外，我们将不被平台使用到的地方直接关闭或去除。 纵向扩展：如增加扩展磁盘和内存。 横向扩展：加减/平行扩展，使用分布式集群。 数据分治 根据数据的不同维度，对数据进行分类、分级。例如：我们从日志中区分error、info、和 debug，甚至将 info 和 debug 级别的日志直接过滤掉。 数据热点：例如：某种日志数据在白天的某个时间段内呈现暴涨趋势，而晚上只是平稳产生。我们就可以根据此热点情况将它们取出来单独处理，以打散热点。 系统降级 我们在对整体业务进行有效区分的基础上，通过制定一些降级方案，将部分不重要的功能停掉，以满足核心业务。 日志系统优化实践 大数据日知录 架构与算法_大数据日知录 架构与算法 pdf_大数据架构师 面对持续增长的数据量，我们虽然增加了许多资源，但是并不能从根本上解决问题。 特别体现在如下三方面： 面对持续增长的数据量，我们虽然增加了许多资源，但是并不能从根本上解决问题。 一级业务架构 大数据日知录 架构与算法_大数据日知录 架构与算法 pdf_大数据架构师 我们日志系统的层次相对比较清晰，可简单分为数据接入、数据存储和数据可视化三大块。 具体包括： 大数据日知录 架构与算法 pdf_大数据架构师_大数据日知录 架构与算法 该架构在实现上会用到 Golang、Ruby、Java、JS 等不同的语言。在后期改造时，我们会将符合 Key-Value 模式的数据快速地导入 HBase 之中。 基于 HBase 的自身特点，我们实现了它在内存层的 B+ 树，并且持久化到我们的磁盘之上，从而达到了理想的快速插入的速度。这也正是我们愿意选择 HBase 作为日志方案的原因。 二级业务架构 大数据日知录 架构与算法 pdf_大数据日知录 架构与算法_大数据架构师 我们直接来看二级业务架构的功能图，它是由如下流程串联而成的： 大数据日知录 架构与算法_大数据架构师_大数据日知录 架构与算法 pdf 通常从采集（logstash/rsyslog/heka/filebeat）到面向缓存的 Kafka 是一种典型的宽依赖。 所谓宽依赖，是指每个 App都可能跟每个 Broker 相关联。在 Kafka 处，每次传输都要在哈希之后，再把数据写到每个 Broker 上。 而窄依赖，则是其每一个 Fluentd 进程都只对应一个 Broker 的过程。最终通过宽依赖过程写入到 ES。 采集 如 Rsyslog 不但占用资源最少，而且可以添加各种规则，它还能支持像 TSL、SSL 之类的安全协议。 Filebeat 轻量，在版本 5.x 中，Elasticsearch 具有解析的能力（像 Logstash 过滤器）— Ingest。 这也就意味着可以将数据直接用 Filebeat 推送到 Elasticsearch，并让 Elasticsearch 既做解析的事情，又做存储的事情。 Kafka 大数据架构师_大数据日知录 架构与算法 pdf_大数据日知录 架构与算法 接着是 Kafka，Kafka 主要实现的是顺序存储，它通过 topic 和消息队列的机制，实现了快速地数据存储。 而它的缺点：由于所有的数据都向 Kafka 写入，会导致 topic 过多，引发磁盘竞争，进而严重拖累 Kafka 的性能。 另外，如果所有的数据都使用统一标签的话，由于不知道所采集到的数据具体类别，我们将很难实现对数据的分治。 因此，在后面的优化传输机制方面，我们改造并自己实现了顺序存储的过程，进而解决了一定要做持久化这一安全保障的需求。 Fluentd Fluentd 有点类似于 Logstash，它的文档和插件非常齐全。其多种插件可保证直接对接到 Hadoop 或 ES。 就接入而言，我们可以采用 Fluentd 到 Fluentd 的方式。即在原有一层数据接入的基础上，再接一次 Fluentd。同时它也支持安全传输。当然我们在后面也对它进行了重点优化。 ES+Kibana 大数据架构师_大数据日知录 架构与算法_大数据日知录 架构与算法 pdf 最后我们用到了 ES 和 Kibana。ES 的优势在于通过 Lucene 实现了快速的倒排索引。 由于大量的日志是非结构化的，因此我们使用 ES 的 Lucene 进行包装，以满足普通用户执行非结构化日志的搜索。而 Kibana 则基于 Lucene 提供可视化显示工具。 问题定位与解决 下面介绍一下我们碰到过的问题和现象，如下这些都是我们着手优化的出发点： 大数据架构师_大数据日知录 架构与算法_大数据日知录 架构与算法 pdf 由于所有数据都被写入 Kafka，而我们只用到了一个 topic，这就造成了每一类数据都要经过不一定与之相关的规则链，并进行不一定适用的规则判断，因此数据的传输效率整体被降低了。 Fluentd 的 host 轮询机制造成高水位频发。由于 Fluentd 在与 ES 对接时遵循一个默认策略：首选前五台进行数据写入，即与前五台的前五个接口交互。 在我们的生产环境中，Fluentd 是用 CRuby 写的。每一个进程属于一个 Fluentd 进程，且每一个进程都会对应一个 host 文件。 而该 host 文件的前五个默认值即为 ES 的写入入口，因此所有机器都会去找这五个入口。 倘若有一台机器宕机，则会轮询到下一台。如此直接造成了高水位的频繁出现、和写入速度的下降。 众所周知，对日志的查询是一种低频次的查询，即只有在出现问题时才会去查看。但是在实际操作中，我们往往通过检索的方式全部取出，因此意义不大。 另外 ES 为了达到较好的性能，会将数据存储在 raid0 中，存储的时间跨度往往会超过 7 天，因此其成本也比较高。 通过对数据的实时线分析，我们发现并未达到写入/写出的平衡状态。 为了提高 Fluentd 的利用率，我们用 Kafka 去数据的时候提高了量，原来是 5 兆，现在我们改到了 6 兆。 如果只是单纯传输，不论计算的话，其实可以改更高。只不过因为我们考虑到这里包含了计算的一些东西，所以只提到了 6 兆。 我们的 Fluentd 是基于 JRuby 的，因为 JRuby 可以多线程，但是我们的 CRuby 没有任何意义。 为了提高内存，我把 Ruby 所有的内存机制了解了一下，就是散列的一些 host 文件，因为我们每个进程都选前五列就可以了，我多开了几个口。ES 的优化这一块，在上 ES 之前，我们已经有人做过一次优化了。 因为基于我刚才说的有时候日志量很高，有时候日志量很少。我们会考虑做动态配置。 因为 ES 就是支持动态配置的，所以它动态配置的时候，我们在某些场景下可以提高它的写入速度，某些场景下可以支持它的这种查询效率。我们可以尝试去做一些动态配置负载。 改造一：存储降低 大数据架构师_大数据日知录 架构与算法 pdf_大数据日知录 架构与算法 大数据架构师_大数据日知录 架构与算法_大数据日知录 架构与算法 pdf 降低存储在整体架构上并没有太大变化，我们只是在传输到 Fluentd 时把天数降下来，改成了一天。 同时，我们直接进行了分流，把数据往 Hadoop 里写，而把一些符合 Kibana 的数据直接放入 ES。 上面提过，日志查询是低频次的，一般需要查询两天以上数据的可能性很小，因此我们降低存储是非常有意义的。 改造二：数据分治 大数据架构师_大数据日知录 架构与算法 pdf_大数据日知录 架构与算法 我们在日志文件节点数较少（机器数量小于 5 台）的情况下，去掉了 Kafka 层。由于 Fluentd 可以支持数据和大文件存储，因此数据能够被持久化地存入磁盘。 我们给每个应用都直接对应了一个 tag，以方便各个应用对应到自己的 tag、遵循自己的固定规则、并最终写入 ES，这样就方便了出现问题的各自定位。 另外，我们运用延迟计算和文件切分也能快速地找到问题的根源。因此我们节约了 Kafka 和 ES 各种计算资源。 在实际操作中，由于 HBase 不用去做 raid，它自己完全能够控制磁盘的写入，因此我们进行了数据压缩。就其效果而言，ES 的存储开销大幅降低。 在后期，我们也尝试过一种更为极端的方案：让用户直接通过客户端的 Shell 去查询数据大数据架构师，并采用本地缓存的留存机制。 （编辑：PHP编程网 - 金华站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐
浙公网安备 33038102330481号