导读：随着 360 企业平安浏览器用户规模的一直扩张，浏览器短时间内会产生大量的日志数据。为了提供更好的日志数据服务，360 企业平安浏览器设计了对立运维治理平台，并引入 Apache Doris 代替了 Elasticsearch，实现日志检索与报表剖析架构的对立，同时依赖 Doris 优异性能，聚合剖析效率呈数量级晋升、存储老本降落 60%…. 为日志数据的可视化和价值施展提供了松软的根底。
作者 |360 企业平安浏览器 刘子健
近年来，随着网络攻击和数据泄露事件的减少，使得浏览器平安问题变得更加紧迫和严厉。破绽一旦被利用，一个简略的链接就能达到数据浸透的目标，而传统浏览器在安全性和隐衷爱护方面存在一些限度，无奈满足政企畛域对于平安浏览的需要。 在此背景下，360 企业平安浏览器成为政企客户的首选，以提供对立治理、降本增效、平安可控的解决方案。
在 360 企业平安浏览器弱小平安防护能力的背地，对海量平安日志进行深入分析和开掘是及时发现潜在危险的重要伎俩。为了提供更好的日志数据服务，360 企业平安浏览器设计了对立运维治理平台，引入 Apache Doris 作为日志剖析架构的外围组件，实现数据导入、计算和存储的对立，保障了数据的准确性和一致性，实现了低成本、高效的实时查问能力与同步能力，为日志数据的可视化和价值施展提供了松软的根底。
业务需要
随着 360 企业平安浏览器用户规模的一直扩张，浏览器短时间内会产生大量的日志数据，这些数据具备格局多样化、信息维度丰盛、时效要求高、数据体量大和隐衷安全性低等特点。如果可能对这些数据进行无效剖析，可及时发现潜在威逼并晋升网站应用体验，因而咱们设计了对立运维治理平台。该平台旨在对终端层、应用层和平安层进行监控和剖析，并进行多维度剖析和可视化展现。
- 在应用层，提供利用总览、拜访剖析、性能剖析、体验剖析以及异样剖析等性能，可全面理解利用的运行状况，及时发现并解决利用中存在的问题。
- 在终端层，提供终端导览和终端沉闷剖析性能，及时把握终端设备情况，从而更好地治理和优化终端性能。
- 在平安层，提供策略预警和策略倡议等性能，可及时发现和预防平安危险，进步零碎的安全性。
对于政企相干单位而言，浏览器受到攻打可能导致大量隐衷数据泄露，给单位和集体带来难以预料的结果。因而， 为保障客户信息的平安，对立运维治理平台应具备以下几个能力：
- 实时告警：局部客户对查问性能有较高的要求。比方：实时统计服务异样或零碎解体的次数，并第一工夫反馈给相干负责人解决。
- 导入性能：在业务运行过程中，生成的日志数据会被保留在服务器上。在高并发的状况下，日志数据量十分宏大，因而对导入性能有较高的要求。
- 数据一致性：数据一致性对任何行业来说都是要害思考因素，只有在数据统一的根底上进行指标计算，能力确保统计后果的准确性。
- 部署简略：因 360 企业平安浏览器次要为政企提供服务，通常采纳私有化部署的形式，这意味着服务和客户端将齐全集成在客户本地环境中。这就要求架构要足够精简，在确保在实现性能的同时，尽可能升高部署的复杂度。
架构 1.0：基于 Elasticsearch 的简洁日志解决架构
为满足对立运维治理平台的要求，咱们首先设计了一个简洁的日志解决架构。在该架构中，浏览器客户端发动申请后，通过业务层的服务 API 解决，日志数据在服务应用层进行解决，并最终存储于 MySQL、Elasticsearch 和 Redis 等数据存储系统中。
MySQL 次要存储业务相干数据以及大量计算实现的统计数据，用于治理平台中随查随用，Elasticsearch 次要用于存储日志类数据，以反对数据实时剖析和检索需要。Redis 次要用于存储热数据和治理平台的配置信息，以进步接口性能。
在架构 1.0 应用过程中，咱们发现几个痛点问题：
- Elasticsearch 索引不反对变更：Elasticsearch 一旦创立索引，不再反对更改，分词参数和字段类型也无奈批改。当提出新的业务需要时，就须要创立新的索引，并须要编写脚本将历史数据迁徙至新索引中，这就带来较高的操作和开发成本。
- Elasticsearch 聚合性能差：当执行简单的聚合查问或存在大量聚合工作时，Elasticsearch 须要为聚合操作调配大量的内存，如果计算资源有余，会造成聚合操作执行工夫过长，从而影响查问效率。
架构 1.1：引入 Apache Doris 1.0 版本
据前文可知，Elasticsearch 聚合性能较差，而在理论的应用场景中存在大量需深度聚合的数据表，因而咱们决定对架构进行降级改良。在正式降级之前，咱们对多个数据分析组件进行调研，并发现 Apache Doris 具备许多个性合乎咱们的需要，无望解决以后存在的问题。以下列举咱们较为关注的特点：
- 反对多种数据模型：反对 Aggregate、Unique、Duplicate 三种数据类型，其中 Aggregate Key 模型可能在疾速且精确的写入数据的同时进行数据聚合，即通过提前聚合大幅晋升查问性能。
- 采纳列式存储：Doris 按列进行数据编码压缩和读取，从而实现极高压缩比，该存储形式也缩小了大量非相干数据的扫描，进步 IO 和 CPU 资源的利用率。
- 反对物化视图：既能对原始明细数据进行任意维度的剖析，也能疾速对固定维度进行剖析查问，对于查问性能的晋升有显著的成果。
基于这些劣势，咱们在架构 1.0 的根底上先引入了 Apache Doris 1.0 版本，并将其作为数据存储层。Apache Doris 在架构中次要代替 Elasticsearch 进行实时计算，并将相干统计报表的计算和存储都迁徙到 Doris 中来进行，由 Doris 提供对立数据服务。
不仅如此，Apache Doris 的引入也带来了许多性能和效率晋升：
- 开发效率晋升：相比之前须要编写简单的 Elasticsearch 聚合代码，当初只须要创立聚合 Key，Doris Aggregate 模型即可实现聚合计算，极大晋升了数据开发的效率。
- 数据一致性保障：Doris 提供了对立的数仓服务，数据的导入、计算和存储均可在 Doris 中实现，简化了数据处理的链路和复杂度，对数据一致性的保障起关键作用。
- 查问性能晋升：当面对 4000 万条数据的聚合查问时，Elasticsearch 须要 6-7 秒能力返回查问后果，而 Doris 在 1 秒内就能实现查问并返回后果，查问性能显著晋升。
除此之外，Apache Doris 在语法结构上也有显著的劣势，这为客户在排查问题时提供了极大的便当、缩短了排查工夫。为更直观体现其便捷性，咱们对 Elasticsearch 和 Apache Doris 的语法结构进行比照。
在 Elasticsearch 中，聚合须要多层 group by，因为其语法与规范 MySQL 协定存在差别，因而语法结构绝对简单。
"aggregations": {
"group_day_time": {
"aggregations": {
"group_urltitle": {
"aggregations": {
"group_app_id": {
"aggregations": {
"group_url_host": {
"aggregations": {
"group_org_id": {
"terms": {
"field": "org_id",
"size": 200000
}
}
},
"terms": {
"field": "url_host",
"size": 200000
}
}
},
"terms": {
"field": "app_id",
"size": 10000
}
}
},
"terms": {
"field": "urltitle",
"size": 100000
}
}
},
"date_histogram": {
"calendar_interval": "day",
"field": "day_time"
}
}
}
当用户遇到问题时，咱们须要向客户发送大量的 Curl 命令来排查问题。然而，对于没有 Elasticsearch 应用教训的用户来说，语法调试难度十分高。
curl -u elastic:elastic 'http://127.0.0.1:9200/user_log*/_search?ignore_unavailable=true&pretty=true' -H 'Content-Type: application/json' -d '{"aggregations":{"group_day_time":{"aggregations":{"group_sysname":{"aggregations":{"group_app_id":{"aggregations":{"group_url_host":{"aggregations":{"group_org_id":{"terms":{"field":"org_id","size":200000}}},"terms":{"field":"url_host","size":200000}}},"terms":{"field":"app_id","size":10000}}},"terms":{"field":"sysname","size":100000}}},"date_histogram":{"calendar_interval":"day","field":"day_time"}}},"query":{"bool":{"filter":[{"range":{"day_time":{"from":"2022-06-02T00:00:00+08:00","include_lower":true,"include_upper":true,"to":null}}},{"range":{"day_time":{"from":null,"include_lower":true,"include_upper":false,"to":"2022-06-03T00:00:00+08:00"}}}]}}}'
引入 Apache Doris 后， 在创立表时能够应用 Aggregate Key 模型来定义聚合条件。且 Apache Doris 反对规范 MySQL，不仅语法更加简洁、查问也更加不便，如呈现问题，只有相熟 MySQL 的根本语法，便能够疾速进行问题排查。
CREATE TABLE user_log
(
day_time datetime DEFAULT NULL COMMENT‘工夫 ',
org_id int(10) DEFAULT‘0’COMMENT‘组织 id',
app_id int(10) DEFAULT‘0’COMMENT‘利用 id',
url_host varchar(255) DEFAULT NULL COMMENT 'url 地址‘,
urltitle varchar(255) DEFAULT ''COMMENT'title',
pv_count BIGINT SUM DEFAULT "0" COMMENT "总数"
) Aggregate KEY(day_time,org_id,app_id, url_host, urltitle)
PARTITION BY RANGE (day_time) ()
DISTRIBUTED BY HASH(day_time) BUCKETS 10
SELECT day_time,org_id，app_id，url_host，urltitle，sum(pv_count) as pv
FROM user_log
WHERE day_time >= "2022-06-02" and day_time <= "2022-06-03"
GROUP BY day_time,org_id，app_id，url_host，urltitle
ORDER BY uv desc;
而在架构 1.1 版本中，咱们依然面临一些挑战和问题：
- Bitmap 问题：在解决大规模数据时，对于字符串类型基数很高的数据，如果间接应用 Bitmap，计算性能无奈很好满足。
- 数据准确性问题：当对 75 万根底数据测试时，Bitmap 哈希抵触可能导致数据准确性问题。
- 存储空间：因为 Elasticsearch 还未被 Apache Doris 全副替换，目前零碎仍存在存储资源耗费较大的问题。
架构 2.0：引入 Apache Doris 2.0，全面代替 Elasticsearch
针对上述问题，咱们踊跃寻找下一步的解决方案。在与 Apache Doris 社区技术同学沟通过程中，咱们得悉 Apache Doris 2.0 版本在日志剖析场景上有了全面增强：
- 反对 JOSN 格局：Apache Doris 2.0 反对 JSON 格局，在咱们的数据中有大量采纳 JSON 格局的数据，该能力使咱们可能更不便地进行数据存储。
- 反对局部列更新：2.0 版本反对了局部列更新性能，无需对整个数据集进行更新，这种准确的更新形式大大降低了计算资源的耗费，进步了数据更新效率。
- 反对倒排索引：2.0 版本反对倒排索引，能够满足字符串类型的全文检索和一般数值 / 日期等类型的等值、范畴检索，更加合乎日志数据分析的场景的查问需要。
基于此，咱们引入了 Apache Doris 2.0 版本，实现了从架构 1.1 到架构 2.0 的降级。在架构 2.0 中，咱们对整体架构进行了调整，以辨别日志服务、根底服务与其余服务，这也使得零碎更加清晰和易于治理。
在新架构中， 咱们应用 Apache Doris 齐全代替了 Elasticsearch，由 Apache Doris 对立提供日志检索和实时报表服务。此外，咱们还对报表导入形式进行了改良，晚期的做法是通过 Insert Into 拼接 MySQL 的形式进行导入，而新架构中引入了 FileBeat 工具，使报表数据的导入和导出更加高效便捷。
具体数据导入流程为 ：当用户在浏览器中拜访利用网址时，须要采集的信息会被记录在本地，当采集工夫或数量达到设定阈值时，这些信息将通过接口上报给日志服务。日志服务的次要工作是对数据进行荡涤和填充，以补充浏览器空缺数据，并生成一条 JSON 存到服务器的日志文件。当轮询脚本触发时，将对日志文件进行读取，数据通过 Stream Load 将数据同步到 Doris 中。
01 简略易用，晋升开发效率
Apache Doris 学习成本低、轻松上手。Apache Doris 兼容 MySQL 协定，反对应用规范 SQL 语言进行数据查问和操作，使得开发人员能够不便地进行简单的数据查问和聚合操作。相比之下，Elasticsearch 的 DSL 是一种基于 JSON 的查询语言，对于不相熟 DSL 开发人员来说，齐全把握该语法须要肯定的学习曲线，具备较高的学习和应用门槛。
咱们通过以下示例代码来展现应用 GOM 实现 Doris 查问性能的代码实现。从代码示例可知，对于相熟代码治理、代码标准、代码品质和前期保护等方面的人来说，这种写法十分不便。对于新退出的共事来说，进行代码审查也变得非常容易，相较于以前的 Elasticsearch，应用 Apache Doris 能够节俭大量的开发工夫。
02 正当进行表设计，满足查问秒级响应
在表设计中，咱们次要应用了 Aggregate Key 聚合模型和 Duplicate Key 明细模型。聚合模型用于统计浏览器相干指标，如用户 PV（页面访问量）和 UV（独立访客数）以及利用拜访 PV 和 UV 等数据；明细模型次要用于存储日志数据，以便进行用户或设施的留存剖析。
在理论的利用中，大部分报表抉择聚合模型进行实时计算，SUM 和 BITMAP 为罕用的聚合计算，其中，SUM 约有 100+ 个聚合维度，BITMAP 约有 20-30 个维度，因波及维度较多，咱们将它们散布在不同的表中。小局部报表采纳明细模型，咱们也在明细模型上建了 Rollup 来进步查问速度。
具体字段设置为：
- UV 采纳 BITMAP 聚合模型，聚合函数
BITMAP_UNION - PV 采纳 BIGINT 类型，聚合函数
SUM - 留存：
BITMAP_INTERSECT - 众数：TOPN
SUM 性能评估
如上所述，咱们在表创立过程中宽泛应用了 Bitmap 和 SUM 函数。为了评估 SUM 函数的性能，咱们对一张约有 54 亿行数据的表进行测试，并在创立 Rollup 后进行查问， 结果显示查问耗时为 0.32 秒， 这表明 SUM 函数在解决大规模数据里体现出良好的性能，满足咱们对查问时延的要求。
select count(*) from testorg; # 5400179000
select org_id,sum(app_pv_count) from org_stats where os_type="windows" and day_time > "2023-07-01" and org_id >0 group by org_id; # 0.32s
Bitmap 性能评估
对于 Bitmap 而言，Bitmap 的长度绝对于数据行数更为重要。随着 Bitmap 数据量的增大，Bitmap Union Count 的执行速度可能变慢。
为验证其性能，咱们对一张蕴含 9 万行数据的表进行 IP 测试，IP 数量始终保持在 75 万以上，即每个 Bitmap 的长度大于等于 75 万。在这个 9 万 *75 万的数据集上，咱们进行 Bitmap Union Count 计算，将 IP 转换为整数类型， 查问工夫约为 0.5 秒，总体而言查问性能较好，合乎性能要求。
select count(*) from testlog; # 90000
select app_id,day_time,bitmap_union_count(ip_pv_count) from test group by app_id,day_time ; #0.5s
03 相较 Elasticseach，存储老本升高 60%
在引入 Apache Doris 之后，咱们对 Doris 和 Elasticseach 的存储空间占用进行了比照。
咱们以一天数据量为例进行测试，大概 606 GB 的 JSON 日志数据。当咱们将这些数据存储到 Doris 中时，其所占用存储空间仅为 170 GB，压缩比达到 1:3.6。
与此相比，雷同规模的数据存储到 Elasticsearch 中则须要 391 GB 的存储空间，远超过 Apache Doris 所需的空间， 降级后存储老本升高 60%。
收益总结
咱们将零碎架构从 Elasticsearch 降级为 Apache Doris 之后，具体获得的收益如下：
- 将日志检索和报表剖析对立到一个零碎中，Doris 2.0 版本在减少倒排索引后，能同时满足这两个场景，从而缩短了数据处理的链路和复杂度，显著进步了数据处理的效率。
- 聚合剖析性能失去数量级的晋升，之前在 Elasticseach 中须要近 10 秒能力实现聚合查问，而在 Doris 中不到 1 秒就能实现，聚合剖析效率至多晋升 100%。
- Doris 提供了高效的数据压缩效率，相较于 Elasticseach，同一份数据的存储资源老本升高了 60%。
- Doris SQL 相比 Elasticseach DSL 更加简略易用，可能大幅晋升开发效率和问题排查的效率。
不仅如此，Apache Doris 的引入帮忙咱们实现了经营可视化治理，提供了浏览器多种指标的实时监控，以领导业务部门下一步动作：
- 在平安方面，当解体次数达到设定阈值时，零碎会通过邮件告诉相干人员，以便排查浏览器解体的起因。还可对登录次数进行统计，无效监测是否存在内部人员试图攻打接口。
- 在绩效统计方面，可对利用拜访数据进行统计，以帮忙咱们评估工作状况，从而更好地安顿工作。
- 优化流量损耗和磁盘占用：通过对页面中 JS、CSS、Image 等资源的统计，可无效地发现拜访流量和资源大小并进行优化，以缩小流量损耗和磁盘空间应用，从而实现降本提效。
- 提供业务零碎衰弱报告：可精确监测利用 Web 页面所援用的资源、资源加载时长以及异常情况等要害信息，并依据这些信息生成利用衰弱报告，基于报告可能帮忙企业实现业务零碎的优化。
将来布局
因为 360 企业平安浏览器面向企业提供服务，将来咱们着重关注并摸索以下方向，以更好地满足客户的需要。
- 冷热数据拆散：冷热数据拆散可能在降低成本的同时提高效率，将来咱们打算将客户的冷数据存储到 S3 等存储介质，将热数据存储在相应的数据磁盘，以进步存储空间的利用率。
- Doris Manager 部署集成：将来咱们打算集成 Doris Manager，以便客户可能直观便捷地排查和发现问题，监控集群的应用状况。