【读书笔记】阿里巴巴大数据实践：数据服务（第6章）

本文链接：https://blog.csdn.net/xiaoyangyangxiong/article/details/134009969

第6章数据服务

一句话评论：业务的大发展要求不断丰富数据服务方式；另一方面，数据一致性又要求整合这些服务方式，因此基于统一的数据服务层，利用数据服务平台提供包括定制/拉取/实时推送在内的多种数据服务方式。这就是OneService的诞生。

6.1 服务架构演进

1 DWSOA

需求驱动
一个需求对应一个或多个接口

2 OpenAPI

按统计粒度进行聚合
以会员维度为例：将所有以会员为中心的数据做成一张逻辑宽表，只要查询会员粒度的数据，仅需调用会员接口即可。

3 SmartDQ

在OpenAPI的基础上抽象一层，用DSL（Domain Specific Laguage）来描述取数需求，采用标准SQL语法
封装标准DataSource，用ORM（Object Relation Mapping）来解决对象关系映射问题
封装跨异构数据源和分布式查询功能
收敛到一个接口

4 OneService

统一的数据服务层
解决复杂的业务逻辑和满足多样化的服务类型：
- OneService-SmartDQ：快速简单查询？
- OneService-Lego：个性化取数，插件化开发，将插件做成微服务，使用Docker隔离
- OneService-iPush：实时数据推送，WebSocket + long polling，商家端实时直播
- OneService-uTiming：即时和定时任务
在这个阶段，开始真正走向平台化✨

6.2 技术架构

1 SmartDQ

元数据模型
- 逻辑表到物理表的映射，主题<–逻辑表<–物理表<–数据源
- 逻辑表唯一挂到一个业务主题下，一个接口基于一个逻辑表提供
- 物理表唯一挂到一个数据源下

2 iPush：推送消息的中间件平台

3 Lego：Node.js

4 uTiming

批量数据处理服务，基于“在云端”
支撑用户识别、用户画像、人群圈选三类服务

6.3 最佳实践

1 性能

（1）资源分配
- 1）剥离计算资源：剥离复杂的计算、统计逻辑，将其交由地城的数据公共层进行处理，只保留核心的业务处理逻辑
- 2）查询资源分配：设计Get 和 List 独立线程池
- 3）执行计划优化：a查询拆分，用户不用关心多个指标在哪张物理表中，b查询优化，将符合条件的List请求转换为Get请求
（2）缓存优化
- 1）元数据缓存：服务启动时，将元数据全量加载到本地缓存，之后进行增量更新
- 2）模型缓存：将DSL解析后的模型缓存在本地，下次遇到相似的SQL，直接从缓存中得到解析结果，节省DSL–>SQL的解析时间
- 3）结果缓存
（3）查询能力
- 1）合并查询
  - 需要同时查询离线和实时数据时，优先使用离线数据；
  - 离线数据未产出时，先用实时数据；
  - 等离线数据产出后，使用REPLACE语法将实时数据替换为离线数据。
- 2）推送服务
  - 对消息生产者进行监听，并做好消息过滤
  - 推送无法满足高效的响应需求，为此需要考虑将符合条件的消息放置在临时队列中，或者对重要消息配置单独的队列单线程运转
  - 不同事件采用不同的监听处理，例如消息的推送必须基于Socket，Netty是最终选择？
  - 在注册消息向Filter广播时，采用协程方式减少上下文切换
  - 为重要的业务/主体消息节约服务器资源
  - 缓存也在推送中有应用
  - 突发事件推送处理，用户信息重新投递时，为避免带宽浪费，进行批量投递或者打包投递

2 稳定性

（1）发布系统：保障元数据等变更不会影响正常系统运行
- 1）元数据隔离
  - 一般的应用有三个环境：日常环境、预发环境、线上环境
  - 对应设计了三套元数据：日常元数据、预发元数据、线上元数据
  - 用户修改元数据的步骤：
    - 1用户操作：在元数据管理平台上操作、修改
    - 2预发布：点击“预发布”，预发元数据被加载到本地缓存，验证用户修改是否影响线上功能
    - 3正式发布：验证通过则可以“正式发布”，预发元数据将同步到线上元数据，流程结束。

2）隔离发布：不同用户的发布不会相互影响
- 资源划分：将隔离的粒度控制在逻辑表层面
- 资源独占：锁定正在被修改的逻辑表及其下挂的物理表等资源
- 增量更新：发布/同步增量元数据
（2）隔离
- 1）机房隔离：双机房容灾
- 2）分组隔离：将服务端的及其划分为若干个分组，每个分组都有明确的服务对象和保障等级；动态调整分组规则。
（3）安全限制
- 强制带LIMIT
- 必传字段，防止全表扫描
- 设置合适的超时时间，及时终止超时的查询
（4）监控
- 1）调用日志采集，保障调用日志的完整性，包括：基础信息（调用时间、接口名等），调用者信息（应用名、来源IP等），调用信息（调用指标、查询筛选条件等），性能指标（响应时间、是否走缓存等），错误信息。
- 2）调用监控，利用日志可以进行以下监控：性能趋势，零调用统计，慢SQL查找，错误排查等
（5）限流/降级
- 限流：针对调用者以及数据源等关键角色做了QPS阈值控制
- 降级：将QPS置为0，对应访问立即全部失败，防止故障扩散；修改元数据中的相关资源为“失效”。