从Hadoop到ClickHouse,现代BI系统有哪些问题?如何解决?

  1. 云栖社区>
  2. 云栖号资讯>
  3. 博客>
  4. 正文

从Hadoop到ClickHouse,现代BI系统有哪些问题?如何解决?

云栖号资讯小哥 2020-06-24 15:30:33 浏览617
展开阅读全文

云栖号资讯:【点击查看更多行业资讯
在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来!

导读:一次机缘巧合,在研究BI产品技术选型的时候,我接触到了ClickHouse,瞬间就被其惊人的性能所折服。这款非Hadoop生态、简单、自成一体的技术组件引起了我极大的好奇。那么ClickHouse好在哪呢?本文带你做一个初步了解。

696BF022_30E1_49d6_BBE6_55120E41E714

01 传统BI系统之殇

得益于IT技术的迅猛发展,ERP、CRM这类IT系统在电力、金融等多个行业均得以实施。这些系统提供了协助企业完成日常流程办公的功能,其应用可以看作线下工作线上化的过程,这也是IT时代的主要特征之一,通常我们把这类系统称为联机事务处理(OLTP)系统。

企业在生产经营的过程中,并不是只关注诸如流程审批、数据录入和填报这类工作。站在监管和决策层面,还需要另一种分析类视角,例如分析报表、分析决策等。而IT系统在早期的建设过程中多呈烟囱式发展,数据散落在各个独立的系统之内,相互割裂、互不相通。

为了解决数据孤岛的问题,人们提出了数据仓库的概念。即通过引入一个专门用于分析类场景的数据库,将分散的数据统一汇聚到一处。借助数据仓库的概念,用户第一次拥有了站在企业全局鸟瞰一切数据的视角。

随着这个概念被进一步完善,一类统一面向数据仓库,专注于提供数据分析、决策类功能的系统与解决方案应运而生。最终于20世纪90年代,有人第一次提出了BI(商业智能)系统的概念。自此以后,人们通常用BI一词指代这类分析系统。相对于联机事务处理系统,我们把这类BI系统称为联机分析(OLAP)系统。

传统BI系统的设计初衷虽然很好,但实际的应用效果却不能完全令人满意。我想之所以会这样,至少有这么几个原因。

首先,传统BI系统对企业的信息化水平要求较高。按照传统BI系统的设计思路,通常只有中大型企业才有能力实施。因为它的定位是站在企业视角通盘分析并辅助决策的,所以如果企业的信息化水平不高,基础设施不完善,想要实施BI系统根本无从谈起。这已然把许多潜在用户挡在了门外。

其次,狭小的受众制约了传统BI系统发展的生命力。传统BI系统的主要受众是企业中的管理层或决策层。这类用户虽然通常具有较高的话语权和决策权,但用户基数相对较小。同时他们对系统的参与度和使用度不高,久而久之这类所谓的BI系统就沦为了领导视察、演示的“特供系统”了。

最后,冗长的研发过程滞后了需求的响应时效。传统BI系统需要大量IT人员的参与,用户的任何想法,哪怕小到只是想把一张用饼图展示的页面换成柱状图展示,可能都需要依靠IT人员来实现。一个分析需求从由用户大脑中产生到最终实现,可能需要几周甚至几个月的时间。这种严重的滞后性仿佛将人类带回到了飞鸽传书的古代。

92B0A048_D339_4e26_A6B7_7477D69D65C4

02 现代BI系统的新思潮

技术普惠是科技进步与社会发展的一个显著特征。从FM频段到GPS定位乃至因特网都遵循着如此的发展规律。有时我们很难想象,这些在现今社会习以为常的技术,其实在几十年前还仅限于服务军队这类少数群体。

每一次技术普惠的浪潮,一方面扩展了技术的受众,让更多的人享受到了技术进步带来的福利;另一方面,由于更多的人接触到了新的技术,反过来也提升了技术的实用性和完善程度,加速了技术的成长与发展。

如果说汽车、火车和飞机是从物理上拉近了人与人之间的距离,那么随着互联网的兴起与风靡,世界的距离从逻辑上再一次被拉近了。现今世界的社会结构与人类行为,也已然被互联网深度改造,我们的世界逐渐变得扁平化与碎片化,节奏也越来越快。

根据一项调查,互联网用户通常都没有耐心。例如47%的消费者希望在2秒或更短的时间内完成网页加载,40%的人放弃了加载时间超过3秒的网站,而页面响应时间每延迟1秒就可以使转换率降低7%。实时应答、简单易用,已经是现代互联网系统的必备素质。

SaaS模式的兴起,为传统企业软件系统的商业模式带来了新的思路,这是一次新的技术普惠。一方面,SaaS模式将之前只服务于中大型企业的软件系统放到了互联网,扩展了它的受众;另一方面,由于互联网用户的基本特征和软件诉求,又倒逼了这些软件系统在方方面面进行革新与升级。

