flume
　　Flume是Cloudera提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。

ETL，Extraction-Transformation-Loading的缩写，中文名称为数据提取、转换和加载。
ETL负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。
　　ETL一词较常出现在数据仓库，但其对象并不局限于数据仓库。
　　ETL是数据仓库中的非常重要的一环。它是承前启后的必要的一步。相对于关系数据库，数据仓库技术没有严格的数学理论基础，它更面向实际工程应用。所以从工程应用的角度来考虑，按着物理数据模型的要求加载数据并对数据进行一些系列处理，处理过程与经验直接相关，同时这部分的工作直接关系数据仓库中数据的质量，从而影响到联机分析处理和数据挖掘的结果的质量。
　　数据仓库是一个独立的数据环境，需要通过抽取过程将数据从联机事务处理环境、外部数据源和脱机的数据存储介质导入到数据仓库中；在技术上，ETL主要涉及到关联、转换、增量、调度和监控等几个方面；数据仓库系统中数据不要求与联机事务处理系统中数据实时同步，所以ETL可以定时进行。但多个ETL的操作时间、顺序和成败对数据仓库中信息的有效性至关重要。

一位互联网上市公司高管出身的创业者曾向南都记者这样自我剖析：“我们这类人创业，最大的问题在于，我们更擅长把一件事从1做到10，却不知道如何从0做到1.”而在已经过去的2011年里，这并不是一个个别现象。
2011年，是国内移动互联网疾速发展的一年，也是整个互联网世界疆土大拓的一年———它不仅指向由于智能手机的进一步普及而衍生出的一个被寄希望 “10倍于传统互联网”的移动网络世界，也包括了向更多传统行业如医疗健康、金融理财等进行更深层次的渗透，孕育出无数新的奇思妙想和商业模式。
同时，作为附带的衍生品之一，在过去一年里，我们也“遭遇”到了许多闻所未闻的新鲜词汇：LBS签到、轻博客、弹性社交、O2O……如果我们只是为了学 习这些概念，而去寻找与之对应的海外代表案例以及它们的故事与成绩，这本无可厚非，但如果将其作为选择创业方向的方法，则极有可能陷入本文开头所说的这种 “无根”状态中。
是的，这并非大公司高管出身的创业者才有的通病。我们称其为“概念式生存”。
真正的用户不会因为你是中国版的“×××”或是贴上了“LBS”、“O2O”这样的热门标签而使用你的产品。这句话直指“概念式生存”的要害。
诚然，这种将自己类比为某个海外热门公司的“中国版”或是为自己贴上几个热门标签的做法，的确能在投资方所限定的短短几分钟内将自身的模式表述得较为清 楚，但一来，即便是在盈利模式的形成普遍滞后的互联网创业领域，引入风险投资也并不是创业公司唯一的头等大事；二来，在实际创业的过程中，如果目光只聚焦 于某一个海外标杆或热门概念，则更容易因为忽略了本土用户的真实需求而招致“水土不服”。
在2011年里，我们看到过、也采访过很多聚集在一些热门概念下的海外标杆之中国版公司。尽管它们中大多数都能比照着某一个或几个海外标杆，将自己的商业模式解释得逻辑通顺，但在它们身上，我们却看不到任何属于他们自己的性格或基因。
真正的互联网创业，远不只是“一个产品经理+一个程序员在一间出租房内coding（写代码）“这么简单，它更需要创业者出没在城乡接合部周围的网吧 里，观察属于你的那群目标用户的真实习惯，抑或是在数九寒冬的深夜，驻守在已经没有了机场大巴、公共交通工具的机场、火车站附近，与旅客攀谈，了解他们当 下的心情与需求变化，并将这种最一手的市场资料融入自身商业模式的打造之中。
在即将展开的2012年里，外部经济环境的不明朗可能导致很多互联网、移动互联网创业企业举步维艰。也正是在这时，对“概念式生存”本身的反思才显得尤为重要。
我们并不反对“模仿”和借鉴，因为在消费者需求深度挖掘领域，海外创业者的确有着更为敏锐的触觉。但在模仿一种界面风格、色彩选择，甚至是一个按钮设计 的背后，它可能引发的用户心理或需求，又如何通过与线上线下信息或资源的整合来满足这种需求，却是需要创业者自己去完成的“隐形”功课。

