放开那程序猿!构建业务导向的大数据云平台

       按数据处理方式及使用目标,企业级IT系统可分为OLTP和OLAP系统。简而言之,OLTP系统生产数据,OLAP系统加工数据。从数据到智慧的转换金字塔上看,OLTP系统实现了底层的数据产生和存储以及面向事务的信息整合,在这之上的各层就要依赖OLAP系统了。OLAP概念源自决策支持系统(DSS),企业中的数据仓库、数据集市、统计报表、驾驶舱、数据挖掘等都属于OLAP体系。其中,数据仓库和数据集市主要实现信息整合,一般统称为数据整合平台。统计报表、驾驶舱、数据挖掘进一步利用数据整合平台的成果,帮助用户发现知识并最终形成智慧。


       OLAP系统的主要用户是分析人员和管理人员,目标是支持管理决策,依据是企业生产经营过程中产生的全量数据,是一个按目标使用场景对数据进行加工、利用的过程。这过程一般可以划分五个阶段:业务部门定义需求;IT部门根据需求获取并整合相关数据;IT部门根据需求设计分析模型;IT部门开发实施并发布;业务部门应用并衡量实际成效。在传统的数据基础和技术环境下,这个周期可能要经历较漫长的时间。还在建设OLAP体系的情况自不必多说,即便已建成OLAP体系统,要及时响应业务部门的需求也是较困难的,而且很有可能最终的交付质量不能达到需求方的预期。


       下图是目前较常见的OLAP体系简图,上游系统指那些OLTP系统,是数据源。数据整合平台包括ODS、数据仓库、数据集市等,主要实现数据整合。下游系统指那些利用数据整合平台成果的系统,包括统计报表、驾驶舱、数据挖掘等。其中,数据整合平台承上启下,在整个OLAP体系中非常重要。按照目前较普遍的架构,从上游到下游的数据流向,至少分为同构层、整合层、应用层。其中同构层在模型上基本与上游接入数据源基本保持一致,整合层一般会采用高范式模型进行数据整合,应用层面向下游具体应用采用星型模型。这个架构是在Inmon帮和Kimball派十几年如一日的不断撕逼和妥协中演进出来的,应该是一种最佳实践。但随着互联网+大数据时代到来,对数据应用有着更高效、更深入的要求,这种架构本身固有的缺点被不断放大。

开发周期长

       为了避免因上游系统接入模型的变化而导致数据整合平台模型的被动调整,整合层建模时一般会采用较高范式实现高内聚、低耦合,ER实体较多、关系复杂。这样就增加了ETL设计、开发以及测试的复杂度,同时ETL程序执行效率也低。业务部门提出的需求,IT首先由下至上逐层对模型进行分析,即便只需在应用层开发,基于上述原因也需要一周以上。如果涉及要改动整合层,开发周期要一个月左右,业务部门显然是不能接受的。最后的结局不用猜都知道,苦逼的程序猿只能再一次强睁熊猫眼天天加班赶工。但是故事并没有到此结束,马上一个意想不到但细细想想又是顺理成章的伴生问题发生了。

架构迅速变坏

       在日复一日的高压下,程序猿只能另辟蹊径为自己减负。既然工作量是由于数据模型和层次的复杂性引起的,那最有效的减少工作量的方法无非就是:1、绕过整合层,数据直接从同构层到应用层。2、还是从通过整合层,但使用面向应用的自建模型。无论哪种方法,都使整合层形同虚设,从同构层到应用层形成一个个数据井道。虽然单个开发任务的开发时间缩短了,但各数据井道之间无法复用,所以总的开发时间绝对要更多,而且后期的维护工作将是一场噩梦。

效率低

       架构变坏后,数据一致性无法保证,大量数据重复存储,大量指标重复计算,ETL作业数急剧上升,数据整合平台效率自然会越来越差。即便架构还能保持,但随着时间的推移,数据量及业务需求不断增加,架构上倾向分割出更多的层次,以便实现更多的复用。随着层次的增加,数据迁移的路径就变长了,长久以往也难逃低效率的宿命。


      再回顾下OLAP数据应用的五个阶段,从业务提出需求到业务应用验证形成闭环,这过程是由IT导向推动的,IT首先与业务讨论分析需求,在业务模型层面中达成共识,然后再映射到系统模型,实现对来自上游系统的数据进行加工处理,最后通过OLAP系统将结果在业务语境中展现给用户,之前讨论的所有弊病都此有关。而对于像银行、保险等发展较成熟的行业,其业务语境、模型是较稳定的,支持业务开展的上游IT系统的系统模型也应该是相对稳定的,因此业务模型和系统模型间能形成较稳定的映射关系。这样只要能达到足够细的粒度,就能实现操纵业务模型来改变系统模型的目的。而业务模型又能被业务所能理解,因此这个闭环过程就可以完全由业务导向不需要IT的参与,整个过程可以简化为:业务设计模型,业务应用验证。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,688评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,559评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,749评论 0 226
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,581评论 0 191
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,741评论 3 271
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,684评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,122评论 2 292
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,847评论 0 182
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,441评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,939评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,333评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,783评论 2 236
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,275评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,830评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,444评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,553评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,618评论 2 249

推荐阅读更多精彩内容