导图社区 金融级IT架构理论
- 142
- 2
- 1
- 举报
金融级IT架构理论
数字经济时代，开源已成为新基建新的“精神文明”。本导图从开源理论引出新一代金融IT架构相关理论，从分布式微服务演进，单元化改造原则，技术风险，业务架构等方面进行整理，方便从业人员体系化学习金融IT架构
编辑于2023-06-19 17:25:43 甘肃- 金融IT架构
- 微服务单元化
- 中台战略
- 分布式云原生
- 相似推荐
- 大纲
金融级架构理论
开源理论
开源管理
架构管理
项目管理
安全管理
配置管理
运维管理
五位一体
开源文明是数字时代的“精神文明”
开源领域
浏览器
微软IE
内核Trident
谷歌Chrome
内核Blink
苹果Safari
内核Webkit
火狐Frixfox
内核Gecko
开源
web领域
Apache
美国超级计算机应用中心NCSA开发
Nginx
俄罗斯伊戈尔.塞索耶夫
人工智能领域
谷歌TensorFlow
支持Python和C++
百度深度学习平台PaddlePaddle
区块链
比特币Bitcoin
以太坊Ethereum
Linux基金会的超级账本Hypherledger
瑞波Ripple
开源的LAMP架构
Linux
Apache软件基金会的httpd软件
MySQL数据库
PHP/Perl/Python等开发语言
企业信息系统架构
业务管理应用系统（CRM、PDM、SCM、OA、ERP、HT）
基础软件系统（中间件、数据库、操作系统）
硬件设施
网络设备及机房环境设施（交换机、路由器等）
安全防护设施
IT组织与管控体系
云计算
改变了传统开源软件公司的商业模式
改变了IT领域的众多惯例
云计算到中台战略
对内协同
对外开放
服务网格开启微服务架构新阶段
降低系统复杂度
独立部署
独立扩展
跨语言编程
无服务器架构Serverless
减少开发运维的复杂度
缩短业务系统的交付周期
IT运维逐步从敏捷时代步入智能时代
Devops改变软件的开发和运营模式
自动化工具
Ansible
Fork
Jenkins
IT&DT
IT时代以自我控制，自我管理为主
DT时代以服务大众、激发生产力为主
新技术领域的开源架构
云原生
容器及容器编排
Docker
Swarm
Docker
Kubernetes
属于云原生计算机基金会CNCF
Harbor(中国企业开源项目)
CNCF孵化
微服务
SpringCloud
Pivotal
Istio
Google、IBM、Lyft
Dubbo
Apache
TARS
Linux
Devops
Ansible
Ansible
Jenkins
Linux
SaltStack
SaltStack
BlueKing
Tencent
大数据
数据库
PostgreSQL
PostgREST
MySQL
Oracle
MongoDB
MariaDB
人工智能
AI
TensorFlow
应用领域
自然语言处理
NLP
人脸识别
推荐系统
电子商务
时间序列预测
可以应用于金融、交通、气象等领域
强化学习
一种机器学习方法，用于教授机器人和其他智能体如何采取行动
Keras
由Python编写的开源人工神经网络库，可以作为Tensorflow、Microsoft-CNTK和Theano的高阶应用程序接口
支持主流的算法
前馈结构和递归结构的主流算法
构建统计学习模型
卷积神经网络CNN和循环神经网络RNN
应用领域
计算机视觉
自然语言处理
Pytorch
Pytorch
Caffe
BVLC运作
基于表达架构与可扩展编码的深度学习框架
一颗NVIDIA K40 GPU一天可处理6000万张图片
80%的数据+20%的算法=更好的人工智能
操作系统
Linux
Ubuntu
智能手机移动操作系统
openSUSE
SUSE Linux专业版
CentOS
Red Hat
Mandriva
开源五要素
人
开源生态的人包括贡献者和使用者
使用者
问题贡献者
普通贡献者
核心贡献者
机
工具包括开源代码托管平台、开源组成分析工具
代码管理工具GitHub
代码合规扫描工具
开源许可证扫描
安全漏洞扫描
奇安信
监测统计工具
CatWatch、Gander、GHCrawler、Gittagstats
Grimoire Lab、OSS-dashboard、OSSTracker
OpenHub、stackalytic
协调沟通工具
料
基础物料是源代码
法
规则包括开源许可证、社区管理办法
环
环境即为开源社区
数字技术概论
改变了商业模式，使新金融成为可能
领域
移动互联、IoT，使得金融可以更便捷地触达客户，并提供更好的客户体验
生物识别解决了远程甄别难题，为边远地区提供了便捷的金融服务
大数据缓解了信息不对称难题，有效识别金融风险，让普惠金融成为可能，并可持续发展
人工智能极大提升了数据处理效率、业务流程效率、商业决策效率和准确度
云计算大大降低了创新和服务成本
区块链让金融服务透明可信，可审计可追溯，解决了信任难题，构建了新的生产关系。
ABCDMIX
新一轮技术革命
【正在对银行业的商业模式、服务模式和运营模式带来颠覆性变革，为商业银行基础设施布局带来深远影响】
分布式技术让商业银行获得了前所未有的性能容量、高可用水平和更敏捷的交付速度
云计算技术大幅提升了资源弹性伸缩能力，降低了IT运营成本
数据、人工智能等技术广泛应用于精准营销、风险防控等领域，为客户提供更好的体验
人工智能、区块链、云计算、大数据、5G代表着数字时代的历史印记，开源不仅是一种思维方式，更是数字时代发展的灵魂所在，是数字时代的“精神文明”
信息技术已成为银行业务经营发展的命脉
金融级架构概述
银行科技体系
整体目标：技术先进、安全可靠、自主可控
传统金融“高可用、高标准、低风险”
高可用
快速恢复、故障隔离、高冗余
标准化
自动化运维、规模化管理
安全可靠
数据安全、资金安全、交易安全
互联网金融“高性能、高弹性、低成本”
高性能
百亿级交易量
高弹性
容量扩展性、性能扩展性
低成本
开源技术、新技术应用快、IT硬件横向扩展
云基础设施架构面临挑战
IT系统面临“潮汐”式流量不稳定压力
“天下武功，唯快不破”快速响应市场需求
面临的矛盾：快速增长的金融业务、丰富多彩的金融创新，以及低成本的技术转型，与稳定性、标准化、安全的金融基础设施需求之间的矛盾
数字金融的业务需求
快速增长的业务需求
丰富多彩的金融创新
快速适应金融场景
延展金融触达方式
低成本的技术转型
高性能、高弹性、低成本
传统金融
稳定性高、标准化高、安全性高
高性能、高弹性、低成本、高可用、标准化、安全可靠
技术风险防控
通过管理措施和技术能力，消除风险隐患，
及时处置运行故障
快速“止血”恢复业务
提升风险防护能力
保证信息系统高可用和资金安全，保障业务连续性
架构演进
应对信息系统在容量、稳定、安全、成本、合规、效能等方面的挑战
数据垂直拆分
数据水平拆分
分布式架构构建
微服务技术架构
侵入式架构
服务框架嵌入源代码，通过SDK进行开发
常见框架：SpringCloud、腾讯TARS、DUBBO、阿里SOFAStack
特征：所有代码部署在同一个进程内
挑战：当服务接口越来越多时，服务间调用、服务发现、服务容错、服务部署、数据调用等服务治理层面面临新的挑战
基础设施迭代演进与业务强耦合，无法按业务维度精细化流量管控，应用安全加固成本高
非侵入式架构
未来发展趋势
以代理的形式，与应用程序部署在一起，接管应用程序的通信网络且对其透明，以服务网格为代表的
常见框架：CNCF的Linkerd、Istio、蚂蚁金服CloudMesh
优势：突破SDK接入方式，对应用以透明的方式处理服务之间。服务与基础设施之间的通信，实现应用研发和基础设施之间最大程度的解耦
业务特征：逻辑代码、依赖微服务框架构建的非功能性代码和框架自身客户端分别部署到不同的进程中，出现边车（Sidecar）进程
边车（Sidecar）进程：负责应用之间的服务发现、路由、调用、负载均衡、健康检查、限流、熔断和监控
云计算平台构建
单元化“多活”架构建设
将一个系统的架构按照某种数据特征维度进行单元划分
每个单元从流量层、应用层到数据层的完整、自治、独立的生态系统，
单元之间互为备份，
少量服务存在需要跨单元，需要服务具备单元间的分发和调度能力
弹性架构建设
弹性计算服务ECS（Elastic Compute Service）
专用宿主机DDH(Dedicated Host)
ECS实例
允许对CPU资源机型进行超分设置
云存储
块存储服务BSS（Block Stroage Service）
SaaS金融应用一般选择“高效云盘”作为数据盘
Paas一般选择ESSD云盘作为数据盘。
存储类型服务一般选择NVMe本地盘或者SATA HDD本地盘
对象存储服务OSS（Object Storage Service）
主要用于文件、图像、音视频内容的存储
日志服务LS（Log Service）
云网络规划使用
专用网络VPC
云防火墙
弹性公网IP地址
负载均衡（Server Load Balancer,SLB）
混合云架构建设
云原生可信架构建设
不再有非功能性代码在应用代码逻辑中体现，让其下沉到基础施设中去
业务运维人员只需专注于业务代码相关部分
容器编排Kubernetes技术承载云原生时代统一资源调度的目标，是云操作系统的基础设施
采用镜像化部署模式，多套环境统一镜像，降低部署成本，提升自动化水平和系统稳定性
将SDK集成的一些网络通信能力下沉到Sidercar中，包括
RPC、消息、数据访问能力
服务发现、服务鉴权、熔断、限流、流量管控
Hystrix、Sentinel组件
设置应用甚至接口级的阈值
数据库分库分表、数据加解密能力
使用云原生新技术带来研发效率、资源效率、安全能力和运维能力的提升
数据库部署架构
分布式数据库
持续可用，引入分布式协议Paxos或Raft实现数据一致性
3副本，1主库，2个备库
分布式事务与数据一致性
ACID属性
原子性 Atomicity
一致性 Consistency
隔离性 Isolation
持久性 Durability
多租户策略
多租户是分布式数据库实现资源隔离与未来进行云化发展的基础
隔离
资源
每个租户可以进行CPU、内存、存储、网络带宽、连接数等资源的控制
安全
只访问自己的实例和相关租户资源
故障
单个“抖动”、资源不足、数据错误不会影响其他租户
运维
应用耗时分析与优化
全链路耗时、热点行、批处理
基于分布式的trace中间件，分析业务链路的不同场景中的依赖库、SQL模板、SQL执行顺序与次数
优化方向：缓存、应用部署、SQL优化、异步化改造
数据访问路由策略
数据库部署模式
扩展模式
按照业务把应用进行分类，把相互依赖的应用部署在同一个机房中
镜像模式
每个机房都部署相同的应用和数据库，都具备全量业务的提供能力，按照比例进行流量调拨
数据分类
1. 可进行流量调拨的数据，按照一定的规则进行等比例划分，实现每个机房只需要一部分数据
2. 不可进行流量调拨的全局数据，数据库的主节点在某个机房，跨城市访问增加耗时
3. 全局数据的耗时涉及跨城情况时，存在业务不可接受的情况，将这部分数据同步到一个独立库中
数据访问优先级：同机房正常状态--》同城正常状态--》同城高负载状态--》跨城正常状态--》跨城高负载状态
数据存储加密
个人金融信息类别
C3类别信息
银行卡磁道、芯片信息，卡片验证码，卡片有效期，银行卡密码、网络支付交易密码
账户登录密码，交易密码，查询密码
用于用户鉴别的个人生物识别信息
C2类别信息
支付账户及其等效信息，如支付账户、证件类识别标识与证件信息（身份证、护照等）、手机号
账户登录的用户名
用户鉴别辅助信息，如动态口令卡、短信验证码、密码提示问题答案；弱用户鉴别信息与账号结合可直接完成用户鉴别，则属于C3类别信息
直接反映个人金融信息主体金融状况的信息，如个人财产信息、借贷信息
用于金融产品与服务的关键信息，如交易信息（交易指令、交易流水、证券委托、保险理赔）等
用于履行了解洗的客户（KYC）要求，以及按行业主管部门存证、保全等需要，在提供产品和服务过程中收集的个人金融信息主体照片、音视频等影像信息
其他能识别出特定主题的信息，如家庭地址等
C1类别信息
账户开立时间、开户机构
基于账户信息产生的支付标记信息
C2和C3类别信息中未保函的其他金融信息
个人金融信息生命周期
收集、传输、存储、使用、删除、销毁
两级密钥管理
数据密钥，用于加密业务数据
主密钥，用于加密数据密钥
中间件透明加密
数据库透明加密
云单元架构
分布式系统架构演进经历的历史阶段
单体架构、应用与数据库服务器拆分、缓存/搜索的能力引入、数据库读写分离、数据库水平/垂直拆分、应用拆分、微服务化等。
架构特征
自包含性
松耦合性
故障独立性
容灾性
通过一定手段将用户访问服务涉及的所有操作收敛在同一机房内完成，避免跨机房数据访问，解决网络时延问题。
逻辑架构
分区单元（Region Zone）RZone
用户维度拆分的核心业务系统，保证用户分布在不同的处理单元内
共享单元（City Zone）CZone
部署不可拆分的数据服务，主要解决跨城通信延迟过高的问题
产品查询系统
全局单元(Global Zone) GZone
部署未按用户维度进行拆分或非交易主链路的应用，提供不可拆分的数据服务
长尾应用或新用户注册系统，运维管理系统
单元化改造十三条原则
系统改造全局原则
原则一：在单元改造过渡阶段，部分原则可不遵循
原则二：单元化改造分阶段完成，优先确保部分流量路由正确
原则三：服务跟着数据走，无法拆分的数据需要迁出分库集群
原则四：异步化处理需要确保路由位不丢失
原则五：任何方案都要确保链路延时、数据时延在可接受范围内
全局单元（GZone）改造单元
原则六：GZone不能直接访问RZone的数据或缓存
原则七：GZone可以访问CZone的数据库、缓存或服务
业务单元（RZone）改造原则
原则八：RZone只处理本单元数据
原则九：RZone不能直接访问GZone数据库或缓存
原则十：RZone尽量少依赖GZone服务
原则十一：RZone可以访问CZone的数据库、缓存及服务
共享单元（CZone）改造原则
原则十二：CZone不能创造新的数据，数据都来自GZone或RZone
原则十三：CZone依赖方需接受数据同步时延影响
单元化流量路由
路由规则设计
按照一定的规则进行分配、转发、重定向
使用XML、JSON解析文件格式
HTTP流量路由
解决怎么将用户的目标单元对应的服务地址匹配出来
客户端感知路由规则的变化
引入HTTPDNS
通过Lua脚本编写获取HTTP的头信息，最终解析得到当前用户的uid及转发的目标Zone信息
RPC流量路由
RPC（Remote Procedure Call）远程过程调用
应用之间的RPC交互通常由服务发布与订阅、应用之间高性能
RPC远程服务调用
服务路由
软负载
RPC比（REST、WebService、RMI）等有优势
RPC调用的实现机制
服务提供方Service
服务消费方reference
消息流量路由
消息发布端和消息订阅端访问同一个Kafka集群
双方的Topic是一致的
Topic作为消息系统队列的唯一标识，是消息路由的关键
数据流量路由
交互
应用与数据库
应用与缓存
应用与对象存储及大数据处理平台
数据库单元化路由
每个Rzone只跟自己对应的分库建立连接并发起请求
缓存单元化路由
缓存解决应用性能的关键组件
共享单元Czone模式缓存
分布式中间件
基础开发框架
应用框架和应用容器是成对出现的
EJB
Jboss、Weblogic、Websphere
Spring、Guice
Tomcate、Jetty的轻量级Servlet容器
Spring架构
IOC反转控制
AOP面向切面编程
MVC模式-视图-控制器
单一架构
应用框架调用主流价值观
SpringBoot Stater
自动化装配能力
Kubernetes
容器调度
DOCKER
容器
SOFABoot框架
类隔离支持
解决类冲突、Jar包冲突
多模块隔离
部分功能扩展
Readiness、HealthCheck
标准的注解和XML XDS规范
微服务平台
MSA（Microservice Architecture）微服务架构
RPC框架
Dubbo、GRPC
服务注册中心
高性能
高吞吐
高可用
AP可用性分区容错性
Availlability可用性
CP一致性分区容错性
Consistency一致性
Partition tolerance分区性容错
任务调度平台
单一架构下的调度方式
Timer、Scheduled、Quartz
特性
可管理
可监控
分布式
每个单元都是一个完整的自治个体
动态配置管控平台
Pub/Sub发布订阅模式
特性
正确性
及时性
可观测性
限流组件
SpringBoot标准的MVC Filter和MethodInterceptor即可完成拦截
机器内存到80%即对请求进行限流
分布式数据访问代理
分库分表、读写分离、全局流水号、单元化支持
访问路由层通过SQL hinit将访问备库的查询语句进行标记，封装成专门的API
分布式可靠事务服务
TCC (Try-Confirm-Cancel) 模式
跨数据库
跨应用
TCC两阶段提交协议
第一阶段采用本地端事务
第二阶段可以异步执行
一致性
强一致性、弱一致性、最终一致性
BASE：基本可用、软状态、最终一致性
分布式消息队列
支持集群水平扩展
支持事务型消息
运单员架构支持
分布式全链路跟踪
全链路追踪
深入应用、数据库、自动捕获性能异常，自动识别出现故障的应用组件与代码
易于使用
监控集成
云单元架构支持
混合云弹性架构
概述
单元架构具备按需弹性伸缩的能力，流量高峰时快速弹性扩展，扩充资源，提升应用处置能力
弹性架构的本质是单元架构的扩展，提供一种以单元化架构中的业务单元为最小粒度进行弹性伸缩的架构能力
两个动作
弹出和弹回
以业务单元为基础的计算资源、网络、应用、数据库层面的全面弹出
弹性业务单元具备的特征
局部性
临时性
跨云
弹出
流量类型
入口流量（通过公网域名发起的服务）
回写Cookie，存放目标单元相关信息
内部流量（RPC调用，消息订阅）
有状态弹出
账户余额的增减
对于没办法多点写入和读取的数据只能采用有状态弹出方案，
无状态弹出
交易的创建
根据用户ID和上下文创建交易
根据交易号查询交易详情
弹性业务单元中弹性库的弹性ID需要使用全局EID，业务参数中的弹性ID等于全局EID则需要弹出
对业务的请求数据进行一定的抽取，然后结合全局弹性规则做出是否弹出的判断
弹回
这个弹出过程的逆过程
步骤
应用流量弹回
数据回迁
资源释放
云原生架构
演进路径
1. 业务集中，虚拟化
2. 简单虚拟化向分布式演进
微服务化、运维标准化、服务规模化
Kubernetes自动化规模化的运维体系
3. 应用无状态化，容器管控，动态编排
从以容器为部署单元向POD（资源对象）为基础的部署单元转型
POD中有多个容器
APP容器、Sidecar容器
MOSN
负责处理服务之间的RPC通信
DBMesh
负责服务与DB之间的通信
业务代码与基础设施组件使用独立的容器部署，具备资源隔离和共享的能力
关注方面
研发效率提升
运行态高可用保障
全链路安全可行
云原生技术的核心构成
不可变基础设施
操作系统OS、安全脚本、运维Agent、开发框架、运行环境
镜像化部署方式，将应用依赖的基础设施及配置全部整合
OS层
软件层
脚本层
安全层
技术栈
服务网格
SDK访问基础实施的网络通信能力下沉到Sidecar中
包括服务RPC、DB访问、消息处理等
实现流量管控，限流熔断，数据库配置等
通过网格技术解决多语言、多技术栈之间的互联互通问题
集群混部技术
在线和离线集群混合部署，统一资源调度，以资源隔离和动态调整为基础
将不同类型的在线服务和离线计算服务进行精确组合，利用高效调度算法和智能化容量计算模型完成资源合理利用，提升资源错峰高效利用水平，降低IT成本。
从CPU、内存、网络、IO等方面进行资源隔离
安全可信
安全容器
服务鉴权
链路鉴权
数据访问鉴权
Serverless
按照实际使用量进行付费
定义
Serverless=FaaS+BaaS
云函数计算
FaaS
应用以函数的形式存在，并交由第三方云平台托管
构成
时间驱动的集合
Event Source Functions
提供服务的Functions或微服务
Functions Instance
管理Functions的控制服务
FaaS Controller
依赖的平台服务
Platform Services Functions
BaaS
Backend as a Service
云原生运维
应用开发和基础设施解耦
使用技术
容器调度Kebernetes、服务网格Service Mesh、无服务器化Serverless
运维变更操作“三板斧”
可监控
可“灰度”
可应急
技术风险防控架构
资金安全
资损
产品设计缺陷、产品实现异常、员工操作错误
防线
线下
在最早时间发现问题
代码分析-》用例执行-》测试验证
灰度
用最小成本控制问题
流量筛选-》流量验证
线上
以最小影响解决问题
核对发现-》风险处置
安全防线运维
日常演练
专项演练
年度演练
全链路压测
借鉴云计算的多租户机制，通过在分布式中间件中对压测流量进行识别，引入压测租户和影子表
影子表
真实业务生产表结构建立一张别名表，处在同一库中，表结构一致
对生产环境的一次高仿真模拟，压测数据不写入生产表，压测流量不流入第三方
三个方面的特别控制
建立压测流量识别机制，调整安全策略，
建立非法流量的检测报警机制
建立中间件和工具组件在识别到非法流量时的主动阻断机制
压测链路与仿真
链路
压测链路
挡板系统
业务链路
压测过程的系统表现
CPU、负载、内存、响应时间
应用的部署机器、分布情况、数据库的负载情况、缓存命中率
业务架构
银行面临的挑战
传统对公业务规模见顶，风险积聚，年轻客户流失，线下渠道使用率大减，客户接触和数据减少，理财、资管、消费信贷被第三方争夺。
监管对普惠金融的要求，社会对普惠金融的期望，与银行传统的、只能服务有限高端客户的业务能力之间的矛盾，都在倒逼银行进行数字化转型，建设数字化服务能力。
数字化银行顶层设计
平台化设计思路
多端多渠道
丰富的应用场景
金融业务云SaaS
为客户提供随时随地可用的金融服务
安全、易用、开放的金融应用开放平台
公共金融业务组件与服务
金融数据云DaaS
海量数据处理和计算能力
实时的数据处理和流转能力
金融技术云PaaS
可伸缩、高可用的分布式金融技术
弹性资源分配和访问管控
基础设施云IaaS
基础资源可伸缩性
安全、智能监控系统资源稳定性
总体建设规划
云计算基础设施
大数据风控体系
依托客户授权数据和外部可获得数据，设计指标体系
创建预测模型和风控策略，形成多层次、完整的风险评估、准入授信、定价策略、风险预警和监控体系。
多端多渠道服务体系
小程序、SDK、API等形态，将银行服务植入场景
实现对客户的全渠道、全场景触达，金融服务的全方位渗透，实现“无微不至，无处不在”的金融服务
智能运营营销体系
通过引入大数据分析，全面解读客户的行为、关系网络，生成客户画像
再根据产品特征、服务内容、客户习惯进行深度挖掘，在不同的商业场景中，向不同的客户推荐不同的产品和服务，
实现千人千面的个性化智能服务和精准触达
智能资产管理
应用大数据、人工智能技术，预测和防控流动性风险，
优化金融市场，资产证券化等业务的交易成本和效率，优化总体资金成本，
保障融资，支付，理财等业务健康、可持续运营
开放银行
应用开放平台、区块链、共享智能技术，联合商业生态系统。金融同业、BCG等，
实现金融能力开放，金融业务开放、数据安全融合与共同利用，
建立开放、共赢的普惠金融合作生态，服务更多小微客户
中台战略
定义
实现了“用数字技术赋能企业商业领域运营，支撑前端业务快速多变和创新，符合新数字经济时代的商业运营方式和价值创造路径”
核心是打破传统僵化的前后台运营模式，重组组织和业务架构
“大中台、小前台”的组织和业务机制，供企业快速、低成本地进行业务创新和企业架构，业务中台将企业的核心能力以数字化形式沉淀为各种服务中心或服务形态
企业具备特征
移动化、互联网化
注重客户体验
数据驱动
开放的生态
科技创新
业务中台
建设背景
传统金融信息化建设“全覆盖、无死角”
各部门不同的IT需求，导致大量重复建设的功能和应用，随着系统变得复杂，数据孤岛越来越多
“组织墙”和“部门墙”阻碍了企业成为真正的“数字化企业”
目的
提供企业能够快速、低成本创新的能力
构建企业共享服务中心
方法论
“方法+工具+业务理解”
服务化、共享化、平台化
实施路径
系统拆分、微服务改造、单元化治理。
数据中台
比喻
数据---》“石油”
数据仓库、数据集市---》“输油管”，属于数据供给侧
数据中台---->“炼油厂”，将石油变成创造商业利润的“石油产品”
概念
一套可持续“让企业的数据用起来”的机制，是一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形产品和实施方法论支撑，构建一套持续不断把数据变成资产并服务于业务的机制
“让企业的数据用起来”的机制
业务数据积累
企业经营数据
客户行为数据
设备运转数据
生态合作数据
数据中台
大数据平台
统一存储计算、数据汇聚连接、数据算法开发
数据体系
数据类目体系、标签类目体系、数据资产管理
数据服务能力
数据应用服务、数据资产交换、``````
数据场景应用
智能BI
个性化推荐
设备智能检测
企业画像
价值框架
业务
业务数据化
数据
数据资产化
资产
资产服务化
服务
服务于业务化
4大核心能力
汇聚整合
管理便捷、集成与运营、确保访问权限、数据可用
提纯加工
标签体系、智能的数据映射、质量保障体系、完善的安全防控
服务可视
数据可视服务、数据开发平台、AI服务能力、数据分析能力
价值变现
跨部门实现业务价值、数据应用管理、洞察驱动业务的通路、面向场景的数据应用
企业数据应用的成熟度评估
第一阶段：统计分析阶段
分析只停留在对过去业务结果的统计，形成面向业务主题的客观事实描述和分析结果
通过IT系统的建设，实现业务过程的流程化、自动化
无数据战略，纯业务驱动；少量业务数据积累，数据维度单一；数据无组织，对各业务数据分散存储管理
无数据质量管控；简单的业务统计报表为主；以系统报表模块和Excel为主
第二阶段：决策支撑阶段
开始通过数据支撑经营决策；注重业务过程中的数据积累、收集；数据维度逐渐丰富
以面向业务主题的指标体系为形式进行数据组织；开始实施数据质量控制，对相关数据进行清洗加工
为企业管理提供决策支撑；以数据仓库。数据开发和专业化BI报表工具为主
第三阶段：数据驱动阶段
开始将数据作为企业重要资产，通过跨界数据应用为企业提供数据服务；各业务数据积累初具规模，且数据量越来越大；
全域数据融合，数据维度更加丰富；开始业务涉及的相关数据汇聚、打通，进行全域数据组织
开始进行数据标准化建设，对数据质量管控更加严格
实现数据与业务深度融合，通过数据驱动发展业务；通过Hadoop生态体系为代表的批计算、流计算、即席分析、在线查询等大数据处理技术及机器学习、深度学习算法进行数据汇集开发
第四阶段：运营优化阶段
企业开始建设数据中台；随着数据闭环的构建，企业数据体量快速增大；数据维度更加完善；
建立数据应用闭环；形成一套完善的数据质量管理规范及管理流程
数据服务体系化；建立一套数据汇聚、加工、管理、服务及应用体系，逐渐实现大数据能力工具化、工具平台化、平台智能化
数据计算能力
批计算
海量数据，批量计算
MapReduce作为数据处理的主要方案
Spark将数据抽象成RDD、DataFrame
数据处理技术
有向无环图DAG
数据格式和内存布局
Spark RDD
执行策略
支持基于Hash的分布式聚合
流计算
实时处理框架
Storm、Flink、Spark Streaming
实时数据、毫秒级RT
应用场景
流式ETL
流式报表
监控预警
在线系统
在线查询
在线计算框架
Elasticsearch、Redis
毫秒级查询、高QPS
应用场景OLTP
画像服务
搜索
圈人场景
即席分析
处理框架
Kylin、Impala、ClickHouse、HAWK、AnalyticDB
秒级RT、内存计算
批处理，聚合
数据资产管理
3个特征
企业拥有或控制
能带来未来经济利益
数据资源
4个目标
可见、可懂、可用、可运营
位置
数据开发---》数据资产管理---》数据应用
数据治理
6个目标
提升数据质量
构建统一的，可执行的数据标准
良好的响应数据生产者、消费者、数据处理技术人员等数据利益相关者的需求
培训组织让大家采用共同的解决数据问题的办法
实现可重复的数据管理流程，并确保流程透明
实现数据的可持续运营、数据资产的增值
6个原则
标准化原则
透明原则
数据的认责和问责
平衡原则
代价和收益之间取得平衡
数据可商用是平衡原则的重要参考
变更原则
数据标准、元数据、数据质量可变更
适应变化，推动标准更新
持续改进原则