基于Hadoop平台的稽核规则概要.doc

《基于Hadoop平台的稽核规则概要.doc》由会员分享，可在线阅读，更多相关《基于Hadoop平台的稽核规则概要.doc（14页珍藏版）》请在三一文库上搜索。

1、基于Hadoop平台的稽核规则测试报告- GRIS平台开发部 谌章义1. 测试过程测试不仅要验证Hadoop平台运行稽核规则的性能，还要验证集群规模与数据量之间的关系，所以每项测试都分为3个，5个，和7个计算节点进行。测试内容如下：1）完全遵循现有稽核规则，将24，37号规则中涉及的视图导入Hive，作为物理表，再分别运行在Hadoop上运行24和37号规则；2）根据Hadoop和Hive特点进行优化：对Hive中的物理表进行排序、分区等预处理，并且在Join操作中，对小表全部载入内存，以提高稽核规则运行性能；3）为了验证Hadoop在大数据处理方面的性能，将现有数据规模扩大10倍，验证Had

2、oop平台运行稽核规则的性能。4）多任务运行时的性能测试和对比测试数据（选取一个省公司实际数据）：1）24号规则检查年底是否存在未实际发生的大额成本挂账情况（具体实现见附录1），涉及的大数据表有两个：aud_newzwpz_2012 记录数：5 110 396，大小：786MBAud_newzwpz_2013 记录数：474 379，大小：72MB.2）37号规则检查应列入未列入工资的情况（具体实现见附录2），涉及的大数据表有两个：Aud_zwpz_2012 记录数：5 110 396，大小：1245MBAud_WL_DWKMHZ_2012 记录数：3 148 560，大小：446MB2. 测

3、试结果2.1 完全遵循现有表结构，在Hadoop上执行稽核规则1）37号规则测试选取了三类测试：0600仅稽核0600这一个单位060X稽核编号以060打头的单位06X稽核该省公司所有单位测试结果如下：37规则3节点5节点7节点Oracle0600207.70 200.99 190.13 161.00 060X234.11 212.25 199.96 208.00 06X302.79 259.90 210.04 119.00 为了对比测试结果，我们以处理的数据量为横轴，对比Hadoop集群（3，5，7节点）和Oracle的执行时间。下图是不同测试环境下，随着稽核单位增多，稽核时间的变化情况：图

4、1. 37号规则执行时间图从图1中可以看到：1） 稽核单个单位，Hadoop性能不如Oracle；2） 但是随着稽核单位的增多，Hadoop的性能开始超过Oracle；3） 稽核单位增加，Hadoop执行时间变化比较平缓，而且节点越多，越平缓（7节点时间变化最小）注：Oracle测试结果在稽核单位增加，数据量增大的情况下，执行时间反而出现逆增长，原因还不是太清楚（Oracle数据又BA同事提供）。2）24号规则测试同样选取三类测试：0600仅稽核0600这一个单位 060X稽核编号以060打头的单位 06X稽核该省公司所有单位测试结果如下：24规则3节点5节点7节点Oracle0600229.

5、10 219.03 224.93 72.00 060X237.47 224.91 229.82 360.00 06X257.34 250.56 242.31 1451.00 同样采用数据量为横轴，对比不同规模Hadoop集群与Oracle执行时间的对比。下图是不同测试环境下，随着稽核单位增多，稽核时间的变化情况：图2. 24号规则执行时间图从图2中可以看到：1） 随着稽核单位增多，Oracle执行时间变化非常明显；原因：24号规则相对于37号规则要复杂（嵌套的层次多），而且涉及两个大表（一个500万记录，一个300万记录）的频繁Join，所以增加稽核单位后，Oracle端的时间变化非常明显。2

6、） Hadoop的执行时间变化还是非常的平稳；3） 虽然稽核的单位增多，数据量增大，但是Hadoop集群规模对于性能影响很小，基本处于同一水平。原因：1）Hive将稽核规则编译生成一系列的Job，每个Job由不同的Map和Reduce组成，如24号规则会生成8个Job：Job 0: Map: 6 Reduce: 7 Cumulative CPU: 86.68 sec HDFS Read: 1247826241 HDFS Write: 7453813 SUCCESSJob 1: Map: 2 Reduce: 1 Cumulative CPU: 21.27 sec HDFS Read: 74568

