学校网站开发协议,夫妻网络网站建设,装修合同电子版,网站 mssql 数据库如今#xff0c;随着诸如互联网以及物联网等技术的不断发展#xff0c;越来越多的数据被生产出来-据统计#xff0c;每天大约有超过2.5亿亿字节的各种各样数据产生。这些数据需要被存储起来并且能够被方便的分析和利用。
随着大数据技术的不断更新和迭代#xff0c;数据管…如今随着诸如互联网以及物联网等技术的不断发展越来越多的数据被生产出来-据统计每天大约有超过2.5亿亿字节的各种各样数据产生。这些数据需要被存储起来并且能够被方便的分析和利用。
随着大数据技术的不断更新和迭代数据管理工具得到了飞速的发展相关概念如雨后春笋一般应运而生如从最初决策支持系统(DSS)到商业智能(BI)、数据仓库、数据湖、数据中台等这些概念特别容易混淆本文对这些名词术语及内涵进行系统的解析便于读者对数据平台相关的概念有全面的认识。
1.1 数据库
关系数据库本质上是一个二元关系说的简单一些就是一个二维表格对普通人来说最简单的理解就是一个Excel表格。这种数据库类型具有结构化程度高独立性强冗余度低等等优点一下子就促进了计算机的发展。 1.2 操作型数据库和分析型数据库
随着关系数据库理论的提出诞生了一系列经典的RDBMS如OracleMySQLSQL Server等。这些RDBMS被成功推向市场并为社会信息化的发展做出的重大贡献。然而随着数据库使用范围的不断扩大它被逐步划分为两大基本类型
操作型数据库
主要用于业务支撑。一个公司往往会使用并维护若干个操作型数据库这些数据库保存着公司的日常操作数据比如商品购买、酒店预订、学生成绩录入等
分析型数据库
主要用于历史数据分析。这类数据库作为公司的单独数据存储负责利用历史数据对公司各主题域进行统计分析
那么为什么要分家在一起不合适吗能不能构建一个同样适用于操作和分析的统一数据库答案是NO。一个显然的原因是它们会打架…如果操作型任务和分析型任务抢资源怎么办呢再者它们有太多不同以致于早已貌合神离。接下来看看它们到底有哪些不同吧。
1.3 操作型数据库 VS 分析型数据库 因为主导功能的不同(面向操作/面向分析)两类数据库就产生了很多细节上的差异。这就好像同样是人但一个和尚和一个穆斯林肯定有很多行为/观念上的不同。
接下来本文将详细分析两类数据库的不同点
数据组成差别 - 数据时间范围差别
一般来讲操作型数据库只会存放90天以内的数据而分析型数据库存放的则是数年内的数据。这点也是将操作型数据和分析型数据进行物理分离的主要原因。
数据组成差别 - 数据细节层次差别
操作型数据库存放的主要是细节数据而分析型数据库中虽然既有细节数据又有汇总数据但对于用户来说重点关注的是汇总数据部分。
操作型数据库中自然也有汇总需求但汇总数据本身不存储而只存储其生成公式。这是因为操作型数据是动态变化的因此汇总数据会在每次查询时动态生成。
而对于分析型数据库来说因为汇总数据比较稳定不会发生改变而且其计算量也比较大(因为时间跨度大)因此它的汇总数据可考虑事先计算好以避免重复计算。
数据组成差别 - 数据时间表示差别
操作型数据通常反映的是现实世界的当前状态而分析型数据库既有当前状态还有过去各时刻的快照分析型数据库的使用者可以综合所有快照对各个历史阶段进行统计分析。
技术差别 - 查询数据总量和查询频度差别
操作型查询的数据量少而频率多分析型查询则反过来数据量大而频率少。要想同时实现这两种情况的配置优化是不可能的这也是将两类数据库物理分隔的原因之一。
技术差别 - 数据更新差别
操作型数据库允许用户进行增删改查分析型数据库用户则只能进行查询。
技术差别 - 数据冗余差别
数据的意义是什么就是减少数据冗余避免更新异常。而如5所述分析型数据库中没有更新操作。因此减少数据冗余也就没那么重要了。
现在回到开篇是提到的第二个问题某大公司Hadoop Hive里的关系表不完全满足完整/参照性约束也不完全满足范式要求甚至第一范式都不满足。这种情况正常吗答曰是正常的。因为Hive是一种数据仓库而数据仓库和分析型数据库的关系非常紧密(后文会讲到)。它只提供查询接口不提供更新接口这就使得消除冗余的诸多措施不需要被特别严格地执行了。
功能差别 - 数据读者差别
操作型数据库的使用者是业务环境内的各个角色如用户商家进货商等分析型数据库则只被少量用户用来做综合性决策。
功能差别 - 数据定位差别
这里说的定位主要是指以何种目的组织起来。操作型数据库是为了支撑具体业务的因此也被称为面向应用型数据库分析型数据库则是针对各特定业务主题域的分析任务创建的因此也被称为面向主题型数据库。
2.1 概述
数据仓库就是为了解决数据库不能解决的问题而提出的。那么数据库无法解决什么样的问题呢这个我们得先说说什么是OLAP和OLTP。
2.2 OLTP和OLAP
2.2.1 OLTP
OLTPOnLine Transaction Processing 联机事务处理 。简单一些就是数据库的增删查改。举个例子你到银行去取一笔钱出来或者转账或者只是想查一下你还有多少存款这些都是面向“事务”类型的操作。这样的操作有几个显著的特点:
首先要求速度很快 基本上都是高可靠的在线操作比如银行 还有这些操作涉及的数据内容不会特别大否则速度也就相应的降低 最后“事务”型的操作往往都要求是精准操作比如你去银行取款必须要求一个具体的数字你是不可能对着柜台员工说我大概想取400到500快之间吧那样人家会一脸懵逼。
2.2.2 OLAP
这个东西又是上面发明关系型数据库的科德发明的。OLAP略有复杂但这里我举一个简单的例子大家就很容易理解了。
比如说沃尔玛超市的数据库里有很多张表格记录着各个商品的交易记录。超市里销售一种运动饮料我们不妨称之为红牛。数据库中有一张表A记录了红牛在一年的各个月份的销售额还有一张表B记录了红牛每个月在美国各个州的销售额甚至还有一张表C记录了这家饮料公司在每个州对红牛饮料的宣传资金投入甚至后来沃尔玛又从国家气象局拿到了美国各个州的一年365天每天的天气表。好最后问题来了请根据以上数据分析红牛在宣传资金不超过三百万的情况下什么季节什么天气美国哪个州最好卖凭借我们的经验可能会得出夏季的晴天在美国的佛罗里达最好卖而且宣传资金投入越高销售额应该也会高。可能这样的结论是正确的但决策者想要看到的是确凿的数据结论而不是“可能”这样的字眼。
科学是不相信直觉的如果我们人工进行手动分析会发现这个要考虑的维度实在太多了根本无法下手何况这才四五个维度要是更多了怎么办OLAP就是为了解决这样的问题诞生的但糟糕的是传统数据库是无法满足OLAP所需要的数据信息的。
2.3 数据仓库概念
2.3.1 概述
数据库的大规模应用使得信息行业的数据爆炸式的增长为了研究数据之间的关系挖掘数据隐藏的价值人们越来越多的需要使用OLAP来为决策者进行分析探究一些深层次的关系和信息。但很显然不同的数据库之间根本做不到数据共享就算同一家数据库公司数据库之间的集成也存在非常大的挑战最主要的问题是庞大的数据如何有效合并、存储。
1988年为解决企业的数据集成问题IBM卧槽又是IBM的两位研究员Barry Devlin和Paul Murphy创造性地提出了一个新的术语数据仓库Data Warehouse。看到这里读者朋友们可能要问了然后呢然后…然后就没然后了。就在这个创世纪的术语诞生了之后IBM就哑火了只是将这个名词作为市场宣传的花哨概念并没有在技术领域有什么实质性的研究和突破可悲我大IBM。。
然而尽管IBM不为所动其他企业却在加紧对数据仓库的研究和开发大家都想在这个领域寻找到第一桶金。终于到了1992年后来被誉为“数据仓库之父”的比尔 恩门Bill Inmon给出了数据仓库的定义二十多年后的今天他的定义依然没有被时代淘汰。我们来看看他是怎么定义的数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合用于支持管理中的决策制定。
对于数据仓库的概念我们可以从两个层次予以理解
首先,数据仓库用于支持决策,面向分析型数据处理,它不同于企业现有的操作型数据库; 其次,数据仓库是对多个异构的数据源有效集成,集成后按照主题进行了重组,并包含历史数据,而且存放在数据仓库中的数据一般不再修改。
我们可以不用管这个定义简单的理解其实就是我们为了进行OLAP把分布在各个散落独立的数据库孤岛整合在了一个数据结构里面称之为数据仓库。
这个数据仓库在技术上是怎么建立的读者朋友们并不需要关心但是我们要知道原来各个数据孤岛中的数据可能会在物理位置比如沃尔玛在各个州可能都有自己的数据中心、存储格式比如月份是数值类型但但天气可能是字符类型、商业平台不同数据库可能用的是Oracle数据库有的是微软SQL Server数据库、编写的语言Java或者Scale等等等各个方面完全不同数据仓库要做的工作就是将他们按照所需要的格式提取出来再进行必要的转换统一数据格式、清洗去掉无效或者不需要的数据等最后装载进数据仓库我们所说的ETL工具就是用来干这个的。这样拿我们上面红牛的例子来说所有的信息就统一放在了数据仓库中了。
自从数据仓库出现之后信息产业就开始从以关系型数据库为基础的运营式系统慢慢向决策支持系统发展。这个决策支持系统其实就是我们现在说的商务智能Business Intelligence即BI。
可以这么说数据仓库为OLAP解决了数据来源问题数据仓库和OLAP互相促进发展进一步驱动了商务智能的成熟但真正将商务智能赋予“智能”的正是我们现在热谈的下一代技术数据挖掘。
2.3.2 数据仓库特点 面向主题
面向主题特性是数据仓库和操作型数据库的根本区别。
操作型数据库是为了支撑各种业务而建立
而分析型数据库则是为了对从各种繁杂业务中抽象出来的分析主题(如用户、成本、商品等)进行分析而建立所谓主题是指用户使用数据仓库进行决策时所关心的重点方面如收入、客户、销售渠道等所谓面向主题是指数据仓库内的信息是按主题进行组织的而不是像业务支撑系统那样是按照业务功能进行组织的。
集成性
集成性是指数据仓库会将不同源数据库中的数据汇总到一起
具体来说是指数据仓库中的信息不是从各个业务系统中简单抽取出来的而是经过一系列加工、整理和汇总的过程因此数据仓库中的信息是关于整个企业的一致的全局信息。
企业范围
数据仓库内的数据是面向公司全局的。比如某个主题域为成本则全公司和成本有关的信息都会被汇集进来
历史性
较之操作型数据库数据仓库的时间跨度通常比较长。前者通常保存几个月后者可能几年甚至几十年
时变性
时变性是指数据仓库包含来自其时间范围不同时间段的数据快照。有了这些数据快照以后用户便可将其汇总生成各历史阶段的数据分析报告
数据仓库内的信息并不只是反映企业当前的状态而是记录了从过去某一时点到当前各个阶段的信息。通过这些信息可以对企业的发展历程和未来趋势做出定量分析和预测。
2.3.3 数据仓库与BI
数据仓库平台逐步从BI报表为主到分析为主、到预测为主、再到操作智能为目标。 从过去报表发生了什么—分析为什么过去会发生----将来会发生什么----什么正在发生-----让正确的事情发生
商务智能BIBusiness Intelligence是一种以提供决策分析性的运营数据为目的而建立的信息系统。
是属于在线分析处理On Line Analytical Processing(OLAP)将预先计算完成的汇总数据储存于魔方数据库(Cube) 之中针对复杂的分析查询提供快速的响应。
在前10年BI报表项目比较多是数据仓库项目的前期预热项目主要分析为主的阶段是数据仓库的初级阶段制作一些可视化报表展现给管理者:
它利用信息科技将分散于企业内、外部各种数据加以整合并转换成知识并依据某些特定的主题需求进行决策分析和运算用户则通过报表、图表、多维度分析的方式寻找解决业务问题所需要的方案这些结果将呈报给决策者以支持策略性的决策和定义组织绩效或者融入智能知识库自动向客户推送。
2.3.4 数据仓库系统作用和定位
数据仓库系统的作用能实现跨业务条线、跨系统的数据整合为管理分析和业务决策提供统一的数据支持。数据仓库能够从根本上帮助你把公司的运营数据转化成为高价值的可以获取的信息或知识并且在恰当的时候通过恰当的方式把恰当的信息传递给恰当的人。 是面向企业中、高级管理进行业务分析和绩效考核的数据整合、分析和展现的工具 是主要用于历史性、综合性和深层次数据分析 数据来源是ERP例:SAP系统或其他业务系统 能够提供灵活、直观、简洁和易于操作的多维查询分析; 不是日常交易操作系统不能直接产生交易数据。
传统离线数据仓库针对实时数据处理非结构化数据处理能力较弱以及在业务在预警预测方面应用相对有限。
但现在已经开始兴起实时数仓。
2.3.5 数据仓库能提供什么 2.4 数据仓库组件
数据仓库的核心组件有四个业务系统各源数据库ETL数据仓库前端应用。如下图所示 业务系统
业务系统包含各种源数据库这些源数据库既为业务系统提供数据支撑同时也作为数据仓库的数据源(注除了业务系统数据仓库也可从其他外部数据源获取数据)
ETL
数据仓库会周期不断地从源数据库提取清洗好了的数据因此也被称为目标系统。ETL分别代表
提取extraction
表示从操作型数据库搜集指定数据
转换transformation
表示将数据转化为指定格式并进行数据清洗保证数据质量
加载load
加载过程表示将转换过后满足指定格式的数据加载进数据仓库。
前端应用
和操作型数据库一样数据仓库通常提供具有直接访问数据仓库功能的前端应用这些应用也被称为BI(商务智能)应用。
数据仓库系统除了包含分析产品本身之外还包含数据集成、数据存储、数据计算、门户展现、平台管理等其它一系列的产品。 数据仓库系统除了包含分析产品本身之外还包含数据集成、数据存储、数据计算、门户展现、平台管理等其它一系列的产品。 2.5 数据仓库开发流程
2.5.1 概述
数据仓库的开发流程和数据库的比较相似因此本文仅就其中区别进行分析。
下图为数据仓库的开发流程 2.5.2 数据仓库需求
需求搜集是所有环节中最重要的一步吃透了用户需求往往就成功了大半。这些需求将指导后面如需求建模、实现、以及前端应用程序开发等。通常来说需求都会通过ER图来表示(参考数据库需求与ER建模)并和各业务方讨论搜集得到最终整理成文档。
要特别强调的一点是数据仓库系统开发需求阶段过程是循环迭代式的一开始的需求集并不大但随着项目的进展需求会越来越多。而且不论是以上哪个阶段发生了需求变动整个流程都需要重新走一遍决不允许隐式变更需求。
比如为一个学生选课系统进行ER建模得到如下结果 2.5.3 数据仓库建模
也就是逻辑模型建模可参考第二篇数据库关系建模
ER建模环节完成后需求就被描述成了ER图。之后便可根据这个ER图设计相应的关系表了。
但从ER图到具体关系表的建立还需要经过两个步骤1. 逻辑模型设计 2. 物理模型设计。其中前者将ER图映射为逻辑意义上的关系表后者则映射为物理意义上的关系表。
逻辑意义上的关系表可以理解为单纯意义上的关系表它不涉及到表中字段数据类型索引信息触发器等等细节信息。 概念模型 VS 逻辑模型
我们首先可以认为【概念模型建模和ER建模需求可视化】表达的是一个意思。在这个环节中数据开发人员绘制ER图并和项目各方人员协同需求达成一致。由于这部分的工作涉及到的人员开发能力比较薄弱甚至不懂开发因此ER图必须清晰明了不能涉及到过多的技术细节比如要给多对多联系/多值属性等多建一张表要设置外码各种复合主码等它们应当对非开发人员透明。而且ER图中每个属性只会出现一次减少了蕴含的信息量是更好的交流和文档化工具。在ER图绘制完毕之后才开始将它映射为关系表。这个映射的过程就叫做逻辑模型建模或者关系建模。
还有ER模型所蕴含的信息也没有全部被逻辑模型包含。比如联系的自定义基数约束比如实体的复合属性派生属性用户的自定义约束等等。因此ER模型在整个开发流程(如物理模型建模甚至前端开发)中是都会用到的不能认为ER模型转换到逻辑模型后就可以扔一边了。
逻辑模型VS物理模型
逻辑模型设计好后就可以开始着手数据仓库的物理实现了他也被称为物理模型建模这个阶段不但需要参照逻辑模型还应当参照ER图。
2.5.4 数据仓库实现
这一步的本质就是在空的数据仓库里实现2种前面创建的关系模型一般通过使用SQL或者提供的前端工具实现。
2.5.5 开发前端应用程序
前端应用开发在需求搜集好了之后就开始进行主要有网站、APP等前端形式。另外前端程序的实际实现涉及到和数据仓库之间交互因此这一步的最终完成在数据库建模之后。
2.5.6 ETL工程
较之数据库系统开发流程数据仓库开发只多出ETL工程部分。然而这一部分极有可能是整个数据仓库开发流程中最为耗时耗资源的一个环节。因为该环节要整理各大业务系统中杂乱无章的数据并协调元数据上的差别所以工作量很大。在很多公司都专门设有ETL工程师这样的岗位大的公司甚至专门聘请ETL专家。
2.5.7 数据仓库部署
顾名思义这一步就是部署数据库系统的软硬件环境。数据库部署往往还包含将初始数据填入数据库中的意思。对于云数据仓库这一步就叫数据上云。
2.5.8 数据仓库使用
这一步没啥多讲的就再讲一个有关的故事吧。同样是在A公司有一次某政企私有云项目完成后我们有人被派去给他们培训如何使用。结果去的人回来后说政企意见很大认为让他们学习SQL以外的东西都不行。拒绝用Python写UDF更拒绝MR编程接口只要SQL和图形界面操作方式。一开始我对政企的这种行为有点看不起但后来我想就是因为有这群挑剔的用户才使得A公司云产品的易用性如此强大从而占领国内云计算的大部分市场。用户的需求才是技术的唯一试金石。
2.5.9 数据库管理和维护
严格来讲这部分不算开发流程属于数据库系统开发完成后的工作。
2.6 数据仓库系统管理
数据仓库系统发行后控制权便从数据仓库设计、实现、部署的团队移交给了数据仓库管理员并由他们来对系统进行管理涵盖了确保一个已经部署的数据仓库系统正确运行的各种行为。为了实现这一目标具体包含以下范畴 2.7 数据质量体系
数据仓库系统需要重视数据质量问题。用一句话概括数据质量就是衡量数据能否真实、及时反映客观世界的指标。具体来说数据质量包含以下几大指标 准确性
准确性要求数据能够正确描述客观世界。比如某用户姓名拼音mu chen错误的录入成了muc hen就应该弹出警告语
唯一性视情况而定
唯一性要求数据不能被重复录入或者不能有两个几乎相同的关系。比如张三李四在不同业务环境下分别建立了近乎相同的关系这时应将这两个关系合并
完整性
完整性要求进行数据搜集时需求数据的被描述程度要高。比如一个用户的购买记录中必然要有支付金额这个属性规则验证。
一致性
一致性要求不同关系、或者同一关系不同字段的数据意义不发生冲突。
比如某关系中昨天存货量字段当天进货量字段-当天销售量字段等于当天存货量就可能是数据质量有问题
及时性
及时性要求数据库系统中的数据保鲜。比如当天的购买记录当天就要入库
统一性
统一性要求数据格式统一。比如nike这个品牌不能有的字段描述为耐克而有的字段又是奈克
小结
数据质量和数据具体意义有很大相关性因此无法单凭理论来保证。且由于具体业务及真实世界的复杂性数据质量问题必然会存在不可能完全预防得了。因此很多公司都提供了数据质量工程服务/软件用来识别和校正数据库系统中的各种数据质量问题。 Bill Inmon说过一句话叫“IT经理们面对最重要的问题就是到底先建立数据仓库还是先建立数据集市”足以说明搞清楚这两者之间的关系是十分重要而迫切的通常在考虑建立数据仓库之前会涉及到如下一些问题
采取自上而下还是自下而上的设计方法 企业范围还是部门范围 先建立数据仓库还是数据集市 建立领航系统还是直接实施 数据集市是否相互独立
数据集市可以理解为是一种小型数据仓库它只包含单个主题且关注范围也非全局。
数据集市可以分为两种:
一种是独立数据集市(independent data mart)这类数据集市有自己的源数据库和ETL架构
另一种是非独立数据集市(dependent data mart)这种数据集市没有自己的源系统它的数据来自数据仓库。当用户或者应用程序不需要/不必要/不允许用到整个数据仓库的数据时非独立数据集市就可以简单为用户提供一个数据仓库的子集。
4.1 概述
Pentaho首席技术官James Dixon创造了“数据湖”一词。它把数据集市描述成一瓶水清洗过的包装过的和结构化易于使用的。
而数据湖更像是在自然状态下的水数据流从源系统流向这个湖。用户可以在数据湖里校验取样或完全的使用数据。
这个也是一个不精确的定义。数据湖还有以下特点 从源系统导入所有的数据没有数据流失。 数据存储时没有经过转换或只是简单的处理。 数据转换和定义schema 用于满足分析需求。 数据湖为什么叫数据湖而不叫数据河或者数据海一个有意思的回答是
“河”强调的是流动性“海纳百川”河终究是要流入大海的而企业级数据是需要长期沉淀的因此叫“湖”比叫“河”要贴切
同时湖水天然是分层的满足不同的生态系统要求这与企业建设统一数据中心存放管理数据的需求是一致的“热”数据在上层方便应用随时使用温数据、冷数据位于数据中心不同的存储介质中达到数据存储容量与成本的平衡。
不叫“海”的原因在于海是无边无界的而“湖”是有边界的这个边界就是企业/组织的业务边界因此数据湖需要更多的数据管理和权限管理能力。
叫“湖”的另一个重要原因是数据湖是需要精细治理的一个缺乏管控、缺乏治理的数据湖最终会退化为“数据沼泽”从而使应用无法有效访问数据使存于其中的数据失去价值。
4.2 数据湖定义
4.2.1 维基百科对数据湖的定义 数据湖Data Lake是一个存储企业的各种各样原始数据的大型仓库其中的数据可供存取、处理、分析及传输。数据湖是以其自然格式存储的数据的系统或存储库通常是对象blob或文件。
数据湖通常是企业所有数据的单一存储包括源系统数据的原始副本以及用于报告、可视化、分析和机器学习等任务的转换数据。
数据湖从企业的多个数据源获取原始数据并且针对不同的目的同一份原始数据还可能有多种满足特定内部模型格式的数据副本。因此数据湖中被处理的数据可能是任意类型的信息从结构化数据到完全非结构化数据。
企业对数据湖寄予厚望希望它能帮助用户快速获取有用信息并能将这些信息用于数据分析和机器学习算法以获得与企业运行相关的洞察力。
数据湖可以包括:
来自关系数据库行和列的结构化数据
半结构化数据CSV日志XMLJSON
非结构化数据电子邮件文档PDF和二进制数据图像音频视频。
目前HDFS是最常用的部署数据湖的技术所以很多人会觉得数据湖就是HDFS集群。数据湖是一个概念而HDFS是用于实现这个概念的技术。
4.2.2 AWS对数据湖的定义
AWS定义数据湖是一个集中式存储库允许您以任意规模存储所有结构化和非结构化数据。
A data lake is a centralized repository that allows you to store all your structured and unstructured data at any scale. You can store your data as-is, without having to first structure the data, and run different types of analytics—from dashboards and visualizations to big data processing, real-time analytics, and machine learning to guide better decisions.
数据湖是一个集中式存储库允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据无需先对数据进行结构化处理并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习以指导做出更好的决策。
4.2.3 微软对数据湖的定义
微软的定义就更加模糊了并没有明确给出什么是Data Lake而是取巧的将数据湖的功能作为定义数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据并且可以跨平台、跨语言的做所有类型的分析和处理。
Azure的数据湖包括一切使得开发者、数据科学家、分析师能更简单的存储、处理数据的能力这些能力使得用户可以存储任意规模、任意类型、任意产生速度的数据并且可以跨平台、跨语言的做所有类型的分析和处理。数据湖在能帮助用户加速应用数据的同时消除了数据采集和存储的复杂性同时也能支持批处理、流式计算、交互式分析等。数据湖能同现有的数据管理和治理的IT投资一起工作保证数据的一致、可管理和安全。它也能同现有的业务数据库和数据仓库无缝集成帮助扩展现有的数据应用。Azure数据湖吸取了大量企业级用户的经验并且在微软一些业务中支持了大规模处理和分析场景包括Office 365, Xbox Live, Azure, Windows, Bing和Skype。Azure解决了许多效率和可扩展性的挑战作为一类服务使得用户可以最大化数据资产的价值来满足当前和未来需求。
4.2.4 数据湖定义小结
数据湖需要提供足够用的数据存储能力 这个存储保存了一个企业/组织中的所有数据。
数据湖可以存储海量的任意类型的数据 包括结构化、半结构化和非结构化数据。
数据湖中的数据是原始数据是业务数据的完整副本。数据湖中的数据保持了他们在业务系统中原来的样子。
数据湖需要具备完善的数据管理能力完善的元数据 可以管理各类数据相关的要素包括数据源、数据格式、连接信息、数据schema、权限管理等。
数据湖需要具备多样化的分析能力 包括但不限于批处理、流式计算、交互式分析以及机器学习同时还需要提供一定的任务调度和管理能力。
数据湖需要具备完善的数据生命周期管理能力。不光需要存储原始数据还需要能够保存各类分析处理的中间结果并完整的记录数据的分析处理过程能帮助用户完整详细追溯任意一条数据的产生过程。 数据湖需要具备完善的数据获取和数据发布能力。数据湖需要能支撑各种各样的数据源并能从相关的数据源中获取全量/增量数据然后规范存储。数据湖能将数据分析处理的结果推送到合适的存储引擎中满足不同的应用访问需求。
对于大数据的支持包括超大规模存储以及可扩展的大规模数据处理能力。
综上个人认为数据湖应该是一种不断演进中、可扩展的大数据存储、处理、分析的基础设施以数据为导向实现任意来源、任意速度、任意规模、任意类型数据的全量获取、全量存储、多模式处理与全生命周期管理并通过与各类外部异构数据源的交互集成支持各类企业级应用。
4.3 数据湖的处理架构
4.3.1 概述 数据湖引擎介于管理数据系统、分析可视化和数据处理工具之间。数据湖引擎不是将数据从数据源移动到单个存储库而是部署在现有数据源和数据使用者的工具(如BI工具和数据科学平台)之上。 BI分析工具如Tableau、Power BI、R、Python和机器学习模型是为数据生活在一个单一的、高性能的关系数据库中的环境而设计的。然而多数组织使用不同的数据格式和不同的技术在多种解决方案中管理他们的数据。多数组织现在使用一个或多个非关系型数据存储如云存储(如S3、ADLS)、Hadoop和NoSQL数据库(如Elasticsearch、Cassandra)。
当数据存储在一个独立的高性能关系数据库中时BI工具、数据科学系统和机器学习模型可以很好运用这部分数据。然而就像我们上面所说的一样数据这并不是存在一个地方。因此我们通常应用自定义ETL开发来集成来自不同系统的数据以便于我们后续分析。通常分析技术栈分为以下几类
ODS
数据从不同的数据库转移到单一的存储区域如云存储服务(如Amazon S3、ADLS)、HDFS。
数据仓库
虽然可以在Hadoop和云存储上直接执行SQL查询但是这些系统的设计目的并不是提供交互性能。因此数据的子集通常被加载到关系数据仓库或MPP数据库中也就是构建数据仓库。
数据集市
为了在大型数据集上提供交互性能必须通过在OLAP系统中构建多维数据集或在数据仓库中构建物化聚合表对数据进行预聚合
这种多层体系架构带来了许多挑战。例如 灵活性比如数据源的变化或新的数据需求必须重新访问数据仓库每一层以确保后续应用人员来使用可能会花费较长的实施周期。 复杂性数据分析人员必须了解所有存储数据的查询语法增加了不必要的复杂性。 技术成本该架构需要广泛的定制ETL开发、DBA专业知识和数据工程来满足业务中不断发展的数据需求。 基础设施成本该架构需要大量的专有技术并且通常会导致存储在不同系统中的数据产生许多副本。 数据治理该架构如果血缘关系搞的不好便使得跟踪、维护变得非常困难。 数据及时性在ETL的过程中需要时间所以一般数据是T-1的统计汇总。
数据湖引擎采用了一种不同的方法来支持数据分析。数据湖引擎不是将数据移动到单个存储库中而是在数据原本存储的地方访问数据并动态地执行任何必要的数据转换和汇总。此外数据湖引擎还提供了一个自助服务模型使数据使用者能够使用他们喜欢的工具(如Power BI、Tableau、Python和R)探索、分析数据而不用关心数据在哪存、结构如何。
有些数据源可能不适合分析处理也无法提供对数据的有效访问。数据湖引擎提供了优化数据物理访问的能力。有了这种能力可以在不改变数据使用者访问数据的方式和他们使用的工具的情况下优化各个数据集。
与传统的解决方案相比数据湖引擎使用多种技术使数据消费者能够访问数据并集成这些技术功能到一个自助服务的解决方案中。
数据湖可以认为是新一代的大数据基础设施。为了更好的理解数据湖的基本架构我们先来看看大数据基础设施架构的演进过程。
4.3.2 第一阶段-以Hadoop为代表的离线数据处理基础设施
数据湖可以认为是新一代的大数据基础设施。为了更好的理解数据湖的基本架构我们先来看看大数据基础设施架构的演进过程。
如下图所示Hadoop是以HDFS为核心存储以MapReduce简称MR为基本计算模型的批量数据处理基础设施。 围绕HDFS和MR产生了一系列的组件不断完善整个大数据平台的数据处理能力例如面向在线KV操作的HBase、面向SQL的HIVE、面向工作流的PIG等。同时随着大家对于批处理的性能要求越来越高新的计算模型不断被提出产生了Tez、Spark、Presto、Flink等计算引擎MR模型也逐渐进化成DAG模型。
DAG模型一方面增加计算模型的抽象并发能力对每一个计算过程进行分解根据计算过程中的聚合操作点对任务进行逻辑切分任务被切分成一个个的stage每个stage都可以有一个或者多个Task组成Task是可以并发执行的从而提升整个计算过程的并行能力
另一方面为减少数据处理过程中的中间结果写文件操作Spark、Presto等计算引擎尽量使用计算节点的内存对数据进行缓存从而提高整个数据过程的效率和系统吞吐能力。
4.3.3 第二阶段lambda架构
随着数据处理能力和处理需求的不断变化越来越多的用户发现批处理模式无论如何提升性能也无法满足一些实时性要求高的处理场景流式计算引擎应运而生例如Storm、Spark Streaming、Flink等。
然而随着越来越多的应用上线大家发现其实批处理和流计算配合使用才能满足大部分应用需求而对于用户而言其实他们并不关心底层的计算模型是什么用户希望无论是批处理还是流计算都能基于统一的数据模型来返回处理结果于是Lambda架构被提出如下图所示。 Lambda架构的核心理念是“流批一体”如上图所示整个数据流向自左向右流入平台。进入平台后一分为二一部分走批处理模式一部分走流式计算模式。无论哪种计算模式最终的处理结果都通过统一服务层对应用提供确保访问的一致性底层到底是批或流对用户透明。
4.3.4 第三阶段Kappa架构
Lambda架构虽然解决了应用读取数据的统一性问题但是“流批分离”的处理链路增大了研发的复杂性。因此有人就提出能不能用一套系统来解决所有问题。目前比较流行的做法就是基于流计算来做。流计算天然的分布式特征注定了他的扩展性更好。通过加大流计算的并发性加大流式数据的“时间窗口”来统一批处理与流式处理两种计算模式。 4.3.5 大数据基础设施架构小结
综上从传统的hadoop架构往lambda架构从lambda架构往Kappa架构的演进大数据平台基础架构的演进逐渐囊括了应用所需的各类数据处理能力大数据平台逐渐演化成了一个企业/组织的全量数据处理平台。当前的企业实践中除了关系型数据库依托于各个独立的业务系统其余的数据几乎都被考虑纳入大数据平台来进行统一的处理。
然而目前的大数据平台基础架构都将视角锁定在了存储和计算而忽略了对于数据的资产化管理这恰恰是数据湖作为新一代的大数据基础设施所重点关注的方向之一。
大数据基础架构的演进其实反应了一点在企业/组织内部数据是一类重要资产已经成为了共识为了更好的利用数据企业/组织需要对数据资产进行如下操作
进行长期的原样存储以便可回溯重放原始数据
进行有效管理与集中治理
提供多模式的计算能力满足处理需求
以及面向业务提供统一的数据视图、数据模型与数据处理结果。
数据湖就是在这个大背景下产生的除了有大数据平台所拥有的各类基础能力之外数据湖更强调对于数据的管理、治理和资产化能力。
落到具体的实现上数据湖需要包括一系列的数据管理组件包括 数据接入 数据搬迁 数据治理 数据质量管理 资产目录 访问控制 任务管理 任务编排 元数据管理等。
如下图所示给出了一个数据湖系统的参考架构。 对于一个典型的数据湖而言它与大数据平台相同的地方在于它也具备处理超大规模数据所需的存储和计算能力能提供多模式的数据处理能力增强点在于数据湖提供了更为完善的数据管理能力具体体现在
更强大的数据接入能力。
数据接入能力体现在对于各类外部异构数据源的定义管理能力以及对于外部数据源相关数据的抽取迁移能力抽取迁移的数据包括外部数据源的元数据与实际存储的数据。
更强大的数据管理能力。
管理能力具体又可分为基本管理能力和扩展管理能力 基本管理能力包括对各类元数据的管理、数据访问控制、数据资产管理是一个数据湖系统所必须的后面我们会在“各厂商的数据湖解决方案”一节相信讨论各个厂商对于基本管理能力的支持方式。 扩展管理能力包括任务管理、流程编排以及与数据质量、数据治理相关的能力。任务管理和流程编排主要用来管理、编排、调度、监测在数据湖系统中处理数据的各类任务通常情况下数据湖构建者会通过购买/研制定制的数据集成或数据开发子系统/模块来提供此类能力定制的系统/模块可以通过读取数据湖的相关元数据来实现与数据湖系统的融合。而数据质量和数据治理则是更为复杂的问题一般情况下数据湖系统不会直接提供相关功能但是会开放各类接口或者元数据供有能力的企业/组织与已有的数据治理软件集成或者做定制开发。
可共享的元数据。
数据湖中的各类计算引擎会与数据湖中的数据深度融合而融合的基础就是数据湖的元数据。
好的数据湖系统计算引擎在处理数据时能从元数据中直接获取数据存储位置、数据格式、数据模式、数据分布等信息然后直接进行数据处理而无需进行人工/编程干预。更进一步好的数据湖系统还可以对数据湖中的数据进行访问控制控制的力度可以做到“库表列行”等不同级别。
还有一点应该指出的是前面数据湖系统的参考架构图的集中式存储更多的是业务概念上的集中本质上是希望一个企业/组织内部的数据能在一个明确统一的地方进行沉淀。事实上数据湖的存储应该是一类可按需扩展的分布式文件系统大多数数据湖实践中也是推荐采用S3/OSS/OBS/HDFS等分布式系统作为数据湖的统一存储。
我们可以再切换到数据维度从数据生命周期的视角来看待数据湖对于数据的处理方式数据在数据湖中的整个生命周期如下图所示。理论上一个管理完善的数据湖中的数据会永久的保留原始数据同时过程数据会不断的完善、演化以满足业务的需要。 4.4 数据湖能给企业带来多种能力
数据湖能给企业带来多种能力例如能实现数据的集中式管理在此之上企业能挖掘出很多之前所不具备的能力。
另外数据湖结合先进的数据科学与机器学习技术能帮助企业构建更多优化后的运营模型也能为企业提供其他能力如预测分析、推荐模型等这些模型能刺激企业能力的后续增长。数据湖能从以下方面帮助到企业
实现数据治理data governance 通过应用机器学习与人工智能技术实现商业智能 预测分析如领域特定的推荐引擎 信息追踪与一致性保障 根据对历史的分析生成新的数据维度 有一个集中式的能存储所有企业数据的数据中心有利于实现一个针对数据传输优化的数据服务 帮助组织或企业做出更多灵活的关于企业增长的决策。
4.5 数据湖与数据仓库区别 4.5.1 概述
对于数据仓库与数据湖的不同之处你可以想象一下仓库和湖泊的区别仓库存储着来自特定来源的货物而湖泊的水来自河流、溪流和其他来源并且是原始数据。
数据仓库供应商包括AWS、Cloudera、IBM、谷歌、微软、甲骨文、Teradata、SAP、SnapLogic和Snowflake等。数据湖提供商包括AWS、谷歌、Informatica、微软、Teradata等。
4.5.2 数据湖保留全部的数据
存储范围
数据仓库开发期间大量的时间花费在分析数据源理解商业处理和描述数据。结果就是为报表设计高结构化的数据模型。这一过程大部分的工作就是来决定数据应不应该导入数据仓库。通常情况下如果数据不能满足指定的问题就不会导入到数据仓库。这么做是为了简化数据模型和节省数据存储空间。
相反数据湖保留所有的数据。不仅仅是当前正在使用的数据甚至不被用到的数据也会导进来。数据会一直被保存所有我们可以回到任何时间点来做分析。
因为数据湖使用的硬件与数据仓库的使用的不同使这种方法成为了可能。现成的服务器与便宜的存储相结合使数据湖扩展到TB级和PB级非常经济。
存储来源
数据仓库主要存储来自运营系统的大量数据
而数据湖则存储来自更多来源的数据包括来自企业的运营系统和其他来源的各种原始数据资产集。
4.5.3 数据湖支持所有数据类型
在储存方面上数据湖中数据为非结构化的所有数据都保持原始形式并且仅在分析时再进行转换。
数据仓库一般由从事务系统中提取的数据组成并由定量度量和描述它们的属性组成。诸如Web服务器日志传感器数据社交网络活动文本和图像等非传统数据源在很大程度上被忽略。这些数据类型的新用途不断被发现但是消费和存储它们可能是昂贵和困难的。
数据湖方法包含这些非传统数据类型。在数据湖中我们保留所有数据而不考虑源和结构。我们保持它的原始形式并且只有在我们准备好使用它时才会对其进行转换。这种方法被称为“读时模式”。
数据仓库则是捕获结构化数据并将其按模式组织。
4.5.4 适用人群
由于数据湖中的数据可能不准确并且可能来自企业运营系统之外的来源因此不是很适合普通的业务分析用户;数据湖更适合数据科学家和其他数据分析专家使用他们需要的非常庞大和多样化的数据集。
其他用户则可以使用更为结构化的数据视图如数据仓库来提供他们使用的数据数据仓库非常适用于月度报告等操作用途因为它具有高度结构化。
4.5.5 数据湖很容易适应变化
关于数据仓库的主要抱怨之一是需要多长时间来改变它们。在开发过程中花费大量时间来获得仓库的结构。一个好的仓库设计可以适应变化但由于数据加载过程的复杂性以及为简化分析和报告所做的工作这些更改必然会消耗一些开发人员资源并需要一些时间。
许多业务问题都迫不及待地让数据仓库团队适应他们的系统来回答问题。日益增长的对更快答案的需求促成了自助式商业智能的概念。
另一方面在数据湖中由于所有数据都以其原始形式存储并且始终可供需要使用它的人访问因此用户有权超越仓库结构以新颖方式探索数据并回答它们问题在他们的步伐。
如果一个探索的结果被证明是有用的并且有重复的愿望那么可以应用更正式的模式并且可以开发自动化和可重用性来帮助将结果扩展到更广泛的受众。如果确定结果无用则可以丢弃该结果并且不会对数据结构进行任何更改也不会消耗开发资源。
所以在架构方面
数据湖通常在存储数据之后定义架构使用较少的初始工作并提供更大的灵活性。
在数据仓库中存储数据之前定义架构。
4.5.6 数据湖支持快速洞察数据 最后的区别实际上是其他区别结果。由于数据湖包含所有数据和数据类型因为它使用户能够在数据转换清理和结构化之前访问数据从而使用户能够比传统数据仓库方法更快地获得结果。
但是这种对数据的早期访问是有代价的。通常由数据仓库开发团队完成的工作可能无法完成分析所需的部分或全部数据源。这让驾驶座位的用户可以根据需要探索和使用数据但上述第一层业务用户可能不希望这样做。他们仍然只想要他们的报告和KPI。
在数据湖中这些操作报告的使用者将利用更加结构化的数据湖中数据的结构视图这些视图与数据仓库中以前一直存在的数据相似。不同之处在于这些视图主要存在于位于湖泊中的数据之上的元数据而不是需要开发人员更改的物理刚性表格。
4.6 数据湖和数据仓库理解误区 误解一数据仓库和数据湖二者在架构上只能二选一
很多人认为数据仓库和数据湖在架构上只能二选一其实这种理解是错误的。数据湖和数据仓库并不是对立关系相反它们的并存可以互补给企业架构带来更多的好处
数据仓库存储结构化的数据适用于快速的BI和决策支撑
而数据湖可以存储任何格式的数据往往通过挖掘能够发挥出数据的更大作为。
所以在一些场景上二者的并存是可以给企业带来更多效益的。 误解二相对于数据湖数据仓库更有名更受欢迎
人工智能AI和机器学习项目的成功往往需要数据湖来做支撑。因为数据湖可让您存储几乎任何类型的数据而无需先准备或清理所以可以保留尽可能多的潜在价值。而数据仓库存储的数据都是经过清洗往往会丢失一些有价值的信息。
数据仓库虽然是这两种中比较知名的但是随着数据挖掘需求的发展数据湖的受欢迎程度可能会继续上升。数据仓库对于某些类型的工作负载和用例工作良好而数据湖则是为其他类型的工作负载提供服务的另一种选择。 误解三数据仓库易于使用而数据湖却很复杂
确实数据湖需要数据工程师和数据科学家的特定技能才能对存储在其中的数据进行分类和利用。数据的非结构化性质使那些不完全了解数据湖如何工作的人更难以访问它。
但是一旦数据科学家和数据工程师建立了数据模型或管道业务用户就可以利用建立的数据模型以及流行的业务工具定制或预先构建的来访问和分析数据而不在乎该数据存储在数据仓库中还是数据湖中。
4.7 数据湖建设的基本过程
个人认为数据湖是比传统大数据平台更为完善的大数据处理基础支撑设施完善在数据湖是更贴近客户业务的技术存在。所有数据湖所包括的、且超出大数据平台存在的特性例如元数据、数据资产目录、权限管理、数据生命周期管理、数据集成和数据开发、数据治理和质量管理等无一不是为了更好的贴近业务更好的方便客户使用。数据湖所强调的一些基本的技术特性例如弹性、存储计算独立扩展、统一的存储引擎、多模式计算引擎等等也是为了满足业务需求并且给业务方提供最具性价比的TCO。
数据湖的建设过程应该与业务紧密结合但是数据湖的建设过程与传统的数据仓库甚至是大热的数据中台应该是有所区别的。区别在于数据湖应该以一种更敏捷的方式去构建“边建边用边用边治理”。为了更好的理解数据湖建设的敏捷性我们先来看一下传统数仓的构建过程。业界对于传统数仓的构建提出了“自下而上”和“自顶而下”两种模式分别由Inmon和KimBall两位大牛提出。具体的过程就不详述了不然可以再写出几百页这里只简单阐述基本思想。
1Inmon提出自下而上EDW-DM的数据仓库建设模式即操作型或事务型系统的数据源通过ETL抽取转换和加载到数据仓库的ODS层ODS层中的数据根据预先设计好的EDW企业级数据仓库范式进行加工处理然后进入到EDW。EDW一般是企业/组织的通用数据模型不方便上层应用直接做数据分析因此各个业务部门会再次根据自己的需要从EDW中处理出数据集市层DM。
优势易于维护高度集成劣势结构一旦确定灵活性不足且为了适应业务部署周期较长。此类方式构造的数仓适合于比较成熟稳定的业务例如金融。
2KimBall提出自顶而下DM-DW的数据架构通过将操作型或事务型系统的数据源抽取或加载到ODS层然后通过ODS的数据利用维度建模方法建设多维主题数据集市DM。各个DM通过一致性的维度联系在一起最终形成企业/组织通用的数据仓库。
优势构建迅速最快的看到投资回报率敏捷灵活劣势作为企业资源不太好维护结构复杂数据集市集成困难。常应用于中小企业或互联网行业。
其实上述只是一个理论上的过程其实无论是先构造EDW还是先构造DM都离不开对于数据的摸底以及在数仓构建之前的数据模型的设计包括当前大热的“数据中台”都逃不出下图所示的基本建设过程。 1 数据摸底。
对于一个企业/组织而言在构建数据湖初始工作就是对自己企业/组织内部的数据做一个全面的摸底和调研包括数据来源、数据类型、数据形态、数据模式、数据总量、数据增量等。在这个阶段一个隐含的重要工作是借助数据摸底工作进一步梳理企业的组织结构明确数据和组织结构之间关系。为后续明确数据湖的用户角色、权限设计、服务方式奠定基础。
2 模型抽象。
针对企业/组织的业务特点梳理归类各类数据对数据进行领域划分形成数据管理的元数据同时基于元数据构建通用的数据模型。
3 数据接入。
根据第一步的摸排结果确定要接入的数据源。根据数据源确定所必须的数据接入技术能力完成数据接入技术选型接入的数据至少包括数据源元数据、原始数据元数据、原始数据。各类数据按照第二步形成的结果分类存放。
4 融合治理。
简单来说就是利用数据湖提供的各类计算引擎对数据进行加工处理形成各类中间数据/结果数据并妥善管理保存。数据湖应该具备完善的数据开发、任务管理、任务调度的能力详细记录数据的处理过程。在治理的过程中会需要更多的数据模型和指标模型。
5 业务支撑。
在通用模型基础上各个业务部门定制自己的细化数据模型、数据使用流程、数据访问服务。
上述过程对于一个快速成长的互联网企业来说太重了很多情况下是无法落地的最现实的问题就是第二步模型抽象很多情况下业务是在试错、在探索根本不清楚未来的方向在哪里也就根本不可能提炼出通用的数据模型没有数据模型后面的一切操作也就无从谈起这也是很多高速成长的企业觉得数据仓库/数据中台无法落地、无法满足需求的重要原因之一。
数据湖应该是一种更为“敏捷”的构建方式我们建议采用如下步骤来构建数据湖。 对比依然是五步但是这五步是一个全面的简化和“可落地”的改进。
1 数据摸底。
依然需要摸清楚数据的基本情况包括数据来源、数据类型、数据形态、数据模式、数据总量、数据增量。但是也就需要做这么多了。数据湖是对原始数据做全量保存因此无需事先进行深层次的设计。
2 技术选型。
根据数据摸底的情况确定数据湖建设的技术选型。事实上这一步也非常的简单因为关于数据湖的技术选型业界有很多的通行的做法基本原则个人建议有三个“计算与存储分离”、“弹性”、“独立扩展”。建议的存储选型是分布式对象存储系统如S3/OSS/OBS计算引擎上建议重点考虑批处理需求和SQL处理能力因为在实践中这两类能力是数据处理的关键关于流计算引擎后面会再讨论一下。无论是计算还是存储建议优先考虑serverless的形式后续可以在应用中逐步演进真的需要独立资源池了再考虑构建专属集群。
3 数据接入。
确定要接入的数据源完成数据的全量抽取与增量接入。
4 应用治理。
这一步是数据湖的关键我个人把“融合治理”改成了“应用治理”。从数据湖的角度来看数据应用和数据治理应该是相互融合、密不可分的。从数据应用入手在应用中明确需求在数据ETL的过程中逐步形成业务可使用的数据同时形成数据模型、指标体系和对应的质量标准。数据湖强调对原始数据的存储强调对数据的探索式分析与应用但这绝对不是说数据湖不需要数据模型恰恰相反对业务的理解与抽象将极大的推动数据湖的发展与应用数据湖技术使得数据的处理与建模保留了极大的敏捷性能快速适应业务的发展与变化。
从技术视角来看数据湖不同于大数据平台还在于数据湖为了支撑数据的全生命周期管理与应用需要具备相对完善的数据管理、类目管理、流程编排、任务调度、数据溯源、数据治理、质量管理、权限管理等能力。在计算能力上目前主流的数据湖方案都支持SQL和可编程的批处理两种模式对机器学习的支持可以采用Spark或者Flink的内置能力在处理范式上几乎都采用基于有向无环图的工作流的模式并提供了对应的集成开发环境。对于流式计算的支持目前各个数据湖解决方案采取了不同的方式。在讨论具体的方式之前我们先对流计算做一个分类
1 模式一实时模式。
这种流计算模式相当于对数据采用“来一条处理一条”/“微批”的方式进行处理多见于在线业务如风控、推荐、预警等。
2 模式二类流式。
这种模式需要获取指定时间点之后变化的数据/读取某一个版本的数据/读取当前的最新数据等是一种类流式的模式多见于数据探索类应用如分析某一时间段内的日活、留存、转化等。
二者的本质不同在于模式一处理数据时数据往往还没有存储到数据湖中仅仅是在网路/内存中流动模式二处理数据时数据已经存储到数据湖中了。综上我个人建议采用如下图模式 图24 数据湖数据流向示意图
如图24所示在需要数据湖具备模式一的处理能力时还是应该引入类Kafka中间件作为数据转发的基础设施。完整的数据湖解决方案方案应该提供将原始数据导流至Kafka的能力。流式引擎具备从类Kafka组件中读取数据的能力。流式计算引擎在处理数据过后根据需要可以将结果写入OSS/RDBMS/NoSQL/DW供应用访问。某种意义上模式一的流计算引擎并非一定要作为数据湖不可分割的一部分存在只需要在应用需要时能够方便的引入即可。但是这里需要指出的是
1流式引擎依然需要能够很方便的读取数据湖的元数据
2流式引擎任务也需要统一的纳入数据湖的任务管理
3流式处理任务依然需要纳入到统一的权限管理中。
对于模式二本质上更接近于批处理。现在许多经典的大数据组件已经提供了支持方式如HUDI/IceBerg/Delta等均支持Spark、Presto等经典的计算引擎。以HUDI为例通过支持特殊类型的表COW/MOR提供访问快照数据指定版本、增量数据、准实时数据的能力。目前AWS、腾讯等已经将HUDI集成到了其EMR服务中阿里云的DLA也正在计划推出DLA on HUDI的能力。
让我们再回到本文开头的第一章我们说过数据湖的主要用户是数据科学家和数据分析师探索式分析和机器学习是这类人群的常见操作流式计算实时模式多用于在线业务严格来看并非数据湖目标用户的刚需。但是流式计算实时模式是目前大多数互联网公司在线业务的重要组成部分而数据湖作为企业/组织内部的数据集中存放地需要在架构上保持一定的扩展能力可以很方便的进行扩展整合流式计算能力。
5 业务支撑。虽然大多数数据湖解决方案都对外提供标准的访问接口如JDBC市面上流行的各类BI报表工具、大屏工具也都可以直接访问数据湖中的数据。但是在实际的应用中我们还是建议将数据湖处理好的数据推送到对应的各类支持在线业务的数据引擎中去能够让应用有更好的体验。
4.8 主流厂商数据湖解决方案
4.8.1 AWS数据湖解决方案 整个方案基于AWS Lake Formation构建AWS Lake Formation本质上是一个管理性质的组件它与其他AWS服务互相配合来完成整个企业级数据湖构建功能。上图自左向右体现了数据流入、数据沉淀、数据计算、数据应用四个步骤。我们进一步来看其关键点
数据流入
数据流入是整个数据湖构建的起始包括元数据的流入和业务数据流入两个部分。
元数据流入包括数据源创建、元数据抓取两步最终会形成数据资源目录并生成对应的安全设置与访问控制策略。解决方案提供专门的组件获取外部数据源的相关元信息该组件能连接外部数据源、检测数据格式和模式schema并在对应的数据资源目录中创建属于数据湖的元数据。
业务数据的流入是通过ETL来完成的。
在具体的产品形式上元数据抓取、ETL和数据准备AWS将其单独抽象出来形成了一个产品叫AWS GLUE。AWS GLUE与AWS Lake Formation共享同一个数据资源目录在AWS GLUE官网文档上明确指出“Each AWS account has one AWS Glue Data Catalog per AWS region”。
对于异构数据源的支持。AWS提供的数据湖解决方案支持S3、AWS关系型数据库、AWS NoSQL数据库AWS利用GLUE、EMR、Athena等组件支持数据的自由流动。
数据沉淀
采用Amazon S3作为整个数据湖的集中存储按需扩展/按使用量付费。
数据计算
整个解决方案利用AWS GLUE来进行基本的数据处理。GLUE基本的计算形式是各类批处理模式的ETL任务任务的出发方式分为手动触发、定时触发、事件触发三种。不得不说AWS的各类服务在生态上实现的非常好事件触发模式上可以利用AWS Lambda进行扩展开发同时触发一个或多个任务极大的提升了任务触发的定制开发能力同时各类ETL任务可以通过CloudWatch进行很好的监控。
数据应用。
在提供基本的批处理计算模式之外AWS通过各类外部计算引擎来提供丰富的计算模式支持例如通过Athena/Redshift来提供基于SQL的交互式批处理能力通过EMR来提供各类基于Spark的计算能力包括Spark能提供的流计算能力和机器学习能力。
权限管理
AWS的数据湖解决方案通过Lake Formation来提供相对完善的权限管理粒度包括“库-表-列”。但是有一点例外的是GLUE访问Lake Formation时粒度只有“库-表”两级这也从另一个侧面说明GLUE和Lake Formation的集成是更为紧密的GLUE对于Lake Formation中的数据有更大的访问权限。
Lake Formation的权限进一步可以细分为数据资源目录访问权限和底层数据访问权限分别对应元数据与实际存储的数据。实际存储数据的访问权限又进一步分为数据存取权限和数据存储访问权限
数据存取权限类似于数据库中对于库表的访问权限
数据存储权限则进一步细化了对于S3中具体目录的访问权限分为显示和隐式两种。如下图所示用户A在只有数据存取的权限下无法创建位于S3指定bucket下的表。 个人认为这进一步体现了数据湖需要支持各种不同的存储引擎未来的数据湖可能不只S3/OSS/OBS/HDFS一类核心存储可能根据应用的访问需求纳入更多类型的存储引擎例如S3存储原始数据NoSQL存储处理过后适合以“键值”模式访问的数据OLAP引擎存储需要实时出各类报表/adhoc查询的数据。虽然当前各类材料都在强调数据湖与数据仓库的不同但是从本质上数据湖更应该是一类融合的数据管理思想的具体实现“湖仓一体化”也很可能是未来的一个发展趋势。
综上AWS数据湖方案成熟度高特别是元数据管理、权限管理上考虑充分打通了异构数据源与各类计算引擎的上下游关系让数据能够自由“移动”起来。
在流计算和机器学习上AWS的解决方案也比较完善
流计算方面AWS推出了专门的流计算组件KinesisKinesis中的Kinesis data Firehose服务可以创建一个完全被托管的数据分发服务通过Kinesis data Stream实时处理的数据可以借助Firehose方便的写入S3中并支持相应的格式转换如将JSON转换成Parquet格式。
AWS整个方案最牛的地方还在与Kinesis可以访问GLUE中的元数据这一点充分体现了AWS数据湖解决方案在生态上的完备性。
同样在机器学习方面AWS提供了SageMaker服务SageMaker可以读取S3中的训练数据并将训练好的模型回写至S3中。但是有一点需要指出的是在AWS的数据湖解决方案中流计算和机器学习并不是固定捆绑的只是作为计算能力扩展能方便的集成。
最后让我们回到数据湖组件参考架构看看AWS的数据湖解决方案的组件覆盖情况参见下图 AWS 数据湖解决方案在参考架构中的映射。 综上AWS的数据湖解决方案覆盖了除质量管理和数据治理的所有功能。其实质量管理和数据治理这个工作和企业的组织结构、业务类型强相关需要做大量的定制开发工作因此通用解决方案不囊括这块内容也是可以理解的。事实上现在也有比较优秀的开源项目支持这个项目比如Apache Griffin如果对质量管理和数据治理有强诉求可以自行定制开发。
4.8.2 华为数据湖解决方案 华为的数据湖解决方案相关信息来自华为官网。目前官网可见的相关产品包括数据湖探索Data Lake InsightDLI和智能数据湖运营平台DAYU
其中DLI相当于是AWS的Lake Formation、GLUE、Athena、EMRFlinkSpark的集合。官网上没找到关于DLI的整体架构图我根据自己的理解尝试画了一个主要是和AWS的解决方案有一个对比所以形式上尽量一致。
华为的数据湖解决方案比较完整DLI承担了所有的数据湖构建、数据处理、数据管理、数据应用的核心功能。DLI最大的特色是在于分析引擎的完备性包括基于SQL的交互式分析以及基于SparkFlink的流批一体处理引擎。在核心存储引擎上DLI依然通过内置的OBS来提供和AWS S3的能力基本对标。华为数据湖解决方案在上下游生态上做的比AWS相对完善对于外部数据源几乎支持所有目前华为云上提供的数据源服务。
DLI可以与华为的CDM云数据迁移服务和DIS数据接入服务对接1借助DISDLI可以定义各类数据点这些点可以在Flink作业中被使用做为source或者sink2借助CDMDLI甚至能接入IDC、第三方云服务的数据。
为了更好的支持数据集成、数据开发、数据治理、质量管理等数据湖高级功能华为云提供了DAYU平台。DAYU平台是华为数据湖治理运营方法论的落地实现。DAYU涵盖了整个数据湖治理的核心流程并对其提供了相应的工具支持甚至在华为的官方文档中给出了数据治理组织的构建建议。DAYU的数据治理方法论的落地实现如下图所示来自华为云官网。 可以看到本质上DAYU数据治理的方法论其实是传统数据仓库治理方法论在数据湖基础设施上的延伸从数据模型来看依然包括贴源层、多源整合层、明细数据层这点与数据仓库完全一致。根据数据模型和指标模型会生成质量规则和转换模型DAYU会和DLI对接直接调用DLI提供的相关数据处理服务完成数据治理。华为云整个的数据湖解决方案完整覆盖了数据处理的生命周期并且明确支持了数据治理并提供了基于模型和指标的数据治理流程工具在华为云的数据湖解决方案中逐渐开始往“湖仓一体化”方向演进。
4.8.3 阿里云数据湖解决方案
阿里云上数据类产品众多因为本人目前在数据BU所以本节方案将关注在如何使用数据库BU的产品来构建数据湖其他云上产品会略有涉及。阿里云的基于数据库产品的数据湖解决方案更加聚焦主打数据湖分析和联邦分析两个场景。阿里云数据湖解决方案如下图所示。 整个方案依然采用OSS作为数据湖的集中存储。在数据源的支持上目前也支持所有的阿里云数据库包括OLTP、OLAP和NoSQL等各类数据库。核心关键点如下
数据接入与搬迁。在建湖过程中DLA的Formation组件具备元数据发现和一键建湖的能力在本文写作之时目前“一键建湖”还只支持全量建湖但是基于binlog的增量建湖已经在开发中了预计近期上线。增量建湖能力会极大的增加数据湖中数据的实时性并将对源端业务数据库的压力降到最下。这里需要注意的是DLA Formation是一个内部组件对外并没有暴露。
数据资源目录。DLA提供Meta data catalog组件对于数据湖中的数据资产进行统一的管理无论数据是在“湖中”还是在“湖外”。Meta data catalog也是联邦分析的统一元数据入口。
在内置计算引擎上DLA提供了SQL计算引擎和Spark计算引擎两种。无论是SQL还是Spark引擎都和Meta data catalog深度集成能方便的获取元数据信息。基于Spark的能力DLA解决方案支持批处理、流计算和机器学习等计算模式。
在外围生态上除了支持各类异构数据源做数据接入与汇聚之外在对外访问能力上DLA与云原生数据仓库原ADB深度整合。一方面DLA处理的结果可之际推送至ADB中满足实时、交互式、ad hoc复杂查询另一方面ADB里的数据也可以借助外表功能很方便的进行数据回流至OSS中。基于DLA阿里云上各类异构数据源可以完全被打通数据自由流动。
在数据集成和开发上阿里云的数据湖解决方案提供两种选择一种是采用dataworks完成另一种是采用DMS来完成。无论是选择哪种都能对外提供可视化的流程编排、任务调度、任务管理能力。在数据生命周期管理上dataworks的数据地图能力相对更加成熟。
在数据管理和数据安全上DMS提供了强大的能力。DMS的数据管理粒度分为“库-表-列-行”完善的支持企业级的数据安全管控需求。除了权限管理之外DMS更精细的地方是把原来基于数据库的devops理念扩展到了数据湖使得数据湖的运维、开发更加精细化。
进一步细化整个数据湖方案的数据应用架构如下图所示。 自左向右从数据的流向来看数据生产者产生各类数据云下/云上/其他云利用各类工具上传至各类通用/标准数据源包括OSS/HDFS/DB等。针对各类数据源DLA通过数据发现、数据接入、数据迁移等能力完整建湖操作。对于“入湖”的数据DLA提供基于SQL和Spark的数据处理能力并可以基于Dataworks/DMS对外提供可视化的数据集成和数据开发能力在对外应用服务能力上DLA提供标准化的JDBC接口可以直接对接各类报表工具、大屏展示功能等。阿里云的DLA的特色在于背靠整个阿里云数据库生态包括OLTP、OLAP、NoSQL等各类数据库对外提供基于SQL的数据处理能力对于传统企业基于数据库的开发技术栈而言转型成本相对较低学习曲线比较平缓。
阿里云的DLA解决方案的另一个特色在于“基于云原生的湖仓一体化”。传统的企业级数据仓库在大数据时代的今天在各类报表应用上依然是无法替代的但是数仓无法满足大数据时代的数据分析处理的灵活性需求因此我们推荐数据仓库应该作为数据湖的上层应用存在即数据湖是原始业务数据在一个企业/组织中唯一官方数据存储地数据湖根据各类业务应用需求将原始数据进行加工处理形成可再次利用的中间结果当中间结果的数据模式Schema相对固定后DLA可以将中间结果推送至数据仓库供企业/组织开展基于数仓的业务应用。阿里云在提供DLA的同时还提供了云原生数仓原ADBDLA和云原生数仓在以下两点上深度融合。1 使用同源的SQL解析引擎。DLA的SQL与ADB的SQL语法上完全兼容这意味着开发者使用一套技术栈即能同时开发数据湖应用和数仓应用。
2 都内置了对于OSS的访问支持。OSS直接作为DLA的原生存储存在对于ADB而言可以通过外部表的能力很方便的访问OSS上的结构化数据。借助外部表数据可以自由的在DLA和ADB之间流转做到真正的湖仓一体。
DLAADB的组合真正做到了云原生的湖仓一体关于什么是云原生不在本文的讨论范畴。本质上DLA可以看成一个能力扩展的数据仓库贴源层。与传统数仓相比该贴源层
1可以保存各类结构化、半结构化和非结构化数据
2可以对接各类异构数据源
3具备元数据发现、管理、同步等能力
4内置的SQL/Spark计算引擎具备更强的数据处理能力满足多样化的数据处理需求
5具备全量数据的全生命周期管理能力。基于DLAADB的湖仓一体化方案将同时覆盖“大数据平台数据仓库”的处理能力。 DLA还有一个重要能力是构建了一个“四通八达”的数据流动体系并以数据库的体验对外提供能力无论数据在云上还是云下无论数据在组织内部还是外部借助数据湖各个系统之间的数据不再存在壁垒可以自由的流进流出更重要的是这种流动是受监管的数据湖完整的记录了数据的流动情况。
4.8.4 Microsoft Azure数据湖解决方案
Azure的数据湖解决方案包括数据湖存储、接口层、资源调度与计算引擎层如下图所示来自Azure官网。
存储层是基于Azure object Storage构建的依然是对结构化、半结构化和非结构化数据提供支撑。
接口层为WebHDFS比较特别的是在Azure object Storage实现了HDFS的接口Azure把这个能力称为“数据湖存储上的多协议存取”。
在资源调度上Azure基于YARN实现。
计算引擎上Azure提供了U-SQL、hadoop和Spark等多种处理引擎。 Azure的特别之处是基于visual studio提供给了客户开发的支持。
开发工具的支持 与visual studio的深度集成Azure推荐使用U-SQL作为数据湖分析应用的开发语言。Visual studio为U-SQL提供了完备的开发环境同时为了降低分布式数据湖系统开发的复杂性visual studio基于项目进行封装在进行U-SQL开发时可以创建“U-SQL database project”在此类项目中利用visual studio可以很方便的进行编码与调试同时也提供向导将开发好的U-SQL脚本发布到生成环境。U-SQL支持Python、R进行扩展满足定制开发需求。
多计算引擎的适配SQL, Apache Hadoop和Apache Spark。这里的hadoop包括Azure提供的HDInsightAzure托管的Hadoop服务Spark包括Azure Databricks。- 多种不同引擎任务之间的自动转换能力。微软推荐U-SQL为数据湖的缺省开发工具并提供各类转换工具支持U-SQL脚本与Hive、SparkHDSightdatabricks、Azure Data Factory data Flow之间的转化。
4.8.5 小结
本文所讨论的是数据湖的解决方案不会涉及到任何云厂商的单个产品。我们从数据接入、数据存储、数据计算、数据管理、应用生态几个方面简单做了一个类似下表的总结。 出于篇幅关系其实知名云厂商的数据湖解决方案还有谷歌和腾讯的。这两家从其官方网站上看数据湖解决方案相对来讲比较简单也仅仅是一些概念上的阐述推荐的落地方案是“osshadoopEMR”。其实数据湖不应该从一个简单的技术平台视角来看实现数据湖的方式也多种多样评价一个数据湖解决方案是否成熟关键应该看其提供的数据管理能力具体包括但不限于元数据、数据资产目录、数据源、数据处理任务、数据生命周期、数据治理、权限管理等以及与外围生态的对接打通能力。
4.9 典型的数据湖应用案例
4.9.1 广告数据分析
近年来流量获取的成本就越来越高线上渠道获客成本的成倍增长让各行各业都面临着严峻的挑战。在互联网广告成本不断攀升的大背景下以花钱买流量拉新为主要的经营策略必然行不通了。流量前端的优化已成强弩之末利用数据工具提高流量到站后的目标转化精细化运营广告投放的各个环节才是改变现状更为直接有效的方式。说到底要提高广告流量的转化率必须依靠大数据分析。
为了能够提供更多的决策支撑依据需要采取更多的埋点数据的收集和分析包括但不限于渠道、投放时间、投放人群以点击率为数据指标进行数据分析从而给出更好的、更迅速的方案和建议实现高效率高产出。因此面对广告投放领域多维度、多媒体、多广告位等结构化、半结构化和非结构化数据采集、存储、分析和决策建议等要求数据湖分析产品解决方案在广告主或者发布商进行新一代技术选型中上受到了很热烈的青睐。
DG是一家全球领先的企业国际化智能营销服务商基于先进的广告技术、大数据和运营能力为客户提供全球高质量用户获取及流量变现服务。DG从成立之初就决定以公有云为基础来构建其IT基础设施最初DG选择了AWS云平台主要将其广告数据在S3中以数据湖的形态进行存放通过Athena进行交互式分析。然而随着互联网广告的飞速发展广告行业带来了几大挑战移动广告的发布与追踪系统必须解决几个关键问题
1 并发性与峰值问题。在广告行业流量高峰时常出现瞬间的点击量可能达到数万甚至数十万这就要求系统具备非常好的可扩展性以快速响应和处理每一次点击
2 如何实现对海量数据的实时分析。为了监控广告投放效果系统需要实时对用户的每一次点击和激活数据进行分析同时把相关数据传输到下游的媒体
3 平台的数据量在急剧增长每天的业务日志数据在持续的产生和上传曝光、点击、推送的数据在持续处理每天新增的数据量已经在10-50TB左右对整个数据处理系统提出了更高的要求。如何高效地完成对广告数据的离线/近实时统计按照广告客户的维度要求进行聚合分析。
针对上述三点业务挑战同时DG这个客户日增量数据正在急剧变大当前日数据扫描量达到100TB继续在AWS平台使用遇到Athena读取S3数据带宽瓶颈、数据分析滞后时间越来越长、为应对数据和分析需求增长而急剧攀升的投入成本等经过认真、仔细的测试和分析最终决定从AWS云平台全量搬站到阿里云平台新架构图如下 图16. 改造后的广告数据湖方案架构
从AWS搬站到阿里云后我们为该客户设计了“利用Data Lake Analytics OSS”极致分析能力来应对业务波峰波谷。一方面轻松应对来自品牌客户的临时分析。另一方面利用Data Lake Analytics的强大计算能力分析按月、季度广告投放精确计算出一个品牌下面会有多少个活动每个活动分媒体分市场分频道分DMP的投放效果进一步增强了加和智能流量平台为品牌营销带来的销售转化率。并且在广告投放与分析的总拥有成本上Data Lake Analytics提供的Serverless的弹性服务为按需收费不需要购买固定的资源完全契合业务潮汐带来的资源波动满足弹性的分析需求同时极大地降低了运维成本和使用成本。 图17 数据湖部署示意图
总体上DG从AWS切换到阿里云后极大地节省了硬件成本、人力成本和开发成本。由于采用DLA serverless云服务DG无需先期投入大量的资金去购买服务器、存储等硬件设备也无需一次性购买大量的云服务其基础设施的规模完全是按需扩展需求高的时候增加服务数量需求减少的时候减少服务数量提高了资金的利用率。使用阿里云平台带来的第二个显著好处是性能的提升。在DG业务的快速增长期以及后续多条业务线接入期DG在移动广告系统的访问量经常呈爆发式增长然而原先AWS方案和平台在Athena读取S3数据遇到数据读取带宽的极大瓶颈数据分析的时间变得越来越长阿里云DLA联合OSS团队等进行了极大的优化和改造同时DLA数据库分析在计算引擎上与TPC-DS打榜世界第一的AnalyticDB共享计算引擎比Presto原生计算引擎的能力提升数十倍性能也极大的为DG提升了分析性能。
广告时间给管理者的未来商业课 4.9.2 游戏运营分析
数据湖是一类TCO表现极其优秀的大数据基础设施。对于很多快速增长的游戏公司而言一个爆款游戏往往在短期内相关数据增长极快同时公司的研发人员的技术栈很难在短期内与数据的增量和增速进行匹配此时呈爆发增长的数据很难被有效利用。数据湖是一个解决此类问题的技术选择。
YJ是一家高速成长的游戏公司公司希望能依托相关用户行为数据进行深入分析指导游戏的开发和运营。数据分析背后的核心逻辑在于随着游戏行业市场竞争局面的扩大玩家对于品质的要求越来越高游戏项目的生命周期越来越短直接影响项目的投入产出比通过数据运营则可以有效的延长项目的生命周期对各个阶段的业务走向进行精准把控。而随着流量成本的日益上升如何构建经济、高效的精细化数据运营体系以更好的支撑业务发展也变得愈发重要起来。数据运营体系就需要有其配套的基础支撑设施如何选择这类基础支撑设施是公司技术决策者需要思考的问题。思考的出发点包括
1 要有足够的弹性。对于游戏而言往往就是短时间爆发数据量激增因此能否适应数据的爆发性增长满足弹性需求是一个重点考量的点无论是计算还是存储都需要具备足够的弹性。
2 要有足够的性价比。对于用户行为数据往往需要拉到一个很长的周期去分析去对比比如留存率不少情况下需要考虑90天甚至180天客户的留存率因此如何以最具性价比的方式长期存储海量数据是需要重点考虑的问题。
3 要有够用的分析能力且具备可扩展性。许多情况下用户行为体现在埋点数据中埋点数据又需要与用户注册信息、登陆信息、账单等结构化数据关联分析因此在数据分析上至少需要有大数据的ETL能力、异构数据源的接入能力和复杂分析的建模能力。
4 要与公司现有技术栈相匹配且后续利于招聘。对于YJ其在技术选型的时候一个重要点就是其技术人员的技术栈YJ的技术团队大部分只熟悉传统的数据库开发即MySQL并且人手紧张做数据运营分析的技术人员只有1个短时间内根本没有能力独立构建大数据分析的基础设施。从YJ的角度出发最好绝大多数分析能够通过SQL完成并且在招聘市场上SQL开发人员的数量也远高于大数据开发工程师的数量。针对客户的情况我们帮助客户对现有方案做了改造。 图18. 改造前的方案
改造前客户所有的结构化数据都在一个高规格的MySQL里面而玩家行为数据则是通过LogTail采集至日志服务SLS中然后从日志服务中分别投递到OSS和ES里。这个架构的问题在于1行为数据和结构化数据完全割裂无法联动分析2对于行为数据智能提供检索功能无法做深层次的挖掘分析3OSS仅仅作为数据存储资源使用并没有挖掘出足够的数据价值。
事实上我们分析客户现存架构其实已经具备了数据湖的雏形全量数据已经在OSS中保存下来了现在需要进一步补齐客户对于OSS中的数据的分析能力。而且数据湖基于SQL的数据处理模式也满足客户对于开发技术栈的需求。综上我们对客户的架构做了如下调整帮助客户构建了数据湖。 图19. 改造后的数据湖解决方案
总体上我们没有改变客户的数据链路流转只是在OSS的基础上增加了DLA组件对OSS的数据进行二次加工处理。DLA提供了标准SQL计算引擎同时支持接入各类异构数据源。基于DLA对OSS的数据进行处理后生成业务直接可用的数据。但是DLA的问题在于无法支撑低延迟需求的交互式分析场景为了解决这个问题我们引入了云原生数据仓库ADB来解决交互式分析的延迟性问题同时在最前端引入QuickBI作为客户的可视化分析工具。YJ方案是图14所示的湖仓一体化解决方案在游戏行业的一个经典落地案例。
YM是一家数据智能服务提供商面向各类中小商家提供一系列数据分析运营服务。具体实现的技术逻辑如下图所示。 图20. YM智能数据服务SaaS模式示意
平台方提供多端SDK供用户商家提供网页、APP、小程序等多种接入形式接入各类埋点数据平台方以SaaS的形式提供统一的数据接入服务和数据分析服务。商家通过访问各类数据分析服务来进行更细粒度的埋点数据分析完成行为统计、客户画像、客户圈选、广告投放监测等基本分析功能。然而这种SaaS模式下会存在一定的问题
1 由于商家类型和需求的多样化平台提供SaaS类分析功能很难覆盖所有类型的商家无法满足商家的定制化需求如有些商家关注销量有些关注客户运营有些关注成本优化很难满足所有的需求。
2 对于一些高级分析功能如依赖于自定义标签的客户圈选、客户自定义扩展等功能统一的数据分析服务无法满足的特别是一些自定义的标签依赖于商家自定义的算法无法满足客户的高级分析需求。
3 数据的资产化管理需求。在大数据时代数据是一个企业/组织的资产已经成为了大家的共识如何能让属于商家的数据合理、长期的沉淀下来也是SaaS服务需要考虑的事情。
综上我们在上图的基本模式上引入了数据湖模式让数据湖作为商家沉淀数据、产出模型、分析运营的基础支撑设施。引入数据湖后的SaaS数据智能服务模式如下。 图21. 基于数据湖的数据智能服务
如图21所示平台方为每个用户提供一键建湖服务商家使用该功能构建自己的数据湖“一键建湖”能力一方面帮助商家将所有埋点数据的数据模型schema同步至数据湖中另一方面将属于该商家的所有埋点数据全量同步至数据湖中并基于“T1”的模式将每天的增量数据归档入湖。基于数据湖的服务模式在传统的数据分析服务的基础上赋予了用户数据资产化、分析模型化和服务定制化三大能力
1 数据资产化能力。利用数据湖商家可以将属于自己的数据持续沉淀下来保存多长时间的数据耗费多少成本完全由商家自主决定。数据湖还提供了数据资产管理能力商家除了能管理原始数据外还能将处理过的过程数据和结果数据分门别类保存极大的提升了埋点数据的价值。
2 分析模型化能力。数据湖中不仅仅有原始数据还有埋点数据的模型schema。埋点数据模型体现了全域数据智能服务平台对于业务逻辑的抽象通过数据湖除了将原始数据作为资产输出外还将数据模型进行了输出借助埋点数据模型商家可以更深入的理解埋点数据背后所体现的用户行为逻辑帮助商家更好的洞察客户行为获取用户需求。
3 服务定制化能力。借助数据湖提供的数据集成和数据开发能力基于对埋点数据模型的理解商家可以定制数据处理过程不断对原始数据进行迭代加工从数据中提炼有价值的信息最终获得超越原有数据分析服务的价值。
4.10 LakeHouse 4.11 数据湖总结
数据湖作为新一代大数据分析处理的基础设施需要超越传统的大数据平台。个人认为目前在以下方面是数据湖解决方案未来可能的发展方向。
云原生架构
关于什么是云原生架构众说纷纭很难找到统一的定义。但是具体到数据湖这个场景个人认为就是以下三点特征
存储和计算分离计算能力和存储能力均可独立扩展
多模态计算引擎支持SQL、批处理、流式计算、机器学习等
提供serverless态服务确保足够的弹性以及支持按需付费。
足够用的数据管理能力
数据湖需要提供更为强大的数据管理能力包括但不限于数据源管理、数据类目管理、处理流程编排、任务调度、数据溯源、数据治理、质量管理、权限管理等。
大数据的能力数据库的体验
目前绝大多数数据分析人员都只有数据库的使用经验大数据平台的能力虽强但是对于用户来说并不友好数据科学家和数据数据分析师应该关注数据、算法、模型及其与业务场景的适配而不是花大量的时间精力去学习大数据平台的开发。
数据湖要想快速发展如何为用户提供良好的使用体验是关键。基于SQL的数据库应用开发已经深入人心如何将数据湖的能力通过SQL的形式释放出来是未来的一个主要方向。
完善的数据集成与数据开发能力
对各种异构数据源的管理与支持对异构数据的全量/增量迁移支持对各种数据格式的支持都是需要不断完善的方向。同时需要具备一个完备的、可视化的、可扩展的集成开发环境。
与业务的深度融合与集成
典型数据湖架构的构成基本已经成为了业界共识分布式对象存储多模态计算引擎数据管理。
决定数据湖方案是否胜出的关键恰恰在于数据管理无论是原始数据的管理、数据类目的管理、数据模型的管理、数据权限的管理还是处理任务的管理都离不开与业务的适配和集成未来会有越来越多的行业数据湖解决方案涌现出来与数据科学家和数据分析师形成良性发展与互动。如何在数据湖解决方案中预置行业数据模型、ETL流程、分析模型和定制算法可能是未来数据湖领域差异化竞争的一个关键点。
5.1 基础概念
5.1.1 产生的背景
企业在过去信息化的历程中形成了大量生产经营及专业业务应用成果同时也累积了大量的企业数据资产。限于传统的数据仓库技术手段数据管理和分析能力成为信息化工作中的短板。
企业信息系统众多系统管理独立数据存储分散横向的数据共享和分析应用仅由具体业务驱动难以对全局数据开展价值挖掘从规模上和效果上都无法真正体现集团庞大数据资产的价值。
市场竞争和产业链日益全球化企业不只满足于内部数据的分析更要通过互联网、微信、APP等新技术手段结合外部市场数据进行整体分析。
传统的数据仓库不能满足数据分析需求 企业在数据分析应用方面呈现“五大转变”从统计分析向预测分析转变、从单领域分析向跨领域转变、从被动分析向主动分析转变、从非实时向实时分析转变、从结构化数据向多元化转变并且对统一的数据中台平台诉求强烈对数据中台的运算能力、核心算法、及数据全面性提出了更高的要求。
数据中台的处理架构发生了变化
传统的数据仓库集成处理架构是ETL结构这是构建数据仓库的重要一环即用户从数据源抽取出所需的数据经过数据清洗将数据加载到数据仓库中去。
而大数据背景下的架构体系是ELT结构其根据上层的应用需求随时从数据中台中抽取想要的原始数据进行建模分析。
一是以Hadoop、Spark等分布式技术和组件为核心的“计算存储混搭”的数据处理架构能够支持批量和实时的数据加载以及灵活的业务需求。
二是数据的预处理流程正在从传统的ETL结构向ELT转变
5.1.2 阿里集团为什么要建立一个“大中台、小前台“
我们从阿里共享业务事业部的发展史说起。起初阿里只有一个淘宝事业部后来成立了天猫事业部此时淘宝的技术团队同时支撑着这两个事业部。当时的淘宝和天猫的电商系统像我们很多大型企业的一样是分为两套独立的烟囱式体系两套体系中都包含的有商品、交易、支付、评价、物流等功能。因为上述原因阿里集团又成立了共享业务事业部其成员主要来自之前的淘宝技术团队同时将两套电商业务做了梳理和沉淀
中台其实就是一个共享服务的体系结构。
我们需要在日常的开发过程中将通用的服务抽离出来做到共享服务的体系结构当中。大中台小前台的体系结构可以使得管理更加高效小团队更加扁平化。
由于资源的共享可以让开发更加敏捷更能够知道需要做什么该怎么做
通过抽象各条业务线把共用的服务抽象出来共享不限于用户、订单等基础模块服务还包括具体的业务的抽象比如教育培训相关的课程、讲师、学员等服务通过抽象并以微服务的形式实现避免重复投入资源造轮子。
5.1.3 中台目标
首先、把当前系统中各个业务的前端应用与后端服务解耦。将各个功能中的服务能力进行梳理、并沉淀。例如我们从外呼业务中梳理出工单管理和问卷管理的能力从知识库中梳理出知识搜索的能力从85电商平台中梳理出商品销售和库存管理的能力等等。
其次、将重复、类似的服务进行整合。同时在单个服务的完善和增强的过程中注意服务的通用性避免其他相似“双胞胎”服务的出现。
最后由于服务能力的集中管控很大程度会促进我们一体化运维的能力但在“大中台、小前台”的模式下每一个服务都负责对N多个前端业务应用提供支持这就要求运维在信息安全、备份、监控等方面要有更强的能力。
5.1.4 中台分类
甄别是不是中台还要回到中台要解决的问题上一切以“以用户为中心的持续规模化创新”为目的将后台各式各样的资源转化为前台易于使用的能力帮助我们打赢这场以用户为中心的战争的平台我们都可以称之为中台
业务中台提供重用服务 例如用户中心订单中心之类的开箱即用可重用能力为战场提供了强大的后台炮火支援能力随叫随到威力强大
数据中台提供了数据分析能力 帮助我们从数据中学习改进调整方向为战场提供了强大及时的雷达监测能力帮助我们掌控战场
移动及算法中台提供了战场一线火力支援能力 帮助我们提供更加个性化的服务增强用户体验为战场提供了陆军支援能力随机应变所向披靡
技术中台提供了自建系统部分的技术支撑能力 帮助我们解决了基础设施分布式数据库等底层技术问题为前台特种兵提供了精良的武器装备
研发中台提供了自建系统部分的管理和技术实践支撑能力 帮助我们快速搭建项目管理进度测试持续集成持续交付是前台特种兵的训练基地及快速送达战场的机动运输部队
组织中台为我们的项目提供投资管理、风险管理、资源调度等 是战场的指挥部战争的大脑指挥前线调度后方。
所以评判一个平台是否称得上中台最终评判标准不是技术也不是长什么模样最终还是得前台说了算毕竟前台才是战争的关键才是感受得到战场的残酷、看得见用户的那部分人。
5.2 数据中台和数仓的关系
5.2.1 传统数仓
传统数仓有几个特点
数据具有历史性
基于文件存储
以表为形态自带元数据存储比如Hive
在数仓的数据是其他原始数据的拷贝或者拷贝的加工 传统数仓需要拷贝数据的重要原因是数据计算和数据存储需要尽可能的近。所以我们需要把MySQL等数据源的数据同步到数仓才能进行进一步处理。这里有点疑问我觉得是因为需要直接对数仓数据进行离线操作而不是对业务数据库进行繁重的操作也就是说数据分析不能影响业务
另外传统数仓更关注的是数据的历史状态所以导致数据规模庞大。数仓本身也具备计算能力同时也可以作为存储供其他计算系统使用。
5.2.2 数据中台
数据中台概念不同于数据平台。数据中台业务侧包含 数据触手(埋点) 数据接入(标准化) 数据仓库(抽象化) 数据治理(可靠性) 数据服务(产品化)
整体是一个闭环的解决方案 其中闭环是最重要的一点。
数据服务接口
数据中台设计立足点本身是数据计算和存储分离的。那就意味着数据中台本身并没有数据数据来源是其他地方比如传统数仓、业务数据库、用户在中台上传的文件临时使用、各个业务系统的API(瞬时我们不关心API之前的数据结果是什么样的)。因为数据中台拥有这些数据源的适配器所以相当于建立了互联管道。
关于元数据
我们知道数仓的优势是有元数据通过表的方式很好的规整了数据。数据需要加工所以一般数仓是有分层的往上走一层数据信息损耗就高一些。
数据中台也有一个全局的元数据管理系统管理也是以表为主粒度到字段级别。数据中台这个元信息包含了各个子存储的元信息以数据中台需要的形态进行组织。
数据地图
数据中台的元数据其中承载的一个重要功能是数据地图虽然在数据中台中修建了通往所有数据的道路但是当用户进来的时候无法知道具体某个数据的地址也就没办法利用这些修好的道路。
数据地图就是解决这个问题 我们需要结合自然语言处理检索技术目录分类技术机器学习以及数据规范化来帮助找到数据地址。数据地址从来都不是面向人类友好的。
通过数据中台的数据地图以及数据中台到各数据源的建立好的管道那么我们就可以很好的找到我们要的数据以及对他们进行关联和处理分析甚至进一步成为机器学习的素材。
数据地图和传统数仓元数据的区别在于
它记录了散落在各个孤岛的数据而不像传统数仓只是在自己的数据。
数据格式是异构的不仅仅是文件或表。
他不仅仅存储表以及字段相关信息同时还让这些信息可检索可查询可以更好的面向人而不是机器。
5.2.3 结论
数仓是数据中台的一个重要组成部分也是元数据的一个重要来源但是随着技术的发展数据计算和存储必定是分离的这就需要一个新的元信息系统数据地图来进行承载。
5.3 数据中台建设是数字化转型的支撑
数据中台成为热点“中台”这个概念是相对于前台和后台而生是前台和后台的链接点将业务共同的工具和技术予以沉淀。数据中台是指数据采集交换、共享融合、组织处理、建模分析、管理治理和服务应用于一体的综合性数据能力平台在大数据生态中处于承上启下的功能提供面向数据应用支撑的底座能力。
广义上来给数据中台一个企业级的定义“聚合和治理跨域数据将数据抽象封装成服务提供给前台以业务价值的逻辑概念”。 中台战略核心是数据服务的共享。中台战略并不是搭建一个数据平台但是中台的大部分服务都是围绕数据而生数据中台是围绕向上层应用提供数据服务构建的中台战略让数据在数据平台和业务系统之间形成了一个良性的闭环也就是实现应用与数据之间解藕并实现紧密交互。
5.4 公司平台分层与大中台小前台战略
5.4.1 互联网巨头“大中台小前台”战略
阿里巴巴在2015年12月进行组织升级就是“大中台小前台”的模式。主要的思路是打破原来树状结构小前台距离一线更近业务全能这样便于快速决策、敏捷行动支持类的业务放在中台扮演平台支撑的角色。
其实这个最早由阿里在2015年提出的“大中台小前台”战略中延伸出来的概念灵感来源于一家芬兰的小公司Supercell——一家仅有300名员工却接连推出爆款游戏是全球最会赚钱的明星游戏公司:
这家看似很小的公司设置了一个强大的技术平台来支持众多的小团队进行游戏研发。这样一来他们就可以专心创新不用担心基础却又至关重要的技术支撑问题。恰恰是这家小公司开创了中台的“玩法”并将其运用到了极致。对于这种多项目并行各项目相对独立但业务需求所需要的支持类似的公司“中台”就有存在的价值。
这种类似的思维应用到大企业中就是需要一个资源整合和能力沉淀的平台对不同的部门进行总协调和支持“中台”也就应运而生。
中台战略是构建符合DT时代的更具备创新性和灵活性的组织机制和业务机制实现管理模式的创新。将公共的业务、数据、技术等公共能力从前台下沉成为独立的中台并且通过组织结构的调整物理拆分为独立的中台部门。
大中台小前台”适用场景
不适合初创公司初创公司的初创阶段没有任何的公共资源的积累没有下沉为中台的内容。初创公司的首要任务是积累所有资源活下来快速迭代主要业务保存自己和核心竞争力。
适合高速发展公司或者快速成长公司。有一定的公共资源的积累公共部分下沉为中台保其高可用高性能为前端业务百花齐放快速迭代提供坚实的后盾。
推荐书籍 5.4.2 公司平台分层
5.4.2.1 概述
阿里组织架构业务中台、数据中台、技术中台公共组成中台。 前台
由各类前台系统组成的前端平台。每个前台系统就是一个用户触点即企业的最终用户直接使用或交互的系统是企业与最终用户的交点。例如用户直接使用的网站手机 app微信公众号等都属于前台范畴。
中台
“中台”的设置就是为了提炼各个业务条线的共性需求并将这些打造成组件化的资源包然后以接口的形式提供给前台各业务部门使用可以使产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷最大限度地减少“重复造轮子”的KPI项目。
“前台”要做什么业务需要什么资源可以直接同公共服务部要。搜索、共享组件、数据技术等模块不需要每次去改动底层进行研发而是在底层不变动的情况下在更丰富灵活的“大中台”基础上获取支持让“小前台”更加灵活敏捷。
后台
由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源数据计算例如财务系统产品系统客户管理系统仓库物流管理系统等这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源也属于后台的一部分。后台并不为前台而生
另外由于后台往往并不能很好的支撑前台快速创新响应用户的需求后台更多解决的是企业管理效率问题而中台要解决的才是前台的创新问题。
5.4.2.2 敏捷前台/小前台
一线作战单元强调敏捷交互及稳定交付的组织能力建设。
对于阿里来说小前台就是各个业务部门个性化的各种前台服务例如阿里的天猫、淘宝、河马、支付宝等一系列的品牌。
5.4.2.3 业务中台
能力固化与赋能固化通用能力赋能前线部队提升配置效率加快前线响应产品化业务化开辟全新生态。
具体来说业务中台对应公司的公共基础业务和通用服务例如短信中心、用户中心、支付中心交易中心、搜索服务等。下图中的公共逻辑层就是业务中台。 5.4.2.4 技术中台
技术中台主要负责基础服务、基础组件、基础平台、存储体系、云平台、运维相关等技术支撑。 5.4.2.5 数据中台
负责大数据统计分析相关的DaaS数据即服务和PaaS平台即服务相关服务建设资产整合与共享整合多维数据统一资产管理连通数据孤岛共享数据资源深入挖掘数据盘活资产价值。 5.4.2.6 稳定后台
以共享中心建设为核心为前中台提供专业的内部服务支撑。
5.5 数据中台定义及处理架构
数据中台是指通过企业内外部多源异构的数据采集、治理、建模、分析应用使数据对内优化管理提高业务对外可以数据合作价值释放成为企业数据资产管理中枢。数据中台建立后会形成数据API为企业和客户提供高效各种数据服务。 数据中台整体技术架构上采用云计算架构模式将数据资源、计算资源、存储资源充分云化并通过多租户技术进行资源打包整合并进行开放为用户提供“一站式”数据服务。
利用大数据技术对海量数据进行统一采集、计算、存储并使用统一的数据规范进行管理将企业内部所有数据统一处理形成标准化数据挖掘出对企业最有价值的数据构建企业数据资产库提供一致的、高可用大 数据服务。
数据中台不是一套软件也不是一个信息系统而是一系列数据组件的集合企业基于自身的信息化建设基础、数据基础以及业务特点对数据中台的能力进行定义基于能力定义利用数据组件搭建自己的数据中台。
5.6 数据中台带来价值
数据中台对一个企业的数字化转型和可持续发展起着至关重要的作用。数据中台为解耦而生企业建设数据中台的最大意义就是应用与数据解藕。这样企业就可以不受限制地按需构建满足业务需求的数据应用。
构建了开放、灵活、可扩展的企业级统一数据管理和分析平台 将企业内、外部数据随需关联打破了数据的系统界限。
利用大数据智能分析、数据可视化等技术实现了数据共享、日常报表自动生成、快速和智能分析满足集团总部和各分子公司各级数据分析应用需求。
深度挖掘数据价值助力企业数字化转型落地。实现了数据的目录、模型、标准、认责、安全、可视化、共享等管理实现数据集中存储、处理、分类与管理建立大数据分析工具库、算法服务库实现报表生成自动化、数据分析敏捷化、数据挖掘可视化实现数据质量评估、落地管理流程。
5.7 传统数据仓库与数据中台的差异点 作为工业企业一般采用混搭架构 6.1 数据仓库vs.数据集市
数据集市和数据仓库经常会被混淆但两者的用途明显不同。
数据集市通常是数据仓库的子集;它等数据通常来自数据仓库 – 尽管还可以来自其他来源。数据集市的数据专门针对特定的用户社区(例如销售团队)以便他们能够快速找到所需的数据。通常数据保存在那里用于特定用途例如财务分析。
数据集市也比数据仓库小得多 – 它们可以容纳数十千兆字节相比之下数据仓库可以存储数百千兆字节到PB级数据并可用于数据处理。
数据集市可从现有数据仓库或其他数据源系统构建你只需设计和构建数据库表使用相关数据填充数据库表并决定谁可以访问数据集即可。
6.2 数据仓库vs.ODS
操作数据存储(ODS)是一种数据库用作所有原始数据的临时存储区域这些数据即将进入数据仓库进行数据处理。我们可以将其想象成仓库装卸码头货物在此处交付、检查和验证。在ODS中数据在进入仓库前可以被清理、检查(因为冗余目的)也可检查是否符合业务规则。
在ODS中我们可以对数据进行查询但是数据是临时的因此它仅提供简单信息查询例如正在进行的客户订单状态。
ODS通常运行在关系数据库管理系统(RDBMS)或Hadoop平台。
6.3 关系型数据库vs.数据仓库和数据湖
数据仓库、数据湖与关系数据库系统之间的主要区别在于
关系数据库用于存储和整理来自单个来源(例如事务系统)的结构化数据
而数据仓库则用于存储来自多个来源的结构化数据。
数据湖的不同之处在于它可存储非结构化、半结构化和结构化数据。
关系数据库创建起来相对简单可用于存储和整理实时数据例如交易数据等。关系数据库的缺点是它们不支持非结构化数据库数据或现在不断生成的大量数据。这使得我们只能在数据仓库与数据湖间做出选择。尽管如此很多企业仍然继续依赖关系数据库来完成运营数据分析或趋势分析等任务。
内部或云端可用的关系数据库包括Microsoft SQL Server、Oracle数据库、MySQL和IBM Db2、以及Amazon Relational Database Service、Google Cloud Spanner等。
可参考 解读阿里巴巴集团的“大中台、小前台”组织战略 互联网中台重要性 What is a Lakehouse? by Ben Lorica, Michael Armbrust, Ali Ghodsi, Reynold Xin and Matei Zaharia Posted in COMPANY BLOGJanuary 30, 2020 带你读《企业数据湖》之一数据导论 带你读《企业数据湖》之二数据湖概念概览 带你读《企业数据湖》之三Lambda架构一种数据湖实现模式 阿里云-什么是数据湖分析
- EOF -
推荐书籍《分布式商业生态战略数字商业新逻辑与企业数字化转型新策略》 素材来源官方媒体/网络新闻
