Poseidon 系统是由 360 开源的日志搜索平台，目前曾经用到了消费环节中，可以在数百万亿条、数百 PB 大小的日志数据中快速剖析和检索特定字符串。由于 Golang 得天独厚的支持并发编程，Poseidon 的中心搜索引擎、发报器、查询代理是用 Golang 开发的，在中心引擎查询、多天查询、多天数据异步下载中少量运用了 goroutine+channel 。
大家上午好，我是郭军，很快乐明天在这里和大家交流。我明天演讲标题，Golang 在百万亿搜索引擎中的运用。Poseidon在希腊意思是海神，在这里是海量数据集的主宰者。
之前我的任务不断面向海量用户，去年年中我接触大数据以及海量数据这样的场景，在明天的演讲中，主要会触及以下几方面内容：
设计目的
Go 运用场景与遭遇的应战
怎样应对?
开源的改动
总结
设计目的
首先说一下为什么要做这个系统。这是一个安全公司，APT ( 高危要挟继续性事情)。在清查APT事情的时分，我们通常会找一个样本在某一样时间之内究竟做了什么事情。在海量日志中找这些信息的话，运气好不梗塞的时分，大约两、三小时可以跑出来，假设运气不好，跑的义务太多梗塞的话就要修复，能够一天两天赋能出来数据，显然这样的效率是不高的。
我们的设计目的，我们总的数据量保留三年的历史数据，一共有一百万亿条，大小有 100 PB。秒级交互式搜索照应，从前端发起央求到某一天数据，我们会在几秒钟之内给你前往。我们之前设定秒级60秒前往就可以，实践上做完之后测试的结果都在3秒到5秒之内，90%央求在10秒之内。每天要支持两千亿数据量灌入，原始数据仅存一份，对现有 MR 义务无侵略。ES 原始数据不止存一份，会再存一份，我们这么大数据量来说，再存正本的话，维护成本以及代价是十分大的。ES 支持不了百万亿级数据量，如今业界做到一千亿，我们只做到300多G。然后自定义的分词策略，我们每一个业务的日志格式都不一样，分词策略需求特别灵敏;然后缺点转移节点负载平衡，自动恢复，支持原始日志的批量下载。
图1是我们总体流程，这个图比较复杂，我们之前有同事分享过这个架构。假设明天再分享架构能够时间会不够，图2是它的一个十分复杂的粗略图。
Go 运用场景与遭遇的应战
首先原始日志。 在转化的时分我们把每 128 行原始日志抽取出来作为一个文档，多个文档结合在一同构成一个文件。这里会有人问为什么选择 128 行，我们每天日志量是700亿，按照每一行一个文档我们有700 亿文档。一行日志一个文档，700 亿文档占用空间太大;700 亿数据会收缩。选择 128 行是由于：第一，700 亿除 128 ，大约是 5.46 亿左右，在一定范围内可以接受;第二，由于我们的ID都是数字方式，以发号器方式收回来的，我们紧缩数字的时分，一定要采取各种各样的紧缩办法，我们在这个中央用的插分，关于128 数字的紧缩是比较好的。紧缩 128 行日志比照紧缩1行日志高很多。我们每天原始日志，我说的业务每天原始日志有 60 ，紧缩之后我们能打成 10 左右，这是每天的数据。我们在输入的时分，这个是原始的日志，最后就要到原始日志外面找，最后就要构建数据。由于我们要存入出来的时分，刚刚我说的一句话，很多人不明白，多个衔接起来构成一个文件。有一个十分大的优势，外面的数据我放到另外一个文件外面，我不断叠加，最后这个文件可以被解压。换一种方式来说，把文件都输入到一个文件外面，作为这一个文件，我从这个文件外面取出某一段来，我就可以解压出来，这是一个十分大的特性。由于我需求读一段日志，我一定要知道这个我从哪个中央读到哪个中央，我要知道我读的紧缩文件，解压出来就是128行日志。我们把整个原数据放到这外面，去建索引以及原数据，大体就是这样一个流程。首先看一下离线引擎，客户端央求日志，包括 PC 卫士、网络以及阅读器等等，这块相当于传统搜索引擎的爬虫。下面会详细讲到，离线生成 DocGz 、DocGzmeta ，然后构建原数据。在线引擎，web 我们做复杂的页面开发，到 proxy 集群，再发到 searcher 集群，然后走到 readHDFS ，readHDFS这个效劳是用 Java开发，用 Java 开发有很多坑，但是又不得不用，由于java依然是操作hadoop最适宜的言语。
来说一下数据结构。 我们用 ProtrBuffer 描画中心数据结构。每一个 ID 下面分为两段，那个 docID 就是我这个文档的编号;第二是 rowIndex，每个外面都会对应多行日志，我这外面对应 128 行外面哪一行日志，就是这个做的定位。我们用 map 的方式描画出来，这个是由 DocID 构成的列表，每一个外面会对应多个DocIDList。map 和 string 外面，我要先找到 map ，然后再把数据拿出来。如图3所示。
说一下搜索引擎的中心技术。 首先倒排索引，倒排索引有一个趋向，DocidList 十分长。我们一个分词会先计算出来 hashid ，知道 hashid 之后要查询的时分我们要做一个平台，给出要查询哪一个业务，比如我要查网络等等这些，我们以业务的简写拼接上hashid，然后要查询的时间，查询哪一天的数据，我们引擎不是实时，由于数据量太大做不了实时，只能做到明天查昨天。然后解析 invertedindex 拿到对应的文档信息在外面，找到这个位置之后，把我们一切的需求的原数据抽出来，然后解压。我们就知道某一个分词对应着 DocidList 是哪一个，依据 DocidList 去查要查的 map 信息在哪个中央，获取之后再拼一个途径，把原始数据拿出来。拿出原始数据之后，一个文件外面会有 128 行日志，这 128 行日志Doc外面rowindx 找到文档在哪一行，做过滤就可以了。用十分复杂的话来总结一下，由于 Docid 比较长，我们存一个位置，我们的 DocidList 每一个 Docid 对应的文档也比较多，我们读原始文档的时分，也会存一个位置，在计算机范围中，各种难以处置的成绩都可以添加一个直接的中间层来处置这个成绩。如图4所示。这句话在我们系统中有了很好的尝试，不只是这一块。
