Java BI新生代

来自百度商业运营的实践 孟然

@数据大不懂

关于我

 

孟然 百度 架构师

近10年Java相关研发经验，

关注 •  应用中间件 •  服务化架构 •  高性能计算

Baidu 百度

大纲

没啥效果

Baidu 百度

BI介绍和实施过程中遇到的问题 1

摸索前进和相关Java工具的应用体会 2

技术框架展示及未来的规划展望 3

BI – 印象

好像很贵

OLAP吧 实施周期⻓长

数据仓库

报表 没啥效果

开源的少

数据挖掘

Baidu 百度

ETL

BI – 认识

目标：数据转化为知识

价值：辅助商业决策

方式：一个解决方案

挑战：大数据和分析模型

决策支持

运营分析

管理效能

Baidu 百度

BI – 行业现状

Baidu 百度

BI 1.0 – 标准实施流程

•  应用集成 •  数据价值链

•  数据二次加工（聚集） •  分析建模

应用阶段

ETL阶段

报表阶段

OLAP 阶段

实施 过程

•  数据一次加工（登台） •  质量把控

•  数据三次加工（展现） •  报表可视化

A

R

O

E

Baidu 百度

~70%

BI 1.0 – 技术思路

Baidu 百度

面向存储的DW + 面向分析的DM

物化处理 + 各级缓存

稳定式数据建模 + 报表

比较分析法 + 多维分析法

BI 1.0 – 相关工具

Eclipse  Birt 02

可视化和报表 模型和分析 存储和计算

Jasper  ReportjPivot

Mondrian

ZKSpreadsheetSaiku  AnalyBcs

MS  Excel

Pentaho  KeDleMySQLWeka

Baidu 百度

Hive Palo（百度） ETLJet（百度）

面向RD 提供API

√

面向RD 提供框架

面向用户 提供服务

R

BI 1.5 – 我们的实践

Baidu 百度

技术

n  ROLAP

n  数据库分片

n  多级结果缓存

n  Agg ETL

n  条件预热

n  服务分级

辅助

n  20个VM + 2台物理机

n  UV在3w左右

n 最小数据延迟时间30min

数据

5亿条事实数据的cube 3秒内响应占比97%

不满意

接入组件

报表配置&集成套件

报表运行时服务

多维计算 组件

报表引擎 组件

可视化 组件

公共基础 组件

Cube Access

JavaCC

FlatData Access

Http Invoker

Json Rpc

DB Con Pool

Cluster Agent

Parallel Calculator

Cache Client

UDF Lib

PivotData Model

MetaData Lib OLAP

Engine

条件 格式

规则引擎 计算列 参数

处理器 模板解析

执行引擎 权限接口

设计工具 Cube建模 图形 设计器

高级查询 Parameter

透视表 Pivottable

图形 Echarts

格式转换 Transform

交互分析 Interaction

布局 Layout

XUI Framework

API&URL 服务

固定报表 动态报表 多维分析报表

组件架构

图形 API

OLAP API

预警 API

静态化 API

数据投递 API

透视表 设计器 SQL编辑器

BI 1.5 – 3%的困扰

Monster用户 超大维度、全量事实数据

钻透操作结果不一致 不同粒度数据不同延迟度

无法Ad-hoc 受限于约定好的指标和维度

自服务能力不够 門槛还是高

响应低延迟的交互分析体验

数据低延迟

技术 难点

Baidu 百度

BI 2.0 – Key Points

Baidu 百度

Build

Fullstack@Web

Run

In-Memory/Cluster

Schemaless ETLless Deployless

ElasBc Parallel Mini  Cubes

Template  First InteracBon  First

BI 2.0 基础技术 – Java8 Stream

•  Parallel Stream/Reduction •  Sum/Count/Avg/Distinct •  Filter/Groupby

原型请参考https://github.com/totyumengr/minicubes

内存Cube聚合计算

Baidu 百度

n  Parallel模式远快于Sequential模式，但稳定度不如

n  Concurrent Reduction慢于普通Reduction模式

n  And/Or操作太消耗方法堆栈（XSS），超K个基本不行

n  不支持in，Filter大量value需要定义Predicate

BI 2.0 基础技术 – Java8 Stream 实际测试数据

Baidu 百度

* Java8 Stream parallel循环执行几次sum聚集计算，parallel模式的第一次通常较慢（和sequential模式持平）；

1. vm上800w数据全量sum，parallel模式（约190ms）比sequential模式（约850ms）快4倍左右；

2. 物理机上2000w数据全量sum，parallel模式（约230ms）比sequential模式（约2秒）快9倍左右； * 8G内存中大约可以存放2.5kw条记录（5个维度和4个指标），这些原始数据大小应该在1.5G。 * 3台物理机+1台虚拟机搭建集群上载入大概1亿条数据：