7、82 HDFS Write: 7452869 SUCCESSJob 2: Map: 6 Reduce: 7 Cumulative CPU: 119.7 sec HDFS Read: 1255279515 HDFS Write: 27583162 SUCCESSJob 3: Map: 1 Reduce: 1 Cumulative CPU: 16.47 sec HDFS Read: 27586086 HDFS Write: 226282 SUCCESSJob 4: Map: 1 Reduce: 1 Cumulative CPU: 6.06 sec HDFS Read: 226824 HDFS Wr

8、ite: 226282 SUCCESSJob 5: Map: 3 Reduce: 3 Cumulative CPU: 33.05 sec HDFS Read: 447504020 HDFS Write: 72257 SUCCESSJob 6: Map: 1 Reduce: 1 Cumulative CPU: 5.2 sec HDFS Read: 73593 HDFS Write: 71759 SUCCESSJob 7: Map: 1 Reduce: 1 Cumulative CPU: 5.11 sec HDFS Read: 72301 HDFS Write: 71759 SUCCESSJob

9、8: Map: 6 Reduce: 7 Cumulative CPU: 237.51 sec HDFS Read: 1247898405 HDFS Write: 231223 SUCCESS有些Job是处理大表（如Job0，Job2和Job8），可以同时启动多个Map，体现多节点优势；但是更多的Job是处理小表或者中间结果，数据规模只需要启动一两个Map和一个Redcue，占用的CPU时间少，但是Hadoop运行时间并不少。所以，零散的Job越多，多节点的优势就越不明显。如果达到一定的数据规模，多节点的优势就能得到体现，为此，在测试中我将数据规模扩大10倍，这时候多节点的增速效果就比较明显。在

10、6.3节将会详细介绍。注：参考Hive的编译生成规则，对稽核规则进行修改，尽可能将零散规则合并，将极大提升系统性能，这部分工作在本次测试中没有开展。2.2 根据稽核原理，对大表的结构进行调整，并相应修改稽核指令稽核规则都是在一定时间范围内，按单位查找；但是稽核相关的大表是将所有单位的数据混合在一起。因为Hive是用全表扫描的方式执行，而且提供的索引功能非常弱，所以我们考虑用Hive提供的分区（Partition）功能，按时间和单位将数据组织在一起。这样稽核的时候，根据指定的时间和单位ID，就可以快速锁定需要的数据，而不用全表扫描，做无用功，从而提高执行性能。考虑的分区方式主要有以下两种：图3.

11、 分区方法如果数据量大，还可以在单位下面再分为“借”和“贷”两个分支。本次测试中，因为数据规模并不大，分区划得太细，数据过于零散，反而不利于Hadoop执行（Hadoop擅长于处理大数据，而不是大量零散的小数据）。所以，我们选择了图3中的单位时间分区。并且只用了一级分区，而且根据Compid前三位划分成20个分区（有170多个单位，按单位分区数据太零散）。1）37号规则测试测试结果如下：37规则PartitionNo_PartitionOracle0600192.643190.13 161.00 060X205.293199.96 208.00 06X585.937210.04 119.00

12、同样以数据量为横轴，对比7节点Hadoop集群在分区、不分区下执行时间和Oracle执行时间的对比，如图4所示：图4. 37号规则分区执行时间从图4可以看到：1） 稽核一个单位和多个单位时，进行分区性能有所提高，但是不明显。原因：数据量太小，无法体现分区的优势。2） 稽核所有单位时，分区性能反而下降。原因：稽核所有单位就是全表遍历，而分区的目的就是为了避免全表遍历，因为有了分区后只会扫描制定的分区，而不是全表扫描。如果做全表扫描，分区会导致数据分散，全表处理时性能不如不分区的表。3） 稽核一个单位，Oracle性能高；稽核多个单位，Hadoop性能略快；稽核所有单位，Oracle性能逆增长。2

13、）24号规则测试该规则测试结果如下：24规则PartitionNo_PartitionOracle0600176.06 224.93 72.00 060X184.78 229.82 360.00 06X300.37 242.31 1451.00 同样以数据量为横轴，对比7节点Hadoop集群在分区、不分区下执行时间和Oracle执行时间的对比，如图4所示：图5. 24号规则分区执行时间从图5可以看到：1） 在稽核部分单位时，分区的性能要高于不分区的情况；2） 稽核单位较多时，Oracle性能急剧下降，执行时间要远大于Hadoop时间；说明Oracle在做大数据分析时性能不佳；3） 稽核所有单位

