案例 | 个推如何采用Greenplum提高PB级别数据处理能力

最新推荐文章于 2024-05-23 15:42:48 发布

Greenplum中文社区

最新推荐文章于 2024-05-23 15:42:48 发布

阅读量290

点赞数

文章标签：数据库运维大数据分布式编程语言

本文链接：https://blog.csdn.net/gp_community/article/details/109720005

版权

前言：近年来，移动互联网、物联网、云计算的快速发展，催生了海量的数据。在大数据处理方面，不同技术栈所具备的性能也有所不同。如何快速有效地处理这些体量庞大的数据，令不少开发者为之苦恼。随着Greenplum的异军突起，以往大数据仓库所存在的很多问题都得到了有效解决，Greenplum也成为新一代数据库的典型代表。本文对个推在处理庞大的数据量时，如何选择有效的技术栈进行了深入研究，并结合自身业务场景，详细分析了Greenplum在个推中的实践。

Greenplum诞生背景

2002年，互联网数据量正处于快速增长期，一方面传统数据库难以满足当前的计算需求，另一方面传统数据库大多基于SMP架构，扩展性能差。因此面对日益增长的数据量，SMP架构难以继续支撑，开发者需要一种数据库，可以支持分布式并行数据计算能力，Greenplum便应运而生。

和传统数据库的SMP架构不同，Greenplum是一种完全无共享(Share Nothing)的结构，相比SMP，扩展能力明显提升。Greenplum系统主要基于MPP架构，由多个服务器通过节点互联网络连接而成，每个节点只需访问自己的本地资源(包括内存、存储等)。

图片来源：bubuko

解读Greenplum架构

Greenplum主要由Master主节点和Interconnect网络层以及负责数据存储和计算的多个节点共同组成。

Master上有主节点和从节点两部分，两者主要的功能是生成查询计划、派发、协调Segment并行计算，同时通过Master维护global system catalog。global system catalog这个全局目录存着一组Greenplum数据库系统本身所具有的元数据的系统表。Master通常不参与数据交互，Greenplum所有的并行任务都是在Segment的数据节点上完成的。因此，Master节点不会成为数据库的性能瓶颈。

中间的网络层Interconnect，主要负责并行查询计划Dispatch分发，同时通过libpq网络连接协调QE节点上执行器的并行执行。正是因为Interconnect的存在，Greenplum才能实现对同一个集群中多个PostgreSQL实例的高效协同和并行计算。

结构图下方是负责数据存储和计算的节点，每个节点上有多个实例。每个实例都是一个PostgreSQL数据库，同一机器上的实例共享节点的IO和CPU，而不同机器间相互独立。PostgreSQL在稳定性和数据处理性能方面较优，同时又有丰富的语法支持，满足了Greenplum的功能需要。

Greenplum的优势

Greenplum之所以能成为处理海量大数据的利器，与其所具备的几大优势密不可分。

优势一：支持数据快速加载和并行计算，大幅提升数据处理效率

图片来源：Greenplum社区

Greenplum的数据管道可以高效地将数据从磁盘传输到CPU，而目前市面上常用的计算引擎Spark在传输数据时，则需要为每个并发查询分配一个内存，这对大型数据集的查询十分不利。Greenplum能够并行加载数据，具备实时查询功能，可以对大数据集进行更高效的计算。

优势二：扩展性能增强

Greenplum基于 MPP架构，节点之间完全不共享，同时又可以并行查询，因此其在进行线性扩展时，数据规模可以达到PB级别。目前，Greenplum已经实现了开源，并且社区生态活跃，对于使用者而言，也是极为可靠的。

优势三：功能性优化

Greenplum支持复杂的SQL查询，大幅简化了数据的操作和交互过程，而目前流行的HAWQ、Spark SQL、Impala等技术基本都是基于MapReduce所进行的优化，虽然部分技术也使用了SQL查询，但是对SQL的支持比较有限。

我们针对目前市面上的几款主流工具，进行了多维度的对比，如下图所示：

方案	使用方式	优点	缺点
Greenplum	实时数据直接读取GPDB，历史数据每天聚合一份存入GPDB	1.原先是商业数据库，容灾性好，稳定。2.查询速度快	超大规模集群扩展性有待验证
phoenix	HBase存储原始数据，通过phoenix查询	主要依赖HBase，使用起来方便；同时支持SQL查询	二级索引会带来数据量的飞速增长，而且当业务维度非常多，如果使用二级索引数据量会很大；HBase会开启协处理器的模式，对运维会有影响
Impala+kudu	流式数据进来后先入到kudu中，实时数据通过Impala查询kudu。每天将kudu的数据转化成parquet格式存储在HDFS中，历史数据通过Impala查询parquet，在页面展示时将实时数据和历史数据union展示	计算和存储分离，存储能直接使用HDFS，查询速度较快	Impala查询对内存要求高，kudu容灾性不是很好；