1. 单指标全量sum耗时平均400ms左右； 2. 单指标全量groupby-sum耗时平均600ms左右，结果7000条左右； 3. 单指标全量groupby-distinct耗时平均800ms左右，结果7000条左右； 4. 单指标全量groupby-distinctcount耗时平均800ms左右，结果7000条左右； 5. 虚拟机性能是物理机的1/3~1/2,所以请保持虚拟机载入数据量为物理机1/3~1/2；

**以上基于CPU12核/内存128G的物理机和CPU8核/16G内存的虚拟机搭建集群测试得出**

引用自： http://www.infoq.com/articles/forkjoin-to-parallel-streams Posted by Raoul-Gabriel Urma & Mario Fusco on Feb 21, 2014

传统单线程

Java8 Stream

ForkJoin框架

BI 2.0 基础技术 – Java8 Stream 示例代码

Baidu 百度

•  groupby

•  map merge

•  sum

BI 2.0 基础技术 – Bitmap Index

•  Low-cardinality •  AND/OR/XOR •  Compressed

引用 https://github.com/lemire/RoaringBitmap

内存Cube数据索引

Baidu 百度

n  OLAP操作中切片/切块/下钻等，很好的对应到Bit操作

n  大量value间的And/Or操作非常快

n  非常适合distinct[-count]类计算

n  内存非常友好，适合做大数据量的索引

BI 2.0 基础技术 – Bitmap Index 实际测试数据

Baidu 百度

•  使用compressed bitset对21147413条记录的5个维度（共340386维值）进行索引，占用内存180M。 •  2000w数据量在单机MySQL和Java8 Stream上性能对比：

具体测试数据请参考https://github.com/totyumengr/minicubes

场景 MySQL Java8 单指标全量sum 8850ms 210ms 单指标全量groupby-sum 24860ms 380ms 单指标全量groupby-distinctcount 26050ms 430ms 过滤1000个维值&&200个维值，单指标groupby-sum 34110ms 380ms 过滤1000个维值，单指标sum 12560ms 240ms 过滤40个维值&&30个维值，单指标groupby-sum 300ms 240ms 过滤6991个维值 && 201个维值，单指标sum操作 600ms

BI 2.0 基础技术 – Hazelcast

•  Parallel Query Executor •  Shard Manager •  Delta Data/Index Queue

引用 https://github.com/hazelcast/hazelcast

内存Cube集群

Baidu 百度

n  轻量级去中心化的集群构建和管理工具

n  Distributed ExecutorService实现

n  移除大量缓存Key时有不一致的现象

n  Map实现性能不高，单机单线程3k/s的put操作

BI 2.0 基础技术 – Spring Boot

•  Smart Autoconfiguration •  Cloud Ready – Single Jar •  Easy Dev-Env Setting

引用 https://github.com/spring-projects/spring-boot https://github.com/spring-projects/spring-boot/issues/1106

微服务构建

Baidu 百度

n  真正基于Spring的应用级开发框架

n  消除了Web开发时偏复杂的环境配置过程

n  可执行Fat-Jar目前不适合reload需求环境

n  集成了Metrics、 Jolokia等产品级特性

BI 2.0 – 突破ROLAP

Baidu 百度

Java开源ROLAP的问题

预警类报表服务

性能表现

叉乘10w个维值是天花板。 现实中很普遍的需求：二级行业维度（200个）和岗位维度（至少500个）交叉 大维度条件会被分批请求DB，然后内存合并，处理时间成几何倍数增⻓长。 退化维和distinct聚合使用带来的MySQL IO占用，间断性拉低整体响应。

架构设计

实现复杂度过高。 架构上⻓长年未进行大版本重构；Cache到处散落；实现MDX导致的逻辑复杂 无法处理大规模数据计算。 过于追求segmentcache复用导致的大结果集内存合并非常占用CPU； 单Actor、单机架构，无法发挥出多核/集群优势 数据冷热分级。 未考虑将超大规模Cube中数据进行分级处理，segmentcache过于碎片化

代码实现

深度应用时会踩到一些“坑”。 比如：schema刷新时的memory-leak；诡异的多维度交叉展开时数据汇总出错；加上计算指标后性能骤降；Top和层级内排序问题； 大量的SoftRef、WeakRef使用，导致GC不友好

BI 2.0 – 突破ROLAP

Baidu 百度

Java开源ROLAP的问题

【

变态】

的业务需求举例

On-the-fly维度。 无法落地为Tree状结构的动态维度，如OLTP系统内的数据权限控制问题；指标通过case when转维度查询

组合维度。 业务上希望可以通过下钻追查不同维度层级间的指标问题。

不完整周期的同环比。 比如当前周的环比上周的情况，如果加上月/季度边界条件会更复杂。

distinct-countif。 比如时间维度上看有消费的客户数，还要有同环比。

维值名称频繁调整。 比如在下钻过程中展示当前时间过滤轴维值条件下的一线部門名称。 （现实情况中岗位维度的架构调整比较频繁）

续

BI 2.0 – Tesseract OLAP Engine

Fact + Dimension

Tables

索引管理

（退化）维度

单维轻度聚合

二级索引列

计算列

内置(同环比等)

自定义函数

分析模型

Schema File