14、时，分区性能下降，原因同上。2.3 数据规模扩大10倍，验证分区及Hadoop集群加速性能由于数据量太少，每个Job都只有一两个Map，根本不能发挥Hadoop的集群优势。所以，我们进行了第三类测试：将数据规模扩大10倍，测试分区的效果，以及Hadoop集群规模和性能的关系。为了测试分区在大数据下的性能提升情况，以及Hadoop集群规模与稽核性能间的关系，我们将数据规模扩大10倍（将原始数据导入10次），并选取24号规则，稽核COMPID由060开头的单位（060X）。测试数据：Aud_zwpz_2012 记录数：51 103 960，大小：12.5 GBAud_WL_DWKMHZ_2012

15、记录数：31 485 600，大小：4.5 GB测试结果：24_060X3节点5节点7节点10X Partition268.721260.34266.14410X No_Partition839.661530.494470.642原数据规模237.47 224.91 229.82 为了对比集群规模对性能的影响，我们以集群规模作为横轴，对比10倍数据规模下，分区、不分区以及在原数据规模下Hadoop的执行时间对比，如图6所示：图6. 24号规则10倍数据测试结果图从图6可以看到：1） 不采用分区，需要处理的数据规模庞大，因此集群的规模对于性能具有很大影响（橙色折线所示）；2）10倍数据规模下，采

16、用分区可以有效提升系统性能。尽管数据规模扩大10倍，执行时间与元数据规模Hadoop执行时间相差无几。3）采用分区后，实际处理数据规模不大，因此集群规模对于性能影响有限，执行时间变化平缓；4）如果不采用分区策略，数据扩大10倍，其执行时间也只有原数据规模下Hadoop执行时间的2-3倍。在7节点情况下，执行时间不到原规模的2倍！如果在Oracle数据库中，按图2所示的发展趋势，数据增加10倍，其执行时间将远远超过10倍。这也充分证明Hadoop处理大数据的优势所在。通过该测试基本可以得出以下结论：1） 每次处理的数据规模在百万条记录，1GB左右数据量，5个左右计算节点基本可以满足要求；如果集群

17、规模大，可以同时运行多个稽核任务，以充分利用资源；2） 数据规模达到千万，10GB以上，如果不能分区，需要10个以上计算节点，采用分区5个即可满足要求；3） 对于更大规模数据，如果能有效分区，10个左右计算节点可以满足要求；否则需要更大集群规模。参考本次测试的数据，如果在10亿条以上数据规模（如国网集中部署的情况下），可以根据时间、省公司、单位等采用多级分区方法，按省公司进行稽核，10个计算节点集群基本可以满足要求。2.4 多任务并行执行测试为了验证多任务并行执行情况，分别在Oracle采用多线程、Hadoop采用多任务的方式进行了测试，结果如下：Oracle5线程7节点5任务37规则060X

18、610.00 460.00 06X285.00 510.00 24规则060X650.00 450.00 06X4566.00 480.00 从结果可以看到：对于37号规则，Hadoop优势不明显，但是对于24号规则，在全表数据处理的情况下，系统性能稳定（在6.3的10倍数据规模情况下，也证明Hadoop在处理大数据时性能很稳定），而Oracle则出现较大性能波动。注：Hadoop的多任务还是比较粗糙，手工进行节点划分，如果应用Cascading进行Job管理，并采用动态资源配置策略，性能会有较大提升。Hadoop1多任务功能不是太强，在最新发布的Hadoop2中得到了很大的改进和增强，这部分

19、的内容我们也在跟进和学习中。3. 总结和讨论3.1 Hadoop在稽核中的应用通过这测试可以看到，将对于Oracle，Hadoop在处理大数据量稽核方面总体性能要优于Oracle，尤其是数据规模10倍增加的情况下，性能相对比较稳定。如果稽核的数据规模在百万条记录级别，建议采用Oracle处理，配合检索及临时表等措施，性能完全可以满足需求；这种情况下Hadoop也可以作为初步处理工具，将稽核结果导入Oracle，然后根据单位进行数据分类即可；如果稽核的数据规模在千万到亿条记录级别，强烈建议采用Hadoop作为处理平台，可以采用两种形式：1） Hadoop仅仅作为初步处理工具，结果记录反馈到Ora

