[4/4]我所经历的大数据平台发展史（四）：互联网时代 • 下篇

作者: 葡萄喃喃呓语 | 来源:发表于2017-02-10 20:57 被阅读64次

//
我所经历的大数据平台发展史（四）：互联网时代 • 下篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-internet-age

//在互联网曲线救国新解决
回顾在传统行业数据平台中，不管两位大师争论点数据模型的设计采用那种范式（Bill Inmon的EDW的原则是准三范式的设计、Ralph kilmbal是星型结构）但是都要非常重视数据源的质量问题。所以传统行业的数据模型会全盘考虑数据质量问题，并通过数据抽样分析给出合适的清洗口径。

编者按：本文是松子（李博源）的大数据平台发展史系列文章的第四篇（共四篇），本系列以独特的视角，比较了非互联网和互联网两个时代以及传统行业与非传统行业。是对数据平台发展的一个回忆，对非互联网、互联网，从数据平台的用户角度、数据架构演进、模型等进行了阐述。
在互联网时代被弱化的数据模型
谈起数据模型就不得不提传统数据平台架构发展，我相信很多朋友都晓得传统数据平台的知识，其架构演进简单一句话说“基本上可以分为五个时代、四种架构”，但是到了互联网时代因为大数据快速膨胀与数据源类型多样化特点，从高阶架构上来看大约从传统数据平台第三代架构开始延续的，但是往后的发展从我自己的这一点知识上很难对互联网的数据平台做架构归类。
但是从数据平台建设与服务角色上还是有章可循的。就像上篇分享到那样，类比两个行业，互联网企业中员工年龄比非互联网企业的要年轻、受教育程度、对计算机的焦虑程度明显比传统企业要低、还偶遇其它各方面的缘故，导致了数据平台所面对用户群体与非互联网数据平台有所差异化。
传统行业与互联网行业数据平台用户特性我只选择前文章的两张图来表示
(点击放大图像)

(点击放大图像)

在传统数据平台要背后有一个完整数据仓库团队去服务业务方，业务方嗷嗷待哺的等待被动方式去满足。中低层数据基本不会对业务方开放，所以不管数据模型采用何种建模方式，主要满足当时数据架构规划即可。
互联网业务的快速发展使得大家已经从经营、分析的诉求重点转为数据化的精细运营上，如何做好精细化运营问题上来，当资源不够时用户就叫喊，甚至有的业务方会挽起袖子来自己参与到从数据整理、加工、分析阶段。
此时呢，原有建设数据平台的多个角色（数据开发、模型设计）可能转为对其它非专业使用数据方，做培训、咨询与落地，写更加适合当前企业数据应用的一些方案与开发些数据产品等。
在互联网数据平台由于数据平台变为自由开放，大家使用数据的人也参与到数据的体系建设时，基本会因为不专业性，导致数据质量问题、重复对分数据浪费存储与资源、口径多样化、编码不统一、命名问题等等原因。数据质量逐渐变成一个特别突出的问题。
传统企业的数据源基本来自excel、表格、DB系统等，但在互联网有网站点击流日志、视频、音频、图片数据等很多非结构化快速产生与保存。移动互联网除了互联网那些外还含有大量定位数据、自动化传感器、嵌入式设备、自动化设备等，传统行业原有的数据平台技术对处理如此复杂而多样化的数据有些力不从心。
当数据模型逐渐被弱化后，数据架构导航图少了、难以建立业务系统与数据之间的映射与转换关系。数据描述经常不一致性。如：同名异义、同物异名。大量冗余的存在。数据模型被弱化（数据仓库模型）是传统企业与互联网企业一个蛮大的差异。但是呢，互联网企业也有自己特点，传统行业所涉及数据模型这个领域涉及的很多内容在互联网变成以其他的曲线救国的方式存在了。
在互联网曲线救国新解决
回顾在传统行业数据平台中，不管两位大师争论点数据模型的设计采用那种范式（Bill Inmon的EDW的原则是准三范式的设计、Ralph kilmbal是星型结构）但是都要非常重视数据源的质量问题。所以传统行业的数据模型会全盘考虑数据质量问题，并通过数据抽样分析给出合适的清洗口径。
(点击放大图像)

上图来自我2009年搞数据质量平台工具数据产品内容之一。
但是在互联网呢，数据质量在互联网数据平台变成了一种心病。（ps：我了解过一个公司，能让数据平台+数据分析师+业务多人“对数”对一年的还是不准的）。在应对数据的质量问题，目前互联网有些做法是把数据标准化前置到业务数据产生就做，从根源上去杜绝数据质量，但是这种场景比较实用在Log 日志的数据源中，比如移动互联网最近流行的基于事件模型“Event”模型，在日志产生时就规定好存储格式（备注：大家度娘搜索，“学习笔记：The Log（我所读过的最好的一篇分布式技术文章）” 对这个讲解很详细）。
在传统行业，目前还是以混合模型设计方式为主。在互联网的我所接触的一些业务，在参照传统数据模型方法论基础上逐步演进适合互联网数据的数据模型方法。
比如互联网金融等一些业务会参考传统金融行业对主题域的划分、OMG数据仓库元数据管理CWM模型、FSDM金融模型，再进一步考虑大数据处理特性去进行设计，所有从Hight Level 数据架构图看到主题层次划分与传统第三代数据仓库还是很多相似之处，当然模型架构也有分三层、四层、五层的。
不同的地方模型细节处理上已经完全不一样，比如数据的多样性、拉宽事实表、度量值单独存储、满足数据快速重生、维度的二次降维处理等、增加大量冗余列、增加大量派生列，结合自动化元数据来耦合、合并等相关管理。
(点击放大图像)

