{
"componentChunkName": "component---src-templates-blog-blog-detail-tsx",
"path": "/blog/how-to-use-htap-to-mine-industrial-data-value",
"result": {"pageContext":{"blog":{"id":"Blogs_447","title":"数益工联 x TiDB丨如何运用 HTAP 挖掘工业数据价值？","tags":["HTAP","TiDB"],"category":{"name":"案例实践"},"summary":"本文将以数益工联数字化工厂为例，介绍“离散型”制造业面临的数据挑战，以及分布式 HTAP 数据库 TiDB 如何助力工业数据价值的挖掘。","body":"制造业是一个古老而悠久的行业，它的起源最早可追溯到石器时代。从新石器时代简单的工具，到今天复杂的智能工厂，制造业历经千年发展，蜕变成了由技术驱动的创新行业，充满各种自动化流程、始终互连的设备和数据丰富的流程。\n\n本文将以数益工联数字化工厂为例，介绍“离散型”制造业面临的数据挑战，以及分布式 HTAP 数据库 TiDB 如何助力工业数据价值的挖掘。\n\n## “离散型”制造业面临数据挑战\n\n在制造业中，通常有着“流程型”和“离散型”两种区分。“流程型”是指被加工对象不间断地通过生产设备，通过一系列的加工装置使原材料进行化学或物理变化，最终得到产品。典型的流程生产制造业有医药、化工、石油化工、电力、钢铁制造、能源、水泥等领域。“离散型”制造，则是指材料的生产过程通常被分解为多项加工任务。典型的离散制造行业主要包括机械制造、电子电器、航空制造、汽车制造等行业。\n\n在整个离散制造业的现场有着太多的生产、物料、工艺以及人员数据。以前，离散制造业往往只能通过人工上报，手动填单等方式来进行数据收集。对于管理层而言，这些数据往往是不透明的、不准确的，或是滞后延迟的。**离散制造企业本身从业务到管理，都亟需通过数字化进行优化和提升。**\n\n## 如何解决“离散型”制造业的数据挑战？\n\n工业数字化软件供应商数益工联，致力于打造基于“数据流 + 价值流”的离散制造业数字化软件。数益工联团队以 IE+IT 为核心能力，实现产品和技术的双轮驱动，已在十多个行业落成全球领先的数字标杆工厂公司。公司至今已获得华创资本、高瓴创投、元生资本等知名机构的风险投资，累计融资额数亿元，在上海、苏州、广州三地设有子公司，打造跨区域全国服务平台。\n\n**数益工联数字工厂系统（DFS，Digital Factory System）应用新一代的物联网技术与丰富的现场交互手段，获取工厂现场最实时、最真实、最有效的数据**，不仅包含设备状态、设备异常数据、设备生产数据等设备 IOT 数据，还包含人员的交互使用数据，如计划报工、工艺、仓储物流、质检等核心生产管理业务的数据等。**对管理层而言，通过数益工联数字工厂系统，可以直观看到清晰、直接的报表，从中发现数据的价值，继而深入分析并采取行动，优化制造现场。**\n\n## 数益工联数字化工厂架构面临的挑战\n\n\n\n数益工联数字化工厂架构图\n \n从架构上看，数益工联数字化工厂主要分为四层：\n\n**第一层为物联层**，包括硬件和软件两部分。硬件主要为数益工联自研的智能终端，软件包括边缘应用和物联平台。其中应用主要具备设备参数的采集、人脸识别等功能，以上应用均运行于智能终端。物联平台则主要承担设备管理、配置和升级的相关工作。\n\n**第二层为应用层**，包括 IOT 数据服务、核心服务、低代码平台。IOT 数据服务是接受物联上报数据，计算设备开机率，异常等设备相关的服务，同时也是其他业务的数据源头；核心服务包括了计划报工、质量等数字化工厂服务；低代码平台主要包括了报表的可视化平台、流程编排等功能。\n\n**第三层为大数据层**，分成了大数据和算法两个部分。大数据应用包括了成本控制、APS、工艺大数据；算法包括了人脸识别、时序分析等算法。\n\n**第四层为基础架构层**，作为基础设施提供其他业务使用。主要包括了存储、数据库、中间件和云原生等部分。\n\n\n\n数字工厂的数据源头主要包括两部分：\n\n第一部分是 IOT 事件，包括了设备的开关机、物联采集、异常等数据，这部分数据通过 mqtt 上传到 IOT 服务进行处理，同时会推送到队列中，方便后续的计算和存储；\n\n另一部分是业务产生的数据，包括了计划报工、上下班等产生业务数据，主要通过 http 进行上传和展示。业务数据会直接存放到数据库中，同时将数据推送到队列中。\n\n数据存储主要采用了 TiDB 和 Starrocks 两个数据库，除了时序相关的数据，业务数据都存放在了 TiDB 中。\n\n**随着数益工联业务规模的不断增长，数据量变得愈发庞大，对于数据库的稳定性也提出了更高的要求**：\n\n1. 多数业务数据需要支持秒级延时，因此需要数据库具有很高的并发能力；随着业务的增长，数据量也会越来越大，需要数据库具有良好的拓展性；\n2. 随着数据量的增大，报表制作成本和难度变大，无法保证实时性。\n\n为解决业务系统的性能瓶颈，提高数据库的性能问题，数益工联选择了 TiDB 这一新型分布式数据库实现重构。\n\n\n\n数益工联研发团队在实践过程发现，TiDB 许多优势正好可以满足数益工联的需求：\n\n- **TiDB 兼容性强**，在实践的过程中几乎没有遇到过不兼容的问题，除了少数默认编码的问题。\n- **支持云原生部署**，可以通过 Kubernetes Operator 来快速部署 TiDB 集群，具有完善的配套监控功能。\n- **能够实现自动化水平扩容，支持高可用**，运维无需手动接入，极大地降低了运维成本。\n- **支持 OLAP**，TiDB 支持 TiFlash，降低部署复杂度，TiFlash 在亿级别数据的查询中，通常能达到 5 倍的加速。\n\n## TiDB 如何助力数益工联挖掘价值数据？\n\n那么，数益研发团队是如何使用 TiDB 实现对于工业数据的价值挖掘的？以工厂运转效率的重要指标设备开机率为例，对于工厂而言，设备的开机率与生产效率息息相关，能否实时获取开机率，机器是否实现了高效且合理的运转非常重要。数益工联团队通过 TiDB 实现了以下功能：\n\n\n\n- **开关机记录**：一条开机记录表示记录单个设备的一次开机时间和关机时间。这种记录表，由于数据量过大，现在主要放在 ES 中。\n- **开机率**：表示在一段时间内的开机时间的占比，延时需要精确到秒级，这种数据现在转换成时序的数据存放在 Starrocks，同时创建物化视图，加速时间跨度大的查询。\n\n但随着时间增长，团队也遇到了以下问题：一是开机记录和开机率数据不同源，导致数据容易不一致；二是 Starrocks 存储量大，占用了大量的计算和存储资源。\n\n因此，数益工联数据团队对于开机率进行了第三次改造：Starrocks 不再保存开机率的时序数据。时序数据量比较大，容易出现异常，导致数据不一致。**数益工联一方面将开机记录存放在 TiDB 中；另一方面通过开机记录来计算出开机率。**\n\n原先 ES 同步写入容易引发业务写入超时的问题，这次改造解决了 ES 数据写入延时的问题，同时，也减少了 Starrocks 的存储资源的占用。**这次改造使得在 100 台设备的应用场景中，一年能减少百 GB 级别的 Starrocks 存储；充分利用了 TiDB 的 HTAP 能力，通过 TiDB 的 HTAP 直接对开机记录进行聚合查询，降低了业务复杂度，给业务开发提供了很大的便利性**。目前，TiDB 在线上运行表现十分稳定。\n\n## 改造 TiFlash，实现 TiDB 物化功能\n\n与此同时，数益工联研发团队也在进行一些定制化的改造。由于业务需要支持任意时间段查询开机率的能力，因此需要按天对数据进行预聚合，但 TiDB 不支持物化能力，需要借助业务逻辑来实现，加大了业务实现复杂度。随**着业务预聚合的需求越来越多，数益工联研发团队决定对 TiFlash 进行改造，实现 TiDB 物化功能：**\n\n1. 根据物化语句生成物化表。\n2. 分区为粒度进行聚合，当数据到达一定时间的策略的时候，会把整个分区进行聚合，放到物化表分区中。\n3. 擎自动判断是否使用基表分区还是物化分区。\n4. iflash团队的交流中发现，需要解决重复计算的问题，因此数据需要多副本去重计算。\n\n\n\n目前，在数益初步的单副本测试中，虽然还存在一些问题需要修复，但能看到 TiFlash 的物化功能展现了很大的潜力，相信将在未来多业务场景下发挥重要作用。\n\n数据库在制造业中扮演着至关重要的角色，它们为工厂提供了强大的信息管理能力，帮助工厂更好地挖掘数据的价值。TiDB 可以帮助制造业处理海量数据，提供高效的查询性能，我们也期待帮助更多制造业用户完成数字化转型，从而提升企业的竞争力与效率。","date":"2022-12-21","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"how-to-use-htap-to-mine-industrial-data-value","file":null,"relatedBlogs":[{"relatedBlog":{"body":"**作者介绍**\n\n郑赫扬（艺名：潜龙），理想汽车 DBA。负责公司分布式数据库的技术探索和业务场景落地，热爱开源。就职于金融、互联网教育、电商、新能源汽车等领域。\n\n理想汽车作为豪华智能电动车品牌，以 **“创造移动的家，创造幸福的家”** 为使命。随着电动汽车业务的不断发展，公司业务既有 OLTP 也有 OLAP 的需求，因此需要一款 HTAP 数据库帮助公司实现实时业务决策。在 TUG 企业行 —— 走进 58 同城活动中，来自理想汽车的郑赫扬老师为大家介绍了**理想汽车 HTAP 读流量在物理环境、业务环境、SQL 优化、热点问题、流量环境、版本及架构等方面的优化方案**。\n\n以下为演讲实录。\n\n## 理想汽车选择 TiDB 的理由\n\n**1）一栈式 HTAP：简化企业技术栈**\n\nTiDB 可以在一份数据源上同时支撑理想汽车 OLTP 和 OLAP 需求，不但能很好地支持实时数据落地存储，也能提供一体化的分析能力。另外，TiDB 也可以集成常见的大数据计算技术框架，比如 Spark、Flink 等等，可以使用其构建离线或者实时的数据仓库体系。\n\n**2）解决 MySQL 传统拆库拆表问题**\n\n随着数据量的激增，单机数据库存不下怎么办？传统关系型数据库再扩展性问题，如果业务上已经用了 MySQL，那只能去做分库分表，或者利用中间件去转化，业务层要把代码改个遍。而 TiDB 与 MySQL 完全兼容，MySQL 应用无需修改便可直接运行。支持包括传统 RDBMS 和 NoSQL 的特性，可以随着数据增长而无缝水平扩展，只需要通过增加更多的机器来满足业务增长需求。\n\n**3）简约但不简单的扩缩容**\n\n在经历产品更新的演进中，TiDB 4.0 和 5.0 版本基本上可以通过一些操作控制来灵活便捷地扩缩容，例如通过增加节点来线性扩展计算能力，存储节点同样可以根据存储需求不断进行扩容增加存储。在进行节点缩容时，对线上服务的影响也几乎无感知。\n\n**4）完善的生态工具**\n\n目前理想汽车正在使用 DM（TiDB Data Migration）、TiCDC、TiSpark 等工具，在实际操作中也很强烈的感受到 TiDB 生态工具非常全面，这些生态工具还在不停地演进发展中，我们也在和官方小伙伴一起探索。\n\n**5）丰富的场景支持**\n\nTiDB 在理想汽车的业务场景包括 OLAP 和 OLTP 两个维度。OLAP 包括离线数仓，实时数仓、DMP 平台（包括日常的决策调度、财务调度、报表等）；OLTP 类的商业前端、算法训练（包括线上派单、交付、信息上报）等等。\n\n**6）良好的社区环境**\n\n社区一直是培养 TiDB 不断发展的优渥土壤，在日常维护中一旦出现故障和难点，官方的技术人员就会马上处理，这也给理想汽车很大的信心把 TiDB 引入更多业务场景中使用。\n\n\n接下来跟大家介绍理想汽车针对读流量在以下 **7 个方面**的优化实践。\n\n## HTAP 读流量如何优化？\n\n**1）物理环境优化**\n\n\n\n理想汽车目前把 TiDB 和 PD 集群的配置从原来的 16 核 32G 升级成了 32 核 128G。对于 TiDB 来说，支持 AP 类的大 SQL 可能要跑 7 - 8G 左右的内存，对内存的需求更高。为了解决 PD 的算力问题，我们会预估一下数仓的数据级，预估之后我们会再调大，例如一个单点的话，一个 PD 在 50 万以上可能有调度问题。所以我们可以调大 Region，来横向避免 Region 数量过多的情况。 \n\nTiKV 刚开始使用的是 32C32G 2T 的百度云 SSD，现在和 TiFlash 一样全部采用 32 核 64G 的 4T NVMe 物理盘，这两个升级都是为了更好地统筹计算资源。\n\n**2）业务环境优化**\n\n目前在理想汽车主要的 TiDB 集群都由 DM 同步上游的 MySQL，针对 DM 集群管理做了大量优化。做完之后，就是现在所有的上游 MySQL 主要库在 TiDB 里面都会有副本，因此 TiDB 就具备了 MySQL 从库 + 业务主库 + DMP 平台结果库的功能。\n\n\n\n**关键业务库表 DDL 变更和业务变更**\n\n- 上游 MySQL DDL 变更是否允许都会做一个规范，防止同步任务中断。\n- 新业务完整的测试环境支持。\n- 上游 MySQL 刷业务数据会有大量写流量，DM-sync 线程扩容。刷数据之前大家需要提前自动化，调整到高峰以应对流量冲击，因为下游有很多重要的业务，数据延迟的话会很有影响。\n\n**分类开发规范:**\n\n- OLTP 开发规范：目前理想汽车的单个事务 SQL 结果集大小不能超过 20MB / 结果集 50W 以下，或者 TiDB 计算节点内存小于 120MB，因为 TiDB 要对结果集做一个处理，可能最大扩大至 6 倍。\n\n- OLAP 开发规范：\n1. 复杂 SQL 大表走 TiFlash （一般 2KW），小表走 TiKV。\n\n1. 结果集最大值小于 7KW 或者 TiDB 计算结果内存小于 8G。\n\n1. 不断探索 TiDB 的 OLAP 性能边界。\n\n\n**DM 优化：**\n\nDDL 的问题是不支持变更，假如下游读流量业务受到影响，例如公司上游挂了很多个 MySQL，你希望做 MySQL 同步关联，你只要同步在一个 TiDB 集群里面，你也可以做一个小的数仓，调整方法，首先调整 TiDB 支持 DDL 变更。\n\n\n解决方法: \n\n(1)调整 TiDB 支持 DDL 变更 \n\n(2)上游新建表 --> 插入业务数据 --> rename 表名 --> 跳过报错（针对上游流量和数据量小，要做数据修补） \n\n(3)下游新建表 --> 插入业务数据 --> rename 表名 --> 跳过报错（下游不会丢失数据）\n\n\n业务环境优化中，典型的 TP 类型的 SQL 对结果集和算子要求就是 20MB，比如需要考虑环境规划，我们要求结果集在多少，总共不能少过多少万行或者多少的内存，下图所示最大内存是 25.3MB。\n\n\n\n再来看下 AP 类型的 SQL 实时数仓，最大内存是 8G，总共少了 7700 万的数据，执行时间是381 秒，是用 TiFlash 跑的。因为有的报表类或者是定时任务实时性不高，所以分类的话，还是 OK 的。我们现在好多类似的 SQL 在这么跑，TiFlash 5.0.2 集群版本，对于我们来说还可以，业务上比较稳定。\n\n\n\n**3）SQL优化**\n\n首先得定一下规则\n\n**SQL 索引：**\n\n- OLTP 类：决定查询速度，所有 SQL 必须走索引\n\n\ta. 注意不走索引的情况（where 条件中左侧等式函数，隐式转化，不等式) \n\n\tb. 优化方式 MySQL 索引基本一致\n\n- OLAP 类：根据表的数量级和 SQL 复杂度 \n\ta. 行存 where 条件查一条数据，行存 + 索引更快。 \n\n\tb. 列存没有细粒度索引，扫描数据性能更好。\n\nDDL 大表（数量过 10 亿）索引上线可能会影响线上业务: \n\n1.参数调整：业务高峰调小调低优先级 \n\ntidb_ddl_reorg_batch_size = 128\n\ntidb_ddl_reorg_worker_cnt = 2\n\ntidb_ddl_reorg_priority = PRIORITY_LOW\n\n\n\n2.业务低峰调大调高优先级（看监控观察业务） \n\ntidb_ddl_reorg_batch_size = 1024\n\ntidb_ddl_reorg_worker_cnt = 16\n\ntidb_ddl_reorg_priority = PRIORITY_HIGH\n\n\n**SQL 执行计划：**\n\n读表算子 TiDB 和 MySQL 不一样。MySQL 的话是 Type、Reader 之类的，但是 TiDB 是有分成算子再往下去读像 TableReader，点查大于索引覆盖，相当于 MySQL 的索引覆盖，相当于 TiDB 普通索引。\n\n读表算子优劣：PointGet/BatchPointGet>IndexReader（MySQL覆盖索引）> IndexLookupReader（普通索引）> TableReader。对于 TP 类型 SQL 来说尽可能消除 TableReader 读表算子或者减少结果集。\n\n\n\n**SQL 错误索引与统计信息：**\n\nTiDB 统计信息和表格健康度会直接影响你的索引，通常就不走了，所以你的业务突然就变慢了，只能说越来越小了。对于理想汽车来说，看表的健康度只要是大于 80% 的话，正确索引的概率基本上是可以保证的。\n\n\n解决方法： \n\n手动或者自动更新表和索引统计信息 \n\n(1)自动更新条件\n- 表中至少 1000 行数据\n- 默认 1 分钟无 DML\n- modify_count > tidb_auto_analyze_ratio参数（默认 0.5，设置成 0.8）\n- tidb_build_stats_concurrency（默认 4，资源充足可以调大）\n- tidb_distsql_scan_concurrency（默认 15，AP 30，TP 10）\n- tidb_index_serial_scan_concurrency（默认 1，TP 不调，AP 调成 4）\n\n\n\n解决方法： \n\n(1) 设置自动 analyze 时间 \n- tidb_auto_analyze_start_time（这里是 UTC 时间，如果是默认值00:00 + 0000，则早上 8 点开始执行）。所以建议设置时间为业务低峰 -8 小时，比如凌晨执行（16:00 + 0000），结束 tidb_auto_analyze_end_time 设置（23:59 + 0000）。\n\n(2) 如果仍然不准确，可以适当入侵绑定 SQL 计划或者强制走索引。 \n \n- CREATE [GLOBAL | SESSION] BINDING FOR BindableStmt USING BindableStmt;\n\n\n(3) 如果避开了自动 analyze 时间，则应该手动重新统计表信息。 \n\n- show stats_meta where table_name='xxx'\n\n- show stats_healthy where table_name='xxx'\n\n- show STATS_HISTOGRAMS where table_name='xxx' analyze table xxx\n\n**SQL 逻辑优化**\n\nTiFlash 函数下推，大家一定要看一下，因为 TiFlash 不是所有的函数都下推。假如你走 TiFlash 数据量很大，又没有函数下推，代表你会在 TiDB 里面计算，这个过程可能就会比较耗时。建议对准官方的支持列表，（下图为部分截取）按照下推列表去规范 SQL。\n\n\n\n\n**4）热点问题优化**\n\n业务报慢 SQL，监控看单个节点 Coprocessor CPU（Coprocessor 是 TiKV 中读取 数据并计算的模块）异常飙升。（v3.0.14 未开启 Unified read pool，面板指标 TiKV - Details -> Thread CPU）\n\n\n\n看读热点，可以基于命令行去做一个脚本，比如 pt-ctl，看 hot read 和 hot write。 \n\n(1) 去看 region 对应的表是哪张，获取热点的单个 region。 \n\n(2) 4.0 以上 dashboard 热力图。 \n\n(3) TiDB_HOT_REGIONS 表中记载了是那张表，有多少个字节。\n\n\n\n然后手动 split Region，然后 hot read schedule 进行调度，CPU 使用资源下降，单个读热点 region 就消失了。\n\n\n\nV4 版本有一个参数 Load base Split，默认 10 秒内 3000 次查询，或者是流量超过了 30MB/秒自动分类。每一家的业务都不一样，每一家的集群也不一样，默认只是说是一个挺好的配置，但是大多数的部署 TiDB 可能用的不是 NVMe，可能用的是云盘的 SSD 或者是普通的 SSD，每一家的读流量标准应该根据各自的硬盘配置标准，设置一个正常流量均衡的 Region。\n\n这个可以通过热力图，也可以通过抓取的方式去看，可以做成自动化监控。所以 TiDB 还有个好处就是 Information Schema 里面几乎涵盖了你所有的信息，比 MySQL 更全。\n\n\n\n像监控、命令可以看最高的读取热点，每天都可以看，用命令行做一个筛选，找到对应的库表切割，切割完之后或者自动切割都可以，然后再观察。但是这个 Load base split 有的时候也有可能，也可以每天跑一遍检验它的结果。\n\n\n\n\n**5）流量环境优化**\n\n第一，强制 SQL 里面走一些执行计划，执行内容可以限定一个参数，比如说 10 秒，或者内存 20M。我们针对线上 TP 类型是有的，比如下图这个业务的 SQL，就是点击类的报表系统，因为点击类的报表系统由于业务人员选的维度不同，最后的数据量级也不同，你可以设置一个限制，否则可能他点很多次的话，一个大的流量就会把你的集群冲击掉。\n\n\n\nOptimizer Hints 熔断：\n- 执行时间: MAX_EXECUTION_TIME(N)\n- 执行内存: MEMORY_QUOTA(N)\n- 线上 TP SQL\n\n\n第二，Global 参数配置确保资源不溢出和连接质量。\n\n- 长连接控制: pt-kill 控制杀掉 Sleep 线程或者重启 TiDB-Server（慎用）\n- 执行内存: tidb_mem_quota_query\n\n\n\n第三，理想汽车 AP 和 TP 读流量是分流的，TP 走的是 TiKV，AP 走的是 TiFlash，线上默认所有库表都加了 TiFlash 副本，有 3000 多个同步任务，大概是 3000 多张表，做一个流量分流。有的时候可能走 TiKV 更快，但是有的时候是一个整体切割，如下图所示，现在是两个流量分流了。\n\n\n\n- AP 和 TP 的流量均摊，可以更改执行计划，但是我们用 Hint 更改执行计划，发现对 AP 类型非常不友好，测试的时候可能还会走到 TiKV 上面。SELECT /*+ READ_FROM_STORAGE(TIFLASH[test1.t1,test2.t2]) */ t1.a FROM test1.t t1, test2.t t2 WHERE t1.a = t2.a;\n\n- Session 会话控制，需要配合 rollback 回滚参数使用，强行走 TiFlash。set @@session.tidb_isolation_read_engines = \"tiflash\";\n\n- TiFlash 下面有一个参数一定要设置，就是如果 TiFlash 发生查询错误，业务语句返回 TiKV 查询数据。确保万一 TiFlash 副本不能用了，还有读取数据的机会。set global tidb_allow_fallback_to_tikv='tiflash';\n\n**6）版本优化：**\n\n5.0 版本因为有 MPP 功能，我们去尝试从轻 AP 类型转到 AP 类型，看是否可以免除业务迁移的麻烦。我们的测试结果拿 2 台 TiFlash 做 MPP 测试作为参考，结果如下：\n\n- 2 台 TiFlash MPP 业务整体提升 35%。\n- 业务 SQL 比较复杂，5.0.2 之后官方做了更多的下推优化。\n\n下图可以看出优化前后的运行时间对比。这些都是线上业务，线上的数仓 SQL 特别复杂，都是一两千行的大 SQL，打开文本看大概有 1400 行，所以这个优化效果还是很棒的。\n\n\n\n生产环境中，我们用 5 个 TiFlash node 跑，这是前后的流量对比图，整体有 32 秒，后来基本都降到了 1 秒以下。\n\n\n\n但是这个图很骗人的，大家千万不能相信这个 999，你真正需要优化的，可能就不在这个 999 里面，全在那个 0.01 里面。但是整体优化的效果还是很明显的，包括事务延迟执行 lantency，都降低了很多。整体的响应更具说服力，以下是一天时间内的对比图，大于 30 秒的 SQL 少了 87%，大于 60 秒的 SQL 也降低了 87%，大于 2 分钟的 SQL 同比降低了 99%，同样的流量，5.0.2 对我们整体的优化提升还是非常大的。\n\n\n\n**7）架构优化**\n\n架构优化的核心思想是用技术架构来转化 SQL 压力，下图是实时数仓的技术架构。上面是 DM 同步 MySQL 的数据源写入到 TiDB，TiDB 做一个 ODS 层之后，再导入到 TiCDC，之后通过分区打入到 Kafka，再分批消费进入 Flink，然后数据回写回 TiDB，提供实时数据和物化视图功能。因为 TiDB 本身不支持物化视图，可以在 Flink 里面解决这个技术难题，打造一个流批一体的实时数仓。\n\n\n\n考虑到 OLAP 业务 SQL，我们选择了 **TiKV 存储引擎**，这个时候在 Flink 做完计算的表再写回 TiDB 的话，有一些 AP 的 SQL 就可以变成 TP 了，像 Table Reader 的算子有的时候可以变成 PointGet 或者是 BatchPointGet（点查或者表查），范围查询就会少很多，这样就在侧面缓解了压力。选择 TiFlash 就可以完成各种维度的聚合操作，实现离线报表和在线统计这些功能。这些都是我们已经实施上线的，但是还有几个使用问题，例如：\n\n- 在理想汽车的 DM 场景下，对表做了 rename 后 TiCDC 就无法识别了。因为 TiCDC 默认是以 Table ID 算的，表名一样，但是里面的 Table ID 已经变了，TiCDC 识别不了，就只能重启；\n- 新增的 Kafka 分区，流量增大时增加 Kafka 分机，TiCDC 无法识别，也需要重启；\n- V4.0.14 版本以前的 TiCDC 稳定性存在问题。\n\n\n## 总结\n\n业务发展推动技术革新，目前理想汽车的发展非常快。TiDB 的读流量优化是个**全局视角**，除了 SQL 本身外，官方提供了非常全面的优化手段，包括引擎、架构、执行计划、参数控制等。大家可以去按照自己的业务发展去做各种不同的尝试。\n\n\n当然，优化都不能只看表面，TiDB Duration SQL 999 线是最常看的指标，但是也有欺骗性，但有时候最需要优化的是那 0.01%。\n\n最后，**没有任何一种数据库是银弹，业务场景的适配和降本增效永远是最重要的**。TiDB 更像是集百家之长，而不是专精于一技，在解决分库分表的基础上，基本覆盖所有场景和生态支持。理想汽车也希望能和 TiDB 一起走得更远。","author":"郑赫扬","category":4,"customUrl":"htap-read-flow-optimization-from-lixiang","fillInMethod":"writeDirectly","id":312,"summary":"“没有任何一种数据库是银弹，业务场景的适配和降本增效永远是最重要的。” 数据库的性能优化能够帮助企业最大限度地利用系统资源，提高业务支撑能力和用户体验。本文为 TiDB 性能调优专题的第一篇，在这个专题中，我们将邀请更多 TiDBer 从实际的业务场景出发，分享 TiDB 优化的最佳实践。","tags":["TiDB 性能调优"],"title":"理想汽车 HTAP 读流量优化指南丨 TiDB 优化实践"}},{"relatedBlog":{"body":"> 本文转载自公众号：韩锋频道（hanfeng_channel） \n> **作者简介**：韩锋，CCIA（中国计算机协会）常务理事，有着丰富的一线数据库架构、软件研发、产品设计、团队管理经验；曾担任多家公司首席 DBA、数据库架构师等职，在云、电商、金融、互联网等行业均有涉猎；精通多种关系型数据库，对 NoSQL 及大数据相关技术也有涉足，实践经验丰富；曾著有数据库相关著作《SQL优化最佳实践》、《数据库高效优化》。\n\n作为数据基础设施的重要组成部分，数据库在其中扮演着重要的角色。近些年来，数据库整体发展也呈现出较之以往很大的不同。 \n \n其一是开源数据库受到更为广泛的关注，从多家机构的最新报告来看，开源数据库无论从产品数量还是受关注程度都超过商业数据库。开源这一新模式，正成为未来数据库发展的主流。 \n\n其二是云计算成为未来主要资源供给方式得到普遍共识。已经有越来越多的企业选择在云上构建基础环境，包括云上数据库的发展速度也远高于非云环境。据乐观估计，在未来 5~10 年云数据库将占据整体数据库市场的七成以上。此外，对迁移到公有云、使用多云环境等问题，也普遍被企业所接受。 \n\n其三是数据融合趋势，针对数据多场景应用，使用融合技术简化访问，提升效率。作为数据使用高地，金融行业一方面对数据库有着极高的要求，一方面又面临很多来自数据新的挑战，诸如海量规模、高并发、数据安全、实时分析等诉求亟待解决。分布式数据库的出现，迎合这一发展趋势，对于金融企业解决上述问题带来新的解决思路。 \n\n本文从金融用户角度入手，对如何选择分布式数据库及选型后的最优实践进行阐述。\n\n ## 金融业数据库选型背景\n\n随着企业数字化转型深入，对于数据使用场景也呈现多元化趋势，正有越来越多数据被企业利用起来。金融行业作为数据库应用“高地”，这一趋势表现更为明显。同时我们也看到，近些年来数据库领域也发展迅速，有分布式数据库、多模数据库、云数据库为代表的产品不断涌现。这些新兴数据库在特定场景有很好的使用前景。基于上面两种趋势，金融行业很多企业都在面临选择数据库的问题。\n\n### 选型技术层面要素分析\n\n从技术角度来看，在数据库选型中有哪些要素需要考虑呢？下面以近期比较关注的分布式数据库的选型为例，说明下重点考量的技术要素。\n\n**分布式事务**\n\n分布式架构，自然会带来分布式事务的问题。由于需要跨节点的网络交互，因此较单机事务会有很多损耗。随之带来的是事务处理时间较长、事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会受到影响。针对单笔事务来说，分布式事务执行效率是肯定会有降低的，分布式带来的更多是整体处理能力的提升。\n\n**性能**\n\n由于分布式数据库通常使用的二阶段提交和各节点之间的网络交互会有性能损耗，分布式数据库优势不是单个简单 SQL 的性能，而是大数据量的 SQL 查询，每个节点会将过滤之后的数据集进行返回，会提升性能，并且分布式数据库的优势是并发，大量的 SQL 并发也会比单机数据库强大，应用需要做分布式架构的适配，将串行执行机制尽量都改造成并发处理。对于含有需要节点间数据流动的 SQL 语句的事务，OLTP 类的分布式数据库处理效率一般较差，事务处理时间会较长，事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会受到影响。建议尽量改造存在跨节点数据流动的 SQL 语句（主要是多表关联）的事务。\n\n**数据备份**\n\n分布式数据库的一致性保证通过内部时钟机制所提供的全局时间戳，所有节点都会遵循该机制，所以备份恢复的增量也是基于全局时间戳，但是分布式数据库的备份解决方案最重要的标志为是否支持物理级的备份，物理级的备份会比逻辑的备份性能吞吐大很多，还有就是是否支持一些分布式备份方案，比如 S3 协议接口，是否支持压缩等功能。分布式数据库基本都具备备份和恢复方案，通常从备节点进行连续备份（全量+日志），恢复的时候指定节点进行恢复到指定时间点，整个过程可配置自动任务、自动执行。\n\n**高可用**\n\n分布式数据库大多都是基于多数派协议，同城双中心不适合多数派的要求，同城数据级多活建议采用三中心部署。如果同城主备可以采用集群级的异步复制，异地建议采用集群级的 binlog 异步复制，建议实例的主备节点设置在同城两个双活数据中心，仲裁节点三机房部署；异地灾备单独启实例与本地实例进行数据库间同步，也可以将本地备份文件 T+1 恢复到异地灾备。\n\n**数据一致性**\n\n分布式数据库大多都是通过获取全局时钟时间戳，采用二阶段提交，可以实现一致性的保证，分库分表架构对于事务的一致性，需要应用层考虑，比如通过合理的分区键设计来规避。部分分布式数据库对于跨节点事务目前还是实现的最终一致，对于全局一致性读，一般通过引入类似全局时间戳的组件统一管理全局事务，在数据库选型时可以重点关注厂商对这一块的实现。如果目前暂时无法提供全局一致性读的分布式数据库，对于要依赖分布式事务“中间状态”的业务，优先进行业务改造进行规避，其次通过合理的数据分片设计让其在单节点内完成。\n\n**数据分析**\n\n分布式数据库，多采用存算分离架构。针对数据分析场景，需要对数据从下层存储节点上移到计算节点，这对分布式数据库提出了更高的要求。一方面可通过算子下推等技术，减少需传输到计算节点的数量；一方面针对汇聚后的结果需要通过流式处理等方式，规避诸如 OOM 的问题；此外也可采用如 MPP 等并行处理技术，加速数据分析过程。\n\n### 选型过程问题痛点分析\n\n在选型过程中，会遇到来自以下几方面的痛点。 \n\n- 由于分布式数据库整体架构还比较新，也是近十年来逐步发展完善的。针对新型架构的诸多特点，包括厂商和用户还都在不断摸索积累之中，还需要有个长期实践的过程。此外，新架构也需要有个逐步成熟完善的过程。\n- 大量产品来自国内数据库厂商，其发展周期相对较短，还需要在产品成熟度、稳定性、周边生态等方面不断完善。对于用户来说，一方面需面临产品多、技术栈多的现状；另一方面还需面对成熟度不足等问题，存在较多痛点。\n- 近些年金融行业发展迅速，各种新的业态产品不断涌现，这些对作为底层数据基础的数据库也提出了更高的要求。\n\n## 数据库选型技术架构\n\n### 分布式路线分析\n\n针对分布式数据库的发展路线，大体可分为两种：\n\n**分布式中间件**\n\n这种架构是从中间件路线演进而来。其采用存储与计算分离架构，底层采用标准单机数据库，副本间基于数据库主从复制机制。上层承担计算，并可将部分计算下推到存储节点执行。这种架构在分布式事务、全局 MVCC 等方面，往往存在一定难点，各厂商也有各自解决之道。\n\n**原生分布式**\n\n这种架构正是受到 Google 论文影响演进而来。其采用存储与计算分离架构，底层采用单机库(不一定是关系型)，副本间采用分布式一致性协议完成复制，支持多数派提交。上层承担计算，并可将部分计算下推到存储节点执行。\n\n### 重点需求满足情况\n\n针对上述遇到的痛点，两类产品实现逻辑也所有不同：\n\n\n\n\n### 路线场景分析\n\n从数据使用场景来讲，可大致按下面进行划分：\n\n\n\n针对不同的场景，不同分布式数据库路线产品各有所长。\n- 针对事务类场景下，强调高并发联机交易、对分析能力要求不高的场景比较适合分布式中间件路线产品。\n- 针对事务类及事务/分析混合类场景，既要满足常规联机交易场景的同时，还需满足分析类的一部分能力，这种情况比较适合原生分布式产品。基于原生分布式的 HTAP 数据库，用一个数据平台应对规模化交易和实时分析，提升业务决策的时效性，降低数据技术栈的复杂性，越来越多的混合负载需求推动了 HTAP 在金融场景的落地。\n\n## 金融业 HTAP 应用场景实践\n\n### 金融场景下 HTAP 的分析\n\n在金融企业数字化转型的过程中，各类业务对“海量、实时、在线”的数据需求变得愈发迫切。在金融企业运营场景中，实时推荐、精准营销是企业提升竞争力的一大因素。在企业风险控制场景中，实时风控、反欺诈等业务开展可以更早地识别和阻断风险可以让企业减少损失，HTAP 正是基于上述背景诞生出的需求，为各类实时数据处理需求提供了解决方案。\n\n### 某金融用户 HTAP 的架构设计和实践\n\n随着金融市场同业业务的蓬勃发展，业务部门对于交易数据的实时统计分析和展现有了急切的需求。基于大数据技术栈的 T+1 报表模式，已无法满足业务部门通过实时分析交易发生情况来防范风险以及提供决策的需求，迫切的需要找到一种能让数据实时变现的解决方案。结合金融行业特点，在技术选型过程中，重点考察待选产品如下能力：包括承载业务复杂查询处理、海量数据容量存储、应用透明无侵入、开发协议可适配及混合负载下的表现等。经过测试，选择 TiDB 作为基础数据库平台。基于其 HTAP 的特性，打造金融市场实时数据平台，目前已投产了灵活报表和交易对手分析等应用场景。整个处理流程包括： \n\n- Flink 消费交易系统产生的实时增量数据，对部分事实表进行拉宽处理并写入 TiDB\n- 维表和其他明细表直接写入 TiDB\n- BI 工具直接连接 TiDB，提供秒级的实时计算和分析能力\n\n\n\n这一案例中，构建千万及以上数据规模、超过五张表的复杂关联实时查询能力，让业务人员在极短的时间内（大部分报表执行时间为几十到几百毫秒、个别报表秒级别）获得实时交易的详情。\n\n### 未来 HTAP 的场景发展\n\n实时数据处理技术还以某些具体的应用场景为主，从现状来看以事件驱动类、流式管道数据计算类为代表的场景，已经开始使用 HTAP 场景的。未来随着 HTAP 计算能力进一步的提升，实时全量数据的计算将带来更多场景。\n\n## 面向未来的架构趋势\n\n### 云原生\n\n从未来的发展趋势来看，云方向是一个大的趋势。\n\n\n\n从上图可见，云数据库的发展经历了几个阶段，从云托管、云服务、云原生之路。 \n\n- **云托管**，是最接近传统数据库系统的部署模式。本质是将原本部署于 IDC 机房内物理服务器上的传统数据库软件部署在了云主机上。这种模式下，云平台提供诸如高可用、异地灾备、备份恢复、数据安全、SQL 审计、性能优化和状态监测等企业级数据库管理能力，用户可减少运维投入即可享受之前同等的服务水平。\n- **云服务**，之前的托管架构中，受限于传统数据库架构的局限，未能完全发挥云计算的优势。在诸如弹性扩展、高性能、高可用等方面，均有不足。到了云服务时代，充分利用云基础设施的底层能力，提供定制化的数据库产品。\n- **云原生**，与之前的云服务架构不同，这一阶段产品将更为充分地利用云基础设施的能力，通过多层资源解耦，可享受云带来的弹性扩展、按需供给、超大规模能力。真正做到了数据库与云的深度结合。从长期来看，金融机构逐渐把业务和技术向云原生演进，实现传统应用迁移上云和云原生改造是重要的方向。在这个过程中需要考虑分布式数据库对 K8s、微服务应用的支持，提供高效、弹性调度能力，同时需要兼顾开发运维和敏捷度。\n\n### 多云方向\n\n云作为未来主流的资源供给方式，多云必然是企业不得不考虑的问题。多云通常指金融机构同时采用多种不同的云环境组合来满足业务需求的多样性和金融业监管的要求。如何围绕数据打造面向未来的多云 IT 架构，满足在多云之间提供数据服务能力，摆脱单一供应商的弊端，是必须考虑的问题。多云架构对分布式数据库的考察重点聚焦于跨地域、跨公有私有云、跨本地 IDC 和 K8S 的部署、服务提供与统一运维能力等。","author":"韩锋","category":5,"customUrl":"distributed-database-selection-and-htap-practice-in-financial-industry","fillInMethod":"writeDirectly","id":388,"summary":"本文转载自公众号：韩锋频道（hanfeng_channel）。文章从金融用户角度入手，对如何选择分布式数据库及选型后的最优实践进行了阐述。","tags":["分布式数据库","HTAP","TiDB"],"title":"金融业分布式数据库选型及 HTAP 场景实践"}},{"relatedBlog":{"body":"> CRM 并不是简单的销售和客户服务的效率工具。本质上，CRM 是以平台化思维实现业务管理和数据的打通，为 360 度客户旅程提供数字化支撑。\n\nIDC 发布的《IDC 中国企业级应用管理 SaaS 市场，2021H2 》报告显示：2021 年中国企业级应用管理 SaaS 市场规模达 67.8 亿美金，其中 CRM 市场份额为 32%，未来五年将以 23.1% 的 CAGR 快速增长。 \n\n虽然受到疫情影响，但随着企业数字化转型的不断深化，更多的企业需要用数字化手段、标准化流程来提高效率和节约成本。从中国企业级应用管理 SaaS 市场来看，平台化、数据化、生态化成为重要的发展趋势。CRM 作为云计算时代典型的数据密集型应用，提升海量数据的处理能力和时效性成为 CRM 服务商提升客户体验、构建核心竞争力的关键所在。\n\n## CRM 的数据架构面临重重挑战\n\n某中国企业级 CRM 头部服务商，其 CRM 产品支持从营销、销售到服务的全流程自动化业务场景，帮助企业转型为真正“以客户为中心”的数字化运营组织，实现业绩的可持续增长。随着产品能力的迭代加速和业务的规模化增长，该服务商实现了从中小企业到大中型企业的覆盖，为了应对不同行业用户的个性化需求推出了 PaaS 平台，基于平台的定制能力服务垂直行业的特定需求；同时，该服务商发力 C 端市场，陆续推出 SCRM 等产品连接海量 C 端用户，打造客户旅程的一体化闭环。 \n\n同时服务几万家不同规模的企业，打通每家企业各个业务系统的数据，为 360 度客户旅程提供数字化支撑，这些都对 CRM 服务商底层的数据平台提出了非常严苛的要求。该 CRM 服务商的数据平台架构采用多形态混合式数据存储模式来满足多租户架构下可定制的业务需求。下图所示的多租户共享数据库，考虑到大表性能、租户数据量，采用了元数据、租户分库、租户分表的整体方案，共享库按照租户和实体做水平扩展的分库分表设计。 \n\n\n多租户共享数据库的分库分表设计\n\n与此同时，为了满足多租户定制化需求，实体主数据表需要预留大量的扩展列，呈现出数据库表多，列多，索引多等特点，也给 CRM 的数据架构带来了重重挑战：\n\n### 大数据量下的分库分表无以为继\n\n随着业务高速增长，CRM 用户数接近 20 万，租户的增长一方面带来海量数据高并发访问的挑战，另一方面使得单租户单实体库数据量快速增长，单表已经超过千万级别。单体 MySQL 数据库无法水平弹性扩展，配置也已经到极限，出现性能下降的问题。此外，MySQL 的分库分表方案，业务拆分难度大，需要进行代码侧的改动进行适配，维护工作也变得非常繁琐。\n\n### 2B 和 2C 客户的体验大打折扣\n\nCRM 业务具有灵活、多变的的特征，经常遇上索引缺失/索引选取错误或者复杂模糊查询等情况，MySQL 性能完全不可接受，慢查询增多导致客户体验差。在批量操作场景，单个任务可能将系统卡死，大量慢查询堆积，严重的时候甚至会造成 OOM，查询被拉黑名单。\n\n### 业务创新的灵活度受到制约\n\n中国的企业级客户由于行业特点和业务环境的变化，通常对 CRM 有定制化和多样化需求，导致数据库需要预留很多的扩展列，经常需要在数据表中增加字段或者增加索引。MySQL 行宽只有 64K，也不支持 Online DDL，使得业务创新的灵活度受到极大制约。\n\n## CRM 真实场景下 MySQL 和 TiDB 的比拼\n\n通过与 CRM 服务商技术部门的探讨，由于 SaaS 业务的稳定性、性能都对最终客户至关重要，组织了一次全面的 PoC 验证工作，覆盖了产品的性能，兼顾数据迁移、稳定性、安全性、运维监控等能力。 \n\n从业务场景的实测结果可以看到：TiDB 并发处理和查询性能提升明显，千万级以上性能提升 70% 左右，单条、跑批都得到了大幅的性能提升（80% 在毫秒级），原先过长时间查询无返回结果的任务，在 TiDB 中得到好转；各类痛点查询，如权限查询、模糊查询、分页查询、无索引查询、聚合查询、联表查询等性能提升几倍至几百倍不等；TiDB 在添加字段，修改字段，增加索引等 DDL 上优势明显。此外，TiDB 提供高效的同步工具 DM，从 RDS-MySQL 同步到 TiDB 延迟控制在毫秒级别。\n\n## 两套数据架构的对比\n\n某 CRM 服务商原有的数据架构中，OLTP 业务通过 Mycat 连接多套 MySQL 数据库处理和存储应用的数据，所有 MySQL 通过 DataPipline 同步到 Greenplum 数仓，由 Greenplum 提供 OLAP 查询服务。引入 TiDB 分布式数据库替换原有架构之后，所有的 OLTP 业务和 OLAP 查询访问一套 TiDB 集群即可，根据业务的实际需求，灵活增加 TiKV 和 TiFlash 节点即可。 \n\n\n某 CRM 服务商数据平台架构\n\n基于 TiDB 的新架构在高可用、性能、定制化需求、客户体验、开发和运维等多个维度体现出优势：\n\n\n## “两升一降”助力 SaaS 服务商构建核心竞争力\n\n### 提升海量数据的处理能力和时效性\n\nTiDB 分布式数据库按需弹性扩展能力使得 CRM 服务商可以轻松应对租户、2B 与 2C 业务海量数据的增长。对于 CRM 类 SaaS 服务商来说，TiDB 分布式架构对库、表无数量限制，一键实现节点扩缩容，使得使得数据架构可以动态、平滑地适配业务的增长。TiDB 原生分布式特点在高并发查询、缺失索引、模糊查询等方面性能表现优异，无需担心租户增加带来高并发问题以及租户单实体数据量大等问题；TiDB HTAP 能力使得海量数据场景下的各类查询秒级得到反馈，极大提升了 CRM 的用户使用体验。\n\n### 提升 SaaS 服务商的业务灵活性\n\n在 SaaS 的基础上集成 PaaS 能力已经成为中国企业级 CRM 市场发展的重要趋势，为了满足企业用户的高度定制化和多样化需求，PaaS 平台要求数据平台具备高度灵活的可定制能力，例如增加字段完成功能迭代等。TiDB 支持 Online DDL，可实现在线添加字段，修改字段对业务无影响，加快了业务创新的速度，进一步增强了 CRM 等 SaaS 服务商在同行业中的竞争力。\n\n### 多管齐下，降低成本\n\nTiDB 一个数据栈支持混合负载，并提供实时的数据洞察，精简了 CRM 服务商数据平台的架构。从单体数据库集群、ETL 工具、数据仓库的多套系统组合到一个 TiDB 集群，大幅节省了数据在各个技术栈之间同步的时间成本以及多个数据副本的存储成本。TiDB 无需分库分表，提高了产品研发的敏捷度，减轻了各类应用的适配难度，研发人员可以把更多精力放在功能迭代和业务创新上。此外，TiDB 还提供了整套的数据同步及数据库管理、监控工具，进一步降低了后期的运维管理成本。 \n\n采用一个简单、强大、一栈式的数据服务平台成为越来越多 SaaS 企业的选择，这个平台既可以支撑海量在线交易，又可以提供实时分析能力，以极少的 DBA 和资源投入，就可以从容应对不确定的环境、多变的业务挑战。 \n\n\n","author":"PingCAP","category":4,"customUrl":"htap-database-practice-in-a-chinese-saas-provider","fillInMethod":"writeDirectly","id":435,"summary":"CRM 并不是简单的销售和客户服务的效率工具。本质上，CRM 是以平台化思维实现业务管理和数据的打通，为 360 度客户旅程提供数字化支撑。","tags":["HTAP"],"title":"MySQL or TiDB？HTAP 数据库在中国 SaaS 行业头部服务商的应用实践"}}]}}},
"staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}