前端搞报表 | 数据分析提效全链路解决方案

背景介绍
【前端搞报表 | 数据分析提效全链路解决方案】闲鱼 2014 年成立，到现在的话已经实现了从 0 ~ 千万级 DAU 的跃迁，随着业务的快速发展，业务决策方法紧跟升级。从最原始的经验驱动到更加科学合理的数据驱动。而要做到数据驱动，需要去做大量的数据分析以及大量的数据报表开发。在整个数据分析链路上，存在一些研发痛点：

BI资源紧张、响应较慢
SQL 查询速度慢、等待耗时较长
前端与服务端的联调成本较高
数据类型复杂度高，难以直观发现有价值的信息

本文插图
业务现状

本文插图
数据分析的现状流程分为三个部分

SQL 开发
应用开发
数据可视化、前台产出分析报告

完成一整个开发流程，平均耗时要达到 5 天甚至以上。我们一步一步地来看看，每一个研发节点在现阶段存在的问题，以及能不能去优化和解决它们。
SQL 开发
负责 SQL 开发的同学工种是 BI ，由于BI缺乏工程抽象的概念，导致每个数据开发的需求过来的时候，都需要从 0~1 重新开发 SQL 代码，但绝大部分数据分析需求的基本逻辑是相似的，没有可复用性，使整体效率变得特别低。那我能不能在 SQL 的领域增加工程抽象的概念呢？我把 SQL 抽象成一个一个的原子 SQL ，前台只需要指定原则 SQL 的拼装规则，拼装层对原子 SQL 进行组装得到最终的SQL查询字符串，进而就得到了想要的查询结果，通过这样，重复的 SQL 能被沉淀和复用，大大减少了重复开发的时间成本。另外，因为 SQL 查询的数据量达到亿级以上，每次请求的耗时等待需要几十分钟甚至以上，用户体验非常差，拉低了分析问题的效率，我们的预期是能够把几十分钟的耗时等待缩短到秒级，目前阿里云推出的一个产品是分析型数据库，它能够满足大数据计算场景下秒级返回查询结果，我们可以直接拿过来用。
应用开发
负责应用开发的是服务端同学，使用 Java 来开发应用，主要工作是 API 的封装和数据组装。前端的定位已经从切图仔泛化到非常广阔的领域，我们的能力的边界在不断的往外扩，有句老话：“任何可以用 JavaScript 来写的应用，最终都将用 JavaScript 来写” 。我们为什么不把这一层应用直接用 Serverless ，用 FaaS 的能力把它实现掉呢？
数据可视化
前端同学负责最后的数据可视化。服务端会跟前端约定透出的数据格式，服务端透出什么样的数据，前台默认会进行全量的数据展现，这样就会有一个问题，特别是在闲鱼的业务场景，举一个 Case：要展现一个数据指标波动的趋势图，指标大概有几十上百种，如果前台把这几十上百条曲线同时的渲染出来的话，前台感受到的就是一团密密麻麻的颜色，他很难去感知到里面一些有价值的数据波动信息。在这里面，前台能不能去做一些事情，去深挖里面的一些细节呢？能不能把数据里面显著性比较高的，可能对业务有帮助的信息，把它提取出来，并直观展现到前台呢？
技术方案

本文插图
基于以上的思考，我设计了这样的一套技术方案，分为 3 层：

数据层
服务层（FaaS）
展现层

整体逻辑是展现层会上报DSL（一个结构化的描述）到 FaaS 层， FaaS 层会经过一层 SQL 拼装、生成的逻辑，把最终的 SQL 放到数据层去做查询，数据层把查询到的结果返回到 FaaS 层， FaaS层再经过数据加工把数据回传给前台做可视化展现。我们再 detail 的往下看，数据层提供的能力围绕两点，就是提供满足分析需要的业务数据，并且使能够更方便地管理所有底层数据，这部分依赖 BI 同学协作一起去完成。而其中的数据存储位置，会在两个位置，第一个是离线数据表，原始数据通过离线计算，定时任务调度去进行数据清洗，存储到了离线数据表，然后离线数据表再通过数据集成，把数据同步到我们的分析型数据库里面。 FaaS 层的逻辑包含：提供基础的监控能力，包含了权限控制、日志管理，以及定义标准的查询 API 的出入参，还有数据加工。在应用逻辑抽象这一块，将可复用能力抽象到 SDK 里面。SDK 实现的关键点是 4 点：