brighthouse小结

1、面向即时查询的分析级开源数据仓库（An Analytic Data Warehouse for Ad-hoc Queries）

     （1）列存储、自动调谐（column-oriented data warehouse with automatically tuned）

             a1、高压缩比，特别在内容的分析、决策支持查询（in the context of analytic，decision support querying）

             a2、列存储适合分析级数据仓库，对列的小集合的选择访问，强调对数据的压缩（suitable for analytic data warehousing，with selective access to small subsets of columns and emphasis on data compression）

             a3、行存储是OLTP系统的更好选择（a better choice for OLTP system）

             a4、更好的策略：混合列存储和行存储的优点（suggesting mixed horizontal/vertical decomposition）

     （2）知识网格（Konwledge Grid-ultra small overhead metadata），极度小的头元数据-取代了传统索引（an alternative to classical indexes）

              b1、查询的优化和执行，减少对数据的读和解压缩的需求（query optimization and execution，by minizing the need of data reads and data decompression）

              b2、自动创建和高层次的数据的数据的使用（an idea of automatic creation and usage of higher-level data about data）

              b3、知识网格的元素是知识结点（Knowledge Nodes），用来描述单个数据或行的相对大的部分（describle relatively large （conbinations of）portions of single data items or rows），即数据块（Data Packs），而不再是单个数据或行

              b4、知识结点比标准的索引更小，以至能够更快的基于内存处理，更体现在较多类型的存储能力上（far smaller than standard indexes，which results in their faster，in-memory processing，as well as in the ability of storing more of their types），适合即时的带不可预测方法的查询的处理的增长需求（fits well with a growing need of dealing with ad-hoc，unpredictable ways of querying），帮助减少物理模型重新调整（helps to eliminate physical model retuning）

      （3）数据块（Data Packs）

       

     （4）Optimizer：获取数据请求；在KG里迭代执行SQL计划；规避掉不需要的DP；仅解压缩不确定的DP；

2、infobright-基于brighthouse引擎的开源数据仓库实现

         Infobright采用了和 MySQL一致的构架，分为两层。上层是服务及应用管理，下层是存储引擎。 Infobright的默认存储引擎是 brighthouse，但是 Infobright还可以支持其他的存储引擎，比如 MyISAM、 MRG_MyISAM、 Memory、 CSV。

       Infobright通过三层来组织数据，分别是 DP(Data Pack)、 DPN（ Data Pack Node）、 KN（ Knowledge Node）。而在这三层之上就是无比强大的知识网络（ Knowledge Grid）。

         

        数据块（DP）是存储的最低层，列中每64K个单元组成一个DP。DP比列更小，具有更好的压缩比率；又比单个数据单元更大，具有更好的查询性能。

　　数据块节点（DPN），DPN和DP之间是一对一的关系。DPN记录着每一个DP里面存储和压缩的一些统计数据，包括最大值、最小值、null的个数、单元总数count、sum等等。

　　KN里面存储着指向DP之间或者列之间关系的一些元数据集合，比如值发生的范围（MIn_Max）、列数据之间的关联。大部分的KN数据是装载数据的时候产生的，另外一些事是查询的时候产生。

　　在这三层之上是知识网络（Knowledge Grid），Knowledge Grid构架是Infobright高性能的重要原因。

 

        Knowledge Grid可分为四部分，DPN、Histogram、CMAP、P-2-P。

      Histogram用来提高数字类型（比如date，time，decimal）的查询的性能。

      DPN中有mix、max，Histogram中把Min-Max分成1024段，如果Mix_Max范围小于1024的话，每一段就是就是一个单独的值。这个时候KN就是一个数值是否在当前段的二进制表示。

       Histogram的作用就是快速判断当前DP是否满足查询条件。比如select id from customerInfo where id>50 and id<70。那么很容易就可以得到当前DP不满足条件。所以Histogram对于那种数字限定的查询能够很有效地减少查询DP的数量。

      CMAP是针对于文本类型的查询，CMAP是统计当前DP内，ASCII在1-64位置出现的情况。

   

        比如上面的图说明了A在文本的第二个、第三个、第四个位置从来没有出现过。0表示没有出现，1表示出现过。查询中文本的比较归根究底还是按照字节进行比较，所以根据CMAP能够很好地提高文本查询的性能。

      Pack-To-Pack是Join操作的时候产生的，它是表示join的两个DP中操作的两个列之间关系的位图，也就是二进制表示的矩阵。

3、Infobright高压缩比分析

       Infobright 号称数据压缩比率是 10:1 到 40:1 ， Infobright 压缩是根据 DP 里面的数据类型，系统自动选择压缩算法，并且自适应地调节算法的参数以达到最优的压缩比。

     通常情况下  KN 数据大小占数据总大小的  1% 左右；

