最近在写现代数据技术栈相关的一些内容,有朋友想让我也写一下在现代数据技术栈中BI相关的内容,正好春节假期有比较整块的时间,决定顺着时间线来捋一下BI、数据仓库、数据湖以及数据湖仓相关的概念和历史。

什么是BI?



想了解什么是BI,大家最好先忘掉目前一些xxBI所代表的一些所谓的BI产品。从维基百科上,我们可以看到BI的一个定义,其定义如下:
Business intelligence (BI) comprises the strategies and technologies used by enterprises for the data analysis and management of business information. Common functions of business intelligence technologies include reporting, online analytical processing, analytics, dashboard development, data mining, process mining, complex event processing, business performance management, benchmarking, text mining, predictive analytics, and prescriptive analytics

从这段描述中,大家可以看到BI是商业智能(Business Intelligence)的简称和缩写,本身并不是一个具体的产品所能代表的。通常来讲,BI实际上是一套包含了从数据处理、数据分析、数据挖掘、预测以及分析报表的解决方案。从这个角度来讲,我们前面讲过的现代数据技术栈中所包含的每一个产品都在BI这个范畴之内。
BI这个概念的历史可以追溯到19世纪60年代,你没有看错,那个时候连计算机都没有。在1865年,理查德.米勒.德文斯在他的《商业趣闻百科全书》中首先提到了商业智能的概念。他用这个词去描述银行家亨利.福尼斯如何去收集和获取信息,早于他的竞争对手基于这些信息进行行动去获取更多的利润。
到了1958年,随着信息技术开始应用到企业中,IBM的研究员汉斯.彼得.卢恩在发表的论文中使用了商业智能这个词。在他的论文中,对于商业和智能分别做了定义:
商业 - 想要达成目标所开展的一系列的行为,目标可能是科学、技术、商业、工业、法律、政府、防御等等。
智能 - 一种理解所呈现的事实之间的关系的能力,以便指导行为朝着预期的目标前进。
而一个商业智能系统就是利用收集来的信息,去自动地指导行动,从而达成商业目标。
到了1989年,Gartner的分析师霍华德.德莱斯纳建议把商业智能作为一个专业术语用于描述"利用基于事实的支撑的系统来改善商业决策的概念和方法",到了20世纪90年代,商业智能这个词开始被广泛的认知和使用。
到了2008年,Forrester的鲍里斯.艾佛尔森进一步对BI进行了阐述,把BI定义为:一组方法、过程、体系结构、以及技术,它们能够将原始数据转变为有意义和有用的信息,用于实现更有效的战略、战术以及运营洞察和决策制定。
从这个定义我们可以看到,我们目前所知道的数据相关的产品,包括数据集成、数据准备、数据仓库、数据分析、数据报表、预测性分析等等都包含在了BI的范畴里边。我自己在刚刚参加工作的时候(1999年),正好有机会参与过上交所BI项目的建设,当时的方案基本上就包含了数据抽取、数仓建模、数据挖掘以及关联分析等等的内容,可见应该把BI理解为一个整体的解决方案,而不是一个具体的某个产品,我们目前所做的产品,都属于BI的范畴。在90年那个时候的BI产品,比较知名的包括:BO(被SAP收购),Cognos(被IBM收购), SAS, Hyperion(被Oracle收购),微策略等等。
在大家对BI的历史和定义有了初步了解后,这里再介绍一下敏捷BI。关于BI的描述我们可以看到传统的BI想要实施成功,是一个比较耗费时间同时也耗费资金的项目,因为复杂度比较高。而随着敏捷开发的流行,为了降低企业采用BI的成本,敏捷BI(Agile Business Intelligence)的概念被提了出来。从维基百科上,我们可以看到敏捷BI的定义如下:
Agile Business Intelligence (BI) refers to the use of the agile software development methodology for BI projects to reduce the time-to-value of traditional BI and helps in quickly adapting to changing business needs

