精华内容
下载资源
问答
  • 0、前言 当前,大部分企业不再建设从源数据采集到分析应用的烟囱式系统,更...阿里的中台是从管理的角度出发,以中台事业部集中数据搜索,技术及产品,数据共享等多个部门的功能。其他组织或企业建设数据中台不一定需

    0、前言

    当前,大部分企业不再建设从源数据采集到分析应用的烟囱式系统,更倾向于数据集中采集、存储,并应用分层建设。这种方式一方面有利于应用系统的快速部署,另一方面也保证了数据的集中管理与运营,体现数据的资产、资源属性。

    数据中台的出现弥补了数据开发和应用开发之间由于开发速度不匹配而出现的响应力不足等缺陷问题。

    数据中台是国内学者提出的概念,起始于阿里的“大中台、小前台”概念。阿里的中台是从管理的角度出发,以中台事业部集中数据搜索,技术及产品,数据共享等多个部门的功能。其他组织或企业建设数据中台不一定需要成立中台事业部,但是数据集中治理与提升数据价值转换效率的思路是一致的。

    一、通用体系架构

    不同的企业对数据有不同的需求。企业数据应用不断更新迭代,企业的中台系统也需要不断变化。

     从数据处理与数据治理两个维度出发,可以设计一个解耦的数据中台体系架构。该数据中台体系架构具有一定的柔性,可按照企业应用需求进行组合,或者对单个模块进行扩充,能满足大多数企业数据中台建设的需求。

     数据中台体系架构示例

    数据中台的通用体系架构如上图所示,该中台体系架构以减少功能冗余和提高功能复用为原则,把数据中台解耦为 6 个可以分别独立建设、演进的功能子系统。

    数据结构与数据处理子系统是数据中台体系架构的核心,数据治理是提升数据价值的重要手段。该数据中台体系架构的通用性表现在以下几点:

    • 综合考虑了数据中台的各种要素,参考这个架构进行建设可以有效提升数据资产价值,提供数据及服务的共享。

    • 参考这个数据中台体系架构,企业可以一次规划、分步实施。首先建设处理子系统及数据存储子系统,然后根据业务发展需求,逐步补充数据采集、数据安全及数据治理子系统。

    • 该数据中台由 6 个解耦的子系统组成。企业在立项建设时可以灵活组合,每个子系统单独招标建设,也可以把多个子系统合并招标建设。数据中台通用体系架构包含数据存储框架、数据采集框架、数据处理框架、数据治理框架、数据安全框架及数据运营框架等 6 大部分。

    1.1 数据存储框架

    数据中台的核心是数据,数据通过采集系统获取,然后数据经过处理框架加工,并接受数据治理框架的管理,同时也要接受数据安全管理框架的管理,最后开放的价值数据将通过数据运营框架对外提供数据服务。

    数据中台的数据架构应该独立规划,并采用合理的技术架构对不同类型的数据进行存储。

    数据存储框架中,无论数据采用对象存储、块存储还是数据库存储技术,各种中台数据可按照上图所示分类管理。

    • 源数据:主要由采集框架进行管理,数据治理框架按照数据特征把数据简单分为结构化和非结构化数据两大类,而规范化分域数据则是数据治理框架对全量数据的规范化分域整理。宽表数据是数据关联的结果,利用宽表数据可以对人、事、地、物、组等对象进行完整的数据画像,同时宽表数据也可以作为上层模型数据的中间层数据。
    • 元数据和标签数据:都是对数据的描述,其中元数据用来对数据的客观属性进行表示,标签数据更倾向于管理者对数据的主观表述及等级划分,比如质量等级标签、安全标签、属性标签等。
    • 主数据:需要在各系统间频繁更新、交换,且需要独立的存储空间进行维护管理。

    1.2 数据采集框架

    数据中台的采集框架应对纳入数据中台的各种源数据进行统一采集管理。数据采集框架中应提供多种数据采集方式,如文件传输协议采集、数据库采集、接口应用程序接入采集、流式采集及网络爬虫采集。

    同时采集框架应按照数据采集规范对源数据进行预处理,从而去除明显不需要的数据及多余数据,并对采集过程进行管理。虽然数据中台的体系架构没有统一模板,但各企业数据采集框架基本一致。

    1.3 数据处理框架

    数据处理是每个数据应用的基本环节之一,经典的数据抽取、转换和加载(ETL)处理流程在数据采集预处理、数据整合、数据建模等多个地方均要使用。单独建设数据处理框架有利于数据处理工具组件的集中开发与管理,也有利于数据中台数据处理任务的协调与调度。

    数据处理框架专门负责数据处理相关的任务,包括批处理、流处理、人工智能分析、数据清洗、数据交换及查询,此外数据处理的相关工具组件可在处理框架中配置。任务调度模块在数据处理框架中处于居中指挥的作用,并对运行的数据处理任务进行监控及异常处理等操作。

    1.4 数据治理框架

    广义的数据治理不仅包含提升数据价值的内容,如数据管理、数据目录、数据质量等,也包含数据安全管理及数据共享服务。

    数据安全管理与数据价值提升是一个矛盾体,如果由一个厂商或开发团队进行数据安全管理及数据价值提升相关软件的开发,则开发者的操作难免有所偏向,而且矛盾不容易公开,少了冲突也就少了优质的解决方案。

    另外,数据共享与数据治理的其他内容也存在相同的问题。因此,建议数据中台的数据治理框架中不包含数据安全与共享的相关内容。

    数据治理框架包含数据目录、数据管理、模型管理和数据质量 4 个模块:

    • 数据地图、数据资产目录、知识图谱及数据血缘的主要作用是展示数据的属性及相互关系,因此都纳入数据目录模块。

    • 数据模型能提高数据中台对外部应用需求的反应能力,固化的中间模型数据需要专门管理。模型管理包括模型目录、模型血缘及模型地图等。

    • 数据管理又可以细分为元数据管理、主数据管理、标签数据管理及源数据管理。

    • 数据质量管理模块按照制定的数据标准及数据稽核规则对数据中台中的数据进行质量管理。

    1.5 数据安全框架

    数据已经成为数据资产,数据安全框架是数据中台必不可少的组成部分。数据安全叠加在数据中台其他功能框架之上,数据采集、处理、交换、共享等每个环节均必须实施安全控制策略。安全框架可以分为日志管理、用户认证、权限管理及加解密等几个功能模块。

    此外,安全全门户也可以对外提供安全能力封装,展示数据中台的安全态势及安全视图。

    1.6 数据运营框架

    数据中台的核心功能是综合众多数据应用的数据处理及数据治理功能,集中建设、集中管理、减少冗余、增加复用。数据中台的最终目的还是为其他应用或开发者提供数据服务,而对外数据服务功能将直接面向不确定的外部对象。

    因此单独建设数据运营,一方面有利于针对外部用户提供针对性功能;另一方面,数据运营模块作为用户与数据中台核心数据服务之间的中间层,可以有效隔离外部用户直接控制、接触核心数据及应用,可保护数据中台的安全性及内部功能的稳定性。

    综合以上因素,数据运营应配置运营门户、能力开放、数据开放及运营监控等功能:

    • 运营门户:对数据中台管理者提供管理门户,对开发者提供开发者门户。对内部应用提供内部应用门户,对外部应用提供外部应用门户。运营门户针对不同的用户提供不同的通道并开放不同的数据中台能力。

    • 能力开放:把数据中台的数据处理能力、数据分析能力等经过适当的封装后对用户提供服务,可以是微服务,也可以是 API 接口,或者直接提供二次开发能力。

    • 数据开放:通过数据目录,数据/模型展示(可视化、数据视图等)为其他数据应用系统提供数据服务。

    • 运营监控:对数据中台的总体运营情况进行监控管理,包括硬件环境、软件环境,并且确定监控指标,按需求提供运营日报,处理告警信息。

    二、典型架构

    数据中台的目标是让数据持续用起来,通过数据中台提供的工具、方法和运行机制,把数据变为一种服务能力,让数据更方便地被业务所使用。下图所示为数据中台总体架构图,数据中台是在底层存储计算平台与上层的数据应用之间的一整套体系。

     数据中台屏蔽掉底层存储平台的计算技术复杂性,降低对技术人才的需求,让数据的使用成本更低。通过数据中台的数据汇聚、数据开发模块建立企业数据资产。通过资产管理与治理、数据服务把数据资产变为数据服务能力,服务于企业业务。数据安全体系、数据运营体系保障数据中台可以长期健康、持续运转。

    2.1 数据汇聚

    数据汇聚是数据中台数据接入的入口。数据中台本身几乎不产生数据,所有数据来自于业务系统、日志、文件、网络等,这些数据分散在不同的网络环境和存储平台中,难以利用,很难产生业务价值。

    数据汇聚是数据中台必须提供的核心工具,把各种异构网络、异构数据源的数据能够方便地采集到数据中台进行集中存储,为后续的加工建模做准备。

    数据汇聚方式一般有数据库同步、埋点、网络爬虫、消息队列等;从汇聚的时效性来分,有离线批量汇聚和实时采集。

    2.2 数据开发

    通过数据汇聚模块汇聚到中台的数据,没有经过什么处理,基本是按照数据的原始状态堆砌在一起的,这样业务还是很难使用。数据开发是一整套数据加工以及加工过程管控的工具,有经验的数据开发、算法建模人员利用数据加工模块提供的功能,可以快速把数据加工成对业务有价值的形式,提供给业务使用。

    数据开发模块主要是面向开发、分析人员,提供离线、实时、算法开发工具以及任务的管理、代码发布、运维、监控、告警等一些列集成工具,方便使用,提升效率。

    2.3 数据资产体系

    有了数据汇聚、数据开发模块,中台已经具备传统数仓平台的基本能力,可以做数据的汇聚以及各种数据开发,就可以建立企业的数据资产体系。之前说数据资产体系是中台的血肉,开发、管理、使用的都是数据。大数据时代,数据量大,增长快,业务对数据的依赖也会越来越高,必须考虑数据的一致性和可复用性,垂直烟囱式的数据和数据服务的建设方式注定不能长久存在。

    不同的企业因业务不同导致数据不同,数据建设的内容也是不同的,但是建设方法可以相似,数据要统一建设,笔者建议数据按照贴源数据、统一数仓、标签数据、应用数据的标准统一建设。

    2.4 数据资产管理

    通过数据资产体系建立起来的数据资产还是一套偏技术的数据体系,业务人员比较难理解。资产管理是以企业全员更好理解的方式,把企业的数据资产展现给企业全员(当然要考虑权限和安全管控),数据资产管理包括对数据资产目录、元数据、数据质量、数据血缘、数据生命周期等进行管理和展示,以一种更直观的方式展现企业的数据资产,提升企业的数据意识。

    2.5 数据服务体系 

    前面利用数据汇聚、数据开发建设企业数据资产,利用数据管理展现企业的数据资产,但是并没有发挥数据的价值。数据服务体系就是把数据变为一种服务能力,通过数据服务让数据参与到业务,激活整个数据中台,数据服务体系是数据中台存在的价值所在。

    企业的数据服务是千变万化的,中台产品可以带有一些标准服务,但是很难满足企业的服务诉求,大部分服务还是需要通过中台的能力快速定制。数据中台的服务模块并没有自带很多服务,而是提供快速的服务生成能力以及服务的管控、鉴权、计量等功能。

    2.6 运营体系和安全体系

    通过前面的数据汇聚、数据开发、数据资产、资产管理、数据服务,已经完成了整个数据中台的搭建和建设,也已经在业务中发挥一定的价值。

    运营体系和安全体系是数据中台得以健康、持续运转的基础,如果没有它们,数据中台很可能像个一般项目一样,一期搭建起平台、建设部分数据、尝试一两个应用场景之后而止步,无法正常地持续运营,不能持续发挥数据应用价值,这也就完全达不到建设数据中台的目标。

    三、不同行业数据中台解决方案

     

     

     

     

     

     四、总结

    建设数据中台,实现企业或机构数据资产的高效管理和数据价值最大化,为机构带来了数据平台化的运营机制,有望解决应用开发与数据开发速度不匹配的问题。利用数据中台,可以将机构的核心技术或团队凝聚在一起,建设机构内强大的数据开发、运营等团队,提升机构的团队的硬实力和软实力。

    虽然一个良好的架构对一个信息系统的后期扩容及运维有重要作用,但总体架构设计只是数据中台建设的第一步,每一个功能模块还有很大的细化空间,如不同类型数据的存储技术选型、数据安全合规审计技术、数据模型设计等。在具体项目中,数据共享与安全保护的平衡点、新技术的引用等,都需要进一步细化研究。

    展开全文
  • 数据中台系统架构设计

    千次阅读 2021-03-11 01:00:01
    架构总览数据中台通常采用分层架构,各层应用采用微服务化方式构建。针对不同的行业,系统托管方式各不一样,比如传统企业更倾向于采用私有云或自建机房,小型互联网企业倾向采用公有云等;针对不同应用...

    架构总览

    数据中台通常采用分层架构,各层应用采用微服务化方式构建。针对不同的行业,系统托管方式各不一样,比如传统企业更倾向于采用私有云或自建机房,小型互联网企业倾向采用公有云等;针对不同应用场景的不同,技术架构也不相同,比如推荐场景,往往采用实时数据架构,传统报表应用采用离线数据架构;针对数据获取途径,所采用 的技术选型也不相同,比如电商行业的数据通常来源于业务数据库和点击日志等,基于Hadoop生态的数据仓库即可满足查询分析应用,工业企业的数据来源于传感器采集的实时数据,因为工业数据量更大,于是采用的数据采集方式和存储系统的选型差别很大,基于Hadoop的生态存储反而无法满足需求。本文以面向传统工业如燃气、水务等行业为例,讨论如何搭建数据中台,其中主要架构原则要点;

    a. 技术成熟稳定

    b. 系统组合最小化

    c. 选型适度超前

    下图是一个基本的总体架构面貌:

    大数据系统从底向上涉及到的系统或者基础设施依次为:

    a.  客户业务系统:如企业资源计划ERP系统、客户关系管理系统CRM以及各类物联网数据采集设备等;

    b.  数据传输网络:业务系统数据的存储位置可以是公有云、私有云、混合云以及自建的专有云等,数据从业务系统上传到数据存储系统或者通过5G网络设备上传等;

    c.  统一数据采集平台:支持离线数据迁移和实时数据迁移以及按需上报等方式。离线迁移通常采用T-1模式定时从客户业务系统同步到数据存储系统;实时迁移通常基于业务系统的日志实时汇聚到数据存储系统;按需上报的方式通常提供业务系统数据上报接口,随时上报;

    d.  大数据基础平台:包括大数据存储和计算平台,数据存储在分布式文件系统或者对象存储系统,比如HDFS、S3等;数据计算平台分为离线计算平台和实时计算平台,离线计算平台包括Hive、Spark等,实时计算平台分为Storm、Flink等。大数据平台根据数据使用场景方式又可以分为大数据分析平台和算法开发平台;

    e:   数据中台:在大数据基础平台之上,通过平台的赋能实现敏捷开发、快速部署等,如通过屏蔽底层系统的接入门槛和使用差异,将开发流程简化为页面操作,提供简洁、易用的敏捷数据开发平台;通过沉淀通用的业务功能进一步赋能业务开发和价值挖掘,如按照行业标准构建通用的数据模型创建的企业级数据仓库通过公共数据服务接口赋能上层应用。大数据中台包含数据仓库系统、数据治理系统、数据血缘系统等;

    f:  数据服务层:提供统一的数据服务API,上游应用系统通过接口访问数据中台的数据;

    g:  数据应用层:接入数据中台的上层业务应用系统,如智能决策、移动推送等。

    数据流程

    系统架构图也反映了数据加工处理的流程和方向,如果从数据流向的角度来看,大概是这样:

    接入到系统的数据源经过一系列处理之后向上层提供服务,因为数据按照应用场景的时效性要求不同,一般会有离线批处理和实时处理两条链路,实时链路作为离线链路的补充,提供增量数据,在提供给上层应用查询之前,需要合并以反映最终全量的数据,这种架构就是典型的lambda数据架构。

    数据中台系统架构

    为支撑上述数据流程的实施,需要数据中台一揽子功能组件的支持和配合,从应用系统功能组件的视角来看是这样子:

    其中绿色部分表示重要且紧急的功能,是构成数据中台的最小必备选项,而红色表示重要但不紧急的功能,可以延后实现,红绿相间的部分表示可以按需酌情实现的功能。总体层次跟架构总览图差不多:

    a. 数据采集层:提供如 实时、离线、填报等功能

    b. 数据存储与计算层:提供诸如存储引擎、计算引擎和调度引擎等核心基础功能,如存储引擎分为行式存储(如hdfs),列式存储(如hbase);计算引擎分为实时处理、离线处理、机器学习等;调度引擎包括分布式任务调度和分布式资源调度等;

    c. 数据中台:包括基于数据存储与计算层实现的敏捷开发工具套件集,如数据集成工具,开发工具、可视化报表系统、权限管理等;数据开发系统,如数据建模、数据分析和算法开发;以及数据治理平台,包括元数据管理,数据血缘、数据资产管理等;

    d. 数据服务层:通过统一的数据访问接口访问数据中台的数据,如数仓数据、画像数据、推荐数据等;

    e. 数据应用层:通过数据服务层赋能上层业务开发,如营销、个性化推荐、计量分析等。

    数据采集系统

     

    数据采集层连接业务系统和数据存储与计算层,实现业务数据到数据存储系统的转移功能:业务系统数据可以通过sqoop等工具实现离线跑批(全量或增量)的方式进入数据仓库,也可以通过日志流的方式,经过kafka和flink实时进入数据仓库的准备层(ODS)。

    数据存储与计算层

    数据存储与计算层连接数据采集层和数据中台,提供数据存储与计算的基本功能。离线数据可以通过sqoop,datax等传输到基于Hadoop生态的数据仓库,实时数据可以通过Debezium或者canal先暂存到kafka,然后经过Flink等处理后传输到Druid,Doris等,这里可选技术组件较多。

    数据中台

    数据中台连接数据存储与计算层和数据服务层,包含数据开发工具套件集、数据开发系统和数据质量系统。其中数据开发系统包括将来自数据采集层的数据按照一定的规范和模型建立标准的企业数据仓库、在此基础上做的书分析系统如分主题数据建模、模型画像等以及以及算法模型训练相关的算法开发。

    数据仓库层

    数据仓库层连接数据开发平台层和数据服务层,提供标准数据建模方式实现企业级数据仓库。数据仓库实现同样采用分层结构:数据运营层( ODS )、数据仓库层(DW)和数据应用层(ADS):

    ods:是最接近数据源中数据的一层,数据源中的数据,经过抽取、洗净、传输,也就说传说中的 ETL 之后,装入本层。本层的数据,总体上大多是按照源头业务系统的分类方式而分类的。

    dw:DW层又细分为 DWD(Data Warehouse Detail)层和DWS(Data WareHouse Servce)层。

    • dwd层一般保持和ODS层一样的数据粒度,并且提供一定的数据质量保证。同时,为了提高数据明细层的易用性,该层会采用一些维度退化手法,将维度退化至事实表中,减少事实表和维表的关联。另外,在该层也会做一部分的数据聚合,将相同主题的数据汇集到一张表中,提高数据的可用性。

    • dws称数据集市或宽表。按照业务划分,如流量、订单、用户等,生成字段比较多的宽表,用于提供后续的业务查询,OLAP分析,数据分发等。一般来讲,该层的数据表会相对比较少,一张表会涵盖比较多的业务内容,由于其字段较多,因此一般也会称该层的表为宽表。

    ads:提供给数据产品和数据分析使用的数据,一般会存放在 ES、PostgreSql、Redis等系统中供线上系统使用,也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据,一般就放在这里。

    dim:维表层主要包含两部分数据:

    • 高基数维度数据:一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。

    • 低基数维度数据:一般是配置表,比如枚举值对应的中文含义,或者日期维表。数据量可能是个位数或者几千几万。

    数据服务层

    数据服务层连接数据仓库层和上层应用层,实现技术包括微服务在内的整个技术栈体系如访问鉴权、负载均衡和流控等。

    数据中台技术架构举例

    -End-

    展开全文
  • 数据中台功能架构和技术选型

    千次阅读 2021-03-04 08:53:24
    站在企业架构的角度,从广义上来讲,数据中台(包含数据平台,数据仓库)应该提供的服务如下图所示: 1.数据资产的规划和治理 做中台之前,首先需要知道业务价值是什么,从业务角度去思考企业的数据资产是什么。...

    数据中台的典型功能架构:

    广义的讲数据中台是直接服务于业务系统的数据服务工厂,狭义上讲,数据中台就是可复用的数据API。

    站在企业架构的角度,从广义上来讲,数据中台(包含数据平台,数据仓库)应该提供的服务如下图所示:

    1.数据资产的规划和治理

    做中台之前,首先需要知道业务价值是什么,从业务角度去思考企业的数据资产是什么。数据资产不等同于数据,数据资产是唯一的,能为业务产生价值的数据。对于同一堆数据,不同业务部门所关注的数据指标可能完全不同,怎么让各个跨域的业务变成统一的标准,就需要规划企业的数据全景图,将所有有可能用上的、所有对企业有可能有价值的数据都规划出来,最终梳理出企业的数据资产目录。

    在这个时候不需要考虑有没有系统、有没有数据,只需要关注哪些数据是对企业业务有价值的。这一层不建议做得太细,太细就难以形成标准,不能适用于多个场景了。

    数据治理是数据中台很重要的一个领域,ThoughtWorks认为在现在业务边界消失、需求快速变化的情况下,企业需要具备精益数据治理的能力 — — Lean Data Governance。传统的中心化、事前控制式的数据治理方式,要改变为去中心化、事后服务式的治理方式。

    2.数据资产的获取和存储

    从广义上来讲,数据中台要为企业提供强大的数据资产的获取和存储的能力。但是这个能力不是数据中台的核心功能,很多企业可以基于原来的数据平台,数据仓库等已有的工具来提供数据采集和存储的能力。

    3.数据的共享和协作

    企业的数据中台一定是跨域的,需要让所有的人都知道数据资产目录在哪里。不能因为数据安全,就不让大家知道企业有什么数据。没有共享和开放,数据没有办法流动起来,没有流动的话数据的价值产生的速度就会非常慢。

    所以在数据安全的基础上,企业的数据资产目录要对利益相关者、价值创造者开放,要让业务人员能够做到“Self-Service”。

    数据资产目录是数据中台很核心的一个基础能力,但是往往目前很多的企业都尚未建立这个能力,这也是导致数据在企业内部不开放,不共享,不被利用的很重要的一个原因。

    4.业务价值的探索和分析

    数据中台不仅要建立到源数据的通路,还需要提供分析数据的工具和能力,帮助业务人员去探索和发现数据的业务价值。一个好的数据中台解决方案中需要针对不同业务岗位的用户提供个性化的数据探索和分析的工具,并且在此基础上一键生成数据API,以多样化的方式提供给前台系统。

    5.数据服务的构建和治理

    数据中台需要保证数据服务的性能和稳定性,以及数据质量和准确性,还需要具备强大的服务治理能力。数据服务要在一开始就有整体的顶层设计,从而能够将数据服务做分类,打标签,能够更方便的被搜索被调用,让好的服务浮现出来,让质量不高的服务自动的退市被销毁。

    数据中台是一个生态平台,在数据中台上面会不断生长各种数据服务,所以从一开始就构建好数据服务的治理结构是非常重要的,就想经营一个市场一样。

    6.数据服务的度量和运营

    如果数据中台最终只是做到把数据给到业务人员,那它就只是一个搬运工的角色,数据中台的核心是为业务应用提供有业务价值的数据服务。所以度量和运营数据服务的能力是数据中台的业务能力。

    数据中台应该能够对提供的数据服务及相关行为做持续跟踪和记录,包括哪些数据服务被哪个部门使用、用了多少次等,通过这些去度量每一个数据服务的业务价值。

    数据中台是一个需要用互联网思维去经营的利润中心平台,数据中台的经营分析人员需要分析,了解为什么今天上午这个财务部门的人用了数据中台、调用了十次,下午他不用了,原因是什么,调用了这些数据服务的人通常还会调用哪些其他的数据服务。

    这些都需要相应地做记录、做日志、做分析,要把数据当做像电商平台一样去经营,然后实时地根据这些业务行为数据去提醒数据服务提供方,调整、改变、优化数据服务,这才是可经营的数据中台,也只有这样业务部门才能得到最快的支持和响应。

    一个数据中台的典型逻辑功能架构单初步定义:

    企业数据中台的团队如何构建:

    数据中台是距离业务更近的能力平台,数据中台是一个需要持续运营的数据服务业务平台,所以数据中台的团队不仅仅是一个技术团队,应该将数据中台当做一个产品团队来构建,整体的结构如下:

    数据中台提供两类服务:

    一类是数据资产目录,数据探索,数据分析等服务,让业务和应用部门的人员能够在数据中台上协作的玩数据。

    一类是数据服务,让各个业务系统能够调用这些服务,包括决策分析类的非实时服务和实时的嵌入式交易规则服务。

    对应到这两类服务,数据中台的团队应该包括以下三组:

    中台运营团队:

    将整个数据中台的服务和功能作为产品来运营,对应的绩效是用户满意度,用户存留,这些用户相关的指标。

    中台开发团队:

    负责数据中台的功能层开发,包括平中台本身的架构,中台上的应用(客户服务,业务监控等)功能的开发,对应的绩效是功能的稳定性和客户的满意度。

    数据服务开发团队:

    负责数据中台之上的数据服务的开发,包括数据处理链的开发,服务的开发等,对应的绩效是数据服务的稳定性, 性能和客户的满意度等。

    参考这样的三个团队组成, 分别应该包括如下角色:

    数据中台架构师:进行整体数据中台的技术架构设计,保证数据中台架构的可持续性,稳定性和扩容弹性。

    DataOps工程师:从基础能力上保障数据中台的运行的稳定性和持续演进。

    数据工程师:数据处理工程师,负责数据的获取,处理,建立数据处理链。

    数据服务产品团队:数据服务的产品团队,包括产品经理(PO),业务分析师,体验设计师,还有算法工程师,和数据工程师和数据运营分析师一起协作,创新、设计、生产数据服务。

    数据运营分析师:将数据服务作为产品来运营的数据运营分析师,通过对数据服务上线后被调用的情况的分析来运营数据服务,像经营一个互联网产品一样来经营数据服务。

    数据中台某种角度上,上是一个数据服务的创新、生产、交易的数据服务市场,那么企

    业对于数据中台整体的绩效评价方法也就出来了,那就是:

    企业评价数据中台的标准:数据中台服务的客户,也就是业务系统的满意度。

    数据中台支撑技术:

    建设数据中台一般需要一整套如下典型的支撑技术:

    指标管理系统:指标是中台与前台之间最关键的接口,也是建设数据中台的牛鼻子,因为它是最核心的业务语言,且指标不一致、数据常出错是建设数据中台最常见的出发点。如果指标体系没有统一的方法论,进行统一建设,那么就很难说是数据中台。指标管理系统一般要实现一套一致的方法论(如原子 / 派生 / 复合指标、维度、修饰词等),做好指标的业务和技术口径管理,还需要支持指标的审批管理。数据中台的指标无法交给各前台业务自助式的建设。

    数据服务系统:类似于在线业务中台需要通过API网关提供标准化的服务,数据中台也需要一个标准化的服务方式,通常称为数据服务系统,也可以说是数据网关或数据门户。类似于别的网关类产品,数据服务系统需要提供鉴权、日志审计、流控、协议转换(如SQL Dialect之间的转换)等功能,也应该发展多引擎融合查询、逻辑模型等扩展功能以提高服务接口的稳定性和实现的灵活性。

    元数据管理系统:元数据管理是整个数据中台的基础和中心,所有的其他系统都依赖元数据管理。元数据管理首先要做好的当然是数据模式或目录(catalog)的管理,至少要知道中台里都有什么数据。对复杂的数据中台来说,数据血缘也很重要。没有血缘信息,不知道数据间的依赖关系,数据质量肯定管不好,因为不知道一个数据的质量问题怎么来,又进而会影响什么。

    同样的,如果没有血缘,数据资产也肯定管不好,因为不知道什么数据有价值什么没价值,这就像如果你不知道一个函数被谁调用,你就不知道它是不是死代码一样。元数据管理系统往往也需要提供一个基础的访问界面,通常称之为数据地图。

    数据仓库开发与管理系统:除了指标管理,数据仓库的开发是将一大堆初始数据建设梳理成一个漂亮的数据中台的核心过程。一般来讲数据中台更适合用Kimball的维度建模方法而非数据仓库之父Bill Inmon所提倡的方法,这是因为Inmon强调顶层设计,而Kimball强调至下而上。

    如果要建设数据中台,肯定是因为前台业务复杂多变,这时强调顶层设计会导致中台建设缓慢、僵化。因为中台虽然应该是由组织高层决策,但目的却是为了支持前台业务,而不是为了控制。*支持而不是控制*,这一点绝不能本末倒置。

    数据质量管理系统:所有复杂的系统都需要专业的质量管理,在线业务系统有一系列的弹力设计和APM等监控运维工具,数据中台也需要专业的质量管理。数据质量管理系统通常设计为支持丰富的稽核 / 校验 / 比对规则,监控数据是否准确、实时、一致,还要做到及时的报警,分析影响面,提供快速修复的手段等。

    但这些手段只能发现和补救问题,不能预防问题,要预防问题,还要通过测试工具减少代码bug、通过资源弹性应对性能波动、通过优先级调度优先满足重要业务需求等。

    相对来说,当前数据中台领域的质量管理没有在线业务领域的成熟,如在线业务领域的测试手段远比数据领域的精细,在线业务领域很常见的熔断、限流、服务降级等模式在数据领域都没有成熟的实践方法(优先级调度可以说是实现了部分的服务降级功能),随着数据中台越来越广泛和重要,这些技术应该也需要持续发展,但技术上的挑战不小。

    数据安全管理系统:数据中台因为汇集了组织所有有价值的数据资产,因此良好的安全管理是必须的。细粒度的权限和审计是基础,一般的还需要隐私 / 敏感数据的脱敏处理、数据加密(特别是将数据托管在第三方平台之上时)、数据泄漏防护(比方说一种常见的方法是限制将数据下载到本地的数据量)等技术。发展到高级阶段甚至可能还需要联邦学习、数据沙盒等技术。

    数据资产管理系统:在数据质量和安全单列的情况下,数据资产管理主要负责的是数据的生命周期管理、成本的统计分析与优化等工作。

    同时,数据中台还需要强大的大数据计算引擎、数据集成 / 同步 / 交换引擎,还往往需要一套敏捷BI系统:

    大数据计算引擎:数据中台要管理的数据规模和复杂度往往都很高(否则搞中台属于为赋新词强说愁),所以传统的数据库和数据仓库基本上支撑不了。当前的技术环境下,基于Hadoop MapReduce或Spark几乎是唯二的选择,当然这也包括了这两者之上的Hive和Spark SQL。能有SQL就用SQL,易于维护,也易于数据血缘的收集。除此之外,流处理可能还需要Flink,交互式查询可能要引入Impala或GreenPlum。

    数据集成 / 同步 / 交换引擎:一方面数据中台需要强大的数据集成和同步能力才能吸纳各方数据。集成和同步的概念相近,同步更强调实时性。另一方面,数据中台往往由多种数据计算引擎构成,就需要同步或交换引擎实现不同引擎见的数据交换。

    敏捷BI系统:建设数据中台通常最重要的目的是为了支持业务运营和决策,为此需要基于数据中台进一步开发数据产品。敏捷BI系统是开发数据产品快速、轻型的手段,能够尽快尽早的发挥数据中台的价值。

    此外,对于互联网业务,统一的埋点引擎往往也是数据中台所需要的。如果埋点的逻辑都不统一的话,建数据中台的时候会发现数据的源头就是乱的,后续也都没法做。其他行业业务,数据采集也属于基础工作,也是要先做好的。

    数据中台技术选型参考:

    在搭建数据中台方面,基于开源技术的选型,尤其是Hadoop生态圈有非常多的选择,从数据整体流向来看各大层级的选型。

    数据抽取层:sqoop和flume是两大主流工具,其中sqoop作为结构化数据(关系型数据库)离线抽取,flume作为非结构化日志接入;

    数据存储层:Hadoop文件系统Hdfs大家都比较了解,而kafka作为流式数据总线应用也非常广泛;

    计算与调度层,包括:

    离线计算:离线计算主要是hive,spark,也有部分选用tez

    实时计算:前些年storm,spark比较流行,最近几年大家纷纷往Flink转型

    数据调度:除了像Airflow Azkaban Oozie等,易观开源的Dolphin-scheduler也非常活跃

    数据引擎层:也就是我们常说的OLAP层,我们看到这一层里的选择非常多,就不一一列举了,(业务需求带动技术进步的典型,选择丰富主要是可以适配不同的数据应用场景)。从概念上讲分为ROLAP、MOLAP以及两者混搭。MOLAP提前做一些预计算,以生成Cube的方式,达到空间换取查询效率;而ROLAP是即查即用,效率完全取决于查询引擎的性能,我个人认为从将来看,ROLAP的趋势会更加明显,因为没有中间的数据链路。但目前看来,没有一个统一的引擎足以支撑各类数据场景(这或许是将来的机会~);

    数据可视化层:比较主流的有Metabase、Superset、Redash,也可以选择阿里、百度的一些开源控件。

    在开源技术的选择里,我们看到各层里都有越来越多国内开源的工具(也充分体现了我们在大数据技术领域的进步)。除了以上列举的这些,整个Hadoop生态圈的技术选择非常多,可以结合自己的实际场景选择自己的架构,在选型层面可以参照的一些原则,比如:

    是否有鲜活的成功案例,优先找自己类似业务场景;

    接口的开放性,与其他组件的兼容性;

    社区活跃性度&发展趋势。

    展开全文
  • 你被大数据杀过熟吗?当今企业对数据的重视度越来越高,在大数据系统架构设计层面,大数据架构师需要完成技术决策、技术选型,还需要根据不同时期的业务场景,不断优化和演进软件架构,最终攻克技术难...

    你被大数据杀过熟吗?当今企业对数据的重视度越来越高,在大数据系统架构设计层面,大数据架构师需要完成技术决策、技术选型,还需要根据不同时期的业务场景,不断优化和演进软件架构,最终攻克技术难点、化解技术风险,创造符合企业长期发展的大数据架构。

    那么,怎样的架构最能满足降本增效?2015年,阿里率先布局“大中台,小前台”战略,虽然张勇近期在阿里内网表示,他对目前阿里的中台并不满意,但“大数据中台”这个由中台延伸出的概念,已然成为行业标配。

    数据中台,是中台战略体系中非常重要的一部分。身为一名大数据架构师,在落地大数据中台架构的过程中,需要具备哪些架构能力和大数据能力?有哪些可复用的优秀经验,以及需要规避的问题点?

    孙玄,前58集团技术委员会主席,前转转二手交易平台首席架构师。今天他想跟你聊聊,那些百万年薪大数据架构师的精益求精之道。

    01

    一个10年首席架构师的自白

    作为前58集团技术委员会主席、前58转转首席架构师,我最近一直在反复问自己一个大数据架构师成长问题:百万年薪大数据架构师的核心竞争力,到底是什么?我认为,是对架构设计的升维认知,以及所具备的顶级思维模型。

    作为百万年薪大数据架构师的顶级思维模型之一:根据(业务)场景Balance的架构设计思维模型。BAT超一线大厂大数据架构设计固然优秀,但照搬拷贝就变的很可笑。作为顶级架构师你需要根据所处公司的业务特点、请求并发、数据规模等场景给出灵活优雅的架构设计解决方案,满足公司未来6个月到2年的业务发展需求。

    02

    百花齐放的大数据架构模式

    具备这些顶级架构设计思维模型,也就具备了大数据架构设计的哲学本质,从而形成了以不变应万变的架构设计能力,在面对任何复杂的业务场景都能够给出优雅的架构解决方案。

    具备这些顶级大数据架构设计思维模型,也就具备了大数据架构设计的“道”,也就彻底明白百花齐放的架构模式(OLTP架构、OLAP离线架构、OLAP实时架构、Lambda架构、Kappa架构、中台化架构、云原生架构等)只为满足各类企业不同场景的业务需求,从而能够真正做到架构设计的终极目标降本增效。在新技术日新月异变化的今天才不会迷失方向,才不会担心惧怕所谓35岁年龄问题。

    那么,如何拥有这些顶级架构思维模型?我想,只有切实在企业级真实架构设计实践才能出真知!

    回想我成长为首席架构师之路,也的确践行了这套方法论。2012年负责IM架构设计、2013年负责招聘业务大数据架构设计、2014年负责房产业务大数据架构设计、2015年二手电商大数据中台架构设计……通过不同业务场景、不同请求并发、不同数据规模、不同安全要求等异构场景架构设计的千锤百炼,才让我真正拥有了这些顶级架构设计思维模型。

    大数据架构师9大顶级思维模型

    但回归企业现状,绝大数同学们都没有这样的企业真实案例的历练机会,如何帮助他们拥有这些大数据架构设计思维模型,学习和模仿是快速提升之路。由我联手 58 快狗打车 CTO 沈剑老师,结合10多年一线大厂实践经验,打造的《百万年薪大数据架构师必备能力—PB级企业高可用高可靠高性能大数据中台架构设计与实践》精品在线课,马上开班,只用2天时间,带你快速掌握三高大数据中台架构设计核心技术,从而具备顶级架构设计思维模型,如果学完后还不能真正掌握,来找我算账就好……

    本公众号仅限前50名特惠购买

    购买后请您耐心等待课程顾问通过~

    长按扫码报名,锁定9.8特惠名额

    精品专栏课原价499,现在花9.8就能拿下,只要半杯奶茶钱,就能换来9大模块名师精心打磨的百万年薪大数据架构师技术和思维模型实战课,相当划算!1月26-27日,绝对是市面上唯一的一门百万年薪大数据架构设计与实践精品课,也是P8级大数据架构师必须掌握的核心能力!

    精品课程为期2天,内容由2大篇章9大模块构成,包括:

    • Day01 总体架构设计哲学篇:PB级企业三高大数据中台总体架构设计与实践

    • Day02 重塑数据中台实践篇:PB级企业三高大数据中台架构真实案例设计与实践

    通过通俗易懂的万亿级企业案例式讲解,带你真正掌握百万年薪大数据架构师的架构设计能力和顶级思维模型,从而在成为百万年薪架构师的路上越走越快!

    总之,通过从PB级企业三高大数据中台架构体系设计核心技术,到企业海量大数据中台架构设计线,再到PB级企业真实业务应用的深度剖析,使得同学们全方面立体掌握三高大数据中台架构设计与实践,同时拥有百万年薪架构师的顶级思维模型。

     

    课程都有哪些特色

    (1)首次完整揭秘百万年薪大数据架构师9大顶级架构设计思维模型;

    (2)以PB级企业真实三高大数据全域中台架构设计为例,完整剖析百万年薪大数据架构师思维模型;

    (3)彻底揭秘PB级企业三高大数据中台架构设计哲学本质,沉淀大数据中台架构设计方法论;

    (4)彻底揭秘PB级企业三高大数据中台总体架构演进哲学本质;

    (5)彻底揭秘PB级企业三高大数据调度中台架构设计方法论与实践;

    (6)彻底揭秘PB级企业三高大数据实时/离线仓库中台架构设计方法论与实践;

    (7)彻底揭秘PB级企业三高大数据事件模型中台架构设计方法论与实践;

    (8)完整揭秘百万年薪大数据架构师快速成长之路。

    2大篇章9模块核心架构技术

    彻底揭秘PB级大数据中台架构之道!

     

    超强名师带你学!

    超强收获

    (1)掌握百万年薪大数据架构师的9大顶级架构设计思维模型,具备以不变应万变的大数据架构设计能力;

    (2)掌握PB级企业三高大数据架构设计哲学本质,沉淀大数据架构设计方法论,从而能够给出优雅架构设计解决方案;

    (3)掌握PB级企业三高大数据调度中台设计方法论与实践,能够确保在生产环境中稳定运行;

    (4)掌握PB级企业三高动态配置化全域大数据离线/实时仓库中台架构设计方法论与实践,再也不惧怕并发的业务需求;

    (5)掌握PB级企业三高大数据事件模型中台架构设计方法论与实践,能够优雅应对业务场景需求;

    (6)掌握PB级企业三高大数据架构设计在阿里电商等不同企业场景的真实设计与实践,能够做到举一反三。

     

    哪些人群适合学习

    如果你是一名:

    • 系统架构师

    • 业务架构师

    • 云原生架构师

    • 大数据架构师

    • 硬件/嵌入式系统架构师

    • 运维架构师

    • DBA架构师

    • 测试架构师

    • 解决方案架构师

    • 技术负责人/技术经理/技术总监/技术VP/CTO

    • 项目经理/项目总监

    • 进一步提升大数据架构设计认知和思维模型的其他职位

    • ……

    那么,PB级企业高可用高可靠高性能大数据中台架构设计与实践这门实践精品课,正是为你量身定制的!

     

    真实好评,名师玄姐口碑爆棚!

    左右滑动查看更多

    百万年薪大数据架构师都研究的PB级大数据中台

    你需要真正掌握它!

    9 大模块架构设计硬核干货

    仅需2天 彻底搞懂

    原价499限时扫码9.8

    快速搞定大数据中台架构和顶级思维模型!

    ????????????

    本公众号仅限前50名特惠购买

    购买后请您耐心等待课程顾问通过

     

    关于奈学教育

    点击查看“阅读原文”,了解奈学教育更多课程内容!

    展开全文
  • 【数商云】在电子商务系统搭建行业有近十几年的服务经验,近年来的数据中台、业务中台等系统架构兴起,大多数企业在不清楚的中台背景的情况下就盲目追求,最后只会导致自身平台丢失原有的优势框架。在这里,我们来...
  • 数据中台建设的价值架构 数据中台的终极使命是赋予数据资产价值变现的能力,无论是通过业务赋能的形式隐性变现,还是通过数据服务公开交易的直接变现。它们都需要一个很重要的基础条件“数据资产化”。 数据中台...
  • 数据中台各种架构图大全

    千次阅读 2021-02-03 00:00:00
    数据中台是指通过数据技术,对海量数据进行采集、计算、存储、加工,同时统一标准和口径。数据中台把数据统一之后,会形成标准数据,再进行存储,形成大数据资产层,进而为客户提供高效服务。以下是...
  • AI 中台的定位AI 中台是实现 AI 技术在千行百业快速研发、共享复用和高效部署管理的智能化基础底座,是智能化能力普惠的关键基础设施可以认为,AI 中台是企业中台的重要组成部分,以加快...
  • AI中台架构模型解析

    2021-03-27 00:59:42
    传统上,企业部署AI应用,一般通过单点开发的方式,即“烟囱式”架构部署AI应用。海量AI应用场景爆发使得原来传统的“烟囱式“AI开发流程无法跟上业务的快速变化,开发速度慢、周期长。越来越多...
  • 阿里及各大企业中台架构详解

    千次阅读 2021-01-10 17:02:00
    IaaS主要是运维负责。 ebay中台架构 staffjoy 中台 参考 https://www2.slideshare.net/tcng3716/ebay-architecture
  • 数据中台需要采集数据作为原材料进行数据加工、数据建模、然后分门别类地储存,再根据实际的业 务场景,打造各类数据服务(含数据应用平台)从而实现对业务的赋能加速。 但以上流程的实现,需要有对应的系统与产品...
  • 第一部分认识中台——微服务设计为什么要选择DDD 一、微服务拆分和设计的困境 微服务的粒度应该如何把握?微服务到底应该如何拆分和设计?微服务的边界到底应该在哪里? 微服务拆分困境产生的根本原因,就是不...
  • 什么是中台? 我个人的理解为.将所有项目的共同业务分离开来,然后把共同的业务塞进同一个微服务; 列如:一个公司有多个项目, 每个项目呢都会有会员模块. 订单模块.等相同的业务. 把所有项目的会员模块都由一个...
  • 4、支持按照优先级匹配策略进行路由,并能启动、停止路由策略 5、支持静态路由,API在运行过程根据Header或URI的标签内容进行分支路由 6、支持穿透式路由,服务对消息不进行解析或者只进行部分解析即可发送给其 ...
  • C/C++ Linux后台服务器开发高级架构师学习知识点路线总结(2021架构师篇完整版) 前言: 小编之前有跟大家分享过一篇架构师体系知识点总结的文章,今天在原来的基础上有所改变更新(2021版)。 相信大家也知道,...
  • 《通知》明确指出,要探索构建适应企业业务特点和发展需求的“数据中台”等新型IT架构模式,建设敏捷高效可复用的新一代数字技术基础设施,加快形成集团级数字技术赋能平台,提升核心架构自主研发水平,为业务数字化...
  • 中台架构,是将企业的核心能力随着业务不断发展以数字化形式沉淀到平台,形成以服务为中心,由业务台和数据中台构建起数据闭环运转的运营体系,供企业更高效的进行业务探索和创新,实现以数字化资产的形态构建...
  • 数据中台之数据服务

    2021-04-13 17:34:43
    一. 简介 DataWorks数据服务旨在为企业搭建统一的数据服务总线,帮助企业统一管理对内对外的API服务。...数据中台 数据服务 架构 1. 生成API 数据服务支持通过可视化配置的向导模式,快速将关系型数据库和NoSQL
  • 但对于大多数大、中型企业来说,这种应用模式是非常不可取的:一方面会使整个企业Web 应用的效率降低,另一...目前主流的应用模式是采用两或多服务器,一为前端的Web服务器,另一作为后台的数据库服务器。We...
  • 导读:百度交易中台作为集团移动生态战略的基础设施,面向收银交易与清分结算场景,为赋能业务提供高效交易生态搭建。目前支持百度体系内多个产品线,主要包含:小程序,地图打车,百家号,招财猫,好看...
  • 1、服务器架构演变的最主要的原因是 2、典型的服务器架构介绍 3、流行的服务器介绍 4、关于服务器架构分布式的看法 5、总结 今天写一下游戏服务器的架构,主要还是还是分析下服务器架构的原理,以及解决的...
  • 1、单体架构:将所有业务的表现层,业务逻辑层,数据访问层放在一个工程最终部署在一服务器 2、垂直架构:按业务场景拆分为互不相干的单体架构项目 3、前后端分离:前端关注页面样式与动态数据的解析及渲染,...
  • C/C++Linux服务器开发/后台架构师知识体系1. 精进基石专栏1.1 数据结构与算法面试必聊的排序与KMP随处可见的红黑树磁盘存储链式的B树与B+树海量数据去重的Hash与布隆过滤器,bitmap图论算法,di jkstra,dfs,bfs,...
  • 12月16-17日,由CNCF、网易数帆、VMware、PingCAP和阿里云联合主办2020 Cloud Native Day云原生生态大会线上...在大会的第二天,网易数帆轻舟事业部微服务平台负责人冯常健、网易数帆轻舟事业部资深解决方案架构师王必
  • 在服务器虚拟化技术,被虚拟出来的服务器称为虚拟机(Virtual Machine,VM)。运行在虚拟机里的操作系统称为客户操作系统,即Guest OS。负责管理虚拟机的软件称为虚拟机管理器,缩写为VMM,也称为Hypervisor。服务器...
  • 准备四虚拟机,关闭防火墙及selinux 192.168.181.130 manager 192.168.181.142 mysql主 192.168.181.168 slave1 192.168.181.169 slave2 免密操作 130,142,168,169 ssh-keygen ssh-copy-id mysql安装及配置文件的...
  • 基于Spring Cloud Alibaba 分布式微服务高并发数据平台化(中台)思想+多租户saas设计的企业开发架构,支持源码二次开发、支持其他业务系统集成、集中式应用权限管理、支持拓展其他任意子项目。 一、架构技术选型二、...
  • 来自2020中国软件技术大会的PPT 分享版 技术架构变革 孔峰 数据中台在数字...关键字:架构设计 技术架构 架构师 软件架构 中台 数据中台 说 明:本资源收集于网络,如侵犯了您的权益,请与我联系告知以便删除。 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 517,019
精华内容 206,807
关键字:

中台服务架构