20、cle，便于进一步处理。这种情况的好处可以最大限度保持现有业务逻辑和实现流程、代码等；缺点是性能有限，且需要频繁的数据交互。2）基于Hadoop建立稽核专有数据库，可以针对稽核规则对表结构、甚至表的组织进行修改，然后再次基础上进行稽核业务。优点：性能高，而且不需要频繁的数据交互；缺点：现有的稽核指令要根据Hive进行调整，同时集群的维护和调优也是艰巨的工作。但是这个调整不会太大。在整个测试中我们可以看到，以Hadoop作为平台、Hive作为数据仓库，其实现流程和Oracle并无太大差异：都是通过JDBC连接，用SQL代码执行稽核规则。所以完全基于Hadoop来构建稽核平台，对于上层的应用基本是

21、透明的。3.2 Hadoop作为ECP的公用模块关于Hadoop，我们的目标是将其作为ECP平台的一个公用模块，任何有大数据处理需要的业务都可以将数据导入Hadoop平台，处理完成后导出结果数据。在现阶段，我们主要提供原始的API，通过JDBC等方式来连接使用；在后期，我们将对API进行封装，并提供图形化的界面用于数据源的配置、处理SQL的设置等图形化界面，并且在后台提供任务调度和管理模块，根据系统资源、任务等级等合理调配资源。3.3 Hadoop的高可靠性在本次测试中，Hadoop在高可靠性方面的表现让我感到非常吃惊。对于不同规模Hadoop集群测试，采取的办法非常简单：先是7个节点，进行测

22、试；然后停掉其中2个节点，进行测试；最后再停掉2个节点，进行测试。一共有7个数据节点，备份数设置的是3份。按常理推测，当只剩下3个节点时（一半以上节点都死掉）时，肯定会出现数据丢失。对于能否取得正确结果心里还是没有太大把握。不过结果证明这种担心是多余的，3节点集群的计算结果依然是完全正确。为什么一半以上节点都死掉，Hadoop集群还能正常工作 ，可靠性有这么高么？仔细分析发现：Hadoop有自动调节功能，先停掉2个节点时，Hadoop发现有2个节点死掉，会对现有节点进行调节，保证所有数据块依然保持3个备份。所以再停掉2个节点时，每个数据块依然能保留至少1个备份。这也是集群规模是3时依然能正常运

23、行的原因。从这个测试可以看到，在Hadoop集群的环境下，数据的可靠性能够得到极大的保证。3.4 Hadoop处理的数据规模在3.1对Hadoop处理的数据规模进行了一些讨论，在此还想多说两句。Hadoop擅长处理大数据，对于Hadoop来说处理GB级别（几百万条记录）的数据，时间上面并不占优势。因为处理一个Job（由一堆的Map和Reduce组成）需要花费一定的准备时间，处理的数据规模越小，准备时间占的比重越大，性能就越差；反之，处理数据量大，准备时间的比重越小，性能就越优异。就像马和汽车比赛，在几十米的距离，是无法体现汽车的优势一样。但这并不表明Hadoop不能用于GB级别数据处理（毕竟我

24、们大多数业务的数据规模还在GB这一规模）。虽然一次处理1GB的数据性能没优势，完全可以同时运行多个GB级的任务，或者将多个GB级数据组合在一起，一次处理。正如这次测试中看到的：一次稽核一个单位，Hadoop处理性能甚至还不如Oracle，但是一次稽核多个单位或者一个省公司所有单位，Hadoop的性能优势立刻就得到体现。而且将数据规模再扩大10倍（类似于一次稽核10个省公司），Hadoop依然能有非常好的性能表现。所以Hadoop的应用场景还是有很大的弹性，关键是要能发挥它的长处，性能才能得到体现。附录1：24号规则存储过程功 能: 财务稽核检查年底是否存在未实际发生的大额成本挂账情况说 明：检

