大数据，商业智能的挑战
分类： 大数据
目录：
1. 大数据背景
2. 开源大数据生态圈和商用大数据生态圈
3. 开源前端生态圈和商用前端生态圈
4. 大数据BI系统的底层技术
5. 大数据BI系统的演变过程
6. 建设大数据BI系统的思考
大数据的4V
1. 数据量大(Volume)
2. 速度快(Velocity)
3. 类型多(Variety)
4. 价值密度低(Value)
开源大数据生态圈
1. Hadoop HDFS、Hadoop MapReduce, HBase、Hive 渐次
诞生，早期Hadoop生态圈逐步形成
2. Hypertable是另类。它存在于Hadoop生态圈之外，但也曾经
有一些用户
Hadoop MapReduce不适合实时计算？
1. 任务分配Server不会将信息Push到计算Node，而是让计算
Node通过心跳去Pull任务
2. 基于框架的通用性，MapReduce代码也会在HDFS中传送，在
各计算Node展开，再通过启动新JVM进程装载并运行
3. 类似的JVM进程启停有5、6次之多
4. Reduce Task只能在所有Map Task完成之后才能启动
中期：开源
在Hadoop MapReduce框架之外，衍生出了一批低延迟的大数据
分析项目：Cloudera Impala, MapR Drill, HBase Coprocessor,
Spark, etc.
开源大数据生态圈
MySQL,MonetDB,PostgreSQL.
商用大数据生态圈
IBM-Netezza,Oracle-Exadata,Teradata,GreenPlum
开源前端生态圈
统计分析和数据挖掘：R，RHadoop,Mahout。
展现分析：JasperSoft,Pentaho,Openi,Birt。
商用前端生态圈
统计分析和数据挖掘：SAS,PASS。
展现分析：Cognos, BO, Microsoft, Oracle, Microstrategy,SmartBI。
大数据BI系统的底层技术
1. 分布式计算
2. 分布式通信
3. 内存计算
4. 列存储
5. 库内计算
分布式计算
1. Offline MPP
2. Online MPP
分布式通信
1. Performance
2. Load
3. Variance
内存计算
1. All Data
2. Hot Data
列存储
1. Compact (Run Length, Dict, Range, LZW，Delta, etc.)
2. Partial I/O
3. Block Copy
库内计算 - 条件查询
库内计算 - 聚集查询
Sum
1. Map: Sum
2. Reduce: Sum_Sum
Count
1. Map: Count
2. Reduce: Sum_Count
Variance
0. Formula: (n * Σx2 – (Σx)2) / (n * (n – 1))
1. Map: Count, Sum, SumSQ
2. Reduce: Sum_Count, Sum_Sum, Sum_SumSQ
Covariance
0. Formula: 1/n * Σxy - μx * μy
1. Map: Sum_x, Sum_y, SumWT_xy,Count_x
2. Reduce: Sum_Sum_x, Sum_Sum_y, Sum_SumWT_xy, Sum_Count
库内计算 子查询
子查询大致可以分为以下几类：
1. Type-A, 2. Type-N, 3. Type-J, 4. Type-JA
例如，Type-J 子查询可改写为Join(关联):
Select t1.col1 from t1 where t1.col2 in (select t2.col2 from t2 where t1.jcol=t2.jcol)
1. Merge the tables in the subquery to the ‘from’ clause of the main query.
2. Add subquery conditions (including joins) to the main query’s ‘where’ clause.
The conditions should be combined using an AND operator.
3. Replace Ri.Ci op (select Rj.Cj) with a join: Ri.Ci nop Rj.Cj,
and AND it with the entire condition.
If op is IN, the condition is Ri.Ci = Rj.Cj
If op is NOT IN, the condition is NOT (Ri.Ci = Rj.Cj)
大数据BI系统的演变过程
第一阶段
1. OLAP on OLTP
第二阶段
1. Materialized View
2. Stage, ODS, DWD, DWA
3. ROLAP, MOLAP, HOLAP
第三阶段
1. 开源社区
2. 一体机 , MPP DW, MPP DM
建立大数据BI系统的思考
大数据BI系统并不仅仅是数据展现
1. 要能够掌握情况、分析问题、找到答案
2. 前端系统的交互和分析能力要强大：过滤(Filter)、钻取(Drill)、
刷取(Brush)、缩放(Zoom)、关联(Associate)、变换
(Transform)、动态计算（Dynamic Calculation）、链接(Link)
3. 数据挖掘、预测将变成重要的需求
性能 — 最重要的功能？
1. 性能需要衡量交付一个BI应用的整体周期及难易程度
2. 谨慎采用 Cache、Preaggregation等不合乎直觉的技术：优
化效果不稳定；难以管理，可能失去控制
3. 性能最好不以牺牲粒度(Granularity)达到：粒度越细越好
4. 海量数据，实时处理
建设方向
1. 业务驱动优于数据驱动
2. 自助式(Self -Service)的大数据BI系统
建设原则
1. 敏捷开发原则（ADP）：Agile Development Principle. 好系统不是一
蹴而就，先切入进去再持续迭代
2. 开闭原则（OCP）：Open to Extension, Close to Modification. 减少BI
应用对数据层的污染
3. 依赖倒置原则（DIP）：Dependency Inversion Principle. 合理架构，
降低数据与应用之间的依赖度
4. 里氏替换原则（LSP）：Liskov Substitution Principle. 开放标准，使
各模块的替换性好
产品选型
1. 正确面对开源和商业产品：开源是一种商业模式，没有免费的午餐
2. 正确面对国际和国内产品：在 TCO、Service、 Customization等方面仔细权衡
3. 大数据BI系统的TCO并不一定就高：曾经观察到一些项目以十万左右的开销支持
了1 TB数据量的实时分析(包括软硬件)
4. 选择最适合自己的、服务最好的产品和技术
常见架构
MPP DM
MPP DW
一体机
hadoop+MySQL
hadoop+HIVE。
1. 大数据背景
2. 开源大数据生态圈和商用大数据生态圈
3. 开源前端生态圈和商用前端生态圈
4. 大数据BI系统的底层技术
5. 大数据BI系统的演变过程
6. 建设大数据BI系统的思考
大数据的4V
1. 数据量大(Volume)
2. 速度快(Velocity)
3. 类型多(Variety)
4. 价值密度低(Value)
开源大数据生态圈
1. Hadoop HDFS、Hadoop MapReduce, HBase、Hive 渐次
诞生，早期Hadoop生态圈逐步形成
2. Hypertable是另类。它存在于Hadoop生态圈之外，但也曾经
有一些用户
1. 任务分配Server不会将信息Push到计算Node，而是让计算
Node通过心跳去Pull任务
2. 基于框架的通用性，MapReduce代码也会在HDFS中传送，在
各计算Node展开，再通过启动新JVM进程装载并运行
3. 类似的JVM进程启停有5、6次之多
4. Reduce Task只能在所有Map Task完成之后才能启动
中期：开源
在Hadoop MapReduce框架之外，衍生出了一批低延迟的大数据
分析项目：Cloudera Impala, MapR Drill, HBase Coprocessor,
Spark, etc.
开源大数据生态圈
MySQL,MonetDB,PostgreSQL.
商用大数据生态圈
IBM-Netezza,Oracle-Exadata,Teradata,GreenPlum
开源前端生态圈
统计分析和数据挖掘：R，RHadoop,Mahout。
展现分析：JasperSoft,Pentaho,Openi,Birt。
商用前端生态圈
统计分析和数据挖掘：SAS,PASS。
展现分析：Cognos, BO, Microsoft, Oracle, Microstrategy,SmartBI。
大数据BI系统的底层技术
1. 分布式计算
2. 分布式通信
3. 内存计算
4. 列存储
5. 库内计算
分布式计算
1. Offline MPP
2. Online MPP
分布式通信
1. Performance
2. Load
3. Variance
内存计算
1. All Data
2. Hot Data
列存储
1. Compact (Run Length, Dict, Range, LZW，Delta, etc.)
2. Partial I/O
3. Block Copy
库内计算 - 条件查询
库内计算 - 聚集查询
Sum
1. Map: Sum
2. Reduce: Sum_Sum
Count
1. Map: Count
2. Reduce: Sum_Count
Variance
0. Formula: (n * Σx2 – (Σx)2) / (n * (n – 1))
1. Map: Count, Sum, SumSQ
2. Reduce: Sum_Count, Sum_Sum, Sum_SumSQ
Covariance
0. Formula: 1/n * Σxy - μx * μy
1. Map: Sum_x, Sum_y, SumWT_xy,Count_x
2. Reduce: Sum_Sum_x, Sum_Sum_y, Sum_SumWT_xy, Sum_Count
库内计算 子查询
子查询大致可以分为以下几类：
1. Type-A, 2. Type-N, 3. Type-J, 4. Type-JA
例如，Type-J 子查询可改写为Join(关联):
Select t1.col1 from t1 where t1.col2 in (select t2.col2 from t2 where t1.jcol=t2.jcol)
1. Merge the tables in the subquery to the ‘from’ clause of the main query.
2. Add subquery conditions (including joins) to the main query’s ‘where’ clause.
The conditions should be combined using an AND operator.
3. Replace Ri.Ci op (select Rj.Cj) with a join: Ri.Ci nop Rj.Cj,
and AND it with the entire condition.
If op is IN, the condition is Ri.Ci = Rj.Cj
If op is NOT IN, the condition is NOT (Ri.Ci = Rj.Cj)
大数据BI系统的演变过程
第一阶段
1. OLAP on OLTP
第二阶段
1. Materialized View
2. Stage, ODS, DWD, DWA
3. ROLAP, MOLAP, HOLAP
第三阶段
1. 开源社区
2. 一体机 , MPP DW, MPP DM
建立大数据BI系统的思考
大数据BI系统并不仅仅是数据展现
1. 要能够掌握情况、分析问题、找到答案
2. 前端系统的交互和分析能力要强大：过滤(Filter)、钻取(Drill)、
刷取(Brush)、缩放(Zoom)、关联(Associate)、变换
(Transform)、动态计算（Dynamic Calculation）、链接(Link)
3. 数据挖掘、预测将变成重要的需求
性能 — 最重要的功能？
1. 性能需要衡量交付一个BI应用的整体周期及难易程度
2. 谨慎采用 Cache、Preaggregation等不合乎直觉的技术：优
化效果不稳定；难以管理，可能失去控制
3. 性能最好不以牺牲粒度(Granularity)达到：粒度越细越好
4. 海量数据，实时处理
建设方向
1. 业务驱动优于数据驱动
2. 自助式(Self -Service)的大数据BI系统
建设原则
1. 敏捷开发原则（ADP）：Agile Development Principle. 好系统不是一
蹴而就，先切入进去再持续迭代
2. 开闭原则（OCP）：Open to Extension, Close to Modification. 减少BI
应用对数据层的污染
3. 依赖倒置原则（DIP）：Dependency Inversion Principle. 合理架构，
降低数据与应用之间的依赖度
4. 里氏替换原则（LSP）：Liskov Substitution Principle. 开放标准，使
各模块的替换性好
产品选型
1. 正确面对开源和商业产品：开源是一种商业模式，没有免费的午餐
2. 正确面对国际和国内产品：在 TCO、Service、 Customization等方面仔细权衡
3. 大数据BI系统的TCO并不一定就高：曾经观察到一些项目以十万左右的开销支持
了1 TB数据量的实时分析(包括软硬件)
4. 选择最适合自己的、服务最好的产品和技术
常见架构
MPP DM
MPP DW
一体机
hadoop+MySQL
hadoop+HIVE。