正文

当大数据架构遇上tidb(代码片段)

TiDB_PingCAP  TiDB_PingCAP  2022-12-14  442

关键词：

作者介绍：胡梦宇，知乎核心架构平台开发工程师，大数据基础架构方向，主要工作内容是负责知乎内部大数据组件的二次开发和数据平台建设。

前言

一年前，知乎的大数据架构与 TiDB 首次相遇，那时我们将 Hive MetaStore 的元数据库迁移到了 TiDB，得到了超过单机数据库一个量级的性能提升。在见识过分布式 NewSQL 数据库 TiDB 的威力后，我们对它寄予厚望，将它应用到了大数据架构的其他场景下，如：Hive 大查询报警，NameNode RPC 加速。

Hive 大查询报警

背景

在知乎内部，Hive 主要被应用与两个场景：1. ETL 核心链路任务 2. Adhoc 即席查询。在 ETL 场景下，Hive SQL 任务都比较固定而且稳定，但是在 Adhoc 场景下，用户提交的 Hive SQL 比较随机多变。在用户对 SQL 没有做好优化的情况下，启动的 MapReduce 任务会扫描过多的数据，不仅使得任务运行较慢，还会对 HDFS 造成巨大压力，影响集群的稳定性，这种情况在季度末或者年底出现得极为频繁，有些用户会扫描一季度甚至一整年的数据，这样的查询一旦出现，便会导致集群资源紧张，进而影响 ETL 任务，导致报表延迟产出。

SQL 大查询实时报警系统简介

针对以上痛点，我们开发了大 SQL 查询实时报警系统，在用户提交 SQL 时，会做以下事情：

解析 SQL 的执行计划，转化成需要扫描的表路径以及分区路径；
汇总所有分区路径的大小，计算出扫描数据总量；
判断扫描分区总量是否超过阈值，如果超过阈值，在企业微信通知用户。

下面详解每一步的具体实现。

从执行计划拿到 Hive 扫描的 HDFS 路径

这一步我们利用 Hive Server 的 Hook 机制，在每条 SQL 被解析完成后，向 Kafka 输出一条审计日志，审计日志的格式如下：


  "operation": "QUERY",
  "user": "hdfs",
  "time": "2021-07-12 15:43:16.022",
  "ip": "127.0.0.1",
  "hiveServerIp": "127.0.0.1",
  "inputPartitionSize": 2,
  "sql": "select count(*) from test_table where pdate in ('2021-07-01','2021-07-02')",
  "hookType": "PRE_EXEC_HOOK",
  "currentDatabase": "default",
  "sessionId": "5e18ff6e-421d-4868-a522-fc3d342c3551",
  "queryId": "hive_20210712154316_fb366800-2cc9-4ba3-83a7-815c97431063",
  "inputTableList": [
    "test_table"
  ],
  "outputTableList": [],
  "inputPaths": [
    "/user/hdfs/tables/default.db/test_table/2021-07-01",
    "/user/hdfs/tables/default.db/test_table/2021-07-02"
  ],
  "app.owner": "humengyu"

这里我们主要关注以下几个字段：

字段	含义
operation	SQL 的类型，如 QUERY, DROP 等
user	提交 SQL 的用户，在知乎内部是组账号
sql	提交的 SQL 内容
inputPaths	扫描的 HDFS 路径
app.owner	提交 SQL 的个人账号

汇总分区的大小

汇总分区大小需要知道 inputPaths 字段里每一个 HDFS 路径的目录大小，这里有以下几种解决方案：

方案	优点	缺点
调用 HDFS API 实时获取	结果准确	需要调用 getContentSummary 方法，比较耗费 NameNode 性能，等待时间比较久。
利用 Hive MetaStore 的分区统计信息	速度较快	结果可能不准，有些表通过其他计算引擎如 Flink，Spark 直接写入 HDFS 目录，没有及时更新统计信息；
利用 HDFS 的 fsimage 解析出所有 Hive 目录大小，存入 TiDB	速度较快	结果具有 T+1 的延迟，当天的分区无法统计大小。

考虑到使用场景，大 SQL 查询大部分情况下都是扫描了几个月甚至几年的数据，一两天的分区信息忽略可以接受，我们选择了第三种方案：每天将 HDFS 的 fsimage 解析，并且计算出每个 Hive 目录的大小，再将结果存入 TiDB。因为我们在其他场景也会用到 fsimage 的信息，所以这里我们不仅仅只存储了 Hive 目录，而是存储了整个 HDFS 的目录情况，近百亿条数据。很明显，在如此大的数据量下，还涉及到数据索引相关，TiDB 是一个很好的选择。

