聊聊主流的分布式数据库

单体数据库时代,随着系统交易量的不断上升,数据库读写性能出现了严重下降。我们可以借助分库分表中间件,比如mycat、shardingjdbc来实现分库分表,缓解单库的读写性能。但是分库分表中间件并不支持事务,如果要保证数据一致性,就需要借助于分布式事务中间件,比如阿里巴巴的seata。后来分布式数据库逐渐成为解决数据一致性的选择,目前分布式数据库产品已经比较成熟,支持ACID事务,本文就来聊一聊分布式数据库。

增加代理层

以mysql为例,我们来看一下单体数据库的逻辑架构,如下图:

从这个图我们可以看到,mysql包括连接器层,server层,存储引擎层和数据/文件层。单体数据库场景下,数据库本身就是支持事务的,我们不用事务做额外的工作。

如果需要分库分表,这时架构就需要调整,如下图:

这个架构增加了代理层,它的功能包括客户端接入、简单的查询处理、进程管理和分片信息管理。这时因为数据分布在不同的切片上,使用的复杂性也大幅度增加。

如果应用要进行全量分页查询、关联查询、排序等应用,一个简单的代理层是很难满足的,代理层必须支持复杂的运算,这时就基本过度到分布式数据库了,而代理层也被叫做了协调节点。

协调节点增加了运算能力,但是要支持分布式事务的一致性,还是远远不够的。下面我们就看一下一致性问题。

一致性

在分布式的CAP理论中,数据一致性是终极目标。我们来聊一下线性一致性和因果一致性。

先看线性一致性,如下图:

图片

 

user1读取足球比赛成绩,比分4:2,1秒之后,user2读取比赛成绩,但user2读到的成绩是4:1,这样后读取的用户读取到的数据反而是旧的数据。

发生这个问题的原因就是多副本同步延迟,而线性一致性要解决的问题如下:

  • 用户的读写请求顺序与实际的时间相一致

  • 如果user1读取某一个key之前user2已经修改了key,那user1读取到的值一定是user2修改后的值

线性一致性是分布式下最强的一致性理论,主流的数据库产品解决线程一致性的手段是引入全局时钟,用单点授时的方式,从这个单一节点获取时间,而且必须保证单一时钟节点的高可靠性。

线性一致性的问题是全局时钟的并发问题,如果共用一个物理时钟,性能必然受到影响。

如果我们在一致性和高性能之间做一个取舍,我们可以降低一些一致性来提高并发性能。这个理论就是因果一致性,它一致性要求低于线性一致性。因为一致性的基础是在数据库的单一切片上,事件肯定是有先后顺序的。在不同的切片上,需要通信的话,发送事件肯定早于接收事件。

基于因果一致性,引入了逻辑时钟的概念。目前也有一些数据库使用逻辑时钟来实现因果一致性,虽然比线性一致性弱一些,但是性能更好。

NewSQL架构

上面我们介绍了传统关系型数据库,增加了切片集群,增加了协调节点,增加了全局时钟,这样就演变成了分布式数据库。如下图:

 这种数据库架构被业内称为PGXC架构,这个名字是PostgreSQL-XC的简称,它是一种提供写可靠性,多主节点数据同步,数据传输的开源集群方案。

注意:这种架构被叫做PGXC,并不是专指PostgreSQL-XC这种分布式数据库,而是文章上面讲的架构风格的一类数据库。

 

NewSQL是由NoSQL键值数据库发展而来,它是一类新的数据库架构方案,不仅具有NoSQL对海量数据的存储管理能力,还保持了传统数据库支持ACID和SQL等特性。它主要有以下特性:

  • 放弃了PGXC架构中单体数据库的事务支持
  • 在BigTable基础上构建了事务支持
  • 引入分片机制,主要采用Range动态分片技术,跟HASH分片相比,数据可以不用固定的在某一个分片上
  • 可靠性方面,放弃传统数据库的主从复制,采用Paxos、Raft等共识算法来保证HA
  • 存储引擎方面,使用LSM-Tree替换B+树模型,写入性能更高
  • 支持事务管理

PGXC数据库 

PGXC数据库由传统关系型数据库基于分库分表的技术演化而来,优点是性能比较稳定,缺点是写入能力有限,这是由架构风格决定的。

我们来介绍几款主流的PGXC数据库,代表如下:

1.TBase

TBase是腾讯数据平台团队在基于PostgreSQL研发的,支持HTAP(Hybrid Transaction and Analytical Process),主要由协调节点、数据节点和全局事务管理器(GTM)组成。特点如下:

  • 分布式事务支持RC和RR两个隔离级别
  • 支持高性能分区表,数据检索效率高
  • SQL语法兼容SQL2003标准、也支持PostgreSQL语法和Oracle主要语法

开源地址:

https://gitee.com/mirrors/tbase

2.GuassDB 300

GuassDB 300由华为研发,也是基于开源PostgreSQL研发的,支持HTAP,支持SQL92、SQL99和SQL2003语法,并且支持提供存储过程、触发器、分页等。目前在招商银行、工商银行和民生银行有使用。

