苏宁大数据中台技术架构

合集下载

数据中台技术路线

数据中台技术路线

技术路线分布式大数据平台分布式大数据平台(TBDS)是可靠、安全、易用的一站式大数据处理平台,提供了多种高性能分析引擎方便应对实时流数据处理、离线批数据分析、实时多维分析等场景的海量数据分析挑战。

此外,还提供了全链路的数据开发以及数据治理服务帮助提升大数据开发效率。

面对数据仓库、用户画像、精准推荐、风险管控等应用场景挑战,TBDS提供一体化大数据应用解决方案。

分布式HTAP数据库提供分布式HTAP数据库TBase 采用无共享的集群架构,提供监控、安全、审计等全套解决方案,适用于GB~PB级海量HTAP 场景。

高效的OLTP/OLAP 能力,分布式HTAP数据库TBase 支持千万级的TPS 事务处理能力,具有全局sequence 功能。

TPC-DS 性能测试结果业界领先,采用高效的压缩算法,压缩比超过400:1。

强大的数据治理能力,分布式HTAP数据库TBase 提供弹性在线扩容能力。

同时提供数据的冷热分离解决方案以及数据防倾斜的解决方案。

数据汇聚数据汇聚采用前后端分离模式部署,前端采用静态页面的形式提高用户的并发访问,后端采用springboot框架编写业务框架。

抽取数据部分采用python脚本的方式,仅消耗本机内存。

后端api服务以及汇聚执行器均可分布式部署。

任务调度采用quartz自带的调度任务锁的形式,保持高可用和防止重复调度出现。

汇聚执行器采用多机器部署的方式,在汇聚开始时,根据当前各个节点分布的任务情况,选择可用的任务少的节点开始任务。

数据标准化数据标准化从技术架构上引入了LUCENE、HANLP、CAFFENIE、SPARK、SPRINGEL等先进技术,在数据对标、数据处理。

使数据标准化平台可以极大的提高对标效率与数据计算处理后端api服务以及标准执行器均可分布式部署。

任务调度采用quartz自带的调度任务锁的形式,保持高可用和防止重复调度出现。

标准执行器采用多机器部署的方式,在标准化开始时,根据当前各个节点分布的任务情况,选择可用的任务少的节点开始任务。

苏宁电器组织结构

苏宁电器组织结构

苏宁电器组织结构分析64103022 徐颖一、组织结构的重要性企业组织结构是指企业全体员工为实现企业目标而进行的分工协作,在职务范围、责任、权力方面所形成的结构体系。

随着企业的产生和发展及领导体制的演变,企业组织结构形式也经历了一个发展变化的过程。

组织作为一项重要的管理职能,其形成和存在的基础在于,由于各种因素的限制,一个人或几个人的独立活动不能实现既定的目标。

在日常生活和实际工作中,一方面每个人都从属于一个或多个组织,另一方面多数工作又是由多人合作才能完成。

因此,建立一个良好的组织结构并使之有效地运转,这无论是对个人目标还是组织目标的实现,都至关重要。

二、苏宁电器公司总部的组织结构苏宁电器1990年创立于江苏南京,是中国3C(家电、电脑、通讯)家电连锁零售企业的领先者,国家商务部重点培育的“全国15家大型商业企业集团”之一。

经过20年的发展,现已成为中国最大的商业企业集团,品牌价值508.31亿元。

营销总部由采购管理中心、市场策划管理中心、连锁店管理中心和团购管理中心构成,全面负责全国的营销系统管理工作;连锁发展总部由连锁发展中心、设计中心、物流基地建设项目部和装饰工程管理中心组成,全面负责连锁拓展相关工作;服务总部由物流管理中心、售后服务管理中心、客户服务管理中心组成,全面负责服务体系的建设和日常运营;财务总部包括财务管理中心、结算管理中心、费用管理中心、信息系统中心等部门,全面负责苏宁的费用管理控制工作。

其具体部门为:董事长(1)召集和主持董事会议,组织讨论和决定公司的发展战略、经营方针、年度计划、财务预算、投资及日常经营工作的重大事项;(2) 审核公司机构调整和重大管理制度改革方案,提交董事会审核、审批;(3) 检查董事会议决议的实施情况,并向董事会提出报告;(4) 提议公司总经理和其它高层人员的聘用、升级、薪酬及解聘,并报董事会批准和备案;(5) 根据总经理的提议,审核公司中层管理人员和高级技术人员的聘任、薪酬和解聘;(6) 审核总经理提出的各项发展计划及执行结果;7) 对公司总经理和高层人员的工作进行考核和监控;(8) 定期审阅公司的财务报表和其它重要报表,按规定对公司的重大财务支出和资金事项进行审核、审批;(9) 签署公司的出资证明书、投资合同书及其它重大合同书、报表与重要文件、资料;(10) 签署批准公司招、解聘中级管理人员和高级技术人员;(11) 在日常工作中对公司的重要业务活动给予指导和监控;(12) 行使法定代表职权;总经理总经理:总经理为集团公司企业最高行政管理领导人,对集团公司企业全局业务全面负责。

