本文共 1362 字，大约阅读时间需要 4 分钟。
自从建了Spark交流的QQ群之后，热情加入的同学不少，大家不仅对Spark很热衷对于Storm也是充满好奇。大家都提到一个问题就是有关storm内部实现机理的资料比较少,理解起来非常费劲。
尽管自己也陆续对storm的源码走读发表了一些博文，当时写的时候比较匆忙，有时候衔接的不是太好，此番做了一些整理，主要是针对TridentTopology部分，修改过的内容采用pdf格式发布，方便打印。
文章中有些内容的理解得益于徐明明和fxjwind两位的指点，非常感谢。
在涉及具体的技术前，先想一想为什么需要OLAP这样的系统，它有什么价值或者说在公司或部门这是不可取代的么？ 可以带来哪些价值，是直接变现还是间接变现。 如果不能回答或回答不了，那么就是一个很大的问题，这其实意味着数据的质量存在问题。没有质量的数据，体量再大也毫无价值。
假设已经有很好的oltp系统，那么oltp系统在数据量不大的情况下，继续扮演olap角色也还可以。一旦业务红火，那么oltp中的analyze部分势必会分离出来，也就是olap和oltp相互单独存在。
olap中存储大量历史数据，数据存储成了olap中要解决的第一个也是首要问题，这个需求的解决方案有多种，可以是HDFS，也可以是NoSQL数据库，也可以是Distributed RDBMS，当中的取舍要视具体情况而定。后面会涉及具体的考虑维度。
如何将数据从oltp迁移到olap，这个同步机制需要考虑数据一致性，zero data-loss, 实时性要求等等。
在大量甚至是海量的历史数据中如何快速定位到所要符合条件的记录？ 数据量如果在TB级以上，就需要考虑使用solr或是elasticsearch
花了好多代价保存下来的海量数据，只是用了做简单明细查询，任何老板都不能容忍，一定要在历史的数据进行复杂的分析才行。这时候有一个好的分布式计算引擎就很有必要了。如spark/presto/impala
数据挖掘是一种比数据分析更为复杂的数据分析，呵呵，个人理解，有些绕。这个时候什么算法啦，什么机器学习啦，可以上场了。
数据分析中还需要考虑到另一个重要约束就是时间，如果希望分析结果愈快愈好，那么就需要采用如druid这样的系统。
如果数据规模在10TB以下，数据包含结构化和半结构化数据，明细查询中条件比较固定，不存在全文搜索。需要在比较短的时间内如秒级得到复杂分析结果，可以考虑使用distributed rdbms.
如果数据规模远远超过10TB，那么就需要将数据存储/数据查询/数据分析交由不同的系统来处理，这个时候就需要组成一个技术栈来解决总量。如HDFS/solr or elasticsearch/Spark or Presto or Impala. 为了提升分析的效率，除了从distributed computing engine侧进行优化之外，还需要从存储侧进行优化，采用先进的存储格式如parquet/orc/carbondata将会极大的提升分析性能。
转载地址：http://jdwal.baihongyu.com/