社保行业推动业务数据大集中,多业务混合负载特点下关键系统如何实现数据强一致性?

全国社保行业有一个特点,省级社保和市级社保分开,是两套独立运行的民生系统,全国的社保联网尚未完成,无法实现数据共享。这种现状维持了很多年,始终没有得到改善。然而由于这几年经济一体化的影响,全国人口的流动性加剧,大多数的社会公民,都离了出生地,和户口所在地,四处打工。如果...显示全部

全国社保行业有一个特点,省级社保和市级社保分开,是两套独立运行的民生系统,全国的社保联网尚未完成,无法实现数据共享。这种现状维持了很多年,始终没有得到改善。然而由于这几年经济一体化的影响,全国人口的流动性加剧,大多数的社会公民,都离了出生地,和户口所在地,四处打工。如果在异地他乡,想要享受医保待遇、社保待遇,那几乎是不可能的事,因此现在人社部正在着力推动各地省级大集中。我们知道银行系统,全国联网已实现多年,公民信息系统也已实现全国共享;所以社保系统全国联网,是时代发展的迫切要求。 那么:

1、社保数据数据大集中,要考虑哪些业务特点?

2、在基础架构层面,需要重点解决哪些技术层面问题,又是如何分步骤实施呢?

3、集中平台实现数据强一致性的架构方案有哪些?

4、集中平台的前端、后台服务器应该如何选型?

欢迎大家参与交流探讨!

收起
参与160

查看其它 9 个回答ibmlinfeng的回答

ibmlinfengibmlinfeng系统架构师IBM

一点浅见,抛砖引玉。

1、社保数据大集中,要考虑哪些业务特点?

社保省级大集中模式的基础是数据集中,不仅在物理上而且在逻辑上都要求最终建立统一的数据记录系统,以便于各业务模块之间、各地域之间统一有机地共享全部业务数据和人员信息。数据集中之后要求数据库服务器必须具备充分的扩展能力,以便保证业务发展时始终保持单一的数据映像,不改变IT架构的逻辑,不影响业务既有的规则与流程。

数据集中之后单一数据库的数据量将跳跃性地提升。数据服务器必须保证在超大数据量的情况下仍能保证业务处理的服务水平,特别是联机实时处理和批量数据汇总的服务水平。大集中后数据库服务器将同时为多种类型的业务应用提供数据服务,这些业务应用特点不尽相同,服务水平和响应时间要求都有差异。要求数据库服务器必须能够满意地保证所有业务类型的服务水平要求,同时提高有效的资源利用率。从业务特点来讲,大致有下面几种分类:

1.    联机事务处理(OLTP):必须能够高效地处理省中心核心业务的联机处理,包括人力资源、劳动就业、社会保障五险业务、社保卡业务,信息交换业务和公共服务业务,等等。业务量参照覆盖人口数计算。

2.    批量处理(Batch):月末/年末结算/测算(征缴费、养老待遇、拨/付款、查询统计,等等)。必须能够按照业务部门的要求在规定的时间窗内完成任务,保证业务的正常开展。例如:对于单项业务的月度征缴核算等任务要求在30分钟内完成;对于单项业务全省的月度并发核算要求在60分钟内完成;对于单项业务全省范围的查询统计要求在60分钟内完成。上述批处理业务包括夜间执行或白天与联机业务并发执行。

3.    查询与数据挖掘(OLAP): 针对各种业务主体建立数据模型并进行分析,支持宏观决策。

4.    数据流转:比如在生产库、交换库和决策库等数据资源之间进行数据抽取、转换、与加载等任务。

5.    数据维护:针对各种数据资源库进行数据加载、备份与恢复,在规定的时间窗内完成,并不影响业务的正常开展。覆盖全省的基础信息库、各个系统的业务经办库、公共服务信息库、各种交换信息库、数据仓库和主题分析库等等。必须提供足够的数据吞吐能力,高效地完成上述任务。

2、在基础架构层面,需要重点解决哪些技术层面问题,又是如何分步骤实施呢?