这里可以看到敏捷BI主要是采用敏捷软件开发的方法去实施BI项目,从而降低BI项目的时间开销,快速地让BI在企业发挥作用。
随着敏捷BI的概念的提出,应运而生了适应敏捷BI的软件企业,其中最著名的就是敏捷BI的代表-Tableau(被Salesforce收购)了,国外知名度比较高的还有PowerBI, Qlik, Sisense等等。最近10几年,国内在敏捷BI领域也有了不错的发展,帆软还进入了Gartner的魔力象限,永洪、观远、衡石等也在国内这个2B软件严苛的环境中继续生存和发展。
相对于传统的BI,敏捷BI一般面向的企业的规模和结构相对要简单一些,企业采用BI的核心诉求是快速能够看到企业的运营状况以及各种指标的数据,面向的用户一般都是业务团队,因此敏捷BI一般都比较易用,报表能力也都比较出色。几个主流的敏捷BI产品基本上都是从数据准备到数据报表一体式部署给客户,为了用户的体验,支持的数据规模也有一定的限制。

什么是数据仓库?



前面介绍了关于BI的知识,我们再来看看什么是数据仓库,我们继续上维基百科:
In computing, a data warehouse (DW or DWH), also known as an enterprise data warehouse (EDW), is a system used for reporting and data analysis and is considered a core component of business intelligence. DWs are central repositories of integrated data from one or more disparate sources. They store current and historical data in one single place that are used for creating analytical reports for workers throughout the enterprise.

从这个描述中我们可以总结出来数据仓库是为了支持报表和数据分析的一个系统,是BI的一个核心的模块。对于企业来讲,数据仓库集中了来自于不同数据来源的数据,从而使得企业的BI可以有一个唯一的位置去获取分析报表所需要的所有的数据。
一个比较常见的数据仓库架构如下图:

从基本定义可以看到,数据仓库中存储的数据一般都是被清洗和整理过的数据,从而方便不同业务的数据使用。
正是因为这个原因,一般数据仓库的建设都避免不了数据建模过程。
一般的数仓建设都是分层的,通常分为ODS层(,运营数据层,一般存储来自于业务系统的详细数据),DW层(数据仓库层,一般又分为DWD-细节数据层,DWB-基础数据层,DWS-数据服务层), ADS层(应用数据服务层)。
而这些数据分层的实现,离不开我们常说的ETL(数据的抽取、转换和装载)。
数据仓库的建设通常会面向不同的主题进行建设,针对不同的主题进行建模。
具体到技术实现路径,数据仓库技术属于典型的OLAP(Online Analytical Processing)场景,针对这个场景,有不同的存储技术的设计和实现,具体到包括MOLAP, ROLAP, HOLAP等等。具体到产品,国产的开源数据库Kylin, 华人创办的硅谷公司开源的Druid应该都是MOLAP的产品。而类似于GreenPlum等等基于MPP架构的产品,则大部分是ROLAP产品。
随着技术发展到云的时代,基于云的数仓技术(CDW)成为了新的趋势,我个人是坚定的云技术支持者,相信CDW一定是数据仓库的未来。Snowflake之所以能够价值千亿美金,也正是因为这个原因。
具体到更多关于数据仓库技术以及相关概念的详细的介绍,网上可以搜到大量的内容,本文这里不再过多的进行详细介绍。

什么是数据湖?



