BI工具-取数分析
全链路监控平台-指标异常（销售额突然降低很多）
数据资产管理
画饼的能力，组内画饼也很重要，调用组员积极性
数据服务的工作，很多跟数仓的工作耦合在一起，尤其是一些自驱的项目，类似于自助取数工具，或者是一些全链路监控的质量保证系统，都是强耦合在数仓的，所以一些工作最好由数仓和服务组统一的老大来统筹安排

数据本身

数据内容
数据质量
数据展现形式

BI工具建设

自助取数工具
自助分析工具
能力开放、对外赋能

需求定制开发 -》自助取数工具 -》自助分析工具 -》其他组的配置化页面可以复用数据组的底层查询路由能力

最好底层取数工具和上层报表展示层解耦，因为有的用户只需要取数，可能不需要配置多么好看的报表

行业标准

有些东西不一定一定要根据业务需求来，一些业界成为标准的东西，可以先建设，然后推动业务同学去使用，比如说：

数据分析的指标二次计算：我们现在支持同环比，是不是还有其他的二次计算功能？
一些业界沉淀的展现形式：一些前端的UI也可以参考业界标准来实现，而不是一定要根据业务需求来做

规范和限制

服务端同学往往只注重代码层面的规范，做的也会相对比较好
对与sql的限制不多，也没有明确的规范和最佳实践，sql写的太复杂，随着数据量增大，性能会有问题，库也受不了，例如品类分析、供应商看板等
所以需要对sql有规范，其中一种方式就是统一的取数工具，取数不是自己写sql，而是通过取数工具统一进行获取

取数工具

核心点：

指标一致性
指标和维度接入速度
- 支持自定义维度，例如某个维度的分段可以作为一个新的维度，比如说头部品类这种
一些衍生&复合指标的快速生成，而不需要数仓二次加工
指标的二次计算逻辑，应该沉淀在取数工具层面，而不是在报表封装组件中
数据模型到数据产品的打通
数据，元数据，基础服务，API

技术点：

查询接口入参和出参统一
- 出参分成数据部分和模板部分，而不是整体的结果跟展示形式耦合在一起

分析工具

分析工具跟取数工具的区别，取数工具帮助用户更快、更准、更好的获取想要的数据，数据拿到了用户可能根据当前阶段的工作进行一些分析，以数据反推业务，促进业务发展；分析数据其实是希望能将用户自己分析的这个过程线上化，线上化的好处主要有：

提效，用户取数之后自己再分析，这个过程效率比较低
沉淀，会用数、分析数据的用户只在少数，其他用户如何分析，通过将头部用户的分析思路进行线上化沉淀，能够将好的思路进行推广，帮助数据分析相对较差的用户更好的运用数据

分析工具的主要形式有：

对比分析
- 同环比、自定义同环比
- 下钻对比
- 同环比波动排序
占比分析
- 各个品类的销售额占比
自定义指标
- 分析需求往往需要自己定义一些指标，典型的是一些衍生指标、计算指标，通过添加限定词、四则运算产生的新指标
自定义分类
- 维度分组：定义城市分级分组，整体对比分区的情况
- 指标分段：销售额TOP20的商品数量等
自定义时间的计算、环比、趋势
- 如果是最近7天，可以时间维表关联事实表，join的条件不是日期相等，而是日期有个7天的delta
- 如果是自定义周等统计时间，需要通过时间维表来进行统计，事实表去关联时间维表
智能分析
- 除了展示数据，分析数据变化，还能帮助用户发现变化背后的原因
- 波动贡献分析：维度拆解、指标拆解（指标公式拆解）

多维分析产品

还原数据事实
定位异动问题
分析问题原因

交互形式：

透视图：多维度组合下钻展示

数据资产管理

数据相关的元数据管理：

元数据应用层
元数据存储层
元数据采集层
数据源
元数据体检（什么东西都需要有监控，即使是监控也需要有监控）

指标和维度：

指标的目标是个指标，有一张事实表，第一列是维度，存储的是指标id，第二列是目标，存储的是目标值；因此需要一个维度叫『指标』，需要一个指标叫『目标』

底层查询引擎

执行计划解析：逻辑执行计划&物理执行计划

逻辑计划树虽然可以看到各个节点之间的关系，但是我们不知道如何去分布式执行。比如各个节点之间的数据传输需不需要进行 Shuffle，如果需要 Shuffle 是用 ROUND_ROBIN 还是 HASH 等分区策略？到目前为止，我们是完全不知道的。所以我们需要进一步处理这个执行计划树，使得它变成物理计划树。

统一查询协议
DataSet统一数据集抽象
Operator统一算子管理

工具入参和响应的定义

入参不要用一个固定字段，比如说bu_id来让前端传对应的值，这样只要前端加一个下拉框就需要我们修改代码。

每个下拉框对应一个维度，每个维度对应一个稳定的id或者code，所以前端的多个下拉框对应的入参是这样的

{
  "condition": [
    {
      "dimId": 100,
      "dimCode": "bu_id",
      "dimValues": [1,2,3]
    },
    {
      "dimId": 1001,
      "dimCode": "cat1_id",
      "dimValues": [1,2,3]    
    }
  ]
}

不能说这种入参一定是最好的，但是对于数据平台的通用BI报表工具，这种应该是通用性最强的，我们后端也不需要做一堆转化，直接通过前端的入参的维度信息，映射到需要查询的起源的维度即可。