上图是支付宝非常早期数据模型
(点击放大图像)

上图为2012年产品UI之一。
(点击放大图像)

上图是2011-2012年该产品系列背后当时使用的技术
互联网业务特点业务垂直拆分非常细，比如一个用户注册、密码找回的流程有可能存在好几个产品负责同一个业务流程不同环节，相关的一个策略、产品feature快速迭代上线等等都要数据评估。数据从前端埋点到采集然后再由各个环节到数据平台，再有数据分析师或各业务部门去使用，基本拉长了时间周期。需求部门与实施部门能力和经验有千差万别的需求，造成了懂技术部门没有没有足够的精力完全理解业务部门奇形怪状需求，可能在各环节放缓与变的低效。
或许适合“敏捷”维度建模在当前是个不错的选择，如果一上来就想着建立一套能兼容所有数据和业务的数据模型，那就又回到传统数据仓库的建设上了，很难满足对业务变化的快速响应。互联网企业业务特点是变化非常迅速的，能稳定的业务达到65%算对数据平台是个福音了（根据对某宝宝的印象）剩余的业务变化迅速，必然导致数据模型快速上下线。
Kimball老人家提出的维度建模（备注，在本系列发展史得第一篇有介绍）围绕业务模型能够非常直观的表达出业务的数据关系，但是在互联网NOSQL牺牲掉了关系型数据库的一致性、完整性等等很多东西。维度数据模型又基于这些大数据技术的，所以进化的更加轻量级与基于细节数据的维度退化建模（原有的缓慢变化维、快速变化维、大维、迷你维、父子维、雪花维为了适应互联网的大数据Nosql处理技术进行反规范化、化&数据冗余设计。
退化维度的反规范化设计一方面可以把一条查询语句所需要的所有数据组合起来放到一个地方存储 Key values 的方式（比如说商品有不同类型，每一种类型商品又有自己的不同属性，可以采用一对多、多对多的方式存储，例如把一个多维映射为一个Key value）。
讲到互联网数据平台就要提数据模型，提了数据模型就要提Nosql技术，
(点击放大图像)

上图来自Nosql文档系列的一幅图
Nosql 是大数据处理的特征之一。互联网数据平台数据模型与NoSql技术还是蛮紧密的。这里有外文讲解Nosql Data modeling technigues 从技术角度讲解非常详（https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/）。
因为前边提到的大数据平台技术特性决定了传统edw模型、维度模型直接在互联网数据大数据平台部署或许还有“好些未知”障碍等待大家去克服。同时在传统数据建模用到的一些方法经过互联网熏陶或许演进成一种新的数据产品或方案吧。
到此为止“我所经历的大数据平台发展史”上下共四篇与大家分享完毕，这个写作前后经历刚好一个月左右，算是对自己数据从业经历回顾之一吧。在知识的整理中很多都是蜻蜓点水，每个知识域都是一个非常深的专业方向，自己涉足很肤浅，在文章中分享不足之处请各位读者见谅！！
个人邮箱是5592094@qq.com 欢迎电邮交流。
接下来我会进入数据产品这个领域的分享，当年车品觉老师自豪的作品之一“黄金策”，我是数据产品经理。（ps：自己躲在墙角拿车品觉老师往自己脸上贴金了）。
后记
有一次数据产品神策的创始人兼好友@桑文锋＠SensorsData跟我说来做次分享吧，我当时出了几个题目，最后就选择了“我所经历的大数据平台“，就形成了大家看到的”我所经历的大数据平台“系列文章.
在整理期间得到了死党@周爱民、@神策-桑文峰、 InfoQ小编@Tina Du 、@betty zhou @Laurel大力协助，在这里感谢！！！
番外篇
这一篇是在24日举行的分享大家提到的一些问题，经过整理算是对正文的补充吧，从互联网敏捷数据模型等角度做了较深入的细节介绍。同时在数据产品方面的回答包含了一点未来写作篇“数据产品”系列的一点内容。
1****，传统我们做BI的，做数据展现会建模后以pivot展现cube数据，不知道现在互联网公司数据展示如何做的？第三方工具还是用API取数据平台里的数据？adhoc报表及灵活更换维度的时候web端一般是怎么做的？
松子老师：刚才文章中提到了比如传统行业的多维数据模型cube。在互联网采用的曲线救国方式解决的。在分享中我给出了几个图。就是通过搜索引擎曲线救国方式实现类似Olap的模拟。
在这块的模型的处理上采用的是维度退化处理。通过反规范化，数据项、数据冗余去处理。在前端做特殊处理。
这个当时产品原型之一：
(点击放大图像)