技术中台架构概述

技术中台架构概述

技术中台架构概述【摘要】中台不能算是一个新的概念,只不过把它从一个单一系统扩展到了企业内部所有系统和组织级(企业架构级)的概念。

那么时下“中台”的本质究竟是什么?技术中台又该如何理解?前台、中台、后台的概念早就有之,只不过不同的场景下有不同的内涵。

前中后台是从应用系统架构层次来说的,比如早期C1ient-Server是前后台的关系,没有中台的概念,后来发展为三层架构(表示层U1业务逻辑层、和数据访问层),把业务逻辑和数据访问分离,形成前中后台架构。

中台不能算是一个新的概念,只不过把它从一个单一系统扩展到了企业内部所有系统和组织级(企业架构级)的概念。

单体系统中的业务架构、数据架构、应用架构和技术架构体系通过把可共享组织服务、可共享数据服务、可共享业务服务、可共享技术服务等提取沉淀,进化为融合企业架构组织中台架构、数据中台架构、业务中台架构和技术中台架构体系。

而把曾经的应用CIient端作为轻量化业务应用部署于不同的渠道为客户提供服务,从而形成了适合规模化业务体系的、适合当前技术发展趋势的、更完善的融合中台架构。

X图1单体架构到融合架构趋势前台是各条线业务应用的轻量化客户端,可以部署于不同的业务渠道(比如App、Web、微信小程序等)。

中台是可复用可共享服务,包括实现不同业务逻辑的业务服务、封装数据访问的数据服务、业务交互或数据交互用到的技术组件服务。

后台是支撑中台服务运行和部署的数据库、数据仓库、大数据平台、中间件平台、PaaS平台等。

这些平台和工具的底层是基础设施资源,这样中台架构就比较清晰地进行层次划分和定义。

“中台”是一系列系统可复用能力的集合。

从前、中、后系统层次架构(图2前中后台架构)来看,把整个企业的各种系统看作不同的组件,所有的系统最终融合为一个系统,那么前、中、后台相对就容易理解了。

前台就是“表示层“,也就是业务应用前端,其是通过服务编排而成的轻量化应用;其调用可复用的业务逻辑单元,这可以称为“业务中台”;业务逻辑单元则调用可复用的封装数据访问的组件,这可以称为“数据中台”,其下其实还有一层数据库或数据平台,以及中间件、PaaS平台等就是所谓的“技术后台”。

数据中台技术方案

数据中台技术方案

数据中台技术方案本技术方案主要明确公司数据中台建设目标、建设原则、能力框架、技术要求和演进策略等内容,为公司数据中台建设提供技术指导。

一、建设背景(一)建设现状当前公司信息内网建成了覆盖公司总部及27家省(市)公司的两级全业务统一数据中心分析域,初步具备了数据接入、数据存储计算、数据分析应用相关能力,实现公司核心业务系统数据的接入及整合汇聚,支撑了各专业数据分析类应用的构建。

在数据接入方面:通过OGG、ETL等技术实现业务系统结构化数据接入至分析域贴源区,通过采集量测数据接入工具实现采集量测数据接入大数据平台。

在数据存储方面:贴源历史层采用分布式关系型数据库(SG-RDB-MS)实现各业务系统贴源数据的存储。

数据仓库层采用MPP数据库(GBase8a),基于统一数据模型(SG-CIM)实现部分数据标准化存储。

数据集市层采用关系型数据库(SG-RDB-PG)实现分析计算后结果数据存储;采集量测数据采用大数据平台分布式列式数据库(Hbase)进行存储。

在数据计算方面:针对小规模数据计算分析需求,通过MPP数据库(Gbase8a)并行计算技术实现。

针对大批量的离线计算需求通过大数据平台批量计算组件(MapReduce)实现。

针对实时数据计算需求,通过大数据平台实时消息队列(kafka)、内存计算(Spark)、流计算(Storm)等组件实现。

在数据应用方面:针对大数据分析应用需求,通过自助式分析工具、Tableau等工具实现。