技术普惠,导致现代BI系统在设计思路上发生了天翻地覆的变化。

首先,它变得“很轻”,不再需要强制捆绑于企业数据仓库这样的庞然大物之上,就算只根据简单的Excel文件也能进行数据分析。

其次,它的受众变得更加多元化,几乎人人都可以成为数据分析师。现代BI系统不需要IT人员的深度参与,用户直接通过自助的形式,通过简单拖拽、搜索就能得到自己想要的分析结果。

最后,由于经过互联网化的洗礼,即便现代BI系统仍然私有化地部署在企业内部,只服务于企业客户,但它也必须具有快速应答、简单易用的使用体验。从某种角度来看,经过SaaS化这波技术普惠的洗礼,互联网帮助传统企业系统在易用性和用户体验上进行了革命性提升。

如果说SaaS化这波技术普惠为现代BI系统带来了新的思路与契机,那么背后的技术创新则保障了其思想的落地。在传统BI系统的体系中,背后是传统的关系型数据库技术(OLTP数据库)。

为了能够解决海量数据下分析查询的性能问题,人们绞尽脑汁,在数据仓库的基础上衍生出众多概念,例如:对数据进行分层,通过层层递进形成数据集市,从而减少最终查询的数据体量;提出数据立方体的概念,通过对数据进行预先处理,以空间换时间,提升查询性能。

然而无论如何努力,设计的局限始终是无法突破的瓶颈。OLTP技术由诞生的那一刻起就注定不是为数据分析而生的,于是很多人将目光投向了新的方向。

Google于2003~2006年相继发表了三篇论文“Google File System”“Google MapReduce”和“Google Bigtable”,将大数据的处理技术带进了大众视野。三篇论文开启了大数据的技术普惠,Hadoop生态由此开始一发不可收拾,数据分析开启了新纪元。

7C65A37C_5F42_4a65_BD51_78C0CC507DF0

2006年开源项目Hadoop的出现,标志着大数据技术普及的开始,大数据技术真正开始走向普罗大众。长期以来受限于数据库处理能力而苦不堪言的各路豪杰们,仿佛发现了新大陆,于是一轮波澜壮阔的技术革新浪潮席卷而来。

从某种角度来看,以使用Hadoop生态为代表的这类非传统关系型数据库技术所实现的BI系统,可以称为现代BI系统。换装了大马力发动机的现代BI系统在面对海量数据分析的场景时,显得更加游刃有余。

然而Hadoop技术也不是银弹,在现代BI系统的构建中仍然面临诸多挑战。在海量数据下要实现多维分析的实时应答,仍旧困难重重。(现代BI系统的典型应用场景是多维分析,某些时候可以直接使用OLAP指代这类场景。)

Hadoop最初指代的是分布式文件系统HDFS和MapReduce计算框架,但是它一路高歌猛进,在此基础之上像搭积木一般快速发展成为一个庞大的生态(包括Yarn、Hive、HBase、Spark等数十种之多)。在大量数据分析场景的解决方案中,传统关系型数据库很快就被Hadoop生态所取代,我所处的BI领域就是其中之一。

传统关系型数据库所构建的数据仓库,被以Hive为代表的大数据技术所取代,数据查询分析的手段也层出不穷,Spark、Impala、Kylin等百花齐放。Hadoop发展至今,早已上升成为大数据的代名词,仿佛一提到海量数据分析场景下的技术选型,就非Hadoop生态莫属。

虽然Hadoop生态化的属性带来了诸多便利性,例如分布式文件系统HDFS可以直接作为其他组件的底层存储(例如HBase、Hive等),生态内部的组件之间不用重复造轮子,只需相互借力、组合就能形成新的方案。

但生态化的另一面则可以看作臃肿和复杂。Hadoop生态下的每种组件都自成一体、相互独立,这种强强组合的技术组件有些时候显得过于笨重了。与此同时,随着现代化终端系统对实效性的要求越来越高,Hadoop在海量数据和高时效性的双重压力下,也显得有些力不从心了。

3A639D20_1CB5_49b5_BBAD_9549C33FBFE5

03 一匹横空出世的黑马

我从2012年正式进入大数据领域,开始从事大数据平台相关的基础研发工作。2016年我所在的公司启动了战略性创新产品的规划工作,自此我开始将工作重心转到设计并研发一款具备现代化SaaS属性的BI分析类产品上。为了实现人人都是分析师的最终目标,这款BI产品必须至少具备如下特征。