实时报警

我们将审计日志实时发送至 Kafka，再用 Flink 实时去消费 Kafka 内的审计日志，利用 KafkaTableSource 和 Json Format 将 Kafka 作为流表，再利用 JdbcLookupTableSource 将 TiDB 作为维表，便可轻松计算出每条 SQL 扫描的数据量再进行报警判断。

最后达成的效果如下：

NameNode PRC 加速

背景

故事的起因是这样的，在有一段时间内，经常有用户反馈 Hive 查询卡住没有反应，短的卡十几分钟，长的卡几小时，十分奇怪，经过定位发现是 Hive 内部在调用 getInputSummary 方法时，有一把全局锁，在某一个查询较大时，调用这个方法会花费较长的时间，导致其他的查询线程在等待这把锁的释放。经过阅读源码发现，getInputSummary 方法是可以并发去执行的，它内部其实就是在调用 HDFS 客户端的 getContentSummary 方法，我们将锁去掉，不再使用全局锁的功能，而是采用了类似线程池的方式，让它可以以一个较高的并发度去执行。但是这样会带来一些问题，HDFS 客户端的 getContentSummary 方法类似于文件系统的 du 操作，如果并发度过高，会显著影响 NameNode 性能。不仅仅只有 Hive，其他的计算引擎也会调用 getContentSummary 方法，因此，优化这个方法十分必要。

缓存 ContentSummary 信息

知乎在 2019 年 HDFS 就已经拆分了 Federation, 采取的是 Router Base Federation 的方案，引入了 NameNode 的代理组件 Router. 我们只要在 Router 层给 HDFS 的 ContentSummary 做一层缓存，在客户端发起调用时，如果缓存命中，则从缓存读取，如果缓存未命中，则从 NameNode 请求。经过内部讨论，缓存方案有以下几种：

方案	优点	缺点
客户端第一次请求 Router 时，从 NameNode 返回，更新缓存；第二次请求时，先拿缓存，并且判断目录的修改时间，如果期间发未发生修改，则返回缓存，如果发生了修改，从 NameNode 返回，更新缓存。	对于不常修改的目录，只需要请求一次 NameNode。	对于第一次请求依然需要去访问 NameNode；只能缓存没有子目录的目录，因为子目录的变更上层目录无法感知。
每天利用 fsimage 产出一份全目录的 ContentSummary 信息缓存至 TiDB，在客户端请求时，走第一种方案的逻辑。	大部分目录的第一次请求都不用走 NameNode。	依然只能缓存没有子目录的目录，因为子目录的变更上层目录无法感知。

我们选择了第二种方案，因为 ContentSummary 信息在我们之前做 Hive SQL 大查询报警的时候已经产出，所以接入进来十分方便。在接入 TiDB 做缓存，并且给请求路径建索引以后，对于一般情况下的 getContentSummary 请求，延迟能保证在 10ms 以下，而对于没有 TiDB 缓存的 NameNode，这个时间可能会花费几分钟甚至几十分钟。

展望

本次我们利用 TiDB 的超大存储和索引功能，缓存了 HDFS 的元信息，满足了知乎内部的一些场景，后续我们会持续改进和扩展此场景：比如缓存 HDFS 文件信息可以做成实时缓存，利用 Edit log 订阅文件变更，然后和 TiDB 里面的存量 fsimage 进行合并，产出低延迟的 NameNode 快照，用于一些在线的分析等。

大数据大数据组件tidb原理+实战篇(代码片段)

文章目录1.TiDB引入1.1.数据库技术发展简史1.2.从MySQL到TiDB1.3.TiDB概述1.4.数据库种类简介2.TiDB架构特性2.1.TiDB整体架构2.2.TiDB核心特性2.3.存储和计算能力3.TiDB安装部署3.1.TiDB-Local单机版3.2.TiDB-Docker集群版4.TiDB实践案例4.1.TiDB-SQL操作4.2... 查看详情

猿创征文|国产数据库tidb架构特性(代码片段)

前言TiDB是PingCAP公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理(HybridTransactionalandAnalyticalProcessing,HTAP)的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、... 查看详情

java遇上spl：架构优势和开发效率，一个不放过(代码片段)

...作者：石臻臻的杂货铺。现代Java应用架构越来越强调数据存储和处理分离，以获得更好的可维护性、可扩展性以及可移植性，比如火热的微服务就是一种典型。这种架构通常要求业务逻辑要在Java程序中实现，而... 查看详情