Greenplum的容错机制

Greenplum数据库简称GPDB，它拥有丰富的特性，支持多级容错机制，具备高可用性能。

主节点高可用

为了避免主节点单点故障问题，Greenplum特别设置了主节点的副本（称为Standby Master），通过流复制技术实现两者同步复制。当主节点发生故障时，从节点可以成为主节点，完成用户请求并协调查询执行。

数据节点高可用

Greenplum每个数据节点都可以配备一个镜像，在6版本之前其通过文件块级别的同步来实现数据同步；在6版本时，Greenplum采用WAL日志复制的方式来实现数据同步（称为filerep技术）。故障检测进程（ftsprobe）会定期探测各个数据节点的心跳，当某个节点发生故障时，GPDB会自动进行故障切换。

网络高可用

为了避免网络的单点故障，每个主机会配置多个网口，并使用多个交换机，防止网络故障时，整个服务器都不可用。

同时，GPDB具有图形化的性能监控功能。基于此功能，用户可以确定数据库当前的运行情况和历史查询信息，同时跟踪系统使用情况和资源信息。

Greenplum在个推业务场景中的引用

在深入调研了Greenplum之后，我们将它纳入了个推的技术地图中，也在个推的业务线中进行了实践，比如在“个推应用统计”的业务中。

业务痛点

“个推应用统计”是一款移动APP数据统计分析平台，它能从用户属性、使用行为、行业对比等多指标多维度对APP进行全面统计分析，帮助APP运营者深层次挖掘用户需求，清晰地了解APP所处的行业地位，为产品运营和推广决策提供全方位数据支撑。

最开始，“个推应用统计”中的数据统计主要是用离线统计的方式，后来随着产品的逐渐迭代、优化，很多需求逐渐无法满足了，例如：

1)部分场景需要实时计算；

2)用户活跃统计中跨天去重的场景；

3)指标的统计维度过多，无法提前计算。

解决方案

针对这一系列问题，个推引入了Greenplum作为实时数据分析的工具。目前个推使用的是Greenplum 5.16的版本。

针对实时性的问题。

“个推应用统计”每天的事件日志量达几十亿条，在数据导入的时候，我们使用了gpkafka作为实时数据写入的方式。

数据导入的具体流程：

Flume采集日志数据后发送到Kafka集群；
Spark Streaming先消费Kafka集群中的数据，再进行实时数据清洗、处理；
Spark Streaming随后将处理后的数据写入到Kafka集群中；
gpkafka工具消费Kafka集群中的数据，把消费后的数据写入到Greenplum的Heap表中，进行实时的数据分析展示。

2. 针对跨天去重的问题

我们改造了Greenplum，在其基础上融入了Roaringbitmap。在数据处理阶段，定时任务将每天的用户信息构造成bitmap的格式，根据bitmap的“与、或”运算实现多天的用户计算查询。

3. 针对复杂维度统计的场景。

“个推应用统计”有一些场景，用户会定义复杂的查询条件，比如多维事件分析、漏斗查询等。“个推应用统计”查询功能模块，运用了pljava，类似于一个udf脚本，通过在SQL中使用pljava定义的function，实现了复杂统计的快速查询。

使用情况

目前个推业务线使用的Greenplum集群规模是10台，每天的数据量达几十亿。在近期，我们也经历了集群的扩容，通过Greenplum中的原生tools对节点进行扩充，对数据进行了自动重分布。Greenplum的一系列自动化工具也让运维人员的的扩容工作变得更加便捷。

效果

引入Greenplum，极大地增强了个推的数据处理能力，包括海量数据的实时入库、实时查询、标签运算等。当前，数据的高效使用对于企业的重要性不言而喻。构建OLAP分析系统，对于业务的指导、公司的决策，都有举足轻重的作用，而Greenplum正可以帮助企业快速构建分析引擎，实现全面的数据分析。

	数据查询	业务支持	稳定性
使用前	之前不支持数据实时入库查询，一般以t+1报表的形式	之前使用的HBase、Codis等对业务的支持能力有限	稳定性一般
使用后	基于海量数据的实时入库，以及实时统计，支持数据即时查询，	能够支持复杂的SQL查询，完成漏斗统计、多维事件分析等功能	有完整的运维系统支撑，能够对数据库做实时监控和告警