⬆️PingCAP DevCon 视频回放及演讲资料已上线
TiDB x 云盛海宏丨加速精细化运营，云海零售系统的架构演进
导读
本文为云盛海宏数据库架构师徐婷的分享实录。云海零售系统是支撑着全渠道、全品类运动鞋服的零售服务平台。本文介绍了云盛海宏云海零售系统所使用的数据库架构从集中式到分布式的演进历程，并根据使用的经验和体验，阐述了为什么选择 TiDB 数据库来支撑其业务，详细讲述了 TiDB 如何在实际使用中助力精细化运营。
01
零售系统升级历程
云海零售系统是支撑着全渠道、全品类运动鞋服的零售服务平台。在过去的十年间我们的业务系统和架构经历过多次的升级和改造，整体来看就是一个从集中式演进到分布式的过程。在 2016 年之前，各个大区自建设信息化系统，每天向总部上传业务数据，属于烟囱式的数据架构。随着移动互联网和数字经济的发展，该架构也暴露出一些问题，比如说没有办法很及时地去查看地区的汇总数据，也无法跨大区去查看全国的实时库存等。
为了解决这些问题，我们在 2016 年的时候就上线了全新的架构——云海零售系统。新架构是采用的微服务 + MySQL 的分库分表架构，并通过 Otter 将数据的实时汇聚到 Oracle，用于支撑复杂的报表查询。随着数字化零售时代的开启，汇聚库 Oracle 也遇到了一些瓶颈，例如存储无法扩展、分析时效差等问题，所以我们就引入了 TiDB 和 Oracle 一起支撑业务需求。对于未来的规划，我们希望能借助 TiDB 混合负载特性，支撑我们整个零售系统。
02
使用新的架构支撑数字化业务
2016 年为了支撑数字化业务，我们进行了业务流程的变革，并升级了我们的 IT 架构，上线了云海零售系统，这是当时的系统架构图。基于 MyCAT 进行分库分表和读写分离，拆分的规则复杂一点，基于每个业务系统还有大区都做了一定的拆分，这个架构的好处是将当时比较分散的数据汇聚到了一起。但这套架构也增加了实时分析的难度，做到了数据的共享，但因为数据做了拆分，如果要做一些复杂的需求，比如一些报表，比较复杂的 SQL，还有一些其他业务的时候就会增加相应的难度，一方面由于 MyCAT 对复杂 SQL 的支持有限、另外 MySQL 大表复杂查询效率也有限，所以我们通过 Otter 将数据实时汇聚到 Oracle 中，在 Oracle 上进行复杂的 SQL 查询。
点击此处丨阅读原文
TiDB in SaaS丨TiDB 在 Moka BI 场景下的应用
导读
Moka 是一家 HR SaaS 服务提供商，致力于通过一流技术和服务赋能企业的人才战略。Moka 的 BI 系统通过数据统计和实时报表等方式，实现了企业招聘和人力资源管理系统的智能化。文章重点介绍了 Moka BI 对其数据库架构的革新，分享了其系统现状及对选型的思考。在综合考虑兼容性、稳定性、简洁性、易用性、高可用等因素后，Moka BI 选择了 TiDB 作为支撑新架构的数据库，解决了数据壁垒，降低业务复杂度，实现了全面的性能提升。
01
Moka BI 介绍
Moka BI 通过全方位的数据统计和可灵活配置的实时报表，赋能智能化招聘管理系统和人力资源管理系统，通过 PC 端和移动端的多样报表展示，从而改善招聘业务、提供数据支持、提升招聘竞争力，从而助力科学决策。
Moka BI 的架构主要是类似于 Lambda 架构，实时处理和离线处理并存，实时数据主要来源为结构化的数据，Canal 采集 MySQL 或者 DBLE（基于 MySQL 的分布式中间件） 的 binlog，输出是 Kafka，未建模的数据按照公司进行分片，存储在业务的 DBLE 中，通过 Flink 进行实时建模，将计算后的数据写入 BI DBLE。Doris 定时同步 BI DBLE 的数据，支持数据大屏和实时报表统计，离线部分则涵盖了实时部分的数据，其结构化的数据来源于建模后的 BI DBLE 数据，明细数据存储在 HBase 中，并进行实时更新，映射成 Hive 表，非结构化的数据通过 ETL 流程存储至 Hive 中，并通过 Spark 进行计算、建模，离线数仓 ADS 层的数据，最终输出至 MySQL Redis 中，支撑离线报表统计，明细数据又支持招聘预测和搜索等外部应用。
02
现状与问题
当前架构的问题也很明显，首先就是在实时建模的过程中，因为单一公司都在一个 shard 上，在大流量下会触发单点瓶颈，从而导致消费延迟。其次在 DBLE、Doris、Hive 数据是大量冗余存储的，造成了数据壁垒。此外，整个数据链路很长，要保证 DBLE、Doris、Hive 的数据都是一致的，数据治理难度非常大，针对上述问题，我们进行了数据库的调研选型。
03
调研目标
我们制定了五个方向的调研目标，一期需要满足一到三项。第一个目标是兼容性，数据库要兼容 MySQL 的协议和生态，其次要兼容 Canal 格式的数据变更，还要兼容不同的云环境。第二是离散性，数据库要尽可能避免单点性能瓶颈。第三是服务的稳定性，首先是集群稳定性要高，并且支持多种容灾级别，在发生灾难时，故障响应时间要小于 30 秒，且在故障恢复后不能有数据延迟或者数据丢失。第四是易用性，我们希望数据库集群的维护成本低，并且便于扩缩容。最后的目标是简洁性，首先要简化数据存储，更进一步是最好能简化整个数据架构。
点击此处丨阅读原文
建设 TiDB 自动化平台：转转 DBA 团队实践
导读
转转是 PingCAP 最早的一批用户之一，见证了 TiDB 的发展，自身也沉淀了不少经验。
从 1.0 GA 开始测试，到 2.0 GA 正式投产，然后升级到了 2.1，后来又升级到 4.0.13，最后建设自动化平台。其实转转 DBA 团队初建以来就开始投入一定的资源进行平台建设，一步一步实现自动化运维，希望一切需求都能实现工单化、一切操作都能实现平台化，进而降低人力成本。
本文将分享转转 DBA 团队实现 TiDB 自动化的历程。从遇到问题开始，到解决问题，以及平台做成什么样，也是对过去工作的总结和梳理。
01
运维痛点
转转现有集群 30 多套，早期都是 2.1.[5,7,8,17] 版本，近 500 个 TiKV 节点，总共差不多一百台机器供 TiKV 使用，集群新建、扩容、迁移都需要人工找机器。也因为缺少一个上帝的视角去管理集群，没法做到资源的合理分配，导致日常工作中有很大一部分时间都是在做迁移，都是重复工作，效率很低。
1 | 转转现有集群 30 多套，早期都是 2.1.[5,7,8,17] 版本，近 500 个 TiKV 节点，总共差不多一百台机器供 TiKV 使用，集群新建、扩容、迁移都需要人工找机器。也因为缺少一个上帝的视角去管理集群，没法做到资源的合理分配，导致日常工作中有很大一部分时间都是在做迁移，都是重复工作，效率很低。 |
2 | 2.1 版本的运维工作都是基于 Ansible 进行。如扩容、下线、启停、修改配置等日常操作，有时候会碰到 Ansible 执行超时的情况。批量操作集群时，根本不知道到哪个节点了，这情况经常能遇到，在 reload 集群配置文件的时候遇到的概率就非常大，要多崩溃有多崩溃。 |
3 | 2.1 版本的 TiDB 自身有很多问题，执行计划失效、读写热点问题（不能快速定位问题）、TiDB 大查询 OOM、乐观事务、监控不完善、以及已知/未知的问题，就连集群状态都无法快速获取，当然备份也很痛苦，这对运维人员的工作加大了难度，也提升了人力成本。 |
4 | 机器资源使用不平衡，存在部分机器内存剩余较多但是磁盘不足，还有部分机器内存不足，但是磁盘剩余很多。导致的结果是老板觉得机器投入已经很大，但是 DBA 实际使用中发现机器还是不够用。 |
5 | 告警噪音比较多，存在重复告警，互相冲刷问题，严重浪费告警资源，对排查问题也带来很不友好的体验。 |
02
解决痛点
元数据管理
将所有节点信息保存到表里，定期采集节点状态及资源使用情况。
过去都是依靠 Ansible 的配置文件进行管理，管理视角基本是停留在集群都有哪些节点，连一台机器都有哪些实例都不清楚，更别谈资源管理了。
现在将所有组件保存到一个表中，定期采集组件服务状态，内存磁盘占有量等信息。这样就有了一个全局的视角进行管理，也很方便的查阅集群状态。
后续基于这份元数据进行项目成本核算。
还有一个收益就是，组件信息的采集，可以很好的控制单个 TiKV 的容量，不会再出现单个集群容量一直增长，然后触发机器的磁盘告警 DBA 才感知到。有了这个采集的数据后，可以设置一个 TiKV 容量上限，比如 500GB，达到这个阈值就发送告警给 DBA 准备扩容。这样能很好的避免因机器磁盘告警而接收大量告警信息（单机多实例），也能提供一个很好的缓冲时间让 DBA 来处理。
总结起来就是，能很好的将机器/集群/组件管理起来，能合理有效的进行资源调度，也为实现自动化提供了基础数据。
点击此处丨阅读原文
Infra Meetup No. 160 报名现已开始
⬇点击下方图片即刻报名
