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

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

【资料图】

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

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

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

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

•缺乏历史数据；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

流批一体的的常用模式就是， 数据进来之后， 分双路进行处理， 一路是传统的数据仓库的ETL， 目标是进入数仓；而另一路数据就会通过流处理引擎， 在流处理引擎中会对数据进行及时响应。

比如在滴滴出租车运营过程中， 那么就需要结合流处理和批处理的数据，对于运营过程中出现的安全事件，进行预测分析及主动干预。

对于一些时效性比较强的行业， 传统的数据仓库可以解决财务分析的难题， 但是不能对全流程进行实时监控，

比如外卖平台， 需要准确知道目前的订单进行到了哪一步？目前整个路程中的瓶颈在什么地方？

比如出租车行业， 需要知道目前周围有没有出租车， 预定的出租车什么时候能到？还需要多久能够到达目的地？

这些需求都需要对当前的实时信息进行获取之后， 再进一步通过AI算法来进行预测之后， 才能进行准确地回答，所以这些行业是实时数仓的主要目标客户群。

实时数仓从整个数据处理的流程上来看， 主要涉及几个环节，实时数据采集， 实时数据运算，报表实时输出。下面分别来看看几个环节的使用场景和相关技术：

实时数据采集， 主要是采用一些变化数据捕获机制，来接入来自各个不同渠道的实时数据变化， 对于关系型数据库，有Golden Gate 或者直接Binlog 解析的方式，直接获取变化数据。另外也有使用Kafka队列， 来实现前端系统的变化数据直接投递的。

实时数据运算， 则是对于最近进来的数据， 马上加入运算引擎进行分析和处理， 比如几乎所有的出行行业，都需要对用户在出行过程中的状态和安全态势 进行分析和研判， 以便于提供及时主动的安全干预。这个需要考虑的是实时数据运算的规模和粒度， 过大过小都不能达到最好效果。需要根据实际场景来具体决定。

实时数据报表， 这个对于很多营销行为就很重要， 比如春晚红包， 那么就需要随时在大屏幕上，展示目前营销活动各个环节的情况， 以便于对策略进行及时的调整。

另外在一些大型调度业务场景， 也需要对海量数据进行分析之后，快速输出分析图表进行大屏展示。

IT 行业瞬息万变，各种新的技术和新的词汇令人无所适从，但是万变不离其宗， 抓住业务场景来去理解业务的痛点， 进而才能有效把握新技术的卖点。

以上我对几个目前流行的技术词汇，进行了简单的剖析和举例，每个行业使用场景不同， 需求也自然不同， 采用的技术路线也会各有千秋。一千个人心中有一千个哈姆雷特， 对于这些场景，您有什么不同的见解， 欢迎拍砖。