4、Infobright工作原理

        Rough Sets 是 Infobright 的核心技术之一， Infobright 在执行查询的时候会根据 Knowledge Grid 把 DP 分成三类： Relevant Packs、I rrelevant Packs、 Suspect Packs ；

     

    每一列总共有 5 个 DP ，其中限制条件是 A>6 。所以 A1 、 A2 、 A4 就是 I rrelevant Packs ， A3 是 Relevant Packs ， A5 是 Suspect Packs 。那么执行查询的时候只需要计算 B5 中满足条件的记录的和然后加上 Sum （ B3 ）， Sum （ B3 ）是已知的。此时只需要解压缩 B5 这个 DP 。从上面的分析可以知道， Infobright 能够很高效地执行一些查询，而且执行的时候 where 语句的区分度越高越好。 where 区分度高可以更精确地确认是否是 Relevant Packs 或者是 I rrelevant Packs 亦或是 Suspect Packs ，尽可能减少 DP 的数量、减少解压缩带来的性能损耗。在做条件判断的使用，一般会用到 Histogram 和 CMAP ，它们能够有效地提高查询性能。

    多表连接的的时候原理也是相似的。先是利用  Pack-To-Pack 产生 join  的那两列的 DP 之间的关系。

　　比如： SELECT MAX(X.D) FROM T JOIN X ON T.B = X.C WHERE T.A > 6 。 Pack-To-Pack 产生 T.B 和 X.C 的 DP 之间的关系矩阵 M 。假设 T.B 的第一个 DP 和 X.C 的第一个 DP 之间有元素交叉，那么 M[1,1]=1 ，否则 M[1,1]=0 。这样就有效地减少了 join 操作时 DP 的数量。

    

     每个 DP 中的 64K 个元素被当成是一个序列，其中所有的 null 的位置都会被单独存储，然后其余的 non-null 的数据会被压缩。数据的压缩跟数据的类型有关， infobright 会根据数据的类型选择压缩算法。 infobright 会自适应地调节算法的参数以达到最优的压缩比；

5、Infobright查询优化

    

      （ 1） 配置环境: 根据 README 里的要求，配置 brighthouse.ini 文件;

　 （ 2） 选取高效的数据类型

 　（ 3） 使用 comment lookup： 可以减少存储空间，提高压缩率，对char和varchar字段采用它可以提高查询效率。 实现机制很像位图索引，实现上利用简短的数值类型替代 char 字段已取得更好的查询性能和压缩比率。 使用时除了对数据类型有要求，对数据也有一定的要求。一般要求数据类别的总数小于 10000 并且当前列的单元数量 / 类别数量大于 10 。 比较适合年龄，性别，省份这一类型的字段。

　　（ 4） 尽量有序地导入数据: 每一列分成 n 个 DP ，每个 DPN  列面存储着 DP 的一些统计信息。有序地导入数据能够使不同的 DP 的 DPN  内的数据差异化更明显。比如按时间 date 顺序导入数据，那么前一个 DP 的 max （ date ） <= 下一个 DP  的 min(date) ，查询的时候就能够减少可疑DP ，提高查询性能。

　 （ 5） 使用高效的查询语句： 尽量不适用 or ，可以采用 in 或者 union 取而代之； 减少 IO 操作，原因是 infobright 里面数据是压缩的，解压缩的过程要消耗很多的时间；查询 的时候尽量条件选择差异化更明显的语句； Select 中尽量使用 where 中出现的字段。原因是 Infobright 按照列处理的，每一列都是单独处理的。 限制在结果中的表的数量，也就是限制 select 中出现表的数量； 尽量使用独立的子查询和 join 操作代替非独立的子查询； 尽量不在 where 里面使用 MySQL 函数和类型转换符； 尽量避免会使用 MySQL 优化器的查询操作； 使用跨越 Infobright 表和 MySQL 表的查询操作；尽 量不在  group by 里或者子查询里面使用数学操作，如 sum （ a*b ）； select 里面尽量剔除不要的字段； Infobright  执行查询语句的时候，大部分的时间都是花在优化阶段； 编写查询语句的时候很多的细节问题还是需要程序员注意；

6、可能的研究点

    （1）New Objectives、New Schemas、New Volumes、New Queries、New KNs；

    （2）New Data Types、SQL Extensions、Feature Extraction、Data Compression

    （3）Count Distinct、Count（*）on Self-Joins、Decision Trees、Contingencies

    （4）Technology based on interaction between rough and precise operations, open for adding new structures

    （5）Full product, simple framework, ad-hoc analytics, good load speed, 10:1"all inclusive"compression

    （6）The core technology based on more data mining, rough sets, computing with rough values, et cetera

    （7）Infobright Community Edition (ICE) ready for a free usage and study, as well as open for contributions