乐趣区

关于elasticsearch:基于-Elasticsearch-的数据报表方案

jiezi

文 | 闵令超 网易智企高级利用开发工程师

前言

数据报表剖析对于企业管理者的剖析决策有着至关重要的作用，因而数据报表的灵便可用以及数据的准确性显得至关重要。本文会介绍基于 Elasticsearch 的数据指标零碎，心愿对大家有肯定的借鉴和帮忙。

背景

数据报表通常在业务开发中是必不可少的一部分，对于 To B 的利用更是如此。企业在应用产品的过程中必然须要对于整个的业务状况有一个精确的判断和剖析，这就须要咱们可能提供给企业尽可能多维度的具体的数据报表。

初始数据报表计划

在我的项目的初期，为了业务的疾速倒退，往往采取的是比较简单的架构进行解决，如下图所示。依据产品对于指标的定义，通常开发通过代码的模式间接定义指标的运算，依赖自研或者开源的定时任务调度零碎，跑出相应的指标计算结果，保留到两头表中，查问的时候依据不同的筛选条件，从不同的两头表中获取指标的计算结果。

存在的问题

  1. 口径不统一。在上述架构中，当不同的业务有数据穿插场景时，往往是从其余业务方复制相干指标计算的代码拿来应用，这会造成数据指标口径发生变化时，各个业务的雷同的指标呈现了指标口径不统一的问题。
  2. 开发效率低。每次增加指标 / 批改指标都须要批改代码、增加数据库字段等多步骤，导致整个的指标开发周期特地的长。
  3. 不同维度的指标的计算逻辑解决逻辑、工作不同，每次批改逻辑须要批改多个中央。

基于 Elasticsearch 的数据报表计划

随着业务的倒退，指标的定义越来越多，报表也变得越来越丰盛，基于定时工作架构的弊病裸露的越来越显著，开发的累赘变的越来越重，在这时候，就须要对上述架构降级，缩小业务开发的工作量。此阶段，因为数据量依然不是很大，同时为了业务不便开发和保护，能够参考数仓零碎，搭建一个繁难的数据指标零碎。

思考到上述存在的问题，首先须要明确大的方向和指标。

  1. 规范化数据指标的开发流程，保证数据口径的对立。
  2. 提供数据指标平台，便于业务开发可能基于 SQL 开发大部分的指标，缩小指标的开发工作量，进步指标的开发效率。
  3. 明确整个数据报表的生产流程，参考数仓建设计划，规范化整个数据指标的产出流程。
  4. 提供无效的 SDK，不便业务方的调用。
  5. 须要反对多数据源，在业务中往往不止一个数据源，可能会有 MySQL、Hive、ElasticSearch 等多个数据源，所以须要反对从多数据源会集数据的能力。
  6. 须要对于指标的异样进行及时告警，不便开发排查业务异样。

术语简介

  • 原子指标：原子指标是指最细粒度的指标，即不能再向下拆分的指标，例如 指标 A= 指标 B+ 指标 C，那么这里指标 B 和指标 C 即为原子指标。
  • 复合指标：复合指标是多个原子指标通过计算解决获取的后果，例如 指标 A= 指标 B+ 指标 C，这里指标 A 就是示意复合指标。
  • 维度：数据查问的角度。个别是指日期、客服组等信息。如下图中标红局部即为维度信息。

  • 工夫周期：工夫周期是用来形容一个指标的计算范畴。在统计指标的过程中必须指定用于计算的工夫周期字段，通常，原子指标的计算的最小工夫周期为小时，天数据基于小时数据做聚合得出。
  • 报表：报表是一系列复合指标 / 原子指标的汇合，通常业务方获取的指标数据都是一张报表。
  • 业务域：一个我的项目往往会有多条业务线，每条业务线咱们能够了解为一个业务域，以七鱼为例，如在线会话、呼叫等，任何的原子指标、复合指标、报表都属于某一个业务域。

架构

基于上述指标，这里以 Elasticsearch 的聚合查问能力为依靠，搭建如下的数据指标平台架构。

整体分为 5 大部分：

  1. 原始数据层：次要是关系型数据库中的表数据
  2. 明细层：次要是通过 binlog 同步到 Elasticsearch 中保留。
  3. 业务层：次要包含两大部分，指标计算和项目管理。指标计算次要是基于明细层数据以及业务开发和产品定义的指标口径，产出相应维度的指标。项目管理次要是维度、指标、业务域相干配置等。
  4. 网关：提供对立的 SDK 便于业务方的间接调用。
  5. 业务方 / 控制台，业务方调用 sdk 获取报表数据以及维度、指标等控制台的配置。

