上次做了一个系统碰到的问题

027xiatian

从原始的apache日志分析，到入库，到各种维度的报表统计，前端日志分析阶段采用的是shell,perl,后端采用的是infobright,整个统计系统分成多层（分层目的也是为了高度复用，避免写入与业务有关的代码),
所以整个过程比较长，为了捕获每一个阶段可能出现的异常，在每一层都会向状态表插入该层处理是否成功的标示，来达到后期自动修补的目的。
目前统计系统出发点也就利用ib的高压缩比，SQL查询的高效,  带来的好处也不用说（存储的压力较小，统计报表的时效性优越），在这个基础之上的数据开发的效率也比较快，只需要填写相应的配置项，SQL语句就可以将报表统计完成，将开发人员的精力集中在业务层面，做业务层面的开发，抽出时间，精力做业务。
弊端也相当明显:
   1.ICE对复杂SQL的准确性有些bug，基本在目前的统计中，没有采用很复杂的SQL(同过系统分层来解决这个问题)
    2.数据容灾上，采取冗余备份的策略（虽然耗费磁盘，目前也没有好的方法来处理 了)
    3.现在由于表的规模已经达到几亿级别（infobright)，做表的导入导出碰到一些问题，ICE不支持DML, 虽然写脚本来完成类似的insert,delete,alter的通用功能模块，但随着表规模的扩大，那么这种操作的时间开销是越来越大！！目前有没有其他的更好的方案呢？(目前正在找解决方法)

027xiatian

结贴，已经通过其他的策略搞定!