巨杉大学SVP专家分享 | 巨杉数据库在数据湖中的应用实践

巨杉数据库SequoiaDB

于 2020-12-09 13:13:39 发布

阅读量746

点赞数

分类专栏： SequoiaDB巨杉数据库教程文章标签：数据库大数据

本文链接：https://blog.csdn.net/SequoiaDB_Official/article/details/110920455

版权

SequoiaDB巨杉数据库同时被 2 个专栏收录

196 篇文章 1 订阅

订阅专栏

教程

49 篇文章 1 订阅

订阅专栏

随着大数据时代的到来，数据已经渗透到各行各业，成为重要的生产要素，数据管理成为当今计算机最重要的应用领域。出于对数据管理领域的关注，不同行业也逐步提升了对数据存储、数据管理及数据分析能力的要求，这一趋势带来了新理念。为此，「巨杉最具价值专家SVP」技术交流会特别邀请巨杉北美实验室核心成员Danny Chen ，讲解数据湖的技术原理与巨杉数据库在数据湖中的应用实践。

01 关于数据湖

从架构演进来说，数据湖可以理解为一个storage即存储区域，存放内容多为原始数据，也叫做裸数据。裸数据是数据原始生成的格式，因此数据湖最大的意义在于当我们不清楚某些数据存在的价值时，可以将数据以原生格式天然沉积在数据湖。数据湖除了单纯的存储数据，还在用户使用数据湖中的数据使其产生价值时，具备了为用户解决数据访问、分析的能力。一般来说，对数据湖的了解主要有以下几点：

数据来源；支持较为方便的将数据按数据原生状态注入到数据湖中。
数据量和种类；可以支持存储多种类的原生数据且支持长期扩展。
数据处理能力；具备对数据进行大数据处理分析能力。
性能和成本；数据湖由于数据量较大，数据类型包含热数据和冷数据，成本是一个考虑因素。

所以，数据湖可以使用不同的注入过程将数据注入到数据湖中。数据来源也各不相同，它能够存储结构化数据（行列数据信息、便于排序和数据挖掘的信息）和非结构化数据（如电子邮件、图片、视频、音频、社交数据、PDF等），最终都是为了在用户需要的时候可以更好的处理数据。

数据湖与数仓的本质区别在于数据湖存储包括结构化和非结构化不同形式的数据。数仓存储的通常是经过转换处理的结构化数据，人们在使用数仓时，对数据的使用目的非常明确，所以在注入数据时按照一定结构、规则来组织和存放。

02 巨杉在数据湖的应用

随着大数据技术的融合发展，数据湖不断演变，逐步实现对数据进行大数据处理、实时分析和机器学习等技术。本章节将介绍数据湖在巨杉数据库的实践中，分布式数据库的优势与数据湖带来的变革。

1.SequoiaDB: 分布式架构

基于巨杉数据库的分布式架构特性，巨杉数据库提供了上层的访问层，可支持包括 MySQL、PostgreSQL 与 SparkSQL 等instance访问。SequoiaDB 存储引擎采用分布式架构，同一个操作系统下可以部署多个节点，节点之间采用不同的端口进行区分。集群中的每个节点为一个独立进程，节点之间采用 TCP/IP 协议进行通讯。

协调节点将用户请求分发至相应的数据节点，最终合并数据节点的结果应答对外进行响应。在特定操作下，协调节点与数据节点均会向编目节点请求元数据信息，以感知数据的分布规律和校验请求的正确性。

巨杉数据库具有原生 SQL与HTAP 读写分离的特殊能力，我们有一个大的底座，使得数据可以持续横向扩展。在上层，巨杉数据库可以支持多种不同的实例，对各类数据库实例做到统一化管理，防止数据碎片化，并对来自不同实例和服务的数据统一实时分析，避免联机交易与分析业务相互干扰。

2.SparkSQL实例优势

Spark 是一个可扩展的数据分析平台，SparkSQL多用于分析型批量处理，在传统的意义上可以理解为数仓。相对来说有以下优势：

