《实时大数据平台规划设计方案》
- 格式:docx
- 大小:1.69 MB
- 文档页数:17
大数据平台数据管理设计方案一、背景介绍随着大数据技术的持续发展,越来越多的企业开始意识到大数据在业务决策中的重要性。
而大数据平台作为支持企业进行数据分析和洞察的基础设施,数据管理的设计方案对于平台的可靠性和可扩展性至关重要。
二、数据管理目标数据管理的目标是为大数据平台提供高效、可靠、安全的数据存储和访问,保证数据的一致性、完整性和可用性。
三、方案设计1. 数据存储:大数据平台需要选择适当的数据存储技术,并根据实际应用场景进行存储架构和容量规划。
一般来说,可以采用分布式文件系统(如HDFS)和分布式数据库(如HBase)结合的方式进行数据存储。
同时,需要考虑数据的冗余备份和灾备方案,确保数据的可靠性和可用性。
2.数据访问:大数据平台的数据访问需要支持高并发、低延迟的需求。
可以通过数据分片、负载均衡和缓存等方式来提高数据访问的性能。
此外,还需要考虑数据的安全性,可以采用权限控制、加密传输等方式保护数据的安全。
3.数据清洗和处理:大数据平台的数据通常包含大量的噪声和冗余信息,需要进行数据清洗和处理。
可以采用数据预处理的方式,对数据进行清洗、去重、筛选等操作,提高数据的质量和可用性。
4.数据同步和迁移:在大数据平台中,常常需要将数据从其他系统同步或迁移到平台中。
可以通过ETL工具或自己开发数据同步和迁移的程序,将数据从原始系统获取并按照规定的格式导入到大数据平台中。
5.数据备份和恢复:为了防止数据丢失或损坏,需要进行数据的备份和恢复。
可以通过定期进行数据备份,并将备份数据存储在不同的地点,以提高数据的可靠性和可恢复性。
6.数据质量监控:为了保证数据的质量和准确性,需要进行数据质量监控。
可以通过实时监控数据的采集、清洗和处理过程中的异常情况,并及时报警和处理,以提高数据的质量和可用性。
7.数据安全和隐私保护:大数据平台存储了大量的敏感数据,需要采取一定的安全措施来保护数据的安全和隐私。
可以通过数据加密、访问控制和审计等方式来加强数据的安全性和隐私保护。
大数据管理中心规划设计方案2整体规划方案关键能力实现方案实施方案背景与需求分析大数据里有民意有民心用大数据改善政府服务、更好满足群众需求 要依托互联网、大数据优化再造政府办事流程 同时也要加强数据安全保护智慧型政府善政惠民 兴业城市大数据科学管理 精准调控 高效协同……服务民生 拉动产业 孵化创新……✓公共数据共享✓社会数据协同✓数据服务开放✓社会治理✓宏观经济✓市场监管✓生态保护✓促进产业发展✓拉动数字经济优化城市资源配给促进城市科学管理✓应急响应✓事件预防✓形成统一的跨部门、跨地域、跨层级的信息交换共享房产局 房产交易所✓购房资格审核✓交易手续确认✓购房能力评估✓……税务局住建委人社公安✓税收审核✓税收缴纳✓社保年限✓缴纳金额✓房产评估✓人户核实✓户口迁转民政✓婚姻状况大数据平台人社数据民政数据税务数据金融信贷数据人员户口数据……✓逐步实现立体化、多层次、全方位的数 据服务体系✓有效支持电子政务公共服务能力提升横向协同纵 向 联 动宏观数据分析应用城市人口分析规划⚫人口迁移分析⚫人群特征分析⚫人群发展预测⚫……社会安防环保数据金融数据公共服务交通数据医疗数据社保数据公共安全分析预测⚫建筑安全评估⚫人流分析预警⚫……生态环境分析研判⚫大气污染分析⚫水质资源分析⚫…………大数据平台资源领导决策政策研究资源投放算法算力存储……市公安物业单位运营商市急救中心大数据平台 事件感知&实时处理消防部门✓消防接警✓消防出警✓救护车资源调拨✓急救医护资源调拨✓事故路段增派人手✓沿途路线道路疏通✓疏散建筑人群✓检查应急通道✓短信通知涉事区域人员✓实时监控区域人流实时感知策略研判实时传递协同处置人口库法人库电子证照库空间地理库航空公司延误旅客数据大数据平台市级数据库个人信用评级社会数据金融机构出行数据个人征信数据保险公司航班延误险定价小型金融机构个人信用评估个人征信数据延误旅客数据BDACE数据归集的频度无法满足业务协同需要未规划数据实时采集技术,无法支撑高效业务协同城市精细化管理缺乏基础数据保障数据共享和开放能力不全面,应用创新动能不足安全管控能力待提升数据授权、使用、审计的全生命周期管控存在短板,数据的安全防护有待提升未实现数据的统一运营,管理及维护难度过高设备、平台、数据规模高速增长,难于实施高效数据治理, 无法及时发现、诊断及解决问题源端数据标准各异,加工存在技术壁垒湖&库缺乏统一规划,数据标准还需完善 应用支撑能力较为薄弱,容易形成数据沼泽10整体规划方案关键能力实现方案实施方案背景与需求分析数据 标准资源 目录安全 体系整合数据能力赋能智慧运营政策 法规运营 策略打造信息化枢纽平台 能力统一管控技术平台逐步实现数据能力规模发展 围绕城市治理提供全产业链服务数据联动数据汇聚管理 制度大 数 据 体 系数据治理AI 服务业务服务数据服务促进大数据供给侧改革,围绕 大数据各项能力开放,推动数 据应用创新发展,激发数据价 值整合现有公共数据资源,布局 行业数据引入,逐步形成城市 数据枢纽搭建数据,业务,智慧三大 中台,与行业先进技术保持 同步演进;打造城市数据运 营、事件管理等数字孪生技 术能力1数据 汇聚3服务赋能2技术驱动使能高效协同,全面优化数据动态更新与同步机制推动公共数据完整归集,按需及时同步和更新公共数据,形成大数据枢纽,保证委办间政务协同驱动数据应用,进一步完善大数据中心主题库建设完成主题数据库建设,推动数据资源整合及数据分析应用聚焦服务赋能,初步构建中台能力开放体系搭建统一流数据处理和业务中台,并完善数据共享服务与数据分析和可视化服务,提升数据共享与开放效能加强数据运营,推动全市数据统一标准化管理及运维构建统一数据开发与调度,增强数据管理能力建立统一数据运维和自有的大数据组件技术栈,保障平台稳定运营确保安全可控,完善数据安全和平台安全管控建立完整的平台安全和数据安全管控体系,保障数据安全管控13市领导各委办局分析人员区政府外部机构公民开发者运维管理者数 据 层服 务 开 放 层门 户应 用 层非结构化数据区对外开放区对外数据开放脱敏区数据沙箱数据沙箱数据沙箱视频数据音频数据图片数据……数据私有数据处理一期升级开放中心一网通办城运系统运营中心分布式存储分布式分析数据库RDB 存储缓存存储采 集 分 发 层数据管理元数据 管理数据开发数据质量 管理数据安全安全合规 管理安全配置 检查网络安全 分析安全事件 响应敏感数据 加密敏感数据 脱敏数据泄漏 防护数据目录任务调度统一 运维数 据 运 维平 台 运 维数据标注共享中心业务中台服务规则定义事件管理AI 中台服务边缘计算存储数据实验区项目1数据项目2数据项目n 数据项目3数据经济运行社会治理二期大数据区实时数据区应用租户应用租户应用租户实时模型实时指标实时事件结 构 化 数 据城市大脑……批量计算流计算挖掘计算计算AI 能力(语音识别、人脸识别)深度学习(模型训练)离线采集实时采集数据采集数据源互联网爬虫政务数据(国家、市级、区)公共事业数据行业数据(金融、电信)互联网数据….物联网数据(气象、摄像头…)流媒体采集数据导入上报物联网网关采集准实时采集图数据库事件服务数据中台服务数据共享交换服务分发消息查询下载数据分析和可视化服务数据可视化工具数据探索工具文件数据开放服务申请/计量合作开发创新研究共享层(标签、指标)标准层(主题模型)数据湖整体规划方案关键能力实现方案实施方案背景与需求分析162.统一汇聚推动数据共享协同实时感知支持城市智慧运营价值提炼 支持宏观管理决策数据互补 政企数据互促互进◼计算资源的读写分离:在TDC 、KunDB 等数据库中 对处理和访问节点分离;◼库的读写分离:数据处理 库和数据访问库分离。
数据资源局政务大数据平台规划设计方案目录一、前言 (3)1.1 编制背景 (3)1.2 编制目的 (4)1.3 编制范围 (6)二、现状分析 (7)2.1 政务数据资源现状 (8)2.2 数据平台建设现状 (9)2.3 存在问题与挑战 (10)三、需求分析 (11)3.1 组织需求 (12)3.2 业务需求 (14)3.3 技术需求 (15)四、平台架构设计 (16)4.2 分层设计 (19)4.3 系统模块划分 (20)五、功能需求与任务分解 (21)5.1 功能需求 (22)5.2 任务分解 (22)六、技术选型与平台搭建 (23)6.1 技术选型原则 (23)6.2 平台搭建步骤 (24)6.3 技术平台介绍 (25)七、安全与隐私保护 (27)7.1 安全策略 (29)7.2 隐私保护措施 (30)八、实施计划与时间表 (31)8.1 实施计划 (32)九、预算与成本分析 (35)9.1 预算编制 (37)9.2 成本分析 (39)十、风险评估与应对措施 (40)10.1 风险评估 (41)10.2 应对措施 (42)十一、总结与展望 (43)11.1 规划方案总结 (44)11.2 发展展望 (44)一、前言随着信息技术的飞速发展,大数据已经成为政府和企业提升治理能力、优化资源配置、实现创新驱动的重要支撑。
政务大数据平台作为连接政府内部与外部、政府与社会的数据桥梁,其建设对于提高政府工作效率、促进经济社会发展具有重要意义。
为了响应国家关于大数据发展的战略部署,满足各级政府部门在数据管理、分析和应用方面的需求,我们提出了政务大数据平台的规划设计方案。
本方案旨在明确平台建设的目标、架构、关键技术和实施路径,为推动政务大数据的发展提供有力保障。
在接下来的章节中,我们将详细介绍政务大数据平台的设计思路、功能模块、技术实现以及预期效果,以期为相关领域的研究和实践提供有益参考。
1.1 编制背景顺应数字政府转型要求,国家进入数字化转型新阶段,构建智能化政府已经成为国家战略,这就要求政府在数据管理、应用及服务等方面具有高效响应和灵活多变的能力。
大数据平台数据治理规划方案目录一、内容描述 (2)1.1 背景与意义 (3)1.2 目标与范围 (4)二、大数据平台现状分析 (5)2.1 数据资源梳理 (6)2.2 数据质量评估 (7)2.3 数据存储与管理现状 (9)2.4 数据安全与隐私保护状况 (10)三、数据治理架构设计 (11)3.1 治理组织架构 (12)3.2 数据治理流程设计 (13)3.3 数据质量管理机制 (14)3.4 数据安全保障体系 (15)四、数据治理实施策略 (16)4.1 数据标准与规范制定 (18)4.2 数据采集与整合策略 (19)4.3 数据清洗与校验方法 (20)4.4 数据共享与交换平台建设 (21)4.5 数据备份与恢复策略 (23)五、数据治理保障措施 (24)5.1 组织架构与人员配备 (26)5.2 制度建设与政策支持 (27)5.3 技术培训与人才引进 (28)5.4 监督与评估机制 (30)六、结语 (31)6.1 规划实施步骤 (32)6.2 预期效果与挑战 (33)一、内容描述项目背景与目标:阐述当前企业面临的数据挑战和发展需求,明确数据治理的重要性和迫切性。
确立数据治理的总体目标,包括优化数据管理架构、提升数据质量、确保数据安全等。
数据治理框架与组织架构:构建符合企业特点的数据治理框架,包括数据治理委员会、数据管理团队等核心组织。
明确各部门的职责与协作机制,确保数据治理工作的有效执行。
数据管理策略与流程:制定详细的数据管理策略,包括数据采集、存储、处理、分析、共享和保护等各个环节的标准和流程。
确保数据的全生命周期管理,提高数据流转效率和使用价值。
数据质量标准与评估机制:建立数据质量标准体系,规范数据格式、命名规则等要求。
制定数据质量评估指标和方法,定期进行数据质量检查和评估,确保数据的准确性和可靠性。
数据安全防护与合规性管理:强化数据安全防护体系,制定数据安全政策和措施。
加强数据加密、备份、恢复等关键技术管理。
实时大数据平台规划设计方案实时大数据平台规划设计方案本文我们探讨了实时数据平台RTDP的相关概念背景和架构设计方案。
在架构设计方案中,我们尤其着重讲了RTDP的定位和目标,整体设计架构,以及涉及到的具体问题和考量思路。
一、相关概念背景1.1 从现代数仓架构角度看待实时数据平台现代数仓由传统数仓发展而来,对比传统数仓,现代数仓既有与其相同之处,也有诸多发展点。
首先我们看一下传统数仓(图1)和现代数仓(图2)的模块架构:图1 传统数仓图2 现代数仓传统数仓大家都很熟悉,这里不做过多介绍,一般来说,传统数仓只能支持T+1天时效延迟的数据处理,数据处理过程以ETL为主,最终产出以报表为主。
现代数仓建立在传统数仓之上,同时增加了更多样化数据源的导入存储,更多样化数据处理方式和时效(支持T+0天时效),更多样化数据使用方式和更多样化数据终端服务。
现代数仓是个很大的话题,在此我们以概念模块的方式来展现其新的特性能力。
首先我们先看一下图3中Melissa Coates的整理总结:在图3Melissa Coates的总结中我们可以得出,现代数仓之所以“现代”,是因为它有多平台架构、数据虚拟化、数据的近实时分析、敏捷交付方式等等一系列特性。
在借鉴Melissa Coates关于现代数仓总结的基础上,加以自己的理解,我们也在此总结提取了现代数仓的几个重要能力,分别是:数据实时化(实时同步和流式处理能力)数据虚拟化(虚拟混算和统一服务能力)数据平民化(可视化和自助配置能力)数据协作化(多租户和分工协作能力)1)数据实时化(实时同步和流式处理能力)数据实时化,是指数据从产生(更新至业务数据库或日志)到最终消费(数据报表、仪表板、分析、挖掘、数据应用等),支持毫秒级/秒级/分钟级延迟(严格来说,秒级/分钟级属于准实时,这里统一称为实时)。
这里涉及到如何将数据实时的从数据源中抽取出来;如何实时流转;为了提高时效性,降低端到端延迟,还需要有能力支持在流转过程中进行计算处理;如何实时落库;如何实时提供后续消费使用。
实时同步是指多源到多目标的端到端同步,流式处理指在流上进行逻辑转换处理。
但是我们要知道,不是所有数据处理计算都可以在流上进行,而我们的目的,是尽可能的降低端到端数据延迟,这里就需要和其他数据流转处理方式配合进行,后面我们会进一步讨论。
2) 数据虚拟化(虚拟混算和统一服务能力)数据虚拟化,是指对于用户或用户程序而言,面对的是统一的交互方式和查询语言,而无需关注数据实际所在的物理库和方言及交互方式(异构系统/异构查询语言)的一种技术。
用户的使用体验是面对一个单一数据库进行操作,但其实这是一个虚拟化的数据库,数据本身并不存放于虚拟数据库中。
虚拟混算指的是虚拟化技术可以支持异构系统数据透明混算的能力,统一服务指对于用户提供统一的服务接口和方式。
图4 数据虚拟化(图1-4均选自“Designing a Modern Data Warehouse + Data Lake”- Melissa Coates, Solution Architect, BlueGranite)3)数据平民化(可视化和自助配置能力)普通用户(无专业大数据技术背景的数据从业人员),可以通过可视化的用户界面,自助的通过配置和SQL方式使用数据完成自己的工作和需求,并无需关注底层技术层面问题(通过计算资源云化,数据虚拟化等技术)。
以上是我们对数据平民化的解读。
对于Data Democratization的解读,还可以参见以下链接:文中提到技术层面如何支持数据平民化,并给出了几个例子:Data virtualization software,Data federation software,Cloud storage,Self-service BI applications等。
其中数据虚拟化和数据联邦本质上是类似技术方案,并且提到了自助BI这个概念。
4)数据协作化(多租户和分工协作能力)技术人员应该多了解业务,还是业务人员应该多了解技术?这一直是企业内争论不休的问题。
而我们相信现代BI是一个可以深度协作的过程,技术人员和业务人员可以在同一个平台上,发挥各自所长,分工协作完成日常BI活动。
这就对平台的多租户能力和分工协作能力提出了较高要求,一个好的现代数据平台是可以支持更好的数据协作化能力的。
我们希望可以设计出一个现代实时数据平台,满足以上提到的实时化、虚拟化、平民化、协作化等能力,成为现代数仓的一个非常重要且必不可少的组成部分。
1.2 从典型数据处理角度看待实时数据处理典型的数据处理,可分为OLTP, OLAP, Streaming, Adhoc, Machine Learning 等。
这里给出OLTP和OLAP的定义和对比:(图5选自文章“Relational Databases are not Designed for MixedWorkloads”-Matt Allen)从某种角度来说,OLTP活动主要发生在业务交易库端,OLAP活动主要发生在数据分析库端。
那么,数据是如何从OLTP库流转到OLAP库呢?如果这个数据流转时效性要求很高,传统的T+1批量ETL方式就无法满足了。
我们将OLTP到OLAP的流转过程叫Data Pipeline(数据处理管道),它是指数据的生产端到消费端之间的所有流转和处理环节,包括了数据抽取、数据同步、流上处理、数据存储、数据查询等。
这里可能会发生很复杂的数据处理转换(如重复语义多源异构数据源到统一Star Schema的转换,明细表到汇总表的转换,多实体表联合成宽表等)。
如何支持实时性很高的Pipeline处理能力,就成了一个有挑战性的话题,我们将这个话题描述为“在线管道处理”(OLPP, Online Pipeline Processing)问题。
因此,本文所讨论的实时数据平台,希望可以从数据处理角度解决OLPP问题,成为OLTP到OLAP实时流转缺失的课题的解决方案。
下面,我们会探讨从架构层面,如何设计这样一个实时数据平台。
二、架构设计方案2.1 定位和目标实时数据平台(Real-time Data Platform,以下简称RTDP),旨在提供数据端到端实时处理能力(毫秒级/秒级/分钟级延迟),可以对接多数据源进行实时数据抽取,可以为多数据应用场景提供实时数据消费。
作为现代数仓的一部分,RTDP可以支持实时化、虚拟化、平民化、协作化等能力,让实时数据应用开发门槛更低、迭代更快、质量更好、运行更稳、运维更简、能力更强。
2.2 整体设计架构概念模块架构,是实时数据处理Pipeline的概念层的分层架构和能力梳理,本身是具备通用性和可参考性的,更像是需求模块。
图6给出了RTDP的整体概念模块架构,具体每个模块含义都可自解释,这里不再详述。
图6 RTDP整体概念模块架构下面我们会根据上图做进一步设计讨论,给出从技术层面的高阶设计思路。
图7 整体设计思想由图7可以看出,我们针对概念模块架构的四个层面进行了统一化抽象:统一数据采集平台统一流式处理平台统一计算服务平台统一数据可视化平台同时,也对存储层保持了开放的原则,意味着用户可以选择不同的存储层以满足具体项目的需要,而又不破坏整体架构设计,用户甚至可以在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数据流转链路。
2.3 具体问题和考量思路下面我们会基于RTDP的整体架构设计,分别从不同维度讨论这个设计需要面对的问题考量和解决思路。
1)功能考量功能考量主要讨论这样一个问题:实时Pipeline能否处理所有ETL复杂逻辑?我们知道,对于Storm/Flink这样的流式计算引擎,是按每条处理的;对于Spark Streaming流式计算引擎,按每个mini-batch处理;而对于离线跑批任务来说,是按每天数据进行处理的。
因此处理范围是数据的一个维度(范围维度)。
另外,流式处理面向的是增量数据,如果数据源来自关系型数据库,那么增量数据往往指的是增量变更数据(增删改,revision);相对的批量处理面向的则是快照数据(snapshot)。
因此展现形式是数据的另一个维度(变更维度)。
单条数据的变更维度,是可以投射收敛成单条快照的,因此变更维度可以收敛成范围维度。
所以流式处理和批量处理的本质区别在于,面对的数据范围维度的不同,流式处理单位为“有限范围”,批量处理单位为“全表范围”。
“全表范围”数据是可以支持各种SQL算子的,而“有限范围”数据只能支持部分SQL算子,具体支持情况如下:join:✔left join:支持。