点击蓝字,关注我们
01
1、分析维度指标要全,否则就需要建设多个数据集,造成数据集多而散,和之前的报表建设一样的问题;
2、数据口径要准、数据权威;
3、单日数据千万+,查询性能是巨大挑战。
1、全(分析维度指标要全,覆盖业务80%+的需求);
2、准(口径统一、数据准确);
3、效(数据产出时效T+10h);
4、快(10亿级数据查询10s内)。
02
业务看板迭代提效(自助化):数据报表迭代模式发生变化,从PM提需RD排期模式逐步转换为PM/运营自助化操作(做看板/分析数据)。
数据洞察分析提效(极速):单次数据查询从分钟级降低到秒级,指标波动分析效率提升20倍,单次指标波动归因分析端到端从2小时->5分钟内。
业务一站式自助分析(一站式):实现数据趋势观测、维度下钻分析、明细导出等功能,实现了数据监控、数据分析一体化体验。
1、数据源接入:业务使用TDS将上游图灵表数据通过计算引擎计算后,将数据写入到clickhouse/mysql/palo等引擎,通过直连的方式接入;或者业务提供自己的palo/mysql数据源接入。
2、数据建模:对接完数据源,数据可以通过写SQL、直接原始表的方式加载到产品中。但这些表通常还需要做一些简单的二次处理,变成可以被分析的数据集。
3、数据分析:用户基于数据集,自由拖拽指标、维度、筛选,选择合适的图表类型及场景分析方式,进行分析计算。
4、数据应用:用户可将分析结果保存至仪表盘、或嵌出到第三方平台、或保存至大屏、或直接用于智能分析等。
2.1 整体设计
1、统一查询上下文:为了后期扩展其他图表功能时,方便通用功能的复用,设计统一的查询上下文。
2、查询构造器:根据前端传过来的请求参数,构造出查询对象(可以是多个,如对表格分页,需要构造两个查询对象,一个是分页查询对象,一个是计数查询对象)。
3、查询连接器:
a.当前只有SQL连接器,用以满足拼SQL查询的引擎(mysql、palo、clickhouse等),不同引擎、语法或一些函数可能会不同,通过不同引擎规则配置去适配;
b. 未来可以扩展其他连接器满足非sql查询。
4、缓存写入:保证查询性能,两种写入方式,用户首次访问时写入,或通过celery定时任务预热缓存。
5、数据集模块:提供数据支持,和底层数据源建立链接,保证数据质量。
6、系统保障模块:订阅、预警、公告实现数据预警能力,分享、发布、授权提升数据的流转效率,管理中心和权限为数据提供底层管理和权限支持。
1、组件库:提供配置解析、不同图表渲染组件、过滤器组件以及自定义组件能力。
2、交互:封装了页面交互能力,包括拖拽式编辑器、下钻联动、辅助快捷功能、画布能力以及其他事件交互。
3、应用:实现不同的可视化应用,面向不同的用户和使用场景,如仪表盘、大屏等。
2.2 详细设计
多源数据、多图表呈现、多种场景分析计算:BI系统底层数据源引擎不止一种,为了灵活的扩展数据源,且呈现样式上也需要丰富的图表支撑,同时为了满足不同场景下的分析计算,需要支持如同环比、日均值等常用的分析能力。
千万级数据秒级查询:公共数据集的建设思路,便于分析的同时也引入了新的挑战。单日千万数据量,对于查询性能的巨大挑战。
统一查询:统一查询上下文,构造查询对象,底层引擎方言适配,返回统一数据格式,前端渲染框架根据图表类型适配渲染。
查询优化:Ⅰ>缓存+自动上卷,覆盖70%公共仪表盘请求;Ⅱ>优化构建SQL查询,充分利用引擎侧聚合能力;III>多域名并发请求,多协程响应处理。
1、用户在页面上自由拖拽分析:切换数据集,切换不同图表类型,拖拽指标、维度、筛选,查询即可;或想使用一些高级的场景分析能力,一键切换配置。
2、前端请求会处理成统一的查询上下文:包含数据源、查询对象、返回形式,其中查询对象封装了基础的指标、维度、筛选信息,以及高级的同环比、日均值等分析配置。
3、统一的鉴权服务:基于仪表盘和数据集双重鉴权的内核,同时支持行列权限更细粒度的权限控制。
4、构造查询对象:先根据指标、维度、筛选三元组完成基础SQL构造(聚合、分组、过滤),然后根据排序规则,组装排序逻辑,有些高级分析选项(如同环比、日均值等)添加额外的组装逻辑,然后处理分页,整个过程中需要结合方言适配,查询数据时根据不同的引擎链接器查询不同的数据库(如mysql、palo、clickhouse等)。
5、查询&处理数据:通过链接器查询数据后,对数据进行处理(日期格式处理、折线图的透视等)。
6、缓存:处理后的数据写入缓存;或查询时如果直接命中缓存则直接读取缓存数据并返回。
7、前端渲染框架统一渲染:返回统一的数据格式,前端完成图表、样式等适配渲染。
1、两种缓存方式:
首次查询:用户首次访问(缓存穿透),查询数据库,然后写入缓存。
离线任务预热:扫描公共仪表盘图表记录,模拟图表请求(每次更新500+)强刷缓存。
2、自动上卷:
根据历史查询的三元组(指标、维度、筛选),建立上卷表,查询命中上卷表,查询的数据量级大幅减少,性能加快。
查询优化:Ⅱ>优化构建SQL查询,充分利用MPP架构引擎(如clickhouse/palo等)的聚合能力。
1、浏览器并发6限制:通过多域名方式,将图表请求与其他请求分流,保证平台交互流畅,图表请求并发度提升,从而提升总体性能。
对操作系统端口资源考虑:PC总端口数为65536,那么一个TCP(http也是tcp)链接就占用一个端口。操作系统通常会对总端口一半开放对外请求,以防端口数量不被迅速消耗殆尽。
过多并发导致频繁切换产生性能问题:一个线程对应处理一个http请求,那么如果并发数量巨大的话会导致线程频繁切换。而线程的上下文切换有时候并不是轻量级的资源。这导致得不偿失,所以请求控制器里面会产生一个链接池,以复用之前的链接。所以我们可以看作同域名下链接池最大为4~8个,如果链接池全部被使用会阻塞后面请求任务,等待有空闲链接时执行后续任务。
避免同一客服端并发大量请求超过服务端的并发阈值:在服务端通常都对同一个客户端来源设置并发阀值避免恶意攻击,如果浏览器不对同一域名做并发限制可能会导致超过服务端的并发阀值被BAN掉。
客户端良知机制:为了防止两个应用抢占资源时候导致强势一方无限制的获取资源,导致弱势一方永远阻塞状态。
2、服务端多进程+多协程并发:
使用多进程开发时,可能会遇到“惊群问题”,即多个进程等待同一个事件。当事件发生时,所有的进程都会被内核唤醒,但唤醒后只有一个进程获得了该事件并进行处理,其他进程发现获取时间失败后又继续进入了等待状态,监听同一个事件的进程数越多,争用CPU的情况越严重,造成了严重的上下文谢欢成本。
故针对这种情况,uwsgi服务设计并实现了共享锁机制,保证同一时刻只有一个进程在监听事件,解决了惊群问题。
但即使如此,进程数也不能无限制扩增,一般建议等于2倍的cpu内核数。
那既然进程数有限制,如何提高吞吐呢?一般情况下IO是阻塞的,你在读数据库或者读文件时,当前的进程、线程会一直等待,直到 IO 操作返回结果才能继续执行后续的代码。如果我们通过多线程的方式增大吞吐,遇到IO阻塞,线程会卡住,其他并发请求就没线程处理了,通过协程实现异步的 IO,即对于每一个线程来说,在自己 IO 时不再等待 IO 结果,而是先去处理新来的请求,等 IO 完成了再跳回到需要等待 IO 的这段代码。通过这种方式,我们充分利用了程序中的每一个线程,让它们永远有事可做。这种方式提高了整体的吞吐量,降低了整体耗时,对单个耗时没有影响。
推送内容:单个图表、整张报表
推送形式:三种形式推送
图表截图
图表的csv数据邮件附件
报表截图
触发条件:
定时推送,根据cron表达式定时推送。
在数据完成同步时推送,在该报表所有图表关联的数据集完成数据同步时,触发推送条件,完成邮件通知。
推送人:邮箱账号,多个时以“,”分割。
权限:
03
3.1 总结
经过不断迭代,TDA已基本具备一站式自助分析能力,实现了以下几个指标:
规模增长:pv由0增长到2w+,uv由0增长到1000+,每日新增图表由0增长到300+。
性能提升:仪表盘首屏90分位耗时从10s+下降到5s。
业务提效:促成核心业务80%+自助化率,波动分析效率提升20倍,单次指标波动归因分析端到端从2小时->5分钟内。
3.2 规划
随着AI原生技术在各个领域的渗透,未来TDA也会结合AI技术,提升平台的智能分析体验,主要有如下几点:
数据自助接入:会放开数据接入,扩充数据源类型等。
AI+BI:归因分析、嵌出式分析、分析报告等BI能力,结合大模型AI,完善智能分析产品。
管理驾驶舱(探索):OKR目标仪表盘。
END
推荐阅读