专门针对统计分析审计等场景使用。
多个不同联机交易库中的表可以被直接映射到同一个 SparkSQL 实例中，自身无法使用索引，执行非例行非经常性的分析查询，避免ETL迁移流程。
源和目标均在SDB集群中，Transform相对不十分复杂，可能包含数据过滤、简单聚合等。
支持数据分区的读写分离，确保联机交易业务与统计分析任务在不同物理机中执行。
对于关联查询，约70%使用mysql和pg直接完成，剩下约30%，spark在整体性能上明显占优的情况下，则通过spark实现。
Spark能发现SDB的节点状况，直接访问可读的数据节点，并自动使用可能的并发机制，Task数量由需要访问的数据量决定，保证更大的并发处理。
多模数据支持。
数据可以直接注入SDB或通过Spark/Spark stream。

SparkSQL注意事项：

理想情况，spark集群建议在sdb以外的服务器进行部署，效果会更加理想。
如果需要部署在同一集群中，特别是数据量比较大的情况下，建议限制spark集群的资源使用上限，从而保证内存分配给sdb使用。

03 案例分享

案例1:某医院临床知识库系统

医疗系统采集工作难点在于数据量庞杂，数据间隔时间长且采集步骤多。在数据类型上，医疗系统的数据类型复杂。与此同时，由于接入的业务和用户规模增长速度加快，为了满足业务的日常运行，保持数据库低延迟和高性能是基本需求。

在总体架构上，实际分为以下三层：

「数据采集层」：主要负责从临床业务系统采集海量历史临床数据，历史记录采集方式分为批采集和实时采集。
「存储分析层」：主要负责数据存储以及数据分析两大部分业务。使用JSON格式，大数据存储引用使用SequoiaDB数据库，数据分析部分由Spark集群来完成。分析结果写入临床知识数据库，临床知识数据库也使用SequoiaDB巨杉数据库进行存储。
「应用逻辑层」：主要负责人机交互以及分析结构回馈临床系统的渠道，也为临床系统的业务辅助。

系统数据流程如下图，整个系统经由数据源数据采集，写入大数据存储SequoiaDB集群，然后由Spark进行分析计算，分析生成的临床知识再写入SequoiaDB知识库，经由WebUI以及标准的API交由临床使用。

使用SDB的能力包括以下几方面：

多模；具备jason、文档、图像等多种数据格式
对接Spark进行分析处理
联机查询
批量导入与实时数据采集

案例2:某证券客户实时数据查询平台

案例中的实时数据查询平台并非全新平台，而是带有一个开源的mysql能力的老系统，老系统由于业务的发展存在一定的风险：

MySQL数据能否存储上线以来所有的投票明细数据以及统计结果。
当投票数据量达到一定量之后，在实时查询和统计上的性能已经不能完全满足客户需求，与此同时，作为使用者基金公司管理员和投资人亦不能实时看到大会的最终统计结果。
投票明细数据达到一定的量之后，大会结束，准确统计投票结果的耗时以及频率下降。

改造后的系统要求：

能够快速，实时，并发的获取基金投票明细数据。并保证数据唯一，零丢失。
基金投票明细数据按照顺序获取统计。
基金投票历史数据存储备份至高可用，高性能可应对海量数据的数据库中。
基金投票明细数据实时统计入库。实时统计结果在短时间内入库。

最终在原有系统变更改动最小的情况下，附加一个新的基金投票实时统计分析系统。

巨杉数据库在此次的案例中使用了以下处理方式：

使用Spark Streaming 流数据处理模式，分别从kafka topic 中获取基金投票明细数据，并过滤清洗，批量入SequoiaDB库的集合中，在SequoiaDB库的集中建立唯一联合索引。
每个数据批基于Spark Streaming流数据处理的API进行实时统计，并将统计结果更新至MySQL库实时统计结果表中。
SequoiaDB即可以作为流计算的sink，又可以作为批量数据处理和实时访问数据源。同时利用其弹性扩张能力解决海量数据存储和查询。