Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >专栏 >全新一代企业级大数据应用模式揭秘

全新一代企业级大数据应用模式揭秘

原创
作者头像
数澜科技
修改于 2019-10-11 10:08:51
修改于 2019-10-11 10:08:51
7870
举报
文章被收录于专栏:数据中台数据中台

三个问题

1.当下是否还需要一个复杂的EDW(企业级数据仓库)?

2.数据系统的目标用户是谁?

3.让数据适应计算能力还是计算跟着数据走

数据仓库这个概念在二十多年前由Bill Inmon提出后,几乎所有的IT厂商都开始介入这个领域,为企业级数据仓库设计非常复杂的体系结构和数据模型,典型的企业级数据应用架构如下:

这个架构,层次结构非常清晰,但是链路非常长,导致数据冗余非常大,同时数据表结构关系复杂,是一个典型的给技术人员使用的模型,业务的同学要使用数据是非常难的,没法理解底层复杂的表结构和表之间复杂的关联关系。这个现状到现在还在持续存在,许多企业投入大量的资源构建企业级数据仓库,目标是提升企业自身数据化运营的能力,其结果大部分都与目标相差很远,更多看到的就是构建了一套报表系统。

同时,随着互联网和移动互联网的兴起,几乎所有的企业都在拥抱互联网,企业里面产生出很多互联网应用,同时也产生了大量的非结构化数据,结果问题来了,发现按照这样的结构设计数据模型,似乎并不能解决企业对非结构化数据的应用能力。同时对于提升数据处理效率也没有带来多大的用处。

业务变化快,这点在新兴互联网公司表现的特别明显,在创新的驱动下,业务变化非常频繁,同时大数据概念的提出,多源数据结合使用将成为主流的数据应用模式,导致数仓工程师很难抽象出一个相对比较稳定的数据仓库模型。

产生大量沉睡数据,很多企业里面,设计了ODS、DW、DM、RT层,产生了大量的数据表和数据任务,结果真正生产上使用的数据不多,导致每天有大量的关联任务在不断的耗用资源。我遇到的一些case,每日从业务库里面抽取的表只有1万多张,但是经过后面的各种加工,整个库里面产生上百万张数据表,技术人员使用起来都非常困难了,找不到数据。

我们回过头来分析一下,为什么会这样,同时也思考一下那三个问题。为什么会按照这个体系来设计:

我认为,出现上述架构的最大的原因是计算能力不够,传统的IT架构用来实现DT架构,计算能力受限,必须通过改变数据的组织形式来适应计算。也就是前面我提到的数据跟着计算走,去积极的适应计算能力。这同时也导致另一个更为严重的问题,二十几年的发展,各个大数据厂商,都把很大精力放在了数据模型的设计和构建上面,忽略了针对上层业务场景化应用的计算模型探索,所以在新的技术体系下,我们需要来重新思考这些问题。

这样的模式下,限制了上层数据应用模式,企业里面业务人员根本不可能去理解一个复杂的IT架构,所有的需求都是由业务人员驱动技术人员来实现。真正对数据有需求的业务人员,理解不了技术的语言,他们理解不了什么是表、什么事字段、什么是主键、什么是外键、表与表之间怎么关联、甚至是SQL怎么写都很难理解。而日常工作中,业务人员更能理解的是什么,他们能理解自己的客户是谁,客户都长什么样子,具备什么样的气质;自己有哪些产品,产品有什么功能,能解决什么问题;自己的客户和产品之间是如何互动,互动的结果是什么。诸如此类的,这是业务人员能力理解的。所以当下要做的就是抽象并提供一套能让业务人员直接可以理解使用的数据模型,而这个模型一定不是传统的数仓模型。

封闭的,不透明的,这也是导致企业内数据膨胀的重要原因,同一个标签,甚至同一张表,在企业数据仓库里面比比皆是,导致大量数据冗余,因为很多技术同学根本不知道库里面有什么,厂商提的元数据管理也是面向技术的一个方案,没有从本质上解决数据的业务视图。所以企业里面需要一种可以协同、共享、共建的全新的数据应用体系,确保有效数据的有效透出。