我们知道项目的需求主要分功能性和非功能性,其中功能性需求定义一个系统或组件的功能,也是一个系统需提供的功能及服务。功能需求会以非功能性需求(或是质量需求)为基础,后者会描述设计或实现时的限制条件(如:RAS、性能、安全、扩展性等等)。基础架构层与非功能性需求关系密切,且作为整个系统的基石,一方面需要满足关键业务类型(如:联机事务处理和批量处理)的性能问题和保证数据的强一致性;另一方面要提供安全、高可靠性的硬件架构,并有能力随着数据集中的逐渐深化而灵活扩展。

基础架构层面要充分考虑系统对批量业务的处理效率,比如有的客户因批量业务太过繁重,而不得不对服务水平进行妥协,给地市分组并按照不同日期/时间段分别进行结算。这种情况相信在省级大集中后会更为突出。

与OLTP有所不同,许多业务需要在固定时间段(月末、季末等)进行批量处理,有的可以在夜间进行,有的必须白天运行。这种类型的负载对I/O能要求大,通常它很难利用多线程去并发处理,因为大多数批处理不得不顺序执行以确保数据完整性。针对这种业务所需计算能力的预估需要特别注意,因为市场上常用的TPC-C值其实并不能对批量处理进行有效评估。基础架构的选择要考虑单CPU线程的处理能力、CPU缓存结构(以及各级缓存大小)、高性能的I/O处理系统、系统带宽等综合技术,来检验服务器处理某个量级的数据所消耗的单位时间。

社保大集中平台很多内容都需要安全和保密,其信息系统将分别在政务内网开展业务,和在政务外网向公众提供必要的服务,因此平台的安全级别要求很高。系统安全性也是该平台搭建过程中的一个重要考量指标。在基础架构设计上除了要考虑内外网设备的物理隔离,也要保证核心服务器本身具有最高的安全性。

最后,社保大集中平台的建设绝不是一蹴而就的,结合人社部信息中心对省级大集中的规划,可分两个步骤实施:1)初步建成省集中格局,基本完成省级基础信息库建设,实现地市基础数据和部分核心业务系统向省中心集中;2)全面实现社保业务系统在省级平台的大集中。分期实施给基础架构层带来新挑战:

1.  稳定的硬件扩展能力来承载从步骤一过渡到步骤二的建设目标,避免计算能力不足导致数据的拆分和应用重构

2.   保持基础架构前后的一致性,避免架构后期的复杂化

4、集中平台的前端、后台服务器应该如何选型?

社保大集中平台前端的展现层和业务接入层等没有数据实时一致性的要求,可以使用分布式的集群部署模式。建议选择性价比高,横向扩展能力强的服务器平台。这个选择的范围很广,如:Intel架构的x86服务器,IBM Power架构的PowerLinux和国产化的OpenPower,结合自身情况选择最适合平台。

后台的数据服务器则至关重要,对于核心的交易数据库系统如:参保人基础信息库/主数据库、业务生产库、一卡通数据库等,建议选择基于IBM大型主机(z Systems)的LinuxONE服务器。LinuxONE兼顾主机50多年传承的硬件高可靠性、安全性和扩展性,并与时俱进引入企业级Linux操作系统和兼容各种开放协议,使得主机的使用更平民化。 其他数据库系统,如决策分析、联网监测、共享交换等,可以选用小型机系统。

结合上述对第2个问题的阐述,LinuxONE服务器作为核心交易数据平台可以满足社保系统的瓶颈业务定期批量处理。LinuxONE具有特别明显的性能优势,这是由大型主机的技术架构特点决定的:强CPU能力(业界最高主频)、多级高Cache设计、强I/O能力和强资源调度能力。同时也可以满足在社保省级大集中不同建设步骤的平滑过渡,例如在阶段一采购部分资源的LinuxONE主机,而然在下一个建设阶段通过微码激活的方式升级所需要的性能,在这个过程中可以始终保持初始的基础架构,不会对原有的应用和数据造成影响。而在安全方面,LinuxONE更是获得高级别(EAL5+)的通用准则 (Common Criteria - CC) 安全认证。

硬件生产 · 2016-01-27
浏览4452

回答者

ibmlinfeng
系统架构师IBM
擅长领域: 服务器存储灾备

ibmlinfeng 最近回答过的问题

回答状态

  • 发布时间:2016-01-27
  • 关注会员:21 人
  • 回答浏览:4452
  • X社区推广