1，针对面向对象的设计与分析：为了让软件有更好的可维护性，重用性以及快速开发，简短的OOAD与它的SOLID原则对于每一个软件工程师来说都是该牢记的。
2，软件品质因素：软件工程的好坏与软件的品质因素是绝对关联的。请在开发过程中深刻的理解这一点。
3，数据结构与算法：深刻理解像数组，列表，栈，树，图，集合等这样的基本数据结构，并在软件开发过程的关键部分使用好的算法。这样整个软件逻辑就会很清晰了。
4，Big-O符号来标记算法复杂度：在开发过程中，请务必使用 Big-O 符号来比较两个代码段或者不同算法所消耗的时间复杂度，这在开发高性能软件项目中是非常重要的。
5，UML图：UML图已经是一个通用的软件设计与分析的语言。如果你们在开发软件的过程中还没有做UML图，那么给人的感觉就是这压根就不是软件工程。
6，正确的衡量软件开发进度。
7，设计模式：设计模式是前人在解决各种各样问题的过程中总结出来的一套标准对策，在绝大部分情况下，使用这些模式肯定是利大于弊的。如果你不想在开发过程中重新造轮子，那么就直接使用它吧。
8，理解操作系统的基本原理：因为所有的应用程序都是直接运行在操作系统这个层级的，学习操作系统的基本原理能让我们对应用程序的底层以及性能有更好的把握。
9，学习计算机组成原理：几乎所有的应用程序甚至是OS都需要与物理硬件打交道的，所以学习计算机组成原理与理解操作系统原理一样都可以让你对于应用程序有更深刻的理解。
10，网络基础：网络与计算机组成，操作系统以及传输流程都是紧密关联的，理解网络基础能让你在开发过程中得心应手。
11，需求分析：对于软件工程来说，需求分析是项目的起点，也是整个项目最最重要的部分。如果这玩意你搞错了，整个项目的方向也就错了。
12，软件测试：在软件工程中，测试也是非常重要的。单元测试，黑盒测试，白盒测试，TDD，集成测试等等都是我们必须知道的。
13，独立管理：主要是说类库(JAR,DLL等等)的管理，熟悉使用一些类似Maven,Ant,lvy这样的知名工具对于大型项目的类库管理是非常有用的。
14，持续化集成：持续化集成能让测试大型模块与组件更加简单与自动化，关于这一点，你可以去了解 Hudson 这个工具。
15，ORM：了解Hibernate这种将对象与数据库表映射工具是非常有好处的，它可以减少你的代码量并节省你的代码维护时间。
16，DI(独立注入)：DI或者IoC(Inversion of Control)的具体实现框架Spring能让你创建对象时更加轻松，对于大型企业级项目更是如此。
17，版本控制系统：VSC工具(SVN,TFS,CVS等)对于团队合作开发以及版本控制都是非常重要的。熟练使用这类工具算得上是必备技能。
18，国际化：通过i18n来将不同语种的字符串存储在其他文件是让软件支持多语种最好的方法。所以i18n在不同的IDE上使用的方法我们应该了解。
19，架构模式：理解类似MVC,MVP,MVVM这样的架构模式非常关键，这能让你写出易维护，简洁以及方便测试的代码。
20，编写干净的代码：你的代码仅仅只是能够正常运行是远远不够的，它必须让编程人员轻易看懂来方便后续维护，所以，代码格式以及编写易读的代码技术都是我们需要了解的关键点。

AJP协议
　　AJP13是定向包协议。因为性能原因，使用二进制格式来传输可读性文本。WEB服务器通过TCP连接和SERVLET容器连接。为了减少进程生成socket的花费，WEB服务器和SERVLET容器之间尝试保持持久性的TCP连接，对多个请求/回复循环重用一个连接。一旦连接分配给一个特定的请求，在请求处理循环结束之前不会在分配。换句话说，在连接上，请求不是多元的。这个是连接两端的编码变得容易，虽然这导致在一时刻会有很多连接。
　　一旦WEB服务器打开了一个到SERVLET容器的连接，连接处于下面的状态：
　　◆ 空闲
　　这个连接上没有处理的请求。
　　◆ 已分派
　　连接正在处理特定的请求。
　　一旦一个连接被分配给一个特定的请求，在连接上发送的基本请求信息是高度压缩的。在这点，SERVLET容器大概准备开始处理请求，当它处理的时候，它能发回下面的信息给WEB服务器：
　　◆ SEND_HEADERS
　　发送一组头到浏览器。
　　◆ SEND_BODY_CHUNK
　　发送一块主体数据到浏览器。
　　◆ GET_BODY_CHUNK
　　从请求获得下一个数据如果还没有全部传输完，如果请求内容的包长度非常大或者长度不确定，这是非常必要的。例如上载文件。注意这和HTTP的块传输没有关联。
　　◆ END_RESPONSE
　　结束请求处理循环。