企业需要数据应用,提升自身数据化运营能力,但是是否需要一个复杂的DW模型,我认为当下不需要了,设计上应该轻数据模型(注意这里是轻数据模型,不是不要),重计算模型。

DTBoost新一代企业数据应用模式

DTBoost是什么?DTBoost是阿里云结合阿里巴巴自身大数据应用场景,经过多年总结抽象出的企业级大数据应用平台,其目标,是让业务人员可以快速的理解数据,应用数据;轻数据模型设计,重计算模型设计;结构开放,快速支撑数据应用开发;企业内部共建共享,协同开发。

DTBoost对标的产品是什么?

我周边经常有人问我这个问题,我可以直接告大家,DTBoost目前没有对标的产品。在我理解,DTBoost是一种全新的企业级数据应用开发的模式,我们通过DT技术的手段,将这种模式实现成一套公共云计算平台上数据应用的PaaS,同时也可以部署在专有云。通过DTBoost可以帮助企业快速实现数据业务解决方案,同时使得业务人员直接使用数据变成现实。

DTBoost架构

通过前面的分析,DT时代需要一个全新的数据模型,这个也将是整个DTBoost的基础。我们要站在业务的视角来设计。同时要提供一套数据模型的管理系统,来方便模型的设计和构建。为此在数据模型这部分将包含以下几个核心模块。

上图中,最下面三个标签工厂、领域OLT模版、智能OL发现主要是为了加速业务OLT模型构建和标签生产。

OLT(Object Link Tag)模型:所谓的实体,例如 消费者、商家、商品等都可以表示成一个实体,这些都是直接业务的同学可以理解的。关系例如 交易、收藏、点击、搜索等行为都是一个关系,由多个实体之间发生的某种行为。同时我们会在实体、关系上打上很多标签,来刻画实体和关系。听下来和OLP模型非常像,不错,在整体模型结构上一致,我们重点在tag(标签)这部分,标签是业务人员最容易理解的一种数据形态,标签可以是实体的某种属性,也可以是通过算法深度加工出来的某个评分,或者多个标签组合的一个计算逻辑。

共建共享

DTBoost可以在标签这个粒度实现权限控制,确保企业内形成共建共享的数据应用模式,标签可以有多个团队开发,可以发布、授权共享给其它部门查看使用。确保业务应用数据层公开透明。

市场机制

在这一层也可以通过市场机制的模式确保数据质量,严格意义上讲是标签数据质量,DTBoost可以通过标签元信息的公开透明,确保业务同学能快速的理解标签业务含义;通过讲标签的数据分布可视化,确保数据产出的稳定性;通过业务线使用标签的情况,来确保标签是否要被淘汰,如果一个标签长时间没人用,系统就可以考虑将其停用下线,释放底层计算资源;再进一步可以通过上层应用的情况,来自动优化物理层数据的组织方式。这里举个例子,如果A、B、C三个标签经常性被业务方组合使用,原先这三个标签在物理层分布在三张表中,那这种情况下,DTBoost会自动检测,自动构建新的底层物理表,将三个标签合并到同一张表中,优化存储的同时,优化了计算。

智能搬迁

这里在标签元信息中,DTBoost会详细记录标签对应物理的存储,当业务方在应用标签时,只用对计算模型进行选择,不用对数据物理存储关心,这个模块会根据计算模型的指令,完成底层物理数据的自动关联和搬迁(这里的搬迁指的是自动的将数据由一个存储搬迁到计算模型需要的存储中),不用数据开发的同学再去做物理数据的关联和数据传输任务的配置。

API

下面的所有功能,DTBoost将其封装成标准的API,共合作伙伴或者开发者做二次开发。

UI

DTBoost通过一个官方标准的交互界面,将底下的这些功能封装,给用户提供一套统一的操作体验。

标签工厂