一站式:下至数百条数据的个人Excel表格,上至数亿级别的企业数据,都能够在系统内部被直接处理。
自服务,简单易用:面向普通用户而非专业IT人员,通过简单拖拽或搜索维度,就能完成初步的分析查询。分析内容可以是自定义的,并不需要预先固定好。
实时应答:无论数据是什么体量级别,查询必须在毫秒至1秒内返回。数据分析是一个通过不断提出假设并验证假设的过程,只有做到快速应答,这种分析过程的路径才算正确。
专业化、智能化:需要具备专业化程度并具备智能化的提升空间,需要提供专业的数学方法。

为了满足上述产品特性,我们在进行底层数据库技术选型的时候可谓是绞尽脑汁。

以Spark为代表的新一代ROLAP方案虽然可以一站式处理海量数据,但无法真正做到实时应答和高并发,它更适合作为一个后端的查询系统。而新一代的MOLAP方案虽然解决了大部分查询性能的瓶颈问题,能够做到实时应答,但数据膨胀和预处理等问题依然没有被很好解决。

除了上述两类方案之外,也有一种另辟蹊径的选择,即摒弃ROLAP和MOALP转而使用搜索引擎来实现OLAP查询,ElasticSearch是这类方案的代表。ElasticSearch支持实时更新,在百万级别数据的场景下可以做到实时聚合查询,但是随着数据体量的继续增大,它的查询性能也将捉襟见肘。

难道真的是鱼与熊掌不可兼得了吗?直到有一天,在查阅一份Spark性能报告的时候,我不经意间看到了一篇性能对比的博文。

Spark的对手是一个我从来没有见过的陌生名字,在10亿条测试数据的体量下,Spark这个我心目中的绝对王者,居然被对手打得落花流水,查询响应时间竟然比对手慢数90%之多。而对手居然只使用了一台配有i5 CPU、16GB内存和SSD磁盘的普通PC电脑。

我揉了揉眼睛,定了定神,这不是做梦。ClickHouse就这样进入了我的视野。

8CA0B714_7179_4dce_8B2D_38E3F885FA77

  1. 天下武功唯快不破

我对ClickHouse的最初印象极为深刻,其具有ROLAP、在线实时查询、完整的DBMS、列式存储、不需要任何数据预处理、支持批量更新、拥有非常完善的SQL支持和函数、支持高可用、不依赖Hadoop复杂生态、开箱即用等许多特点。

特别是它那夸张的查询性能,我想大多数刚接触ClickHouse的人也一定会因为它的性能指标而动容。在一系列官方公布的基准测试对比中,ClickHouse都遥遥领先对手,这其中不乏一些我们耳熟能详的名字。

所有用于对比的数据库都使用了相同配置的服务器,在单个节点的情况下,对一张拥有133个字段的数据表分别在1000万、1亿和10亿三种数据体量下执行基准测试,基准测试的范围涵盖43项SQL查询。

在1亿数据集体量的情况下,ClickHouse的平均响应速度是Vertica的2.63倍、InfiniDB的17倍、MonetDB的27倍、Hive的126倍、MySQL的429倍以及Greenplum的10倍。

详细的测试结果可以查阅:
https://clickhouse.yandex/benchmark.html

  1. 社区活跃

ClickHouse是一款开源软件,遵循Apache License 2.0协议,所以它可以被免费使用。同时它的开源社区也非常跃度,其在全球范围内约有400位贡献者。

ClickHouse版本发布频率惊人,基本保持着每个月发布一次版本的更新频率。友好的开源协议、活跃的社区加上积极的响应,意味着我们可以及时获取最新特性并得到修复缺陷的补丁。

篇幅有限,如果你想了解ClickHouse的更多细节,可以看一看《QQ音乐大数据架构技术演进》这篇文章,并关注我们后续的推送文章,还有下面这本书。

关于作者:朱凯,ClickHouse贡献者之一,ClickHouse布道者,资深架构师,腾讯云最具价值专家TVP,开源爱好者,Apache DolphinScheduler Committer,《企业级大数据平台构建:架构与实现》作者,公众号“ClickHouse的秘密基地”运营者。十多年IT从业经验,对大数据领域主流技术与解决方案有深入研究,擅长分布式系统的架构设计与整合。

本文摘编自《ClickHouse原理解析与应用实践》,经出版方授权发布。

【云栖号在线课堂】每天都有产品技术专家分享!
课程地址:https://yqh.aliyun.com/zhibo

立即加入社群,与专家面对面,及时了解课程最新动态!
【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

原文发布时间:2020-06-23
本文作者:朱凯
本文来自:“大数据DT 微信公众号 ”,了解相关信息可以关注“[大数据D](https://mp.weixin.qq.com/s/YHP5Fhla2QplwrSBwokhNA

网友评论

登录后评论
0/500
评论
云栖号资讯小哥
+ 关注
所属团队号: 云栖号资讯