29 August 2020
在大数据的概念出现之前，稍微有点规模的企业想做以决策为目的的技术和应用，通常是用商业智能BI框架/数据仓库来做，传统的BI通常由Data warehouse技术来处理不用来源的数据， 比如企业的ERP，CRM，SCM这样的业务系统等等等，利用数据分析和数据挖掘，然后使用商用报表工具比如microstrategy，tableau或者自定义报表做数据可视化。
随着企业业务的发展，传统的数据库软件工具在海量数据的获取/存储/管理/分析方面逐渐力不从心，于是大数据的生态系统应运而生，在谷歌三驾马车之前， 各大公司的解决办法都是做垂直伸缩追求黑又硬的超级计算机，但这样做即便有摩尔定律也逐渐开始架不住日益增长的业务需求，2003年开始到2007年，google发表三篇论文， 分别是分布式文件系统GFS，大数据分布式计算框架MapReduce和NoSQL数据库BigTable，更好更贵更大的单个服务器始终是干不过抱团到一起的多个普通机器的， 然而google只发表论文，并不开源（因为最开始三驾马车主要是为了解决谷歌内部网页抓取和索引构建的需求），这就蛋疼了， 于是当时还在yahoo的大神道格卡丁（此君也是Lucene的创始人）就实现了对应的三个阉割版，HDFS对应GFS，Hadoop MapReduce对应google的MapReduce，HBase对应BigTable， 这就齐活了，虽然刚开始这个山寨版跟google内部用的正统版差得很远，但是架不住用的人越来越多，结果后来的google云反而不得不提供开源社区的山寨版本的服务（可见社区的重要性）， 当然因为使用场景的不同，山寨版和正统版发展的方向也是渐行渐远了。
作为以前商业智能BI的替代者，目前大数据的特征包括：数据源多，数据格式多样（结构化数据，非结构化数据比如日志，Excel文件，CSV文件，文本文件，甚至pdf等）， 从量级上看最少也应该是TB级别（TB, PB, EB …），同时数据增长速率也很快。
大数据生态和各种轮子技术逐渐趋于成熟：
数据来源很多，应该如何采集和集中呢？于是Sqoop，Flume等工具就出现了；
数据采集后，该怎么存储呢？于是GFS/HDFS, FB Haystack, Tecent FS这样的分布式文件存储系统就出现了；
数据增长太快了，水平伸缩不可避免，光是RAID可不行，HDFS设计的时候的高可用性很重要（区块链的JPFS，STORJ这些也是类似的思想）；
数据存储之后，如何快速把数据转换成统一的格式，比如paquet或protocol buffer？刚开始的计算框架是Hadoop MapReduce，但有些以前专门做分析的人只会sql，那怎么办？于是Pig，Hive这样的引擎出现，可以将sql解析成MapReduce使用的代码；
Hadoop MapReduce只能一批一批地处理（批处理），如果想流式处理，输入一条数据就能得到结果，那就可以使用Storm/JStrom；又想流处理又想批处理，那就得搭HDFS+MapReduce+Yarn的Hadoop集群，再搭一个Storm集群，两个集群很难管理，于是可以用Spark，Flink， Beam这样的一站式计算框架，两个方面都兼顾到了（当然统一接口还有很多工作要做），同时因为相比MapReduce和Storm更优化的设计，Spark的计算能力也提高了很多；
现在一些一线公司做实时计算外，大部分公司还是做离线计算的，很多时候大数据的架构只需要配置存储+计算+任务调度这些，HDFS+Hive+Zookeeper为主，一些实时计算需要Storm，Kafka； Lambda和Kappa这些架构出现提供了业务处理的通用架构；
数据库的垂直伸缩其实也大大加强了，比如google的spanner，亚麻的redshift，可以解决很多大数据的问题；水平伸缩关系型数据库可以做读写分离/分库分表/负载均衡集群，NoSQL同样做水平伸缩，根据业务考虑ACID的取舍；整体架构根据业务做CAP取舍，比如分布式架构，P是必选的；
Azkaban,Ozzie可以提供定时任务调度；
Zepplin和Hue等可以作为图形化任务执行管理工具，方便查看和编写；
Java，Scala和Python都要掌握；