(二)存在问题当前分析域在各单位分析应用中发挥了一定的作用,但从应用角度来看仍存在技术门槛高、数据难读懂、数据获取难等问题,具体如下:1.技术组件多样,应用难度大。

分析域主要包括数据接入、数据存储、数据计算等方面的21个技术组件,涉及厂商多,技术体系性差,组件之间技术集成复杂,相关工具友好性不足,对专业能力要求高,应用难度大。

2.找数据困难,数据应用门槛高。

一是当前分析域未形成完整的数据资源目录,数据资源检索困难;二是分析域目前尚未构建数据服务,数据应用复用性差,增加数据应用难度。

大数据平台的系统架构设计与实现

大数据平台的系统架构设计与实现

大数据平台的系统架构设计与实现随着数字化时代的到来,大数据已经成为了一个重要的话题。

如何利用大数据,成为现代企业的一个重要命题。

为了有效管理和利用数据,传统的数据存储已经无法满足需求,这时候,大数据平台便应运而生。

大数据平台是一个能够支持快速处理和分析大量数据的系统集成方案。

在大数据时代,大数据平台的架构设计和实现是至关重要的。

一、大数据平台的架构设计大数据平台的结构设计通常包括以下几个部分:1. 数据源数据源指大数据平台获取数据的渠道,包括传感器、社交媒体、Web应用程序和传统数据库等。

在架构设计中,需要将数据源进行分类,以便于后续数据分析和处理。

2. 数据采集数据采集是将数据从数据源获取,并将其存储到大数据平台中。

大数据平台通常使用一些常见的大数据工具,如Storm、Kafka和Flume等。

这些工具能够帮助我们获取数据,并将其按照指定的格式写入数据仓库。

3. 数据仓库数据仓库是大数据平台的核心部件。

在数据仓库中,数据被存储在一个中央位置中,并且能够轻松地进行分析和处理。

大数据仓库通常包括存储、索引和查询三个组件。

4. 数据分析数据分析是大数据平台的一个重要组成部分,它可以利用大数据平台存储的数据来寻找数据中隐藏的模式或者规律。

对于大数据平台而言,数据分析通常具有以下几个阶段:(1) 数据预处理:数据预处理是数据分析的第一步,通过预处理,可以帮助我们检查数据是否完整、是否合法,以及数据的质量是否需要进行改进。

(2) 数据挖掘:数据挖掘是数据分析过程中最复杂和最关键的部分,通过数据挖掘,可以找到数据中隐藏的规律和模式,帮助我们更好地理解数据。

(3) 数据可视化:数据可视化可以让我们更加方便地理解数据分析结果。

通过数据可视化,可以将数据分析结果以图表等形式呈现出来,使得数据分析结果更加直观。

二、大数据平台的实现大数据平台的实现需要考虑多方面的因素,包括硬件和软件等。

下面我们从几个方面来讨论大数据平台的实现。

数据中台技术架构解读

数据中台技术架构解读

数据中台技术架构解读目录前言 (3)一当前关于“中台”问题研究存在诸多问题 (3)二科学界定“数据中台”问题的基本原则 (7)三小数据是理解数据中台的关键 (11)前言数据中台最近特别火,之前还在炒概念,现在突然就看到有的企业已经宣传自家的数据中台了,有的企业向外介绍如何构建自己的数据中台,利用数据中台打造数据驱动的经营能力。

大家热衷于讨论什么是“数据中台”,并且还有“有一千个企业,就有一千个数据中台”的说法,但大家真的都理解了什么是数据中台了吗?本文基于笔者的个人思考,首先介绍了当前关于“中台”问题研究存在的3个主要问题,然后从3个方面说明了科学界定数据中台的基本原则,最后指出小数据是理解数据中台的关键,以更加科学合理的角度使读者更加清晰、全面的认识数据中台。

”一当前关于“中台”问题研究存在诸多问题Supercell,芬兰移动游戏巨头,成立于2010年,拥有《部落冲突》、《卡通农场》、《海岛奇兵》、《皇室战争》和《荒野乱斗》等全球热门游戏。

据说,2015年12月马云亲自率队到Supercell公司进行商务拜访,马云对Supercell的高效运营无比感慨,将其经营秘密概括为中台战略,要求阿里巴巴按照“大中台、小前台”的组织原则进行公司架构改革。

不管上述“中台”的马云说是否属实,但“中台”的概念确实在近年来不断发酵并从去年开始流行起来,日益成为行业共识,但大家对如何认识这个共识还没有达成一致意见,同时当前关于“中台”问题的研究还存在诸多问题。

