加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 大数据 > 正文

利用UDW构建企业级数据仓库和BI系统

发布时间:2020-12-14 01:25:35 所属栏目:大数据 来源:网络整理
导读:背景 随着大数据应用的发展与普及,越来越多的企业认识到企业运行中所产生数据本身也是一种高价值资产。并且,商业智能在企业的经营与决策中所扮演的角色,既可以是操作层中的数据指导,也可以是战术层与战略层上的决策顾问。 商业智能——即Business Intell

背景

随着大数据应用的发展与普及,越来越多的企业认识到企业运行中所产生数据本身也是一种高价值资产。并且,商业智能在企业的经营与决策中所扮演的角色,既可以是操作层中的数据指导,也可以是战术层与战略层上的决策顾问。

商业智能——即Business Intelligence,其所关注与解决的问题是如何将数据转化为知识,帮助企业将纷繁浩杂的数据整合加工,从而为决策/管理等提供精准的支持及预测发展趋势。BI系统从不同的应用中将数据汇聚到核心存储服务中,并对这些数据进行加工和多维度分析,最终将分析结论以报表或可视化的方式展现给决策者。

在大数据时代的BI系统中,数据的价值被更多的人们所发现,并且,伴随着数据源的日益丰富,数据的体量及增长速率也变得越来越大。所以,数据仓库不但在整个BI系统中起到了支柱的角色,更是企业和组织海量数据收集、存储、分析的核心。

BI的演进

BI系统也在IT技术发展的过程中经历了多次演变,其中最为重要的就是从传统商务智能(BI)到Just In Time BI(实时BI)的变更。

在传统商务智能场景下,BI系统侧重对历史中所产生的数据进行离线分析。而Just In Time BI场景,则是实时数据分析需求所产生的,要求分析能够在任意时点,立即给出分析结果。所以实时BI必须要基于动态数据仓库,并侧重业务数据流的实时整合,以便根据当下的数据,及时对运营决策进行优化与调整。


图1 传统BI VS 实时BI

传统数据仓库面临的挑战

在大数据和实时BI时代,数据源不断增多,数据访问和数据同步变得复杂,开始包括非结构化与半结构化数据;数据量增大、应用不断增加,运行沉重缓慢,不堪重负;数据处理延时长,无法看到实时运营情况;先前的逻辑数据模型不能支撑数据快速分析和价值发现。

下面我们先分析传统的数据仓库对大数据、实时BI中的不足。

基于Oracle、MySQL等关系型数据库

  • 加载速度非常慢、无法满足数据增长需求

  • 数据处理延时长,无法看到实时运营情况,在做复杂的点击查询时,要等上半天到一天,有时还出不来结果

  • 系统无法满足海量的历史数据分析

  • 之前的数据模型不能支持业务快速的发展需求

基于DB2/Sybase IQ/Oracle+小型机+阵列

  • 数据量越来越大,统计任务越来越难完成

  • 数据量增大、应用不断增多,系统运行越来越缓慢

  • 硬件扩容成本高

面对数据快速增长、BI的实时运营分析的挑战,这就要求底层支撑平台数据仓库可以实现动态数据仓库,具备强大的数据流动和交换能力、存储能力、线性扩展能力以及数据分析能力,从而支持数据的高效的数据采集和处理、多模式数据的准确实时共享以及面对需求变化的快速响应。

基于UDW数据仓库和BI解决方案

UDW采用无共享的MPP架构,是大规模并行处理数据仓库产品,提供Greenplum和Udpg两种可选的类型。Greenplum是EMC开源的数据仓库,Udpg是基于PostgreSQL开发的大规模并行、完全托管的PB级数据仓库服务。UDW可以为简单、高效,为互联网、物联网、金融、电信等行业BI系统提供有力的支持。


图2 基于UDW数据仓库和BI解决方案

上图是基于UDW的数据仓库和BI解决方案,通过ETL过程把不同来源的数据加载批量、实时准实时的加载到UDW,基于UDW的数据仓库、用户可以对历史的数据进行定时分析、展示,对当前的业务数据进行实时准实时分析、挖掘,加快需求响应速度,能够让企业快速的感知市场的变化,加快决策与实施。

下面我们分析一下UDW如何面对海量数据、实时BI需求的挑战。

支持海量数据存储和分析