猿创征文|国产数据库实战之使用docker部署tidb集群(代码片段)

猿创征文|国产数据库实战之使用Docker部署TiDB集群一、TiDB介绍1.TiDB简介2.TiDB特性3.TiDB集群整体架构4.TiDB集群各部分介绍5.本次TiDB集群组件二、检查本地环境1.检查docker状态2.检查docker版本3.检查docker-compose版本三、下载tidb-docker-comp... 查看详情

猿创征文|国产数据库实战之使用docker部署tidb集群(代码片段)

网易云音乐dba谈tidb选型：效率的选择(代码片段)

...ry:本文摘自由网易DBA团队撰写的《效率的选择——分布式数据库TiDB网易内部选型介绍》一文，对比了以TiDB为基础的创新架构和MySQL+DDB传统架构的差异，从业务适配、降本增效、技术创新等多个维度阐释了网易考虑引... 查看详情

tidb一个大数据实时计算的存储利器(代码片段)

...是由中国PingCAP公司开发的，是一个开源的分布式NewSQL数据库。它最初的设计目标是解决传统关系型数据库的瓶颈和限制，实现高可用、可扩展和高性能的数据存储和处理。TiDB架构详解TiDB是一个分布式的NewSQL数据库，... 查看详情

tidb常用api(代码片段)

...TiDB的所有指标curlhttp://TiDBIP:10080/metrics#获取所有区域的元数据curlhttp://TiDBIP:10080/regions/meta#获取热点区域的表/索引curlhttp://TiDBIP:10080/regions/hot#通过ID获取特定区域的信息curlhttp://TiDBIP:10080/regions/regionID#从db.table中获取区域信息curlhtt... 查看详情

tidb常用api(代码片段)

tidb-使用ticdc将数据同步至下游mysql中(代码片段)

一、TICDCTiCDC是一款通过拉取TiKV变更日志实现的TiDB增量数据同步工具，具有将数据还原到与上游任意TSO一致状态的能力，同时提供开放数据协议(TiCDCOpenProtocol)，支持其他系统订阅数据变更。和前面学习的Tidbbinlog不同&... 查看详情

tidb-使用tidbbinlog实现数据复制(代码片段)

...解为Mysql的Binlog主从服务模式，并且TiDBBinlog还支持将数据发送到Kafka中，这又类似与Canal中间件。目前TIDBBinlog集群主要分为Pump和Drainer两个组件，以及binlogctl工具。TiDBBinlog整体架构注意：TiDBBinlog与TiDBv5.0版本开始... 查看详情

猿创征文｜分布式国产数据库tidb从入门到实战(代码片段)

写在前面本文讲解的是目前欢迎程度最高分布式国产数据库TiDB，详细讲解了TiDB的由来、架构、SQL基本操作、SpringBoot整合TiDB等内容。目录写在前面一、概述二、与MySQL兼容性对比三、安装使用四、SQL基本操作4.1、库操作4.2、... 查看详情

tidb入门+深入(代码片段)

...4、TiDB安装部署开发及测试环境生产环境5、TiDB-读取历史数据6、数据迁移-TiDBLightning一、概述数据库（DataBase）是按照数据结构来组织、存储和管理数据的仓库。我们的程序都是在内存中运行的，一旦程序运行结束或... 查看详情

猿创征文|国产数据库实战之tidb数据库快速入门(代码片段)

猿创征文|国产数据库实战之TiDB数据库快速入门一、系统检查1.检查系统版本2.查看本地IP地址3.TiDB集群介绍二、快速部署本地测试集群1.安装TiUP工具2.声明全局环境变量3.快速部署TiDB集群三、连接TiDB数据库1.新开一个session以访问T... 查看详情

tidb整体架构

参考技术ATiDB整体架构可参考下图节点内部之间的通信通过gRPC完成。除了上面提到的几种类型的节点外，TiDB还提供了一些数据同步的工具。查看详情

tidb海量数据新增索引(代码片段)

TIDB海量数据新增索引由于创建索引在扫表回填索引的时候会消耗大量资源，甚至与一些频繁更新的字段会发生冲突导致正常业务受到影响。大表创建索引的过程往往会持续很长时间，所以要尽可能地平衡执行时间和集群... 查看详情

tidb数据一致性校验实现：sync-diff-inspector优化方案(代码片段)

简介在数据同步的场景下，上下游数据的一致性校验是非常重要的一个环节，缺少数据校验，可能会对商业决策产生非常负面的影响。。Sync-diff-inspector是DataPlatform团队开发的一款一致性校验工具，它能对多种数据... 查看详情