精彩看点：实时数仓、湖仓一体、流批一体，它们都在说什么

2022-09-29 09:46:01来源：ITPUB

01 先看来龙，再谈去脉

数据仓库概念兴起于上世纪90年代，随着IT系统的大发展，人们发现应用系统越来越多，但是对于经营决策的问题，反而越来越难以获取准确的决策信息。

据说有个笑话，发生在2000年前后，Oracle 总裁Larry 想知道Oracle 全球有多少人。但那时没有人知道，因为Oracle全球的业务系统分布在各个大洲/各个国家，每个区域都有自己的应用系统，但是没有一个全球统一的中央系统，从而发生了这么一个有趣的事。

【资料图】

这也促使Oracle 花费大量人力物力，把分布在各个不同国家地区的系统统一上收，做成全球系统。基于全球统一的数据进行决策分析，进入了Oracle 高速发展的20年。

其实很多企业都会发现，在经过了IT系统大规模建设之后，反而越来越难以获得有效的决策信息，数据分散在多个业务系统中，演变成有大量数据，但是缺乏有效信息的尴尬局面。一般而言，有这样的几种情况：

•决策信息分散在多个业务系统中；

•数据的不一致性突出，多个信息提供者对信息都不具备严格的定义，不同的业务系统对同一信息数据的理解和定义不同，甚至许多相同命名的数据所指代的业务信息并不相同；

•缺乏历史数据；

•业务系统的数据模型，是针对事务处理设计的，不适合做分析；

•在业务系统上做信息查询，会影响现有系统的运行；

•太多的数据，太少的信息。

为了走出重重困境，数据仓库就自然成了企业家关注的焦点，经过各行各业的业务实践，虽然也有很多种变种，但是大体上是个这样的结构。

02 数据仓库给企业带来了发展的机遇，也带来了挑战

数据仓库进入中国市场之后，经历了飞速发展的十年。在这十年里，多少IT届的仁人志士都在这个赛道上奋斗过，有很多成功的经验，也有不少失败的案例。

这里简单分享一个小故事，首先是中国移动的经营分析系统，经过10多年的发展，变成支撑企业绩效考评和市场运营的重要工具。我个人的观点，中国移动能够后来者居上，力压其他两家，和经营分析的有力支撑，有着千丝万缕的关系。

2015年之后，中国移动基本就没有再大规模地推出过经营分析建设规范，但是直到如今，中国移动的一级经营分析系统的各省数据上收，还是各省公司考核的重要指标。

随着智能手机和各种智能终端的快速发展，中国移动也推出各种新的业务和新的模式。这个时候，如何更好地了解客户，了解客户的行为习惯和消费模式，从而有针对性地推出新业务，自然就是市场部门的重要诉求。

手机用户在手机上交友、浏览、购物，娱乐都会产生大量的日志数据，另外手机基本上和人是一一绑定的，那么手机的定位系统自然也可以了解到用户的出行情况。但是这些数据对于现有的数据仓库来说，体量太大了，要想很好地收集处理，需要耗费巨量的资源。

举个例子，移动交换机每15分钟会把当前用户的位置信息吐出，交给后台处理，这个数据基本上是PB级的。

另外还有用户上网日志，包括网址信息，这些都是非结构化的信息，也很难纳入到当前的仓库模型当中，所以必须使用大数据技术。

谈到大数据技术，那肯定就是Hadoop，但是怎么更好地使用Hadoop技术，这时候就产生一些分歧：

•一部分人认为， Hadoop是全新的技术，是可以完全取代传统数据库进行数据分析的技术，传统数据库已经落伍。

•另外一部分人认为，Hadoop还不够成熟和普及，对于数据仓库的adhoc查询和分析，不可能奢望每个分析人员都会coding。而是应该发挥Hadoop大数据并行处理的优势，对于数据进行预处理之后，再去把结果导入到数据仓库中。

经过一段时间的沉淀和磨合，现在大家基本上更加认可第二种方式。

