数据存储和处理是一个古老而重要的技术, 从远古时期的结绳记事到古人的文本记事, 再到计算机诞生后的各种系统, 直到 E.F.Codd 提出关系模型, 人类终于有了一种相对高效而统一的数据处理系统 -- 关系数据库.
在传统的关系数据处理系统中, 习惯把系统按照业务特点分为在线事务处理系统 (OLTP) 和在线分析处理(OLAP), 一般意义上 OLTP 关注实时在线业务, 要求低延时, 高吞吐量, 总体数据量一般不会特别大; 而 OLAP 系统用来处理大规模数据的报表分析, 要求低响应时间. 两者因为数据量, 查询请求, 业务要求的不用, 加上之前技术条件的限制, 就分解为两个独立的系统, 即 OLTP 系统用来处理在线交易, OLAP 系统用来进行报表处理, 两者之间通过 ETL 工具连接.
一般这个两套数据库系统是相互独立的产品, 常见的 OLTP 产品有 IBM DB2,Informix,ORACLE,SQL SERVER,MySQL,PostgreSQL 等, 在 OLAP 常见的如 TeraData,SybaseIQ,GreenPlum,HP VERTICA, SAP HANA,Hadoop 大数据平台等等. 在这个架构中, 有两套独立的数据系统需要维护, 增加系统采购的成本和系统运维的成本; 同时 ETL 过程中 OLTP 到 OLAP 系统的数据一致性也是一个让人头疼的问题.
TBase 向我们展示了一种革命性的数据处理架构, 把 OLTP 和 OLAP 处理进行融合, 在一套数据库系统中同时完成两种操作, 同时降低业务复杂度和业务成本. TBase 在某省部门上线运行超过快四年, 在客户的架构升级中扮演了重要的角色, 当前在该客户有快 10 套 TBase 系统在运行, 集群规模快接近百台. 本文希望借助客户的实际案例来对 TBase 的架构进行下解析, 增加大家对 TBase 的了解.
TBase 架构特点:
TBase 分布式无共享 (share nothing) 分布式数据库, 集群结构如下:
Coordinator: 协调节点(简称 CN), 对外提供接口, 负责数据的分发和查询规划, 多个节点位置对等, 每个节点都提供相同的数据库视图; 在功能上 CN 上只存储系统的全局元数据, 并不存储实际的业务数据.
Datanode: 处理存储本节点相关的元数据, 每个节点还存储业务数据的分片, 简称 DN. 在功能上, DN 节点负责完成执行协调节点分发的执行请求.
GTM: 全局事务管理器(Global transactionmanager.), 负责管理集群事务信息, 同时管理集群的全局对象, 比如序列等.
在这个架构下, TBase 集群具有下面几个能力:
多活 / 多主: 每个 coordinator 提供相同的集群视图, 可以从任何一个 CN 进行写入, 业务无需感知集群拓扑;
读 / 写扩展: 数据被分片存储在了不同的 DN, 集群的读 / 写能力, 随着集群规模的扩大做而得到提升;
集群写一致: 业务在一个 CN 节点发生的写事务会一致性的呈现在其他的 CN 节点, 就像这些事务是本 CN 节点发生的一样;
集群结构透明: 数据位于不同的数据库节点中, 当查询数据时, 不必关心数据位于具体的节点;
TBase 的 share nothing 集群架构方便了业务接入, 降低了业务接入的门槛.
TBase 的 HTAP 能力:
HTAP 是混合事务和分析处理 Hybrid Transactional/Analytical Processing 的简写, TBase 通过下面这些技术构建了原生的 HTAP 能力.
事务 ACID 强保证:
在分布式数据库中, 分布式事务的 ACID 保证是一个很有挑战性的工作, 但是业务系统在使用数据库的过程中, 往往会依赖数据库提供的 ACID 能力来开发他们的业务, 因此事务 ACID 能力的保证也成了分布式数据库必不可少的能力. 先把数据库理论中的 ACID 的定义拿出来, 熟悉下这些概念:
ACID, 指数据库事务正确执行的四个基本要素的缩写. 包含: 原子性 (Atomicity), 一致性(Consistency), 隔离性(Isolation), 持久性(Durability). 一个支持事务(Transaction) 的数据库, 必须要具有这四种特性, 否则在事务过程 (Transaction processing) 当中无法保证数据的正确性, 交易过程极可能达不到交易方的要求.
详细解释下:
原子性 (Atomicity): 整个事务中的所有操作, 要么全部完成, 要么全部不完成, 不可能停滞在中间某个环节. 事务在执行过程中发生错误, 会被回滚(Rollback) 到事务开始前的状态, 就像这个事务从来没有执行过一样.
一致性(Consistency): 事务必须始终保持系统处于一致的状态, 不管在任何给定的时间并发事务有多少.
也就是说: 如果事务是并发多个, 系统也必须如同串行事务一样操作. 其主要特征是保护性和不变性(Preserving an Invariant), 以转账案例为例, 假设有五个账户, 每个账户余额是 100 元, 那么五个账户总额是 500 元, 如果在这个 5 个账户之间同时发生多个转账, 无论并发多少个, 比如在 A 与 B 账户之间转账 5 元, 在 C 与 D 账户之间转账 10 元, 在 B 与 E 之间转账 15 元, 五个账户总额也应该还是 500 元, 这就是保护性和不变性.
一致性是分布式事务中的重大挑战, 网络时延和操作系统调度等不确定因素给分布式事务一致性的保证带来诸多困难, 但是分布式数据必须有一套完整的分布式事务一致性逻辑, 否则会带来灾难性的后果.
隔离性(Isolation): 隔离状态执行事务, 使它们好像是系统在给定时间内执行的唯一操作. 如果有两个事务, 运行在相同的时间内, 执行相同的功能, 事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统. 这种属性有时称为串行化, 为了防止事务操作间的混淆, 必须串行化或序列化请求, 使得在同一时间仅有一个请求用于同一数据.
持久性(Durability): 在事务完成以后, 该事务对数据库所作的更改便持久的保存在数据库之中, 并不会被回滚.
TBase 中的事务严格遵守事务的 ACID, 当前支持 read committed 和 repeatable read 两个隔离级别, 并提供可扩展的事务吞吐能力. 在事务测试模型 TPC-C 中有 9 张表, 用来模拟从仓库中下订单发货, 库存状态查询, 并有一定的回滚比例, 每个事务中有 5-6 条 SQL, 读写混合, 测试过程中要求严格遵守 ACID. 在这个模型下 TBase 的处理能力随着集群规模的提升近似线性提升, 在 30 台 (24core,64G,1000Mb) 规模时可以达到 300W tpm.
Share nothing 架构决定了随着集群规模的增加系统的 TPC-C 处理能力会进一步的提升, TBase 在事务处理中处理能力可以到千万级 QPS.
完整 SQL 兼容性:
SQL 是访问数据库的必备工具, 在 SQL 诞生了几十年后的今天, 大量的软件产品使用 SQL 进行开发, 每个程序员都或多或少的使用到 SQL, 数据库对 SQL 的处理能力直接关系软件产品的稳定和程序开发的效率. TBase 在设计之初就定下一条设计规则: SQL 语法完全兼容 SQL2003 标准, 让用户像使用普通数据库一样来使用 TBase.
因此在 TBase 中, 数据库开发工程师可以像在之前熟悉的数据库产品中一样编写 SQL, 不用担心数据库产品的变化带来额外的学习工作量. 为业务节省大量的开发工作, 降低业务升级的成本.
除了 SQL 语法兼容性, 为了达到高效的分布式执行, TBase 有专门为分布式环境设计的基于代价的查询优化器, 与之配合的是专门为分布式环境设计的分布式执行器.
分布式执行器提供了目前已知的所有数据库算子 (operator) 支持, 包括聚合, 窗口函数, cube, 存储过程, 自定义函数, 触发器, 物化视图, 并行执行等等.
完美的 SQL 语法兼容 + 代价优化器 + 分布式执行器 = 完整 SQL 兼容性, 为业务提供良好了的数据库使用体验, 大幅降低业务的迁移成本和开发人员的学习成本, 提高业务迁移的效率.
SQL 兼容性和性能我们通过 TPC-H 来测试. TPC-H 标准满足了数据仓库领域的测试需求. TPC-H 中 用 3NF 实现了一个数据仓库, 共包含 8 个基本表, 22 个查询(Q1~Q22), 其主要评价指标是各个查询的响应时间, 即从提交查询到结果返回所需时间(越短越好). 其中的查询主要涉及: 多表关联(超过 4 张), 多表聚合, 子查询等.
下图是 TBase 在行存储模式下 TPC-H 测试结果和国际知名数据库仓库的测试结果对比, 从测试结果来看, TBase 在所有 22 个测试用例中都大幅度的领先.
在数据库语法中, 除了 SQL 标准外, 每个数据库都产品有自己的本地化语义, 在本地化语义方面, TBase 完整的的兼容 PostgreSQL 语法, 部分兼容 Oracle 语法.
完整列存储能力
数据库的物理文件存储格式常见的有两种: 按行存储和按列存储. 下面对每种存储结构给出一个例子, 下表是我们的表结构和定义.
姓名 | 部门 | 薪酬 | 家庭信息 |
---|---|---|---|
蜘蛛侠 | 工程部 | 200 | XX |
超人 | 采购部 | 300 | YY |
火箭浣熊 | 采购部 | 150 | ZZ |
闪电侠 | 工程部 | 100 | EE |
钢铁侠 | 董事局 | 500 | EE |
如果采用按行存储的格式, 我们的数据文件是左边这样的, 按列存储是右边这样的:
列存储
行存储
按行存储格式, 数据按照逻辑顺序相同的方式来来进行文件存储, 一行中的所有列数据按照顺序存储在物理磁盘上, 这种格式的好处很明显, 如果同时访问一行中的多列数据时, 一般只需要一次磁盘 IO, 比较适合 OLTP 类型的负载.
按列存储格式, 表中的每列数据存储为一个独立的磁盘文件, 比如例子中,"姓名","部门","薪酬","家庭信息" 每列中的数据都为一个独立的数据文件, 这中格式在一次需要访问表中少数列时相比行存能够节省大量的磁盘 IO, 在聚合类场景下尤其高效, 因此多用在 OLAP 类系统中.
行存储是 TBase 的基本存储格式, 为了支持高效的 OLAP TBase 也提供了完整的列存储能力, 业务可以根据自己的需要对写入数据库中的数据选择需要的存储格式. TBase 的列存储还支持强大的压缩能力, 支持透明压缩和轻量级压缩, 透明压缩支持 gzip,zstd 等压缩算法, 轻量级压缩算法可以根据数据的特征进行高效压缩, 压缩比高达 400+.
TPC-DS 是一套决策支持系统测试基准, 主要针对零售行业. 提供了 99 个 SQL 查询(SQL 2003), 分析数据量大, 测试数据与实际商业数据高度相似, 同时具有各种业务模型(分析报告型, 数据挖掘型等等), 主要用来对决策支持系统进行性能性能评测. TBase 列存储的 TPC-DS 上运行了 1T 的工作集合, 测试结果如下:
从测试结果来看, TBase 在列存储模式下的 TPC-DS 能力要远远优于业界标杆.
PS:TBase 中行表和列表之间可以进行任意关联查询, 可以进行相互的格式转换(通过 insert into select).
资源隔离能力
在 HTAP 系统中, OLTP 和 OLAP 业务要同时运行, 两者都会消耗巨量的资源都, 如果不对资源使用进行隔离必然会造成相互之间的干扰, 影像系统的整体稳定性和服务质量.
TBase 中的资源隔离方案 -- 节点组的资源隔离方案, 如果业务的 OLTP 和 OLAP 访问的是不同的数据, 可以使用 TBase 中的节点组把 OLTP 业务和 OLAP 业务在集群中分离为两个节点组, 对与 OLTP 节点组中的 CN 设置 OLTP 优化器, 对于与 OLAP 节点组中的 CN 设置 OLAP 优化, 从硬件上进行严格的分离.
在 TBase 中每个用户 session 都有一个资源配额限制, 使用这个配额可以限制用户 session 的 CPU, 内存, 网络等资源, 在 OLTP 和 OLAP 不存在绝对竞争的场景也可以让两者运行在同一个 group, 使用用户资源配置来资源进行管控和配置.
TBase 资源隔离方式 - 多副本方式(专利技术), 多平面技术, 此时用户数据还是同一份数据, 通过副本复制的方式把数据从 OLTP 系统复制到 OLAP 系统, 同时实现行存储到列存储的转换, 通过这种方式从硬件上分离了 OLTP 和 OLAP 业务, 同时数据库内部的数据复制可靠性由数据库内部机制保证, 可靠性远远高于 ETL 工具. 这种资源隔离技术 TBase 中的叫多平面技术.
通过上面这些资源隔离技术, TBase 实现了 HTAP 中关键的资源隔离技术, 可以很好的保证系统的服务质量和改善客户体验.
TBase 安全解决方案:
得益于 TBase 常年服务公司内部客户, TBase 建设了一套很有特色的数据安全系统, 可以说 TBase 是目前市面上安全能力最出色的数据库产品, 这一特性得到内外部客户的一致认可, 并作为安全技术标准写入到 PICC 的数据库安全规范中.
TBase 的数据安全系统我们称之为 MLS(multiplelevel security), 这个体系的整体视图如下:
以三权分立为基础, 消除系统的超级用户权限. 在安全管理规则中增加强制安全规则, 支持对表进行矩阵式的权限划分, 在数据访问层和存储层进行加密和脱敏控制, 防止数据拖库时发生的数据泄密:
在事后追溯和实时审计中, TBase 提供了完整的审计规则和丰富的自定义审计规则来进行支持. 通过 FGA(细粒度审计),TBase 还可以做到数据越权访问的实时告警, 实时防止数据越权访问.
客户案例场景:
案例 1:TBase 协助解决某省汇集库瓶颈, 助力客户架构升级:
原有系统使用 OracleRAC 集群. Oracle 在支撑数据量到 300 亿数据时, 计算和查询的时候能力已经到达极限, 超时宕机的场景频发, 入库的速率最后只能达到 3000 条 / 秒的极限值, 远远无法满足业务需要.
TBase 汇集库在系统中的位置:
汇集库在系统中承担着数据汇集处理的作用, 既要对接其他关系数据库, 消息中间件等, 还要运行部分核心系统的 OLTP 业务, 并在这两者数据的基础上运行模型构建, 离线行为分析等 OLAP 类计算. 是一个典型的 HTAP 系统.
之前的系统之所以遇到瓶颈, 很大程度上也是因为业务模型本身计算量大, 模型复杂超出了 RAC 的处理效率.
TBase 团队在分析了业务的特点后, 结合 TBase 的本身能力为业务制订详细的解决方案. 方案的核心要点是 OLTP 和 OLAP 的多平面资源隔离技术, 我们为系统的请求详细的划分了业务的运行平面, 业务的写入全都集中在主平面, 把查询类的请求根据计算复杂度和实时要求划分到备用平面和主平面. 很好的隔离了实时请求和离线请求. 汇集库 TBase CN 和 DN 的部署结构如下图.
汇集集群当前有节点数近百, 存储数据数百 T.120 亿数据的 OLTP 类业务 1 秒内完成处理. 处理性能远远超越了之前系统, 成本相比却大幅降低, 得到用户的高度认可!
案例二: 物联网地理信息系统:
业务背景: 随着物联网的到来, 很多的传感器数据需要进行接入, 这些数据中都包含共同点, 都包含一些点位信息(经度和纬度). 结合这些位置信息和我们已有的地理信息进行关联分析, 可以分析出很有价值的数据, 为国民生产生活所用.
这个系统的核心功能是要对地理位置信息进行关联计算和查询, 这个需要 TBase 提供的地理信息能力进行支持. PS:TBase 支持最先进的开源地理信息引擎 PostGIS, 可以提供丰富高效的地理信息处理能力.
该业务系统的部署架构如下:
TBase 上游对接接业务传感器后端的 ETL, 数据进入集群后先对清洗变换, 并把人和位置信息进行关联形成宽表; 在宽表的基础上进行 GIS OLAP 分析, 输出我们需要的高价值信息.
目前 GIS 的数据规模已经超过 100T.
案例三, 某核心 OLTP 在线核查系统:
某省核心服务微信公众号后台系统, 核心系统结构如下:
业务的核心 TBase 服务器部署内网, 敏感数据部署在这个核心 TBase 实例中, 互联网部署的一台应用服务器, 运行公众号相关的业务数据, 并通过网络边界同步工具把数据同步到业务内网.
总结: TBase 构建 HTAP 能力的过程中团队小伙伴们突破了一个又一个技术难点, 创造了一个又一个 "不可能", 回顾这个过程, 就想起一句古语 "筚路蓝缕, 以启山林"! 对 TBase 来说, 应该是 "筚路蓝缕, 开拓创新"!
当前 TBase 服务的外部客户包括金融, 公安, 消防, 政务, 医疗, 社保, 能源, 税务等行业, 外部集群超过 30 个. 在案例中的省份上线运行已经快 4 年, 集群规模从最开始的十几台逐渐增长到现在的近百台, 业务系统也有最初的一个增长到现在的快十个, 在帮助业务解决痛点的同时, TBase 自己也获得了很多成长的机会!
感谢大家对 TBase 的关注, 希望有更多的机会和大家交流!
来源: https://www.qcloud.com/developer/article/1398288