1.1对数据中台的定义不清目前关于数据中台的定义很多,笔者根据网上数据中台相关著作或文章,搜集了一些对数据中台的定义,供读者参考,如下表所示。

表1 网上关于数据中台的定义从上表这些定义来看,人们对于中台的解释还是很不一致的,有的定义甚至还谈不上是严格的定义,充其量只能说是对其某方面属性的简单描述,还谈不上是对其本质属性的界定。

1.2缺乏明确的数据中台架构模型阿里巴巴从2009年就开始建设共享业务事业部,已经为中台战略在转型过程中将会面临的组织间业务协作、业务核心能力的沉淀、组织KPI考核等方面都做了很好的实践和经验沉淀,阿里巴巴共享业务事业部的架构图也被阿里的人看作是解读阿里中台战略最常用的一个图,讨论阿里中台战略的时候都会用到。

数据中心总体架构

数据中心总体架构

数据中心总体架构随着信息技术的快速发展,数据中心已成为现代企业运营的关键基础设施。

数据中心总体架构的设计与实施,对于确保企业数据的安全、可靠和高效利用至关重要。

本文将探讨数据中心总体架构的构成及实施策略。

一、数据中心总体架构概述数据中心总体架构是指对数据中心的硬件、软件、网络等基础设施进行统一规划、设计和实施,以满足企业业务需求的一种结构模式。

它主要包括基础设施层、网络层、计算层、存储层和应用层五个层面,每个层面都有其特定的功能和作用。

二、基础设施层基础设施层是数据中心总体架构的基础,主要包括场地设施、供电设施、制冷设施等。

这一层的主要任务是确保数据中心的物理环境安全、稳定,能够为上层建筑提供可靠的支撑。

在实施过程中,需要考虑场地选址、电力供应、制冷系统设计等因素,以保证数据中心的正常运行。

三、网络层网络层是连接数据中心内部各个设备的桥梁,主要负责数据的传输和交互。

在网络层的设计和实施过程中,需要考虑到网络的扩展性、稳定性、安全性等因素。

常用的技术包括局域网(LAN)、存储区域网络(SAN)等。

四、计算层计算层是数据中心的“大脑”,主要负责数据处理和计算。

在设计和实施计算层时,需要考虑计算能力、存储能力、网络接口等因素。

常用的技术包括服务器、路由器、交换机等。

五、存储层存储层是数据中心的重要组成部分,主要负责数据的存储和管理。

在设计和实施存储层时,需要考虑数据安全性、可扩展性、可用性等因素。

常用的技术包括独立磁盘冗余阵列(RAID)、网络附着存储(NAS)、直接附加存储(DAS)等。

六、应用层应用层是数据中心总体架构的顶层,主要负责实现企业的业务需求。

应用层的设计和实施需要结合企业的实际业务需求,考虑软件功能、用户体验等因素。

常用的技术包括数据库管理系统(DBMS)、中间件等。

七、数据中心总体架构实施策略1、统一规划:在设计和实施数据中心总体架构时,需要对基础设施、网络、计算、存储和应用等方面进行全面考虑,确保各个层面之间的协调一致。

中台技术架构解读

中台技术架构解读

中台技术架构解读中台不同于平台,那么到底啥是中台?1、哪些不是中台,而是应该叫平台做开发,有所谓的三层技术架构:前端展示层、中间逻辑层、后端数据层。

我们现在讲的中台不在这个维度上。

做开发,还有所谓的技术中间件。

一开始我们没有中间件的概念,只有操作系统、数据库这些简单玩意,后来有了所谓的分布式计算,才有了所谓的中间件。

如分布式组件容器(如EJB容器/COM容器),如分布式事务(有了分布式事务协调中间件),如需要在分布式应用之间传递数据就有了分布式消息队列...。

从而,中间件成了一个独立市场。

但是,我们现在讲的中台也不在这个维度上。

现在到了云计算时代,云计算整个大体系被简单粗暴分为SaaS、PaaS、IaaS,有人就混淆视听,就把PaaS叫做中台,中台就滥了:Spark/Hadoop叫做中台、TensorFlow 人工智能叫做中台、IoT物联接入平台叫做中台、音视频处理(如转码/裁剪/鉴黄等)也叫做中台。

麻麻蛋。

现在是个东西就叫做中台。

但是,我们真正要讲到的中台也并不在PaaS这个维度上。

2、我们为什么需要中台因为这是一个企业信息化的新时代。

