大数据中心考核草案

金融大数据中心考核草案为了更好的推进和保证金融大数据中心建设和对外支持工作，特编写金融大数据中心考核草案，草案主要涉及到金融大数据中心数据开发部、应用开发部、数据挖掘部，各部门要明确相关部门主要的目标、策略、责任及考核最终落实到人；草案涉及到两部分，一部分是要求类，另一部分是考核类，要求类是日常设计、开发或运维等工作中需要遵守且对中心内部比较重要的指标或事项，考核类主要是影响业务正常开展的相关指标，系统的不可用、不及时、不准确等对业务部门的工作造成了一定的影响，都属于本中心考核范畴；考核草案详情如下：一、数据开发部1.数据定义有逻辑模型和物理模型，并有建模说明，建模按照建模规范进行，模型标准和规范进行考核。建模规范、考核标准2.数据分类数据按照数据仓库行业标准并结合金融大数据中心实际内容指定标准分类，数据严格按照分类进行划分(例如：数据归类可划分当事人、产品、渠道、合约、机构、事件、活动、账务等)分类标准、考核标准3.元数据管理从以下几点进行考核：1)对数据仓库中的数据(包含来源以及数据仓库中产生的数据)进行描述，相关人员可以查看。2)统一记录好ETL中调度时间、依赖、抽取内容、方式、方法等。3)记录并检测系统数据的一致性，并能记录执行情况。4)记录好ETL数据清洗模型、转换模型、加载模型，相关信息入库。4.数据标准主要针对指标的业务标准、技术标准。业务标准：对指标有明确的统计逻辑。技术标准：表、视图、索引、分区、文件、脚本、字段等符合规范，相同指标需要有统一的定义。业务标准、技术标准(有了，看看是否需要完善)5.数据质量1)根据不同的业务需求和规则验证数据是否被正确地转化。2)确保所有预期的数据加载到数据仓库中没有任何数据丢失和截断。3)确保数据在规定和预计的时间框架内被加载到数据仓库中，以确认改进的性能和可扩展性。4)预期数据被添加到目标系统5)确认所有的数据库字段，字段数据加载没有任何截断6)记录计数匹配的数据校验7)被拒绝的数据的错误日志都有详细记录8)NULL值字段9)重复数据未加载10)数据的完整性缺少数据质量衡量标准。6.稳定性：每天ETL调度的出错率需要在总任务量的10%以内，出错要找出出错原因(例如：没有顺序执行、时间延迟、程序错误等)，并上报给规划管理部进行记录备案，并纳入季度及年度部门及个人考核。7.其它1)脚本编写等需要有良好的数据库移植性，不适用特定数据库的特殊函数(使用sql9.2标准)，便于后期不同的平台、系统、数据的移植。2)安全性：系统的安全性要首先考虑，系统或数据仓库的设计要从网络安全、系统安全、数据安全方面充分考虑，对外数据支持需要走流程，规划管理部要进行审核。3)数据分散与集中相结合：所有数据集中存储，数据仓库根据需要对外系统(中心外或中心内的应用系统)管理分别设置权限，不同的用户维护不同数据。二、应用开发部应用开发部主要涉及到应用程序或接口服务程序的设计、开发、优化、监控、运维等(例如WEB、APP、接口程序等)工作，下面提出针对系统设计、开发或运维时需要考虑的部分指标，指标有待大家进行扩充和完善。1.事务（Transaction）在web中一个事务表示一个“从用户发送请求-webserver接受到请求，进行处理-webserver向DB获取数据-生成用户的object(页面)，返回给用户”的过程，一般的响应时间都是针对事务而言的。支持事物个数：？2.请求响应时间请求响应时间指的是从客户端发起的一个请求开始，到客户端接收到从服务器端返回的响应结束，这个过程所耗费的时间，在某些工具中，响应通常会称为“TTLB”，即timetolastbyte，意思是从发起一个请求开始，到客户端接收到最后一个字节的响应所耗费的时间，响应时间的单位一般为“秒”或者“毫秒”。公式为：响应时间＝网络响应时间+应用程序响应时间。标准可参考国外的3/5/10原则：（1）在3秒钟之内，页面给予用户响应并有所显示，可认为是“很不错的”；（2）在3~5秒钟内，页面给予用户响应并有所显示，可认为是“好的”；（3）在5~10秒钟内，页面给予用户响应并有所显示，可认为是“勉强接受的”；（4）超过10秒就让人有点不耐烦了，用户很可能不会继续等待下去；3.事务响应时间事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念，是为了向用户说明业务响应时间而提出的。各系统事物响应时间？4.并发用户数并发一般分为2种情况。一种是严格意义上的并发，即所有的用户在同一时刻做同一件事情或者操作，这种操作一般指做同一类型的业务；还有一种特例，即所有用户进行完全一样操作。各系统的并发用户数？5.吞吐量指的是在一次性能测试过程中网络上传输的数据量的总和.吞吐量/传输时间,就是吞吐率.6.TPS（transactionpersecond）每秒钟系统能够处理的交易或者事务的数量.它是衡量系统处理能力的重要指标.7.宕机率主要系统全年宕机时间=?8.点击率每秒钟用户向WEB服务器提交的HTTP请求数.这个指标是WEB应用特有的一个指标:WEB应用是请求-响应模式,用户发出一次申请,服务器就要处理一次,所以点击是WEB应用能够处理的交易的最小单位.如果把每次点击定义为一个交易,点击率和TPS就是一个概念.容易看出,点击率越大,对服务器的压力越大.9.资源利用率1)通用指标（指Web应用服务器、数据库服务器必需测试项)指标说明ProcessorTime服务器CPU占用率，一般平均达到70%时，服务就接近饱和MemoryAvailableMbyte可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重PhysicsdiskTime物理磁盘读写时间情况2)Web服务器指标指标说明RequestsPerSecond（AvgRps）平均每秒钟响应次数＝总请求时间/秒数Avgtimetolastbyteperterstion（mstes）平均每秒业务脚本的迭代次数,有人会把上面那个混淆SuccessfulRounds成功的请求FailedRequests失败的请求SuccessfulHits成功的点击次数FailedHits失败的点击次数HitsPerSecond每秒点击次数SuccessfulHitsPerSecond每秒成功的点击次数FailedHitsPerSecond每秒失败的点击次数AttemptedConnections尝试链接数3)数据库服务器性能指标指标说明User0Connections用户连接数，也就是数据库的连接数量Numberofdeadlocks数据库死锁ButterCachehit数据库Cache的命中情况4)系统的瓶颈定义性能项命令指标CPU限制vmstat当%user+%sys超过80%时磁盘I/O限制Vmstat当%iowait超过40%(AIX4.3.3或更高版本)时应用磁盘限制Iostat当%tm_act超过70%时虚存空间少Lsps，-a当分页空间的活动率超过70%时换页限制Iostat,stat虚存逻辑卷%tm_act超过I/O(iostat)的30%，激活的虚存率超过CPU数量(vmstat)的10倍时系统失效Vmstat,sar页交换增大、CPU等待并运行队列5)稳定系统的资源状态性能项资源评价CPU占用率70%好85%坏90%+很差磁盘I/030%好40%坏50%+很差网络30%带宽好运行队列2*CPU数量好内存没有页交换好每个CPU每秒10个页交换坏更多的页交换很差三、数据挖掘部（待编写）