25、查年底是否存在未实际发生的大额成本挂账情况 -关闭VPD策略 VPD_PKG.SET_CONTEXT_COMPID(-1); VPD_PKG.SET_CONTEXT_VPD_YEAR(-1); -拼接查询语句 V_SQL :=WITH JFPZ AS ( SELECT BILLID FROM VIEW_AUD_ZWPZ_| V_YEAR | A WHERE A.COMPID =| V_COMPID | AND A.BZJD=借 AND INSTR(A.CODE,5001) 0 AND A.TTIME BETWEEN TO_DATE( | I_STIME | ,YYYY-MM-DD) AND T

26、O_DATE( | I_ETIME | ,YYYY-MM-DD) GROUP BY BILLID), DFPZ AS ( SELECT A.BILLID,A.CODE,A.CAPTION FROM VIEW_AUD_ZWPZ_| V_YEAR | A,JFPZ B,ZWITEMSYW C WHERE C.IID = A.KMID AND B.BILLID = A.BILLID AND A.BZJD=贷 AND (INSTR(A.CODE,2241) = 1 AND (INSTR(A.CODE,99) 0 OR INSTR(A.CODE,98) 0 OR INSTR(C.CAP2,其他) 0 O

27、R INSTR(C.CAP2,综合) 0) OR (INSTR(A.CODE,1122) = 1 AND (INSTR(A.CODE,99) 0 OR INSTR(A.CODE,98) 0 OR INSTR(C.CAP2,其他) 0 OR INSTR(C.CAP2,综合) 0) OR (INSTR(A.CODE,1123) = 1 AND (INSTR(A.CODE,99) 0 OR INSTR(A.CODE,98) 0 OR INSTR(C.CAP2,其他) 0 OR INSTR(C.CAP2,综合) 0) OR (INSTR(A.CODE,1221) = 1 AND (INSTR(A.CO

28、DE,99) 0 OR INSTR(A.CODE,98) 0 OR INSTR(C.CAP2,其他) 0 OR INSTR(C.CAP2,综合) 0) OR (INSTR(A.CODE,2202) = 1 AND (INSTR(A.CODE,99) 0 OR INSTR(A.CODE,98) 0 OR INSTR(C.CAP2,其他) 0 OR INSTR(C.CAP2,综合) 0) OR (INSTR(A.CODE,2203) = 1 AND (INSTR(A.CODE,99) 0 OR INSTR(A.CODE,98) 0 OR INSTR(C.CAP2,其他) 0 OR INSTR(C.

29、CAP2,综合) 0) GROUP BY A.BILLID,A.CODE,A.CAPTION), WL AS ( SELECT B.BILLID FROM VIEW_AUD_WL_DWKMHZ_| V_YEAR | A,DFPZ B WHERE A.AMONTH = TO_NUMBER(TO_CHAR(TO_DATE( | I_ETIME | ,YYYY-MM-DD),MM) AND A.DH =| V_COMPID | AND B.CODE = A.CODE AND B.CAPTION = A.CAPTION AND A.QM_YE 0 GROUP BY B.BILLID)SELECT CO

30、UNT(1) FROM (SELECT A.BILLID,A.COMPID,A.COMPNAME,A.CODE2,A.SUMMARY,A.TTIME,A.ZJE,A.CODE,A.CAPTION,A.BZJD,A.TMONEYF,A.DXMC,A.GLDXID FROM VIEW_AUD_ZWPZ_| V_YEAR | A,WL B WHERE A.BILLID=B.BILLID); -RC_LOGMSG(稽核24-1记录数据sql:|V_SQL); -获取记录数 /* EXECUTE IMMEDIATE V_SQL INTO V_SUM;*/ -返回结果 - O_RATE := 1; V_S

31、QL := WITH JFPZ AS ( SELECT BILLID FROM VIEW_AUD_ZWPZ_| V_YEAR | A WHERE A.COMPID =| V_COMPID | AND A.BZJD=借 AND INSTR(A.CODE,5001) 0 AND A.TTIME BETWEEN TO_DATE( | I_STIME | ,YYYY-MM-DD) AND TO_DATE( | I_ETIME | ,YYYY-MM-DD) GROUP BY BILLID), DFPZ AS ( SELECT A.BILLID,A.CODE,A.CAPTION FROM VIEW_AUD

32、_ZWPZ_| V_YEAR | A,JFPZ B,ZWITEMSYW C WHERE C.IID = A.KMID AND B.BILLID = A.BILLID AND A.BZJD=贷 AND (INSTR(A.CODE,2241) = 1 AND (INSTR(A.CODE,99) 0 OR INSTR(A.CODE,98) 0 OR INSTR(C.CAP2,其他) 0 OR INSTR(C.CAP2,综合) 0) OR (INSTR(A.CODE,1122) = 1 AND (INSTR(A.CODE,99) 0 OR INSTR(A.CODE,98) 0 OR INSTR(C.C

33、AP2,其他) 0 OR INSTR(C.CAP2,综合) 0) OR (INSTR(A.CODE,1123) = 1 AND (INSTR(A.CODE,99) 0 OR INSTR(A.CODE,98) 0 OR INSTR(C.CAP2,其他) 0 OR INSTR(C.CAP2,综合) 0) OR (INSTR(A.CODE,1221) = 1 AND (INSTR(A.CODE,99) 0 OR INSTR(A.CODE,98) 0 OR INSTR(C.CAP2,其他) 0 OR INSTR(C.CAP2,综合) 0) OR (INSTR(A.CODE,2202) = 1 AND

34、(INSTR(A.CODE,99) 0 OR INSTR(A.CODE,98) 0 OR INSTR(C.CAP2,其他) 0 OR INSTR(C.CAP2,综合) 0) OR (INSTR(A.CODE,2203) = 1 AND (INSTR(A.CODE,99) 0 OR INSTR(A.CODE,98) 0 OR INSTR(C.CAP2,其他) 0 OR INSTR(C.CAP2,综合) 0) GROUP BY A.BILLID,A.CODE,A.CAPTION), WL AS ( SELECT B.BILLID FROM VIEW_AUD_WL_DWKMHZ_| V_YEAR |

35、 A,DFPZ B WHERE A.AMONTH = TO_NUMBER(TO_CHAR(TO_DATE( | I_ETIME | ,YYYY-MM-DD),MM) AND A.DH =| V_COMPID | AND B.CODE = A.CODE AND B.CAPTION = A.CAPTION AND A.QM_YE 0 GROUP BY B.BILLID) SELECT A.BILLID,A.COMPID,A.COMPNAME,A.CODE2,A.SUMMARY,A.TTIME,A.ZJE,A.CODE,A.CAPTION,A.BZJD,A.TMONEYF,A.DXMC,A.GLDX

36、ID FROM VIEW_AUD_ZWPZ_| V_YEAR | A,WL B WHERE A.BILLID=B.BILLID; RC_LOGMSG(稽核24-1结果记录明细sql:|V_SQL); OPEN P_CURSOR FOR V_SQL;END;附录2：37号规则实现SQL功能：检查应列入未列入工资的情况SELECT * FROM (SELECT W1.CODE2 AS XPZST_CODE2, W1.SUMMARY AS XPZST_SUMMARY, W1.TTIME AS XPZST_TTIME, W1.ZJE AS XPZST_ZJE, W1.FDZS AS XPZST_FDZ

37、S, W1.KMID AS XPZST_KMID, W2.CAPTION AS KJKM_0_CAPTION, W2.CODE AS KJKM_0_CODE, W1.MXSUMMARY AS XPZST_M, W1.BZJD AS XPZST_BZJD, W1.TMONEYF AS XPZST_TMONEYF, W1.COMPID AS XPZST_BZJCZZd, W3.COMPNAME AS BZJCZZ_COMPNAME From (SELECT A.*, 2012 YEAR_SOB FROM VIEW_AUD_NEWZWPZ_2012 A UNION ALL SELECT A.*, 2

38、013 YEAR_SOB FROM VIEW_AUD_NEWZWPZ_2013 A) W1 INNER JOIN ZWITEMSYW W2 ON W1.KMID = W2.IID INNER JOIN (SELECT W5.WLPZ_XPZSD AS GZDPZID_WLD, W9.XPZST_BILLID AS XJCB_XPZSD, COUNT(1) AS JS From (SELECT W1.BILLID AS XPZST_BILLID, COUNT(1) AS JS From (SELECT A.*, 2012 YEAR_SOB FROM VIEW_AUD_NEWZWPZ_2012 A UNION ALL SELECT A.*, 2013 YEAR_SOB FROM VIEW_AUD_NEWZWPZ_2013 A) W1 INNER JOIN ZWITEMSYW W2 ON W1.KMID = W2.IID WHERE (W1.BZJD = 借 OR (W1.BZJD IS NULL AND 借 IS NULL) AND (W2.CODE LIKE | 5001 | %) AND (W1.TTIME = TO_DATE(2013-01-01, YYYY-MM-DD) AND (W1.TTIME = W2.