UDW采用无共享的MPP架构,同时使用多台机器存储和计算,极大的提高了海量数据的存储能力和并行处理能力。面对数据的快速增长,通过增加节点就可以线性的提高系统的存储和计算能力。UDW支持百GB到上PB级别的数据存储和分析。

丰富的数据加载方式

当今时代,数据的来源越来越多,我们的数据有来自业务DB数据、系统日志、运维日志等内部数据,也有来自移动数据、社交媒体数据、爬虫数据等外部数据。为了支持不同来源数据的加载,UDW除了可以使用insert和copy的方式加载数据外,还提供了丰富的数据导入方式。我们可以通过mysql2udw把MySQL中的数据全量或增量导入到UDW;通过外部表并行的加载外部文本文件,极大的提高了数据加载速度;使用sqoop或者HDFS外部表把HDFS中的数据加载到UDW;创建UFile的外部表、把UFile中的数据导入到UDW。

动态的数据加载

传统的数据仓库都是先把数据加载好,再去支撑业务查询。大数据实时BI时代的数据仓库要求能够动态的加载数据,动态加载数据的要求是在加载数据的同时不荷不能影响用户使用数据仓库。UDW并行的处理能力、充分利用每个节点的存储和计算能力,大大提高了数据吞吐能力。

支持实时BI

UDW通过准实时、实时的数据加载,实现对数据仓库的实时更新,利用数据分布式分布、任务并行执行、节点线性扩展能力增加UDW的处理能力来轻松应对海量数据的查询和分析;利用列存储、分区、索引降低磁盘IO的方式减少查询和分析时处理的数据量来提高数据分析效率。UDW利用这些特性,可以轻松的实现动态的数据仓库,能够让企业敏锐感知市场的变化,加快决策支持的反应速度。

UCloud基于UDW的数据仓库

需求分析

目标

实现公司统一的数据服务平台

需求
  • 公司的经营数据分析:用户消费分析、用户购买产品分析、产品消费分析、行业消费分析、客户经理销售分析、不同地区消费分析等

  • 业务系统服务质量分析:用户请求失败的概率分析、失败的原因分析、服务异常查询

  • 公司资源分析:交换机、物理机、虚拟机、网络等资源的画像

  • 监控数据分析:检测异常、资源利用率、资源使用习惯

  • 产品运营分析:产品存量、增长率、数据量等

数据源
  • 业务数据库:计费系统、账户系统、销售系统、交易系统等业务数据库数据

  • CMDB系统:机房、机架、物理机、虚拟机、网络等资源信息,格式化的数据

  • 日志系统:API日志、ngnix日志,日志总量20T,每天新增50G

    API日志格式如下:


    ngnix日志格式如下:



  • 监控数据:各个产品的监控指标数据,监控数据总量10T,每天新增数据30G,格式化数据。

  • 产品运营数据:UHost、UDB等各个产品数据,各个产品的数据不统一,有格式化数据,有JSON格式的数据。

问题分析

数据源来源多

数据有来自业务数据库,有来自CMDB数据,有监控数据,还有日志系统里面的数据。

数据格式多样化

除了结构化数据,还是半结构化数据,还有json格式的数据

即时查询多

70%以上为临时性的统计分析,很多需求无法提前预知。

产品运营数据平台不统一

各个产品各自管理自己的运营数据、解决方案各自不同(Hive、MySQL、Mongodb、Elasticsearch等),管理复杂。

基于UDW的方案

如下图所示,是基于UDW数据仓库的一个解决方案架构图。


图3 基于UDW数据仓库解决方案架构

多数据源的数据导入

通过mysql2udw工具,定时增量的把业务数据导入到UDW;通过rsyslog把日志系统、监控系统的数据实时同步到Kafka,每隔一分钟把Kafka中最新的数据进行加工处理,然后导入到UDW中;CMDB里面的数据定期dump成CSV文件然后导入UDW;各个业务产生的运营数据通过UDW接口实时的写入UDW。

JSON格式数据

UDW已经支持JSON数据类型,可以在创建的表格的时使用JSON格式类型,很方便的处理JSON类型数据,如下所示。?


通过下面对JSON数据查询可以很方便的查看一个请求返回是否正常。



当不同的类型的数据通过定期或者实时的导入到UDW之后,可以很方便的满足上述数据分析需求,为公司统一的数据平台做有力的支撑。

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读