一、项目名称
XXXX平台大数据改造
二、开发周期
2016年3月 - 2016年11月
三、从个人视角看团队
1) 值得保持的优点
- 团队氛围融洽、交流通畅。
- 团队构成比较合理。年轻人技术强力，老人能够把控项目方向。
- 遇到问题及时沟通，群策群力解决问题。
- 有吃苦耐劳的精神，每个人都抱有很高的责任心。能顶住持续高强的压力。
- 公司大环境给予的支持力度大，从技术、工程、到后勤保障都值得称赞。
2) 仍需要改进的地方
- 需求管理：
客户提出来的需求比较零散，需要整理入册，安排优先级。应对其状态进行追踪。保持与客户的互动。
- 单点作战：
每个人担当的任务没有其他人可以分担，一旦出现问题，项目将受到较大影响。
- 质量管控：
由于持续高压，导致程序质量多少存在一些问题。
大数据项目的测试手段比较落后，也是一个对质量影响比较大的因素。
- 架构风险：
整个项目的技术架构经历了很多次的迭代，给予项目带来了极大风险。
虽然侥幸过关，但是，这种框架上的持续变动确实需要想办法避免。
应尽量在项目前期，提出多种解决方案，采取并行研发的方式来寻求降低风险。
四、从项目看自己
XX项目虽然有惊无险的顺利过关了。但是，我个人在参与整个项目的过程中，却一直有一种莫名的“恐慌感”，最近也一直在想这种恐慌来源于何处。可能来自于以下几点吧。
- 对个人技术功底的不自信。多年外包的经验很难在技术上给我带来多大的自信。
- 对新技术稳定性存的不信任。
- 久久未能得到客户的认可时，对项目未来的担忧。
- 一直持续追赶的状态，安全感被逐渐消磨。
- 有些技术问题从表面上看是解决掉了，但是并没有理解其中的“道”。
虽然项目赢得了阶段性的胜利，但这些恐慌在一定时间内将一直伴随着我。
希望能够逐渐适应这种节奏，把这些恐慌扼杀，带着节奏去完成今后的项目。
五、项目优化策略
- 资源隔离：
将耗费性能的处理隔离出来，单独占用资源，以防止资源被其他处理抢占。
- 热点数据：
将经常访问的数据形成热点数据区，以加快查询速度。（HBase Bucket Cache）
- 数据分流：
增加后置资源利用率，将一部分企业放置到后置集群进行处理。
- 采用SSD：
实践证明SSD盘可以非常明显的提高读写速度。
- 批量写入：
数据写入数据库的处理，尽量使用批量写入的方式。
- 展示分离：
展示页面所使用的数据与永久持久化的数据可以分离开，以提高展示的性能。
六、大数据入门策略
XX项目是我第一个国内的项目，也是我经历的第一个大数据项目。
自己技术功底相对薄弱，从零基础到给项目提供战斗力还是经历了比较痛苦的过程。
比较想分享的是自己学习大数据的从0到1的这个过程吧。
- 认识大数据
首先要知道大数据的定义，知道大数据的产生和意义、大数据能解决什么问题。
- 了解大数据用到的技术
这里的了解，只是知道有这么一个技术而已。不需要对技术有更深层次的了解。
从以下几个方面对真个技术生态圈有一个概念上的认识即可。
- 编程语言
- 展现技术
- 数据存储
- 处理框架
（机器学习、数据挖掘等没有接触）
- 从必备基础技能学起
基础建设决定上层建筑，在进入项目之前需要在基础上下功夫。如：
- Linux命令
- Shell编程
- Java基础
- 大数据词汇（DB、ETL、DW、OLAP、DM、BI等）
- Git用法
- Maven用法
- 从Hadoop入门
大数据技术更多是的是采取分布式计算来解决海量数据的计算。而Hadoop是大数据技术领域中比较代表性的计算框架，技术比较成熟，其中的MapReduce是比较容易上手，非常适合理解分布式的“分而治之”的理念。
学习方法无碍是：看视频、看书、动手实践、解决问题、再次看书。
同时，需要多余身边的优秀人才交流，从他们那里吸收大数据的思维方式。
- 学习大数据必会技能
大数据的技术错综复杂，更新迭代也比较快。个人感觉下面几个应该属于必会技能了。
目前我还没有全部解除到，希望以后能逐渐接触。
【计算框架】
- Hadoop（离线处理、Yarn资源管理）
- Storm（流式计算）
- Spark（基于内存的分布式数据集、流式计算等）
【数据存储】
- HBase
- MongoDB
- 内存数据库（如Redis）
如果将大数据的相关技能比作一颗大树，那么整个技术生态可以按照下面这样来比喻吧：
- 水分 → 数据源
- 根茎 → ETL（数据抽取、转换、加载）
- 树干 → 数据仓库
- 枝叶 → 展示
- 深入了解分布式思维
传统的计算机技术大部分都是基于单点完成的，也就是一台计算机就可以完成。
计算量比较大的时候，就去想办法提高计算机的硬件性能。
而大数据由于有5个V在那里，所有，更多的采用分布式来完成计算和存储功能。
也就是“分布式”处理了。那么，分布式处理和传统的处理方式在思维方式上有什么区别呢？
彪哥说：“万事万物道理都是相通的”。
我时常将“分布式计算”与“项目管理”进行比较，也确实从中获益不少。
------------------------------------
一个人是一个独立单位，可以独立完成量比较小的任务。
当任务比较多、大、复杂的时候，就需要多人协作完成，也就是团队了。
一个团队的构成比较复杂，不同的协作方式，可以解决不同的场景，
当然，不同的协作方式也代表效率、风险、职能等多方面的不同。
假如一台计算机比作一个人。
一台计算机完成的任务有限，当大量的任务的时候，就需要多台计算机来协作完成。
同样，多台计算机同时处理一个作业的时候，就涉及到协作策略、节点职能、沟通策略、风险应对等多方面的考虑。
比如从以下几点来看：
① 项目经理不应该成为团队的瓶颈。（Hadoop1.x进化到Hadoop2.x的原因）
② 资源需要备份，个人问题不能影响团队。（单节点故障问题）
③ 团队之间的高效沟通。（节点之间的通讯策略）
④ 数据存储策略。（是放在脑袋（内存）里，还是写在本（磁盘）上）
⑤ 资源分配方式。（Yarn资源分配）
------------------------------------
七、总结
保持学习的心态。
在技术上不要掉队。
为项目提供即战力为先。
保护革命的本钱（身体）。
持续推演个人职业规划。
多与年轻人接触。
※由于有项目保密协议，无法透露项目的具体细节，以及调优的相关参数。
也不敢透露项目的架构设计，仅留此博客用来自我总结。
--END--