为什么需要这个模块,DTBoost数据模型里面有非常重要的一块就是标签,但是标签怎么产生,哪些标签是有效的标签,这个就至关重要。而生成标签的方式有多种,可以让数据开发人员,根据业务同学的定义,通过SQL或着MR去一一实现,这个也是不可避免的。但是经过对业务需求的分析,你会发现有一部分计算逻辑是非常通用的,为此DTBoost里面可以为客户提供这部分功能,来解决企业内30-50%的标签加工需求,让业务人员自己就可以实现通用方法的标签加工。同时标签工厂能够对用户屏蔽底层之间的表联接逻辑,用户只需要知道所用的标签含义即可。当在某个时间段内同时有多个标签进行生成、处理、分析的时候,标签工厂可以自动找出这些处理的共同依赖、同一计算等,节省计算资源,避免某些热门物理表被多次全盘扫描。现阶段规划的功能如下:

当前支持的衍生方法:

  • 时间序列上的衍生: 方法名称 方法描述
  • cnt 变量在一定周期内的发生次数
  • cntd 变量在一定周期内出现的不同值次数
  • totv 变量在一定周期内的总和
  • ttav 变量在一定周期内的均值
  • hmax 变量在一定周期内的最大值
  • hmin 变量在一定周期内的最小值
  • hmedian 变量在一定周期内的中位数
  • stddev 变量在一定周期内的标准差
  • variance 变量在一定周期内的方差
  • days 变量在一定周期内满足条件的天数
  • ftdays 变量在一定周期内满足条件的首次行为距今时长 ltdays 变量在一定周期内满足条件的末次行为距今时长
  • 组合标签支持的表达式以及函数:
  • 计算运算:+, -, *, /, %
  • 数学函数:abs,acos,asin,atan,ceil,conv,cos,cosh,cot,exp,floor,ln,log,pow,round,sin,sinh,sqrt,tanh,tanh
  • 智能发现
  • 这个模块的作用就是加速构建OLT模型的过程,如果说 标签工厂是加速T的过程,那么智能发现就是加速OL的过程。如何构建一个有效的OLT模型非常关键,也是这个新一代大数据应用模式里面可能花费时间最长的环节。为此我们通过技术的手段来辅助解决这个问题,实体在物理数据中大部分都是以Key的形式存在,关系一般都是以组合Key的形式存在,我们采用机器学习方式,通过对业务库log的挖掘,自动的发现出可能的实体和关系,并根据关系的强弱切割成不同的子图,来帮助建模师确认、发现关键的业务模型。

领域OLT模版

这点非常有意思,也是真正意义上的领域知识,通过DTBoost在不同行业的不断输出,可以总结沉淀出不同领域的实体关系模型,沉淀出不同领域标签模型以及标签分类体系,来形成DTBoost领域知识库。同时它不仅仅是模型层的一个领域模版,他会和上层计算模型联动,形成从模型层到应用层一整套模版。比如金融领域,首先会沉淀出一套金融领域的实体关系标签模型,基于这个之上,可以沉淀出一套多维交叉分析模版、风控预警模版、市场营销模版。在相同领域输出时,可以基于这个领域知识库做快速的客户化改造。

到这里,数据模型部分可以告一个段落,这块是新一代企业大数据应用模式的基础,非常重要,为此DTBoost在这部分花了大量的时间和资源进行设计开发。重要但确实是个基础,他并不能直接解决业务问题,真正作用到业务是基于这套数据模型之上的计算模型。