为什么这样说呢?过去企业信息化的主流重心是企业内部信息化。

但现在以及未来的企业信息化的主流重心是企业外部信息化。

我过去已经说了,中国互联网从1998年算起(新浪搜狐网易都在那一年成立),到现在20年了。

20年,其实就两个阶段。

按to C的分法就是PC互联网时代、移动互联网时代,按to B的分法营销时代、交易时代。

第一个10年(1998-2008),不管你是搞音乐图片视频,还是你搞新闻、爬虫新闻、博客论坛,本质上就一个事:做内容拉消费者流量然后拉企业广告变现。

到了第二个10年(2008-2018),给企业倒流量,企业已经不信了,你给我多少点击量没用,我归根到底还是得看我卖出了多少东西。

所以中国互联网进入了交易时代。

为啥从2008年之后,中国电子商务公司如雨后春笋爆发,就是因为这个历史大规律背景。

数据中台架构的主数据平台及关键技术设计

数据中台架构的主数据平台及关键技术设计

数据中台架构的主数据平台及关键技术设计摘要:针对传统数据平台存储容量不高、数据处理能力较差的问题,对业务数据进行层级分割和水平解耦,构建数据中台架构的主数据平台,实现跨域数据整合和数据积累。

通过服务的形式构造数据接口,进行数据业务的开发,对业务前后端应用需求灵活应对。

关键词:数据中台架构;主数据平台;关键技术引言传统的数据平台基于简单的总体架构,完成数据导入、整理多维数据集合简单的数据分析。

当前传统的数据平台是单节点,数据存储容量不大,只能对结构化的数据进行处理,面对海量的异构数据时,一些数据源无法涉及。

1数据中台架构的主数据平台1.1主数据平台设计数据的中台架构为完成系统业务数据的层级分割和水平解耦,将公共业务数据入口独立出来,通过数据层的数据模型实现跨域数据整理和知识累积,应用视图和控制器实现构建数据接口,进行数据业务的开放,对数据业务的前后端应用需求灵活部署。

数据平台对数据划分多个层次可以更好地管理数据模型,按照数据结构规范分层处理,数据模型将多种数据标准化,使用多维度建模。

数据标准化概括为3层:基础数据模型处理数据;融合模型按照数据的维度进行建模,整合多种数据类型,处理数据的形式包括整合、关联和分解;挖掘数据模型偏向于业务层面,复用性较高的融合在中台架构中,作为企业的数据模型,提高了业务效率。

数据中台架构的主数据平台对外提供统一的服务能力,按照应用要求,对构成数据根据业务场景进行服务。

数据服务能够使开发人员快速访问和查询数据业务,数据分析人员可以进行算法分析,包括数据模型的管理和数据结构的分析。

数据平台中,源数据和数据模型是数据中台搭建的基础,数据开发是连接前台开发重要的环节。

首先是提供标签库,基于标签库的分类区分营销客户,面向业务人员。

数据开发平台面向所有用户和SQL开发人员,提供数据访问,将业务数据可视化处理。

方便快速掌握了解数据,及时发现透明数据动态,保护数据的安全性。

在数据业务响应过程中,共享数据服务实现数据共享。

中台技术架构概述

中台技术架构概述

中台技术架构概述目录1. 什么是中台 (3)2. 中台和微服务的区别 (5)3. 为什么要做中台 (6)4. 深入中台架构 (8)5. 总结 (10)这两年中台很火,已经代替微服务成为架构首选,涌现出各种各样的中台名词,业务中台、数据中台、技术中台、算法中台等,让人眼花缭乱,稍微大点的互联网公司都号称在做中台。

1. 什么是中台既然讲中台,必然还有前台和后台。

前台很好理解,指的是面向C 端的应用,包括前端(如App/ 小程序) 和对应的服务端。

至于后台,很多人把它等同于管理后台,比如商品管理后台,负责商品定义/ 上下架等,提供给内部运营人员使用,这可能不够准确。

简单来说,对于一个交易系统,前台对应用户能看到的部分,如商品浏览和下单,属于接单的部分;后台对应履单部分,如仓库拣货/ 配送/ 财务结算/ 采购补货等,属于实际干活的,由企业内部人员负责,处于一个交易处理流程的后端。

在传统企业,没有在线的前台,基本是线下手工接单,内部信息管理系统基本都属于履单范畴,例如ERP、CRM、采购系统、仓库管理系统,财务系统等,这些系统属于一般意义上的后台概念。

