滴滴如何基于开源引擎，打造自主可控服务体系

本文作者：张亮 滴滴云-商业数据 负责人

2014年加入滴滴，负责过LogAgent、Kafka、ElasticSearch、OLAP的引擎建设工作，具有丰富的高并发、高吞吐场景的架构设计与研发经验，主持构建过任务调度系统、监控系统、日志服务、实时计算、同步中心等数据体系的平台设计与研发工作。

一、分享背景

在滴滴负责过LogAgent、Kafka、Flink、Elasticsearch、Clickhouse等开源大数据引擎服务体系建设工作，走过很多弯路，趟过很多坑，积累了一些实战经验；近年疫情肆虐，加速了企业数字化转型的步伐，与数十家互联网、金融、证券、教育企业进行了深度交流，大家对基于开源数据引擎建设自主、可控、安全的服务体系有强烈诉求，常见的困惑是如何基于开源引擎，结合企业特点与发展阶段，进行高ROI的服务体系建设。 

二、建设实践

滴滴基于开源引擎搭建大数据基础设施，始于数据驱动业务运营与商业决策的BI需求，随着实时数据流量达到百MB/S，存储达到PB级，开源数据引擎的服务运营会遇到各种各样的稳定性、易用性、运维友好性挑战。经历了四个阶段：引擎体验期、引擎发展期、引擎突破期、引擎治理期，不同阶段遇到的痛点问题与服务挑战各不相同：

• 引擎体验期：伴随业务快速发展，引擎的选择、版本的选择，机型的选择、部署架构的设计，复盘来看是早期稳定性工作的关键抓手。 
• 引擎发展期：随着引擎用户规模的增长，日常运营过程中的问题答疑、最佳实践落地、线上问题诊断消耗团队60%+的精力，亟需大数据PaaS层建设，降低用户引擎技术学习、应用、运维门槛，提升用户自助服务能力。
• 引擎突破期：随着集群规模的膨胀、业务场景的多元，势必触碰开源引擎的能力边界，亟需构建基于开源引擎的内部迭代机制，既需要与开源社区紧密协同，平滑版本升级，享受社区的技术红利，又需要在开源引擎的基础上进行BUG FIX与企业特性增强。
• 引擎治理期：随着PaaS平台的构建，引擎版本的快速迭代，会衍生三大类问题：未区分SLA场景的混用、超出引擎能力边界的误用、没有成本意识的滥用。导致引擎服务口碑低、资源（机器+人力）ROI业务价值低，亟需基于元数据驱动的引擎治理体系建设。

 

1、引擎体验期

解决特定技术问题的开源引擎众多，比如消息队列有Kafka、Pulsar、RocketMQ等，技术选型对于服务的SLA、运维保障至关重要，严重影响幸福感与价值感。 

1）引擎选择

要综合考虑社区的Star数、Contributor数，国内是否有PMC或Committer；应用的广泛度，有无众多大厂生产实践背书，线下Meetup是否频繁，线上问题答疑响应速度，线上最佳实践资料是否丰富，部署架构是否放精简等多种因素。

2）机型选择

业务从应用场景上可以分为IOPS场景与TPS场景，开源引擎可以分为CPU密集型、IO密集型、混合型。以分布式搜索引擎Elasticsearch为例，企业级搜索场景，随机IO频繁，对磁盘的IOPS能力要求高，SSD磁盘是刚需；CPU消耗需要根据查询复杂度、QPS来评估此业务场景对CPU的诉求；推荐的做法是模拟业务场景做BenchMark，摸底引擎在特定场景下的性能表现，为机型选择提供依据，下图是滴滴Elasticsearch引擎在做机型选择时的压测验证：

基于引擎原理与业内最佳实践建议，结合应用场景与压测结果，根据当下可选机型做选择，理想状态是CPU、磁盘容量、网络IO、磁盘IO资源均衡使用，尽量让CPU成为瓶颈。另外随着引擎的不断优化，软硬件基础设施的发展，机器过保置换是常态，最佳机型选择是一个动态演进的过程，滴滴运维保障团队2020年进行了新一轮机型优化与场景的调优，Elasticsearch日志集群成本降低了一半，CPU峰值平均利用率达到了50%。

3）部署选择

以Elasticsearch为例，最小高可用部署集群是3个节点，单节点承担Master Node、Client Node、 Data Node三种角色。一般3到5个节点集群规模影响不大，一旦到几十个节点，写入吞吐量达到百MB/S，节点网络处理线程池、内存资源竞争突显，元数据处理与索引数据处理资源未隔离，会导致集群元信息出现同步性能或一致性问题，进而诱发集群不可用，所以达到了一定体量后，需要考虑分角色部署。