SQL生成器

Dialect

Mini Cube

多维模型

DSL Parser Cells Request

REST  API

Pivot Result

Mini Cube

Mini Indexes

任务执行器

Index Task

SQL Task

Baidu 百度

逻辑

BI 2.0 – Tesseract OLAP Engine

Baidu 百度

物理

Index Store@主（MMap/NIOFS）

查询服务 （A版本）

增量更新 （B版本）

索引节点@副本

查询服务 （A版本）

增量更新 （B版本）

Index Writer线程 申请更新锁

载入数据/索引写入

开始副本分发

索引管理 - cube1/B building - cube2/A working - cube3/B dispatching

Index Reader线程 Filter

Map Collecor

Nginx Cluster

REST  API

Netty IO

Embedded Tomcat Rest Handler

JVM（Spring Boot App）

Data Source JMX Exporter

JVM

Netty IO

Embedded Tomcat

Index Reader

Index Writer

Dispatch Task Query Task

Fact + Dimension Tables

Groupby

Check

sum/count/distinct Sort

Agg by Java8 Stream Split

Route

Fill

Combine

MiniCubes MiniCubes

Hazelcast

- Cluster Manager - Cluster Event Queue

Cluster

BI 2.0 – 突破传统报表

Baidu 百度

设计器

提供客户端软件形式居多。比如JasperReport和Birt

纯画布式设计理念。門槛非常高

面向报告类的排版⻛风格设计。CSS绝对定位

数据可视化

多以平面表格（最多二维交叉表）来承载数据模型

面向“打印机”的报表。 缺乏报表内组件的Interaction设计思路。整体驱动力仅仅是一条SQL

可视化能力较差。 图形大都后台生成的静态图片，缺少现代富交互图形效果。 更加缺少领域内的可视化模型：营销转化漏斗、类脑图的因素分析

二次

开发

后端技术生成的HTML报表。 报表⻚页面结构组织非常“怪异”，无法深入集成：比如内外⻚页面间事件通知

Java开源报表引擎的问题

BI 2.0 – 突破传统报表

Baidu 百度

Java开源报表引擎的问题

方法：用现代FE技术来做报表和分析工具

【

变态】

的业务需求举例

报表⻚页面中部分功能的权限控制。 比如：下载功能需要的权限控制，无权限不显示按钮。

报表⻚页面中可以嵌入OLAP工具。 主题分析业务上希望可以有多维交叉和钻取操作，但同时操作不能过于复杂。

固定报表多端展现一致。 同一报表在浏览器、Outlook邮件、下载的Excel中表现一致。

支持在浏览器上全流程制作报表。 开源的报表设计器操控不符合“国情”，用户觉得还是太偏的RD工具。

续

BI 2.0 – XUI Engine

Baidu 百度

前端引擎驱动模式

数据准备

报表组装

数据获取

数据加工 函数表达式计算列/条件格式

透视表模型

处理链

JSON “data”:“OK”

平面表模型 图形模型

权限 系统

DAL

DB

CUBE

App 数据权限

报表服务接入物理模型

报表使用 RMI

VM <div>…</div>

模板化之路 = 打通前/后端组件

BE Access

Entry

元数据 DB

日历 下拉

树形 输入 Form

JS图形 拖放

点击

导出

透视表 平面表

面包屑

OLAP

下载

参数 组件

图形 组件

表格 组件

Interactions Bus

Interactions Bus

Json RPC

Param Handler

Pivot Data Model

Chart Handler

Data Access Layer

Calc/Cf Handler

Distribute Cache

Cube Meta Mgr Olap Model Service

应用 DB

Frontend Action

Data Transfer Bus

静态文件 服务器

1. DI Factory

FE Engine

2. Bind UI event

3. Regist interaction

4. Init phase

分⻚页

①

②

WebSocket

BI 2.0 – Rich Interactive Report

Baidu 百度

融合OLAP分析能力和报表可视化能力

1. 时间粒度及时间点切换

3. 切片切块

2. 维度指标切换

5. 个性化定制报表

4. 数据下载

6. 维度可下钻 7. 指标排序对比

8. 可下钻至账户明细

9. 趋势分析

•  适度放开OLAP分析功能，平衡操作复杂度 •  加入分析过程可视化支持，增强一体化体验

Demo

BI 2.0 – ShowCase

Baidu 百度

BI 2.0 – 开源计划

Baidu 百度

平台整体开源

2014/10/31

hDps://github.com/Baidu-­‐ecom/bi-­‐plaYorm

•  报表设计器@Web •  JS OLAP工具

•  Tesseract OLAP引擎

BI 2.0 – 未来规划

Baidu 百度

移动BI方向

大背景

n  决策支持需求客户基本上不在PC端工作

n  业务管理层在移动端有更高的管理效能类指标查询需求

n  语音入口和声音出口更有利于BI类“片状”信息的获取

技术需求

ü  语音识别（百度擅⻓长的领域）

ü  App开发（目前已非难点）

谢谢

@InfoQ   infoqchina