在互联网企业,因为系统一般是自己开发,管理后台既包含面向前台销售的功能,如商品上下架和促销管理,也包含面向履单部分,比如配送、采购、财务结算,所以互联网企业的管理后台并不简单等同于履单后台。

接单和履单之间还有一系列事情要做,包括生成订单时的优惠计算/ 创建实际的订单/ 支付/ 库存扣减等, 这部分功能属于交易逻辑的核心。

在简单场景下,前台应用包含这部分功能,在复杂的场景下,就有必要把这部分独立出来,构成独立的中台,为前台减负。

一些文章笼统地介绍中台是用来连接前台和后台的,这个值得商榷。

如果管理后台就是后台,那没有连接的必要,因为管理后台本身就是系统的附属部分,和前台属于一体两面。

至于履单后台,前台接单系统和后台履单系统设计时就是打通的,也不需要额外定义一个中台来连接两者。

一文读懂数据中台技术架构

一文读懂数据中台技术架构

数据中台的架构数钥数据中台,能够提供面向企业业务场景的一站式大数据分析平台,采用大数据、移动互联网、人工智能等先进技术,支撑企业业务创新,随时随地透视经营,辅助企业科学决策,加速企业数据驱动转型变革。

数钥数据中台,基于Hadoop和Spark体系相关技术,融合数据采集、分析、存储能力,以Spring boot微服务形态对外提供服务。

整体架构:应用架构:大规模数据管理的能力:分析云拥有PB级大规模数据管理能力,支持穿透数据库、Hadoop、大规模MPP 集群。

可支持⚫PB级结构化数据⚫PB级非结构化数据可实现多样化海量数据的统一存储、管理和分析。

一、数据存储Hadoop技术已经经历了十几年的发展,而数据中台作为第二数据平面最重要的数据存储和计算平台,与Hadoop技术的融合越来越紧密,相辅相成,相得益彰。

⚫HBase可以让数据中台保存海量数据;⚫Spark 使得数据湖可以更快的批量分析海量数据;⚫Storm,Flink,NiFi等使数据湖能够实时接入和处理IOT数据。

Hadoop本身更多的聚焦于数据的处理与应用,但是对于底层的数据存储工作则并未过多的关注。

数据中台需要从数据存储、数据治理等方面继续发展。

许多企业通常忽略数据积累的价值,数据需要从企业的各个方面持续的收集、存储,才有可能基于这些数据挖掘出价值信息,指导业务决策,驱动公司发展。

数据中台解决方案实现数据集中存储与共享是基于Hadoop+Spark大数据解决方案和海量对象存储架构,实现万亿级数据可靠存储与高效分析。

使用一套数据存储资源池,可有效解决企业中的数据烟囱问题,提供统一的命名空间,多协议互通访问,实现数据资源的高效共享,减少数据移动。

数据集中存储与共享实际上是将存储资源池化,将计算和数据进行分离。

当前仍然有不少人不能接受大数据的计算和数据分离架构,认为一旦采用分离架构,必然会导致性能的降低。

但实际上,分离后可极大降低存储成本,有效提高计算资源利用率,增强计算和存储集群的灵活性。

苏宁大数据中台技术架构

苏宁大数据中台技术架构
个性化筛选条件
统一维度支持 自定/维度支持 自定/参数支持
度量
计算函数: max/min/count/count distinct/sum/avg/abs 累计函数 lastday
指标属性
可比 占比 同环比 均值
指标定义
衍生计算表达式
支持逻辑流 支持运算符 时间计算函数 异常数据
可视化测试
小天工 多维度数据验证 性能验证
类型 星型 宽表 定制类
时效类型 实时 离线
离线+实时
时序类型 时序 非时序
模型基本属性
构建类别 +细 汇总
明 细 +汇总
调度类型 任务流 调度周期
模型存储
时序 汇总 DRUID
星型 非时序
明细 ES
定制类
宽表
汇总
PG
会员系统
定制化的建模方案
数 仓
会员字典表
访间流量表
会员购买表
会员购买信息 (根据会员去重)
衍生指标_ 2- Vl .2 衍生指标_ 2- Vl .3
历史 上线
开发中
指标新版本上线
指标版本回滚
菲容性校验
统I维度库 数据仓库
数据层:可视+引擎
指标层
指标定义
数据 API
模型层
事实表+维表
OLAP
公共维度表
ADS
解析引擎 计划引擎 执A引擎
OLAP查询引擎 OLAP数据加速引擎
OLAP任务调度
建立维度全链路 统一的数据监控 体系,提升平台 数据安全
维度监 控管理
维度数 据服务
提供高效、稳 定的维度查询 服务,满足高 井发的查询
统一维度系统架构
维度类型

