数据服务技术架构图数据服务主要是哪方面

转载

jacksky 2023-11-25 05:32:18

文章标签 数据服务技术架构图 java 数据库大数据元数据 文章分类 架构后端开发

第6章数据服务

1.服务架构演进

演进过程
DWSOA

（1）实施原理
将业务方对数据的需求通过SOA服务的方式暴露出去。有需求驱动，一个需求开发一个或则几个接口，编写接口文档，开放给业务方调用。
（2）优点
实现简单
（3）缺点
接口粒度比加粗
灵活性不高
扩展性差
复用率低
开发效率低
人力成本较高

OpenAPI

（1）实施原理
将数据按照其统计粒度进行聚合，同样维度的数据，形成一张逻辑表，采用同样的接口描述。以会员维度为例把所有以会员为中心的数据做成一张逻辑宽表，只要是查询会员粒度的数据，仅需要调用会员接口即可。
（2）优点
有效的收敛了接口的数量
（3）缺点
数据维度控制较难

SmartMQ

（1）实施原理
在OpenAPI的基础上，再抽象一层，用DSL(Domain Specific Language，领域专用语言)来描述需求。
（2）优点
所有的简单查询服务减少到只有一个接口，大大降低了数据服务的维护成本。
（3）缺点
不能满足个性化的取数业务场景

统一的数据服务层

提供多种服务类型来满足用户需求，分别是OneService-SmartDQ、OneService-Lego、OneService-iPush、OneService-uTiming

（1）OneService-SmartDQ

元数据模型架构示意图：

数据服务技术架构图数据服务主要是哪方面_java

SmartDQ 的元数据模型，简单来说，就是逻辑表到物理表的映射。
① 数据源
SmartDQ 支持跨数据源查询，底层支持接人多种数据源，比如MySQL、HBase、OpenSearch 等。
② 物理表
物理表是具体某个数据源中的一张表。每张物理表都需要指明主键由哪些列组成，主键确定后即可得知该表的统计粒度。
③ 逻辑表
逻辑表可以理解为数据库中的视图，是一张虚拟表，也可以看作由若干主键相同的物理表构成的大宽表。 SmartDQ 对用户展现的只是逻辑表，从而屏蔽了底层物理表的存储细节。
④ 主题
逻辑表一般会挂载在某个主题下，以便进行管理与查找

架构示意图：

数据服务技术架构图数据服务主要是哪方面_数据库_02

( I ）查询数据库
SmartDQ 底层支持种数据源，数据的来源主要有两种：①实时公共层的计算作业直接将计算结果写人 HBase ；②通过同步作业将公共层的离线数据同步到对应的查询库。
(2 ）服务层
元数据配置。数据发布者需要到元数据中心进行元数据配置，建好物理表与逻辑表的映射关系，服务层会将元数据加载到本地缓存中，以便进行后续的模型解析。·
主处理模块。一次查询从开始到结果返回，一般会经过如下几步。
DSL 解析：对用户的查询 DSL 进行语法解析，构建完整的查询树。
逻辑 Query 构建：遍历查询树，通过查找元数据模型，转变为逻辑 Query
物理 Query 构建：通过查找元数据模型中的逻辑表与物理表的映射关系，将逻辑 Query 转变为物理 Query
Query 拆分：如果该次查询涉及多张物理表，并且在该查询场景下允许拆分，则将 Query 拆分为多个 SubQuery
SQL 执行：将拆分后的 SubQuery 组装成 SQL 语句，交给对应DB 执行。
结果合并：将 DB 执行的返回结果进行合井，返回给调用者。
其他模块。除了一些必要的功能（比如日志记录、权限校验等），服务中的一些模块是专门用于性能及稳定性方面的优化的。

（2）OneService-Lego

数据服务技术架构图数据服务主要是哪方面_数据库_03

（1）Lego 被设计成个面向中度和高度定制化数据查询需求、支持插件机制的服务容器。它本身只提供日志、服务注册、 Diamond 配置监听、鉴权、数据源管理等一系列基础设施，具体的数据服务则由服务插件提供。基于 Lego 的插件框架可以快速实现个性化需求并发布上线。
（2）Lego 采用轻量级的 Node.JS 技术核实现，适合处理高并发、低延迟的 IO 集型场景，目前主要支撑用户识别发码、用户识别、用户画像、人群透视和人群圈选等在线服务。底层根据需求特点分别选用 Tair、HBase、ADS 存储数据。

（3）OneService-iPush

数据服务技术架构图数据服务主要是哪方面_java_04

iPush 应用产品是一个面向 TT、MetaQ 等不同消息源，通过定制滤规则，向 Web 、无线等终端推送消息的中间件平台。 iPush 核心服务器端基于高性能异步事件驱动模型的网络通信框架 Netty 实现，结合使用 Guava 缓存实现本地注册信息的存储， Filter与Server 之间的通信采用 Thrift 异步调用高效服务实现，消息基于 Disruptor 高性能的异步处理框架（可以认为是最快的消息框架）的消息队列，在服务器运行中Zookeeper 实时监控服务器状态，以及通过 Diamond 作为统一的控制触发中心.

（4）OneService-uTiming

数据服务技术架构图数据服务主要是哪方面_大数据_05

（1）uTiming 是基于在云端的任务调度应用，提供批量数据处理服务，支撑用户识别、用户画像、人群圈选三类服务的离线计算，以及用户识别、用户画像、人群透视的服务数据预处理、人库。
（2）uTiming-scheduler 负责调度执行 SQL 或特定配置的离线任务，但并不直接对用户暴露任务调度接口。用户使用数据超市工具或 Lego API 建立任务。

2.最佳实践

性能提升方式

（1）资源分配

剥离计算资源
查询资源分配
执行计划优化：查询拆分和查询优化

（2）缓存优化

元数据缓存
模型缓存
结果缓存

（3）查询能力

合并查询
推送服务

如何保证稳定性
（1）发布系统

元数据隔离：三个环境——日常环境、预发环境、线上环境。对应三个元数据——日常元数据、预发元数据、线上元数据。
隔离发布：资源划分、资源独占、增量更新

（2）隔离

机房隔离
分组隔离

（3）安全限制

最大返回记录数。数据库的查询强制带上 LIMIT 限制，具体数值以用户配置为准。
必传字段。每张逻辑表都会配置主键，并标识哪些字段是调用者必须传人的。这样最终的 SQL 肯定会带上这些字段的限制条件，防止对表做全表扫描。
超时时间。设置合适的超时时间，以使得超时的查询能及时终止并释放资源，保障系统不会被偶发的超时拖垮。

（4）监控

调用日志采集
采集的信息包括：
基础信息 ，包括调用时间、接口名、方法名、返回记录数等。
调用者信息，包括调用者应用名、来源 IP 地址等。
调用信息，包括调用指标、查询筛选条件等。
性能指标，包括响应时间、是否走缓存等。
错误信息，包括出错原因、错误类型、数据源、错误堆械等。
调用监控
监控可以从以下几个方面展开：
性能趋势。总体 QPS 趋势图、 RT 趋势图、响应时长区间分布。分组性能统计、单机 QPS 统计，以对当前系统容量做评估。
零调用统计。找出最近天无调用的表，进行下线处理，节约成本。
慢 SQL 查找。找出响应时间较长的 SQL ，及时进行优化。
错误排查。当系统的调用错误数突增时，能从错误日志中及时发现出错原因、出错的数据源等。