精华内容
下载资源
问答
  • 目录:一、航空业数据治理现状二、航空业大数据治理的三个发展趋势三、规划企业数据架构的两种模式四、规划企业数据架构的三个关键技术五、总结一、航空业数据治理现状目前航空行业数据治理已经逐步在开展起来,驱动...

    目录:


    一、航空业数据治理现状

    二、航空业大数据治理的三个发展趋势

    三、规划企业数据架构的两种模式

    四、规划企业数据架构的三个关键技术

    五、总结


    一、航空业数据治理现状


    目前航空行业数据治理已经逐步在开展起来,驱动航空行业开展数据治理工作的因素与证券、银行、通信领域不同。证券行业有证监会33条规定,银行业有银监会要求在2017年7月份开始实施报送数据标准化规范要求,这些外在监管要求促使了证券、银行必须开展数据治理方面的建设。


    促使航空行业开展数据治理的主要因素是客户倒逼企业在做,服务行业现在都在做客户精准营销,航空业也不例外。这些年航空公司的信息化快速发展,积累了很多有价值的数据。但是拥有数据,并不意味着拥有数据资产




    那么如何将企业的数据转化为数据资产?我们知道企业在日常运营过程中产生的数据,只是一些原材料,存在不可知、不可信、不可取等问题。要想将其转化为数据资产,需要借助大数据治理打通数据和信息的通道。从而为挖掘数据价值、业务创新提供决策支持,以满足客户的个性化服务的要求。


    通过对国内两家大型航空公司数据治理项目的实施以及中小航空公司数据治理的交流探讨,我总结出航空数据现状总体面临着散、乱、难问题,数据资产分布散、数据定义乱、数据管理难。这使得航空业大数据治理呈现出三个趋势


    二、航空业大数据治理的

    三个发展趋势


    • 趋势1:集中管理企业数据资产


    针对分散在企业各个系统的数据资产,对企业数据资产进行盘点,实现对数据资产的统一集中管理。管理的内容包DB数据资产、接口数据资产、报表数据资产、指标标准和企业数据模型等。




    • 趋势2:提升企业数据洞察能力


    通过数据治理构建数据洞察能力趋势,举个例子说:小张销售部门的数据分析员,现在需要做一个2017年“春运”的市场和销售情况分析。他知道需要航班日期、起落机场、机型、收入、成本等这些基本数据,并且这些基础数据来源于航班运控系统。但是他想分析中加入航油、腹舱货运,天气对航班的影响。这些数据有没有?从哪里取?连他这个老员工都不清楚,就更不用说新员工了。通过大数据治理,提升企业对数据资产洞察能力,可以快速定位到需要的数据。




    • 趋势3:规划企业数据架构


    数据架构简单来说就是“人对企业业务的表达、记录,并转化为计算机可处理的格式”,是连接数据与信息的桥梁,部分航空公司为了适应这个趋势,专门成立了数据架构部,负责建立维护管理企业整体数据架构。


    我们认为企业的数据架构,主要有三个组件构成。分别是数据标准、企业模型和数据存储结构。如下图所示




    标准在最上层,是总体纲领。企业模型在中层,最下层是数据资源存储结构。层次是这样划分的,但在实际建立的过程中,是一个由下而上的方式。通常是在现有数据存储结构的基础上,设计企业数据模型,然后归并数据项,形成数据标准。


    通过大数据治理,可以规划统一、标准的数据架构,为企业信息化建设提供规范和标准,使得在业务层和应用层之间,做各个操作型应用的设计、开发;在各个操作型应用和数据层之间,做业务系统数据结构的设计以及数据集成;在分析型应用和数据层之间,做数据获取、分析,从而指导规范企业信息化建设。


    三、规划企业数据架构的两种模式


    规划企业数据架构,通常有两种典型的模式


    模式一:从技术到业务,也可以称为Bottom-up模式。典型特征是先定义主题域,在从现有操作性数据结构出发,通过调研和访谈,规划数据架构,实现数据到信息的打通。


    模式二:从业务到技术,也可以称为Top-Down模式。其特征是以业务流程为主线,串联业务单元、业务环节、业务活动。分析业务活动所需的实体、属性。通过调研访谈,确认最终业务用户的数据需求和KPI绩效考核标准。整合在一起,再结合现有的数据结构,规划企业数据架构,实现数据到信息的打通。




    两种工作模式没有好坏之分,需要根据企业的数据现状,采用适合自身的工作模式。


    • 从技术到业务模式的经典案例


    借助数据治理工具,实现对企业数据资产的盘点,盘点数据资产管理的对象包括数据从业务系统到数据仓库、集市、报表的流转加工关系。盘点的范围是以数仓为核心,构建业务系统到数仓、数仓到数据分析应用的全链路数据资产盘点。




    在数据资产盘点的基础参考同业案例或经验,划分数据主题域。在项目中我们借鉴达美航空经验确定了13个数据主题域,同时又分析了数仓的模型中2000多个实体,对现有系统的数据结构进行调研确认,从而构建了企业数据模型。




    在企业数据模型的基础上,对数据项进行归并、指标口径的标准化。抽象出数据标准层,形成统一数据架构,提升数据服务能力。


    • 从业务到技术模式的经典案例


    模式一以现有企业信息化系统数据结构为基础。模式二以业务流程切入,以业务环节中的获取信息为基础,汇总企业数据项的信息。


    下图是某航空公司飞机运行生命周期管理业务流程。从规划发展部做飞机引进计划,到飞机投入运营,再到飞机退出,每个业务环节都会产生业务数据。在梳理的工程中,会从业务部门收集业务流程的各环节涉及的数据集和数据项信息。




    然后对数据项进行整合,按照数据项使用的热度,频率、关联度等,整合数据项、代码、指标度量、维度等,在结合(国际/国内)同业经验,形成某业务域的数据架构。


    在构建企业统一数据架构过程中会遇到各种问题,在关于设备主题域数据项制定的过程中,就发现了一个飞机号B5917,却存在三个不同的叫法,有的系统叫飞机尾号、有的叫飞机号,还有的叫飞机设备尾号。总之各系统存在数据项业务含义不统一的地方。在梳理过程中要弄清楚数据的来源,来源不唯一的情况下还要从业务角度划分数据的责任方。最终确定统一的名称和业务含义。


    下图是我们在某航空公司构建数据标准示例,我们可以看到,航空业数据标准主要包括指标标准、业务术语,基础编码和数据项。




    四、规划企业数据架构的

    三个关键技术


    通过合理规划企业的数据架构,可以打通数据与信息的通道。我这里列出了3个关键技术,来帮助企业快速合理地规划企业数据架构,实现数据到信息的转换。


    • 关键技术1:自动化数据资产收集技术


    通过自动化数据资产收集,需要完成以下几件事:


    • 梳理全企业数据架构,对企业的数据模型、数据关系、数据处理有清晰化的认识。

    • 对数据资产形成统一的自动化管理,形成企业的元数据库。

    • 对企业数据资产形成多种视图,使数据资产能够对不同用户,有不同视角的展示。


    从一定程度上来说,元数据采集的全面性和准确性决定了自动化数据资产收集的成败,是否能够对大数据、数据仓库、关系型/非关系型数据库、数据模型、主流ETL工具等实现自动化的元数据采集是关键。




    • 关键技术2:数据资产自动分类实现技术


    通过元数据聚类能力,形成资产密度分类,结合已有的的模型体系进行归类和整合。将收集的元数据分类归集到信息模型上,形成多维度的、完整的模型体系,从而贯通业务技术。这里面需要元数据产品具备自动化的分类引擎以及可扩展的元模型管理能力。




    • 关键技术3:数据资产质量自动监控技术


    数据资产质量自动监控,要求能够从数据的准确性、完整性、及时性、一致性等六性的维度,对数据资产的质量进行管理,从数据问题定义、问题发现、问题处理、问题跟踪和问题评估统计5个环节,构建资产质量的闭环管理流程。




    五、总结


    航空数据现状总体面临着数据资产分布散、数据定义乱、数据管理难等常见问题,集中管理数据资产、提升企业数据洞察能力、规划企业数据架构是航空业应用大数据治理的三大趋势。其实,不只是在航空行业,各个行业在将企业数据转化为数据资产的过程中,打通数据与信息的通道都是关键的一环。通过自动化收集、自动化分类、自动化数据质量监控等技术手段,可以辅助企业规划统一、标准的数据架构,最终为数据转化为信息(数据资产)提供可靠、可行的途径。


    关于作者:刘庆会,主要负责普元大数据治理产品的实施,十年大型企业信息数据治理架构设计与建设经验,为多家大型金融机构、企业设计与规划数据管理整体框架和项目实施,客户包括国家开发银行、中信银行、北京银行、重庆农商行、攀枝花银行、国家电网、浙江电力、新奥能源以及中国东方航空、中国国际航空等。数据行业有着深入的研究和洞察,并对企业信息化平台建设,数据治理及大数据平台建设有着丰富经验。


    展开全文
  • 作者介绍刘庆会,主要负责普元大数据治理产品的实施,十年大型企业信息...声明:本文转自EAWorld(eaworld)公众号目录大纲:1、航空业数据治理现状2、航空业大数据治理的三个发展趋势3、规划企业数据架构的两种模式4
        

    作者介绍

    刘庆会主要负责普元大数据治理产品的实施,十年大型企业信息数据治理架构设计与建设经验,为多家大型金融机构、企业设计与规划数据管理整体框架和项目实施。对数据行业有着深入的研究和洞察,并在企业信息化平台建设、数据治理及大数据平台建设有着丰富经验。

    声明:本文转自EAWorld(eaworld)公众号


    目录大纲:

    1、航空业数据治理现状

    2、航空业大数据治理的三个发展趋势

    3、规划企业数据架构的两种模式

    4、规划企业数据架构的三个关键技术

    5、总结


    一、航空业数据治理现状


    目前航空行业数据治理已经逐步开展起来,驱动航空行业开展数据治理工作的因素与证券、银行、通信领域不同。证券行业有证监会33条规定,银行业有银监会要求在2017年7月份开始实施报送数据标准化规范要求,这些外在监管要求促使了证券、银行必须开展数据治理方面的建设。而促使航空行业开展数据治理的主要因素是客户倒逼企业在做,服务行业现在都在做客户精准营销,航空业也不例外。


    这些年航空公司的信息化快速发展,积累了很多有价值的数据。但拥有数据,并不意味着拥有数据资产。


    640?wx_fmt=png&wxfrom=5&wx_lazy=1


    如何将企业的数据转化为数据资产?我们知道企业在日常运营过程中产生的数据,只是一些原材料,存在不可知、不可信、不可取等问题。要想将其转化为数据资产,需要借助大数据治理打通数据和信息的通道,从而为挖掘数据价值、业务创新提供决策支持,以满足客户的个性化服务的要求。


    通过对国内两家大型航空公司数据治理项目的实施以及中小航空公司数据治理的交流探讨,笔者总结出航空数据现状总体面临着散、乱、难问题,数据资产分布散、数据定义乱、数据管理难,这使得航空业大数据治理呈现出三个趋势。


    二、航空业大数据治理的三个发展趋势


    趋势1:集中管理企业数据资产


    针对分散在企业各个系统的数据资产,对企业数据资产进行盘点,实现对数据资产的统一集中管理。管理的内容包DB数据资产、接口数据资产、报表数据资产、指标标准和企业数据模型等。


    640?wx_fmt=png


    趋势2:提升企业数据洞察能力


    通过数据治理构建数据洞察能力趋势,举个例子说:小张是销售部门的数据分析员,现在需要做一个2017年“春运”的市场和销售情况分析。他知道需要航班日期、起落机场、机型、收入、成本等这些基本数据,并且这些基础数据来源于航班运控系统。但他想分析中加入航油、腹舱货运,天气对航班的影响。这些数据有没有?从哪里取?连他这个老员工都不清楚,就更不用说新员工了。


    通过大数据治理,提升企业对数据资产洞察能力,可以快速定位到需要的数据。


    640?wx_fmt=png


    趋势3:规划企业数据架构


    简单来说,数据架构就是“人对企业业务的表达、记录,并转化为计算机可处理的格式”,是连接数据与信息的桥梁,部分航空公司为了适应这个趋势,专门成立了数据架构部,负责建立维护管理企业整体数据架构。


    我们认为企业的数据架构,主要有三个组件构成,分别是数据标准、企业模型和数据存储结构,如下图所示:


    640?wx_fmt=png


    标准在最上层,是总体纲领,企业模型在中层,最下层是数据资源存储结构,层次是这样划分的。但在实际建立的过程中,是一个由下而上的方式,通常是在现有数据存储结构的基础上,设计企业数据模型,然后归并数据项,形成数据标准。


    通过大数据治理,可以规划统一、标准的数据架构,为企业信息化建设提供规范和标准,使得在业务层和应用层之间,做各个操作型应用的设计、开发;在各个操作型应用和数据层之间,做业务系统数据结构的设计以及数据集成;在分析型应用和数据层之间,做数据获取、分析,从而指导规范企业信息化建设。


    三、规划企业数据架构的两种模式


    规划企业数据架构,通常有两种典型的模式:

     

    模式一:从技术到业务,也可以称为Bottom-up模式。典型特征是先定义主题域,在从现有操作性数据结构出发,通过调研和访谈,规划数据架构,实现数据到信息的打通。


    模式二:从业务到技术,也可以称为Top-Down模式。特征是以业务流程为主线,串联业务单元、业务环节、业务活动。分析业务活动所需的实体、属性。通过调研访谈,确认最终业务用户的数据需求和KPI绩效考核标准。整合在一起,再结合现有的数据结构,规划企业数据架构,实现数据到信息的打通。


    640?wx_fmt=png


    两种工作模式没有好坏之分,需要根据企业的数据现状,采用适合自身的工作模式。


    从技术到业务模式的经典案例


    借助数据治理工具,实现对企业数据资产的盘点,盘点数据资产管理的对象包括数据从业务系统到数据仓库、集市、报表的流转加工关系。盘点的范围是以数仓为核心,构建业务系统到数仓、数仓到数据分析应用的全链路数据资产盘点。


    640?wx_fmt=png


    在数据资产盘点的基础参考同业案例或经验,划分数据主题域。在项目中我们借鉴达美航空经验确定了13个数据主题域,同时又分析了数仓的模型中2000多个实体,对现有系统的数据结构进行调研确认,从而构建了企业数据模型。


    640?wx_fmt=png


    在企业数据模型的基础上,对数据项进行归并、指标口径的标准化,抽象出数据标准层,形成统一数据架构,提升数据服务能力。


    从业务到技术模式的经典案例


    模式一以现有企业信息化系统数据结构为基础。模式二以业务流程切入,以业务环节中的获取信息为基础,汇总企业数据项的信息。


    下图是某航空公司飞机运行生命周期管理业务流程。从规划发展部做飞机引进计划,到飞机投入运营,再到飞机退出,每个业务环节都会产生业务数据。在梳理的工程中,会从业务部门收集业务流程的各环节涉及的数据集和数据项信息。


    640?wx_fmt=png


    然后对数据项进行整合,按照数据项使用的热度,频率、关联度等,整合数据项、代码、指标度量、维度等,在结合(国际/国内)同业经验,形成某业务域的数据架构。


    在构建企业统一数据架构过程中会遇到各种问题,在关于设备主题域数据项制定的过程中,就发现了一个飞机号B5917,却存在三个不同的叫法,有的系统叫飞机尾号、有的叫飞机号,还有的叫飞机设备尾号。总之,各系统存在数据项业务含义不统一的地方。在梳理过程中要弄清楚数据的来源,来源不唯一的情况下还要从业务角度划分数据的责任方。最终确定统一的名称和业务含义。


    下图是我们在某航空公司构建数据标准示例,我们可以看到,航空业数据标准主要包括指标标准、业务术语、基础编码和数据项。


    640?wx_fmt=png


    四、规划企业数据架构的三个关键技术


    通过合理规划企业的数据架构,可以打通数据与信息的通道。这里列出了3个关键技术,来帮助企业快速合理地规划企业数据架构,实现数据到信息的转换。


    关键技术1:自动化数据资产收集技术


    通过自动化数据资产收集,需要完成以下几件事:

    • 梳理全企业数据架构,对企业的数据模型、数据关系、数据处理有清晰化的认识;

    • 对数据资产形成统一的自动化管理,形成企业的元数据库;

    • 对企业数据资产形成多种视图,使数据资产能够对不同用户,有不同视角的展示。


    从一定程度上来说,元数据采集的全面性和准确性决定了自动化数据资产收集的成败,是否能够对大数据、数据仓库、关系型/非关系型数据库、数据模型、主流ETL工具等实现自动化的元数据采集是关键。


    640?wx_fmt=png


    关键技术2:数据资产自动分类实现技术


    通过元数据聚类能力,形成资产密度分类,结合已有的的模型体系进行归类和整合。将收集的元数据分类归集到信息模型上,形成多维度的、完整的模型体系,从而贯通业务技术。这里面需要元数据产品具备自动化的分类引擎以及可扩展的元模型管理能力。


    640?wx_fmt=png


    关键技术3:数据资产质量自动监控技术


    数据资产质量自动监控,要求能够从数据的准确性、完整性、及时性、一致性等六性的维度,对数据资产的质量进行管理,从数据问题定义、问题发现、问题处理、问题跟踪和问题评估统计5个环节,构建资产质量的闭环管理流程。


    640?wx_fmt=jpeg


    五、总结


    航空数据现状总体面临着数据资产分布散、数据定义乱、数据管理难等常见问题,集中管理数据资产、提升企业数据洞察能力、规划企业数据架构是航空业应用大数据治理的三大趋势。


    其实不只在航空行业,各个行业在将企业数据转化为数据资产的过程中,打通数据与信息的通道都是关键的一环。通过自动化收集、自动化分类、自动化数据质量监控等技术手段,可以辅助企业规划统一、标准的数据架构,最终为数据转化为信息(数据资产)提供可靠、可行的途径。

    640?wx_fmt=png

    人工智能赛博物理操作系统

    AI-CPS OS

    人工智能赛博物理操作系统新一代技术+商业操作系统“AI-CPS OS:云计算+大数据+物联网+区块链+人工智能)分支用来的今天,企业领导者必须了解如何将“技术”全面渗入整个公司、产品等“商业”场景中,利用AI-CPS OS形成数字化+智能化力量,实现行业的重新布局、企业的重新构建和自我的焕然新生。


    AI-CPS OS的真正价值并不来自构成技术或功能,而是要以一种传递独特竞争优势的方式将自动化+信息化、智造+产品+服务数据+分析一体化,这种整合方式能够释放新的业务和运营模式。如果不能实现跨功能的更大规模融合,没有颠覆现状的意愿,这些将不可能实现。


    领导者无法依靠某种单一战略方法来应对多维度的数字化变革。面对新一代技术+商业操作系统AI-CPS OS颠覆性的数字化+智能化力量,领导者必须在行业、企业与个人这三个层面都保持领先地位:

    1. 重新行业布局:你的世界观要怎样改变才算足够?你必须对行业典范进行怎样的反思?

    2. 重新构建企业:你的企业需要做出什么样的变化?你准备如何重新定义你的公司?

    3. 重新打造自己:你需要成为怎样的人?要重塑自己并在数字化+智能化时代保有领先地位,你必须如何去做?

    AI-CPS OS是数字化智能化创新平台,设计思路是将大数据、物联网、区块链和人工智能等无缝整合在云端,可以帮助企业将创新成果融入自身业务体系,实现各个前沿技术在云端的优势协同。AI-CPS OS形成的字化+智能化力量与行业、企业及个人三个层面的交叉,形成了领导力模式,使数字化融入到领导者所在企业与领导方式的核心位置:

    1. 精细种力量能够使人在更加真实、细致的层面观察与感知现实世界和数字化世界正在发生的一切,进而理解和更加精细地进行产品个性化控制、微观业务场景事件和结果控制。

    2. 智能:模型随着时间(数据)的变化而变化,整个系统就具备了智能(自学习)的能力。

    3. 高效:企业需要建立实时或者准实时的数据采集传输、模型预测和响应决策能力,这样智能就从批量性、阶段性的行为变成一个可以实时触达的行为。

    4. 不确定性:数字化变更颠覆和改变了领导者曾经仰仗的思维方式、结构和实践经验,其结果就是形成了复合不确定性这种颠覆性力量。主要的不确定性蕴含于三个领域:技术、文化、制度。

    5. 边界模糊:数字世界与现实世界的不断融合成CPS不仅让人们所知行业的核心产品、经济学定理和可能性都产生了变化,还模糊了不同行业间的界限。这种效应正在向生态系统、企业、客户、产品快速蔓延。

    AI-CPS OS形成的数字化+智能化力量通过三个方式激发经济增长:

    1. 创造虚拟劳动力,承担需要适应性和敏捷性的复杂任务,即“智能自动化”,以区别于传统的自动化解决方案;

    2. 对现有劳动力和实物资产进行有利的补充和提升,提高资本效率

    3. 人工智能的普及,将推动多行业的相关创新,开辟崭新的经济增长空间


    给决策制定者和商业领袖的建议:

    1. 超越自动化,开启新创新模式:利用具有自主学习和自我控制能力的动态机器智能,为企业创造新商机;

    2. 迎接新一代信息技术,迎接人工智能:无缝整合人类智慧与机器智能,重新

      评估未来的知识和技能类型;

    3. 制定道德规范:切实为人工智能生态系统制定道德准则,并在智能机器的开

      发过程中确定更加明晰的标准和最佳实践;

    4. 重视再分配效应:对人工智能可能带来的冲击做好准备,制定战略帮助面临

      较高失业风险的人群;

    5. 开发数字化+智能化企业所需新能力:员工团队需要积极掌握判断、沟通及想象力和创造力等人类所特有的重要能力。对于中国企业来说,创造兼具包容性和多样性的文化也非常重要。


    子曰:“君子和而不同,小人同而不和。”  《论语·子路》云计算、大数据、物联网、区块链和 人工智能,像君子一般融合,一起体现科技就是生产力。


    如果说上一次哥伦布地理大发现,拓展的是人类的物理空间。那么这一次地理大发现,拓展的就是人们的数字空间。在数学空间,建立新的商业文明,从而发现新的创富模式,为人类社会带来新的财富空间。云计算,大数据、物联网和区块链,是进入这个数字空间的船,而人工智能就是那船上的帆,哥伦布之帆!


    新一代技术+商业的人工智能赛博物理操作系统AI-CPS OS作为新一轮产业变革的核心驱动力,将进一步释放历次科技革命和产业变革积蓄的巨大能量,并创造新的强大引擎。重构生产、分配、交换、消费等经济活动各环节,形成从宏观到微观各领域的智能化新需求,催生新技术、新产品、新产业、新业态、新模式。引发经济结构重大变革,深刻改变人类生产生活方式和思维模式,实现社会生产力的整体跃升。



    产业智能官  AI-CPS


    用“人工智能赛博物理操作系统新一代技术+商业操作系统“AI-CPS OS”:云计算+大数据+物联网+区块链+人工智能)在场景中构建状态感知-实时分析-自主决策-精准执行-学习提升的认知计算和机器智能;实现产业转型升级、DT驱动业务、价值创新创造的产业互联生态链


    640?wx_fmt=png

    640?wx_fmt=png

    长按上方二维码关注微信公众号: AI-CPS,更多信息回复:


    新技术“云计算”、“大数据”、“物联网”、“区块链”、“人工智能新产业:智能制造”、智能金融”、“智能零售”、“智能驾驶”、智能城市新模式:“财富空间“工业互联网”、“数据科学家”、“赛博物理系统CPS”、“供应链金融”


    官方网站:AI-CPS.NET


    本文系“产业智能官”(公众号ID:AI-CPS)收集整理,转载请注明出处!



    版权声明产业智能官(公众号ID:AI-CPS推荐的文章,除非确实无法确认,我们都会注明作者和来源。部分文章推送时未能与原作者取得联系。若涉及版权问题,烦请原作者联系我们,与您共同协商解决。联系、投稿邮箱:erp_vip@hotmail.com




    展开全文
  • 数据架构与数据模型

    千次阅读 2020-06-26 21:12:57
    数据架构与数据模型 数据架构与数据模型两者关系经常是讨论的热点。 因为数据架构里面主要工作和产物就是数据建模和数据模型,那为什么要将...另一方面,数据架构企业架构(Enterprise Architecture)的一部分。 ...

    数据架构与数据模型

    数据架构与数据模型两者关系经常是讨论的热点。 因为数据架构里面主要工作和产物就是数据建模和数据模型,那为什么要将两者作为独立的两个过程域。 本文将对此问题进行探讨。

     

    在《数据管理知识手册》(DMBOK 2)的第二版中,数据架构定义为管理数据资产的蓝图

    从广义上讲,数据架构会定义,'我们作为一家企业要做什么数字化业务?最适合该目的的技术是什么,以及它们如何协同工作?”

     

     

    另一方面,数据架构是企业架构(Enterprise Architecture)的一部分。 企业架构从更宏观的视角看待业务和IT,包括业务流程,业务组织架构和业务目标。这对数据架构以及安全性和合规性都很重要。

    数据架构还需要决策哪个最佳平台是适合当前业务目标的,是否迁移到基于云的解决方案,产品业务相关的安全风险,以及数据库的选择。

    在许多公司数据化转型中,要做的第一件事就是绘制其现有架构图。

    数据的独特之处在于它既是业务角色,又是技术角色。有的数据架构师只专注于平台和IT角色,他们的权限仅限于技术层面的决策,例如要使用哪种服务器或备份和恢复选项。但真正的架构师必须对业务也熟悉,像首席数据官一样。”

    当企业的数据需求超过IT部门满足这些需求的能力时,IT部门可能会感到压力巨大。

    企业实际情况是业务人员缺乏IT信息无法构建解决方案,而IT人员专注于技术忽略了业务需求。许多公司正在通过创建一个新的数据部门来解决这种情况,该部门业务和IT紧密配合,因为两者缺一个都不行,需要这两个技能的综合体。

     

    数据模型的定义

    DMBOK 2将数据建模和设计定义为“数据模型是形式化的表达和沟通数据需求的过程和产物”。数据模型通过对实体、关系和属性等描述,使组织能够理解其数据资产。如业务的核心概念,客户、产品、员工等。

    数据建模从业务和技术角度设计。“数据建模师可能擅长对特定系统或特定业务案例进行建模。但数据架构师必须看得更广泛,“数据建模通常对物理层上特定数据库的设计,或逻辑、概念层上特定业务领域的设计。

     

    需要将数据架构和数据建模,与组织过程结合起来。

    数据架构和数据建模应该与组织的核心业务流程和活动保持一致。

    • 例如,当销售部门想要购买一个新的电子商务平台时,它需要集成到整个体系结构中。如果不知道现有的数据输入和输出流程是什么,就很难知道新平台如何集成。“数据模型通常就是在这里出现的。试着比较两个系统的数据,我们如何整合?找出系统间的关联关系”

    在较高的层次上,数据模型记录了企业核心的业务对象和业务规则:客户、产品、部件等。不需要花几个月的时间去创建一个完美的数据模型,不断迭代和沉淀,即使只是问一些简单的描述,对数据资产的理解也能起到很大的作用。

    • 一位即将实施一个新系统的客户,他们召集所有人一起进行两小时的实施前数据模型的评审会议。在这个过程中,他们发现了一些重大的错误。结果他们很高兴把一些问题扼杀在萌芽状态,否则这将是未来的噩梦。
    • 另一个客户购买了多个系统,但他们的数仓遗漏一个设计来支持一个客户可以有多个电子邮件地址。他们花了数周重构数仓才解决。如果更早关注数据模型设计,他们就会知道设计与他们的业务规则不匹配。
    • 另一家公司正在建设一个人力资源系统,员工可以担任多个工作角色,在数据模型设计中表明“员工可能有多个角色。这是数据建模的基本常识,但他们没有关注数据模型的设计。现在公司检查每一个业务系统,并将其与他们的企业级数据模型进行比较,因为“他们的企业级数据模型就是他们的业务运营模式
    • 另一个更大的客户现在要求供应商在交付软件之前遵守特定的数据标准。因为他们是一家大公司,基于他们的购买力,供应商必须遵守相关规则。公司对其系统的数据模型进行管控,后面数据资产的集成和服务就越能顺利进行。

     

    随着数据中台的负面声音越来越多。 企业将回归基础,数据治理和企业架构曾经被认为是“老派”(Old school)。当一切尘埃落定,喧嚣归于平静,数据基础建设将更加脚踏实地,因为它是行之有效的唯一途径。

     

    这个行业经历了一个“青少年阶段”,一些人说“我们将打破所有的规则,我们不再需要那些愚蠢的数据模型了”。 但我认为我们现在已经走上了更成熟的阶段,深谋远虑的设计,对未来长期发展会有很大的帮助

     

    业务人员越来越意识到数据资产的重要性并参与其中,业务和IT的融合。这些融合最终都体现在数据模型上。数据管理、数据体系结构和数据建模等基础知识的需求正在增加,人们希望探索创新,他们意识到,如果不先建立基础,就是不断的原地踏步。 

     

    Datablau Data Modeler简介

    DDM(Datablau Data Modeler)是国内首创的专业建模工具,是数据治理体系的重要组成部分。数据模型是“所有系统、文档和流程中包含的所有数据的语境。是生数据的知识。”换句话说,如果没有数据模型,组织IT系统中收集和存储的所有数据都会失去意义,也就没有业务价值。


    Datablau简介

    北京数语科技有限公司(以下简称“数语科技”)成立于2016年,是专注于数据治理领域的国内自主知识产权的专业软件产品提供商,主要业务是数据治理软件产品的研发与销售。数语科技的创始团队全部来自CA erwin,天然具有世界级水准的软件产品开发能力。

    创始人兼CEO王琤:曾任职erwin全球研发总监,拥有超过十年以上数据建模和数据管理的从业经验。

    CTO朱金宝:曾任职erwin首席架构师,先后服务多家全球知名企业,并曾全程参与中国建设银行数据治理项目,目前全面负责Datablau软件平台的研发工作和关键项目的实施工作。

    数语科技根据DAMA理论和中国国情独立研发Datablau新一代数据治理平台,平台由Datablau DDM数据建模产品和Datablau DAM数据资产管理平台两大部分组成,全部拥有软件著作权和知识产权,一站式全面满足中国企业的数据治理需求。其中数据建模产品DDM是Datablau填补国内空白的重量级产品,帮助中国客户摆脱国外产品的垄断现状。2018年,Datablau数据治理平台通过了中国信息通信研究院严格苛刻的产品评测并获得的“最佳大数据产品”奖。

    更多渠道了解我们
    官网:www.datablau.cn
    关注我们,及时了解数据治理干货

     

    展开全文
  • 企业数据湖与大数据 Lambda 架构

    千次阅读 2019-11-07 09:31:44
    1.Lambda架构背景介绍 2.大数据系统的关键特性 3.数据系统的本质 3.1.数据的本质 3.1.1.数据的特性:When & What 3.1.2.数据的存储:Store Everything Rawly and Immutably 3.2.查询的本质 4....

    目录

    1.Lambda架构背景介绍

    2.大数据系统的关键特性

    3.数据系统的本质

    3.1.数据的本质

    3.1.1.数据的特性:When & What

    3.1.2.数据的存储:Store Everything Rawly and Immutably

    3.2.查询的本质

    4.Lambda架构

    4.1.Batch Layer

    4.1.1.储存数据集

    4.1.2.构建查询View

    4.2.Speed Layer

    4.3.Serving Layer

    5.Big Picture

    5.1.Lambda架构组件选型

    5.2.Lambda架构组件选型原则

    6.Lambda架构 vs. Event Sourcing vs. CQRS

    6.1.事件溯源(Event Sourcing)vs. Lambda架构

    6.2.CQRS vs. Lambda架构

    7.总结

    1.Lambda架构背景介绍

    Lambda架构是由Storm的作者Nathan Marz提出的一个实时大数据处理框架。Marz在Twitter工作期间开发了著名的实时大数据处理框架Storm,Lambda架构是其根据多年进行分布式大数据系统的经验总结提炼而成。

    Lambda架构的目标是设计出一个能满足实时大数据系统关键特性的架构,包括有:高容错、低延时和可扩展等。Lambda架构整合离线计算和实时计算,融合不可变性(Immunability),读写分离和复杂性隔离等一系列架构原则,可集成Hadoop,Kafka,Storm,Spark,Hbase等各类大数据组件。

    Lambda 是实时处理框架Storm的作者Nathan Marz提出的用于同时处理离线和实时数据的架构理念。Lambda架构(LA)旨在满足一个稳定的大规模数据处理系统所需的容错性、低延迟、可扩展的特性。LA的可行性和必要性基于如下假设和原则。

    • 任何数据系统可定义为:query=functional(all data)。

    • 人为容错性(Human Fault-Tolerance):数据是易丢失的。

    • 数据不可变形(Data Immutability):数据是只读的,不再变化。

    • 重新计算(Recomputation):因为上面两个原则,运行函数重新计算结果是可能的。

    LA 基本框架如图所示:

    Lambda架构

    该架构具有如下特点。

    • 所有数据分别分发到批处理层和实时处理层。

    • 批处理层有两个功能:管理主要的数据(该类数据的特点是只能增加,不能更新);为下一步计算出批处理视图做预计算。

    • 服务层计算出批处理视图中的数据做索引,以提供低延时,即席查询。

    • 实时处理层仅处理实时数据,并为服务层提供查询服务。

    • 任何查询都可以通过实时处理层和批处理层的查询结果合并得到。

    https://www.jianshu.com/p/c56351b11de5

    2.大数据系统的关键特性

    Marz认为大数据系统应具有以下的关键特性:

    • Robust and fault-tolerant(容错性和鲁棒性):对大规模分布式系统来说,机器是不可靠的,可能会当机,但是系统需要是健壮、行为正确的,即使是遇到机器错误。除了机器错误,人更可能会犯错误。在软件开发中难免会有一些Bug,系统必须对有Bug的程序写入的错误数据有足够的适应能力,所以比机器容错性更加重要的容错性是人为操作容错性。对于大规模的分布式系统来说,人和机器的错误每天都可能会发生,如何应对人和机器的错误,让系统能够从错误中快速恢复尤其重要。

    • Low latency reads and updates(低延时):很多应用对于读和写操作的延时要求非常高,要求对更新和查询的响应是低延时的。

    • Scalable(横向扩容):当数据量/负载增大时,可扩展性的系统通过增加更多的机器资源来维持性能。也就是常说的系统需要线性可扩展,通常采用scale out(通过增加机器的个数)而不是scale up(通过增强机器的性能)。

    • General(通用性):系统需要能够适应广泛的应用,包括金融领域、社交网络、电子商务数据分析等。

    • Extensible(可扩展):需要增加新功能、新特性时,可扩展的系统能以最小的开发代价来增加新功能。

    • Allows ad hoc queries(方便查询):数据中蕴含有价值,需要能够方便、快速的查询出所需要的数据。

    • Minimal maintenance(易于维护):系统要想做到易于维护,其关键是控制其复杂性,越是复杂的系统越容易出错、越难维护。

    • Debuggable(易调试):当出问题时,系统需要有足够的信息来调试错误,找到问题的根源。其关键是能够追根溯源到每个数据生成点。

    3.数据系统的本质

    为了设计出能满足前述的大数据关键特性的系统,我们需要对数据系统有本质性的理解。我们可将数据系统简化为:

    数据系统 = 数据 + 查询

    从而从数据和查询两方面来认识大数据系统的本质。

    3.1.数据的本质

    3.1.1.数据的特性:When & What

    我们先从“数据”的特性谈起。数据是一个不可分割的单位,数据有两个关键的性质:When和What。

    • When是指数据是与时间相关的,数据一定是在某个时间点产生的。比如Log日志就隐含着按照时间先后顺序产生的数据,Log前面的日志数据一定先于Log后面的日志数据产生;消息系统中消息的接受者一定是在消息的发送者发送消息后接收到的消息。相比于数据库,数据库中表的记录就丢失了时间先后顺序的信息,中间某条记录可能是在最后一条记录产生后发生更新的。对于分布式系统,数据的时间特性尤其重要。分布式系统中数据可能产生于不同的系统中,时间决定了数据发生的全局先后顺序。比如对一个值做算术运算,先+2,后*3,与先*3,后+2,得到的结果完全不同。数据的时间性质决定了数据的全局发生先后,也就决定了数据的结果。

    • What是指数据的本身。由于数据跟某个时间点相关,所以数据的本身是不可变的(immutable),过往的数据已经成为事实(Fact),你不可能回到过去的某个时间点去改变数据事实。这也就意味着对数据的操作其实只有两种:读取已存在的数据和添加更多的新数据。采用数据库的记法,CRUD就变成了CR,Update和Delete本质上其实是新产生的数据信息,用C来记录。

    3.1.2.数据的存储:Store Everything Rawly and Immutably

    根据上述对数据本质特性的分析,Lamba架构中对数据的存储采用的方式是:数据不可变,存储所有数据。

    通过采用不可变方式存储所有的数据,可以有如下好处:

    • 简单。采用不可变的数据模型,存储数据时只需要简单的往主数据集后追加数据即可。相比于采用可变的数据模型,为了Update操作,数据通常需要被索引,从而能快速找到要更新的数据去做更新操作。

    • 应对人为和机器的错误。前述中提到人和机器每天都可能会出错,如何应对人和机器的错误,让系统能够从错误中快速恢复极其重要。不可变性(Immutability)和重新计算(Recomputation)则是应对人为和机器错误的常用方法。采用可变数据模型,引发错误的数据有可能被覆盖而丢失。相比于采用不可变的数据模型,因为所有的数据都在,引发错误的数据也在。修复的方法就可以简单的是遍历数据集上存储的所有的数据,丢弃错误的数据,重新计算得到Views(View的概念参考4.1.2)。重新计算的关键点在于利用数据的时间特性决定的全局次序,依次顺序重新执行,必然能得到正确的结果。

    当前业界有很多采用不可变数据模型来存储所有数据的例子。比如分布式数据库Datomic,基于不可变数据模型来存储数据,从而简化了设计。分布式消息中间件Kafka,基于Log日志,以追加append-only的方式来存储消息。

    3.2.查询

    查询是个什么概念?Marz给查询如下一个简单的定义:

    Query = Function(All Data)
    

    该等式的含义是:查询是应用于数据集上的函数。该定义看似简单,却几乎囊括了数据库和数据系统的所有领域:RDBMS、索引、OLAP、OLTP、MapReduce、EFL、分布式文件系统、NoSQL等都可以用这个等式来表示。

    让我们进一步深入看一下函数的特性,从而挖掘函数自身的特点来执行查询。

    有一类称为Monoid特性的函数应用非常广泛。Monoid的概念来源于范畴学(Category Theory),其一个重要特性是满足结合律。如整数的加法就满足Monoid特性:

    (a+b)+c=a+(b+c)
    

    不满足Monoid特性的函数很多时候可以转化成多个满足Monoid特性的函数的运算。如多个数的平均值Avg函数,多个平均值没法直接通过结合来得到最终的平均值,但是可以拆成分母除以分子,分母和分子都是整数的加法,从而满足Monoid特性。

    Monoid的结合律特性在分布式计算中极其重要,满足Monoid特性意味着我们可以将计算分解到多台机器并行运算,然后再结合各自的部分运算结果得到最终结果。同时也意味着部分运算结果可以储存下来被别的运算共享利用(如果该运算也包含相同的部分子运算),从而减少重复运算的工作量。

    4.Lambda架构

    有了上面对数据系统本质的探讨,下面我们来讨论大数据系统的关键问题:如何实时地在任意大数据集上进行查询?大数据再加上实时计算,问题的难度比较大。

    最简单的方法是,根据前述的查询等式Query = Function(All Data),在全体数据集上在线运行查询函数得到结果。但如果数据量比较大,该方法的计算代价太大了,所以不现实。

    Lambda架构通过分解的三层架构来解决该问题:Batch Layer,Speed Layer和Serving Layer。

    4.1.Batch Layer

    Batch Layer的功能主要有两点:

    • 存储数据集

    • 在数据集上预先计算查询函数,构建查询所对应的View

    4.1.1.储存数据集

    根据前述对数据When&What特性的讨论,Batch Layer采用不可变模型存储所有的数据。因为数据量比较大,可以采用HDFS之类的大数据储存方案。如果需要按照数据产生的时间先后顺序存放数据,可以考虑如InfluxDB之类的时间序列数据库(TSDB)存储方案。

    4.1.2.构建查询View

    上面说到根据等式Query = Function(All Data),在全体数据集上在线运行查询函数得到结果的代价太大。但如果我们预先在数据集上计算并保存查询函数的结果,查询的时候就可以直接返回结果(或通过简单的加工运算就可得到结果)而无需重新进行完整费时的计算了。这儿可以把Batch Layer看成是一个数据预处理的过程。我们把针对查询预先计算并保存的结果称为View,View是Lamba架构的一个核心概念,它是针对查询的优化,通过View即可以快速得到查询结果。

    如果采用HDFS来储存数据,我们就可以使用MapReduce来在数据集上构建查询的View。Batch Layer的工作可以简单的用如下伪码表示: 

    该工作看似简单,实质非常强大。任何人为或机器发生的错误,都可以通过修正错误后重新计算来恢复得到正确结果。

    对View的理解:

    View是一个和业务关联性比较大的概念,View的创建需要从业务自身的需求出发。一个通用的数据库查询系统,查询对应的函数千变万化,不可能穷举。但是如果从业务自身的需求出发,可以发现业务所需要的查询常常是有限的。Batch Layer需要做的一件重要的工作就是根据业务的需求,考察可能需要的各种查询,根据查询定义其在数据集上对应的Views。

    4.2.Speed Layer

    Batch Layer可以很好的处理离线数据,但有很多场景数据不断实时生成,并且需要实时查询处理。Speed Layer正是用来处理增量的实时数据。

    Speed Layer和Batch Layer比较类似,对数据进行计算并生成Realtime View,其主要区别在于:

    • Speed Layer处理的数据是最近的增量数据流,Batch Layer处理的全体数据集

    • Speed Layer为了效率,接收到新数据时不断更新Realtime View,而Batch Layer根据全体离线数据集直接得到Batch View。

    Lambda架构将数据处理分解为Batch Layer和Speed Layer有如下优点:

    • 容错性。Speed Layer中处理的数据也不断写入Batch Layer,当Batch Layer中重新计算的数据集包含Speed Layer处理的数据集后,当前的Realtime View就可以丢弃,这也就意味着Speed Layer处理中引入的错误,在Batch Layer重新计算时都可以得到修正。这点也可以看成是CAP理论中的最终一致性(Eventual Consistency)的体现。

    • 复杂性隔离。Batch Layer处理的是离线数据,可以很好的掌控。Speed Layer采用增量算法处理实时数据,复杂性比Batch Layer要高很多。通过分开Batch Layer和Speed Layer,把复杂性隔离到Speed Layer,可以很好的提高整个系统的鲁棒性和可靠性。

    4.3.Serving Layer

    Lambda架构的Serving Layer用于响应用户的查询请求,合并Batch View和Realtime View中的结果数据集到最终的数据集。

    这儿涉及到数据如何合并的问题。前面我们讨论了查询函数的Monoid性质,如果查询函数满足Monoid性质,即满足结合率,只需要简单的合并Batch View和Realtime View中的结果数据集即可。否则的话,可以把查询函数转换成多个满足Monoid性质的查询函数的运算,单独对每个满足Monoid性质的查询函数进行Batch View和Realtime View中的结果数据集合并,然后再计算得到最终的结果数据集。另外也可以根据业务自身的特性,运用业务自身的规则来对Batch View和Realtime View中的结果数据集合并。

    5.Big Picture

    上面分别讨论了Lambda架构的三层:Batch Layer,Speed Layer和Serving Layer。下图给出了Lambda架构的一个完整视图和流程。

    数据流进入系统后,同时发往Batch Layer和Speed Layer处理。Batch Layer以不可变模型离线存储所有数据集,通过在全体数据集上不断重新计算构建查询所对应的Batch Views。Speed Layer处理增量的实时数据流,不断更新查询所对应的Realtime Views。Serving Layer响应用户的查询请求,合并Batch View和Realtime View中的结果数据集到最终的数据集。

    5.1.Lambda架构组件选型

    下图给出了Lambda架构中各个层常用的组件。数据流存储可选用基于不可变日志的分布式消息系统Kafka;Batch Layer数据集的存储可选用Hadoop的HDFS,或者是阿里云的ODPS;Batch View的预计算可以选用MapReduce或Spark;Batch View自身结果数据的存储可使用MySQL(查询少量的最近结果数据),或HBase(查询大量的历史结果数据)。Speed Layer增量数据的处理可选用Storm或Spark Streaming;Realtime View增量结果数据集为了满足实时更新的效率,可选用Redis等内存NoSQL。

    5.2.Lambda架构组件选型原则

    Lambda架构是个通用框架,各个层选型时不要局限时上面给出的组件,特别是对于View的选型。从我对Lambda架构的实践来看,因为View是个和业务关联性非常大的概念,View选择组件时关键是要根据业务的需求,来选择最适合查询的组件。不同的View组件的选择要深入挖掘数据和计算自身的特点,从而选择出最适合数据和计算自身特点的组件,同时不同的View可以选择不同的组件。

    6.Lambda架构 vs. Event Sourcing vs. CQRS

    在Lambda架构身上可以看到很多现有设计思想和架构的影子,如Event Sourcing和CQRS,这儿我们把它们和Lambda架构做一结合对比,从而去更深入的理解Lambda架构。

    6.1.事件溯源(Event Sourcing)vs. Lambda架构

    事件溯源(Event Sourcing)是由大名鼎鼎的Martin Flower大叔提出来的架构模式。Event Sourcing本质上是一种数据持久化的方式,它将引发变化的事件(Event)本身存储下来。相比于传统数据是持久化方式,存储的是事件引发的结果,而非事件本身,这样我们在保存结果的同时,实际上失去了追溯导致结果原因的机会。

    这儿可以看到Lambda架构中数据集的存储和Event Sourcing中的思想是完全一致的,本质都是采用不可变的数据模型存储引发变化的事件而非变化产生的结果。从而在发生错误的时候,能够追本溯源,找到发生错误的根源,通过重新计算丢弃错误的信息来恢复系统,达到系统的容错性。

    6.2.CQRS vs. Lambda架构

    CQRS (Command Query Responsibility Segregation)将对数据的修改操作和查询操作分离,其本质和Lambda架构一样,也是一种形式的读写分离。在Lambda架构中,数据以不可变的方式存储下来(写操作),转换成查询所对应的Views,查询从View中直接得到结果数据(读操作)。

    读写分离将读和写两个视角进行分离,带来的好处是复杂性的隔离,从而简化系统的设计。相比于传统做法中的将读和写操作放在一起的处理方式,对于读写操作业务非常复杂的系统,只会使系统变得异常复杂,难以维护。

    7.总结

    本文介绍了Lambda架构的基本概念。Lambda架构通过对数据和查询的本质认识,融合了不可变性(Immunability),读写分离和复杂性隔离等一系列架构原则,将大数据处理系统划分为Batch Layer, Speed Layer和Serving Layer三层,从而设计出一个能满足实时大数据系统关键特性(如高容错、低延时和可扩展等)的架构。Lambda架构作为一个通用的大数据处理框架,可以很方便的集成Hadoop,Kafka,Storm,Spark,Hbase等各类大数据组件。

    https://blog.csdn.net/brucesea/article/details/45937875

    Lambda架构

    Nathan Marz针对通用的,可扩展的和容错的数据处理架构提出了术语Lambda Architecture。它是一种旨在通过利用批处理和流处理这两者的优势来处理大量数据的数据处理架构。

    我强烈建议阅读Nathan Marz的书,因为它从提出者的角度提供了Lambda Architecture的完整表述。

    图层

    从宏观角度看,它的处理流程如下:

    所有进入系统的数据都被分配到批处理层和速度层进行处理。批处理层管理主数据集(一个不可变的,仅可扩展的原始数据集)并预先计算批处理视图。服务层对批处理视图进行索引,以便可以在低延迟的情况下进行点对点查询。速度层只处理最近的数据。任何传入的查询都必须通过合并来自批量视图和实时视图的结果来得到结果。

    焦点

    许多工程师认为Lambda Architecture是全部关于这些层次和定义的数据流的,但Nathan Marz在他的书中将重点放在其他重要方面,如:

    • 思考的分布式

    • 避免增量架构

    • 强制数据不可变

    • 创建重新计算算法

    数据的相关性

    如前所述,任何传入查询都必须通过合并来自批量视图和实时视图的结果来得到答案,因此这些视图需要可合并性。需要注意的一点是,实时视图是以前的实时视图和新数据增量的函数,因此可以使用增量算法。批处理视图是所有数据的函数,因此应该在那里使用重算算法。

    权衡

    我们生活中的每一件事都是一种折衷,而Lambda Architecture也不是一个例外。通常,我们需要解决一些主要的折衷:

    • 完全重新计算与部分重新计算

      • 在某些情况下,可以使用Bloom过滤器来避免完全重新计算

    • 重算算法与增量算法

      • 使用增量算法有很大的诱惑力,但根据指南我们必须使用重新计算算法,即使它使达到相同的结果变得更加困难。

    • 加法算法与近似算法

      • Lambda Architecture与加法算法很好地协作。因此,这是我们需要考虑使用近似算法的另一种情况,例如,HyperLogLog用于计数不同的问题等。

    实现

    有多种实现Lambda体系结构的方法,因为它对于每个层的底层解决方案都是不可知的。每一层都需要底层实现的特定功能,这可能有助于做出更好的选择并避免过度的决定:

    • 批处理层:一次写入,批量读取多次

    • 服务层:随机读取,不随机写入; 批量计算和批量写入

    • 速度层:随机读取,随机写入; 增量计算

    例如,其中一个实现(使用Kafka,Apache Hadoop,Voldemort,Twitter Storm,Cassandra)可能如下所示:

    Apache Spark

    Apache Spark可以被视为在所有Lambda体系结构层上处理的集成解决方案。它包含Spark Core,包括高层次的API,并且支持通用执行图表的优化引擎,Spark SQL为SQL和结构化数据提供处理,以及Spark Streaming,支持可扩展性,高吞吐量,容错流的实时数据流的处理。当然,使用Spark进行批量处理可能会非常昂贵,并且可能不适合所有场景和数据量,但除此之外,它是Lambda Architecture实施方案的适当匹配。

    示例应用程序

    让我们用一些捷径创建一个示例应用程序来演示Lambda架构,这个程序的主要目标是提供在#morningatlohika推文中使用的主题标签统计数据。

    源代码位于GitHub上,关于上述主题的更多视觉信息位于Slideshare上。

    批处理视图

    为了简单起见,假设我们的主数据集包含自开始以来的所有推文。另外,我们实施了批量处理,创建我们业务目标所需的批处理视图,因此我们有一个预先计算的批处理视图,其中包含与#morningatlohika一起使用的所有主题标签统计信息:

    apache6
    architecture – 12
    aws – 3
    java – 4
    jeeconf – 7
    lambda – 6
    morningatlohika – 15
    simpleworkflow – 14
    spark – 5

    数字很容易记住,因为我简单地在相应的主题标签中使用了许多字母。

    实时视图

    想象一下,当应用程序启动并运行时,现在有人正在发送推文消息:

    “ @tmatyashovsky关于 #lambda #architecture 使用  #apache #spark 在  #morningatlohika的 酷博客文章 ”

    在这种情况下,适当的实时视图应该包含以下hash标签和它们的统计信息(在我们的例子中仅为1,因为相应的hash标签只用了一次):

    apache1
    architecture – 1
    lambda – 1
    morningatlohika – 1
    spark – 1

    查询

    当客户端为了实时得到所有的Hash标签的统计结果进行查询时,我们只需要将批量视图与实时视图合并即可。所以输出应该如下所示(适当的hashtags的统计数字增加1):

    apache7
    architecture – 13
    aws – 3
    java – 4
    jeeconf – 7
    lambda – 7
    morningatlohika – 16
    simpleworkflow – 14
    spark – 6

    演示方案

    演示场景的简化步骤如下:

    • 通过Apache Spark 创建批处理视图( .parquet

    • 在Apache Spark中缓存批处理视图

    • 开始连接到Twitter的流应用程序

    • 关注即时#morningatlohika推文

    • 构建增量的实时视图

    • 查询,即即时合并批处理和实时视图

    技术细节

    源代码基于Apache Spark 1.6.x,即在引入结构化流式传输之前。Spark Streaming架构是纯粹的微批处理架构:

    因此,对于流媒体应用程序,我是用DSTREAM使用连接到Twitter TwitterUtils:

    JavaDStream < Status > twitterStatuses = TwitterUtils.createStream ( javaStreamingContext,createTwitterAuthorization (),new  String [ ] {twitterFilterText } );

    在每个微批处理中(使用可配置的批处理间隔),我正在执行新推文中hashtags统计的计算,并使用updateStateByKey()有状态转换更新实时视图的状态。为了简单起见,使用临时表将实时视图存储在内存中。

    查询服务反映了通过代码显式合并由DataFrame表示的批处理视图和实时视图:

    DataFrame realTimeView = streamingService . getRealTimeView ( ) ;
    DataFrame batchView = servingService . getBatchView ( ) ;
    DataFrame mergedView = realTimeView . unionAll ( batchView )
                                       . groupBy ( realTimeView . col ( HASH_TAG . getValue ( ) ) )
                                       . sum ( COUNT . getValue ( ) )
                                       . orderBy ( HASH_TAG . getValue ( ) ) ;
    

    List < Row > merged = mergedView . collectAsList ( ) ;

    return merged . stream ( )
    . map ( row - > new HashTagCount ( row . getString ( 0 ) , row . getLong ( 1 ) ) )
    . collect ( Collectors . toList ( ) ) ;

    结果

    使用简化的方法,开头提到的真正基于Hadoop的M/R管道可能会使用Apache Spark进行增强,并按以下方式查看:

    并不是后记

    正如前面提到的,Lambda Architecture有其优点和缺点,人们也划分成支持者和反对者两派。他们中的一些人说批处理视图和实时视图有很多重复的逻辑,因为他们最终需要从查询角度创建可合并的视图。所以他们创建了Kappa架构 - 简化了Lambda架构。Kappa架构系统是删除了批处理系统的架构。要取代批处理,数据只需通过流式传输系统快速提供:

    但即使在这种情况下,Kappa Architecture也有使用Apache Spark的地方,例如流处理系统:

    展开全文
  • 在BATJ等互联网大厂大肆推广中台建设成果的当下,各个行业的企业似乎都想做数字化转型,建设业务中台,但是中台到底是啥,需要我们提前了解和学习,本文是我学习张旭老师《数据中台架构企业数据化最佳实践》一书的...
  • 企业应用架构是指一整套软件系统的构建,通过合理的划分和设计组合在一起,支持企业方方面面的经营运作。 不论是传统企业,还是互联网公司,发展到一定阶段,都需要一整套体系化的应用架构来支撑其运转。良好的、...
  • 企业架构-数据服务总线思路

    千次阅读 2020-04-20 15:14:51
    数据服务总线是快速数据集市构建工具,提供企业内部以及跨企业间不同业务主题之间数据共享和同步服务,设计的目的是对最终业务数据进行预处理,以减少业务复杂度提高访问效率。 背景描述 在常规的业务系统中数据...
  • 企业应用架构模式之数据源模式

    千次阅读 2012-10-13 17:07:59
    一旦选择了领域层(见领域逻辑架构模式),就必须决定如何与数据源相联系,这时候的选择是以领域层的选择为基础的。一般里说有以下4种方法:表数据入口、行数据入口、活动记录、数据映射器。称之为数据架构模式。 ...
  • 大型企业网络架构

    万次阅读 多人点赞 2018-11-24 10:57:01
    可以看到,在大型企业网络架构中,有非常多的产品:交换机、路由器、防火墙、IDS、IPS、服务器等设备。 那么有很多人会问,有了防火墙为什么还要IPS和IDS呢? 防火墙较多的应用在内网保护(NAT),流控,过滤等...
  • 一、总线架构 维度建模的数据仓库中,有一个概念叫Bus Architecture,中文一般翻译为“总线架构”。...在多维体系结构(MD) 的数据仓库架构中,主导思想是分步建立数据仓库,由数据集市组合成企业的...
  • 信息爆炸的时代,很少有人能够耐心的读完冗长的文章,除非学术研究或者纯技术类文章。 对于我们发表的表达观点...我们想表达的一个观点是,数据对一个企业来说,真的很重要,重要到会决定一个企业的生死存亡。 IT
  • 数据中台架构详解

    千人学习 2019-04-19 14:13:24
    当今是数据时代,越来越多的企业开始重视并探索数据的价值,希望通过数据运营赋能业务、让数据成为企业业务增长的新能源。但在数据运营过程中,... 本次直播将深度揭秘企业数据中台的技术架构、数据架构、产品架构。
  • 一个运行了20多年的数据架构,必然有其合理性。也正是因为年代久远,存量过多,才导致举步维艰。在Cloud和5G时代,超密度网络集成和大数据洞察需求给电信供应商带来新的挑战,从数据仓库到数...
  • 在实际工作中,我们经常听到“架构”和“架构师”这样的名词,并不新鲜...
  • 企业数据仓库体系架构

    千次阅读 2005-11-16 19:44:00
    [作者blog: duzhaoyi2000 ] 一个典型的企业数据仓库系统通常包含数据源、数据存储与管理、OLAP服务器以及前端工具与应用四个部分。 500)this.width=500" border="0" alt=""/> 数据源:是数据仓库系统的基础,是...
  • 数据仓库架构

    千次阅读 2012-03-10 10:51:42
    对于数据仓库的架构方法,不同的架构师有不同的原则和方法,笔者在这里来总结一下当前常采用的...而独立的数据集市架构(Independent data marts)没有企业范围内一致的数据,很可能会导致信息孤岛的产生,除非在很小
  • 全栈必备 面向数据架构

    千次阅读 2016-11-30 20:49:43
    数据是系统的核心,在面向服务的架构之外,可以考虑面向数据架构方式。面向数据的服务架构需要支持多数据源异构,支持动态数据和静态数据,既支持公有云部署又支持私有云部署,提供多种数据应用和数据产品......
  • 但是如果站在企业级别就要统一考虑,这样在设计时就会规避好多问题,在技术/数据架构设计时,可以控制全局的复杂性,可重用性,可扩展,可管理性,下面是我想象中的一个企业的技术/数据架构逻辑图模型:
  • 在一个企业中,可能数据部门在一个公司中组织架构中的位置,决定了部门的定位和一些做的事情,所以笔者认为,数据部门所处的组织架构数据价值实现是一个很重要因素。   问题:为什么传统BI没有达到今天...
  • 数据仓库体系架构

    千次阅读 2014-01-15 08:34:10
    数据仓库架构,是IT架构的一个分支,随着数据企业的核心作用的增强,数据仓库的架构日益重要。数据仓库架构由于其技术选择非常广泛,看上去复杂,不过背后有一套比较稳定的思路,这也是数据仓库架构设计的一个要点...
  • 经过几十年的发展业界已经涌现出了很多企业架构以及企业架构框架理论。企业架构创建的方法论,亦即企业架构框架,由于其具备标准化的特性,将被作为本章内容的重点。当然,即便企业架构框架具有其标准性的一面,也并...
  • 《SOD框架“企业级”应用数据架构实战》是框架作者“深蓝医生”10年架构师经验的精华总结,同时又是 国内第一本探讨程序员行业“996”问题现状与解决方案的图书,也是探讨普通程序员生存现状,拜托繁琐的CRUD,如何...
  • 数据仓库架构设计

    千次阅读 2009-01-23 12:27:00
    数据仓库架构,是IT架构的一个分支,随着数据企业的核心作用的增强,数据仓库的架构日益重要。数据仓库架构由于其技术选择非常广泛,看上去复杂,不过背后有一套比较稳定的思路,这也是数据仓库架构设计的一个要点...
  • 企业IT架构的发展历程

    千次阅读 多人点赞 2019-04-17 09:58:52
    提起IT架构每个人都不陌生,有人说IT架构企业架构中的一部分,与业务架构结合,为企业打造适合业务的IT信息化建设,也有人说IT架构是方法论,是一种为企业制定IT构建策略、标准、服务、产品、解决方案及对应IT厂商...
  • 企业架构(Enterprise Architecture),简称EA。是指对企业事业信息管理系统中具有体系的、普遍性的问题而提供的通用解决方案,更确切的说,是基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行...
  • 联邦企业架构框架提供了一个组织结构和收集渠道,方便联邦成员将各自的架构集中到联邦企业架构中去。这个框架是非限制性的,适用于所有的联邦内机构特别是已存在架构的机构。   CIO委员会针对联邦企业架构框架...
  • Kyuubi是网易数帆旗下易数大数据团队开源的一个企业数据湖管理平台,建立在Apache Spark之上。Kyuubi提供一个高性能的通用JDBC和SQL执行引擎,通过它,用户能够像处理普通数据一样处理大数据。本文将详细解读...
  • IFTTT的数据架构

    千次阅读 2016-04-11 18:51:29
    最近在调研一款神器——IFTTT,发现这个应用用了不少高端的技术,比如说:Docker、微服务架构、Kafka、Amazon云服务、Elasticsearch、机器学习、数据挖掘等。下面开始介绍。 IFTTT简介 各种各样的互联网服务如社交...
  • 数据仓库的架构与设计

    万次阅读 多人点赞 2017-04-01 17:52:19
    数据仓库的架构 数据仓库多维数据模型的设计 1. 什么是数据仓库1.1 数据仓库的概念官方定义数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合,用于对管理决策过程的支持。
  • 企业IT架构介绍

    千次阅读 2017-06-21 14:53:00
    企业信息化之路 问题   互联互通 ...企业数据集成业务架构 业务流程框架 业务流程模型 个性流程支持 跨业务的业务流程组合 EBS总线 ]

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 395,919
精华内容 158,367
关键字:

企业数据架构