Apache Doris实际应用实践录
2023-05-19 11:50:58 
阿炯
天眼查基于Apache Doris构建统一实时数据仓库
奇安信基于Apache Doris升级日志安全分析系统
长安汽车基于 Apache Doris 的车联网数据分析平台建设实践
Apache Doris 在网易日志和时序场景的实践
天眼查基于Apache Doris构建统一实时数据仓库
随着天眼查近年来对产品的持续深耕和迭代，用户数量也在不断攀升，业务的突破更加依赖于数据赋能，精细化的用户/客户运营也成为提升体验、促进消费的重要动力。在这样的背景下正式引入 Apache Doris 对数仓架构进行升级改造，实现了数据门户的统一，大大缩短了数据处理链路，数据导入速率提升 75%，500 万及以下人群圈选可以实现毫秒级响应，收获了公司内部数据部门、业务方的一致好评。数据秒级写，查询毫秒应。
作者 | 天眼查实时计算负责人-王涛(2023年5月)
天眼查是中国领先的商业查询平台，以公开数据为切入点、以关系为核心的产品，帮助传统企业或个人降低成本，为防范化解金融风险方面提供了产品化的解决方案。目前已收录全国3亿多家社会实体信息，300多种维度信息及时更新，致力于构建商业安全，从而实现“公平看清世界”。
业务背景
天眼查的数据仓库主要服务于三个业务场景，每个场景都有其特点和需求，具体如下：
1).亿级用户人群圈选：人群圈选场景中目前有 100+ 人群包，我们需要根据 SQL 条件圈选人群包，来支持人群包的交并差、人群包实时圈选和人群包更新通知下游等需求。例如：圈选出下单未支付超过 5 分钟的用户，我们通过用户标签可以直观掌握用户支付状态，为运营 & 营销团队提供更精细化的人群管理服务，从而提高转化率。
2).多元活动支撑的精准营销：该场景目前支持了 1000 多个指标，可支持即席查询，根据活动效果及时调整运营策略。例如在“开工季”活动中，需要为数据分析 & 运营团队提供数据支持，从而生成可视化的活动驾驶舱。
3).高并发的 C 端分析数据：该场景承载了 3 亿+实体（多种维度）的数据体量，同时要求实时更新，以供用户进行数据分析。
原有架构及痛点
为满足各业务场景提出的需求，我们开始搭建第一代数据仓库，即原有数仓：
在原有数仓架构中， Hive 作为数据计算层，MySQL、ES、PG 作为数据存储 层，我们简单介绍一下架构的运行原理：
1).数据源层和数据接入层：MySQL 通过 Canal 将 BinLog 接入 Kafka、埋点日志通过 Flume 接入 Kafka，最后由 DataX 把 Kafka 中的数据接入数据计算层 Hive 中；
2).数据计算层：该层使用 Hive 中的传统的数仓模型，并利用海豚调度使数据通过 ODS -> DWD -> DWS 分层，最后通过 DataX 将 T+1 把数据导入到数据存储层的 MySQL 和 ES 中。
3).数据存储层：MySQL 主要为 DataBank、Tableau、C 端提供分析数据，ES 用于存储用户画像数据，PG 用于人群包的存储（PG 安装的插件具有 Bitmap 交并差功能），ES、PG 两者均服务于 DMP人群圈选系统。
问题与挑战
依托于原有架构的投入使用，初步解决了业务方的需求，但随着天眼查近年来对产品的持续深耕和迭代，用户数量也在不断攀升，业务的突破更加依赖于数据赋能。精细化的用户/客户运营也成为提升体验、促进消费的重要动力。在这样的背景下，原有架构的缺点逐渐暴露：
1).开发流程冗长：体现在数据处理链路上，比如当面对一个简单的开发需求，需要先拉取数据，再经过 Hive 计算，然后通过 T+1 更新导入数据等，数据处理链路较长且复杂，非常影响开发效率。
2).不支持即席查询：体现在报表服务和人群圈选场景中，所用的指标无法根据条件直接查询，必须提前进行定义和开发。
3).T+1 更新延迟高：T+1 数据时效性已经无法提供精确的线索，主要体现在报表和人群圈选场景上。
4).运维难度高：原有架构具有多条数据处理链路、多组件耦合的特点，运维和管理难度都很高。
理想架构
基于以上问题，我们决定对架构进行升级改进，在正式升级之前，我们希望未来的架构可以做到以下几点：
1).原架构涉及 MySQL 、PG、ES 等多个组件，并为不同应用提供服务；我们希望未来的架构可以兼容 MySQL 协议，实现低成本替换、无缝衔接以上组件。
2).支持即席查询且性能优异，即席查询能够给业务方提供更灵活的表达方式，业务方可以从多个角度、多个维度对数据进行查询和分析，更好地发现数据的规律和趋势，帮助业务方更精准备地做出决策。
3).支持实时聚合，以减轻开发负担并保证计算结果的准确性。
4).统一数据出口，原架构中数据出口不唯一，我们希望未来的架构能更统一数据出口，缩短链路维护成本，提升数据的可复用性。
5).支持高并发， C 端的实时分析数据需要较高的并发能力，我们希望未来的架构可以高并发性能优异。
技术选型
考虑到和需求的匹配度，我们重点对 OLAP 引擎进行了调研，并快速定位到 ClickHouse 和 Apache Doris 这两款产品，在深入调研中发现 Doris 在以下几个方面优势明显，更符合我们的诉求：
1).标准 SQL：ClickHouse 对标准 SQL 支持有限，使用中需要对多表 Join 语法进行改写；而 Doris 兼容 MySQL 协议，支持标准 SQL ，可以直接运行，同时 Doris 的 Join 性能远优于 ClickHouse。
2).降本增效：Doris 部署简单，只有 FE 和 BE 两个组件，不依赖其他系统；生态内导数功能较为完备，可根据数据源/数据格式选择导入方式；还可以直接使用命令行操作弹性伸缩，无需额外投入人力；运维简单，问题排查难度低。相比之下，ClickHouse 需要投入较多的开发人力来实现类似的功能，使用难度高；同时 ClickHouse 运维难度很高，需要研发一个运维系统来支持处理大部分的日常运维工作。
3).并发能力：ClickHouse 的并发能力较弱是一个潜在风险，而 Doris 并发能力更占优势，并且刚刚发布的 2.0 版本支持了 。
4).导入事务：ClickHouse 的数据导入没有事务支持，无法实现 Exactly Once 语义，如导数失败需要删除重导，流程比较复杂；而 Doris 导入数据支持事务，可以保证一批次内的数据原子生效，不会出现部分数据写入的情况，降低了判断的成本。
5).丰富的使用场景：ClickHouse 支持场景单一，Doris 支持场景更加丰富，用户基于 Doris 可以构建用户行为分析、AB 实验平台、日志检索分析、用户画像分析、订单分析等应用。
6).丰富的数据模型：Doris 提供了Unique、Duplicate、Aggregate 三种数据模型，可以针对不同场景灵活应用不同的数据模型。
7).社区响应速度快：Doris 社区的响应速度是其独有特色，SelectDB 为社区组建了一直完备的社区支持团队，社区的快速响应让我们少走了很多歪路，帮助我们解决了许多问题。
新数仓架构
经过对 Doris 进行综合评估，我们最终决定采用 Doris 对原有架构进行升级优化，并在架构层级进行了压缩。新的架构图如下所示：
在新架构中，数据源层和数据接入层与原有架构保持一致，主要变化是将 Doris 作为新架构的数据服务层，统一了原有架构中的数据计算层和存储层，这样实现了数据门户的统一，大大缩短了数据处理链路，解决了开发流程冗长的问题。同时，基于 Doris 的高性能，实现了即席查询能力，提高了数据查询效率。另外，Flink 与 Doris 的结合实现了实时数据快速写入，解决了 T+1 数据更新延迟较高的问题。除此之外，借助于 Doris 精简的架构，大幅降低了架构维护的难度。
数据流图
缩短数据处理链路直接或间接地带来了许多收益。接下来，我们将具体介绍引入 Doris 后的数据流图。
总体而言，数据源由 MySQL 和日志文件组成，数据在 Kafka 中进行分层操作（ODS、DWD、DWS），Apache Doris 作为数据终点统一进行存储和计算。应用层包含 C 端、Tableau 和 DMP 系统，通过网关服务从 Doris 中获取相应的数据。
具体来看，MySQL 通过 Canal 把 Binlog 接入 Kafka，日志文件通过 Flume 接入 Kafka 作为 ODS 层。然后经过 Flink SQL 进行清洗、关联维表，形成 DWD 层的宽表，并生成聚合表。为了节省空间，我们将 ODS 层存储在 Kafka 中，DWD 层和 DWS 层主要与 Doris 进行交互。DWD 层的数据一般通过 Flink SQL 写入 Doris。针对不同的场景，我们应用了不同的数据模型进行数据导入。MySQL 数据使用 Unique 模型，日志数据使用 Duplicate 模型，DWS 层采用 Aggregate 模型，可进行实时聚合，从而减少开发成本。
应用场景优化
在应用新的架构之后，必须对业务场景的数据处理流程进行优化以匹配新架构，从而达到最佳应用效果。接下来以人群圈选、C端分析数据及精准营销线索为主要场景，分享相关场景流程优化的实践与经验。
一、 人群圈选
原流程（左）中，业务人员在画像平台页面上利用表的元数据创建人群圈选任务，任务创建后进行人群 ID 分配，写入到 PG 画像表和 MySQL 任务表中。接着根据任务条件定时在 ES 中查询结果，获取结果后更新任务表的状态，并把 Bitmap 人群包写入 PG。利用 PG 插件提供的 Bitmap 交并差能力操作人群包，最后下游运营介质从 PG 取相应人群包。
然而，该流程处理方式非常复杂，ES 和 PG 中的表无法复用，造成成本高、效益低。同时，原流程中的数据为 T+1 更新，标签必须提前进行定义及计算，这非常影响查询效率。
现流程（右）中，业务人员在画像平台创建人群圈选任务，后台分配人群 ID，并将其写入 MySQL 任务表中。首次圈选时，根据任务条件在 Doris 中进行即席查询，获取结果后对任务表状态进行更新，并将人群包写入 Doris。后续根据时间进行微批轮询，利用 Doris Bitmap 函数提供的交并差功能与上一次的人群包做差集，如果有人群包更新会主动通知下游。
引入 Doris 后，原有流程的问题得到了解决，新流程以 Doris 为核心构建了人群圈选服务，支持人群包实时更新，新标签无需提前定义，可通过条件配置自助生成，减少了开发时间。新流程表达方式更加灵活，为人群包 AB 实验提供了便捷的条件。流程中采用 Doris 统一了明细数据和人群包的存储介质，实现业务聚焦，无需处理多组件数据之间的读写问题，达到了降本增效的终极目标。
二、C端分析数据及精准营销线索场景
原流程：在原流程中，如果业务提出新需求，需要先发起需求变更，再经过评审、排期开发，然后开始对 Hive 中的数据模型进行开发并进行测试，测试完成后进行数仓上线，配置 T+1 调度任务写入 MySQL，最后 C端和精准营销系统对 MySQL 数据进行读取。原流程链路复杂，主要体现在流程长、成本高、上线周期长。
现流程：当前明细数据已经在 Doris 上线，当业务方发起需求变更时，只需要拉取元数据管理平台元数据信息，配置查询条件，审批完成后即可上线，上线 SQL 可直接在 Doris 中进行即席查询。相比原流程，现在的流程大幅缩短了需求变更流程，只需进行低代码配置，成功降低了开发成本，缩短了上线周期。
优化经验
为了规避风险，许多公司的人群包user_id是随机生成的，这些user_id相差很大且是非连续的。然而，使用非连续的user_id进行人群圈选时，会导致 Bitmap 生成速度较慢。因此生成了映射表，并生成了连续稠密的 user_id。当使用连续user_id圈选人群时，速度较之前提升了 70%。
用户 ID 映射表样例数据：从图可知原始用户 ID 由多位数字组合，并且 ID 很 稀疏（用户 ID 间相差很大），而连续用户 ID 则 从1开始，且 ID 很稠密。
案例展示：
1、用户 ID 映射表：
用户 ID 映射表将用户 ID 作为唯一键模型，而连续用户 ID 则通过用户 ID 来生成，一般从 1 开始，严格保持单调递增。需要注意的是，因为该表使用频 繁，因此将in_memory设置为true，直接将其缓存在内存中。
2、人群包表
人群包表是以用户标签作聚合键的模型，假设以 user_id 大于 0、小于 2000000 作为圈选条件，使用原始 user_id 进行圈选耗费的时间远远远大于连续稠密 user_id 圈选所耗时间。
如下图所示，左侧使用tyc_user_id圈选生成人群包响应时间：1843ms，右侧使用使tyc_user_id_continuous圈选生成人群包响应时间：543ms，消耗时间 大幅缩短。
规模与收益
引入 Doris 后，我们已经搭建了 2 个集群，承载的数据规模正随着迁移的推进而持续增大。目前已经处理的数据总量已经达到了数十TB，单日新增数据量已经达到了数十亿条，而数据体量还在持续增长中。此外在 Doris 上运行的指标和人群包数量已经超过了 500，分别涵盖了商查、搜索、运营、用户和营收五大类指标。
Doris 的引入满足了业务上的新需求，解决了原有架构的痛点问题，具体表现为以下几点：
1).降本增效：Doris 统一了数据的门户，实现了存储和计算的统一，提高了数据/表的复用率，降低了资源消耗。同时，新架构优化了数据到 MySQL、ES 的流程，开发效率得到有效提升。
2).导入速率提升：原有数据流程中，数据处理流程过长，数据的导入速度随着业务体量的增长和数据量的不断上升而急剧下降。引入 Doris 后，得益于 Broker Load 优秀的写入能力，使得导入速率提升了 75%以上。
3).响应速度：Doris 的使用提高了各业务场景中的查询响应速度。例如在人群圈选场景中，对于 500 万及以下的人群包进行圈选时，能够做到毫秒级响应。
未来规划
如前文所讲，Apache Doris 的引入解决了许多架构及业务上的难题，初见成效，同时也收获了公司内部数据部门、业务方的一致好评，未来我们将继续探索，基于 Doris 展开更深度的应用，不久的将来，我们将重点推进以下几个方面工作：
1).离线指标实时化：将更多的指标从离线转为实时，提供更及时的数据服务。
2).搭建数据血缘系统：将代码中的血缘关系重新定义为可视，全面构建数据血缘关系，为问题排查、链路报警等提供有效支持。
3).探索批流一体路线：从使用者的角度思考设计，实现语义开发层的统一，使数据开发更便捷、更低门槛、更高效率。
在此特别感谢 SelectDB 团队，作为一家基于 Apache Doris 的商业化公司，为社区投入了大量的研发和用户支持力量，在使用过程中遇到任何问题都能及时响应，为我们降低了许多试错成本。
奇安信基于Apache Doris升级日志安全分析系统，查询平均提速700%
本节导读：数智时代的到来使网络安全成为了不可忽视的重要领域。奇安信作为一家领先的网络安全解决方案领军者，致力于为企业提供先进全面的网络安全保护，其日志分析系统在网络安全中发挥着关键作用，通过对运行日志数据的深入分析，能够对漏洞和异常行为生成关键见解，帮助企业建立有效的防御策略。本文将深入探讨奇安信在网络安全与日志分析解决方案的关键优势，了解基于 Apache Doris 构建的全新一体化日志存储分析平台如何实时监测和分析日志事件，加强对可疑活动的追踪与应对，提升系统安全性与快速响应能力。
（作者｜奇安信 服务端技术专家：舒鹏，本节转自SelectDB空间）
奇安信是中国企业级网络安全市场的领军者，专注于为政府和企业用户提供新一代网络安全产品和服务。目前核心产品天擎终端安全系统在国内已有 4000 万政企用户部署、全国部署服务器超过 100 万台、服务超 40 万大型机构。作为网络安全国家队，奇安信立志为国家构建安全的网络空间，在终端安全、云安全、威胁情报、态势感知等领域的技术研发持续领先。
随着现代企业数字化转型的不断深化，大数据、物联网、5G等创新技术的广泛应用加速了企业的数字化转型步伐，这使得原先的网络边界被打破，多源多样的终端设备成为了新的安全边界。
网络安全系统的防御性能与日志分析密不可分，当网络设备、操作系统以及应用程序在运行时，会产生大量的运行日志，其中蕴涵了丰富的数据价值。最大化地利用运行日志数据能够有效检测内部系统的安全风险、还原攻击路径、回溯攻击入口等，可以进一步提升系统安全性、保障企业网络安全，因此日志分析系统在其中发挥着不可或缺的作用。
本节将介绍奇安信在网络安全场景中，基于 Apache Doris 进行架构升级迭代并建设全新一体化日志存储分析平台的实践经验。
早期架构痛点与需求
安全日志平台的架构如下图所示，原始的设备、系统日志首先经过业务处理环节，包括归一化和扩充维度等操作。这些处理步骤旨在将来自不同设备和系统日志转化为半结构化 JSON 格式的安全日志，并将其写入 Kafka 消息队列中。
最新的日志会被写入实时数仓，安全分析师可以通过分析平台对实时数仓中的最新数据进行交互式查询，从而进行攻击研判和追踪溯源等安全分析工作。另外，离线数仓用于保存历史数据，以支持长周期数据挖掘的离线分析。
在以上日志数据平台中，日志数据的写入速度与查询分析效率对上层业务人员进行实时安全事件监控和分析至关重要，这也是当前我们所面对的最主要痛点。
一方面，每天所生产的安全日志数据达到千亿级，写入压力很大。最初我们选择使用某 Apache Doris 的 Fork 版本来存储日志数据，但在实际应用中，随着每天新增日志量的不断增长，入库速度逐渐降低、集群写入压力过大、高峰期数据积压严重，对集群稳定性造成很大影响，并且数据压力较高时、查询效率也达不到有效果的保证。随后我们对集群进行多次扩容，从 3 节点逐步扩容到 13 节点，尽管机器成本已经大幅超过预期、但写入效率并没有发生本质的改善。
另一方面，业务人员在进行安全日志分析时，经常需要对文本字段（如 URL，payload 等）进行关键字匹配。在原系统中只能通过 SQL LIKE 进行全量扫描和暴力匹配，整体查询性能不佳，千亿级数量的数据表查询耗时接近分钟级甚至达到数百秒，即便按照时间区间过滤大量数据后、查询耗时仍在数秒到数十秒。一旦遇到并发查询性能还会进一步恶化，很难满足日常安全分析的需求。
除写入和查询效率以外，运维监控也是我们的痛点之一，该厂商提供的可视化运维系统需要商业 License 授权，对于开源社区用户不友好，集群维护处于原始手动状态。
架构选型与升级的思考
为了解决过去版本的痛点、满足更高效实时的日志分析诉求，我们亟需对早期系统升级改造。同时面向安全日志分析场景，我们也对新日志分析平台的架构提出了更高的要求：
1.写入性能：系统一方面需要支持海量病毒查杀事件等数据实时写入与存储，以满足分析时效性的要求，另一方面需要基于日志数据 Schema Free 特点支持丰富数据类型的写入与变更。
2.查询性能：由于日志查询分析会涉及对文本类型、JSON 数据进行全文检索、日期或普通数值的范围查询，系统需要对字符串提供模糊查询的能力，还需要支持能够灵活创建且类型丰富的索引，以加速筛选过滤海量数据，提升查询效率。
3.存储成本：设备每天产生大量的日志数据，为了挖掘这些有价值的日志信息，业务人员还需要从数据中进行筛选和分析，并对异常日志回溯追踪，这使得日志存储的规模很大、存储周期相对较长，因此高性价比的存储成本也是系统构建的目标之一。
4.运维成本：系统自身的运维简易程度以及是否具备合适的管控工具都能帮助我们进一步提效。
在持续关注业界 OLAP 数据库的过程中，我们发现 Apache Doris 最近一年的发展非常迅猛，最新的 2.0 版本也把日志存储和检索分析作为新的发力点，推出了倒排索引、NGram BloomFilter 索引等特性，对关键词检索、LIKE 文本匹配的性能有大幅提升，与我们文本检索慢的痛点需求非常契合，因此开启了新架构的升级之旅。
架构升级之旅
上文中提到，在整体架构选型过程中我们主要关注的地方包括写入性能、查询性能、数据存储成本以及运维成本等方面。在架构升级过程中，我们选择了 Apache Doris 当时最新发布的 2.0 版本，具体升级收益如下。
1、写入性能提升超 200%
为了评估 Apache Doris 写入的极限性能，我们初期使用与线上系统相同配置的 3 台服务器，从 Kafka 接入线上真实写入流量，测试期间当 CPU 写入效率跑满至 100% 时写入吞吐达到了 108 万条 /s、1.15 GB/s，写入数据的可见性延迟保持在秒级。
而线上运行的原系统集群规模达 13 台，在同样的数据写入情况下，CPU 利用率 30% 左右、写入吞吐仅 30 万条/s，并且存在高峰期 CPU Load 高、系统响应慢的问题。
根据测试结果，我们预估架构替换为 Apache Doris 后保持同样 30% 的 CPU 占用，只需要 3 台服务器即可满足写入需求，机器资源成本至少节约 70%。值得注意的是，在测试中对 Apache Doris 表中一半字段开启了倒排索引，如果不开启倒排索引的话，写入性能在之前基础上还能够再提升 50% 左右。
2、存储成本降低近 40%
在看到写入性能的大幅提升后，Apache Doris 存储空间占用也给我们带来了惊喜。在开启倒排索引的前提下，存储空间比原系统不具备倒排索引还要略低，压缩比从 1 : 4.3 提高至 1 : 5.7。
通过对比 Apache Doris 在磁盘上存储的文件大小，同一份数据的索引文件 (.idx) 与数据文件 (.dat) 大小相差无几。换言而之，增加索引后 Doris 数据膨胀率大约在 1 倍左右，与许多数据库和检索引擎 3-5 倍的膨胀率相比，Doris 的数据存储空间占用相对较低。经过研究发现，Apache Doris 采用了列式存储和 ZSTD 压缩算法来优化存储空间占用。Doris 将原始数据和倒排索引都以列的形式存储，使同一列的数据被存储在相邻位置，从而实现了更高的压缩率。
ZSTD 是一个优秀的新型压缩算法，使用了智能优化算法，相较于常见的 GZIP 算法， ZSTD 具有更高的压缩率和更快的解压速度，尤其在处理日志场景时表现非常出色。
3、查询性能平均提升 690%
对于业务最关注的查询性能，我们从线上查询日志进行去重后分析出 79 条 SQL，在同一天总数据（1000 亿条）、同样规模的集群（10 BE 节点）上对比测试 Apache Doris 与原系统的查询耗时。
发现与原系统相比，所有的查询语句均有明显提升，整体查询性能提升近 7 倍，有 26 条 SQL 查询语句性能提升 10 倍以上，其中 8 条 SQL 查询提升 10-20 倍、14 条 SQL 查询提升 20-50 倍、还有 4 条 SQL 查询提升 50 倍以上。最大差异的一条 SQL 查询语句为 Q43，在原系统中执行时间接近一分钟，在 Apache Doris 中仅需不到 1 秒，其性能差异高达到 88 倍。
针对性能提升幅度高的查询，我们进行了对比分析并发现了其中几个共同点：倒排索引对关键词查找的加速：Q23、Q24、Q30、Q31、Q42、Q43、Q50 等
-- 例如q43 提升88.2倍
SELECT count() from table2
WHERE ( event\_time >= 1693065600000 and event\_time < 1693152000000)
AND (rule\_hit\_big MATCH 'xxxx');
这种基于倒排索引进行关键词检索的技术，相较于基本的暴力扫描后进行文本匹配具有显著的优势，一方面极大地减少了需要读取的数据量；另一方面，在查询过程中无需进行文本匹配操作，因此查询效率往往提升一个数量级甚至更高。
NGram BloomFilter 索引对 LIKE 的加速：Q75、Q76、Q77、Q78 等
-- 例如q75 提升44.4倍
SELECT * FROM table1
WHERE ent_id = 'xxxxx'
AND event_date = '2023-08-27'
AND file_level = 70
AND rule\_group\_id LIKE 'adid:%'
ORDER BY event_time LIMIT 100；
对于要查找的非一个完整关键词的场景，LIKE 仍然是有用的查询方式，Apache Doris 的 NGram BloomFilter 索引能对常规的 LIKE 进行加速。
NGram BloomFilter 索引与普通 BloomFilter 索引不同，它不是将整个文本放入 BloomFilter ，而是将文本分成连续的子串，每个子串长度为 n ，并将他们放入 NGram BloomFilter 中。对于 cola LIKE '%pattern%' 的查询，将'pattern' 按照同样的方式分成长度为 n 的子串，判断每个子串在 BloomFilter 中是否存在，如果有一个子串不存在，则说明 BloomFilter 对应的数据块中没有跟'pattern' 匹配的数据块，因此通过跳过数据块扫描的步骤，达到加速查询的效果。
满足条件的最新 TopN 条日志明细查询优化：Q19-Q29 等
-- 例如q22，提升50.3倍
SELECT * FROM table1
where event\_date = '2023-08-27' and file\_level = 70
and ent\_id = 'nnnnnnn' and file\_name = 'xxx.exe'
order by event_time limit 100;
这种 SELECT * FROM t WHERE xxx ORDER BY xx LIMIT n 的查询，在查找满足某种条件的最新 n 条日志时使用频率非常高，Apache Doris 针对这种 SQL 查询模式进行了专门的优化，根据查询的中间状态确定排序字段的动态范围，并利用自动动态谓词下推的方式，避免读全部数据进行排序取 TopN，从而减少需要读取的数据量（有时甚至可以减少一个数量级），进而提升了查询效率。
4、可视化运维管控和可视化查询 WebUI，最大化减少运维和探索分析成本
为了提高日常集群维护的效率，我们使用了飞轮科技免费开放的可视化集群管理工具 Cluster Manager for Apache Doris （以下简称 Doris Manager ）。Doris Manager 提供的功能可以满足日常运维中集群监控、巡检、修改配置、扩缩容、升级等操作，降低登陆机器手动操作的麻烦和误操作风险。
除了管控 Apache Doris 集群之后，Doris Manager 还集成了类似 Kibana 的可视化日志探索分析 WebUI，对于习惯 ELK 日志分析的用户非常友好，支持关键词检索、趋势图展示、趋势图拖拽日期范围、明细日志平铺和折叠展示、字段值过滤等交互方便的探索式分析，跟日志场景探索下钻的分析需求很契合。
总结与规划
在跟随 Apache Doris 2.0-alpha，2.0-beta，2.0 正式版本发布的节奏，我们根据业务场景进行了详细的评测，也为社区反馈了不少优化建议，得到社区的积极响应和解决。系统经历试运行一个月之后，我们将 2.0.1 版本正式用于生产环境，替换了原系统集群，完成架构升级改造，实现了写入性能、查询性能、存储成本、运维成本等多方面收益：
1.写入性能提升 3 倍以上：目前，奇安信的日志分析平台每日平均有数千亿的新增安全日志数据，通过 Doris 的 Routine Load 能够将数据实时稳定写入库，保障数据低延迟高吞吐写入。
2.查询性能平均提升 7 倍：查询响应时间大幅减少，与之前的查询效率相比达到平均 7 倍提升，其中业务特别关注的全文检索速度达到 20 倍以上的提升，助力日志分析与网络安全运营效率。
3.高效便捷的可视化管理：Cluster Manager for Apache Doris 工具提供了可视化集群监控告警平台，满足日常集群监控等一系列操作，同时 WebUI 多种功能为分析人员提供了操作简单、使用便捷的交互式分析。总而言之，Doris 的易用性、灵活性大幅降低了开发、运维、分析人员的学习与使用成本。
后续还将在日志分析场景下探索更多 Apache Doris 的能力。我们将扩大 JSON 数据类型的相关应用，加强系统对于半结构化数据深度分析的能力。同时也非常期待 Apache Doris 2.1 版本中新增的 Variant 可变数据类型，支持存储任意结构的 JSON 数据，支持字段个数与类型的变化，让业务人员灵活定义特殊字符，以更好地实现半结构数据 Schema Free 的分析需求。
非常感谢 SelectDB 团队一直以来对我们的技术支持，助力奇安信走向 “体系化防御、数字化运营” 的网络日志安全管理，帮助客户准确识别、保护和监管网络设备与各类系统，确保业务人员在任何时候都能够安全、可信、稳定地访问数据与业务。
最后，我们也将持续参与到 Apache Doris 社区建设中，将相关成果贡献回馈社区，希望 Apache Doris 飞速发展！
长安汽车基于 Apache Doris 的车联网数据分析平台建设实践
导读：随着消费者更安全、更舒适、更便捷的驾驶体验需求不断增长，汽车智能化已成必然趋势。长安汽车智能化研究院作为长安汽车集团有限责任公司旗下的研发机构，专注于汽车智能化技术的创新与研究。为满足各业务部门的数据分析需求，长安汽车基于 Apache Doris 升级了车联网数据分析平台，支撑单日百亿级别数据实时处理，并实现十亿级别数据查询秒级响应，为长安汽车在提升用户用车体验、实时预警车辆故障、保证车辆安全驾驶等方面带来显著成果，为其在智能化方向的技术创新提供了有力支持。
作者｜长安汽车智能化研究院
智能化是汽车工业进程中的一场革命，它旨在利用大数据、人工智能、云计算、物联网等前沿数字技术，对汽车设备和系统的运行状态进行全方位的感知、分析、决策和控制，从而提高汽车的安全性、舒适性、便捷性和节能性。
长安汽车智能化研究院作为长安汽车集团有限责任公司旗下的研发机构，专注于汽车智能化技术的创新与研究，其愿景是通过持续创新和技术突破，实现汽车智能驾驶、智能网联和智能交通的全面发展，为消费者提供更安全、更便捷、更智能的出行体验，并致力于成为中国汽车智能化领域的领军企业。
实现汽车智能化的关键之一，是需要建立稳定、高效的数据平台，以承载和利用海量的车联网数据。作为智能化发展的重要支撑，长安汽车智能化研究院肩负着整个长安汽车集团车联网数据的汇聚、处理和应用工作。为满足各业务部门提出的数据支持需求，目前已经构建了车联网数据分析平台，并在业务指标分析、质量管理系统、智慧能耗、智能诊断、智慧运营等多个重点领域实现数据应用。
本文将详细介绍长安汽车车联网数据分析平台的演进历程及实践经验，分享长安汽车基于 Apache Doris 支撑单日百亿级别数据实时处理、实现十亿级别数据查询秒级响应的实践经验。此外，Apache Doris 的引入还为长安汽车在用户用车体验提升、驾驶安全保障等方面带来显著收益，为长安汽车从机电化到智能化转型发展提供有力支持。
汽车智能化所面临的挑战
近些年来，长安汽车取得了令人瞩目的销量增长成绩。1-8 月，长安汽车自主乘用车累计销量超百万辆、保持持续上升的发展势头，以深蓝、阿维塔、启源为代表的新能源系列品牌力和产品竞争力不断提升，自主新能源车累计销量约为 25.6 万辆、同比增长 102.44%，成为销量增长新动能。
在汽车销量快速攀升的背后，车联网数据更是呈现爆发式增长的态势，其中最为核心的即车辆 CAN 总线数据。CAN 即 Controller Area Network，通过 CAN 总线可以对车辆上的各类电子控制系统进行统一通信，在实际车辆运行过程中 ，CAN 总线数据是车辆安全性、可靠性和高性能的重要保证：
1.车辆系统监测和控制：CAN 总线数据可用于监测和控制系统中的各种设备和组件。传感器通过 CAN 总线发送其测量值，如温度、压力、位置等，以便其他设备或控制器实时监测和采取相应的措施。同时，控制器可以通过 CAN 总线向执行器发送控制指令，如调节阀门、驱动电机等，以实现对系统的控制。
2.车辆信息实时反馈：CAN 总线数据可用于提供实时反馈信息。例如在车辆控制系统中，传感器通过 CAN 总线传输车速、转向角度、制动状态等数据，控制器可以根据这些数据进行实时决策和调整，以确保车辆的安全性和性能。
3.数据共享和协调：CAN 总线数据允许不同设备之间进行数据共享和协调。通过 CAN 总线，不同的控制器和设备可以交换信息，共享状态和控制命令，有利于提高系统的整体性能和效率。
4.网络管理和故障诊断：CAN 总线数据用于网络管理和故障诊断。通过 CAN 总线，可以进行设备的自动识别、配置和监控，以便进行网络管理和故障排查，提高系统的可靠性和可维护性。
随着网联车销量不断增长，车辆每天将产生千亿级别的 CAN 数据，清洗处理后的数据也在 50 亿级别，面对如此庞大且持续膨胀的数据规模，如何从海量数据中快速提取挖掘有价值的信息，为研发、生产、销售等部门提供数据支持，成为当前亟需解决的问题。而想要提供良好的数据支持及服务，首先需要应对以下几大挑战：
1.大规模数据实时写入及处理：为实现智能化，汽车的车门、座椅、刹车灯设备被设置了大量的传感器，每个传感器收集一种或者多种信号数据，数据被汇聚后进一步加工处理。目前长安汽车需要支持至少 400 万辆车的链接，车联网数据每秒吞吐量已达百万级 TPS ，每日新增数据规模高达数十 TB ，且还在持续增长中。如何对数据进行实时写入成为了长安汽车首要面临的挑战。
2.准确及时的实时数据分析需求：车联网场景下数据分析通常要求实时性，快速获取分析结果是实时监控、故障诊断、预警和实时决策等服务的重要保障。例如在智能诊断中，车企需要近实时地收集相关信号数据，并快速定位故障原因。通过分析车辆传感器数据、行驶记录等，可以提前发现潜在故障，进行预防性维护，提高车辆的可靠性和安全性。
3.更加低廉的数据存储和计算成本：面对快速增长的的数据以及日益强烈的全量写入和计算需求，导致数据存储和计算成本不断攀升。这就要求数据平台具备低成本存储和计算的能力，以降低使用成本；同时需具备弹性伸缩能力，以便用户在业务高峰期快速扩容，提升海量数据计算场景的分析效率。
为给用户提供更优质的驾车体验、为业务部门提供更准确高效的数据支持，长安汽车开始对大数据平台的建设进行探索和实践。
Hive 离线数据仓库难以支撑超大规模实时数据服务
长安汽车最早以 Hive 为核心构建了数据平台架构，所处理数据包括车辆 CAN 总线数据和埋点数据，这些数据通过 4G 网络从车端传送至长安云端网关，然后由网关将数据写入 Kafka。考虑到数据量级和存储空间的限制，早期架构中的数据处理流程是将 Kafka 采集到的数据直接通过 Flink 进行处理，并通过 ETL 将结果存储到 Hive 中。下游应用使用 Spark SQL 进行逐层离线计算，并通过 Sqoop 将汇总数据导出到 MySQL 中。最终由 Hive 和 MySQL 分别为应用层提供数据服务。
尽管该架构在早期基本满足了数据处理需求，但随着车辆销量不断增长，当需要面对每天千亿级别的数据处理分析工作时，架构的问题逐步暴露出来：
1.数据时效性无法保证：Hive 的导入速度较慢，尤其在处理大规模数据时，导入时间明显增加；同时部分业务依赖 T+1 离线任务，无法满足实时数据处理需求；此外， Hive 只支持分区覆盖，不支持主键级别的数据更新，无法满足特殊场景的数据更新需求。
2.数据查询分析延迟较高：对于 10 亿级别以上大规模表查询，Hive 查询性能较慢。通过 SparkSQL 进行数仓分层运算时，启动和任务执行时间较长，对查询响应也会产生影响。此外，数据看板、BI 展示应用无法直接从 Hive 中查询，需要将 Hive 中数据导出到 MySQL 中，由 MySQL 提供服务，受限于 Hive 导数性能，当数据量较大时，导出到 MySQL 耗时大幅增加，进而导致查询响应时间变长。此外，通过 Java 后端查询 MySQL 时，数据量过大也会影响数据的响应时间。
追根究底，产生这些问题的根本原因在于早期架构无法满足超大规模实时数据场景下的数据需求，这迫使长安汽车必须进行平台升级改造。
技术调研与选型
长安汽车经过深入调研，决定引入开源实时数据仓库 Apache Doris ，在导入性能、实时查询等方面具有显著优势：
1.丰富的数据导入方式：Doris 提供了丰富的内置导入方式，如 Broker Load 和 Stream Load 等，可以满足实时和离线场景中数据导入需求。
2.支持实时查询分析：Doris 大表 Join 能力突出，提供了多种分布式 Join 方式，使 Join SQL 编写具备高度灵活性，极大提升数据分析的效率。此外，Doris 支持单节点上万 QPS 的超高并发，可解决早期架构由于前端并发量过大导致查询失败的问题。
3.较低的使用成本：Doris 兼容 MySQL 协议，开发人员可以更高效便捷的使用 MySQL 编写和执行查询语句，有效提高开发效率。基于 Doris 极简的架构，不仅让部署运维更加简单，也让扩缩容操作变的更加方便弹性。同时，Doris 拥有良好的上下游生态，可为用户提供灵活高效的数据管理和分析体验。这些优势和特性都极大的降低了 Doris 的使用成本。
除此以外，开源社区的活跃度也是我们考虑的重要因素之一 。Apache Doris 吸引了大量的开发者及用户参与社区，共同贡献代码和改进 Doris，这对质量和稳定性的提高起关键作用。同时Doris 社区为用户提供了全面的文档资料和技术支持，任何问题都可以快速得到解答和帮助。Apache Doris 的活跃程度使我们在使用时更加放心，解决了技术方面的后顾之忧。
基于 Apache Doris 车联网数据分析平台
在新的车联网数据分析平台中，通过 Flink 结合 Doris 的 Stream Load 功能，可直接将 Kafka 数据实时写入 Doris，同时，利用 Doris Broker Load 功能可以将 Hive 中数据导入到 Doris 中进行分析计算。在这个架构中，Apache Doris 承担了实时数据部分的计算和处理，还作为结果端直接输出数据给上游业务平台调用。
这一升级在系统上缩短了数据处理的路径，保证了大规模数据导入的时效性。此外，Apache Doris 的引入为上游应用层提供统一数据服务支持，这对于查询分析效率的提升至关重要。具体收益如下：
1.便捷进行数据写入和迁移：Doris 支持丰富的数据导入形式，可轻松从不同的数据源中导入数据。其次，Doris 支持通过 insert into select 快速导入数据，无需进行繁重的数据迁移配置以及引入外部同步组件。
2.统一数据服务，秒级查询响应：通过 Doris Multi-Catalog 功能，数据分析师可直接从 Doris 上查询数据，实现秒级别查询响应。其次，Doris Join 能力优异，对于超过 1000 万的结果表查询也可实现秒级返回结果。
3.降低存储和计算成本：在早期架构中，使用 Flink 实时写入数据并进行压缩时需要消耗大量的计算资源。而引入 Apache Doris 后，借助 Doris ZSTD 压缩算法（3-5 倍压缩率提升），可有效降低计算和存储所需的资源，还可以将压缩处理流程放到 Doris 内部进行，无需消耗 Flink 计算资源。
从 T+1 到 T+0，实时数据提升智能驾驶体验
CAN 总线数据在车辆分析中扮演着关键的角色，通过 CAN 总线可以读取车辆的各种状态信息，例如车速、转速、水温等。这些数据对于分析车辆的行驶数据具有重要的价值，为整车研发单位提供宝贵的参考信息。
在早期架构中，车辆 CAN 数据是按照 CAN ID 作为维度进行上传的，而在实际使用中，通常需要将不同 CAN ID 的信号按照时间对齐形成一个宽表。过去的数仓架构解决方案会先将 Kafka 中的数据写入到 Hive，此时不同 CAN ID 的数据被存储在不同的行中，需要使用 SparkSQL T+1 将数据转换为几个不同业务域的宽表。然而，这种计算方式耗时较长，SQL 语句难以维护，且数据的实时性较差。
在引入 Apache Doris 之后，我们在 Doris 中基于 Aggregate 聚合模型建立了业务域的宽表，将车辆和时间等作为主键，其他的信号字段都用 REPLACE_IF_NOT_NULL 定义。具体如下：
首先，可以使用 Flink 来消费 Kafka 中按 CAN ID 维度的数据，在 Flink 中根据业务域宽表的配置对数据进行分流，将同一个 CAN ID 上的信号分配到相应的业务域宽表中。当同一个车辆在同一时间内不同 CAN ID 的数据到达同一个业务域宽表时，可以将这些数据填充到同一行中的不同 CAN ID 的信号数据字段中，实现宽表的构建（如上图 Doris 的表示例）。
在这种方式中，主要通过 Flink 对数据进行分流，将数据发送到不同的 Doris 业务域宽表中（每个宽表约有 200 个字段）。宽表的生成逻辑被放在了 Doris 中，而不是在 Flink 中进行宽表对齐的操作。这样设计的原因是不同 CAN ID 的数据上传存在一定的时间差，时间窗口过大时，使用 Flink 根据车辆和时间进行聚合可能会导致资源开销过高。
通过以上方案，可以将数据的新鲜度从 T+1 提高到 T+0 。同时，对于包含约 10 亿行数据的宽表，可以达到秒级的查询效率，即在进行单车查询时，可以快速地获取查询结果。
10 亿级别 DTC 故障码实时查询，保障车辆驾驶安全
DTC 属于 CAN 数据中的故障报文，因此对其进行单独的业务数据存储。每天的 DTC 数据量级可以达到 10 亿条，为了让业务端便捷高效的使用这些数据，快速进行故障诊断，提升车辆安全性，需要将 DTC 故障码明细数据与一张 MySQL 业务配置表进行关联。
在早期架构中，开发人员每天都需要将海量 DTC 数据先写入到 Kafka 中，然后通过 Flink 进行实时处理，并将结果存储到 Hive 中。而这种处理方式存在一些问题：
1.面对 10 亿级数据量的表，难以将其导入 MySQL 进行实时查询。如果直接查询 Hive，则查询反馈时间会非常长，难以满足业务需求。
2.由于无法直接关联 MySQL 的配置表，不得不定时将配置表导入 Hive 数仓。这样做虽然能够满足数据处理的需求，但却丢失了 DTC 配置的实时性。
在引入 Apache Doris 后，采用上图所示处理方式成功解决了早期架构存在的问题。首先将 Hive 的 DTC 明细数据通过 HDFS 文件导入的方式导入到 Doris 中，然后创建对应的 MySQL Catalog 连接，最后使用后端 Java 通过 MyBatis 连接 Doris 数据库，并使用 SQL 通过 Catalog 连接 MySQL 的 DTC 配置表进行 Join 操作，可直接实时查询返回结果。
通过 Apache Doris 成功完成了 10 亿级别数据的实时查询，并且可以对关联的 MySQL 配置表进行直接关联查询，成功实现了配置的实时更新。
总结与规划
凭借 Apache Doris 卓越的性能，目前在长安汽车已经部署数十台机器，支撑了近十条业务线，每天处理数据规模达到百亿级别。 Apache Doris 的引入为长安汽车在提升用户用车体验、实时预警车辆故障、保证车辆安全驾驶等方面带来显著成果，为其在智能化方向的技术创新提供了有力支持。
未来长安汽车将进一步将 Apache Doris 应用在标签和指标业务，实现以下需求：
1.自动识别冷热数据：将热数据存储在 Apache Doris 中，冷数据存储在 Hive 中，通过这种方式实现更高效的数据访问和管理。
2.扩大业务范围：对现有的 Doris 业务 SQL 代码进行优化，利用 Doris 的某些特性和功能，将适合这些特性的业务迁移到 Doris 中，从而提高数据处理和查询的效率。
3.共建社区：积极尝试使用 Doris 最新版本及新功能，在与社区保持同步的同时，不断探索和应用新的技术，反哺社区、为社区发展做出贡献。
查询提速 11 倍、资源节省 70%，Apache Doris 在网易日志和时序场景的实践
作者｜隐形（邢颖），网易资深数据库内核工程师
编辑整理｜SelectDB 技术团队
导读：作为网易重要的业务线，灵犀办公和云信针对大规模日志/时序数据处理和分析的挑战，分别构建了灵犀 Eagle 监控平台和云信数据平台。本文将重点介绍 Apache Doris 在网易日志和时序场景中的应用，如何使用 Apache Doris 替换 Elasticsearch 和 InfluxDB，从而实现更低的服务器资源以及更高的查询性能体验，相较于 Elasticsearch，Apache Doris 查询速度至少提升 11 倍，存储资源的节省高达 70%。
随着信息技术的飞速发展，企业数据量呈现爆炸式增长。对于像网易这样规模庞大的互联网公司，无论是内部办公系统还是外部提供的服务，每天都会产生大量的日志和时序数据。这些数据已成为故障排查、问题诊断、安全监测、风险预警以及用户行为分析及体验优化的重要基石。充分挖掘这些数据的价值，有利于提升产品的可靠性、性能、安全性以及用户满意度。
灵犀办公和云信作为网易重要的业务线，分别构建了灵犀 Eagle 监控平台、云信数据平台来应对大规模日志/时序数据在处理分析时带来的挑战。而随着业务的持续扩张，日志/时序数据也呈井喷式增长，随之带来的是存储成本增高，查询时间延长、系统稳定性变差等问题。早期的平台已难以为继，这促使网易寻找更加优质的解决方案。
本节将聚焦于 Apache Doris 在网易日志和时序类场景中的落地，分别介绍它在网易灵犀办公、网易云信业务中的架构升级实践，并结合实际场景分享建表、导入、查询等方面的调优方案。
早期架构及痛点
1、灵犀 - Eagle 监控平台
网易灵犀办公是全新一代邮件协同办公平台。整合了邮箱、日历、云文档、即时消息、客户管理等模块。Eagle 监控平台是一个全链路 APM 系统，可为网易灵犀办公提供多维度、不同粒度的性能分析。
Eagle 监控平台主要对灵犀办公、企业邮、有道云笔记、灵犀文档等业务日志数据进行存储分析，日志数据首先通过 Logstash 采集并处理，然后存储到 Elasticsearch 中，由 Elasticsearch 进行实时日志检索及分析，并为灵犀办公提供日志搜索以及全链路日志查询等服务。
随着时间的推移、日志数据的增长，在使用 Elasticsearch 的过程中逐渐暴露出一些问题：
1.查询延迟高：在日常查询中，Elasticsearch 平均响应延迟较高，影响使用体验。这主要受到数据的规模、索引设计的合理性以及硬件资源等因素的制约。
2.存储成本高：在降本增效的大背景下，业务对降低存储成本的需求日益迫切。但由于 Elasticsearch 存在正排、倒排、列存等多份数据存储，数据冗余程度较高，给降本提效带来了一定的挑战。
2、云信 - 数据平台
网易云信是集网易 26 年技术打造的融合通信与云原生 PaaS 服务专家，提供融合通信与云原生核心产品及解决方案，包含 IM 即时通讯、视频云、短信，及轻舟微服务、中间件 PaaS 等。
云信数据平台主要是对 IM、RTC、短信等服务所产生的时序数据进行分析。早期数据架构主要基于时序数据库 InfluxDB 搭建，数据源首先通过 Kafka 消息队列进行上报 ，经字段解析和清洗之后，存储到时序数据库 InfluxDB 中，以提供在线和离线查询。离线侧支持离线 T+1 数据分析，实时侧需提供指标监控报表及账单的实时生成。
在客户规模的快速覆盖下，上报的数据源也持续增加，InfluxDB 同样面临一系列新的挑战：
1.内存溢出 OOM：随着数据源的增多，需要基于多个数据源进行离线分析，分析难度随之增加。受限于 InfluxDB 的查询能力，当前架构在面对多个数据源的复杂查询时，可能会导致内存溢出（ OOM），这给业务的可用性及系统的稳定性带来巨大的挑战。
2.存储成本高：业务的发展也带来集群数据量的不断增长，而集群中较大比例数据为冷数据，冷热数据采用同一种方式进行存储，导致了高昂的存储成本，这与降本增效的企业目标相悖。
核心引擎的选型
为此网易开始寻找新的数据库解决方案，旨在解决上述两大业务在日志时序类场景所面临的挑战。同时，网易期望只用一个数据库，能够适配两大应用场景的业务体系及技术架构，满足极简易用、低成本投入的升级需求。在这方面，Apache Doris 符合我们的选型要求，具体表现在以下几个方面：
1.存储成本优化：Apache Doris 在存储结构上面进行了许多优化，减少了冗余存储。具有更高的压缩比，且支持基于 S3、NOS （网易对象存储服务 Netease Object Storage）的冷热分层存储，可有效降低存储成本，提高数据存储效率。
2.高吞吐高性能：Apache Doris 支持列式存储高性能磁盘写入、时序 Compaction 以及 Stream Load 高效流式导入，能够支持每秒数十 GB 的数据写入。这样既能保证日志数据的大规模写入，同时还能够提供低延迟的查询可见性。
3.实时日志检索：Apache Doris 不仅能够支持日志文本的全文检索，还能够实现实时查询响应。Doris 支持在内部增加倒排索引，可以满足字符串类型的全文检索和普通数值/日期等类型的等值、范围检索，同时可进一步优化倒排索引的查询性能、使其更加契合日志数据分析的场景需求。
4.支持大规模租户隔离： Doris 可承载数千数据库以及数万数据表，并能够实现一个租户独立使用一个数据库，满足多租户数据隔离的需求，保证了数据的隐私性和安全性。
除此之外，近一年以来， Apache Doris 在日志场景持续深耕，推出了一系列核心能力，如高效的倒排索引、灵活的 Variant 数据类型等，为日志/时序数据的处理分析提供了更高效、灵活的解决方案。综合以上优势，网易最终决定引入 Apache Doris 作为全新架构核心引擎。
基于 Apache Doris 的统一日志存储和分析平台
1、灵犀 - Eagle 监控平台
首先，在灵犀办公 - Eagle 监控平台中，网易成功将 Elasticsearch 全面升级为 Apache Doris，从而构建了统一的日志存储和分析平台。这一架构升级不仅显著提升了平台的性能与稳定性，更为其提供了强大且高效的日志检索服务。具体收益体现在：
1.存储资源节省 70%：得益于 Doris 列式存储和 ZSTD 高压缩比，存储同样的日志数据，Elasticsearch 需要 100T 存储空间，而存储到 Doris 中仅需要 30T 存储空间，存储资源节省 70%。由于存储空间大幅节省，在同样的成本下可以使用 SSD 代替 HDD 存储热数据，又带来更大的查询性能提升。
2.查询提速 11 倍：新架构以更低的 CPU 资源消耗带来了数十倍的查询效率提升。从下方示意图可知，最近 3 小时、1 天 、7 天的日志检索，Doris 查询耗时保持稳定且均低于 4s，最快可在 1s 内响应。而 Elasticsearch 查询耗时呈现出较大的波动，最长耗时高达 75s，即使最短耗时也需要 6-7s。在更低的资源占用下，Doris 的查询效率至少是 Elasticsearch 的 11 倍。
2、云信 - 数据平台
在云信数据平台中，网易同样使用 Apache Doris 替代了早期架构中的时序数据库 InfluxDB，将其作为数据平台核心存储和计算引擎，由 Apache Doris 统一提供离线和实时查询服务。
1.支持高吞吐写入：线上平均 500M/s、峰值 1GB/s 的写入流量，InfluxDB 使用 22 台服务器，CPU 资源使用率约 50%，而 Doris 仅使用 11 台机器，CPU 使用率约 50%，整体资源消耗仅仅为之前的 1/2。
2.存储资源节省 67%：使用 11 台 Doris 物理机替换了 22 台 InfluxDB ，存储同样的数据规模，InfluxDB 需要 150T 存储空间，而存储到 Doris 中仅需要 50T 存储空间，存储资源节省 67%。
3.查询响应快且更稳定：为验证其查询响应速度，随机挑选一个线上 SQL（最近 10min 匹配一个字符串），对该 SQL 连续查询 99 次。从下图可知，Doris（蓝色）的查询性能比 InfluxDB（红色） 更稳定，99 次查询均比较平稳、没有明显波动，而 InfluxD 出现多次异常波动，查询耗时直线上升，查询稳定性受到严重影响。
实践及调优
在业务落地的过程中，网易也遇到一些问题及挑战。借此机会，将这些宝贵的优化经验整理并分享，希望对大家的使用有所指引及帮助。
01 建表优化
数据库 Schema 的设计对于性能至关重要，而在处理日志和时序数据时也不例外。Apache Doris 针对这两种场景提供了一些专门的优化选项，因此在表的创建过程中启用这些优化选项非常关键。以下是我们在实践中使用到的具体优化选项：
1.当使用 DATETIME 类型的时间字段作为主键 Key 时，查询最新 n 条日志的速度会得到显著提升。
2.使用基于时间字段的 RANGE 分区，并开启动态 Partiiton ，以便按天自动管理分区，提升数据查询和管理的灵活性。
3.在分桶策略上，可以使⽤ RANDOM 进行随机分桶，分桶数量大致设置为集群磁盘总数的 3 倍。
4.对于经常需要查询的字段，建议构建索引以提高查询效率；而对于需要进行全文检索的字段，应指定合适的分词器参数 parser，确保检索的准确性和效率。
5.针对日志类、时序类场景，使用专门优化过的时序 Compaction 策略。
6.采用 ZSTD 压缩，可以获得更好的压缩效果，节省存储空间。
CREATE TABLE log
(
ts DATETIME,
host VARCHAR(20),
msg TEXT,
status INT,
size INT,
INDEX idx_size (size) USING INVERTED,
INDEX idx_status (status) USING INVERTED,
INDEX idx_host (host) USING INVERTED,
INDEX idx_msg (msg) USING INVERTED PROPERTIES("parser" = "unicode")
)
ENGINE = OLAP
DUPLICATE KEY(ts)
PARTITION BY RANGE(ts) ()
DISTRIBUTED BY RANDOM BUCKETS 250
PROPERTIES (
"compression"="zstd",
"compaction_policy" = "time_series",
"dynamic_partition.enable" = "true",
"dynamic_partition.create_history_partition" = "true",
"dynamic_partition.time_unit" = "DAY",
"dynamic_partition.start" = "-7",
"dynamic_partition.end" = "3",
"dynamic_partition.prefix" = "p",
"dynamic_partition.buckets" = "250"
);
02 集群配置优化
FE 配置
# 开启单副本导入提升导入性能
enable_single_replica_load = true
# 更加均衡的tablet分配和balance测量
enable_round_robin_create_tablet = true
tablet_rebalancer_type = partition
# 频繁导入相关的内存优化
max_running_txn_num_per_db = 10000
streaming_label_keep_max_second = 300
label_clean_interval_second = 300
BE 配置
write_buffer_size=1073741824
max_tablet_version_num = 20000
max_cumu_compaction_threads = 10(cpu的一半)
enable_write_index_searcher_cache = false
disable_storage_page_cache = true
enable_single_replica_load = true
streaming_load_json_max_mb=250
03 Stream Load 导入调优
云信 - 数据平台在业务高峰期时，面临着高达 100 万以上的写入 TPS 以及 1GB/s 的写入流量，这无疑对系统性能提出了极高的要求。然而，由于业务侧存在众多小并发的表，且查询侧对数据的实时性要求极高，这使得在短时间内无法将批处理积攒到足够大的 Batch。联合业务方进行系列优化后， Stream Load 仍然难以迅速消费 Kafka 中的数据，导致 Kafka 中的数据积压现象日益严重。
经过深入分析，发现在业务高峰期，业务侧的数据导入程序已遭受性能瓶颈，主要体现在 CPU 和内存资源的过度占用。然而，Doris 侧的性能状况尚未出现显著的瓶颈，但 Stream Load 的响应时间却有明显的上升趋势。
由于业务程序是同步调用 Stream Load 的，这意味着 Stream Load 的响应速度直接影响着整体的数据处理效率。因此，如果能够有效降低单个 Stream Load 的响应时间，那么整个系统的吞吐能力将得到显著提升。
在与 Apache Doris 社区同学交流之后，了解到针对日志和时序场景，Doris 推出了两个重要的导入性能优化：
1.单副本导入：先写入一个副本，其他副本从第一个副本拉取数据。这种方式可避免多个副本重复排序、构建建索引所带来的开销。
2.单 Tablet 导入：相较于普通模式下数据分散到多个 Tablet 的写入方式，可采用一次仅写入单个 Tablet 的策略。这种优化减少了写入时产生的小文件数量和 IO 开销，进而提升了整体的导入效率。可在导入时设置 load_to_single_tablet 参数为 true 来启用这一功能。
在使用上述方式优化后，导入性能得到显著的提升：
消费 Kafka 速度提升超 2 倍
Kafka 的延迟时间显著下降，仅为原先耗时的 1/4
Stream Load 的 RT 减少约 70%
网易在正式上线前也开展了大压力测试和灰度试运行，经过持续不断的调优工作，最终确保系统能够在大规模场景下稳定上线运行，为业务提供强有力的支持。
1. Stream Load 超时：
在压测初期出现数据导入频繁超时报错的问题，且在进程及集群状态正常的情况下，监控无法正常采集 BE 的 Metrics 数据。
通过 Pstack 获得 Doris BE 的堆栈，并使用 PT-PMT 对堆栈进行分析。发现主要原因是当客户端发起请求时，没有设置 HTTP Chunked 编码 也没有设置 Content-Length，这导致 Doris 误认为数据传输尚未结束，从而一直处于等待状态。在客户端添加 Chunked 编码设置后，数据导入恢复正常。
2. Stream Load 单次导入数据量超过阈值：
通过调大 streaming_load_json_max_mb 参数到 250M（默认 100M ）后解决。
3. 副本不足写入报错： alive replica num 0 < quorum replica num 1
通过 show backends 发现有一台 BE 状态异常显示为 OFFLINE。查看对应的 be_custom 配置文件，发现其中存在 broken_storage_path。进一步检查 BE 的日志，发现报错信息提示 “too many open files”，这意味着 BE 进程打开的文件句柄数量已经超出了系统设定的最大值，从而导致 IO 操作失败。
当 Doris 系统检测到这种异常情况时，会将该磁盘标记为不可用状态。由于该表的配置是单副本策略，当唯一的副本所在磁盘出现问题时，就会因为副本数不足而无法继续写入数据。
因此，将进程 FD 最大打开限制调整到了 100 万，并删除 be_custom.conf 配置文件、重启该 BE 节点，服务最终恢复正常运行。
4. FE 内存抖动
在业务灰度测试期间，出现无法连接到 FE 的问题。通过查看监控数据，发现 JVM 32G 内存已经耗尽，同时 FE 的 meta 目录下 bdb 文件目录异常膨胀至 50G。
由于业务一直在进行高并发的 Stream Load 数据导入操作，而导入过程中 FE 会记录相关的 Load 信息，每次导入产生的内存信息约为 200K。这些内存信息的清理时间由 streaming_label_keep_max_second 参数控制，默认值为 12 小时，将它调小到 5 分钟后 FE 内存不会耗尽，但是运行一段时间后，发现内存按照 1 小时为周期进行抖动，高峰内存使用率达到 80%。分析代码发现清理 label 的线程每隔 label_clean_interval_second 运行一次，默认为 1 小时，把它也调小到 5 分钟后，FE 内存很平稳。
04 查询调优
当灵犀 - Eagle 监控平台在进行查询测试的时候，疑似读取到了不符合匹配条件的结果，这一现象显然不符合预期的检索逻辑。如下图第一条记录：
起初误以为是 Doris 的 Bug，于是尝试搜索类似的 issue 及规避方案。然而，在咨询社区成员并仔细查阅官方文档后，发现问题的根源是对 match_all 使用场景的理解存在误区。
match_all 的工作原理是只要存在分词就能进行匹配，而分词是依据空格或标点来进行的。在该案例中，match_all 中的 '29' 与第一条记录后续内容中的 '29' 进行了匹配，从而输出了不符合预期的结果。
针对该 Case，正确的方式是使用 MATCH_PHRASE 进行匹配，MATCH_PHRASE 可以满足文本中的顺序要求。
-- 1.4 logmsg中同时包含keyword1和keyword2的行，并且按照keyword1在前，keyword2在后的顺序
SELECT * FROM table_name WHERE logmsg MATCH_PHRASE 'keyword1 keyword2';
在使用 MATCH_PHRASE 进行匹配时，建索引时需指定 support_phrase，否则系统会进行全表扫描并进行硬匹配，查询效率较差。
INDEX idx_name4(column_name4) USING INVERTED PROPERTIES("parser" = "english|unicode|chinese", "support_phrase" = "true")
对于已经写入数据的表，若希望启用 support_phrase，可以执行 DROP INDEX 来删除旧的索引，随后使用 ADD INDEX 添加新的索引。这一过程是在已有表上增量进行，无需重写整个表的数据，从而确保了操作的高效性。
相较于 Elasticsearch，Doris 的索引管理方式更为灵活，能够根据业务需求快速添加或删除索引，提供了更大的便利性和灵活性。
结束语
Apache Doris 的引入，有效满足了网易对日志、时序场景的需求，有效解决了网易灵犀办公以及网易云信早期日志处理及分析平台存储成本高，查询效率低等问题。
在实际应用中，Apache Doris 以更低的服务器资源，承载了线上平均 500MB/s 、峰值超 1GB/s 的写入流量的平稳写入。同时，查询响应也得到了显著的提升，相较于 Elasticsearch ，查询效率至少提升了 11 倍。此外Doris具备更高的压缩比，存储资源相较之前可节约 70%。
最后，特别感谢 SelectDB 技术团队一直以来的支持。未来，网易将继续推广 Apache Doris，将其深入应用于网易其他大数据场景中。同时也期待能与更多对 Doris 感兴趣的业务团队展开深入交流，共同推动 Apache Doris 发展。
奇安信基于Apache Doris升级日志安全分析系统
长安汽车基于 Apache Doris 的车联网数据分析平台建设实践
Apache Doris 在网易日志和时序场景的实践
天眼查基于Apache Doris构建统一实时数据仓库
随着天眼查近年来对产品的持续深耕和迭代，用户数量也在不断攀升，业务的突破更加依赖于数据赋能，精细化的用户/客户运营也成为提升体验、促进消费的重要动力。在这样的背景下正式引入 Apache Doris 对数仓架构进行升级改造，实现了数据门户的统一，大大缩短了数据处理链路，数据导入速率提升 75%，500 万及以下人群圈选可以实现毫秒级响应，收获了公司内部数据部门、业务方的一致好评。数据秒级写，查询毫秒应。
作者 | 天眼查实时计算负责人-王涛(2023年5月)
天眼查是中国领先的商业查询平台，以公开数据为切入点、以关系为核心的产品，帮助传统企业或个人降低成本，为防范化解金融风险方面提供了产品化的解决方案。目前已收录全国3亿多家社会实体信息，300多种维度信息及时更新，致力于构建商业安全，从而实现“公平看清世界”。
业务背景
天眼查的数据仓库主要服务于三个业务场景，每个场景都有其特点和需求，具体如下：
1).亿级用户人群圈选：人群圈选场景中目前有 100+ 人群包，我们需要根据 SQL 条件圈选人群包，来支持人群包的交并差、人群包实时圈选和人群包更新通知下游等需求。例如：圈选出下单未支付超过 5 分钟的用户，我们通过用户标签可以直观掌握用户支付状态，为运营 & 营销团队提供更精细化的人群管理服务，从而提高转化率。
2).多元活动支撑的精准营销：该场景目前支持了 1000 多个指标，可支持即席查询，根据活动效果及时调整运营策略。例如在“开工季”活动中，需要为数据分析 & 运营团队提供数据支持，从而生成可视化的活动驾驶舱。
3).高并发的 C 端分析数据：该场景承载了 3 亿+实体（多种维度）的数据体量，同时要求实时更新，以供用户进行数据分析。
原有架构及痛点
为满足各业务场景提出的需求，我们开始搭建第一代数据仓库，即原有数仓：
在原有数仓架构中， Hive 作为数据计算层，MySQL、ES、PG 作为数据存储 层，我们简单介绍一下架构的运行原理：
1).数据源层和数据接入层：MySQL 通过 Canal 将 BinLog 接入 Kafka、埋点日志通过 Flume 接入 Kafka，最后由 DataX 把 Kafka 中的数据接入数据计算层 Hive 中；
2).数据计算层：该层使用 Hive 中的传统的数仓模型，并利用海豚调度使数据通过 ODS -> DWD -> DWS 分层，最后通过 DataX 将 T+1 把数据导入到数据存储层的 MySQL 和 ES 中。
3).数据存储层：MySQL 主要为 DataBank、Tableau、C 端提供分析数据，ES 用于存储用户画像数据，PG 用于人群包的存储（PG 安装的插件具有 Bitmap 交并差功能），ES、PG 两者均服务于 DMP人群圈选系统。
问题与挑战
依托于原有架构的投入使用，初步解决了业务方的需求，但随着天眼查近年来对产品的持续深耕和迭代，用户数量也在不断攀升，业务的突破更加依赖于数据赋能。精细化的用户/客户运营也成为提升体验、促进消费的重要动力。在这样的背景下，原有架构的缺点逐渐暴露：
1).开发流程冗长：体现在数据处理链路上，比如当面对一个简单的开发需求，需要先拉取数据，再经过 Hive 计算，然后通过 T+1 更新导入数据等，数据处理链路较长且复杂，非常影响开发效率。
2).不支持即席查询：体现在报表服务和人群圈选场景中，所用的指标无法根据条件直接查询，必须提前进行定义和开发。
3).T+1 更新延迟高：T+1 数据时效性已经无法提供精确的线索，主要体现在报表和人群圈选场景上。
4).运维难度高：原有架构具有多条数据处理链路、多组件耦合的特点，运维和管理难度都很高。
理想架构
基于以上问题，我们决定对架构进行升级改进，在正式升级之前，我们希望未来的架构可以做到以下几点：
1).原架构涉及 MySQL 、PG、ES 等多个组件，并为不同应用提供服务；我们希望未来的架构可以兼容 MySQL 协议，实现低成本替换、无缝衔接以上组件。
2).支持即席查询且性能优异，即席查询能够给业务方提供更灵活的表达方式，业务方可以从多个角度、多个维度对数据进行查询和分析，更好地发现数据的规律和趋势，帮助业务方更精准备地做出决策。
3).支持实时聚合，以减轻开发负担并保证计算结果的准确性。
4).统一数据出口，原架构中数据出口不唯一，我们希望未来的架构能更统一数据出口，缩短链路维护成本，提升数据的可复用性。
5).支持高并发， C 端的实时分析数据需要较高的并发能力，我们希望未来的架构可以高并发性能优异。
技术选型
考虑到和需求的匹配度，我们重点对 OLAP 引擎进行了调研，并快速定位到 ClickHouse 和 Apache Doris 这两款产品，在深入调研中发现 Doris 在以下几个方面优势明显，更符合我们的诉求：
1).标准 SQL：ClickHouse 对标准 SQL 支持有限，使用中需要对多表 Join 语法进行改写；而 Doris 兼容 MySQL 协议，支持标准 SQL ，可以直接运行，同时 Doris 的 Join 性能远优于 ClickHouse。
2).降本增效：Doris 部署简单，只有 FE 和 BE 两个组件，不依赖其他系统；生态内导数功能较为完备，可根据数据源/数据格式选择导入方式；还可以直接使用命令行操作弹性伸缩，无需额外投入人力；运维简单，问题排查难度低。相比之下，ClickHouse 需要投入较多的开发人力来实现类似的功能，使用难度高；同时 ClickHouse 运维难度很高，需要研发一个运维系统来支持处理大部分的日常运维工作。
3).并发能力：ClickHouse 的并发能力较弱是一个潜在风险，而 Doris 并发能力更占优势，并且刚刚发布的 2.0 版本支持了 。
4).导入事务：ClickHouse 的数据导入没有事务支持，无法实现 Exactly Once 语义，如导数失败需要删除重导，流程比较复杂；而 Doris 导入数据支持事务，可以保证一批次内的数据原子生效，不会出现部分数据写入的情况，降低了判断的成本。
5).丰富的使用场景：ClickHouse 支持场景单一，Doris 支持场景更加丰富，用户基于 Doris 可以构建用户行为分析、AB 实验平台、日志检索分析、用户画像分析、订单分析等应用。
6).丰富的数据模型：Doris 提供了Unique、Duplicate、Aggregate 三种数据模型，可以针对不同场景灵活应用不同的数据模型。
7).社区响应速度快：Doris 社区的响应速度是其独有特色，SelectDB 为社区组建了一直完备的社区支持团队，社区的快速响应让我们少走了很多歪路，帮助我们解决了许多问题。
新数仓架构
经过对 Doris 进行综合评估，我们最终决定采用 Doris 对原有架构进行升级优化，并在架构层级进行了压缩。新的架构图如下所示：
在新架构中，数据源层和数据接入层与原有架构保持一致，主要变化是将 Doris 作为新架构的数据服务层，统一了原有架构中的数据计算层和存储层，这样实现了数据门户的统一，大大缩短了数据处理链路，解决了开发流程冗长的问题。同时，基于 Doris 的高性能，实现了即席查询能力，提高了数据查询效率。另外，Flink 与 Doris 的结合实现了实时数据快速写入，解决了 T+1 数据更新延迟较高的问题。除此之外，借助于 Doris 精简的架构，大幅降低了架构维护的难度。
数据流图
缩短数据处理链路直接或间接地带来了许多收益。接下来，我们将具体介绍引入 Doris 后的数据流图。
总体而言，数据源由 MySQL 和日志文件组成，数据在 Kafka 中进行分层操作（ODS、DWD、DWS），Apache Doris 作为数据终点统一进行存储和计算。应用层包含 C 端、Tableau 和 DMP 系统，通过网关服务从 Doris 中获取相应的数据。
具体来看，MySQL 通过 Canal 把 Binlog 接入 Kafka，日志文件通过 Flume 接入 Kafka 作为 ODS 层。然后经过 Flink SQL 进行清洗、关联维表，形成 DWD 层的宽表，并生成聚合表。为了节省空间，我们将 ODS 层存储在 Kafka 中，DWD 层和 DWS 层主要与 Doris 进行交互。DWD 层的数据一般通过 Flink SQL 写入 Doris。针对不同的场景，我们应用了不同的数据模型进行数据导入。MySQL 数据使用 Unique 模型，日志数据使用 Duplicate 模型，DWS 层采用 Aggregate 模型，可进行实时聚合，从而减少开发成本。
应用场景优化
在应用新的架构之后，必须对业务场景的数据处理流程进行优化以匹配新架构，从而达到最佳应用效果。接下来以人群圈选、C端分析数据及精准营销线索为主要场景，分享相关场景流程优化的实践与经验。
一、 人群圈选
原流程（左）中，业务人员在画像平台页面上利用表的元数据创建人群圈选任务，任务创建后进行人群 ID 分配，写入到 PG 画像表和 MySQL 任务表中。接着根据任务条件定时在 ES 中查询结果，获取结果后更新任务表的状态，并把 Bitmap 人群包写入 PG。利用 PG 插件提供的 Bitmap 交并差能力操作人群包，最后下游运营介质从 PG 取相应人群包。
然而，该流程处理方式非常复杂，ES 和 PG 中的表无法复用，造成成本高、效益低。同时，原流程中的数据为 T+1 更新，标签必须提前进行定义及计算，这非常影响查询效率。
现流程（右）中，业务人员在画像平台创建人群圈选任务，后台分配人群 ID，并将其写入 MySQL 任务表中。首次圈选时，根据任务条件在 Doris 中进行即席查询，获取结果后对任务表状态进行更新，并将人群包写入 Doris。后续根据时间进行微批轮询，利用 Doris Bitmap 函数提供的交并差功能与上一次的人群包做差集，如果有人群包更新会主动通知下游。
引入 Doris 后，原有流程的问题得到了解决，新流程以 Doris 为核心构建了人群圈选服务，支持人群包实时更新，新标签无需提前定义，可通过条件配置自助生成，减少了开发时间。新流程表达方式更加灵活，为人群包 AB 实验提供了便捷的条件。流程中采用 Doris 统一了明细数据和人群包的存储介质，实现业务聚焦，无需处理多组件数据之间的读写问题，达到了降本增效的终极目标。
二、C端分析数据及精准营销线索场景
原流程：在原流程中，如果业务提出新需求，需要先发起需求变更，再经过评审、排期开发，然后开始对 Hive 中的数据模型进行开发并进行测试，测试完成后进行数仓上线，配置 T+1 调度任务写入 MySQL，最后 C端和精准营销系统对 MySQL 数据进行读取。原流程链路复杂，主要体现在流程长、成本高、上线周期长。
现流程：当前明细数据已经在 Doris 上线，当业务方发起需求变更时，只需要拉取元数据管理平台元数据信息，配置查询条件，审批完成后即可上线，上线 SQL 可直接在 Doris 中进行即席查询。相比原流程，现在的流程大幅缩短了需求变更流程，只需进行低代码配置，成功降低了开发成本，缩短了上线周期。
优化经验
为了规避风险，许多公司的人群包user_id是随机生成的，这些user_id相差很大且是非连续的。然而，使用非连续的user_id进行人群圈选时，会导致 Bitmap 生成速度较慢。因此生成了映射表，并生成了连续稠密的 user_id。当使用连续user_id圈选人群时，速度较之前提升了 70%。
用户 ID 映射表样例数据：从图可知原始用户 ID 由多位数字组合，并且 ID 很 稀疏（用户 ID 间相差很大），而连续用户 ID 则 从1开始，且 ID 很稠密。
案例展示：
1、用户 ID 映射表：
用户 ID 映射表将用户 ID 作为唯一键模型，而连续用户 ID 则通过用户 ID 来生成，一般从 1 开始，严格保持单调递增。需要注意的是，因为该表使用频 繁，因此将in_memory设置为true，直接将其缓存在内存中。
2、人群包表
人群包表是以用户标签作聚合键的模型，假设以 user_id 大于 0、小于 2000000 作为圈选条件，使用原始 user_id 进行圈选耗费的时间远远远大于连续稠密 user_id 圈选所耗时间。
如下图所示，左侧使用tyc_user_id圈选生成人群包响应时间：1843ms，右侧使用使tyc_user_id_continuous圈选生成人群包响应时间：543ms，消耗时间 大幅缩短。
规模与收益
引入 Doris 后，我们已经搭建了 2 个集群，承载的数据规模正随着迁移的推进而持续增大。目前已经处理的数据总量已经达到了数十TB，单日新增数据量已经达到了数十亿条，而数据体量还在持续增长中。此外在 Doris 上运行的指标和人群包数量已经超过了 500，分别涵盖了商查、搜索、运营、用户和营收五大类指标。
Doris 的引入满足了业务上的新需求，解决了原有架构的痛点问题，具体表现为以下几点：
1).降本增效：Doris 统一了数据的门户，实现了存储和计算的统一，提高了数据/表的复用率，降低了资源消耗。同时，新架构优化了数据到 MySQL、ES 的流程，开发效率得到有效提升。
2).导入速率提升：原有数据流程中，数据处理流程过长，数据的导入速度随着业务体量的增长和数据量的不断上升而急剧下降。引入 Doris 后，得益于 Broker Load 优秀的写入能力，使得导入速率提升了 75%以上。
3).响应速度：Doris 的使用提高了各业务场景中的查询响应速度。例如在人群圈选场景中，对于 500 万及以下的人群包进行圈选时，能够做到毫秒级响应。
未来规划
如前文所讲，Apache Doris 的引入解决了许多架构及业务上的难题，初见成效，同时也收获了公司内部数据部门、业务方的一致好评，未来我们将继续探索，基于 Doris 展开更深度的应用，不久的将来，我们将重点推进以下几个方面工作：
1).离线指标实时化：将更多的指标从离线转为实时，提供更及时的数据服务。
2).搭建数据血缘系统：将代码中的血缘关系重新定义为可视，全面构建数据血缘关系，为问题排查、链路报警等提供有效支持。
3).探索批流一体路线：从使用者的角度思考设计，实现语义开发层的统一，使数据开发更便捷、更低门槛、更高效率。
在此特别感谢 SelectDB 团队，作为一家基于 Apache Doris 的商业化公司，为社区投入了大量的研发和用户支持力量，在使用过程中遇到任何问题都能及时响应，为我们降低了许多试错成本。
奇安信基于Apache Doris升级日志安全分析系统，查询平均提速700%
本节导读：数智时代的到来使网络安全成为了不可忽视的重要领域。奇安信作为一家领先的网络安全解决方案领军者，致力于为企业提供先进全面的网络安全保护，其日志分析系统在网络安全中发挥着关键作用，通过对运行日志数据的深入分析，能够对漏洞和异常行为生成关键见解，帮助企业建立有效的防御策略。本文将深入探讨奇安信在网络安全与日志分析解决方案的关键优势，了解基于 Apache Doris 构建的全新一体化日志存储分析平台如何实时监测和分析日志事件，加强对可疑活动的追踪与应对，提升系统安全性与快速响应能力。
（作者｜奇安信 服务端技术专家：舒鹏，本节转自SelectDB空间）
奇安信是中国企业级网络安全市场的领军者，专注于为政府和企业用户提供新一代网络安全产品和服务。目前核心产品天擎终端安全系统在国内已有 4000 万政企用户部署、全国部署服务器超过 100 万台、服务超 40 万大型机构。作为网络安全国家队，奇安信立志为国家构建安全的网络空间，在终端安全、云安全、威胁情报、态势感知等领域的技术研发持续领先。
随着现代企业数字化转型的不断深化，大数据、物联网、5G等创新技术的广泛应用加速了企业的数字化转型步伐，这使得原先的网络边界被打破，多源多样的终端设备成为了新的安全边界。
网络安全系统的防御性能与日志分析密不可分，当网络设备、操作系统以及应用程序在运行时，会产生大量的运行日志，其中蕴涵了丰富的数据价值。最大化地利用运行日志数据能够有效检测内部系统的安全风险、还原攻击路径、回溯攻击入口等，可以进一步提升系统安全性、保障企业网络安全，因此日志分析系统在其中发挥着不可或缺的作用。
本节将介绍奇安信在网络安全场景中，基于 Apache Doris 进行架构升级迭代并建设全新一体化日志存储分析平台的实践经验。
早期架构痛点与需求
安全日志平台的架构如下图所示，原始的设备、系统日志首先经过业务处理环节，包括归一化和扩充维度等操作。这些处理步骤旨在将来自不同设备和系统日志转化为半结构化 JSON 格式的安全日志，并将其写入 Kafka 消息队列中。
最新的日志会被写入实时数仓，安全分析师可以通过分析平台对实时数仓中的最新数据进行交互式查询，从而进行攻击研判和追踪溯源等安全分析工作。另外，离线数仓用于保存历史数据，以支持长周期数据挖掘的离线分析。
在以上日志数据平台中，日志数据的写入速度与查询分析效率对上层业务人员进行实时安全事件监控和分析至关重要，这也是当前我们所面对的最主要痛点。
一方面，每天所生产的安全日志数据达到千亿级，写入压力很大。最初我们选择使用某 Apache Doris 的 Fork 版本来存储日志数据，但在实际应用中，随着每天新增日志量的不断增长，入库速度逐渐降低、集群写入压力过大、高峰期数据积压严重，对集群稳定性造成很大影响，并且数据压力较高时、查询效率也达不到有效果的保证。随后我们对集群进行多次扩容，从 3 节点逐步扩容到 13 节点，尽管机器成本已经大幅超过预期、但写入效率并没有发生本质的改善。
另一方面，业务人员在进行安全日志分析时，经常需要对文本字段（如 URL，payload 等）进行关键字匹配。在原系统中只能通过 SQL LIKE 进行全量扫描和暴力匹配，整体查询性能不佳，千亿级数量的数据表查询耗时接近分钟级甚至达到数百秒，即便按照时间区间过滤大量数据后、查询耗时仍在数秒到数十秒。一旦遇到并发查询性能还会进一步恶化，很难满足日常安全分析的需求。
除写入和查询效率以外，运维监控也是我们的痛点之一，该厂商提供的可视化运维系统需要商业 License 授权，对于开源社区用户不友好，集群维护处于原始手动状态。
架构选型与升级的思考
为了解决过去版本的痛点、满足更高效实时的日志分析诉求，我们亟需对早期系统升级改造。同时面向安全日志分析场景，我们也对新日志分析平台的架构提出了更高的要求：
1.写入性能：系统一方面需要支持海量病毒查杀事件等数据实时写入与存储，以满足分析时效性的要求，另一方面需要基于日志数据 Schema Free 特点支持丰富数据类型的写入与变更。
2.查询性能：由于日志查询分析会涉及对文本类型、JSON 数据进行全文检索、日期或普通数值的范围查询，系统需要对字符串提供模糊查询的能力，还需要支持能够灵活创建且类型丰富的索引，以加速筛选过滤海量数据，提升查询效率。
3.存储成本：设备每天产生大量的日志数据，为了挖掘这些有价值的日志信息，业务人员还需要从数据中进行筛选和分析，并对异常日志回溯追踪，这使得日志存储的规模很大、存储周期相对较长，因此高性价比的存储成本也是系统构建的目标之一。
4.运维成本：系统自身的运维简易程度以及是否具备合适的管控工具都能帮助我们进一步提效。
在持续关注业界 OLAP 数据库的过程中，我们发现 Apache Doris 最近一年的发展非常迅猛，最新的 2.0 版本也把日志存储和检索分析作为新的发力点，推出了倒排索引、NGram BloomFilter 索引等特性，对关键词检索、LIKE 文本匹配的性能有大幅提升，与我们文本检索慢的痛点需求非常契合，因此开启了新架构的升级之旅。
架构升级之旅
上文中提到，在整体架构选型过程中我们主要关注的地方包括写入性能、查询性能、数据存储成本以及运维成本等方面。在架构升级过程中，我们选择了 Apache Doris 当时最新发布的 2.0 版本，具体升级收益如下。
1、写入性能提升超 200%
为了评估 Apache Doris 写入的极限性能，我们初期使用与线上系统相同配置的 3 台服务器，从 Kafka 接入线上真实写入流量，测试期间当 CPU 写入效率跑满至 100% 时写入吞吐达到了 108 万条 /s、1.15 GB/s，写入数据的可见性延迟保持在秒级。
而线上运行的原系统集群规模达 13 台，在同样的数据写入情况下，CPU 利用率 30% 左右、写入吞吐仅 30 万条/s，并且存在高峰期 CPU Load 高、系统响应慢的问题。
根据测试结果，我们预估架构替换为 Apache Doris 后保持同样 30% 的 CPU 占用，只需要 3 台服务器即可满足写入需求，机器资源成本至少节约 70%。值得注意的是，在测试中对 Apache Doris 表中一半字段开启了倒排索引，如果不开启倒排索引的话，写入性能在之前基础上还能够再提升 50% 左右。
2、存储成本降低近 40%
在看到写入性能的大幅提升后，Apache Doris 存储空间占用也给我们带来了惊喜。在开启倒排索引的前提下，存储空间比原系统不具备倒排索引还要略低，压缩比从 1 : 4.3 提高至 1 : 5.7。
通过对比 Apache Doris 在磁盘上存储的文件大小，同一份数据的索引文件 (.idx) 与数据文件 (.dat) 大小相差无几。换言而之，增加索引后 Doris 数据膨胀率大约在 1 倍左右，与许多数据库和检索引擎 3-5 倍的膨胀率相比，Doris 的数据存储空间占用相对较低。经过研究发现，Apache Doris 采用了列式存储和 ZSTD 压缩算法来优化存储空间占用。Doris 将原始数据和倒排索引都以列的形式存储，使同一列的数据被存储在相邻位置，从而实现了更高的压缩率。
ZSTD 是一个优秀的新型压缩算法，使用了智能优化算法，相较于常见的 GZIP 算法， ZSTD 具有更高的压缩率和更快的解压速度，尤其在处理日志场景时表现非常出色。
3、查询性能平均提升 690%
对于业务最关注的查询性能，我们从线上查询日志进行去重后分析出 79 条 SQL，在同一天总数据（1000 亿条）、同样规模的集群（10 BE 节点）上对比测试 Apache Doris 与原系统的查询耗时。
发现与原系统相比，所有的查询语句均有明显提升，整体查询性能提升近 7 倍，有 26 条 SQL 查询语句性能提升 10 倍以上，其中 8 条 SQL 查询提升 10-20 倍、14 条 SQL 查询提升 20-50 倍、还有 4 条 SQL 查询提升 50 倍以上。最大差异的一条 SQL 查询语句为 Q43，在原系统中执行时间接近一分钟，在 Apache Doris 中仅需不到 1 秒，其性能差异高达到 88 倍。
针对性能提升幅度高的查询，我们进行了对比分析并发现了其中几个共同点：倒排索引对关键词查找的加速：Q23、Q24、Q30、Q31、Q42、Q43、Q50 等
-- 例如q43 提升88.2倍
SELECT count() from table2
WHERE ( event\_time >= 1693065600000 and event\_time < 1693152000000)
AND (rule\_hit\_big MATCH 'xxxx');
这种基于倒排索引进行关键词检索的技术，相较于基本的暴力扫描后进行文本匹配具有显著的优势，一方面极大地减少了需要读取的数据量；另一方面，在查询过程中无需进行文本匹配操作，因此查询效率往往提升一个数量级甚至更高。
NGram BloomFilter 索引对 LIKE 的加速：Q75、Q76、Q77、Q78 等
-- 例如q75 提升44.4倍
SELECT * FROM table1
WHERE ent_id = 'xxxxx'
AND event_date = '2023-08-27'
AND file_level = 70
AND rule\_group\_id LIKE 'adid:%'
ORDER BY event_time LIMIT 100；
对于要查找的非一个完整关键词的场景，LIKE 仍然是有用的查询方式，Apache Doris 的 NGram BloomFilter 索引能对常规的 LIKE 进行加速。
NGram BloomFilter 索引与普通 BloomFilter 索引不同，它不是将整个文本放入 BloomFilter ，而是将文本分成连续的子串，每个子串长度为 n ，并将他们放入 NGram BloomFilter 中。对于 cola LIKE '%pattern%' 的查询，将'pattern' 按照同样的方式分成长度为 n 的子串，判断每个子串在 BloomFilter 中是否存在，如果有一个子串不存在，则说明 BloomFilter 对应的数据块中没有跟'pattern' 匹配的数据块，因此通过跳过数据块扫描的步骤，达到加速查询的效果。
满足条件的最新 TopN 条日志明细查询优化：Q19-Q29 等
-- 例如q22，提升50.3倍
SELECT * FROM table1
where event\_date = '2023-08-27' and file\_level = 70
and ent\_id = 'nnnnnnn' and file\_name = 'xxx.exe'
order by event_time limit 100;
这种 SELECT * FROM t WHERE xxx ORDER BY xx LIMIT n 的查询，在查找满足某种条件的最新 n 条日志时使用频率非常高，Apache Doris 针对这种 SQL 查询模式进行了专门的优化，根据查询的中间状态确定排序字段的动态范围，并利用自动动态谓词下推的方式，避免读全部数据进行排序取 TopN，从而减少需要读取的数据量（有时甚至可以减少一个数量级），进而提升了查询效率。
4、可视化运维管控和可视化查询 WebUI，最大化减少运维和探索分析成本
为了提高日常集群维护的效率，我们使用了飞轮科技免费开放的可视化集群管理工具 Cluster Manager for Apache Doris （以下简称 Doris Manager ）。Doris Manager 提供的功能可以满足日常运维中集群监控、巡检、修改配置、扩缩容、升级等操作，降低登陆机器手动操作的麻烦和误操作风险。
除了管控 Apache Doris 集群之后，Doris Manager 还集成了类似 Kibana 的可视化日志探索分析 WebUI，对于习惯 ELK 日志分析的用户非常友好，支持关键词检索、趋势图展示、趋势图拖拽日期范围、明细日志平铺和折叠展示、字段值过滤等交互方便的探索式分析，跟日志场景探索下钻的分析需求很契合。
总结与规划
在跟随 Apache Doris 2.0-alpha，2.0-beta，2.0 正式版本发布的节奏，我们根据业务场景进行了详细的评测，也为社区反馈了不少优化建议，得到社区的积极响应和解决。系统经历试运行一个月之后，我们将 2.0.1 版本正式用于生产环境，替换了原系统集群，完成架构升级改造，实现了写入性能、查询性能、存储成本、运维成本等多方面收益：
1.写入性能提升 3 倍以上：目前，奇安信的日志分析平台每日平均有数千亿的新增安全日志数据，通过 Doris 的 Routine Load 能够将数据实时稳定写入库，保障数据低延迟高吞吐写入。
2.查询性能平均提升 7 倍：查询响应时间大幅减少，与之前的查询效率相比达到平均 7 倍提升，其中业务特别关注的全文检索速度达到 20 倍以上的提升，助力日志分析与网络安全运营效率。
3.高效便捷的可视化管理：Cluster Manager for Apache Doris 工具提供了可视化集群监控告警平台，满足日常集群监控等一系列操作，同时 WebUI 多种功能为分析人员提供了操作简单、使用便捷的交互式分析。总而言之，Doris 的易用性、灵活性大幅降低了开发、运维、分析人员的学习与使用成本。
后续还将在日志分析场景下探索更多 Apache Doris 的能力。我们将扩大 JSON 数据类型的相关应用，加强系统对于半结构化数据深度分析的能力。同时也非常期待 Apache Doris 2.1 版本中新增的 Variant 可变数据类型，支持存储任意结构的 JSON 数据，支持字段个数与类型的变化，让业务人员灵活定义特殊字符，以更好地实现半结构数据 Schema Free 的分析需求。
非常感谢 SelectDB 团队一直以来对我们的技术支持，助力奇安信走向 “体系化防御、数字化运营” 的网络日志安全管理，帮助客户准确识别、保护和监管网络设备与各类系统，确保业务人员在任何时候都能够安全、可信、稳定地访问数据与业务。
最后，我们也将持续参与到 Apache Doris 社区建设中，将相关成果贡献回馈社区，希望 Apache Doris 飞速发展！
长安汽车基于 Apache Doris 的车联网数据分析平台建设实践
导读：随着消费者更安全、更舒适、更便捷的驾驶体验需求不断增长，汽车智能化已成必然趋势。长安汽车智能化研究院作为长安汽车集团有限责任公司旗下的研发机构，专注于汽车智能化技术的创新与研究。为满足各业务部门的数据分析需求，长安汽车基于 Apache Doris 升级了车联网数据分析平台，支撑单日百亿级别数据实时处理，并实现十亿级别数据查询秒级响应，为长安汽车在提升用户用车体验、实时预警车辆故障、保证车辆安全驾驶等方面带来显著成果，为其在智能化方向的技术创新提供了有力支持。
作者｜长安汽车智能化研究院
智能化是汽车工业进程中的一场革命，它旨在利用大数据、人工智能、云计算、物联网等前沿数字技术，对汽车设备和系统的运行状态进行全方位的感知、分析、决策和控制，从而提高汽车的安全性、舒适性、便捷性和节能性。
长安汽车智能化研究院作为长安汽车集团有限责任公司旗下的研发机构，专注于汽车智能化技术的创新与研究，其愿景是通过持续创新和技术突破，实现汽车智能驾驶、智能网联和智能交通的全面发展，为消费者提供更安全、更便捷、更智能的出行体验，并致力于成为中国汽车智能化领域的领军企业。
实现汽车智能化的关键之一，是需要建立稳定、高效的数据平台，以承载和利用海量的车联网数据。作为智能化发展的重要支撑，长安汽车智能化研究院肩负着整个长安汽车集团车联网数据的汇聚、处理和应用工作。为满足各业务部门提出的数据支持需求，目前已经构建了车联网数据分析平台，并在业务指标分析、质量管理系统、智慧能耗、智能诊断、智慧运营等多个重点领域实现数据应用。
本文将详细介绍长安汽车车联网数据分析平台的演进历程及实践经验，分享长安汽车基于 Apache Doris 支撑单日百亿级别数据实时处理、实现十亿级别数据查询秒级响应的实践经验。此外，Apache Doris 的引入还为长安汽车在用户用车体验提升、驾驶安全保障等方面带来显著收益，为长安汽车从机电化到智能化转型发展提供有力支持。
汽车智能化所面临的挑战
近些年来，长安汽车取得了令人瞩目的销量增长成绩。1-8 月，长安汽车自主乘用车累计销量超百万辆、保持持续上升的发展势头，以深蓝、阿维塔、启源为代表的新能源系列品牌力和产品竞争力不断提升，自主新能源车累计销量约为 25.6 万辆、同比增长 102.44%，成为销量增长新动能。
在汽车销量快速攀升的背后，车联网数据更是呈现爆发式增长的态势，其中最为核心的即车辆 CAN 总线数据。CAN 即 Controller Area Network，通过 CAN 总线可以对车辆上的各类电子控制系统进行统一通信，在实际车辆运行过程中 ，CAN 总线数据是车辆安全性、可靠性和高性能的重要保证：
1.车辆系统监测和控制：CAN 总线数据可用于监测和控制系统中的各种设备和组件。传感器通过 CAN 总线发送其测量值，如温度、压力、位置等，以便其他设备或控制器实时监测和采取相应的措施。同时，控制器可以通过 CAN 总线向执行器发送控制指令，如调节阀门、驱动电机等，以实现对系统的控制。
2.车辆信息实时反馈：CAN 总线数据可用于提供实时反馈信息。例如在车辆控制系统中，传感器通过 CAN 总线传输车速、转向角度、制动状态等数据，控制器可以根据这些数据进行实时决策和调整，以确保车辆的安全性和性能。
3.数据共享和协调：CAN 总线数据允许不同设备之间进行数据共享和协调。通过 CAN 总线，不同的控制器和设备可以交换信息，共享状态和控制命令，有利于提高系统的整体性能和效率。
4.网络管理和故障诊断：CAN 总线数据用于网络管理和故障诊断。通过 CAN 总线，可以进行设备的自动识别、配置和监控，以便进行网络管理和故障排查，提高系统的可靠性和可维护性。
随着网联车销量不断增长，车辆每天将产生千亿级别的 CAN 数据，清洗处理后的数据也在 50 亿级别，面对如此庞大且持续膨胀的数据规模，如何从海量数据中快速提取挖掘有价值的信息，为研发、生产、销售等部门提供数据支持，成为当前亟需解决的问题。而想要提供良好的数据支持及服务，首先需要应对以下几大挑战：
1.大规模数据实时写入及处理：为实现智能化，汽车的车门、座椅、刹车灯设备被设置了大量的传感器，每个传感器收集一种或者多种信号数据，数据被汇聚后进一步加工处理。目前长安汽车需要支持至少 400 万辆车的链接，车联网数据每秒吞吐量已达百万级 TPS ，每日新增数据规模高达数十 TB ，且还在持续增长中。如何对数据进行实时写入成为了长安汽车首要面临的挑战。
2.准确及时的实时数据分析需求：车联网场景下数据分析通常要求实时性，快速获取分析结果是实时监控、故障诊断、预警和实时决策等服务的重要保障。例如在智能诊断中，车企需要近实时地收集相关信号数据，并快速定位故障原因。通过分析车辆传感器数据、行驶记录等，可以提前发现潜在故障，进行预防性维护，提高车辆的可靠性和安全性。
3.更加低廉的数据存储和计算成本：面对快速增长的的数据以及日益强烈的全量写入和计算需求，导致数据存储和计算成本不断攀升。这就要求数据平台具备低成本存储和计算的能力，以降低使用成本；同时需具备弹性伸缩能力，以便用户在业务高峰期快速扩容，提升海量数据计算场景的分析效率。
为给用户提供更优质的驾车体验、为业务部门提供更准确高效的数据支持，长安汽车开始对大数据平台的建设进行探索和实践。
Hive 离线数据仓库难以支撑超大规模实时数据服务
长安汽车最早以 Hive 为核心构建了数据平台架构，所处理数据包括车辆 CAN 总线数据和埋点数据，这些数据通过 4G 网络从车端传送至长安云端网关，然后由网关将数据写入 Kafka。考虑到数据量级和存储空间的限制，早期架构中的数据处理流程是将 Kafka 采集到的数据直接通过 Flink 进行处理，并通过 ETL 将结果存储到 Hive 中。下游应用使用 Spark SQL 进行逐层离线计算，并通过 Sqoop 将汇总数据导出到 MySQL 中。最终由 Hive 和 MySQL 分别为应用层提供数据服务。
尽管该架构在早期基本满足了数据处理需求，但随着车辆销量不断增长，当需要面对每天千亿级别的数据处理分析工作时，架构的问题逐步暴露出来：
1.数据时效性无法保证：Hive 的导入速度较慢，尤其在处理大规模数据时，导入时间明显增加；同时部分业务依赖 T+1 离线任务，无法满足实时数据处理需求；此外， Hive 只支持分区覆盖，不支持主键级别的数据更新，无法满足特殊场景的数据更新需求。
2.数据查询分析延迟较高：对于 10 亿级别以上大规模表查询，Hive 查询性能较慢。通过 SparkSQL 进行数仓分层运算时，启动和任务执行时间较长，对查询响应也会产生影响。此外，数据看板、BI 展示应用无法直接从 Hive 中查询，需要将 Hive 中数据导出到 MySQL 中，由 MySQL 提供服务，受限于 Hive 导数性能，当数据量较大时，导出到 MySQL 耗时大幅增加，进而导致查询响应时间变长。此外，通过 Java 后端查询 MySQL 时，数据量过大也会影响数据的响应时间。
追根究底，产生这些问题的根本原因在于早期架构无法满足超大规模实时数据场景下的数据需求，这迫使长安汽车必须进行平台升级改造。
技术调研与选型
长安汽车经过深入调研，决定引入开源实时数据仓库 Apache Doris ，在导入性能、实时查询等方面具有显著优势：
1.丰富的数据导入方式：Doris 提供了丰富的内置导入方式，如 Broker Load 和 Stream Load 等，可以满足实时和离线场景中数据导入需求。
2.支持实时查询分析：Doris 大表 Join 能力突出，提供了多种分布式 Join 方式，使 Join SQL 编写具备高度灵活性，极大提升数据分析的效率。此外，Doris 支持单节点上万 QPS 的超高并发，可解决早期架构由于前端并发量过大导致查询失败的问题。
3.较低的使用成本：Doris 兼容 MySQL 协议，开发人员可以更高效便捷的使用 MySQL 编写和执行查询语句，有效提高开发效率。基于 Doris 极简的架构，不仅让部署运维更加简单，也让扩缩容操作变的更加方便弹性。同时，Doris 拥有良好的上下游生态，可为用户提供灵活高效的数据管理和分析体验。这些优势和特性都极大的降低了 Doris 的使用成本。
除此以外，开源社区的活跃度也是我们考虑的重要因素之一 。Apache Doris 吸引了大量的开发者及用户参与社区，共同贡献代码和改进 Doris，这对质量和稳定性的提高起关键作用。同时Doris 社区为用户提供了全面的文档资料和技术支持，任何问题都可以快速得到解答和帮助。Apache Doris 的活跃程度使我们在使用时更加放心，解决了技术方面的后顾之忧。
基于 Apache Doris 车联网数据分析平台
在新的车联网数据分析平台中，通过 Flink 结合 Doris 的 Stream Load 功能，可直接将 Kafka 数据实时写入 Doris，同时，利用 Doris Broker Load 功能可以将 Hive 中数据导入到 Doris 中进行分析计算。在这个架构中，Apache Doris 承担了实时数据部分的计算和处理，还作为结果端直接输出数据给上游业务平台调用。
这一升级在系统上缩短了数据处理的路径，保证了大规模数据导入的时效性。此外，Apache Doris 的引入为上游应用层提供统一数据服务支持，这对于查询分析效率的提升至关重要。具体收益如下：
1.便捷进行数据写入和迁移：Doris 支持丰富的数据导入形式，可轻松从不同的数据源中导入数据。其次，Doris 支持通过 insert into select 快速导入数据，无需进行繁重的数据迁移配置以及引入外部同步组件。
2.统一数据服务，秒级查询响应：通过 Doris Multi-Catalog 功能，数据分析师可直接从 Doris 上查询数据，实现秒级别查询响应。其次，Doris Join 能力优异，对于超过 1000 万的结果表查询也可实现秒级返回结果。
3.降低存储和计算成本：在早期架构中，使用 Flink 实时写入数据并进行压缩时需要消耗大量的计算资源。而引入 Apache Doris 后，借助 Doris ZSTD 压缩算法（3-5 倍压缩率提升），可有效降低计算和存储所需的资源，还可以将压缩处理流程放到 Doris 内部进行，无需消耗 Flink 计算资源。
从 T+1 到 T+0，实时数据提升智能驾驶体验
CAN 总线数据在车辆分析中扮演着关键的角色，通过 CAN 总线可以读取车辆的各种状态信息，例如车速、转速、水温等。这些数据对于分析车辆的行驶数据具有重要的价值，为整车研发单位提供宝贵的参考信息。
在早期架构中，车辆 CAN 数据是按照 CAN ID 作为维度进行上传的，而在实际使用中，通常需要将不同 CAN ID 的信号按照时间对齐形成一个宽表。过去的数仓架构解决方案会先将 Kafka 中的数据写入到 Hive，此时不同 CAN ID 的数据被存储在不同的行中，需要使用 SparkSQL T+1 将数据转换为几个不同业务域的宽表。然而，这种计算方式耗时较长，SQL 语句难以维护，且数据的实时性较差。
在引入 Apache Doris 之后，我们在 Doris 中基于 Aggregate 聚合模型建立了业务域的宽表，将车辆和时间等作为主键，其他的信号字段都用 REPLACE_IF_NOT_NULL 定义。具体如下：
首先，可以使用 Flink 来消费 Kafka 中按 CAN ID 维度的数据，在 Flink 中根据业务域宽表的配置对数据进行分流，将同一个 CAN ID 上的信号分配到相应的业务域宽表中。当同一个车辆在同一时间内不同 CAN ID 的数据到达同一个业务域宽表时，可以将这些数据填充到同一行中的不同 CAN ID 的信号数据字段中，实现宽表的构建（如上图 Doris 的表示例）。
在这种方式中，主要通过 Flink 对数据进行分流，将数据发送到不同的 Doris 业务域宽表中（每个宽表约有 200 个字段）。宽表的生成逻辑被放在了 Doris 中，而不是在 Flink 中进行宽表对齐的操作。这样设计的原因是不同 CAN ID 的数据上传存在一定的时间差，时间窗口过大时，使用 Flink 根据车辆和时间进行聚合可能会导致资源开销过高。
通过以上方案，可以将数据的新鲜度从 T+1 提高到 T+0 。同时，对于包含约 10 亿行数据的宽表，可以达到秒级的查询效率，即在进行单车查询时，可以快速地获取查询结果。
10 亿级别 DTC 故障码实时查询，保障车辆驾驶安全
DTC 属于 CAN 数据中的故障报文，因此对其进行单独的业务数据存储。每天的 DTC 数据量级可以达到 10 亿条，为了让业务端便捷高效的使用这些数据，快速进行故障诊断，提升车辆安全性，需要将 DTC 故障码明细数据与一张 MySQL 业务配置表进行关联。
在早期架构中，开发人员每天都需要将海量 DTC 数据先写入到 Kafka 中，然后通过 Flink 进行实时处理，并将结果存储到 Hive 中。而这种处理方式存在一些问题：
1.面对 10 亿级数据量的表，难以将其导入 MySQL 进行实时查询。如果直接查询 Hive，则查询反馈时间会非常长，难以满足业务需求。
2.由于无法直接关联 MySQL 的配置表，不得不定时将配置表导入 Hive 数仓。这样做虽然能够满足数据处理的需求，但却丢失了 DTC 配置的实时性。
在引入 Apache Doris 后，采用上图所示处理方式成功解决了早期架构存在的问题。首先将 Hive 的 DTC 明细数据通过 HDFS 文件导入的方式导入到 Doris 中，然后创建对应的 MySQL Catalog 连接，最后使用后端 Java 通过 MyBatis 连接 Doris 数据库，并使用 SQL 通过 Catalog 连接 MySQL 的 DTC 配置表进行 Join 操作，可直接实时查询返回结果。
通过 Apache Doris 成功完成了 10 亿级别数据的实时查询，并且可以对关联的 MySQL 配置表进行直接关联查询，成功实现了配置的实时更新。
总结与规划
凭借 Apache Doris 卓越的性能，目前在长安汽车已经部署数十台机器，支撑了近十条业务线，每天处理数据规模达到百亿级别。 Apache Doris 的引入为长安汽车在提升用户用车体验、实时预警车辆故障、保证车辆安全驾驶等方面带来显著成果，为其在智能化方向的技术创新提供了有力支持。
未来长安汽车将进一步将 Apache Doris 应用在标签和指标业务，实现以下需求：
1.自动识别冷热数据：将热数据存储在 Apache Doris 中，冷数据存储在 Hive 中，通过这种方式实现更高效的数据访问和管理。
2.扩大业务范围：对现有的 Doris 业务 SQL 代码进行优化，利用 Doris 的某些特性和功能，将适合这些特性的业务迁移到 Doris 中，从而提高数据处理和查询的效率。
3.共建社区：积极尝试使用 Doris 最新版本及新功能，在与社区保持同步的同时，不断探索和应用新的技术，反哺社区、为社区发展做出贡献。
查询提速 11 倍、资源节省 70%，Apache Doris 在网易日志和时序场景的实践
作者｜隐形（邢颖），网易资深数据库内核工程师
编辑整理｜SelectDB 技术团队
导读：作为网易重要的业务线，灵犀办公和云信针对大规模日志/时序数据处理和分析的挑战，分别构建了灵犀 Eagle 监控平台和云信数据平台。本文将重点介绍 Apache Doris 在网易日志和时序场景中的应用，如何使用 Apache Doris 替换 Elasticsearch 和 InfluxDB，从而实现更低的服务器资源以及更高的查询性能体验，相较于 Elasticsearch，Apache Doris 查询速度至少提升 11 倍，存储资源的节省高达 70%。
随着信息技术的飞速发展，企业数据量呈现爆炸式增长。对于像网易这样规模庞大的互联网公司，无论是内部办公系统还是外部提供的服务，每天都会产生大量的日志和时序数据。这些数据已成为故障排查、问题诊断、安全监测、风险预警以及用户行为分析及体验优化的重要基石。充分挖掘这些数据的价值，有利于提升产品的可靠性、性能、安全性以及用户满意度。
灵犀办公和云信作为网易重要的业务线，分别构建了灵犀 Eagle 监控平台、云信数据平台来应对大规模日志/时序数据在处理分析时带来的挑战。而随着业务的持续扩张，日志/时序数据也呈井喷式增长，随之带来的是存储成本增高，查询时间延长、系统稳定性变差等问题。早期的平台已难以为继，这促使网易寻找更加优质的解决方案。
本节将聚焦于 Apache Doris 在网易日志和时序类场景中的落地，分别介绍它在网易灵犀办公、网易云信业务中的架构升级实践，并结合实际场景分享建表、导入、查询等方面的调优方案。
早期架构及痛点
1、灵犀 - Eagle 监控平台
网易灵犀办公是全新一代邮件协同办公平台。整合了邮箱、日历、云文档、即时消息、客户管理等模块。Eagle 监控平台是一个全链路 APM 系统，可为网易灵犀办公提供多维度、不同粒度的性能分析。
Eagle 监控平台主要对灵犀办公、企业邮、有道云笔记、灵犀文档等业务日志数据进行存储分析，日志数据首先通过 Logstash 采集并处理，然后存储到 Elasticsearch 中，由 Elasticsearch 进行实时日志检索及分析，并为灵犀办公提供日志搜索以及全链路日志查询等服务。
随着时间的推移、日志数据的增长，在使用 Elasticsearch 的过程中逐渐暴露出一些问题：
1.查询延迟高：在日常查询中，Elasticsearch 平均响应延迟较高，影响使用体验。这主要受到数据的规模、索引设计的合理性以及硬件资源等因素的制约。
2.存储成本高：在降本增效的大背景下，业务对降低存储成本的需求日益迫切。但由于 Elasticsearch 存在正排、倒排、列存等多份数据存储，数据冗余程度较高，给降本提效带来了一定的挑战。
2、云信 - 数据平台
网易云信是集网易 26 年技术打造的融合通信与云原生 PaaS 服务专家，提供融合通信与云原生核心产品及解决方案，包含 IM 即时通讯、视频云、短信，及轻舟微服务、中间件 PaaS 等。
云信数据平台主要是对 IM、RTC、短信等服务所产生的时序数据进行分析。早期数据架构主要基于时序数据库 InfluxDB 搭建，数据源首先通过 Kafka 消息队列进行上报 ，经字段解析和清洗之后，存储到时序数据库 InfluxDB 中，以提供在线和离线查询。离线侧支持离线 T+1 数据分析，实时侧需提供指标监控报表及账单的实时生成。
在客户规模的快速覆盖下，上报的数据源也持续增加，InfluxDB 同样面临一系列新的挑战：
1.内存溢出 OOM：随着数据源的增多，需要基于多个数据源进行离线分析，分析难度随之增加。受限于 InfluxDB 的查询能力，当前架构在面对多个数据源的复杂查询时，可能会导致内存溢出（ OOM），这给业务的可用性及系统的稳定性带来巨大的挑战。
2.存储成本高：业务的发展也带来集群数据量的不断增长，而集群中较大比例数据为冷数据，冷热数据采用同一种方式进行存储，导致了高昂的存储成本，这与降本增效的企业目标相悖。
核心引擎的选型
为此网易开始寻找新的数据库解决方案，旨在解决上述两大业务在日志时序类场景所面临的挑战。同时，网易期望只用一个数据库，能够适配两大应用场景的业务体系及技术架构，满足极简易用、低成本投入的升级需求。在这方面，Apache Doris 符合我们的选型要求，具体表现在以下几个方面：
1.存储成本优化：Apache Doris 在存储结构上面进行了许多优化，减少了冗余存储。具有更高的压缩比，且支持基于 S3、NOS （网易对象存储服务 Netease Object Storage）的冷热分层存储，可有效降低存储成本，提高数据存储效率。
2.高吞吐高性能：Apache Doris 支持列式存储高性能磁盘写入、时序 Compaction 以及 Stream Load 高效流式导入，能够支持每秒数十 GB 的数据写入。这样既能保证日志数据的大规模写入，同时还能够提供低延迟的查询可见性。
3.实时日志检索：Apache Doris 不仅能够支持日志文本的全文检索，还能够实现实时查询响应。Doris 支持在内部增加倒排索引，可以满足字符串类型的全文检索和普通数值/日期等类型的等值、范围检索，同时可进一步优化倒排索引的查询性能、使其更加契合日志数据分析的场景需求。
4.支持大规模租户隔离： Doris 可承载数千数据库以及数万数据表，并能够实现一个租户独立使用一个数据库，满足多租户数据隔离的需求，保证了数据的隐私性和安全性。
除此之外，近一年以来， Apache Doris 在日志场景持续深耕，推出了一系列核心能力，如高效的倒排索引、灵活的 Variant 数据类型等，为日志/时序数据的处理分析提供了更高效、灵活的解决方案。综合以上优势，网易最终决定引入 Apache Doris 作为全新架构核心引擎。
基于 Apache Doris 的统一日志存储和分析平台
1、灵犀 - Eagle 监控平台
首先，在灵犀办公 - Eagle 监控平台中，网易成功将 Elasticsearch 全面升级为 Apache Doris，从而构建了统一的日志存储和分析平台。这一架构升级不仅显著提升了平台的性能与稳定性，更为其提供了强大且高效的日志检索服务。具体收益体现在：
1.存储资源节省 70%：得益于 Doris 列式存储和 ZSTD 高压缩比，存储同样的日志数据，Elasticsearch 需要 100T 存储空间，而存储到 Doris 中仅需要 30T 存储空间，存储资源节省 70%。由于存储空间大幅节省，在同样的成本下可以使用 SSD 代替 HDD 存储热数据，又带来更大的查询性能提升。
2.查询提速 11 倍：新架构以更低的 CPU 资源消耗带来了数十倍的查询效率提升。从下方示意图可知，最近 3 小时、1 天 、7 天的日志检索，Doris 查询耗时保持稳定且均低于 4s，最快可在 1s 内响应。而 Elasticsearch 查询耗时呈现出较大的波动，最长耗时高达 75s，即使最短耗时也需要 6-7s。在更低的资源占用下，Doris 的查询效率至少是 Elasticsearch 的 11 倍。
2、云信 - 数据平台
在云信数据平台中，网易同样使用 Apache Doris 替代了早期架构中的时序数据库 InfluxDB，将其作为数据平台核心存储和计算引擎，由 Apache Doris 统一提供离线和实时查询服务。
1.支持高吞吐写入：线上平均 500M/s、峰值 1GB/s 的写入流量，InfluxDB 使用 22 台服务器，CPU 资源使用率约 50%，而 Doris 仅使用 11 台机器，CPU 使用率约 50%，整体资源消耗仅仅为之前的 1/2。
2.存储资源节省 67%：使用 11 台 Doris 物理机替换了 22 台 InfluxDB ，存储同样的数据规模，InfluxDB 需要 150T 存储空间，而存储到 Doris 中仅需要 50T 存储空间，存储资源节省 67%。
3.查询响应快且更稳定：为验证其查询响应速度，随机挑选一个线上 SQL（最近 10min 匹配一个字符串），对该 SQL 连续查询 99 次。从下图可知，Doris（蓝色）的查询性能比 InfluxDB（红色） 更稳定，99 次查询均比较平稳、没有明显波动，而 InfluxD 出现多次异常波动，查询耗时直线上升，查询稳定性受到严重影响。
实践及调优
在业务落地的过程中，网易也遇到一些问题及挑战。借此机会，将这些宝贵的优化经验整理并分享，希望对大家的使用有所指引及帮助。
01 建表优化
数据库 Schema 的设计对于性能至关重要，而在处理日志和时序数据时也不例外。Apache Doris 针对这两种场景提供了一些专门的优化选项，因此在表的创建过程中启用这些优化选项非常关键。以下是我们在实践中使用到的具体优化选项：
1.当使用 DATETIME 类型的时间字段作为主键 Key 时，查询最新 n 条日志的速度会得到显著提升。
2.使用基于时间字段的 RANGE 分区，并开启动态 Partiiton ，以便按天自动管理分区，提升数据查询和管理的灵活性。
3.在分桶策略上，可以使⽤ RANDOM 进行随机分桶，分桶数量大致设置为集群磁盘总数的 3 倍。
4.对于经常需要查询的字段，建议构建索引以提高查询效率；而对于需要进行全文检索的字段，应指定合适的分词器参数 parser，确保检索的准确性和效率。
5.针对日志类、时序类场景，使用专门优化过的时序 Compaction 策略。
6.采用 ZSTD 压缩，可以获得更好的压缩效果，节省存储空间。
CREATE TABLE log
(
ts DATETIME,
host VARCHAR(20),
msg TEXT,
status INT,
size INT,
INDEX idx_size (size) USING INVERTED,
INDEX idx_status (status) USING INVERTED,
INDEX idx_host (host) USING INVERTED,
INDEX idx_msg (msg) USING INVERTED PROPERTIES("parser" = "unicode")
)
ENGINE = OLAP
DUPLICATE KEY(ts)
PARTITION BY RANGE(ts) ()
DISTRIBUTED BY RANDOM BUCKETS 250
PROPERTIES (
"compression"="zstd",
"compaction_policy" = "time_series",
"dynamic_partition.enable" = "true",
"dynamic_partition.create_history_partition" = "true",
"dynamic_partition.time_unit" = "DAY",
"dynamic_partition.start" = "-7",
"dynamic_partition.end" = "3",
"dynamic_partition.prefix" = "p",
"dynamic_partition.buckets" = "250"
);
02 集群配置优化
FE 配置
# 开启单副本导入提升导入性能
enable_single_replica_load = true
# 更加均衡的tablet分配和balance测量
enable_round_robin_create_tablet = true
tablet_rebalancer_type = partition
# 频繁导入相关的内存优化
max_running_txn_num_per_db = 10000
streaming_label_keep_max_second = 300
label_clean_interval_second = 300
BE 配置
write_buffer_size=1073741824
max_tablet_version_num = 20000
max_cumu_compaction_threads = 10(cpu的一半)
enable_write_index_searcher_cache = false
disable_storage_page_cache = true
enable_single_replica_load = true
streaming_load_json_max_mb=250
03 Stream Load 导入调优
云信 - 数据平台在业务高峰期时，面临着高达 100 万以上的写入 TPS 以及 1GB/s 的写入流量，这无疑对系统性能提出了极高的要求。然而，由于业务侧存在众多小并发的表，且查询侧对数据的实时性要求极高，这使得在短时间内无法将批处理积攒到足够大的 Batch。联合业务方进行系列优化后， Stream Load 仍然难以迅速消费 Kafka 中的数据，导致 Kafka 中的数据积压现象日益严重。
经过深入分析，发现在业务高峰期，业务侧的数据导入程序已遭受性能瓶颈，主要体现在 CPU 和内存资源的过度占用。然而，Doris 侧的性能状况尚未出现显著的瓶颈，但 Stream Load 的响应时间却有明显的上升趋势。
由于业务程序是同步调用 Stream Load 的，这意味着 Stream Load 的响应速度直接影响着整体的数据处理效率。因此，如果能够有效降低单个 Stream Load 的响应时间，那么整个系统的吞吐能力将得到显著提升。
在与 Apache Doris 社区同学交流之后，了解到针对日志和时序场景，Doris 推出了两个重要的导入性能优化：
1.单副本导入：先写入一个副本，其他副本从第一个副本拉取数据。这种方式可避免多个副本重复排序、构建建索引所带来的开销。
2.单 Tablet 导入：相较于普通模式下数据分散到多个 Tablet 的写入方式，可采用一次仅写入单个 Tablet 的策略。这种优化减少了写入时产生的小文件数量和 IO 开销，进而提升了整体的导入效率。可在导入时设置 load_to_single_tablet 参数为 true 来启用这一功能。
在使用上述方式优化后，导入性能得到显著的提升：
消费 Kafka 速度提升超 2 倍
Kafka 的延迟时间显著下降，仅为原先耗时的 1/4
Stream Load 的 RT 减少约 70%
网易在正式上线前也开展了大压力测试和灰度试运行，经过持续不断的调优工作，最终确保系统能够在大规模场景下稳定上线运行，为业务提供强有力的支持。
1. Stream Load 超时：
在压测初期出现数据导入频繁超时报错的问题，且在进程及集群状态正常的情况下，监控无法正常采集 BE 的 Metrics 数据。
通过 Pstack 获得 Doris BE 的堆栈，并使用 PT-PMT 对堆栈进行分析。发现主要原因是当客户端发起请求时，没有设置 HTTP Chunked 编码 也没有设置 Content-Length，这导致 Doris 误认为数据传输尚未结束，从而一直处于等待状态。在客户端添加 Chunked 编码设置后，数据导入恢复正常。
2. Stream Load 单次导入数据量超过阈值：
通过调大 streaming_load_json_max_mb 参数到 250M（默认 100M ）后解决。
3. 副本不足写入报错： alive replica num 0 < quorum replica num 1
通过 show backends 发现有一台 BE 状态异常显示为 OFFLINE。查看对应的 be_custom 配置文件，发现其中存在 broken_storage_path。进一步检查 BE 的日志，发现报错信息提示 “too many open files”，这意味着 BE 进程打开的文件句柄数量已经超出了系统设定的最大值，从而导致 IO 操作失败。
当 Doris 系统检测到这种异常情况时，会将该磁盘标记为不可用状态。由于该表的配置是单副本策略，当唯一的副本所在磁盘出现问题时，就会因为副本数不足而无法继续写入数据。
因此，将进程 FD 最大打开限制调整到了 100 万，并删除 be_custom.conf 配置文件、重启该 BE 节点，服务最终恢复正常运行。
4. FE 内存抖动
在业务灰度测试期间，出现无法连接到 FE 的问题。通过查看监控数据，发现 JVM 32G 内存已经耗尽，同时 FE 的 meta 目录下 bdb 文件目录异常膨胀至 50G。
由于业务一直在进行高并发的 Stream Load 数据导入操作，而导入过程中 FE 会记录相关的 Load 信息，每次导入产生的内存信息约为 200K。这些内存信息的清理时间由 streaming_label_keep_max_second 参数控制，默认值为 12 小时，将它调小到 5 分钟后 FE 内存不会耗尽，但是运行一段时间后，发现内存按照 1 小时为周期进行抖动，高峰内存使用率达到 80%。分析代码发现清理 label 的线程每隔 label_clean_interval_second 运行一次，默认为 1 小时，把它也调小到 5 分钟后，FE 内存很平稳。
04 查询调优
当灵犀 - Eagle 监控平台在进行查询测试的时候，疑似读取到了不符合匹配条件的结果，这一现象显然不符合预期的检索逻辑。如下图第一条记录：
起初误以为是 Doris 的 Bug，于是尝试搜索类似的 issue 及规避方案。然而，在咨询社区成员并仔细查阅官方文档后，发现问题的根源是对 match_all 使用场景的理解存在误区。
match_all 的工作原理是只要存在分词就能进行匹配，而分词是依据空格或标点来进行的。在该案例中，match_all 中的 '29' 与第一条记录后续内容中的 '29' 进行了匹配，从而输出了不符合预期的结果。
针对该 Case，正确的方式是使用 MATCH_PHRASE 进行匹配，MATCH_PHRASE 可以满足文本中的顺序要求。
-- 1.4 logmsg中同时包含keyword1和keyword2的行，并且按照keyword1在前，keyword2在后的顺序
SELECT * FROM table_name WHERE logmsg MATCH_PHRASE 'keyword1 keyword2';
在使用 MATCH_PHRASE 进行匹配时，建索引时需指定 support_phrase，否则系统会进行全表扫描并进行硬匹配，查询效率较差。
INDEX idx_name4(column_name4) USING INVERTED PROPERTIES("parser" = "english|unicode|chinese", "support_phrase" = "true")
对于已经写入数据的表，若希望启用 support_phrase，可以执行 DROP INDEX 来删除旧的索引，随后使用 ADD INDEX 添加新的索引。这一过程是在已有表上增量进行，无需重写整个表的数据，从而确保了操作的高效性。
相较于 Elasticsearch，Doris 的索引管理方式更为灵活，能够根据业务需求快速添加或删除索引，提供了更大的便利性和灵活性。
结束语
Apache Doris 的引入，有效满足了网易对日志、时序场景的需求，有效解决了网易灵犀办公以及网易云信早期日志处理及分析平台存储成本高，查询效率低等问题。
在实际应用中，Apache Doris 以更低的服务器资源，承载了线上平均 500MB/s 、峰值超 1GB/s 的写入流量的平稳写入。同时，查询响应也得到了显著的提升，相较于 Elasticsearch ，查询效率至少提升了 11 倍。此外Doris具备更高的压缩比，存储资源相较之前可节约 70%。
最后，特别感谢 SelectDB 技术团队一直以来的支持。未来，网易将继续推广 Apache Doris，将其深入应用于网易其他大数据场景中。同时也期待能与更多对 Doris 感兴趣的业务团队展开深入交流，共同推动 Apache Doris 发展。