LINE案例研究:使用Fluentd从批处理到流日志处理

109次阅读

共计 1714 个字符,预计需要花费 5 分钟才能阅读完成。

用几句话:

公司:LINE 公司
地点:日本东京

用例概述:

Terabyte 级:Fluentd 用作主要数据流处理器,每天处理数 TB 的数据。
灵活的数据处理:开发了许多自定义插件。Fluentd 充满活力和开放的社区是其在 LINE 上取得成功的关键。
将 Fluentd 的可扩展性提升到一个新的水平:他们的一位工程师在 Fluentd 之上构建了一个无模式 SQL 流处理引擎。

目标:近实时地汇总和处理日志数据
LINE 公司以其同名的应用程序及其平台上的各种服务而闻名,面临着每天收集、存储和分析海量日志数据的挑战。当 Satoshi Tagomori,他们的数据工程团队成员四年前加入公司时,他们有一个经典的 Hadoop 设置:他们使用 Scribe 日志收集器将所有东西收集到 Hadoop 中,并在 Hadoop 上运行批处理作业来处理日志。这个设置工作得很好,但 Tagomori 先生认为有一些改进的地方。

Hadoop 旨在以可扩展的方式运行批处理作业,但不太适合实时的流内处理:Tagomori 先生想要将一些日志处理(特别是针对固定时间窗口的处理)放入到数据收集器中,以便在日志进入时进行分析。该系统可以近乎实时地为内部利益相关者提供有关日志数据的统计数据,从而使整个公司能够更快地做出决策。
通过将日志处理卸载到数据收集器,可以更好地利用 Hadoop 集群的资源:通过将 Hadoop 上的日志数据的一些批处理转换为数据收集器中的流内处理,他们将能够释放 Hadoop 的资源并使用它用于其他批处理作业。

Tagomori 先生探索了各种选择,包括自己建造原型。最终,他找到了 Fluentd 并开始与社区合作。
与社区共同发展
当 Fluentd 于 2011 年 10 月首次推出时,它已经拥有了许多当前的主要优势:可插拔架构使其易于定制和扩展其行为、内存占用空间小、可靠的缓冲和负载平衡机制。然而,有一件事它没有,那就是性能。
“Fluentd… 不是很快。”Tagomori 先生回忆道,他现在是 Fluentd 的核心维护者。“但由于它是一个开源项目,我开始与核心开发人员合作,帮助他们对 Fluentd 的性能进行基准测试。在接下来的一年左右,Fluentd 的性能提高了 10x-15x。”
今天,Fluentd 对于 LINE 来说非常快:他们每天使用 Fluentd 处理 1.5TB(56 亿条记录)的日志数据,在高峰时段每秒数据超过 120,000 条记录。此外,作为 Fluentd 的活跃用户,Tagomori 先生已经贡献了 34 个插件,从 HDFS 输出插件到各种过滤器插件,现在在许多其他组织中使用。
“社区是我最喜欢 Fluentd 的地方之一。”Tagomori 先生说。“我确实考虑过其他开源数据采集器,但 Fluentd 拥有一个充满活力的社区,可以通过坚定的承诺保持 Fluentd 的简单、强大和快速。此外,它的插件系统经过精心设计,使贡献变得非常容易。”
现在:在 Fluentd 上使用 SQL 进行无模式流处理
在开发了数十个插件之后,Tagomori 先生开始认为他可以将 Fluentd 演变成一个轻量级数据流处理器。2014 年 5 月,他推出了无模式流处理引擎 Norikra,允许用户针对数据流编写 SQL 查询。
“Norikra 可以在 Fluentd 上对数据流进行采样、过滤、聚合和连接。它的查询语言是 SQL,所以没有特殊的 DSL 需要学习,你可以随时添加和删除 SQL 查询。Norikra 已经替 LINE 解决了一些数据相关的挑战,允许我们直接查询数据流。”

KubeCon + CloudNativeCon 和 Open Source Summit 大会日期:

会议日程通告日期:2019 年 4 月 10 日
会议活动举办日期:2019 年 6 月 24 至 26 日

KubeCon + CloudNativeCon 和 Open Source Summit 赞助方案 KubeCon + CloudNativeCon 和 Open Source Summit 多元化奖学金现正接受申请 KubeCon + CloudNativeCon 和 Open Source Summit 即将首次合体落地中国 KubeCon + CloudNativeCon 和 Open Source Summit 购票窗口,立即购票!CNCF 邀请你加入最终用户社区

正文完
 0