目前大部分企业采用ApacheFlink和Kafka的结合方式进行实时数据处理，即Kafka从其他端获取数据后，立即在Flink中进行计算，将Flink的结果导入到数据库中经过计算。整个过程就是Datastreaming。但是，由于Kafka不会将数据持久化到磁盘，在极端情况下，数据可能会丢失。笔者在综合研究了市场上主流的数据库和存储系统后，找到了一种更有效、更准确的实时数仓方案，即通过Pravega+TiDB架构组合构建实时数仓。在本文中，我们将重点介绍Pravega分布式流存储系统和TiDB分布式SQL数据库可以为用户带来的价值，以及这种组合如何解决Kafka数据持久化挑战。同时，Pravega+TiDB在实时数仓的自动扩容、高并发、可用性和安全性方面表现如何。Pravega——重构流式存储架构Pravega是DellEmc的开源分布式流式存储系统，也是全球顶级开源基金会CNCF（CloudNativeComputingFoundation）的沙盒项目。与Kafka和ApachePulsar类似，Pravega专注于解决批量统一的问题。此外，Pravega还有更丰富的功能：更多的自动扩容能力。Pravega是一个完整的存储接口，提供与流的抽象接口，支持对上层计算引擎的统一访问。▲Pravega架构在分布式系统中，客户端应用与消息系统之间的信息异步传输一般是基于消息队列来实现的。说到消息队列，大家首先想到的是Kafka。Kafka是一个基于Zookeeper的分布式日志系统。它支持多分区、多副本和多订阅者。可以说，Pravega重构了流式存储架构，主要是为了解决Kafka无法解决的问题。作为一种实时流式存储解决方案，Pravega支持长期数据保留。Pravega将数据写在Hadoop分布式文件系统(HDFS)或S3上，消除了对数据持久化的担忧。另外，Pravega在整个系统中只存储一份数据，从架构设计上解决了Kafka无法解决的问题。为什么Pravega比Kafka好？您可能会问，“既然已经有了Kafka，为什么还要重新发明轮子？”答案是使用Kafka有一个重要的挑战，那就是数据丢失、数据保留和重新平衡问题。Kafka吃的数据多于吐出的数据，存在数据丢失的风险。当你设置acks=all时，只有当所有消费者都确认消息被保存时才会返回ACK，不会丢失数据。当acks=1时，如果leaderconsumer保存了消息，就会返回ACK。如果leader在备份数据之前就关机了，数据就会丢失。当acks=0时，Kafka不等待消费者确认。当消费者关闭时，数据丢失。Kafka没有提供简单有效的方案来持久化数据到HDFS或S3，因此数据保留成为一个问题。虽然Confluent提供了相关的解决方案，但是你必须使用两套存储接口来访问不同层的数据。使用ApacheFlume通过Kafka->Flume->HDFS访问数据。使用kafka-hadoop-loader通过Kafka->kafka-hadoop-loader->HDFS访问数据。使用KafkaConnectHDFS通过Kafka->KafkaConnectHDFS->HDFS访问数据。消费者再平衡也是有害的。随着新消费者被添加到队列中，队列可能会在重新平衡期间停止消费消息。由于提交之间的间隔很长，消费者可能会重复处理数据。无论哪种方式，重新平衡都会导致消息积压，增加延迟。与Kafka相比，Pravega提供了更多的功能。▲PravegaVSKafkaPravega的特别之处在于它使用ApacheBookKeeper来处理低延迟、高并发、实时数据写入等问题。但是，BookKeeper只是作为批量写入的缓存层。所有对Pravega的读取请求都直接向HDFS或S3发出，以利用其高吞吐量功能。也就是说，Pravega没有使用BookKeeper作为数据缓冲层，而是提供了一个基于HDFS或者S3的存储层。该存储层支持低延迟尾部读写和高吞吐量追赶读取。当数据在BookKeeper和HDFS或S3之间移动时，使用BookKeeper作为单独层的系统可能无法正常运行。相比之下，Pravega确保了令人满意的性能。Pravega的优势和价值通常，DBA主要关注三个方面：数据准确性、系统稳定性和系统可用性。数据准确性非常重要。任何数据丢失、损坏或重复都将是一场灾难。系统的稳定性和可用性使DBA从繁琐的维护过程中解脱出来，使他们能够将时间投入到改进系统应用程序中。Pravega解决了DBA的这些担忧。其长期保留保证了数据的安全性，以精确的一次性语义保证了数据的准确性，尤其是自动扩展性，使得系统维护变得容易。什么样的架构才是实时数仓？问题是，实时数据仓库的关键组件是什么？一个实时数据仓库通常有四个组成部分：数据采集层、数据存储层、实时计算层和实时应用层。通过将多种技术集成到一个无缝的架构中，我们可以构建一个可扩展的大数据架构，可以支持数据分析和挖掘、在线交易、统一的批流处理等。▲实时数仓的四个组成部分有很多数据存储层的选择，但并非都适合实时数据仓库：Hadoop或传统的OLAP数据库无法提供令人满意的实时处理。像HBase这样的NoSQL解决方案可以实时扩展和处理数据，但不能提供分析。独立的关系数据库无法扩展以容纳大量数据。然而，TiDB满足了所有这些需求。为什么选择TiDB？TiDB是一个开源分布式SQL数据库，支持混合事务和分析处理(HTAP)工作负载。兼容MySQL，具有水平扩展性、强一致性和高可用性。与其他开源数据库相比，TiDB的HTAP架构更适合构建实时数仓。TiDB有一个混合存储层，由TiKV（行存储引擎）和TiFlash（列存储引擎）组成。这两个存储引擎使用TiDB作为共享SQL层。TiDB响应联机事务处理(OLTP)和联机分析处理(OLAP)查询，并根据执行计划的成本从任一引擎获取数据。▲TiDBHTAP架构此外，TiDB5.0引入了大规模并行处理（MPP）架构。在MPP模式下，TiFlash与TiDB的计算能力互补。在处理OLAP工作负载时，TiDB成为主节点。用户向TiDB服务器发送请求，所有TiDB服务器执行表连接并将结果提交给优化器进行决策。优化器评估所有可能的执行计划（基于行、基于列、索引、单服务器引擎和MPP引擎）并选择最佳计划。▲TiDB的MPP模型例如，订单处理系统在销售活动中可能会遇到突然的流量高峰。在这个高峰期，商家需要进行快速分析，以便及时对客户行为做出反应和响应。传统的数据仓库很难在短时间内处理海量的数据，后续的数据分析和处理可能需要很长时间。通过MPP计算引擎，TiDB可以预测即将到来的流量高峰，动态扩展集群，为活动提供更多的资源。而且，它可以在几秒钟内轻松响应聚合和分析请求。当TiDB遇上Pravega，借助Flink，当TiDB遇上Pravega，一个实时、高吞吐、稳定的数据仓库就形成了。这个数据仓库可以满足用户对大数据的各种需求，可以提供一站式高效处理OLTP和OLAP工作负载。