对于处理完的海量数据，怎么处理呢？

这就是个两难选择，因为存储需要成本，如果存储数据带来的收益不能cover 存储成本的话，那存储数据就不合算。

但是如果觉得数据还是很有价值，可能有一些目前没有发现的价值，将来还有其他的分析角度和分析需求的时候，那么就只有存储起来。这个时候就是数据湖（Data lake）了。

03 湖仓一体的主要目标就是打破壁垒，实现湖仓联动

Data lake 的主要定位，就是一个可以持续扩充的海量数据存储，容量更大，单位成本更低，主要用于对于这些海量数据的深度开采，另外也保存下来以备将来可用。

这个时候就有一些问题了。第一个需求，比如用户行为分析，因为用户行为分析和用户本身的属性是高度关联的。但是用户的所有属性都是在CRM系统中管理和存储，每当用户的属性发生变化，那么如何快速传递到数据湖，以免数据挖掘系统使用后不准确的数据，产生不准确的结果。

第二个需求，比如，经过数据湖中的数据挖掘，对于现有的数据分类、标签等操作，但是这些比如用户流失风险评估，用户近期喜好等特性，最好还是通过统一的用户界面与用户进行交互。

那么就自然需要把这些数据湖中的挖掘结果，尽快同步到电子渠道系统当中去，这样才能通过各种渠道媒介与客户互动，避免发生短信轰炸。

第三个需求，就是SQL on hadoop，这个是很自然的需求。因为无论如何，懂SQL的人总是比懂Spark或者Flink的人多。而且绝大多数的业务系统，目前都是使用SQL 作为主要数据处理语言。那么，如何把数据湖中的数据规范化之后，提供SQL 接口，让业务系统能够直接使用SQL访问数据湖中的数据，这也便成了顺理成章的需求了。

所以目前大家所讲的湖仓一体化，归根到底，实际上是针对数据的价值，并通过技术手段实现各层次之间联动：

高价值、高使用频度的数据，放在关系型数据库中，有条件可以上全闪或者数据库一体机，加快用户分析效率。

中等价值的数据，可以考虑多种存储模式，或者传统关系型，或者是使用MPP。更有甚者，考虑目前市面上的分布式数据库，都可以做一个性价比上的一个平衡。

当然巨量数据，还是优先推荐存放在Hadoop，甚至可以是云空间的对象存储上。因为不少Big SQL 的外延，已经可以扩展到S3之类的对象存储上了。这样就可以把历史数据的存储成本降到更低。

04 流批一体的目标，是进一步提高数据驱动能力

传统的数据仓库，一般都是T+1的数据采集模式。因为一般而言需要头天做了数据关账，才能给后台提供比较准确的财务数据，后来随着CDC技术的发展，现在业务系统的数据变化可以准实时进入到数据仓库中。

但是我们要知道，数据准实时同步，不一定代表分析数据准实时，因为多个系统之间，可能同步周期不一定相同。

另外，数据进入数据仓库，还有一个清晰度和汇总的过程，如果数据仓库随时进行海量数据的汇总和计算，那么计算量就太大了，得不偿失。对于大多数业务而言，数据粒度到前一天就够了。

但万事总有特例，对于一些实时营销的需求，那么数据粒度到前一天就不一定够了。

典型的，就像需要LBS（Location Based Services）信息的分析要求，就需要知道您现在到哪里了？比如您现在在高速上开车，那么需要知道的前方道路上的信息，事故或者堵车的情况，那么这些分析结果嘛，就需要利用流处理的方式，进行实时处理。

在流处理中，使用比较多的技术还是事件驱动（Event Drive），通过对于预先设定的一些事件进行预定义相关的操作。当数据流快速通过的时候，捕获事件模式，出现模式匹配的时候，去触发预定义的一些动作。

不过流处理的缺点在于，需要事先配置事件，如果没有配置相关事件，那么数据就自然而然的被忽视了。