随着各个业务系统的不断增加, 以及各业务系统数据量不断激增, 业务用户的分析诉求越来越多且变化很快, IT 数据支撑方的工作变得越来越复杂.
1, 数据来自多个不同的系统, 存在需要跨数据源分析, 需要对接各种不同数据源等问题.
2, 需要分析的数据体量越来越大, 并且要快速获得分析结果的问题.
3, 部分数据还需要二次加工处理的问题.
供数据支撑方在业务系统的前端看起来基本没有任何操作, 但背后的逻辑十分复杂, 实现难度也很大. 就像看得到的是冰山一角, 看不到的是海水下绝大部分的支撑.
为了解决日益激增的大数据量分析诉求, 大部分公司会通过搭建 Hadoop,Spark 等大数据架构, 配以 BI 工具做数据层面的分析, 来搭建这样一整套大数据分析平台.
大数据分析很关键的一个点在于性能: 取数快不快, 分析响应快不快, 能否实时?
这个问题除了平台的底层架构, BI 的运行性能也有很大相关.
大家可能普遍认为的 BI, 就是一个数据展现工具, 在前端看起来没有太多有技术含量的操作, 但背后的逻辑十分复杂, 实现难度也很大. 就像看得到的是冰山一角, 看不到的是海水下绝大部分的支撑.
好的 BI 工具都有与之依赖的数据引擎, 数据引擎的作用一方面是数据响应的性能(数据量, 速率), 还有很重要的一点是能否适应企业不同业务情况的模式 / 方案. 比如小数据快速读取, 大数据分布式并行运算, 节点数据实时展现等等.....
FineBI V5.0 版本就是一个可以支撑以上需求的工具, 背后依赖的是 Spider 大数据引擎.
Spider 高性能引擎可以支撑 10 亿量级数据在 BI 前端快速的拖拽分析和展示, 且有高可用架构设计保证数据引擎全年可支撑业务分析.
Spider 引擎的前世今生
为什么叫 Spider 引擎呢? 听起来很像爬虫软件, 和数据分析又有什么关系呢?
一则是字面翻译过来的意思 -- 蜘蛛, 从蜘蛛就很容易联想到结网. 从结网的角度的看, 有两个含义, 一是将之前已有的引擎功能全部联结在一起, 因为 5.0 引擎实现了实时数据与抽取数据的对接与灵活切换; 二是 5.0 数据引擎比较重要的分布式模式, 这种模式是由各个组件组合起来的架构, 结网就是将这些组件联结起来的意思.
二则是谐音法拉利的一款敞篷跑车. 跑车嘛, 速度快. 这款跑车做了加长与加宽设计, 使其更稳定, 保持性能且更安全. 恰好与我们的数据引擎理念不谋而合.
因此, 就取名 Spider 引擎.
再来说说它的发展史.
FineBI 的数据引擎从起初做数据抽取的 cube/FineIndex 引擎, 发展到后来开发了直连引擎 / FineDirect 引擎. 再到 2016 年开发, 17 年到 18 年迅速扩展到 60 多家客户使用的分布式引擎. 引擎功能与支撑数据量都在伴随着时代的发展不断进步. 然而引擎类别繁多, 用户理解与使用都是问题.
因此, 到 v5.0 版本, 将引擎做了大一统, Spider 引擎将之前所有引擎功能全部囊括其中, 抽取数据与实时数据可互相切换, 本地模式可根据数据量情况扩展为分布式模式, 使用与理解上都更加简单了.
定位和亮点
Spider 作为数据引擎, 在 BI 中使用中扮演着支撑数据分析的角色, 强大的数据处理与计算能力为前端的灵活快速应用分析提供强有力的支撑.
亮点:
(1)引擎支撑前端快速地展示分析, 真正实现亿级数据, 秒级展示.
(2)用户可以根据数据量, 实时性要求, 使用频次等, 自由选择实时或抽取的方式, 灵活满足实时数据分析与大数据量历史数据分析的需求.
(3)抽取数据的高性能增量更新功能, 可满足多种数据更新场景, 减少数据更新时间, 减少数据库服务器压力.
(4)合理的引擎系统架构设计可保证全年无故障, 全年可正常使用.
在数据源支持上, 常规的数据源都可支持, 无需担心数据源支持问题.
功能 & 优势
数据部分, 可以做到抽取数据或实时数据. 可以分为三种模式, 详细解释如下:
1. 本地模式(Local Mode)
Spider 引擎的本地模式, 可以将数据抽取到本地磁盘中, 以二进制文件形式存放, 查询计算时候多线程并行计算, 完全利用可用 CPU 资源. 从而在小数据量情况下, 展示效果优异. 与 web 应用放在一起, 十分轻量方便.
2. 分布式模式(Distributed Mode)
Spider 引擎可灵活支撑不同数据量级的分析, 在数据量激增之后, 可横向扩展机器节点, 利用 Spider 引擎专为支撑海量大数据分析而生的分布式方案.
Spider 引擎分布式模式, 结合 HADOOP 大数据处理思路, 以最轻量级的架构实现大数据量高性能分析. 此分布式方案集成了 ALLUXIO ,SPARK, HDFS,ZOOKEEPER 等大数据组件, 结合自研高性能算法, 列式存储, 并行内存计算, 计算本地化加上高性能算法, 解决大数据量分析问题以及在 FineBI 中快速展示的问题. 同时从架构上保证了引擎系统全年可正常使用.
3. 直连模式(Direct Mode)
Spider 引擎的直连模式, 可以直接对接数据库做实时大数据分析. 将用户在 FineBI 前端拖拽分析的操作, 实时地转化为经过处理的查询语言, 实现对企业数据库的数据进行实时分析的效果, 在实时性要求较高, 或数据库计算性能优秀的情况下, 可以采用这种模式, 实现数据的实时查询计算, 且充分发挥数据库计算性能.
直连模式的实时数据与本地模式以及分布式模式下的抽取数据可以灵活转换, 大量历史数据使用抽取数据, 实时性要求较高的数据使用实时数据, 两种方式的数据可以在前端同一个 DashBoard 页展示, 便于用户对数据灵活分析.
底层技术详解
那底层详细技术细节是怎样的呢, 可详细看看下列的介绍:
1. 列式数据存储, 字典压缩
抽取数据的存储是以列为单位的, 同一列数据连续存储, 在查询时可以大幅降低 I/O, 提高查询效率. 并且连续存储的列数据, 具有更大的压缩单元和数据相似性, 可以大幅提高压缩效率.
列式数据存储的基础上, 同一类数据的数据类型一致, 相同值比例较高, 将相同值取出来作为字典, 每个列值直接存储该值映射的索引即可, 之后再做压缩. 这样, 数据压缩比例大幅提升. 如下是原始数据与抽取数据之后的大小对比情况(数据备份系数是 2 份), 可以发现, 小数据量情况下, 数据大小基本无差异; 数据量越大, 抽取后压缩情况越好, 基本可以达到抽取数据: 原始数据 = 1:1.5 的效果.
2. 智能位图索引
位图索引即 Bitmap 索引, 是处理大数据时加快过滤速度的一种常见技术, 并且可以利用位图索引实现大数据量并发计算.
假设有以下的表:
进行如下的查询: 假设有以 select 下姓名 from table where 性别 = ` 男 ` and 教育程度 != ` 本科 `
在没有索引 e 情况下 c 只能一行一行地进行扫描 r 判断是否符合过滤条件 d 符合 ` 加入结加集入结 们现在我们将性别和教育程度中的值建立建立位图索具体如下
其中的 1 代表在这一行是对应的值, 否则即为 0.
由此, 对于性别 = ` 男 ` 这一过滤条件, 我们可以快速取得 "男" 的位图 1010 对于教育程度 != ` 本科 ` 这一过滤条件, 我们可以快速取得 "本科" 的位图 1001, 然后进行取反操作 0110 最后, 将两个位图进行按位 AND 操作, 得到最终位图 0010, 其中只有第三行为 1, 因此第三行就是我们过滤出来的结果
位图索引是一种典型的空间换时间的思想, 由于其空间占用较大而数据结构简单易压缩, 因此做了优化压缩, 使得数据的压缩做到上述展示的效果.
3. 分页引擎
除上述智能位图索引, 我们时常会遇到超大分组(返回结果集百万行以上), 虽然在我们的前端分析展示时, 一次性的操作不需要看到这么大量级的数据. 然而在业务分析时候, 虽然不需全量一次性加载展示, 然而总是有用户会希望看到一些汇总后内容, 之后再做出判断决定下一步的分析操作. 因此一款面向各种类别业务分析师的数据分析工具, 必须要能支持这种分析场景.
在分页引擎诞生之前, 类数据库的流式引擎处理大分组一直是一个难题:
对于 select A, B, C, sum(V) group by A, B, C(返回结果行百万以上)的查询
一方面, 基于 HashMap 的分组计算, 在分组逐渐变大的同时, HashMap 的访问效率也会不断下降. 另一方面, 聚合后返回的数据相当大, 加大了序列化和 reduce 的消耗, 过大的结果数据集也会增加内存的压力.
引入基于树结构的分页引擎之后, 实现父子节点之间的关系可以被快速计算出来, 关系维护构建成功之后, 每个节点就有各自对应的位图索引, 分别遍历即可获得计算结果. 使得大分组计算不再是难题. 如下图中是 100W 大分组之下的展示性能(都是首次计算返回时间, 排除缓存因素), 单位是 s, 可以看到 Spider 引擎的计算时间基本都在 3s 左右. 相同场可以看到 MPP 数据库的效果. 再对比某敏捷 BI 的数据集市情况如下所示, 其中没有数据的场景是该产品不支持的功能或者产品崩溃导致无法记录测试时长.
4. 异步数据导入
数据抽取导入的过程中, JDBC 做数据抽取的时候就开始执行数据压缩工作, 压缩工作不会阻碍抽数的动作. 压缩的时候, 数据的分片处理使得因此压缩量不会太大, 资源占用很少. 同时独立的压缩线程在抽取的同时进行工作, 并行处理减少数据抽取时间. 结合数据存储的优化, 使得海量数据导入避免了 OOM 等性能问题.
下图是一个 100 列, 10 亿行数据表 (其中不重复长字符串表超过 1 亿行) 的导入过程, 将内存控制在 4G 以下, 效果显著(使用 Jprofile 记录资源占用情况的截图).
5. 分布式文件存储系统
Spider 引擎比较重要的两大模式 (本地模式和分布式模式) 是要做数据抽取的, 因此数据存储介质就很重要了. 小数据量的情况下, 为了轻量方便使用, 直接使用本地磁盘作为存储介质, 数据与应用在一起, 没有网络传输时间.
在大数据量存储上, 就需要有廉价的存储方式, 能存储非结构化数据, 能做分布式计算. 那首先就想到 Hadoop 中的分布式文件系统 --HDFS.HDFS 的稳定性以及容错性机制都比较完善, Hadoop 2.X 版本之后实现对 HA 的支持, 可做到存储数据全年可用. 自然, 其在大数据领域的生态也比较好的, 因此我们引入其作为长期冗余备份的存储系统.
但是 HDFS 的存储还是基于磁盘的, 其 I/O 性能难以满足流式计算所要求的延时, 频繁的网络数据交换进一步拖累了计算处理过程. 因此我们引入 Alluxio 作为分布式存储系统的核心存储系统. Alluxio 以内存为中心的存储特性使得上层应用的数据访问速度比现有常规方案快几个数量级. 利用 Alluxio 的分层存储特性, 综合使用了内存, SSD 和磁盘多种存储资源. 通过 Alluxio 提供的 LRU,LFU 等缓存策略可以保证热数据一直保留在内存中, 冷数据则被持久化到 level 2 甚至 level 3 的存储设备上, 最下层的 HDFS 作为长期的文件持久化存储系统.
6. 数据本地化计算
分布式计算是联合多台机器计算, 那多台机器就必然存在机器节点间的数据传输问题. 为了减少网络传输的消耗, 避免不必要的 shuffle, 利用 Spark 的调度机制实现数据本地化计算. 就是在知道每个执行任务所需数据位置的前提下, 将任务分配到拥有计算数据的节点上, 节省了数据传输的消耗, 从而使得大量级数据计算速度也能达到秒出的效果.
7. 智能缓存
智能缓存更多是为了直连模式 (Direct Mode) 的情况下, 系统也能有效支撑并发查询. 由于直接对接数据库, 性能自然无可避免受到数据库的限制. 同时用户分析查询会存在针对相同数据查询场景, 因此引入 encache 框架做智能缓存, 以及针对返回数据之后的操作有多级缓存和智能命中策略, 避免重复缓存, 从而大幅提升查询性能. 如下是首次查询与二次查询的对比效果.
最后, 整体方案还是基于 FineBI 的, 感兴趣的可以先戳↓↓↓体验 FineBI~
了解更多
来源: http://www.jianshu.com/p/877f213bd51e