数据中台的通用体系架构方案

数据中台的通用体系架构方案

数据中台的通用体系架构方案从数据中台的建设、运营角度出发,对数据中台在企业数据应用中的作用进行了分析,把数据中台定位为多个数据应用的共享数据平台。

从数据应用及数据治理两个维度分析了数据中台的建设要素,提出了模块化、解耦的数据中台体系架构。

数据中台体系架构包含数据存储框架、数据采集框架、数据处理框架。

数据治理框架、数据安全框架及数据运营模块,可按照企业应用需求进行组合,可以对单个模块进行扩充,能满足大多数企业数据中台建设的需求。

内容目录:0 引言1 数据中台系统定位2 数据中台通用体系架构2.1 数据存储框架2.2 数据采集框架2.3 数据处理框架2.4 数据治理框架2.5 数据安全框架2.6 数据运营框架3 结语0、引言进入信息时代,随着数据产业的蓬勃发展,数字化建设如火如荼。

“数字中国”“互联网+”等国家战略项目已在资源、可持续发展、环境、行政办公等领域取得了良好的效果。

数据是资产、资源,但如何把数据资产、数据资源转化为社会收益和企业利润,还需要多方探索。

当前,机构和企业不再建设从源数据采集到分析应用的烟囱式系统,更倾向于数据集中采集、存储,并应用分层建设。

这种方式一方面有利于应用系统的快速部署,另一方面也保证了数据的集中管理与运营,体现数据的资产、资源属性。

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

数据中台是国内学者提出的概念,起始于阿里的“大中台、小前台”概念。

阿里的中台是从管理的角度出发,以中台事业部集中数据搜索,技术及产品,数据共享等多个部门的功能。

其他组织或企业建设数据中台不一定需要成立中台事业部,但是数据集中治理与提升数据价值转换效率的思路是一致的。

有学者提出了一种基于数据中台的数据治理系统,他认为数据中台是一种大数据架构,用来完成数据治理。

也有学者认为数据中台并非指大数据平台,数据中台完成数据治理后会形成标准数据,再对数据进行存储,进而形成大数据资产,可以为用户提供高效的优质服务。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
层次类型 • 层级维度 • 非层级维度
建立维度全链路 统一的数据监控 体系,提升平台 数据安全
维度监 控管理
维度数 据服务
提供高效、稳 定的维度查询 服务,满足高 井发的查询
统一维度系统架构
维度类型
• 普通维度 • 父子维度 • 角色扮演维度 • 杂项维度 • 日历时间维度
时效分类
• 实时 • 离线
维度管理
维护分类 • 主数据维度 • 手工维度
统一维度建设背景
工具
ETL开发人员/产 品人员,存在大 量手工配置表需 要规则维护,缺 乏快速开发工具。
平台
业务人员想查询 维度信L,缺乏 可靠的公共E台 去快速方便的 查 询。
根据业务需求, 提供快速定义维 度的功能,保证 维度的唯一性
维度开 发管理
统一维度管理目标
维度信 息管理
完善的维度管理 流程,对维度新 增,变更,下线 全生命周期管理
苏宁大数据中台技术架构
技术创新 变革未来
01 总览 02 数据建模与指标化 03 维度管理 04 指标查询服务与OLAP引擎 05 总结

诸葛PC
诸葛APP


数据集市DM

DPA汇总层


SOR基础层
库 层
SSA缓冲层
业务系统采集
数据中台出现之前
物 流
天眼

数据集市DM

DPA汇总层


SOR基础层
个性化筛选条件
统一维度支持 自定/维度支持 自定/参数支持
度量
计算函数: max/min/count/count distinct/sum/avg/abs 累计函数 lastday
指标属性
可比 占比 同环比 均值
指标定义
衍生计算表达式
支持逻辑流 支持运算符 时间计算函数 异常数据
可视化测试
小天工 多维度数据验证 性能验证
类型 星型 宽表 定制类
时效类型 实时 离线
离线+实时
时序类型 时序 非时序
模型基本属性
构建类别 +细 汇总
明 细 +汇总
调度类型 任务流 调度周期
模型存储
时序 汇总 DRUID
星型 非时序
明细 ES
定制类
宽表
汇总
PG
会员系统
定制化的建模方案
数 仓
会员字典表
访间流量表
会员购买表
会员购买信息 (根据会员去重)
DWS
DWD
01 总览 02 数据建模与指标化 03 维度管理 04 指标查询服务与OLAP引擎 05 总结
标准
维度业务口径不 统一,缺乏T效 的管理流程来对 /进行管理和约 束,维度建设存 在重复和歧义
成本
对于维度服务的 开发,各个产品 中心需要各自实 现,造成开发成 本重复投入。例 如公司的维度。
空间
3NF
OLTP
雪花
为什么是星型模型
反范式
OLAP
允许数据适当 冗余,缩短操 作数据的时间, 用空间换取时 间
星型
数据建模