3.AntDB

由亚信科技开发,基于开源PostgreSQL内核研发的,主要特点是对Oracle兼容性高,分布式事务支持2PC协议和MVCC,集群支持动态扩展。

开源地址:

https://gitee.com/adbsql/antdb

4.GoldenDB

由中兴通讯研发,跟前面3款不一样的是,这款数据库以mysql为内核构建的,按照官方的描述,这款数据库对金融行业的支持比较好,目前中信银行的核心业务系统有使用。

5.TDSQL

TDSQL由腾讯研发,它算不上是完全的PGXC架构,因为没有全局时钟。不过它也有自己解决一致性的方案,它的自增长序列为用户提供一个全局唯一数字ID服务,对全局锁和mvcc都有一定的作用。

NewSQL数据库 

NewSQL数据库有很大的架构上的优势,但是首先难度也很大,我们来看一下目前主流的数据库产品。

1.谷歌Spanner

谷歌Spanner可以说是NewSQL数据库的鼻祖,后来的好多数据库都是借鉴了Spanner的思想。它有下面几个特性:

使用GPS加原子钟的方式来实现全局时钟,这就就是引入了true time,支持全球化部署

支持线性一致性

2.TiDB

TiDB也是非常有名的一块NewSQL数据库,由PingCAP研发,支持HTAP,支持线性一致性,一个亮点是兼容mysql协议和生态,github地址如下:

https://github.com/pingcap

3.Ocean Base

蚂蚁集团研发,按照官方说法,2020年5月,OceanBase以7.07亿tpmC的在线事务处理性能,打破了去年自己创造的TPC-C 世界纪录。截止至目前,OceanBase 是第一个也是唯一一个上榜的中国数据库。

虽然官方说Ocean Base高度兼容各种主流关系型数据库,但是业界普遍认为对Oracle兼容不太好。

采用Paxos分布式选举算法来实现高可用。

4.SequoiaDB

巨杉金融级分布式数据库,它具有如下特性:

完整支持分布式事务、强一致、多副本高可用,满足分布式核心交易业务需求

支持 MySQL、PostgreSQL、SparkSQL 和 MariaDB 四种关系型数据库实例,100%兼容MySQL语法

支持HTAP混合事务/分析处理

目前在广发、民生等金融机构有一定使用。

5.CockroachDB和YugabyteDB

这2个数据库放在一起讲的原因是它们不支持线性一致性,只支持因果一致性,因为它们使用的是混合逻辑时钟(Hybrid Logical Clocks),它们的设计思想都是来自Spanner。

CockroachDB采用了Range分区,每个range对应一个RocksDB数据库,同时使用raft算法的改进算法multi raft,让多分片并行处理提升性能。

YugabyteDB除了NewSQL的特性外,还支持文档数据库接口,查询层支持同时SQL和CQL两种API,SQL API是基于postgreSQL改的,所以对postgreSQL的支持非常好。

Aurora数据库

Aurora数据库是amazon推出的云原生数据库,它的特点是计算节点垂直扩展,存储节点可以水平扩展。可见计算节点依然是单节点。Aurora基于mysql引擎构建,100%支持mysql。

Aurora数据缓存在主节点,然后同步到其他从节点,可见跟其他分布式数据库相比,从节点不支持写入,所以不支持多写,从节点只能分担读的压力。

不过这也是一种风格,目前这个风格的数据库有阿里的polarDB,腾讯的CynosDB和华为的Taurus。

总结

传统的分库分表架构不断演进,增加了协调节点,全局时钟,就演变成了PGXC架构,这是主流分布式数据库的一个分支。

在基于BigTable键值数据库的基础上增加事务支持,就演变成了NewSQL,是分布式数据库的另一个分支。

amazon推出Aurora分布式数据库并不算是上面2种架构的一种,并没有解决分布式场景下的写入压力,但也是一种分布式数据库的风格。

分布式数据库的产品已经很成熟,数量也很多,需要结合业务特性来做技术选型。


公众号:jinjunzhu


 

