需求:
腾讯云数据仓库PostgreSql TDSQL,PingCAP的TiDB,阿里的OceanBase,华为云DWS,都是HTAP的业内常用数仓,可以一站式解决需求。
https://cloud.tencent.com/document/product/878/18778
云数据仓库 PostgreSQL(Cloud Data Warehouse PostgreSQL)(原 Snova 数据仓库)为您提供简单、快速、经济高效的 PB 级云端数据仓库解决方案。云数据仓库兼容 Greenplum 开源数据仓库,是一种基于 MPP(大规模并行处理)架构的数仓服务。借助于该产品,可以使用丰富的 PostgreSQL 开源生态工具,实现对云数据仓库中海量数据的即席查询分析、ETL 处理及可视化探索,对标华为云DWS;
数据接入可使用DataX工具将其他数据源如MySQL、SQL Server、Oracle、PostgreSQL、HDFS、Hive、HBase数据增量更新或者离线更新至云数仓PGSQL。并支持通过SQL方式将需要的数据导入至云数仓PGSQL。若有多个数据源可配置多个DataX任务进行数据接入。
类型 | 数据源 | Reader(读) | Writer(写) | 文档 |
---|---|---|---|---|
RDBMS 关系型数据库 | MySQL | √ | √ | 读 、写 |
Oracle | √ | √ | 读 、写 | |
SQLServer | √ | √ | 读 、写 | |
PostgreSQL | √ | √ | 读 、写 | |
通用RDBMS(支持所有关系型数据库) | √ | √ | 读 、写 | |
NoSQL数据存储 | Hbase0.94 | √ | √ | 读 、写 |
Hbase1.1 | √ | √ | 读 、写 | |
MongoDB | √ | √ | 读 、写 | |
Hive | √ | √ | 读 、写 | |
无结构化数据存储 | TxtFile | √ | √ | 读 、写 |
FTP | √ | √ | 读 、写 | |
HDFS | √ | √ | 读 、写 | |
Elasticsearch | √ | 写 |
https://cloud.tencent.com/document/product/878/47391
https://github.com/HashDataInc/DataX
或者使用COS数据作为外表进行加载与查询,存储时间较长,查询需求较少的冷数据也可迁移至COS以减少成本。
加载COS数据 https://cloud.tencent.com/document/product/878/34875
冷数据迁移 https://cloud.tencent.com/document/product/878/45908
数仓内进行数据聚合ETL管理可以使用开源组件AirFlow或者azkaban,安装配置完成后可以对数仓内多个表进行实时/离线聚合,这里以AirFlow为例。
https://cloud.tencent.com/document/product/878/47355
TiDB是PingCAP公司自主设计、研发的开源分布式关系型数据库,是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型分布式数据库产品,具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。
数据迁移:https://docs.pingcap.com/zh/tidb/stable/migration-overview
常用OLAP MPP框架优劣势
业界常用组合方案 Hbase+Phoenix 、Kudu+impala、 clickhouse 对比如下
HBASE在实时大批量查询与写入表现都很优秀,在引入Phoenix后查询方便许多,也能解决一些rowkey设计问题。不过后期运维成本可能会较高。
业务聚合处理: 简单的可以使用Phoenix写SQL直接进行,支持跨多表聚合,复杂的聚合操作可使用spark进行处理;
事务性:HBASE支持对数据进行修改;
扩展与运维:EMR支持一键扩容,可提供运维;
Kudu和Impala均是Cloudera贡献给Apache基金会的顶级项目。Kudu作为底层存储,在支持高并发低延迟kv查询的同时,还保持良好的Scan性能,该特性使得其理论上能够同时兼顾OLTP类和OLAP类查询。Impala作为老牌的SQL解析引擎,其面对即席查询(Ad-Hoc Query)类请求的稳定性和速度在工业界得到过广泛的验证,Impala并没有自己的存储引擎,其负责解析SQL,并连接其底层的存储引擎。在发布之初Impala主要支持HDFS,Kudu发布之后,Impala和Kudu更是做了深度集成。
在众多大数据框架中,Impala定位类似Hive,不过Impala更关注即席查询SQL的快速解析,对于执行时间过长的SQL,仍旧是Hive更合适。
对于GroupBy等SQL查询,Impala进行的是内存计算,因而Impala对机器配置要求较高,官方建议内存128G以上,此类问题Hive底层对应的是传统的MapReduce计算框架,虽然执行效率低,但是稳定性好,对机器配置要求也低。
执行效率是Impala的最大优势,对于存储在HDFS中的数据,Impala的解析速度本来就远快于Hive,有了Kudu加成之后,更是如虎添翼,部分查询执行速度差别可达百倍。
区别于Hbase等存储引擎,Kudu有如下优势:
列式存储有如此优势,主要因为两点:
Kudu和Hbase有如下两点本质不同
Kudu可以保证单行操作的原子性
Kudu不支持多行的事务操作,不支持回滚事务
在多表聚合ETL可使用impala view创建不同数据源的临时表,再使用实时与离线任务加载不同数据源聚合的宽表,供业务方进行不同的聚合查询统计。
单看性能,Cassandra还是很强大的,不过和其他数据库不太一样的地方,Cassandra 是一种无主的,反言之即 Cassandra 是一种多主的。多主的意思就是多个节点都可以操作,并不是都转发到一个节点上。在一个节点上很容易加锁,只要对某一行加锁,对所有的请求保持串行就可以了。所以对于独立行写其实是有冲突的,在 Cassandra 里面解决冲突的办法是很暴力的,就是 last write win ( 最后写入者获胜 ),因此导致 Cassandra 不适合做先读后写的操作。对于这种场景,Cassandra 建议使用 cas 的语法,但 cas 的性能比较差,因此使用 cassandra 时要避免冲突很多的场景。什么是冲突很多呢?比如多个手机用户同时更新一条数据,就是强冲突的。
在数仓写入性能有瓶颈,写入压力较大的或者对实时性要求较高情况下,可以引入实时计算框架进行实时聚合,减少下游的计算压力。
可参见Oceanus,基于Flink,可支持传统关系型数据库racle、缓存Redis、或者Hadoop生态HBASE、hdfs、消息队列Kafka以及clickhouse、ES、hippo、HTTP等等进行建source与sink表。
需要说明的是,source表、sink表并不代表在oceanus中真的创建了类似数据库的真实物理表,实际上source表、sink表均是逻辑表,它只是通过业务填写的配置项映射到真实的数据源、目的地。
根据美团Flink与Storm对比数据(spark streaming为秒级 storm与flink为毫秒级)
Flink可以通过创建view即临时表,实现对多个业务表进行聚合,且结果不会存储,并可以按需聚合。业务可以按需写SQL进行查询view,且不需要写spark程序,不需要每次使用spark在hive建立宽表再进行查询,流程会简单许多。
若有复杂运算支持UDF。
部分事务可以使用Flink的时间窗口解决,如统计订单数时有取消订单可以使用时间窗口或者。传统数据库的ACID目前不支持。
flink提供了两种构建模块来实现事务性sink连接器:write-ahead-log(WAL,预写式日志)sink和两阶段提交sink。WAL式sink将会把所有计算结果写入到应用程序的状态中,等接到检查点完成的通知,才会将计算结果发送到sink系统。因为sink操作会把数据都缓存在状态后段,所以WAL可以使用在任何外部sink系统上。尽管如此,WAL还是无法提供刀枪不入的恰好处理一次语义的保证,再加上由于要缓存数据带来的状态后段的状态大小的问题,WAL模型并不十分完美。与之形成对比的,2PC sink需要sink系统提供事务的支持或者可以模拟出事务特性的模块。对于每一个检查点,sink开始一个事务,然后将所有的接收到的数据都添加到事务中,并将这些数据写入到sink系统,但并没有提交(commit)它们。当事务接收到检查点完成的通知时,事务将被commit,数据将被真正的写入sink系统。这项机制主要依赖于一次sink可以在检查点完成之前开始事务,并在应用程序从一次故障中恢复以后再commit的能力。2PC协议依赖于Flink的检查点机制。检查点屏障是开始一个新的事务的通知,所有操作符自己的检查点成功的通知是它们可以commit的投票,而作业管理器通知一个检查点成功的消息是commit事务的指令。于WAL sink形成对比的是,2PC sinks依赖于sink系统和sink本身的实现可以实现恰好处理一次语义。更多的,2PC sink不断的将数据写入到sink系统中,而WAL写模型就会有之前所述的问题。
各个实时计算引擎对比表如下
项目/引擎 | Storm | Flink | spark-treaming |
---|---|---|---|
API | 灵活的底层 API 和具有事务保证的 Trident API | 流 API 和更加适合数据开发的 Table API 和 Flink SQL 支持 | 流 API 和 Structured-Streaming API 同时也可以使用更适合数据开发的 Spark SQL |
容错机制 | ACK 机制 | State 分布式快照保存点 | RDD 保存点 |
状态管理 | Trident State状态管理 | Key State 和 Operator State两种 State 可以使用,支持多种持久化方案 | 有 UpdateStateByKey 等 API 进行带状态的变更,支持多种持久化方案 |
处理模式 | 单条流式处理 | 单条流式处理 | Mic batch处理 |
延迟 | 毫秒级 | 毫秒级 | 秒级 |
语义保障 | At Least Once,Exactly Once | Exactly Once,At Least Once | At Least Once |
相比于Storm和其他一些流计算框架,Flink具有以下几点优势:
总结:Flink 和 Spark Streaming 的 API 、容错机制与状态持久化机制都可以解决一部分使用 Storm 中遇到的问题。但 Flink 在数据延迟上和 Storm 更接近,所以业界偏向使用Flink作实时计算与聚合。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。