
根据处理设备的结构方式、工作方式,以及数据的时间空间分布方式的不同,数据处理有不同的方式。不同的处理方式要求不同的硬件和软件支持。每种处理方式都有自己的特点,应当根据应用问题的实际环境选择合适的处理方式。数据处理主要有四种分类方式①根据处理设备的结构方式区分,有联机处理方式和脱机处理方式。②根据数据处理时间的分配方式区分,有批处理方式、分时处理方式和实时处理方式。③根据数据处理空间的分布方式区分,有集中式处理方式和分布处理方式。④根据计算机中央处理器的工作方式区分,有单道作业处理方式、多道作业处理方式和交互式处理方式。
数据处理对数据(包括数值的和非数值的)进行分析和加工的技术过程。包括对各种原始数据的分析、整理、计算、编辑等的加工和处理。比数据分析含义广。随着计算机的日益普及,在计算机应用领域中,数值计算所占比重很小,通过计算机数据处理进行信息管理已成为主要的应用。如测绘制图管理、仓库管理、财会管理、交通运输管理,技术情报管理、办公室自动化等。在地理数据方面既有大量自然环境数据(土地、水、气候、生物等各类资源数据),也有大量社会经济数据(人口、交通、工农业等),常要求进行综合性数据处理。故需建立地理数据库,系统地整理和存储地理数据减少冗余,发展数据处理软件,充分利用数据库技术进行数据管理和处理。
PetaBase-V作为Vertica基于亿信分析产品的定制版,提供面向大数据的实时分析服务,采用无共享大规模并行架构(MPP),可线性扩展集群的计算能力和数据处理容量,基于列式数据库技术,使 PetaBase-V 拥有高性能、高扩展性、高压缩率、高健壮性等特点,可完美解决报表计算慢和明细数据查询等性能问题。大数据实时分析平台(以下简称PB-S),旨在提供数据端到端实时处理能力(毫秒级/秒级/分钟级延迟),可以对接多数据源进行实时数据抽取,可以为多数据应用场景提供实时数据消费。作为现代数仓的一部分,PB-S可以支持实时化、虚拟化、平民化、协作化等能力,让实时数据应用开发门槛更低、迭代更快、质量更好、运行更稳、运维更简、能力更强。
整体设计思想
我们针对用户需求的四个层面进行了统一化抽象:
统一数据采集平台
统一流式处理平台
统一计算服务平台
统一数据可视化平台
同时,也对存储层保持了开放的原则,意味着用户可以选择不同的存储层以满足具体项目的需要,而又不破坏整体架构设计,用户甚至可以在Pipeline中同时选择多个异构存储提供支持。下面分别对四个抽象层进行解读。
1)统一数据采集平台
统一数据采集平台,既可以支持不同数据源的全量抽取,也可以支持增强抽取。其中对于业务数据库的增量抽取会选择读取数据库日志,以减少对业务库的读取压力。平台还可以对抽取的数据进行统一处理,然后以统一格式发布到数据总线上。这里我们选择一种自定义的标准化统一消息格式UMS(Unified Message Schema)做为 统一数据采集平台和统一流式处理平台之间的数据层面协议。
UMS自带Namespace信息和Schema信息,这是一种自定位自解释消息协议格式,这样做的好处是:
整个架构无需依赖外部元数据管理平台;
消息和物理媒介解耦(这里物理媒介指如Kafka的Topic, Spark Streaming的Stream等),因此可以通过物理媒介支持多消息流并行,和消息流的自由漂移。
平台也支持多租户体系,和配置化简单处理清洗能力。
2)统一流式处理平台
统一流式处理平台,会消费来自数据总线上的消息,可以支持UMS协议消息,也可以支持普通JSON格式消息。同时,平台还支持以下能力:
支持可视化/配置化/SQL化方式降低流式逻辑开发/部署/管理门槛
支持配置化方式幂等落入多个异构目标库以确保数据的最终一致性
支持多租户体系,做到项目级的计算资源/表资源/用户资源等隔离
3)统一计算服务平台
统一计算服务平台,是一种数据虚拟化/数据联邦的实现。平台对内支持多异构数据源的下推计算和拉取混算,也支持对外的统一服务接口(JDBC/REST)和统一查询语言(SQL)。由于平台可以统一收口服务,因此可以基于平台打造统一元数据管理/数据质量管理/数据安全审计/数据安全策略等模块。平台也支持多租户体系。
4)统一数据可视化平台
统一数据可视化平台,加上多租户和完善的用户体系/权限体系,可以支持跨部门数据从业人员的分工协作能力,让用户在可视化环境下,通过紧密合作的方式,更能发挥各自所长来完成数据平台最后十公里的应用。
以上是基于整体模块架构之上,进行了统一抽象设计,并开放存储选项以提高灵活性和需求适配性。这样的RTDP平台设计,体现了现代数仓的实时化/虚拟化/平民化/协作化等能力,并且覆盖了端到端的OLPP数据流转链路。
具体问题和解决思路
下面我们会基于PB-S的整体架构设计,分别从不同维度讨论这个设计需要面对的问题考量和解决思路。
功能考量主要讨论这样一个问题:实时Pipeline能否处理所有ETL复杂逻辑?
我们知道,对于Storm/Flink这样的流式计算引擎,是按每条处理的;对于Spark Streaming流式计算引擎,按每个mini-batch处理;而对于离线跑批任务来说,是按每天数据进行处理的。因此处理范围是数据的一个维度(范围维度)。
另外,流式处理面向的是增量数据,如果数据源来自关系型数据库,那么增量数据往往指的是增量变更数据(增删改,revision);相对的批量处理面向的则是快照数据(snapshot)。因此展现形式是数据的另一个维度(变更维度)。
单条数据的变更维度,是可以投射收敛成单条快照的,因此变更维度可以收敛成范围维度。所以流式处理和批量处理的本质区别在于,面对的数据范围维度的不同,流式处理单位为“有限范围”,批量处理单位为“全表范围”。“全表范围”数据是可以支持各种SQL算子的,而“有限范围”数据只能支持部分SQL算子。
复杂的ETL并不是单一算子,经常会是由多个算子组合而成,由上可以看出单纯的流式处理并不能很好的支持所有ETL复杂逻辑。那么如何在实时Pipeline中支持更多复杂的ETL算子,并且保持时效性?这就需要“有限范围”和“全表范围”处理的相互转换能力。
设想一下:流式处理平台可以支持流上适合的处理,然后实时落不同的异构库,计算服务平台可以定时批量混算多源异构库(时间设定可以是每隔几分钟或更短),并将每批计算结果发送到数据总线上继续流转,这样流式处理平台和计算服务平台就形成了计算闭环,各自做擅长的算子处理,数据在不同频率触发流转过程中进行各种算子转换,这样的架构模式理论上即可支持所有ETL复杂逻辑。
2)质量考量
上面的介绍也引出了两个主流实时数据处理架构:Lambda架构和Kappa架构,具体两个架构的介绍网上有很多资料,这里不再赘述。Lambda架构和Kappa架构各有其优劣势,但都支持数据的最终一致性,从某种程度上确保了数据质量,如何在Lambda架构和Kappa架构中取长补短,形成某种融合架构,这个话题会在其他文章中详细探讨。
当然数据质量也是个非常大的话题,只支持重跑和回灌并不能完全解决所有数据质量问题,只是从技术架构层面给出了补数据的工程方案。关于大数据数据质量问题,我们也会起一个新的话题讨论。
3)稳定考量
这个话题涉及但不限于以下几点,这里简单给出应对的思路:
高可用HA
整个实时Pipeline链路都应该选取高可用组件,确保理论上整体高可用;在数据关键链路上支持数据备份和重演机制;在业务关键链路上支持双跑融合机制
SLA保障
在确保集群和实时Pipeline高可用的前提下,支持动态扩容和数据处理流程自动漂移
d性反脆弱
? 基于规则和算法的资源d性伸缩
? 支持事件触发动作引擎的失效处理
监控预警
集群设施层面,物理管道层面,数据逻辑层面的多方面监控预警能力
自动运维
能够捕捉并存档缺失数据和处理异常,并具备定期自动重试机制修复问题数据
上游元数据变更抗性
?上游业务库要求兼容性元数据变更
? 实时Pipeline处理显式字段
4)成本考量
这个话题涉及但不限于以下几点,这里简单给出应对的思路:
人力成本
通过支持数据应用平民化降低人才人力成本
资源成本
通过支持动态资源利用降低静态资源占用造成的资源浪费
运维成本
通过支持自动运维/高可用/d性反脆弱等机制降低运维成本
试错成本
通过支持敏捷开发/快速迭代降低试错成本
5)敏捷考量
敏捷大数据是一整套理论体系和方法学,在前文已有所描述,从数据使用角度来看,敏捷考量意味着:配置化,SQL化,平民化。
6)管理考量
数据管理也是一个非常大的话题,这里我们会重点关注两个方面:元数据管理和数据安全管理。如果在现代数仓多数据存储选型的环境下统一管理元数据和数据安全,是一个非常有挑战的话题,我们会在实时Pipeline上各个环节平台分别考虑这两个方面问题并给出内置支持,同时也可以支持对接外部统一的元数据管理平台和统一数据安全策略。
以上是我们探讨的大数据实时分析平台PB-S的设计方案。
企业实时数据库系统EI模块主要分为八个模块:
企业实时数据库:EI;
数据采集接口:IO;
实时数据应用:Package;
实时数据发布服务器:Portal;
管控数据集成:ERPConnect;
实时数据报表:Report;
实时数据挖掘:DataDig;
开放式接口:OPCServer For EI、API开发包;
企业实时数据库系统EI特点
应用广泛:在化工生产、电力、石油、造纸、钢铁、水泥厂等工业领域,EI均可得到广泛应用。
简单实用:EI针对中国用户使用习惯而专门设计,减少了用户的学习时间,提高工作效率。
辅助工具齐全:EI提供的丰富实用的系统辅助工具和应用软件,为用户分析数据,制作报表、应用开发提供有力支持。
兼容性强:整个EI系统软件模块化,实时数据库核心外的其它模块均可与国外主流实时数据库系统兼容。
开放性好:第三方应用程序可以通过系统提供的OPC Server、API等与EI实时数据库进行通讯。
分布式结构:实时数据库服务器、数据采集客户端、实时数据应用客户端等可以任意组合,分别运行在一台或者若干台机器上。
多服务器:一个EI系统中可以有多个不同类型的实时数据库服务器,如EI、PI和Infoplus.21等。
故障自动恢复:数据采集网络发生通讯故障,当网络通讯恢复后,系统数据采集、传输自动恢复正常。
通讯接口丰富:可和DCS、PLC、智能仪表等多种生产数据源进行通讯,可和其他的数据库系统进行数据交换,给国内外各种DCS、PLC、SCADA以及电力自动化等系统提供OPC Server通讯接口。
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)