<think>嗯,用户让我聊聊ETL工具,我需要先理解ETL是什么,然后逐步展开。首先,ETL代表的是提取、转换、加载,这三个步骤对吧。用户可能想了解ETL的基本概念、流程、常用工具以及应用场景。 先想想ETL的定义。提取是从不同数据源获取数据,比如数据库、文件或者API。转换可能包括清洗数据、格式转换、合并等操作,确保数据质量。加载就是把处理后的数据存储到目标数据库或者数据仓库里,比如Hadoop、AWS Redshift这些。 接下来,用户可能需要知道ETL的流程。分三个阶段,每个阶段的具体任务是什么。比如提取的时候要考虑增量还是全量,转换阶段有哪些常见操作,比如过滤无效数据、标准化日期格式,或者数据聚合。加载阶段的不同策略,比如覆盖还是追加。 然后,常用的ETL工具。这里需要分开源和商业工具。开源的像Apache NiFi、Kettle(现在叫Pentaho Data Integration)、Talend,还有Airflow可能也算,虽然它更偏向任务调度。商业工具比如Informatica、IBM DataStage、微软的SSIS,还有AWS Glue这种云服务。每个工具的特点是什么,比如NiFi的可视化界面,Talend的代码生成,云服务的优势等。 应用场景方面,数据仓库构建、数据迁移、数据集成,还有大数据处理。比如企业要整合多个系统的数据到数据仓库进行分析,或者迁移旧系统到新系统时的数据转移,或者实时处理日志数据。 可能还需要比较一下ETL和ELT的区别,现在随着大数据技术的发展,ELT更流行,因为转换步骤可以在目标系统进行,利用其处理能力,比如Snowflake、BigQuery这些云数据仓库。 最后,选型时的考虑因素,数据源类型、处理速度(实时还是批处理)、扩展性、成本,以及团队的技术栈。比如小公司可能选开源工具节省成本,大企业可能需要商业工具的支持和稳定性。 用户可能是想了解ETL的基础知识,或者在选择工具时寻求建议。需要确保回答结构清晰,分点解释,同时给出实际例子帮助理解。还要注意用户可能对技术细节不太熟悉,所以语言要尽量通俗,避免过多术语,必要时举例说明。 现在检查有没有遗漏的部分,比如ETL的挑战,比如数据质量、处理效率、错误处理等,可能也需要提到。不过用户的问题主要是“介绍一下”,所以可能不需要太深入,但简要提及可以增加全面性。 总结一下,回答的结构应该是:定义ETL,分步解释三个流程,介绍常见工具(分开源和商业),应用场景,与其他概念的区别(如ELT),选型考虑因素,以及面临的挑战。这样用户就能有一个全面的了解,同时帮助他们在实际应用中选择合适的工具。</think>### ETL工具介绍:从数据搬运工到价值挖掘器 ETL(**Extract-Transform-Load**)是数据处理的**核心流程**,用于将分散、异构的数据整合为统一、可分析的形态。以下是逐步解析: --- #### 一、ETL核心三步骤 1. **提取(Extract)** - **目标**:从**异构数据源**(如数据库、日志文件、API)抓取数据。 - **关键点**:需处理全量/增量抽取、数据源兼容性(如MySQL vs NoSQL)。 2. **转换(Transform)** - **核心任务**:清洗、标准化、计算衍生字段。例如: - 过滤无效记录(如手机号格式错误) - 合并多表数据(如用户表+订单表) - 计算指标(如用户留存率:$$ \text{留存率} = \frac{\text{次日活跃用户数}}{\text{首日新增用户数}} \times 100\% $$) 3. **加载(Load)** - **策略**:全量覆盖(适合小数据)、增量追加(大数据场景)。 - **目标系统**:数据仓库(如Hive)、数据湖(如S3)、BI平台(如Tableau)。 --- #### 二、主流ETL工具对比 | 类型 | 工具举例 | 特点 | 适用场景 | |------------|--------------------|-----------------------------------|------------------------| | **开源** | Apache NiFi | 可视化拖拽,支持实时流处理 | IoT设备数据采集 | | | Kettle (PDI) | 轻量级,社区活跃 | 中小企业传统ETL | | **商业** | Informatica | 企业级功能完善,支持复杂逻辑 | 金融行业数据治理 | | **云原生** | AWS Glue | Serverless架构,无缝集成S3/Redshift | 云上数据湖构建 | --- #### 三、典型应用场景 1. **数据仓库构建** - 将分散的ERP、CRM系统数据整合到**Snowflake**,支撑BI分析。 2. **实时风控** - 使用**Flink**实时ETL处理交易日志,检测异常行为(如每秒交易次数 > 100触发告警)。 3. **数据迁移** - 从Oracle迁移到PostgreSQL时,处理字段类型转换(如`NUMBER`转`INTEGER`)。 --- #### 四、选型关键考量 1. **数据规模** - 日均TB级数据优先选择分布式工具(如**Spark**)。 2. **实时性需求** - 分钟级延迟可用**Kafka Streams**,小时级批处理用**Airflow**。 3. **开发成本** - 低代码工具(如**Talend**)减少编码工作量。 --- #### 五、ETL vs ELT新趋势 传统ETL在加载前转换数据,而现代**ELT**(如**dbt**)利用云数仓的计算能力,直接在目标端转换: ```sql -- dbt示例:在Snowflake中直接转换 SELECT user_id, SUM(order_amount) AS lifetime_value -- 直接计算用户LTV FROM orders GROUP BY 1 ``` 优势:减少中间环节,充分利用云资源弹性。 --- #### 六、挑战与解决思路 - **数据质量**:通过**Great Expectations**定义校验规则(如字段非空率 ≥ 99.9%)。 - **性能瓶颈**:对10亿级数据,采用**分区并行处理**(如按日期分片)。 - **维护成本**:使用**数据血缘工具**(如Apache Atlas)追踪字段级依赖关系。 --- 通过合理选择ETL工具和架构设计,企业能将原始数据转化为高价值资产,驱动数据驱动决策。实际项目中建议先通过PoC验证工具与业务场景的匹配度。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

君哥聊技术

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值