最具影响力的数字化技术在线社区

168大数据

 找回密码
 立即注册

QQ登录

只需一步,快速开始

1 2 3 4 5
打印 上一主题 下一主题
开启左侧

漫谈数仓第四篇NO.4 『数据应用』(BI&OLAP)

[复制链接]
跳转到指定楼层
楼主
发表于 2020-2-29 15:24:33 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
今天是我们漫谈数仓系列第四篇NO.4 『数据应用』。
数据应用,是真正体现数仓价值的部分,包括且又不局限于 数据可视化、BI、OLAP、即席查询,实时大屏,用户画像,推荐系统,数据分析,数据挖掘,人脸识别,风控反欺诈等等。

数据仓库架构图
本文侧重于数据应用之BI可视化和OLAP。
一、BI可视化工具
1.1 BI现状
大数据时代商业智能(BI)和数据可视化诉求更为强烈,淘宝大屏更是风靡全球!数据可视化是大数据『最后一公里』。
BI唤醒沉睡的数据。
传统型BI力求大而全的统一综合型报表和分析平台,侧重传统式报表开发,俨然一把屠龙刀。现互联网公司快速迭代的业务发展,需要的却是倚天剑,促使自助式BI和敏捷BI得以迅速发展。

时代召唤,传统BI巨头也逐渐向自助式BI和云BI转型。一时间,BI数据可视化已呈现出"百家争鸣,群雄争霸"的态势!
1.2 BI分类
统看业界可视化BI工具可大致分为:开源bi,商业bi,和传统重bi工具。
业界目前比较流行的开源bi工具有Superset、metabase、Redash、Cboard、Spagobi等,商业bi工具有帆软、tableau、PowerBI、SmartBI、QlinkView、QuickBI等,传统企业、传统数仓,大多依然沿用重bi产品,如Congos、BIEE、BO、MicroStrategydeng等。

详细每一款bi工具,我们前面文章有详细介绍。如果你感兴趣,或正在调研开BI工具选型,可移步:大数据可视化BI工具,呕血总结,通幽洞微(点击链接即可跳转)
二、OLAP基本操作和类型
OLAP,On-Line Analytical Processing,在线分析处理,主要用于支持企业决策管理分析。区别于OLTP,On-Line Transaction Processing,联机事务处理。
OLAP的优势:丰富的数据展现方式、高效的数据查询以及多视角多层次的数据分析。

数据仓库与OLAP的关系是互补的,现代OLAP系统一般以数据仓库作为基础,即从数据仓库中抽取详细数据的一个子集并经过必要的聚集存储到OLAP存储器中供前端分析工具读取。
2.1 OLAP基本操作
OLAP的多维分析操作包括:钻取(Drill-down)、上卷(Roll-up)、切片(Slice)、切块(Dice)以及旋转(Pivot)。

钻取:维的层次变化,从粗粒度到细粒度,汇总数据下钻到明细数据。如通过季度销售数据钻取每个月的销售数据
上卷:钻取的逆,向上钻取。从细粒度到粗粒度,细粒度数据到不同维层级的汇总。eg. 通过每个月的销售数据汇总季度、年销售数据
切片:特定维数据(剩余维两个)。eg.  只选电子产品销售数据
切块:维区间数据(剩余维三个)。eg. 第一季度到第二季度销售数据
旋转:维位置互换(数据行列互换),通过旋转可以得到不同视角的数据。
2.2 OLAP分类
OLAP按存储器的数据存储格式分为ROLAP(Relational OLAP)、MOLAP(Multi-dimensional OLAP)和 HOLAP(Hybrid OLAP)。

  • MOLAP,基于多维数组的存储模型,也是OLAP最初的形态,特点是对数据进行预计算,以空间换效率,明细和聚合数据都保存在cube中。但生成cube需要大量时间和空间。
  • ROLAP,完全基于关系模型进行存储数据,不需要预计算,按需即时查询。明细和汇总数据都保存在关系型数据库事实表中。
  • HOLAP,混合模型,细节数据以ROLAP存放,聚合数据以MOLAP存放。这种方式相对灵活,且更加高效。可按企业业务场景和数据粒度进行取舍,没有最好,只有最适合。