这是一个2011年-2012年左右的数据产品，当时算是即时计算的一种。不过已经过去好几年了，当今新技术下Olap 引擎应该有很好的提升。
目前我知道的家互联网公司，在前端展现有使用第三方套件比如spagoBi、pentaho 等有自己设计开发定制化数据前端展现。比如我刚开始分享的那两个之前在去哪儿网设计的数据平台内部界面之一，当然数据产品是另一个话题了，通过对数据分析抽象指标、分析模型、用户使用功能与流程、未来规划考虑用户体验去设计。
(点击放大图像)

(点击放大图像)

2****，互联网财经类公司，业务包括财经网站、基金、股票、金融等，这类公司的数据仓库模型应该如何设计？特点和注意事项是什么？案例介绍？十分感谢。
松子老师：我自己经历过的是互联网金融以及移动互联网行。对这两块比较清楚。互联网金融起因为业务的特性是类金融类的，与银行有些地方是相似的。
比如大约在2012年前支付宝业务特点涉及类金融交易：充值、提现、账务管理类电子商务：购物交易过程变更、实际交易（对B机票、对C水电等）非纯电子商务；纯金融；个人信用，理财类。系统之间依赖度较为复杂，垂直依赖（业务与核心）跨层依赖（跨过交易到账务）。
在设计方法上还是采用维度模型设计方式。底层是数据驱动为向导，结合业务需求驱动，通过简单、退化维度的方式拉宽表结构。
底层采用松耦合设计。主题之间是松耦合方式。至体内采用细粒度退化维度。
在主题域上的的设计基本参考了OMG的数据仓库元数据设计CWM模型、IBM 的fsdm金融模型、还有新巴塞尔资本协议（Basel II Capital Accord）需提供数据规范去的设计。所以数据模型是五层的结构。
在细节处理上，增量ODS层数据和前一天DWD相关表进行 merge处理。
在一些层次上，基本聚合、汇总增加派生事实表（简单一句话退化为度打宽）。然后按照业务主体合并信息等。
比如开始给大家分享的那张图：
(点击放大图像)

更加详细的每一代数据平台建设、服务角色特点您可以看我这个系列文章的第三篇，http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02

4****，有没有好的元数据管理工具推荐？主要偏向数据字典与血统等。
松子老师：元数据以前目前没有太多的好管理工具。以前是在支付宝是我自己设计的一个数据产品。第一版自己用Delphi 开发的。
（图很多：）
(点击放大图像)

(点击放大图像)

以前被逼的自己写了一个，通过解析，实现了字段级的血缘影响分析。这只是第二步，后来又把running 信息给搞了进来。还有分享时提到的模型信息、整个闭环的分类信息。
这是一个分支：
(点击放大图像)

但是我们实现了字段级解析准确率达到了94%左右。有细微的错误就人工revew一遍。

5. ****松子老师，数据管控的数据质量部分是怎么处理的呢？

松子老师： 数据管控，这方面我不太懂的，但是数据质量，这玩意可大可小的。比如像在分享时说过的，在移动互联网的数据质量处理方式可以由原有的ETL(ELT)阶段前置到业务系统去解决，比如移动互联网的App log 日志，日志标准化后事件模型”存储来解决。那非app 日志类如何解决呢比如Payment、order等，数据质量比较考虑的可以只做到监控。
我来分享个图。刚好是我设计数据质量产品时搞的，理清数据质量的问题：
(点击放大图像)

(点击放大图像)

只要数据进入仓库与应用体系，处理起来就比较困难了，所以在数据平台阶段最好是通过监控、前置去解决。目前数据质量确实难以100%由事后搞到事前去处理。我对数据平台与数据产品的建设就是实用为主。怎么实用怎么来。我是比较现实的实用主义者。

6. ****能否分享一些数据产品种类及实例：

松子老师：在前边五个问题、以及文章中又都涉及数据产品实力的一些分享。
提到数据产品的分类我就想把这个图发出来。
自己认为没有特别明确的划分线，但是数据产品从三个维度划分，面向业务、功能、用户可以划分出三个方向的数据产品来。
比如面向数据平台工具型数据产品:调度、数据质量、元数据、数据建模、ETL工具、资源管控等等。
面向用户功能有报表型、多维型数据产品、定制化数据产品、挖掘型数据产品。
面向内部用户、外部个人用户、外部企业用户又有不同的分类。
根据业务又可以划分很多，面向C类用户、面向B类商户、金融风险等等
从近几年的数据产品来看，是更好的辅助用户的做决策的一种产品形态，在用户的决策与行动中充当信息的分析者与价值使用者；数据产品有个自己的共性：由解决的一个实际的业务问题出发，分解出的分析指标，分析模型，分析流程组成，再考虑到功能易用性，未来功能扩展，考虑用户对数据易用性（比如数据的呈现层次，不可能一次把所有数据的呈现给用户）来组成的。
(点击放大图像)