{
    "componentChunkName": "component---src-templates-blog-blog-detail-tsx",
    "path": "/blog/devcon-2021-shareit",
    "result": {"pageContext":{"blog":{"id":"Blogs_304","title":"TiDB 在茄子科技的应用实践及演进","tags":["DevCon"],"category":{"name":"案例实践"},"summary":"本文根据茄子科技存储负责人闫林林在【PingCAP DevCon 2021】上的演讲整理而成，介绍了茄子科技面向不同业态的数据库选型、TiDB 在 APM 场景的应用实践及茄子科技基于 TiKV 打造分布式 KV 系统的历程。","body":"> 本文根据茄子科技存储负责人闫林林在【PingCAP DevCon 2021】上的演讲整理而成\n\n## 背景介绍 – 公司介绍\n\n茄子科技（海外 SHAREit Group）是一家**全球化互联网科技公司**，主要从事**移动互联网软件研发与全球移动广告变现解决方案、跨境支付解决方案等互联网服务**等业务。茄子快传（SHAREit）是茄子科技旗下的代表产品， 是一款**一站式数字娱乐内容与跨平台资源分享平台**，累计安装用户数近 24 亿。茄子科技作为一家出海企业，已经在东南亚、南亚、中东以及非洲等地区，打造了多款工具和内容的应用，并且在 Google Play 的下载榜上常年名列前茅。\n\n## 背景介绍 – 业务特点及选型\n\n茄子科技的产品矩阵较多，产品形态相对比较复杂，包括了**工具、内容、游戏、广告、支付**等。针对相对复杂的业务场景，根据不同的业务形态，我们做了不同的数据库选型。目前，茄子科技使用的六款最主要的数据库包括：\n\n- **自研持久化 KV**：特征平台、用户画像、行为记录等 \n- **Redis Cluster**：业务缓存、session 信息等 \n- **Cassandra**：内容库 \n- **MySQL**： Hue、Metadata、运营平台等 \n- **ClickHouse**：数据分析、实时报表 \n- **TiDB**：用户增长、APM 系统、云账单等\n\n## TiDB的应用实践 – 业务痛点及 TiDB 的优势\n\n基于业务层面的痛点思考，我们在多个业务场景引入了 TiDB：  \n\n第一，茄子科技作为一家出海企业引入了多家**公有云**作为基础设施，所以在数据库的层面，要考虑业务在多云架构下的**业务适配、数据迁移、数据库的兼容以及数据同步**的问题。  \n第二，茄子有多款高流量的 APP 产品，业务呈现**高速增长**的态势，传统的 DRS 数据库，比如 MySQL，因为需要分库分表，阻碍业务快速发展。  \n第三，Cassandra、HBase 等 NoSQL 数据库，无法满足**分布式事务，多表 join** 等复杂场景。\n\n茄子科技的 APM 等系统，有一些是 HTAP 场景，同一份业务数据既有 OLTP 又有 OLAP 的需求，我们希望一套数据库可以搞定。\n\n引入 TiDB 之后，TiDB 在多个方面发挥出独特优势，帮助茄子科技打造可持续发展的数据库生态：\n- 利用 TiDB 的**跨集群迁移、数据同步**的能力打造多云架构下的业务扩展能力，满足多云架构下的业务架构设计。\n- TiDB 提供**自动水平弹性**扩展的能力，做到业务无感知，解决分库分表的问题。\n- TiDB 高度兼容 MySQL，在大容量、高并发的场景下学习成本低、迁移成本低。\n- 利用 TiDB HTAP 的能力，满足业务在一份数据上的 OLTP 与 OLAP 的双重需求。\n\n## TiDB的应用实践 – APM 场景应用\n\n茄子科技的 **APM（Application Performance Management）**系统提供 APP 崩溃、性能等问题的**监控、分析、看板、修复**的一体化能力，用来支撑多款高增长的 APP 应用。这个系统的第一个特点就是**信息量大**，每天产生百亿条的数据，需要保留 30 天；第二个特点是**时效性**要求比较高，针对一些比较棘手的情况，比如说崩溃以及严重的性能问题，如果时效性不能满足的话会直接影响到用户的体验，甚至是产品的营收；第三个特点是需要打通**工单系统，提供问题追踪、修复的一体化**能力；第四个特点是**在 OLTP 事务场景的基础上需要兼顾 OLAP 的分析场景**。\n\n首先分析一下早期 APM 的数据流转，从 APP 数据上报到日志收集，最后到 ClickHouse，整个数据流转是一个类似**批处理**的流程，大概需要两个多小时，整体时效性偏弱，问题暴露不及时，会对用户体验产生影响。另外，这套系统里面有 MySQL 和 ClickHouse 两套数据库。为什么这么设计？因为 ClickHouse 可以用来做**数据的分析聚合**，MySQL 主要是用来打造**流程工单**，同时有两套数据库在支撑，在成本上比较高。\n\n![qzkc-1.png](https://img1.www.pingcap.com/prod/qzkc_1_81328b2845.png)\n\n再来看引入了 TiDB 之后的新版 APM 数据流转，可以看到从 APP 的上报，到看板展示，到报警，再到流程工单，实现**分钟级**的准实时看版展示和报警。这部分主要是借助了 TiDB 的 HTAP 能力，通过聚合分析向看版进行展示，向报警中心进行及时的报警。同时，利用 TiDB 的 OLTP 能力进行看板的行更新。所以，我们可以通过一套 TiDB 数据库打通看版、监控、问题的追踪和修复流程。\n\n![qzkc-2.png](https://img1.www.pingcap.com/prod/qzkc_2_8288fc3fa3.png)\n\n ## 基于 TiKV 的演进 – 自研分布式 KV \n\n大家知道 TiKV 是 TiDB 的**存储层**，同时也是一个 Key-Value 数据库，接下来谈谈茄子科技基于 TiKV 打造分布式 KV 系统的历程。茄子科技主要是提供工具和内容产品，产生的数据量非常大，KV 存储需要支撑两类场景：一类是**数据的实时产生**，实时写入；另一类是针对**用户画像和特征引擎**，将离线产生的大批量数据快速地加载到在线的 KV 存储，为在线业务提供快速的访问，即 Bulk Load 能力，实际业务中需要**每小时 TB 级的吞吐量**。\n\n下图是茄子科技之前基于 Rocksdb 自研的分布式 KV，这个系统同时满足上述的两类对 KV 的需求。图中左边展示的架构主要是**实时写入能力的实现**，数据先从 SDK 到网络协议层，然后到拓扑层，再到数据结构的映射层，最后到 Rocksdb。右边是 Bulk Load 批量导入的流程。大家可能有一个疑问，为什么左边实时的写入流程不能满足小时级  TB  数据导入？主要原因有两点：一是因为 Rocksdb 的写放大，尤其在大key型场景下，Rocksdb写放大是非常严重的。另一点是受限于单块盘的网络带宽，导致了单机负载或者单机存储是有限的。右边**整个批量导入的能力**是怎么实现的？它是通过 Spark 把 Parquet 进行数据解析、预分片以及  SST 生成，把 SST 上传到 Rocksdb 的存储节点，最后通过 ingest & compact 统一加载到 KV 层，供在线的业务进行访问，单机吞吐每秒种可以达到百兆。\n\n![qzkc-3.png](https://img1.www.pingcap.com/prod/qzkc_3_25b4befd58.png)\n\n## 基于 TiKV 的演进 – 基于 TiKV 的分布式 KV\n\n茄子科技既然已经自研了基于 Rocksdb 的分布式 KV，为什么还要用到 TiKV ？首先在技术层面，虽然自研分布式 KV 在生产已经运行了两年多的时间，支撑了上百 TB 的数据，但是有些技术问题，比如**自动弹性升缩、强一致性、事务和大 key **等支持上还需要进一步投入研发。第二，在**人才层面针对高质量数据库人才储备**还有一定的欠缺。经过多次调研以及和 TiKV 研发同学的沟通，发现我们的需求和痛点与 TiKV 的产品规划是不谋而合的，这就促使了我们积极地拥抱 TiKV。我们借助 TiKV 可以在技术上打造存储与计算分离的 KV 产品。第三，TiKV 拥有活跃的开源社区，我们可以借助社区的力量共同打磨产品。\n\n下图中的架构是茄子科技基于 TiKV 打造的一款分布式 KV。左侧部分主要是解决数据实时写入的一个流程，从 SDK 到网络存储，到数据计算，最后到 TiKV 的存储引擎。我们重点的研究方向是右侧部分**整个 Bulk Load 能力**的研发，与自研的分布式 KV 的不同，把整个 SST 的生成流程放在 TiKV 内部去做，这样做的原因是可以**最大化地减少 Spark 部分的代码开发和维护成本，提升易用性**。\n\n![qzkc-4.png](https://img1.www.pingcap.com/prod/qzkc_4_f2a1eaa80f.png)\n\n## 基于 TiKV的演进 – 测试结论\n\n以下两张表是基于 TiKV 的 Bulk Load 能力进行实际测试的结果。上面这张表是在 E5 CPU，40 个 vcore，磁盘使用 NVMe 的情况下，最大可以达到 **256 兆**的单机吞吐。下边这张表是我们在进行 Bulk Load 的同时对 online reading 部分进行压测，可以看到 Latency 响应时间的抖动是非常小的，不管是 P99 还是 P99.99 ，都是处在一个**比较稳定**的状态。这个测试结果是一个 Demo 的验证，相信后续经过我们的优化，不管是存储吞吐还是响应延迟，都会有质的提升。\n\n![qzkc-5.png](https://img1.www.pingcap.com/prod/qzkc_5_087cc45a19.png)\n\nBulk Load 的能力是我们和 TiKV 的研发同学一起，共同协作开发、共同演进的。我们相信开放的力量，后面我们会把整个架构，包括测试数据都会放到 GitHub 上公开，如果大家有相应的需求可以关注一下。","date":"2021-09-17","author":"闫林林","fillInMethod":"writeDirectly","customUrl":"devcon-2021-shareit","file":null,"relatedBlogs":[]}}},
    "staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}