说一点自己理解的大数据

之前写了好几年的web开发，前端后端都做过些项目，最近公司准备上马一个大数据项目，让我来负责，搞得刷题时间都被压缩了，诚惶诚恐很怕做不好，因为我的大数据经验只是在虚拟机/aws和openstack上搭建word count的水平。当然压力之下也有动力，决定努力攻克大数据工程师这个门槛，所以在这里记录下自己乱七八糟的学习感悟。

先提一下学习方式的问题，现在这么多新技术，应该如何去学，如果实在焦虑，可以在每种新技术出来的时候，花5分钟去了解这个技术是大致干什么的，然后花30分钟去读下文档了解下应用场景，最后花2个小时做个demo，这就足够了；如果这个技术好，那它就总会在将来某个时候以各种方式再三出现在你的面前，这时候深耕学习也不迟；如果这个技术不合适消逝了，那之前花的时间也不多，沉没成本很少。我一直记这个方式，所以之前也学习大数据和机器学习，都是这么做的，然后现在果不其然，很多技术要用到了，有时候摒弃完美主义，学习道路上做减法并努力去做个T字型人才会让感觉思路更清晰一些。

现在开始扯淡我从java工程师到现在深耕学习大数据的理解和做法，由于我以前很悲惨是学生物的，好巧不巧还是学进化生物学的，所以看什么东西都喜欢先看它发展的前因后果。

在大数据的概念出现之前，稍微有点规模的企业想做以决策为目的的技术和应用，通常是用商业智能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 ...），同时数据增长速率也很快。

现在9012年了，大数据生态和各种轮子技术逐渐趋于成熟：
1. 数据来源很多，应该如何采集和集中呢？于是Sqoop，Flume等工具就出现了；

2. 数据采集后，该怎么存储呢？于是GFS/HDFS, FB Haystack, Tecent FS这样的分布式文件存储系统就出现了；

3. 数据增长太快了，水平伸缩不可避免，光是RAID可不行，HDFS设计的时候的高可用性很重要（区块链的JPFS，STORJ这些也是类似的思想）；

4. 数据存储之后，如何快速把数据转换成统一的格式，比如paquet或protocol buffer？刚开始的计算框架是Hadoop MapReduce，但有些以前专门做分析的人只会sql，那怎么办？于是Pig，Hive这样的引擎出现，可以将sql解析成MapReduce使用的代码；

5.Hadoop MapReduce只能一批一批地处理（批处理），如果想流式处理，输入一条数据就能得到结果，那就可以使用Storm/JStrom；又想流处理又想批处理，那就得搭HDFS+MapReduce+Yarn的Hadoop集群，再搭一个Storm集群，两个集群很难管理，于是可以用Spark，Flink， Beam这样的一站式计算框架，两个方面都兼顾到了（当然统一接口还有很多工作要做），同时因为相比MapReduce和Storm更优化的设计，Spark的计算能力也提高了很多；

7. 现在一些一线公司做实时计算外，大部分公司还是做离线计算的，很多时候大数据的架构只需要配置存储+计算+任务调度这些，HDFS+Hive+Zookeeper为主，一些实时计算需要Storm，Kafka； Lambda和Kappa这些架构出现提供了业务处理的通用架构；

8. 数据库的垂直伸缩其实也大大加强了，比如google的spanner，亚麻的redshift，可以解决很多大数据的问题；水平伸缩关系型数据库可以做读写分离/分库分表/负载均衡集群，NoSQL同样做水平伸缩，根据业务考虑ACID的取舍；整体架构根据业务做CAP取舍，比如分布式架构，P是必选的；

9. Azkaban,Ozzie可以提供定时任务调度；

10. Zepplin和Hue等可以作为图形化任务执行管理工具，方便查看和编写；

11. Java，Scala和Python都要掌握；

下面我画了一个思维导图：

Java高级：反射机制，多线程，并发，虚拟机

Linux： 安装（centos/debian/suse），常用命令，Linux网络，防火墙，shell编程；

zookeeper： 分布式协调服务原理和选举机制，集群的安装和部署，zk的数据结构和命令；