【转自:必达】

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
一篇并不起眼的数据仓库面试题
首先,用于支持决策,面向分析型数据处理;其次,对多个异构的数据源有效集成,集成后按照主题进行重组,并包含历史数据,而且存放在数据仓库中的数据一般不再修改。
王知无-import_bigdata
2021/07/12
2K0
一篇并不起眼的数据仓库面试题
50000字,数仓建设保姆级教程,离线和实时一网打尽(理论+实战) 上
我们在谈数仓之前,为了让大家有直观的认识,先来谈数仓架构,“架构”是什么?这个问题从来就没有一个准确的答案。这里我们引用一段话:在软件行业,一种被普遍接受的架构定义是指系统的一个或多个结构。结构中包括软件的构建(构建是指软件的设计与实现),构建的外部可以看到属性以及它们之间的相互关系。
五分钟学大数据
2021/12/09
11.8K0
50000字,数仓建设保姆级教程,离线和实时一网打尽(理论+实战) 上
中台之上(五):业务架构和中台的难点,都是需要反复锤炼出标准模型
企业级业务模型的建设离不开标准化操作,因为做企业级模型要横向对比分析企业所有业务领域,以期望在设计上实现“以更少支持更多”,这是很多企业搞企业级系统建设或者企业级转型的目标,希望能够同时实现系统实现的快速灵活和减少重复开发以降低成本这两个目标。这个愿望是非常美好的,也是很多企业级架构设计追求的目标,关于对这一点的体会,留待以后再讲,这节我们还是一起讨论下为实现这一目标所需要进行的标准化工作。
用户6900693
2020/04/10
7000
数据仓库常用几种建模方法
什么是数据模型 为什么需要数据模型 如何建设数据模型 最后,我们在本文的结尾给大家介绍了一个具体的数据仓库建模的样例,帮助大家来了解整个数据建模的过程。
Spark学习技巧
2020/12/11
1.7K0
数据仓库常用几种建模方法
企业级业务架构设计笔记三:设计起点与设计过程
业务架构面向企业战略和企业整体。它的一般实现包括设计和落地两个过程,并且设计与落地(升级)这两个过程是不断交替上升的。
程序员架构进阶
2022/12/01
9710
企业级业务架构设计笔记三:设计起点与设计过程
关于数据建模之思考(一)
之前分享了关于数据中台建设之思考和关于中台建设之思考,数据中台建设要考虑三个方面,一是前沿IT技术之储备,二是对业务的掌握程度,三是数据建模方法。
python与大数据分析
2022/03/11
4350
关于数据建模之思考(一)
关于数据仓库的数据模型的思考
任何需求均来源于业务 , 业务决定了需求 , 需求分析的正确与否是关系到项目成败的关键所在 , 从任何角度都可以说项目是由业务驱动的所以数据仓库项目也是由业务所驱动的 。
python与大数据分析
2022/03/11
3150
关于数据仓库的数据模型的思考
读《企业级业务结构设计方法论与实践》笔记
因为近两年的数字化很火,未来可能是数字化货币、数字化企业管理、数字化正在一步步的被可度量化、被逐渐的实现,那么听过企业数字化转型,到底何为数字化呢?
用户6900693
2021/03/11
9500
读《企业级业务结构设计方法论与实践》笔记
程序员们,是时候重新关注下企业架构了!(续)
笔者有幸参加过一个在全世界范围看也少有的极为完整的大型银行企业架构转型工程,是一家国有银行,工程历时六年多,项目投入和深度都是无与伦比的。该项目采用的是 TOGAF 加 CBM 的融合型方法论,其工程情况如下图所示:
用户6900693
2021/12/26
5140
程序员们,是时候重新关注下企业架构了!(续)
【揭秘】中国四大银行的大数据应用已到了哪个阶段?
对于大数据给企业带来的价值,已经毋庸置疑。在国内,银行业应该是IT建设更为领先的行业之一。特别中、农、工、建四大银行,更是走在整个银行业的前面。那么,他们对于大数据是如何看待的?在这四大银行,大数据的
IT阅读排行榜
2018/08/17
7780
从0建设离线数据仓库
技术升级快于我们的想象,今天的故事在明天来看就是一种常识。对于数仓而言,又何尝不是?互联网的发展,导致大数据的人才缺口。互联网公司雨后春笋,传统行业机巧转身。短短几年,数据行业已沧海桑田。今天谈大数据已不复当年雾里看花的景象,它像一列更高速的快车,和老前辈们一样,向自己的终点加速。
王知无-import_bigdata
2019/08/29
2.5K0
从0建设离线数据仓库
中台之上(八):企业级业务架构的实现需要不断沟通和调整
前面讲过了模型转化为方案和基于模型的沟通,自然就到了基于模型和业务架构进行的企业级 IT 系统开发,相信到这一讲很多人都会有所期待,毕竟从业务到模型只是一个复杂的“预备过程”,开发才是大家关注的重头戏,然而,我不得不以自己六年的企业级项目经验告诉大家,这里既没有什么神秘,也不该有什么神秘。可能让你失望了,但这是事实。为什么很多企业,甚至包括科技企业在内,业务转型或企业级方面做得不理想,其实是因为一个很简单的问题——脱节。一开始把企业级或业务转型搞得“高大上”,请咨询顾问、搞战略项目,但是往往停留在企业高层,缺少向执行层面的贯穿,当然也就更谈不到传导到开发,甚至搞战略时技术人员都很少参与。
用户6900693
2020/04/10
4940
如何设计企业级大数据分析平台?
传统企业的OLAP几乎都是基于关系型数据库,在面临“大数据”分析瓶颈,甚至实时数据分析的挑战时,在架构上如何应对?本文试拟出几个大数据OLAP平台的设计要点,意在抛砖引玉。 一、突破设计原则 建设企业
企鹅号小编
2018/02/01
1.4K0
数据仓库面试题集锦(附答案和数仓知识体系)
光阴似箭,岁月如刀。小编已经从刚毕业时堤上看风的白衣少年,变成了一个有五年开发经验的半老程序员。五年——是一个非常重要的时间节点,意味你见过很多套技术构架,学过很多技术组件,写过很多行代码,有了自己的技术理解、知识体系和编码风格。这个时候我们对待技术的态度已经从扩宽广度,慢慢转变成沉淀深度为主了。
不吃西红柿
2022/07/29
6.1K0
数据仓库面试题集锦(附答案和数仓知识体系)
阿里大数据之路:数据模型篇大总结
核心:从业务架构设计(如何快速上手工作)到模型设计,从数据研发到数据服务,做到数据可管理、可追溯、可规避重复建设。
王知无-import_bigdata
2022/11/11
1.9K0
阿里大数据之路:数据模型篇大总结
架构演进的第四个趋势:行业级标准化
笔者在上一篇文章《关于架构演进发展的探讨》(又名《中台辨析:架构的演化趋势》)中,总结了架构方法发展的三个趋势:
用户6900693
2020/04/10
1K0
论道数据仓库维度建模和关系建模
为什么要数据仓库建模呢? 如果把数据看作图书馆里的书,我们希望看到它们在书架上分门别类地放置;如果把数据看作城市的建筑,我们希望城市规划布局合理;如果把数据看作电脑文件和文件夹,我们希望按照自己的习惯有很好的文件夹组织方式,而不是糟糕混乱的桌面,经常为找一个文件而不知所措。 数据模型就是数据组织和存储方法,它强调从业务、数据存取和使用角度合理存储数据。Linux的创始人Torvalds有一段关于“什么才是优秀程序员”的话:“烂程序员关心的是代码,好程序员关心的是数据结构和它们之间的关系”,最能够说明数据模型
企鹅号小编
2018/02/24
2.1K0
论道数据仓库维度建模和关系建模
一文探究数据仓库体系(2.7万字建议收藏)
数据仓库,英文名称为Data Warehouse,可简写为DW或DWH。数据仓库,是为企业所有级别的决策制定过程,提供所有类型数据支持的战略集合。它出于分析性报告和决策支持目的而创建。
肉眼品世界
2020/11/11
1.9K0
一文探究数据仓库体系(2.7万字建议收藏)
数字化转型时代的企业数据新基建 | 爱分析报告
刚刚过去的21世纪的第二个十年,是消费互联网蓬勃发展的十年,也是云计算、大数据、人工智能等新一代信息技术,即“数字化技术”快速崛起的十年。
爱分析ifenxi
2022/07/22
4920
数字化转型时代的企业数据新基建 | 爱分析报告
【案例】恒丰银行——基于大数据技术的数据仓库应用建设
数据猿导读 恒丰银行探索采用大数据技术构建统一的企业级数据管理平台,重构数据仓库应用,减少数据重复加工与存储,促进信息管理应用的数据融合共享,提高数据处理总体效率,提升数据分析和应用创新能力,正逐步取得预期的成效。 本篇案例为数据猿推出的大型“金融大数据主题策划”活动(查看详情)第一部分的系列案例/征文;感谢 恒丰银行 的投递 作为整体活动的第二部分,2017年6月29日,由数据猿主办,互联网普惠金融研究院合办,中国信息通信研究院、大数据发展促进委员会、上海大数据联盟、首席数据官联盟协
数据猿
2018/04/24
3.7K0
【案例】恒丰银行——基于大数据技术的数据仓库应用建设
推荐阅读
相关推荐
一篇并不起眼的数据仓库面试题
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档