说完了数据仓库,我们再来说一下数据湖-Data Lake。数据湖这个概念的产生实际上跟互联网的发展和大数据概念的产生有一定的关联性。数据仓库的数据来源一般都是来自于业务系统的数据库,但是随着各种事件类型的数据、日志类型的数据被记录和收集,如何更好地利用这些数据来指导业务就变得越来越重要,这也就促进了数据湖这个概念的产生。让我们来看看维基百科对数据湖的定义和描述:
A data lake is a system or repository of data stored in its natural/raw format, usually object blobs or files. A data lake is usually a single store of data including raw copies of source system data, sensor data, social data etc., and transformed data used for tasks such as reporting, visualization, advanced analytics and machine learning. A data lake can include structured data from relational databases (rows and columns), semi-structured data (CSV, logs, XML, JSON), unstructured data (emails, documents, PDFs) and binary data (images, audio, video).[

从这里可以看到,数据湖主要的目的就是存储各种类型的数据,可能包括结构化的数据,更重要的能够包括半结构化或者非结构化的数据,从而使得企业的各种类型的数据能够被存储下来,方便后期的利用。
对照数据仓库的定义和描述,我们可以比较清晰地理解数据湖和数据仓库的区别。数据仓库中的数据都是被整理和清洗过的,很好的组织起来的数据库表类型的结构化数据,因此数据仓库的数据可以方便的被使用。但是数据湖中的数据很多都是没有经过处理的原始数据,一般处于脏乱差的状态,想要被使用,就要被处理过之后才能更方便利用。不过由于数据仓库中的数据已经被清洗和处理过,因此也就损失了一部分原始的信息。尤其现在很多企业应用数据的需求很多都是即时性需求,基于数据仓库整理好的数据可能不能满足这些需求的要求,这个时候基于数据湖能够进行数据的处理、分析到结论就变得很关键。另外,很多预测型的需求也要求使用到更原始的数据来进行特征的提取,因此数据湖也为数据科学等等工作提供了很好的支撑。
当然,如果数据只是存到数据湖中,没有很好的整理,而且也没有很好的数据目录来维护元数据信息,数据湖有可能变成数据沼泽,让你的数据使用变得非常困难,所谓的数据资产可能就会变成负资产了。
随着云技术的发展和成熟,尤其是云存储的价格又相对比较低廉,而且技术的成熟度也比较高,因此越来越多的企业开始基于公有云来构建自己的数据湖,然后用云端提供的现代数据技术栈来让自己的数据产生价值。

湖仓一体是什么?



前面介绍了数据仓库以及数据湖的概念,接下来我们再说一下湖仓一体。从前面的介绍,我们可以看到数据仓库和数据湖各自有各自的使用场景和优缺点。但是对于企业来讲,最核心的是要能够更好地利用自己的数据,同时也能够尽量低成本地来管理和维护数据系统。如果企业需要维护一套数据仓库,同时也需要维护一套数据湖,无疑对企业带来很大的压力。也正是因为这个原因,一个新的数据架构-湖仓一体(Lakehouse)应运而生。湖仓一体式结合了数据仓库和数据湖的优点,直接在数据湖的低成本的存储的基础上,支持类似于数据仓库的结构化数据分析和管理能力。一般都湖仓一体架构有如下的特点:
支持事务,从而保证用SQL的时候的数据一致性
支持强制的Schema以及数据治理,支持类似于数据仓库的星型模型或者雪花模型,并且支持数据的全生命周期追溯和管理
支持BI工具,使得BI工具可以直接访问原始数据
存储计算分离,从而能够更好地支持弹性的并发计算请求
支持结构化、半结构化以及非结构化数据
支持不同类型的计算,包括多维分析、预测分析、数据科学模型等等
支持端到端的流式计算,从而能够支持实时数据应用
下图是关于数据仓库、数据湖和湖仓一体的区别的描述,图例来自于Databricks的官方博客:

湖仓一体是一个相对新的概念,但是由于它代表了一定的未来,而且处于整个数据驱动的核心位置,因此有很多相关的产品正在推出。比较知名的有Databricks的Deltalake,Netflix的Iceberg以及Uber的Hudi。据我所知,国内有多个团队在做类似的产品研发,其中不乏从阿里、百度大数据团队出来创业的公司,毕竟大家都希望中国能有自己的Databricks产生。

总结一下



到这里做个总结和展望,BI实际上是一个涵盖了数据应用各个环节的更广泛的概念,只是因为传统BI项目实施周期和成本太高,才有了更注重报表的敏捷BI的产生。数据仓库是支持BI报表的基础的数据存储。数据仓库、敏捷BI都是基于结构数据,侧重在报表分析的技术,因此在过去相当长一段时间能够满足企业使用数据的需求。但是随着互联网和云计算的发展,各种类型的数据在飞速的产生,传统的数据仓库和敏捷BI的使用场景已经不能够满足企业更丰富的使用数据的需求,这就促进了数据湖和后来湖仓一体的产生和发展。而随着公有云在逐渐吞噬一切,在云上构建数据仓库、数据湖、湖仓一体会成为趋势,基于云端数据仓库、数据湖和湖仓一体必然会产生新的各种数据相关的工具,这也是为什么现代数据技术栈在蓬勃发展的基础和原因。相信在未来几年,随着企业数据驱动需求的进一步放大,会有越来越多成功的数据工具公司产生。