三、OLAP数据库选型
在大数据数仓架构中,离线以Hive为主,实时计算一般是Spark+Flink配合,消息队列Kafka一家独大,后起之秀Pulsar想要做出超越难度很大,Hbase、Redis和MySQL都在特定场景下有一席之地。
唯独在OLAP领域,百家争鸣,各有所长。
OLAP引擎/工具/数据库,技术选型可有很多选择,传统公司大多以Congos、Oracle、MicroStrategy等OLAP产品,互联网公司则普遍强势拥抱开源,如
Presto,Druid ,Impala,SparkSQL,AnalyticDB,(Hbase)Phoenix,kudu, Kylin,Greenplum,Clickhouse, Hawq,  Drill,ES等
在数据架构时,可以说目前没有一个引擎能在数据量,灵活程度和性能上(吞吐和并发)做到完美,用户需要根据自己的业务场景进行选型。
开源技术选型,MOLAP可选Kylin、Druid,ROLAP可选Presto、impala等
Presto
Presto 是由 Facebook 开源的大数据分布式 SQL 查询引擎,基于内存的低延迟高并发并行计算(mpp),适用于交互式分析查询。
首先我们先来看一下Presto官方的介绍:

  • ☆ 本身并不存储数据,但是可以接入多种数据源,包括Hive、RDBMS(Mysql、Oracle、Tidb等)、Kafka、MongoDB、Redis等
  • ☆ 完全支持ANSI SQL标准,用户可以直接使用 ANSI SQL 进行数据查询和计算
  • ☆ 可以混合多个catalog进行join查询和计算,支持跨数据源的级联查询
  • ☆ 基于PipeLine进行设计的,流水管道式数据处理,支持数据规模GB~PB,计算中拿出一部分放在内存、计算、抛出、再拿。
  • ☆ SQL on hadoop:弥补Hive的效率性能和灵活性的不足,Presto和Spark SQL、Impala有很多异曲同工之处。
presto架构(master+slaver模式):

Presto应用场景:

Druid
Druid是一个用于大数据实时查询和分析的高容错、高性能开源分布式系统,用于解决如何在大规模数据集下进行快速的、交互式的查询和分析。
数据可以实时摄入,进入到Druid后立即可查,同时数据是几乎是不可变。通常是基于时序的事实事件,事实发生后进入Druid,外部系统就可以对该事实进行查询。
Druid架构

基本特点
Apache Druid 具有以下特点:
  • 亚秒级 OLAP 查询,包括多维过滤、Ad-hoc 的属性分组、快速聚合数据等等。
  • 实时的数据消费,真正做到数据摄入实时、查询结果实时。
  • 高效的多租户能力,最高可以做到几千用户同时在线查询。
  • 扩展性强,支持 PB 级数据、千亿级事件快速处理,支持每秒数千查询并发。
  • 极高的高可用保障,支持滚动升级。
应用场景
实时数据分析是 Apache Druid 最典型的使用场景。该场景涵盖的面很广,例如:
  • 实时指标监控
  • 推荐模型
  • 广告平台
  • 搜索模型
Druid也有很多不足需要注意,由于druid属于时间存储,删除操作比较繁琐,且不支持查询条件删除数据,只能根据时间范围删除数据。Druid能接受的数据的格式相对简单,比如不能处理嵌套结构的数据。
Druid案例
知乎:技术选型上,知乎根据不同业务场景选择了HBase 和 Redis 作为实时指标的存储引擎,在OLAP选型上,知乎选择了Druid。

OPPO:而OPPO根据自身不同的业务场景,报表层选择了Druid,标签选择了ES,接口层选择了Hbase。

Kylin
Apache Kylin™是一个开源的分布式分析引擎,提供Hadoop/Spark之上的SQL查询接口及多维分析(OLAP)能力以支持超大规模数据,最初由eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表。

kylin特性:
  • 可扩展超快olap引擎,Hadoop/Spark上百亿数据规模
  • 提供 Hadoop ANSI SQL 接口
  • 交互式查询能力,用户可以与Hadoop数据进行亚秒级交互
  • 百亿以上数据集构建多维立方体(MOLAP CUBE)
  • 与BI工具无缝整合,如Tableau,PowerBI/Excel,MSTR,QlikSense,Hue和SuperSet
kylin生态圈:

Clickhouse
Clickhouse是一个用于在线分析处理(OLAP)的列式数据库管理系统(DBMS)。
是由俄罗斯的Yandex公司为了Yandex Metrica网络分析服务而开发。它支持分析实时更新的数据,Clickhouse以高性能著称。
先看一下官方定义:

ClickHouse is a column-oriented database management system (DBMS) for online analytical processing of queries (OLAP).
场景特征:
  • 大多数是读请求
  • 数据总是以相当大的批(> 1000 rows)进行写入
  • 不修改已添加的数据
  • 每次查询都从数据库中读取大量的行,但是同时又仅需要少量的列
  • 宽表,即每个表包含着大量的列
  • 较少的查询(通常每台服务器每秒数百个查询或更少)
  • 对于简单查询,允许延迟大约50毫秒
  • 列中的数据相对较小:数字和短字符串(例如,每个URL 60个字节)
  • 处理单个查询时需要高吞吐量(每个服务器每秒高达数十亿行)
  • 事务不是必须的
  • 对数据一致性要求低
  • 每一个查询除了一个大表外都很小
  • 查询结果明显小于源数据,换句话说,数据被过滤或聚合后能够被盛放在单台服务器的内存中
clickhouse自身限制:
  • 不支持真正的删除/更新支持 不支持事务
  • 不支持二级索引
  • 有限的SQL支持,join实现与众不同
  • 不支持窗口功能
  • 元数据管理需要人工干预维护
ClickHouse开源的出现让许多想做大数据并且想做大数据分析的很多公司和企业耳目一新。ClickHouse 正是以不依赖Hadoop 生态、安装和维护简单、查询速度快、可以支持SQL等特点在大数据分析领域披荆斩棘越走越远。
ADB(AnalyticDB for MySQL)
分析型数据库MySQL版(AnalyticDB for MySQL),是阿里巴巴自主研发的海量数据实时高并发在线分析(Realtime OLAP)云计算服务,使得您可以在毫秒级针对千亿级数据进行即时的多维分析透视和业务探索。
adb优势和特性
  • 超大规模:极致弹性轻松扩展至PB级规模
  • 简单易用:全面兼容MySQL协议和BI工具
  • 实时化分析:通过实时同步,报表延时1分钟内
  • 查询速度快:传统关系型数据库的5-10倍性能
基于adb实时数仓架构

通过数据传输服务DTS(Data Transmission Service),您可以将RDS for MySQL同步到AnalyticDB for MySQL,帮助您快速构建企业内部BI、交互查询、实时报表等系统。
adb数据化链路架构

四、数据挖掘
分类、聚类、预测、关联
本文不多做介绍,对于这一块,后面会专门写一篇文章介绍。
五、本文结束语
☆☞ 对于数据架构,不管是数据仓库、数据湖,还是数据中台,数据应用才是数据价值体现所在
☆☞ 对于可视化BI工具,通幽洞微,建议熟练掌握2-3款即可,理解工具思想和实现方式
☆☞ 对于OLAP数据库,没有一个引擎能同时在数据量、性能、和灵活性三个方面做到完美,每个系统在设计时都需要在这三者间做出取舍。
参考资料:
https://help.aliyun.com/document_detail/72987.html
http://kylin.apache.org/cn/
https://clickhouse.yandex/
https://clickhouse.yandex/docs/zh/
[外]-分析型数据库AnalyticDB产品白皮书

本文分享自微信公众号 - 飞总聊IT(feiitworld)



楼主热帖
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 转播转播 分享分享 分享淘帖 赞 踩

168大数据 - 论坛版权1.本主题所有言论和图片纯属网友个人见解,与本站立场无关
2.本站所有主题由网友自行投稿发布。若为首发或独家,该帖子作者与168大数据享有帖子相关版权。
3.其他单位或个人使用、转载或引用本文时必须同时征得该帖子作者和168大数据的同意,并添加本文出处。
4.本站所收集的部分公开资料来源于网络,转载目的在于传递价值及用于交流学习,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。
5.任何通过此网页连接而得到的资讯、产品及服务,本站概不负责,亦不负任何法律责任。
6.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源,若标注有误或遗漏而侵犯到任何版权问题,请尽快告知,本站将及时删除。
7.168大数据管理员和版主有权不事先通知发贴者而删除本文。

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

关于我们|小黑屋|Archiver|168大数据 ( 京ICP备14035423号|申请友情链接

GMT+8, 2024-6-5 09:59

Powered by BI168大数据社区

© 2012-2014 168大数据

快速回复 返回顶部 返回列表