互联网数据模型不得不说的几件事
互联网时代被弱化的数据模型
谈起数据模型就不得不提传统数据平台架构发展，我相信很多朋友都晓得传统数据平台的知识，其架构演进简单一句话说“基本上可以分为五个时代、四种架构”，但是到了互联网时代因为大数据快速膨胀与数据源类型多样化特点，从高阶架构上来看大约从传统数据平台第三代架构开始延续的，但是往后的发展从我自己的这一点知识上很难对互联网的数据平台做架构归类。
但是从数据平台建设与服务角色上还是有章可循的。就像上篇分享到那样，类比两个行业，互联网企业中员工年龄比非互联网企业的要年轻、受教育程度、对计算机的焦虑程度明显比传统企业要低、还偶遇其它各方面的缘故，导致了数据平台所面对用户群体与非互联网数据平台有所差异化。
传统行业与互联网行业数据平台用户特性我只选择前文章的两张图来表示
在传统数据平台要背后有一个完整数据仓库团队去服务业务方，业务方嗷嗷待哺的等待被动方式去满足。中低层数据基本不会对业务方开放，所以不管数据模型采用何种建模方式，主要满足当时数据架构规划即可。
互联网业务的快速发展使得大家已经从经营、分析的诉求重点转为数据化的精细运营上，如何做好精细化运营问题上来，当资源不够时用户就叫喊， 甚至有的业务方会挽起袖子来自己参与到从数据整理、加工、分析阶段。
此时呢，原有建设数据平台的多个角色（数据开发、模型设计）可能转为对其它非专业使用数据方，做培训、咨询与落地，写更加适合当前企业数据应用的一些方案与开发些数据产品等。
在互联网数据平台由于数据平台变为自由开放，大家使用数据的人也参与到数据的体系建设时，基本会因为不专业性，导致数据质量问题、重复对分数据浪费存储与资源、口径多样化、编码不统一、命名问题等等原因。数据质量逐渐变成一个特别突出的问题。
传统企业的数据源基本来自excel、表格、DB系统等，但在互联网有网站点击流日志、视频、音频、图片数据等很多非结构化快速产生与保存。移动互联网除了互联网那些外还含有大量定位数据、自动化传感器、嵌入式设备、自动化设备等，传统行业原有的数据平台技术对处理如此复杂而多样化的数据有些力不从心。
当数据模型逐渐被弱化后，数据架构导航图少了、难以建立业务系统与数据之间的映射与转换关系。数据描述经常不一致性。如：同名异义、同物异名。大量冗余的存在。数据模型被弱化（数据仓库模型）是传统企业与互联网企业一个蛮大的差异。但是呢，互联网企业也有自己特点，传统行业所涉及数据模型这个领域涉及的很多内容在互联网变成以其他的曲线救国的方式存在了。
互联网曲线救国新解决
回顾在传统行业数据平台中，不管两位大师争论点数据模型的设计采用那种范式（Bill Inmon的EDW的原则是准三范式的设计、Ralph kilmbal是星型结构）但是都要非常重视数据源的质量问题。所以传统行业的数据模型会全盘考虑数据质量问题，并通过数据抽样分析给出合适的清洗口径。
上图来自我2009年搞数据质量平台工具数据产品内容之一▲
但是在互联网呢，数据质量在互联网数据平台变成了一种心病。
（ps：我了解过一个公司，能让数据平台+数据分析师+业务多人“对数”对一年的还是不准的）
在应对数据的质量问题，目前互联网有些做法是把数据标准化前置到业务数据产生就做，从根源上去杜绝数据质量，但是这种场景比较实用在Log 日志的数据源中，比如移动互联网最近流行的基于事件模型“Event”模型，在日志产生时就规定好存储格式
（备注：大家度娘搜索，“学习笔记：The Log（我所读过的最好的一篇分布式技术文章）” 对这个讲解很详细）
在传统行业，目前还是以混合模型设计方式为主。在互联网的我所接触的一些业务，在参照传统数据模型方法论基础上逐步演进适合互联网数据的数据模型方法。
比如互联网金融等一些业务会参考传统金融行业对主题域的划分、OMG数据仓库元数据管理CWM模型、FSDM金融模型，再进一步考虑大数据处理特性去进行设计，所有从Hight Level 数据架构图看到主题层次划分与传统第三代数据仓库还是很多相似之处，当然模型架构也有分三层、四层、五层的。
不同的地方模型细节处理上已经完全不一样，比如数据的多样性、拉宽事实表、度量值单独存储、满足数据快速重生、维度的二次降维处理等、增加大量冗余列、增加大量派生列，结合自动化元数据来耦合、合并等相关管理。
支付宝非常早期数据模型
支付宝非常早期数据模型
我们常提到的多维模型在大数据处理下进行了退化维度处理。大家知道Olap多维模型，随着维度的增加事实表的数据量会成几何指数暴增，即使在现有的大数据技术、新的Olap 引擎对一个Cube的数据量要求也要在时间与数据量上需要做到用户使用容忍度的平衡。
类似Olap的应用在互联网这个奇特思维土壤中我经历过一个曲线救国方式（2011-2012年时设计多维挖掘分析数据产品背后的技术就是搜索引擎实现的），现在应该也有新技术出现了来解决类似的问题。
上图为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模型、维度模型直接在互联网数据大数据平台部署或许还有“好些未知”障碍等待大家去克服。同时在传统数据建模用到的一些方法经过互联网熏陶或许演进成一种新的数据产品或方案吧。
Q & A
Q1：传统做BI的，做数据展现会建模后以pivot展现cube数据。现在互联网公司数据展示如何做的？第三方工具还是用API取数据平台里的数据？adhoc报表及灵活更换维度的时候web端一般是怎么做的？
A：刚才文章中提到了比如传统行业的多维数据模型cube。在互联网采用的曲线救国方式解决的。 在分享中我给出了几个图。就是通过搜索引擎曲线救国方式实现类似Olap的模拟。
在这块的模型的处理上采用的是维度退化处理。通过反规范化，数据项、数据冗余去处理。在前端做特殊处理。
这个当时产品原型之一：
这是一个2011年-2012年左右的数据产品，当时算是即时计算的一种。不过已经过去好几年了，当今新技术下Olap 引擎应该有很好的提升。
目前我知道的家互联网公司，在前端展现有使用第三方套件 比如spagoBi、pentaho 等有自己设计开发定制化数据前端展现。
比如我刚开始分享的那两个之前在去哪儿网设计的数据平台内部界面之一，当然数据产品是另一个话题了，通过对数据分析抽象指标、分析模型、用户使用功能与流程、未来规划考虑用户体验去设计。
Q2：互联网财经类公司，包括财经网站、基金、股票、金融等，这类公司的数据仓库模型应该如何设计？特点和注意事项是什么？案例介绍？
A：互联网金融起因为业务的特性是类金融类的，与银行有些地方是相似的。比如大约在2012年前支付宝业务特点涉及类金融交易：充值、提现、账务管理类电子商务：购物交易过程变更、实际交易（对B机票、对C水电等） 非纯电子商务；纯金融；个人信用，理财类。系统之间依赖度较为复杂，垂直依赖（业务与核心）跨层依赖（跨过交易到账务）。
在设计方法上还是采用维度模型设计方式。底层是数据驱动为向导，结合业务需求驱动，通过简单、退化维度的方式拉宽表结构。
底层采用松耦合设计。主题之间是松耦合方式。至体内采用细粒度退化维度。
在主题域上的的设计基本参考了OMG的数据仓库元数据设计CWM模型、IBM 的fsdm金融模型、还有新巴塞尔资本协议（Basel II Capital Accord）需提供数据规范去的设计。所以数据模型是五层的结构。
在细节处理上，增量ODS层数据和前一天DWD相关表进行 merge处理。
在一些层次上，基本聚合、汇总增加派生事实表（简单一句话退化为度打宽）。然后按照业务主体合并信息等。
比如开始给大家分享的那张图：
在维度模型退化处理时，要注意最细粒度数据保留、不同层次的数据支持数据重新生成。同时一定要注意互联网数据业务特性，数据质量是大心病。有可能一天某些表会重跑很多遍。在互联网的做法有可能一天会重跑好几次数据。
所以曲线救国的病态的产生出了一种通过元数据驱动的数据模型。
Q3：互联网企业大数据平台的发展历程是怎样的？
A：传统行业数据平台架构演进我总结简单一句话说“基本上可以分为五个时代、四种架构”，但是到了互联网时代因为大数据快速膨胀与类型暴增的特点，从高阶架构上来看大约从第三代架构开始延续的，但是从我自己的知识上很难对互联网的数据平台做架构归类。
所以我从互联网数据平台的建设、用户使用变化特征去做了总结。互联网数据平台基本是从传统数据平台的第三代开始的。那是我们总结下来用户特点：
更加详细的每一代数据平台建设、服务角色特点您可以看我这个系列文章的第三篇
http://www.infoq.com/cn/articles/the-development-history-of-big-data-platform-paet02
Q4：有没有好的元数据管理工具推荐？主要偏向数据字典与血统等。
A：元数据以前目前没有太多的好管理工具。以前是在支付宝是我自己设计的一个数据产品。第一版自己用Delphi 开发的。
以前被逼的自己写了一个，通过解析，实现了字段级的血缘影响分析。这只是第二步，后来又把running 信息给搞了进来。还有分享时提到的模型信息、整个闭环的分类信息。
这是一个分支：
但是我们实现了字段级解析准确率达到了94%左右。有细微的错误就人工revew一遍。
Q5： 数据管控的数据质量部分是怎么处理的呢？
A： 数据管控， 这方面我不太懂的，但是数据质量，这玩意可大可小的。比如像在分享时说过的，在移动互联网的数据质量处理方式可以由原有的ETL(ELT)阶段前置到业务系统去解决，比如移动互联网的App log 日志，日志标准化后事件模型”存储来解决。
非app 日志类如何解决呢比如Payment、order等，数据质量比较考虑的可以只做到监控。
我来分享个图。刚好是我设计数据质量产品时搞的，理清数据质量的问题：
只要数据进入仓库与应用体系，处理起来就比较困难了，所以在数据平台阶段最好是通过监控、前置去解决。目前数据质量确实难以100%由事后搞到事前去处理。我对数据平台与数据产品的建设就是实用为主。怎么实用怎么来。我是比较现实的实用主义者。
Q6：能否分享一些数据产品种类及实例？
A：在前边五个问题、以及文章中又都涉及数据产品实力的一些分享。提到数据产品的分类我就想把这个图发出来。
自己认为没有特别明确的划分线，但是数据产品从三个维度划分，面向业务、功能、用户 可以划分出三个方向的数据产品来。
比如面向数据平台工具型数据产品:调度、数据质量、元数据、数据建模、ETL工具、资源管控等等。
面向用户功能有报表型、多维型数据产品、定制化数据产品、挖掘型数据产品。面向内部用户、外部个人用户、外部企业用户又有不同的分类。
根据业务又可以划分很多，面向C类用户、面向B类商户、金融风险等等
从近几年的数据产品来看，是更好的辅助用户的做决策的一种产品形态，在用户的决策与行动中充当信息的分析者与价值使用者；数据产品有个自己的共性：由解决的一个实际的业务问题出发，分解出的分析指标，分析模型，分析流程组成，再考虑到功能易用性，未来功能扩展，考虑用户对数据易用性（比如数据的呈现层次，不可能一次把所有数据的呈现给用户）来组成的。
Q7：银行业从传统的ods到edw再到大数据平台这块过渡，模型如何建设？平台优势如何发挥？
A：这个问题还是有些难度的，自己回答的可能有些片面。首先我们清醒的清楚“大数据”是什么？再次不同的场景可以采用不同的技术去解决。
“大数据”，拆开来看大、数据，大可以是指的数据源结构简单（ps 如果了解过当代对大数据的定义就知道四个特性）但是量级够大，比如清算、结算、对公、对私、中间业务等等每一个拿出来都是几十T，但是这些业务数据都是保存传统的关系型数据库中如DB2、Oracle、MSsql中，因为在数据平台存储是通过准3范式等等结构去保存。
在存储时可能要比较复杂的SQL 多表关联的，感觉目前传统的数据平台技技术在处理数据很让人着急。想通过互联网的大数据平台hadoop、Hive 、Spark 等技术的去演进解决。（最早时我的是中信银行、光大银行在2011年左右开始考虑Hadoop技术，后来不知道如何了）。
但是互联网的数据平台技术大都是NOSQL模式，牺牲掉了传统数据库的数据一致性、完整性、唯一索引等等，只干性能的事情（当然除了性能、可扩展性也是的）.
原有在传统数据平台模型设计上可以考虑的一些通过主外键、唯一索引做一些业务约束的方法，在nosql上统统的都没有了，这些约束必须放到数据加工阶段去想办法做检查。传统数据平台如果在Insert、update数据时违反了业务约束可以做报警或异常处理，但是在Nosql的平台上要求ETL 去手动遵守这些规则检查。
但是有时ETL开发根本不遵守的，仅仅是两个表关联起来，也可能忘记按照某一个业务唯一索引做去重操作。简单说，原有靠关系型数据库本身机制去做检查一些规则变为人工，变为人工就会犯错。
从关系型数据平台往Nosql数据平台迁移时，尤其是对传统行业的业务来说，在模型设计阶段、以及给出的ETL口径要考虑更多的业务规则检查，其次要考虑更多的维度退化、多冗余、表打宽处理。简单说就是发挥数据平台的计算能力同时要更加的各方面确保数据准确安全可靠。
数据模型ODS 到EDW 这块的设计方法百度上留下的文档资料太多的了，请这位提问的老师百度吧。
Q8：大数据仓库中如何做快速维处理？互联网数仓数据质量不好如何对数，如何确立标准的对数口径？
A：快速变化维度可以转化为缓慢变化为来出来，我自己理解的快速维度是相对于缓慢维度参照的来说的。
举个例子，年龄-转化为天数可以是定义快速变化维度，因为每天都在变化。我们可以把年龄退化为区间维度来处理，还可以把年龄做成动态维度来处理，事实表中保存的就是实际的出生年月并打宽表，年龄(天)通过计算方式来处理。还有种方法通过对代理键的方式来处理。
我目前也不知道对数据的标准是什么。但是我自己用的方法，把一个指标的整个数据流向切出几个关键点通过SQL去实现对数，看波动振幅，波动曲线。同时还会比如发不通的版本的小流量测试的方式来做数据校对。
Q9： 做为数据行业从业者，需要掌握哪些重要的基础知识？另：如果从零开始建立一个数据平台，需要哪些资源配置（人，财，物，技术）？大致总投资额度多少？如果同行产品间多种来源的数据，可有成熟的解决方案？
A：这个问题太宏观了。作为数据行业从业者，需要掌握哪些重要基础知识，这个是要看从事具体数据域的垂直行业。
比如说 数据开发、数据模型、数据产品、数据分析师、数据运营、数据架构师这些更加专业领域是需要不同的知识的。大家可以去itongji.cn、百度等去搜索数据架构等文章能得到更加专业的答案。
一家公司建设数据平台是跟公司目前数据量、未来数据增长、技术选型、解决业务问题有很直接的关系的。所以在解决业务目标不太明确下，难以确定方案，人员配置上选用不同技术方案去搭建的配置是不太一样的，比如说传统平台来讲，运维、DBA、数据开发、数据模型、报表人员。
从互联网数据平台基本配置上，数据架构师、运维、底层大数据技术、数据开发兼模型、数据分析师、数据产品等都有可能需要的。
同行产品间度多种数据来源，那就看数据源种类，文本的、日志类、视频影像、爬虫类的、结构化、非结构化的数据源有不同的解决技术。
Q10：传统银行业数据模型什么时候会走向互联网模式呢？目前在传统银行数据平台的产品是不是特别多？
A：这个问题我自己就不知道了，或许是传统银行在数据平台的实施上全面用互联网的Nosql大数据处理技术吧。至于说传统银行数据模型用现有的互联网数据模型理念去设计是否完全可行，数据一致性、高准确性通过更多的方案去保证。
首先我需要确定一下这个产品是否指的“数据产品”。
如果是数据产品，那其实传统行业数据平台本身就有一些数据产品了，而且也都是存在的。数据产品自从数据仓库出现以来它其实一直都存在的，只不过是近几年因为互联网特别爱制造“流行词“把数据产品这个词给放大了。互联网是得数据产品从早期的重量级逐渐进化为轻量级、从大而全的解决方案逐渐演进为因小而美。
我来给出几组例子，大约从2004年到现在的几组数据产品的例子
你可以分类一下，这些数据产品的特点是什么？满足了用户怎么样的痛点需求？满足了用户怎么样的使用流程。
Q11：传统行业的数据仓库从业人员，如果转到互联网行业，应该学习哪些技能？
A：这个问题你可以百度搜索“大数据职位所需要的数据技能” http://blog.jobbole.com/99039/ 这篇文章。自己觉得人家回答的比我专业。
欢迎加入本站公开兴趣群
软件开发技术群
兴趣范围包括：Java，C/C++，Python，PHP，Ruby，shell等各种语言开发经验交流，各种框架使用，外包项目机会，学习、培训、跳槽等交流
QQ群：26931708
Hadoop源代码研究群
兴趣范围包括：Hadoop源代码解读，改进，优化，分布式系统场景定制，与Hadoop有关的各种开源项目，总之就是玩转Hadoop
QQ群：288410967