Hadoop（HDFS+MapReduce+Yarn）：HDFS工作机制；MapReduce运行机制（运行流程，并发数如何决定，shuffle机制，自定义分区，排序，序列化，数据压缩，与Yarn协调，参数优化）；

HBase（JavaAPI操作）；

Hive(Hql基本操作和原理理解）；

Kafka

Storm - 因为出现的时间较早，所以很多企业其实用的还是它(扯个淡，当时Google自己玩自己的，微软觉得自己很牛也搞了个cosmos自己玩，别的公司单独玩不起，只好团结在一起做开源，雅虎领头贡献了三件套的阉割版，fb贡献了Hive，Presto和Cassandra；Linkedin贡献了Kafaka；Twitter贡献了Storm - Closure太小众了所以后来阿里重写为JStorm；另外大小公司贡献若干，比如HBase；至于亚马逊，2007年发表了Dynamo的论文后就一直躲在开源社区后面吸血发财，可惜了那么强的技术实力但对开源社区贡献几乎为0)
Scala：基础，编译器，数据结构（数组，映射，元组，集合），Actor， Akka， 高阶函数，隐式转换；

Python

Spark： Spark Core， RDD（api， 缓存， DAG）， sparksql（DataFrame， DataSet）， Spark streaming（DStream）

辅助工具(Sqoop/Flume/Oozie/Hue等)

机器学习算法以及mahout库加MLlib - 这个不专门做机器学习用不到；

Lambda/Kappa架构

Kylin

Alluxio

列了一堆，发现条理不够，只能先这样了，同时还发现又不知不觉掉入Yak Shaving的圈套：本来要打开软件写一个helloworld的，软件提示需要升级，然后点了升级，提示xx库不够新，然后又更新xx库，提示要升级yy驱动，然后升级yy驱动，系统告诉说要编译这个驱动，必须下载zz版本的编译器和库，只能更新编译器，系统又说zz版本编译器必须在aa系统上运行，然后就升级系统了，系统升级完后要重启才行，重启后刚才的思路断了。。。几个小时过去，发现系统升级导致了别的几个软件损坏不能用了，然后更新那些软件，上网去找解决问题的方法，不知不觉到了半夜，累成了狗，却发现问题还有一大堆没解决，而最开始的helloworld也还没写。。。。

等我学习一段时间理解更深刻了再回来接着写。。。。

你还能想起最开始的helloworld也还没写。我现在已经忘了看这篇文章之前准备看完后干啥了


update: 二十分钟过去了。
还没想起来原来准备干啥
但是想到了我还有个学习Cassandra的学习笔记。贴到这里也许对他人有用：

https://www.1point3acres.com/bbs/thread-514224-1-1.html

给大家推荐个干货 知乎搜 阿莱克西斯

感觉这两年都是containerize了，哈哈

写的很好 mark一个

感谢！！！！！！

14417335 发表于 2019-5-4 21:34
你还能想起最开始的helloworld也还没写。我现在已经忘了看这篇文章之前准备看完后干啥了

我去看了下链接，挺详细的，希望你坚持写。。数据存储方面由于公司发展阶段需要业务支撑的问题，我们最开始用的是企业解决方案Vertica，然后现在随着业务趋于稳定，可以逐渐开始拥抱开源了，采用开源产品对公司的知识产权/专利，技术栈发展甚至人才梯队的建设等等是有好处的，代价是技术栈转型过程中会有无数的坑正在踩或者准备踩，替换Vertica的过程中我们也考虑过Cassandra，但是在根据我们自己的业务数据做试验的时候发现Cassandra的性能，尤其是读性能比Vertica低了~20%，我自己觉得可以继续在Cassandra上做优化减小这个差异，但是几个同事是数据库专家，坚持要切换到另外的开源产品上。。。让我看看能不能从你的链接中学到些什么

感谢分享.受益颇多.

感谢分享.受益颇多.

写得真好！

写得太好了！求楼主继续写

希望LZ 能不能整理一个Data engineer 的面筋。