从整个架构体系来看，上述架构次要是对立了各个业务的原始层和明细层数据，并基于此开发了数据指标配置零碎，可能疾速的响应业务需要，将数据指标的开发周期大大缩短，也防止了开发人员间接在代码外面编写指标计算代码，带来口径不对立或者反复建设的问题。

原始数据层 / 明细层

从上图中能够看到，最底层局部是原始数据层和明细层，这个是整个架构的根底所在。从原始层到明细层同步采纳 binlog+ 自定义音讯的同步形式，具体架构如下：

同步数据次要有三种模式：

  1. binlog 模式。通过 binlog 模式，同步数据库中相应表中的数据，依据指定的关联表的惟一键，能够将多张表的数据同步到一张大宽表中，不便指标的运算。binlog 同步能够依附开源的 Canal、Maxwell 等组件，也能够是自研组件等。
  2. 全量同步模式。当 binlog 同步呈现数据失落，或者须要历史数据同步时，采纳全量同步的模式进行数据的补全和修改。全量同步次要依赖业务的定时任务调度零碎。
  3. 自定义 topic。当数据统计须要增加自定义字段而又不想在数据库中增加相应字段时，能够通过自定义 topic 将想要增加的字段增加到对应的大宽表中。

明细层数据的存储在 es 中，通过明细层能够实现业务到数据的转换，保留维度信息以及最细粒度的数据。聚合层可基于明细层进行简单的指标计算。

明细层数据保留在 Elasticsearch 中，咱们须要思考索引的分片规定，避免因为分片规定导致索引的数据分布不平均，会对于搜寻和聚合产生较大的影响。对于索引的划分，通常采纳月份进行划分索引，这样保障明细数据在各个索引中会比拟平均的散布，同时，当索引较多时，也不便对于历史索引做冷数据处理，聚合的速度也可能保留比较稳定的状态，不会因为某个索引的数据过多，升高聚合的速度。

聚合层

聚合层负责对业务指标进行积淀、向上提供对立的计算口径，同时能够基于现有的指标进行组合查问，防止反复计算指标。目前指标的查问计算均通过 Elasticsearch 计算。通过依赖 ElasticsearchSql 组件，能够使得业务方通过编写 SQL 的形式定义原子指标，如下 

SELECT COUNT(*) 
FROM table_1 
WHERE condition_1<>2 AND condition_2=2 GROUP BY A,B

如下面语句所示，WHERE 即原子指标计算的查问条件，GROUP BY 即指标计算的维度。具体计算流程如下：

当然在聚合指标数据的过程中，过多的指标聚合查问，可能会导致 Elasticsesrch 的 CPU 负载过高，为了防止这个问题咱们须要调整工作策略，每个指标一次批量解决多家企业，这样能够大大降低申请的次数，进步了工作的执行速度，保障了 Elasticsearch 集群的稳固。

在理论的业务指标开发中，常常会碰到产品对于指标的定义的扭转，当指标定义扭转时，须要测试用户对于改指标变动的反馈水平，以及可能提供相应的策略，不便回滚到老的指标定义的数据。

针对下面的问题，咱们提出了环境和版本的概念。指标的上线会有业务定义的多套环境，例如灰度和全量。通过环境，能够给一部分企业尝试切换新的指标定义，测试反馈成果。同时，每一个原子指标会有多个版本，每一次定义的扭转都会产生一个版本，复合指标能够抉择相应版本的指标进行后果的计算，如果客户对于新的指标定义不称心，仍然能够回滚到之前的版本。具体的操作流程如下图所示：

业务方调用

业务方增加指标并调用的整个流程如下图：

如上图所示，业务方须要增加指标时，须要在原子指标池中增加相应的指标计算规定，默认初始化版本为 V1，如果须要同步历史数据则在增加指标时创立历史数据同步工作，创立完工作之后，零碎会主动计算并同步所选时间段的指标数据，历史数据同步实现之后方可在指标建模中勾选新指标。指标建模实现之后，通常是须要业务方在本人的定制化报表中增加建模之后的指标，通过 SDK 获取相应的报表时，会主动返回增加的指标值。

总结与瞻望

当然，上述的架构仍有肯定的局限性，当业务倒退到比拟大的规模，业务线逐步增多，业务数据量级也逐步增大，企业对于数据的需要要求会变的更加的多样，往往咱们的报表不能充沛的满足客户的需要，这个时候，就须要给客户提供自定义报表的能力，使其不局限于零碎内提供的报表查问维度，对于一个指标，企业能够从任意的可选维度进行查问剖析。这个时候这套计划曾经不能满足客户的需要。所以须要对报表零碎再次进行架构降级，这时候能够搭建业务外部的数仓零碎，整合外部企业剖析以及对外数据报表输入能力。

更多技术干货，欢送关注【网易智企技术 +】微信公众号

退出移动版