从Hadoop到ClickHouse，现代BI系统有哪些问题？如何解决？
导读：一次机缘巧合 ， 在研究BI产品技术选型的时候 ， 我接触到了ClickHouse ， 瞬间就被其惊人的性能所折服 。 这款非Hadoop生态、简单、自成一体的技术组件引起了我极大的好奇 。 那么ClickHouse好在哪呢？本文带你做一个初步了解 。
作者：朱凯
来源：华章科技
文章图片
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人员来实现 。 一个分析需求从由用户大脑中产生到最终实现 ， 可能需要几周甚至几个月的时间 。 这种严重的滞后性仿佛将人类带回到了飞鸽传书的古代 。
文章图片
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年相继发表了三篇论文“GoogleFileSystem”“GoogleMapReduce”和“GoogleBigtable” ， 将大数据的处理技术带进了大众视野 。 三篇论文开启了大数据的技术普惠 ， Hadoop生态由此开始一发不可收拾 ， 数据分析开启了新纪元 。
文章图片
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在海量数据和高时效性的双重压力下 ， 也显得有些力不从心了 。
文章图片
03一匹横空出世的黑马
我从2012年正式进入大数据领域 ， 开始从事大数据平台相关的基础研发工作 。 2016年我所在的公司启动了战略性创新产品的规划工作 ， 自此我开始将工作重心转到设计并研发一款具备现代化SaaS属性的BI分析类产品上 。 为了实现人人都是分析师的最终目标 ， 这款BI产品必须至少具备如下特征 。
一站式：下至数百条数据的个人Excel表格 ， 上至数亿级别的企业数据 ， 都能够在系统内部被直接处理 。 自服务 ， 简单易用：面向普通用户而非专业IT人员 ， 通过简单拖拽或搜索维度 ， 就能完成初步的分析查询 。 分析内容可以是自定义的 ， 并不需要预先固定好 。 实时应答：无论数据是什么体量级别 ， 查询必须在毫秒至1秒内返回 。 数据分析是一个通过不断提出假设并验证假设的过程 ， 只有做到快速应答 ， 这种分析过程的路径才算正确 。 专业化、智能化：需要具备专业化程度并具备智能化的提升空间 ， 需要提供专业的数学方法 。为了满足上述产品特性 ， 我们在进行底层数据库技术选型的时候可谓是绞尽脑汁 。
以Spark为代表的新一代ROLAP方案虽然可以一站式处理海量数据 ， 但无法真正做到实时应答和高并发 ， 它更适合作为一个后端的查询系统 。 而新一代的MOLAP方案虽然解决了大部分查询性能的瓶颈问题 ， 能够做到实时应答 ， 但数据膨胀和预处理等问题依然没有被很好解决 。
除了上述两类方案之外 ， 也有一种另辟蹊径的选择 ， 即摒弃ROLAP和MOALP转而使用搜索引擎来实现OLAP查询 ， ElasticSearch是这类方案的代表 。 ElasticSearch支持实时更新 ， 在百万级别数据的场景下可以做到实时聚合查询 ， 但是随着数据体量的继续增大 ， 它的查询性能也将捉襟见肘 。
难道真的是鱼与熊掌不可兼得了吗？直到有一天 ， 在查阅一份Spark性能报告的时候 ， 我不经意间看到了一篇性能对比的博文 。
Spark的对手是一个我从来没有见过的陌生名字 ， 在10亿条测试数据的体量下 ， Spark这个我心目中的绝对王者 ， 居然被对手打得落花流水 ， 查询响应时间竟然比对手慢数90%之多 。 而对手居然只使用了一台配有i5CPU、16GB内存和SSD磁盘的普通PC电脑 。
我揉了揉眼睛 ， 定了定神 ， 这不是做梦 。 ClickHouse就这样进入了我的视野 。
文章图片
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
2.社区活跃
ClickHouse是一款开源软件 ， 遵循ApacheLicense2.0协议 ， 所以它可以被免费使用 。 同时它的开源社区也非常跃度 ， 其在全球范围内约有400位贡献者 。
ClickHouse版本发布频率惊人 ， 基本保持着每个月发布一次版本的更新频率 。 友好的开源协议、活跃的社区加上积极的响应 ， 意味着我们可以及时获取最新特性并得到修复缺陷的补丁 。
篇幅有限 ， 如果你想了解ClickHouse的更多细节 ， 可以看一看《QQ音乐大数据架构技术演进》这篇文章 ， 并关注我们后续的推送文章 ， 还有下面这本书 。
关于作者：朱凯 ， ClickHouse贡献者之一 ， ClickHouse布道者 ， 资深架构师 ， 腾讯云最具价值专家TVP ， 开源爱好者 ， ApacheDolphinSchedulerCommitter ， 《企业级大数据平台构建：架构与实现》作者 ， 公众号“ClickHouse的秘密基地”运营者 。 十多年IT从业经验 ， 对大数据领域主流技术与解决方案有深入研究 ， 擅长分布式系统的架构设计与整合 。
本文摘编自《ClickHouse原理解析与应用实践》 ， 经出版方授权发布 。
文章图片
延伸阅读《ClickHouse原理解析与应用实践》
【从Hadoop到ClickHouse，现代BI系统有哪些问题？如何解决？】推荐语：ClickHouse开发团队负责人及核心贡献者亲自作序推荐 ， ClickHouse贡献者和布道者亲自执笔 ， 从核心理念、基础功能、运行原理以及实践应用等多个维度 ， 对ClickHouse进行全方位解析 。
推荐阅读
- 粤游记|旅游就该诗酒趁年华，带你一起到东京，我们玩点不一样的！
- IT|国药集团董事长：新冠灭活疫苗预计年底上市，两针不到一千元
- 绿色可循环包装好处多，为啥收快递时却遇不到？
- 分手后会彻底从你世界里消失的星座，从不停留，再不相见
- 知书达理，这些星座从来不出熊孩子
- 本月底，对爱情从来不会强求，即使失败，也能坦然面对的4大星座
- 18.19号事业宏图大展，运势爆棚，财富高涨，苦难到头的属相
- 星车记|9万买了一辆宝马5系，本以为自己捡到宝，拆开底盘一看维修工懵了
- 淡泊名利不贪心的3属相，赚钱却不少，从容也致富，能早一日发家
- 推荐|北京丰台一处自来水井发生“井喷”，多方联动，不到一小时修好