简单来讲，就是在标签、数据源等元数据管理的基础上，通过各种圈选条件生成SQL查询语句，执行具体查询，结果导出以应用的过程。

一般查询引擎为OLAP引擎。

以圈人为例，知识点梳理思路

圈品流程类似

业务流程是什么？
对应的技术流程又是什么？
每个流程的技术难点有什么？

业务流程

人群分析的目的

  • 通过对目标人群的分析，找到问题可能的原因，并进行运营投放、AB实验等，以达到提升用户活跃，提升留存，用户增长等目标

典型的使用场景

  • 分析支付宝交易量在哪些用户群体下还可能有提升空间，这时要分析用户的画像分布。或者了解下待运营用户行为特征，画像特征，匹配适合的承接内容【单人群统计分析/最大特征分析】
  • 支付宝交易笔数下降了，分析这段时间内交易用户 和 之前的交易用户的差异在哪里，针对于这部分差异用户再进一步分析为什么他们流失了【人群差异分析】
  • 根据历史的流失用户群体，预测未来可能流失的用户，提前预防流失【业务流失预测】

人和品圈选的结合

电商的核心是人和品的匹配。圈人和圈品如何分隔来 体现不出来合力，做不到好的人货匹配。 在圈品的同时能够同时给出这些品该投什么人，这才能提升匹配效率。更进一步，运营只给定“主题”（目的），算法能力给出品和人的集合。

典型的人群分析流程

  • 1、圈人
    • 可以基于平台已有的权威标签来圈人（个人理解：平台标签应该只是标签，他们需要与业务数据进行join，标签+业务数据 得到全集后才能进行分析）
    • 可以来源于BI的odps表
    • 可以基于已有的人群，根据算法找到相似特征的人群，帮助发现潜在用户
  • 2、分析
    • 洞察分析（人群统计分析、单人群最大特征分析、多人群对比分析，业务流失预测）
    • 漏斗分析：比如，当日新登用户，进入手淘后的行为漏洞是怎样的
    • 留存分析：比如，当日新登用户，点击了淘金币签到（起始行为）后，后续15日内的手淘回访（留存行为）留存曲线是怎样的
    • 其他分析手段
      • 人群分桶：将一个人群一分为N（个人理解，可以做AB实验使用，对比实验人群和基准人群的差异）

技术流程

人群是如何创建的
人群是如何被查询的
人群是如何被使用的

创建人群

方式

  • 文件上传
  • ODPS表引入
  • 标签圈选
  • 算法圈选（比如通过种子人群放大）：如何放大的，如何管理和执行算法的

    技术点

    这里是不是要提前建立人群集元数据。背后需要先做什么？

    这里就是huangjince做的事情，元数据管理。包括底层数据表的引入和管理等。这一步的作用是让后面圈选时知道往哪里查。

算法圈选中，人群放大算法是如何做的。工程上如何管理和执行算法？

人群计算

技术点

人群规模预估

交并差：如何做的？

SQL生成模块（重点）

  • 在标签圈人场景下，通过前台的结构化的圈人条件（一般与业务场景强相关），转换为完整的SQL语句的过程

yuque-domain/ae-ba/rgblzg/qf3hkt

从顶层来看，每个SQL语句都可以从有这样的层级结构 TableScan（最基础的查询语句，select from table） Filter（where） Limit（limit） AGG（count） 每一层都是执行计划的一个步骤，每一层都会生成该层的sql，每一层都是一个完整的sql语句。 以”select from table where a=xx”为例，会生成如下的sql语句： select from (select from table) where a=xx 这样生成的语句是会冗余，但这是一个标准的逻辑执行计划，在底层引擎执行时实际还会先优化（简化）SQL，然后最终执行时，还会再反过来生成“冗余”形式的执行计划。

生成器分为哪几个模块呢？

  • expression部分：in 、like、and这些都是Expression。每个Expression有自己的toSql定义
  • relation部分：filter、limit、agg这些称之为relation，每个relation也有自己的to sql定义

一些核心类

  • TableScan：代表最基础的查询语句部分
  • TableSchema：代表不同的查询模式；比如单表查询，join查询等

原始查询逻辑JSON定义 -> TableSchema -> Table （转换为Relation定义）-> 根据Relation就可以拼sql了（Relation有各自的toSql定义）

人群是如何被使用的

技术点

圈人能力如何给业务系统用？

  • 判定：
    • 目的是什么？（个人理解：判定某个人是否属于某个群组，比如发红包）
    • 方案是什么？为什么会有近端包的方式？
  • 导出：
    • 结果导出到某处（个人理解一般是这样：查询adb-> adb结果快照 -> odps离线存储 -> hbase等引擎实时查询；当然也可能有其他方式 ），然后业务用于投放等
  • 查询

群组导出

  • 一般会将圈选逻辑作为异步任务的形式运行，任务执行结果导出到某个存储；
  • 客户端接受执行结果的消息通知，主动查询dump结果

yuque-domain/ae-ba/rgblzg/okpng3
yuque-domain/ae-ba/rgblzg/un414k

快照的含义？

  • 可以理解为查询结果集。一般会有一个ID 来 标识某次查询结果，并以此ID查询结果

这里面的workflow机制是什么样的？

查询、导出等都定义为一个节点，执行过程抽象为一个workflow

以圈品为例，知识点梳理思路

核心服务能力有哪些

场景

  • 商品投放：圈品投放到C端用户或搜索推荐
  • 在线判定：下游系统调用服务判断某个商品是否在某个商品集里，常见场景：detail页面透标

技术能力

  • 商品圈选：基本都是采用OLAP能力
  • 在线化服务：一般是打平到itemId上，kv存储，快速查询
  • 实时化服务：商品投放一般采用odps存储结果集，业务系统直接用odps的数据构建到自己的业务存储中再使用。 但大促场景 需要选品后 会场实时调控生效，不满足诉求的，所以需要实时链路。

核心技术难点

大数据量导出/同步

不管实时导出还是离线导出 都需要 支持 大数据量的高并行的导出

基本流程：

  • T+1针对每个群组生成导出任务，从OLAP导出到odps
  • 所有任务结果经过一致性处理（表示数据是否已经完备）得到最终结果数据给业务

这里面工程上有哪些优化点 ？待完善
可能的优化方向：并发

实时化能力

应对大促等实时调控场景

这里主要依赖和下游业务系统深度打通和联动。

  • 业务系统触发圈选引擎 dump：olap-adb
  • 导出完成后，通知业务系统可用

自定义编排能力

不同的业务场景深度合作时可能有不同的流程，比如商品集导出到odps后，需要和一些业务odps数据做一些合并处理后生成最终结果集。这种都属于业务特定逻辑，平台支持自定义编写组件 和 定义workflow

混合场景查询能力

既要明细查询，也要有实时 离线的混合指标分析（OLAP）

这里主要是引擎的选择

其他问题

群组导出 目前是从olap导出到odps，能否减少这一步的倒来倒去的成本，进一步提升实时性，直接将olap透出给业务