1.数据服务

数据服务研究的是海量数据如何方便高效地开放出去。

1.1 服务架构演进

1.1.1 DWSOA

实现：需求为驱动，一个需求开发一个或多个接口，编写接口文档，开放给业务方。

优点：简单。

缺点：粒度粗，不灵活，扩展性差，复用率低，接口数量增加快，维护成本高，开发效率低，无法快速响应。

1.1.2 OpenAPI

实现：将数据按统计粒度聚合，同样维度的数据形成逻辑表，采用同样的接口描述。例如把会员为中心的数据做成一张逻辑表，查询会员维度的数据都调用会员接口。

优点：接口数量收敛。

缺点：维度不可控，随时间推移，维度越来越多。

1.1.3 SamrtDQ

实现：在 OpenAPI 上再抽象一层，采用 SQL 语法。同时也可以用对象关系映射（ORM）框架（例如 MyBatis）来解决。

优点：不用关系底层物理表（例如底层是 HBase 还是 MySQL，是单表还是分库），把逻辑表的作用发挥出来了。

缺点：SQL 不能解决负责业务逻辑，不能满足个性化的取数业务场景。

1.1.4 OneService 统一的数据服务层

实现：提供多种服务类型来满足用户需求。包括 SmartDQ、Lego、iPush、uTiming。

1.2 技术架构

1.2.1 SmartDQ

简单来说就是物理表到逻辑表的映射。

• 数据源：底层多种数据源接入，比如 MySQL、HBase
• 物理表：某个数据源中的一张表
• 逻辑表：可以理解为视图，虚拟表
• 主题：逻辑表挂在在某个主题下

1.2.2 iPush

面向不同消息源，通过定制过滤规则，向 Web、无线终端推送消息。

1.2.3 Lego

面向中度和高度定制化数据查询需求、支持插件机制的服务容器。基于插件可以快速实现个性化需求并发布上线。采用 Node。JS 技术栈实现，适合处理高并发、低延迟的 IO 密集型场景，支撑用户识别发码、用户识别、用户画像、人群透视和人气圈选等在线服务。

1.2.4 uTiming

云端的任务调度应用，提供批量数据处理，支持用户识别、用户画像、人群圈选三类服务的离线计算，以及用户识别、用户画像、人群透视的服务数据预处理、入库。

1.3 最佳实践

1.3.1 性能

1 资源分配

• 剥离计算资源：复制的计算逻辑交给下面的公共层处理，只保留核心的业务处理逻辑。
• 查询资源分配：两种查询接口，Get 接口返回一条数据，List 接口返回很多数据，因此 Get 查询耗时很短，但是在队列等待上消耗大量时间，为了避免不必要的等待，分成两个线程池。减少 Get 请求的等待时间。
• 执行计划优化：
  • 查询拆分：引擎差分调用者的请求，并发执行，返回时汇总，提高性能。
  • 查询优化：将用户的 List 请求转为 Get 请求，提高性能。

2 缓存优化

• 元数据缓存：启动时全部加载到本地缓存。
• 模型缓存：将解析后的模型缓存，下次遇到相似的 SQL 时从缓存中解析。
• 结果缓存：复杂的查询等。

3 查询能力

• 合并查询：比如卖家支付金额查询，日期选今天应该是实时查询，选昨天应该是离线查询。设计新的语法能够统一处理这两种情况。
• 推送服务：轮询会有服务器压力大（轮询时间短）或者实时性不佳（轮询时间长）的问题。推送能很好解决问题。

1.3.2 稳定性

1 发布系统

• 元数据隔离：用户的变更在预发环境中进行充分的验证，验证后在发布到线上环境中。
• 隔离发布：不同用户的发布互不影响。

2 隔离

机房隔离、分组隔离（不同调用者优先级不同）

3 安全限制

最大返回记录数（查询强制带上 limit），必传字段（防止全表扫描），超时时间（释放系统资源）

4 监控

调用日志采集，调用监控

5 限流、降级