ＩＬＭ技术在银行中的应用:大数据技术与应用就业

　　利用ILM技术中的一些概念，可实现对银行大量信息的管理，满足业务系统的需要。 　　上海建设银行某业务系统采用的是IBM pSeries小型机，配合EMC Clarrion中端存储，使用IBM CMoD / DB2软件，用于进行账表管理。该系统是典型的数据库与文件组合的应用，数据库保存账表数据和CMoD数据索引，文件保存CMoD数据内容，每年有大约200G的数据增量，历史数据需要永久保留。自2002年系统开始上线，累积至今已经达到2T左右的空间，并且在不断增加中。由于数据量巨大，历史数据都采用成本过高的在线保存方式，因此自2005年开始，对3年前的历史数据采用归档处理，用户无法即时查询到历史数据。
　　另一方面，从业务层考虑，该系统的数据要求在任何时候都能被查询到，因此目前采用的方式是当有访问需求时，需要后台管理人员进行手工操作，将归档数据上线，并打开限制开关，前台用户才能访问到历史数据，这种方案显然造成成本过高，而且不灵活。
　　
　　发现问题
　　
　　经过对建行某业务系统的研究，发现业务系统可以很好地应用ILM（信息生命周期管理）技术中的一些概念，实现信息管理，满足业务的要求。该业务系统需要解决的一些问题如下：
　　1.数据量随着时间累积越来越多，需要成本更低的数据保存方案；
　　2.历史数据访问量很低，没有性能要求，但是如果采用完全离线处理，在有访问的时候需要人工操作实现数据在线―离线之间状态转换，工作量较大；
　　3.数据访问时间阶段性比较强，通常历史数据不会被访问，但可能在某个时间段需要连续访问数据；
　　4.数据类型包括数据库和文件两种有代表性的数据，都存在数据历史保存和在线访问的问题。
　　
　　三种技术方案
　　
　　在建行某系统实施ILM技术，我们采用了数据分离、数据访问监控、存储分级和策略化迁移的方案。在具体实现过程中，我们遇到了很多实际实施的问题，例如在进行数据分离的时候，数据库本身没有自动对数据按照时间进行分离；数据库和操作系统也都没有直接的命令收集数据访问频度。策略化迁移则需要自己去设定策略和程序实现，目前尚没有软件能够自动实现建行需要的迁移功能。
　　
　　数据分离技术
　　
　　为了能恰当地进行数据分离，我们引入了DB2 V9的最新功能数据分区表技术，数据分区技术让DB2可以在不同表空间之间按照某些特定规则进行数据存放。此技术在进行表空间数据存放的时候，可以在不同容器之间进行hash，实现最分散化的数据保存，以期达到最佳访问性能。数据分区表技术则是按照特定的规则，将数据按照规则“集中”存放，符合特定规则的数据保存在物理可分离的位置，这样可以配合其他的技术进行数据迁移。
　　数据访问频度收集技术
　　在AIX系统直接提供一些命令用于收集逻辑磁盘（LUN）的访问情况，但并没有显示某个逻辑卷（对应于数据库的表空间）的命令。为收集这些数据，我们引入了AIX的trace功能。在AIX操作系统中提供了许多Hook，在程序每次进行系统调用操作，例如逻辑卷读、写，都会调用特定的操作系统程序，而这些程序提供了Hook接口，可以让外部程序记录该调用的类型和次数。通过trace命令，可以针对特定的系统调用进行收集，从而记录下Hook的数据，再对这些数据进行分析，即可实现对任何需要的系统数据的收集。
　　考虑到trace本身也要消耗一些系统资源，特别是在I/O比较繁忙的时候，因此在实际编程中，并非收集所有的I/O信息，而是间断地收集几秒钟的瞬时信息，然后全天累加，进行统计。数据收集时间也应当可以控制，对于特定的时间，例如备份，将不进行收集，以减少统计误差。由于备份执行时间不固定，因此考虑在备份执行命令脚本中增加控制访问数据收集的开关，备份前关闭开关，备份结束后打开开关。
　　
　　迁移策略和方式
　　
　　建行现有系统采用EMC Clariion作为高端存储，STK SATA磁盘作为低端存储，STK VTL作为虚拟磁带库，SUN C4作为磁带库。这四种存储中，磁盘存储按高、低端保存数据，迁移策略应当尽量确保使用所有划分给系统使用的高端存储，这样可以最大限度利用高端存储资源；迁移策略应当对所管理的逻辑卷表空间进行访问频度排序，用其中访问频度最高的逻辑卷去填充高端存储，直到高端存储空间用尽，剩余的则保存在低端存储；迁移策略应能控制哪些逻辑卷被管理，哪些不被管理；随着迁移的执行，逻辑卷在存储上的分布会越来越凌乱，尽管现有的磁盘都使用RAID技术，操作系统看到的磁盘是逻辑磁盘，并非物理磁盘，但过于零乱的数据也会对管理造成影响，所以自动迁移程序中应当有对应的逻辑卷重整的处理（使用AIX提供的reorgvg命令）。迁移方式采用AIX提供的migratepv命令，可以实现某个特定的逻辑卷从高端组到低端组（或反之）的迁移。
　　几个关键点操作
　　由于本文篇幅所限，无法详细对程序进行全文解释，现只对程序的一些关键点作简单介绍分析。该程序采用KSH编程，由于使用操作系统高级命令明码编程，因此可以更快速地适应系统的新要求，对于程序的bug也能更方便地处理。
　　数据收集
　　根据系统调用Hook分析，我们采用了0x10B这个接口点，该接口点是操作系统对逻辑卷进行的所有操作，包括读、写、打开、关闭，同时每个操作还有起始时间和结束时间。为了简化操作，减少对系统造成的额外压力，我们仅对单位时间内的读、写操作进行跟踪，记录下读写操作的次数，进行统计。
　　收集单位时间逻辑卷裸设备（表空间）访问数据：
　　#!/bin/ksh
　　trace "10B"
　　逻辑卷迁移
　　migratepv -1 lv_name source_pv target_pv1 target_pv2 target_pv3…
　　此命令将lv_name这个逻辑卷从source_pv迁移到target_pv1…3 等pv（操作系统观察到的磁盘，如果采用了EMC的多路径管理软件，则应当是hdiskpowerx的格式）组中。此处要注意migratepv的限制：所有迁移的磁盘都应当在同一个VG（卷组）中。
　　前期规划和注意事项
　　虽然进行数据迁移不是比较危险的操作，但进行大量的数据搬运依然要考虑到很多细节，特别是由程序完成这项工作，要注意其中不能有任何失误，而如果系统处于某些不稳定状态时，也建议不继续迁移动作。这些情况包括：
　　卷组中最多磁盘数的限制：AIX中普通卷组只能支持32个物理磁盘，因此建议使用Big VG（支持128个磁盘）或者Scalable VG（支持1024个磁盘）模式。
　　卷组迁移前应当没有stale的PP：stale PP表示卷组中某些数据块不同步，而迁移需要利用操作系统的数据副本和同步技术完成迁移。如果在迁移前已经有数据不同步，而迁移恰好会使用这块数据，则会导致迁移失败或者数据丢失，因此迁移前要检查不应有stale的PP。
　　Partial Mirrored是另一种中间状态，类似stale PP，通常是由于迁移进行一半的时候，迁移过程被强制中断，造成了部分数据被迁移走，但还有部分数据没有完成迁移。这种状态也会造成今后继续迁移的混乱，需要人工确认后，删除不正常的数据碎片。