gnuplot绘图的套路和商业智能的不太一样，商业智能领域用D3( https://en.wikipedia.org/wiki/D3.js) 的lib不少，也有用Fusioncharts(https://en.wikipedia.org/wiki/FusionCharts)的，天善用的是Echarts, 但觉得和你的需求套路都不太一样。
 
这有个列表，你可以参考一下：
https://en.wikipedia.org/wiki/List_of_information_graphics_software
 

大数据只是统计分析为了达到目的而引入的一个技术工具或手段。
在此之前，统计分析的基础可能都只是抽样
有了大数据，那统计分析的维度更加丰富，结论也会有更多新的发现。
但是 大数据时代 传统统计学依然是数据分析的灵魂

我觉得任何东西都有一个度，物极必反，索引也是这样。
1. 索引建立过多肯定是非聚集索引的增加，因为聚集索引就一个，如果出现聚集索引发生变化的情况就意味着所有的非聚集索引都会跟着发生变化。

2. 不可能不考虑磁盘空间大小，也不可能不考虑建立太多索引时间太长的问题。数据仓库中的很多设计都会考虑磁盘空间大小和时间的问题。

3. 一个表总共就20个字段，结果建立了15个索引，这些表在维护插入更新的时候，可能就需要同时维护这15个索引，这种操作将变得非常的慢。

4. 索引过多优化器在选择优化过程的时候需要做更多额外的工作，需要评估那种组合优化更好一些。

5. 每一个索引都有统计信息，索引越多统计信息就越多。

帮你整理一下更全面的解释：
大多数SQL Server表需要索引来提高数据的访问速度，如果没有索引SQL Server要进行表格扫描读取表中的每一个记录才能找到索要的数据。为什么不对表中的每一个列创建一个索引呢？

这是因为，增加索引也有许多不利的一个方面：
第一，创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加；
第二，索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大，如果非聚集索引很多，一旦聚集索引改变，那么所有非聚集索引都会跟着变；
第三，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，一旦一个数据改变，并且改变的列比较多，可能会引起好几个索引跟着改变，这样就降低了数据的维护速度。
第四、每个索引都有统计信息，索引越多统计信息越多，过多索引会导致优化器优化过程需要评估的组合增多。创建索引的时候，应该仔细考虑在哪些列上可以创建索引，在哪些列上不能创建索引。

一般来说，应该在这些列上创建索引，例如：在经常需要搜索的列上，可以加快搜索的速度；

在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构；
在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；
在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的；这样查询可以利用索引的排序，加快排序查询时间；
在经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。
当增加索引时，会提高检索性能，但是会降低修改性能。

 
主键约束是一种保持数据完整性的逻辑，它限制表中的记录有相同的主键记录。在创建主键约束时，系统自动创建了一个唯一性的聚簇索引。虽然，在逻辑上，主键约束是一种重要的结构，但是，在物理结构上，与主键约束相对应的结构是唯一性的聚簇索引。换句话说，在物理实现上，不存在主键约束，而只存在唯一性的聚簇索引。

同样，在创建唯一性键约束时，也同时创建了索引，这种索引则是唯一性的非聚簇索引。因此，当使用约束创建索引时，索引的类型和特征基本上都已经确定了，由用户定制的余地比较小。 当在表上定义主键或者唯一性键约束时，如果表中已经有了使用CREATE INDEX语句创建的标准索引时，那么主键约束或者唯一性键约束创建的索引覆盖以前创建的标准索引。也就是说，主键约束或者唯一性键约束创建的索引的优先级高于使用CREATE INDEX语句创建的索引。

当创建唯一性索引时，应该认真考虑这些规则：当在表中创建主键约束或者唯一性键约束时，SQL Server自动创建一个唯一性索引；如果表中已经包含有数据，那么当创建索引时，SQL Server检查表中已有数据的冗余性；每当使用插入语句插入数据或者使用修改语句修改数据时，SQL Server检查数据的冗余性：如果有冗余值，那么SQL Server取消该语句的执行，并且返回一个错误消息；确保表中的每一行数据都有一个唯一值，这样可以确保每一个实体都可以唯一确认；只能在可以保证实体完整性的列上创建唯一性索引。

当创建复合索引时，应该考虑这些规则：最多可以把16个列合并成一个单独的复合索引，构成复合索引的列的总长度不能超过900字节，也就是说复合列的长度不能太长；在复合索引中，所有的列必须来自同一个表中，不能跨表建立复合列；在复合索引中，列的排列顺序是非常重要的，因此要认真排列列的顺序，原则上，应该首先定义最唯一的列，例如在（COL1，COL2）上的索引与在（COL2，COL1）上的索引是不相同的，因为两个索引的列的顺序不同。为了使查询优化器使用复合索引，查询语句中的WHERE子句必须参考复合索引中第一个列；当表中有多个关键列时，复合索引是非常有用的；使用复合索引可以提高查询性能，减少在一个表中所创建的索引数量。

索引可以分为簇索引和非簇索引，簇索引通过重排表中的数据来提高数据的访问速度，非簇索引则通过维护表中的数据指针来提高数据的索引。

聚簇索引的体系结构：索引的结构类似于树状结构，树的顶部称为叶级，树的其它部分称为非叶级，树的根部在非叶级中。同样，在聚簇索引中，聚簇索引的叶级和非叶级构成了一个树状结构，索引的最低级是叶级。

在聚簇索引中，表中的数据所在的数据页是叶级，在叶级之上的索引页是非叶级，索引数据所在的索引页是非叶级。在聚簇索引中，数据值的顺序总是按照升序排列。应该在表中经常搜索的列或者按照顺序访问的列上创建聚簇索引。

当创建聚簇索引时，应该考虑这些因素：每一个表只能有一个聚簇索引，因为表中数据的物理顺序只能有一个；表中行的物理顺序和索引中行的物理顺序是相同的，在创建任何非聚簇索引之前创建聚簇索引，这是因为聚簇索引改变了表中行的物理顺序，数据行按照一定的顺序排列，并且自动维护这个顺序；关键值的唯一性要么使用UNIQUE关键字明确维护，要么由一个内部的唯一标识符明确维护，这些唯一性标识符是系统自己使用的，用户不能访问；聚簇索引的平均大小大约是数据表的百分之五，但是，实际的聚簇索引的大小常常根据索引列的大小变化而变化；

在索引的创建过程中，SQL Server临时使用当前数据库的磁盘空间，当创建聚簇索引时，需要1.2倍的表空间的大小，因此，一定要保证有足够的空间来创建聚簇索引。索引的体系结构为什么要不断的维护表的索引，首先简单介绍一下索引的体系结构。SQL Server在硬盘中用8KB页面在数据库文件内存放数据，缺省情况下这些页面及其包含的数据是无组织的，为了使混乱变为有序就要生成索引，生成索引后就有了索引页和数据页，数据页保存用户写入的数据信息，索引页存放用于检索列的数据值清单关键词和索引表中该值所在纪录的地址指针。簇索引实质上是将表中的数据排序，就好像是字典的索引目录。

非簇索引不对数据排序它只保存了数据的指针地址。向一个带簇索引的表中插入数据，当数据页达到100%时由于页面没有空间插入新的纪录，这时就会发生分页，SQL Server 将大约一半的资料从满页中移到空页中从而生成两个半的满页，这样就有大量的数据空间。
簇索引是双向链表，在每一页的头部保存了前一页、后一页地址以及分页后数据移动的地址，由于新页可能在数据库文件中的任何地方因此页面的链接不一定指向磁盘的下一个物理页链接，可能指向了另一个区域这就形成了分块从而减慢了系统的速度。对于非簇索引的表来说，非簇索引的关键词是指向簇索引的而不是指向数据页的本身。为了克服数据分块带来的负面影响需要重构表的索引这是非常费时的，因此只能在需要时进行。

因为报表需求是最为直接和直观的，通常业务部门能把需求整理到这种程度已经算是非常不错的了。
 
并且我理解的数据分析，从业务人员角度来看他们所需要的报表和数据就已经满足了他们最基本的数据业务分析要求了。
 
你所提到的数据分析，我理解是不是抛开业务人员自身提出的报表要求之外，更加深入的希望从现有数据中再去挖掘一些潜在的价值？那么这一点如何引导我觉得取决于业务人员对业务本身的敏感程度，相应的工作包括需求分析的提出应该也是交给熟悉业务的分析人员来做，这种数据分析需求不是技术驱动的。
 
所以简单来说，业务部门提出的报表需求已经满足了他们的现有基本数据分析要求；更进一步的数据分析应该由对业务非常熟悉又有懂数据分析的专业人员来提出，他们会从业务数据中探索、发掘出更多常规报表中没有体现出来的数据价值和规律。
 
最后，可以借助于一些工具来做一些主动的数据分析和探索工作，比如像 Tableau，QlikView 或者永洪BI 的产品。
 
 
 
 

数据质量和业务逻辑有很大关系，我考虑主要分3类：
1.ETL过程质量问题
   汇总表不一致，ETL过程异常等
2.业务数据缺失
   主要的一些主数据啊或者是需要同步或上传的数据，应该有而没有，造成数据异常，这个需要业务执行上改善。
3.业务数据不一致
  多个业务系统需要同步但是由于各种原因，导致多份数据不一致，这部分还是需要业务系统改善。

具体监控可以根据业务规则做监控报表， 不过和BI报表一样需要有人看，特别是业务数据上本生的问题，这个就需要业务分工了。

BI切入点主要有三个个，建模，ETL开发，报表开发。建模需要经验，因为对于模型的建立要根据实际业务需求而定，ETL与报表开发是比较好的切入点，ETL开发主要接触的是底层的东西，学会ETL开发之后就可以逐渐切入到数据库建模的学习了，另一个切入点就是报表发开，报表开发是根据底层已经搭建好的模型进行前台界面报表的开发工作，上手快比较容易就搞报表，要搞核心，做底层，就学ETL开发。
另外数据库操作的基础是必有要有的。

RFM分析算不上是一个模型，它只是一个数据分析方法，分析者可以根据自己不同的需求将客户分类为8大类、4大类、6大类都可以，它和决策树分析方法结合起来可以更细致的找到客户的特点，后面根据不同客户的特点采取不同的营销措施。

数据质量这块深有体味，曾经开发实施ERP多年，接过很多ERP业务需求并深入了解过业务，BI报表的需求等，有关数据质量分几种：
1.系统BUG问题：
 产生原因：A.开发测试验收流程不规范，遵循开发加自测=》测试=》业务需求部门验收的流程操作，减少这块引起的数据质量问题。
        B.开发过程中，可能版本控制的问题，对公用的过程，我修改后另外的开发人员进行覆盖等等问题
 解决方案：A.规范开发测试及版本控制流程，没有任何捷径所走，上面几个朋友都有提到，对已发生的问题开发人员进行修改；
        B.曾经使用过一套平台化开发的ERP系统，主要原因是开发人员的进进出去，修修改改，数据质量经常不准确，后来通过3个月的时间，把所有单据明细与库存明细帐、销售明细账、期间表、即时库存、成本表等等所有的过账逻辑在晚上进行修复重算，再更新重算后正确的数据，一举解决了困扰公司几年老大难的问题。但这工作需要对业务、数据结构、ERP业务流程、开发能力都比较强的人员来操作，才能保证重算的准确。
2.分析指标统一口径问题：
 产生原因：在一公司做BI系统的时候，指标口径不统一，比如像成本有：门店成本、销售成本、加成成本等等好几个，每次开会的时候，采购部、销售中心、财务中心、市场部等等拿出来的数据可能名称一样，但数据都不一样；
 解决方案：我想这一块还是比较好解决的，只要先统计整理公司所有的指标，然后把业务部门请上来，统一指标名称、指标解释、计算公式等，就不会产生同一个人，这个叫李老四，那个叫李二狗。
3.企业不同的时期业务系统处理方式上逐步优化产生的数据差异：
 产生原因：企业在不同的发展时间，系统处理会有所差异，特别是二开比较多的公司
 解决方案：A.后续规范的数据与前面不规范的数据，看是否可以通过相对应的关系，进行整理统一；
        B.如果上述都不能处理的话，我想还是对前面的一些数据进行分开统计分析，否则两者不一样统计了来会误导业务人员
        以前在一通讯行业工作的时候，原来在联通新用户（存费送机、购机送费、单开户）、老用户等等以前都是通过一个或几个字段的状态标志进行区别，后来业务发展，发现这样太复杂，后来做了一个政策层级的分类，统一规范。在处理前面数据的时候，对以前的数据进行修复处理，以保证与后续的数据统计方式一致。否则区别两个统计方式。
4.因为实际业务过程中无法规范而产生的数据质量问题：
 问题举例：在一服装制造行业工作的时候，来统计产品的实际工时，因为是A产品完工、B产品新生产，在这一交接阶段，同时进行生产，无法正确的统计实际的生产工时，这是正常的实际情况。
 解决方案：后与业务部门沟通，将当天的实际工时根据当天完工产品的理论工价来按比例分配，这样对统计分析虽然会有不真实的情况，但也是能相对真实。
 所以碰到问题的时候，可以是否可以折中处理，只要不完全违背统计分析的原则，还要以考虑相应的处理方式。
 说了这么多废话，希望可以在实际工作中引起一些思考。

是刚刚大学，还是刚刚大学毕业呀？这两个差别还是有些大的。
我想，如果你立志成为大数据架构师，那么不管spark，storm乃至更多更多的技术及方向，都是需要了解的。
这种纠结是完全没有必要的。
拿spark，storm这些来说，他们都是会有共同性的，找一个走走，可以借鉴了解，举一反三。如果你熟练了，可以很容易的切换的。至少我身边碰到水平稍高些的朋友都是如此。
因此，我觉得你纠结着两个，跳出来看，还是太小的范围了，建议你涉猎更多更多还要更多的技术方向，为了你的大数据架构师目标。
祝好运~

数据仓库，如果你作为概念来理解的话，他可以用大多数的数据库产品来解决。
譬如，数据仓库可以建立在DB2里，也可以建立在Oracle，SQL Server里。
与这些平台没有太多的紧密或是必然的联系，但是有些平台里会有对数据仓库的特别支持，一个例子是Oracle的OLAP Option。
如果你把数据仓库从产品角度来看，那么会有一些产品，乃至硬件软件一体机的产品。Teradata可以归作这一类吧。
至于建立数据仓库的过程中，可以通过手工脚本，也可以使用ETL工具来实现。
ETL工具也会有很多种的了。譬如SSIS，Infomatica，Datastage，Kettle等等。

实在对不起，没用过Greenplum，只用过类似的。
 
注重看几个问题：
1. 并发性，别被单用户查询性能给骗了
2. 复杂SQL查询能力：这个主要是看多SQL优化器是不是足够智能，很遗憾，很多都表现不好，
                                  单表查询能力超快...那有什么用啊？
                                  8个表还凑合？ 32个表根本查不了？ 那你设计的时候就要考虑很多逆规范化了
 
基本上，很多产品牛吹的闪闪发光，但有很多问题， 测了才知道。                         
除以上的日常应用问题，还需要考虑
1、 高可用性
2、磁盘利用率
3、重分布
 
希望真用过GP的出来说话。
 
 

Role Play模式的建模，不用建三个表。
只建一个部门的表，其他的用视图，或者SQL里用别名。

利用RFM方法算出最近一次购买时间、购买次数、购买金额的得分以后，可以找出购买次数大于2次以上的客户的消费特点：比如结合客户的基本信息和平均每次的消费金额，利用决策树或者聚类的方法都可以找出一些共同的特点，哪个范围内消费者的购买概率比较大，可以重点针对这个范围的客户做推广、活动，也可以根据这个结果改善客户维系的方法

我看着每天我的报表被人看了多少边，我就觉得是有价值的。

7804
 
另外，你说的价值我觉得你可以响数据分析方面发展，一般体现的都是数据的价值

我这几年陆陆续续认识过一些朋友做过不同的银行数据仓库项目，包括就在这个社区的很多朋友都有这方面的经验。项目失败肯定是不允许的，项目存在瑕疵肯定也是存在的。不会一次成型，迭代开发，多年维护，这跟其它 BI 项目本质上没有任何区别。
 
所有的 BI 项目从启动到调研，到开发测试上线维护的路线大都一样，没有什么特别的，所以也自然不会因为行业特殊就有特殊的科学实施步骤，参照正常的 BI 开发流程就可以了。
 
BI 项目中遇到的问题在这种银行项目中遇到的问题没有区别，非要强调的话就是业务至上至上至上上，数据安全、准确程度要求更高。其它的 BI 项目数字不准确了可能还会有一定的回旋余地，这种项目数字不准确错一个小数点上线就是大问题。