Apache Doris在任子行的应用实践

孔繁艺高级研发工程师 分享嘉宾-任子行 高级研发工程师 背景介绍01架构演进02企业实践03总结规划04 目录 1-1公司介绍 任子行网络技术股份有限公司成立于2000年5月，2012年4月，在深圳证券交易所创业板正式挂牌上市，是国内网络安全行业领军企业，致力于成为国内领先的“网络空间数据治理专家”。 业务涵盖网络安全、公共安全、信息安全、运营商网络资源安全、终端安全、5G数据安全、工业互联网安全等众多领域，是国家重大活动网络安全服务支撑单位，也为“一带一路”海外友好国家政府提供网络安全解决方案。 1-2早期业务架构 1-3背景介绍 离线分析难度大 无法二次分析 数据孤岛 2-1架构演进：技术选型思考 •存在写入瓶颈，吞吐能力达不到预期；•对服务器的CPU，内存及磁盘的要求都比较高；•倒排索引导致存储成本较高，达不到降本增效的效果；•聚合计算场景能力一般，会出现聚合不准确的情况；•分析需要具备DSL能力，复杂场景SQL模式支持有限； •传统数仓架构实时性得不到很好的保证。•架构复杂度比较高，数据链路长。•缺乏湖生态的技术储备，预研周期较长。 2-1架构演进：技术选型思考 2-1架构演进：技术选型思考 2-2架构演进：数仓架构 245TB1.5TB200+亿 3-1企业实践：数据建模 DWS汇总层 DWS层跟据具体的数据特性在AggredateKey模型和UniqueKey模型之间进行选择。简单的去重和更新使用UniqueKey模型，指标语句和复杂数据合并使用AggredateKey模型； ADS层作为对外直接使用的应用层数据，我们主要沿用DuplicateKey模型和UniqueKey模型。点查和实时更新使用UniqueKey模型，周期全量计算结果表使用DuplicateKey模型； 每天有几千万上亿的半结构化数据需要摄入，Json深度及字段数量都不可控，因此ODS层我们选用了基础的DuplicateKey模型，快速稳定的完成原始数据存储； 3-2企业实践：写入吞吐问题 CREATETABLE`ods_xxx_post`(`post_id`VARCHAR(64)NOTNULLCOMMENT'帖子ID',`user_id`VARCHAR(64)NOTNULLCOMMENT'用户ID',`insert_date`DATENULLCOMMENT'入库日期',...,`create_date`DATENOTNULLCOMMENT'发布日期',`full_data`TEXTNULLCOMMENT'原始JSON',)DUPLICATEKEY(`post_id`,`user_id`,`insert_date`,`task_id`)PARTITIONBYRANGE(`insert_date`)DISTRIBUTEDBYHASH(`post_id`)BUCKETS16PROPERTIES("dynamic_partition.enable"="true","dynamic_partition.time_unit"="MONTH",...); CREATETABLE`ods_xxx_post`(`post_id`VARCHAR(64)NOTNULLCOMMENT'帖子ID',`user_id`VARCHAR(64)NOTNULLCOMMENT'用户ID',`create_date`DATENOTNULLCOMMENT'发布日期',...,`full_data`TEXTNULLCOMMENT'原始JSON',`insert_date`DATENULLCOMMENT'入库日期')DUPLICATEKEY(`post_id`,`user_id`,`create_date`,`task_id`)PARTITIONBYRANGE(`create_date`)DISTRIBUTEDBYHASH(`post_id`)BUCKETS16PROPERTIES("dynamic_partition.enable"="true","dynamic_partition.time_unit"="MONTH",...); 建表分区策略改为按照“处理时间”进行按月分区后，写入吞吐直线上升，compactioncore维持在100+左右，CPU负载水平也回落到正常负载，解决了写入吞吐低以及版本堆积导致的频繁写入失败问题。 3-3企业实践：数据更新问题 社交用户数据场景中，数据渠道较多，每种渠道的字段内容的稳定性不一，没有明显特征。假设用户数据有A，B，C，D，E五个字段，其中A为主键，同一用户在部分渠道中只能获取A，B，C字段，另一渠道下却只能获取A，B，D，E字段，并且相同渠道也会有不确定因素存在，因此DWS层的用户数据去重与合并是一大重要挑战。 3-4企业实践：离线迁移 HBasetoDoris 15亿的账号数据，128个分区，8个分区作为一批，DataX串行化执行，同步至Doris总耗时为6小时； ElasticsearchtoDoris 遇到数据类型的字段需要提前在Elasticsearch索引映射的_meta部分添加特定的Doris结构注释，使用REFRESH命令手动刷新元数据； 4-1总结规划：降本增效 经过多种类型数据的对比，存储成本能节省61%-76%之间。特别社交帖文数据场景下，Elasticsearch需要使用5.98TB磁盘内存，而在ApacheDoris只需要1.393TB，在保持高吞吐和实时性能的前提下，同等规模的数据，存储成本大幅度降低。 4-2总结规划：高效导数 4-3总结规划：统一分析平台 即席查询 自助BI 自助API 能够在数十亿级表中实时查看数据明细，通过关键词、时间、实体等纬度进行筛选。 只需要基于SQL定义输入输出，在线API测试这2步即可生成API。 基于SQL轻松完成BI报表、数据大屏的开发与输出。 4-4总结规划：高效计算 4-5总结规划：未来规划 接入日志分析业务 •节省日志数据的存储空间，支持更长的数据保存周期。•缓解数据高峰时期带来的数据写入瓶颈问题。•更加准确的分析结果。 •解决TEXT以及JSON类型在存储压缩水平上的不足。•替换使用JSON函数查询和解析数据的场景，提高半结构列的查询性能。 •迁移HBase点查业务，高并发点查场景统一由ApacheDoris支撑。 ThanksforWatching！