事务型事实宽表

业务过程分析 周期性快照事实宽表 确认粒度/数据来凉
累计快照事实宽表
模型基本属性确认
确认/储介质
建 模
选择事实表
选择维表和维度


选择字段类型/属性
设置cube组 合
数据中台系统架构
数据应用
BI报表
可视化大屏
精准营销
个性化推荐
More
数据应用引擎
可视化引擎Z 数据服务引擎 数据分析引擎
数据开发套件
数据仓库主题域
数据集成 任务运维
实时任务开发 离M任务开发
维度 库
用户主题域 销售题域 商品主题域
计算存储引擎
画像引擎
数据治理套件
数据质量 数据地图 数据模型
基础服务
用户数据服务 数仓管理 运维监控 多租户隔离 集群部署
统O维度库 数据仓库
模型-指标-报表体系系统架构
天工数据层:可 I - 引 擎
指标层
指标定义
模型层
事实表+维表
数据 API
OLAP
解析引擎 计划引擎 执行引擎
OLAPAL引 擎 OLAP数据+速引擎
OLAP任务调度
公共维度表
ADS
DWS
DWD
统I维度库 数据仓库
存储过程 (生成会员序列ID)
存储过程 (bitmap全量和增量数据)
O
L
查询维度月留存bitmap
查询维度新买家
查询维度老买家
A
p
查询维度半年留存
bitmap
bitmap
查询维度纯新买家
查询维度新老买家
bitmap 查询维度年留存
bitmap
bitmap
bitmap
指标基础信息
多种时间粒度 多种时间周期 多单 位 换 算
模型
流量3Vl.2 流量3Vl.3
会员-V l.0 会员-V l.l 会员- V l . 2
模型版本回滚
模型、指标多版本体系
单一指标
uV - Vl.2 uV- Vl.3
PV3V.l.0
会员- V l.2 会员- V.l .3 会员-V.l .4
衍生指标
衍生指标_ l - V l . 3 衍生指标_ l - V l . 4
数据层:可视+引擎
指标层
指标定义
数据 API
模型层
事实表+维表
OLAP
公共维度表
ADS
解析引擎 计划引擎 执A引擎
OLAP查询引擎 OLAP数据加速引擎
OLAP任务调度
DWS
DWD
01 总览 02 数据建模与指标化 03 维度管理 04 指标查询服务与OLAP引擎 05 总结
避免数据冗余, 减少数据库的
库 层
SSA缓冲层
业务系统采集
数据平台 v s 数据中台
数据平台
有完整的数据模型设计,但偏重设计和技术,在执行过程中,很难保证数据的全,数据应 用一般不跨过数据中心 初期数据发展快,效率高,快速体现业务价值,但是随着数仓的建设,数据量急速鳌加, 整体成本居高不下,导致数据混乱、灾难。
数据中台
数据中台的基本理念是:将所有数据汇聚到数据中台,每个数据应用都以数据中台为唯一 数据来源。 苏宁数据中台的目标是为苏宁的数据战略提供有力的支撑,从企业全局进行统一规划,统 一建设,强调数据的“全”,从设计、组织、建设、流程角度保障了模式的落地。 数据中台的建设减低了数据使用门槛
衍生指标_ 2- Vl .2 衍生指标_ 2- Vl .3
历史 上线
开发中
指标新版本上线
指标版本回滚层:可视+引擎
指标层
指标定义
数据 API
模型层
事实表+维表
OLAP
公共维度表
ADS
解析引擎 计划引擎 执A引擎
OLAP查询引擎 OLAP数据加速引擎
OLAP任务调度
模型、指标多版本体系
原则
状态分成上线/历史/开发中 上线单一/标来源于上线的模型 上线衍生/标中的单一/标必定是上线版本 历史版本模型有冻结期,冻结期结束此版本模型删 除,关联历史/标下线
Druid
da1a0. 2rcel da1a0.2rce2
PG
1ablel 1able2 1able3
模型新版本上线
相关文档
最新文档