目前,大多数企业采用Apache Flink与Kafka相结合的方式进行实时数据处理,即kafka从其他端获取数据后,⽴刻到Flink进行计算,Flink计算完后结果导入到数据库,整个过程是数据流式处理。然而,由于Kafka不在磁盘中持久保存数据,在极端情况下,数据可能会丢失。
成都创新互联是一家集网站建设,即墨企业网站建设,即墨品牌网站建设,网站定制,即墨网站建设报价,网络营销,网络优化,即墨网站推广为一体的创新建站企业,帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿,时刻以成就客户成长自我,坚持不断学习、思考、沉淀、净化自己,让我们为更多的企业打造出实用型网站。
综合研究了市场上主流的数据库和存储系统以后,笔者发现了一个更有效、更准确的实时数据仓库解决方案,即通过Pravega+TiDB这种架构组合,来构建实时数据仓库。
在这篇文章中,我们将重点介绍Pravega分布式流存储系统、TiDB分布式SQL数据库能给用户带来哪些价值,以及这种组合如何解决Kafka数据持久性挑战。同时,Pravega+TiDB在自动扩展、实时数据仓库的高并发性、可用性和安全性等方面有哪些表现。
Pravega 是Dell Emc开源分布式流存储系统,也是全球顶级开源基金会CNCF(云原生计算基金会)的沙盒项目。与Kafka和Apache Pulsar相似,Pravega重点解决了流批统一问题。
除此之外,Pravega功能更丰富:
▲Pravega架构
在分布式系统中,客户端应用程序和消息系统之间的异步传递信息,一般基于消息队列来实现。提到消息队列,大家首先会想到Kafka。Kafka是一个基于Zookeeper的分布式日志系统。它支持多分区、多副本和多订阅者。
可以说,Pravega重构了流式存储架构,主要为解决Kafka无法解决的问题而建立。作为一个实时流式存储解决方案,Pravega支持长期数据保留。Pravega在Hadoop分布式文件系统(HDFS)或S3上写入数据,从而消除了对数据持久性的担忧。此外,Pravega在整个系统中只存储一个数据副本,从架构设计上解决了Kafka无法解决的问题。
你可能会问,"既然已经有了Kafka,为什么还要重新发明轮子?" 答案是,使用Kafka存在一个重要挑战,那就是数据丢失、数据保留和再平衡问题。Kafka吃的数据比它吐出的多,存在着数据丢失的风险。
Kafka没有提供一个简单有效的解决方案来将数据持久化到HDFS或S3,所以数据保留成为一个问题。虽然Confluent提供了相关解决方案,但你必须使用两套存储接口来访问不同层的数据。
消费者再平衡也是有害的。因为新的消费者被添加到队列中,队列可能在重新平衡期间停止消费消息。因为提交间隔时间长,消费者可能会重复处理数据。无论哪种方式,重新平衡都可能导致消息积压,从而增加延迟。
与Kafka相比,Pravega提供了更多的功能。
▲Pravega VS Kafka
Pravega的特别之处在于,使用Apache BookKeeper来处理低延迟、高并发和数据的实时写入等问题。然而,BookKeeper只作为一个缓存层,用于批量写入。所有对Pravega的读取请求都是直接向HDFS或S3发出,以利用其高吞吐量能力。
换句话说,Pravega不使用BookKeeper作为数据缓冲层,而是提供一个基于HDFS或S3的存储层。这个存储层既支持低延迟的尾部读写,也支持高吞吐量的追赶式读取的抽象。当数据在BookKeeper和HDFS或S3之间移动时,使用BookKeeper作为独立层的系统可能表现不佳。相比之下,Pravega可以确保令人满意的性能。
通常,DBA有三个主要关注点:数据准确性、系统稳定性和系统可用性。
Pravega解决了DBA的这些担忧。它长期保留保证了数据的安全性,并且以精确的一次语义保证了数据的准确性,尤其是自动扩展性,使系统维护变得轻而易举。
问题是,实时数据仓库应该包含哪些关键组成部分?
一个实时数据仓库通常有四个组成部分:数据采集层、数据存储层、实时计算层和实时应用层。通过将多种技术整合到一个无缝的架构中,我们可以建立一个可扩展的大数据架构,可以支持数据分析和挖掘,在线交易,以及统一的批处理和流处理等等。
▲实时数据仓库的四个组成部分
数据存储层有多种选择,但不是所有的都适合实时数据仓库:
然而,TiDB解决了所有这些需求。
TiDB是一个开源的分布式SQL数据库,支持混合交易和分析处理(HTAP)工作负载。它与MySQL兼容,具有水平扩展性、强一致性和高可用性。
与其他开源数据库相比,TiDB这种HTAP架构更适合于建立实时数据仓库。TiDB拥有一个混合存储层,由TiKV(行存储引擎)和TiFlash(列存储引擎)组成。这两个存储引擎使用TiDB作为一个共享的SQL层。TiDB回答在线事务处理(OLTP)和在线分析处理(OLAP)查询,并根据执行计划的成本从任何一个引擎中获取数据。
▲TiDB HTAP架构
此外,TiDB 5.0引入了大规模并行处理(MPP)架构。在MPP模式下,TiFlash补充了TiDB的计算能力。在处理OLAP工作负载时,TiDB成为一个主节点。用户向TiDB服务器发送请求,所有的TiDB服务器执行表连接,并将结果提交给优化器进行决策。优化器评估所有可能的执行计划(基于行、基于列、索引、单服务器引擎和MPP引擎),并选择最佳计划。
▲TiDB的MPP模式
例如,一个订单处理系统在销售活动中可能会遇到一个突然的流量高峰。在这个高峰期,企业需要进行快速分析,以便及时对客户行为做出反应和回应。传统的数据仓库很难在短时间内应对泛滥的数据,而且可能需要很长的时间来进行后续的数据分析处理。
通过MPP计算引擎,TiDB可以预测即将到来的流量高峰,并动态地扩展集群,为活动提供更多的资源。并且,它可以轻松地在几秒钟内响应聚合和分析请求。
在Flink的帮助下,当TiDB遇到Pravega,构成了一个实时、高吞吐量、稳定的数据仓库,该数据仓库能够满足用户对大数据的各种要求,并能一站式地处理OLTP和OLAP工作负载。
当前标题:当Pravega遇到TiDB,如何构建出实时数据仓库?
链接URL:http://www.gawzjz.com/qtweb/news11/165761.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联