什么是软件配置管理(SCM)
　　软件配置管理是指通过执行版本控制、变更控制的规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。 (Software configuration management (SCM, or just plain CM) is an organizational framework — that is, a discipline — for managing the evolution of computer systems throughout all stages of systems development.)
为什么需要配置管理
　　如果没有软件配置管理，最大的麻烦是工作成果无法回溯。为了避免成果被覆盖，包括我自己在内的很多人早期采用手工管理版本的方式，例如当一个新版本产生时用当时的日期来命名文件夹，然后再复制一下以后的修改在复制的文件夹内进行，这样上一个版本就被保存下来了，周而复始不同的版本不会被覆盖。虽然这种方式可以从某种程度上解决版本的回溯问题，但他存在的缺点是显而易见的：第一点如果保留结果过于频繁，将会导致产生大量的有着重复内容的文件夹，庞大的物理空间，管理起来很麻烦；如果保留旧版本的时间间隔太长，可能产生某些有用的老程序无法回溯。第二容易产生版本的混乱，如果是团队开发软件，这种简单的方法更难解决问题的本质了。
人的问题
　　配置管理的方法是成熟的，而且相应的软件工具也是成熟的，基本上不存在看不懂、不会用的问题。配置管理的执行效果如何，完全是事在人为。妨碍配置管理的主要问题是人们嫌麻烦和侥幸心理作怪。
　　在没出乱子的情况下，执行版本控制看起来有些麻烦。每次修改工作的时候总是要Get Latest Version，接着Check Out，修改完后又要Check In，多做了三步。其实这三步加起来也就十几秒钟，而且不费脑子，根本没有添加多少麻烦，仅仅是个人感觉不爽而以。然而不执行版本控制的话，万一发生工作成果被覆盖或丢失等问题，麻烦就大了。
软件配置管理规范
　　软件研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，他们都应当妥善地保管起来，以便查阅和修改。如果把所有文件一股脑的塞进计算机里，那么使用起来很麻烦。
　　凡是纳入配置管理范畴的工作成果统称为配置项，配置项主要有两大类：一类是属于产品的组成部分，例如需求文档、设计文档、源代码、测试用例等等；另一类是在管理过程中产生的文档，例如各种计划、报告等。
　　每个配置项的主要属性有名称、标识符、文件状态、版本、作者、日期等。配置项及历史纪录反映了软件的演化过程。
　　基线由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被冻结后，不能再被任何人随意更改。基线通常对应于开发过程中的里程碑。通常将交付该客户的基线称为一个Release，为内部开发用的基线称为一个Build。
　　版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混乱等现象。配置项的状态有三种：“草稿”、“正式发布”和“正在修改” 。
　　配置项的版本号与配置项的状态紧密相关：
　　（1） 处于“草稿”状态的配置项的版本号格式为：0.YZ
　　（2） 处于“正式发布”状态的配置项的版本号格式为：X.Y。
　　一般只是Y值递增，当Y值到达一定的范围时X值才发生变化。
　　（3） 处于“正在修改”状态的配置项的版本号格式为：X.YZ。
　　一般只增大Z值，当配置项修改完毕，状态重新变成“正式发布”时，将Z值变为0，增加X.Y值。
常用的配置管理软件
　　目前国内常用的配置管理工具大概有SourceSafe、CVS、subversion、git和ClearCase，其中CVS，subversion和git属于开源版本控制系统。
　　SCM（Software Configuration Management，软件配置管理）是一种标识、组织和控制修改的技术。软件配置管理应用于整个软件工程过程。我们知道，在软件建立时变更是不可避免的，而变更加剧了项目中软件开发者之间的混乱。SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更。从某种角度讲，SCM是一种标识、组织和控制修改的技术，目的是使错误降为最小并最有效地提高生产效率。
常用的软件配置管理工具
　　现在常用的软件配置管理工具主要分为三个级别：
　　Rational ClearCase，CA CCC/Havest
　　Merant PVCS
　　Microsoft VSS，CVS