对于数据工作的一些总结

近几天由于升级了系统，系统的中文输入法ibus-pinyin一直用不了，安装了一个Sougou的云输入法Chrome插件，又可以输入中文了。科技的进步给我么生活带来的便利确实是令人惊讶的，所以做人当怀感恩之情，长有敬畏之心，别人用技术改变了我们的生活，而我们也要通过我么能做的为别人提供便利，这样这个世界才能更美好。

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

有总结才能有提高，做了一年半的数据工作了，现在辞职，闲赋在家，也到了总结一下的时候了，其中有经验也有教训，与大家分享一下，也希望能得到大家的批评与指正。说到数据工作，总体上有以下几个大块组成吧（按照工作的依赖关系或者时间先后）：

1。ETL模块

2。存储模块

3。计算模块

4。数据预处理模块

5。报表模块

6。监控系统模块

7。深度的分析挖掘模块

8。分析报告展现模块

9。基于分析挖掘模块的数据服务系统

10。数据服务系统反馈模块

X。数据清洗模块

以下就详细地说一下整个过程吧：

1。ETL模块（快照数据：Python脚本+Shell驱动+Rsyn（wget），用户行为日志数据：scribe+hdfs）：

ETL翻译成中文就是Extract（提取），Transform（转换，涉及到数据清洗），Load（载入）。连起来描述一下就是：将数据提取出来，做一下转换，然后讲转换后的数据载入到数据仓库中。概念并不复杂，但是在实际去做的过程中还是有许多需要考虑的问题。

（0）比如数据的存储结构，如果数据的存储是一致并且高度结构化的（像是金融行业数据），那我么就可以通过一些成型的工具来完成整个ETL过程；

（1）如果数据是结构化的但是数据是不一致的（比如跨国公司在全球的各个数据中心之间的数据），这样的情况下，Transform的过程就非常重要的，数据中心A用0和1来表示性别，而数据中心B用F和M来表示性别，我们必须通过T这个步骤将它们转换成一个统一的标识；

（2）还有就是数据的存储是非结构化的，比如用户的数据是存储在序列化之后的对象中（我所面临的情况就是，部分数据是结构化的，还有一部分数据是序列化后的对象），这样的情况下，用传统的ETL工具也许就没有那么顺手了，需要自己写一些脚本来完成数据的提取以及转换过程；

（3）还有就是数据的存储是非结构化的，并且要兼顾许多产品的ETL过程，这在我所在的社交游戏行业尤为明显，一个公司可能会有多款产品同时在线运营，而社交游戏的数据存储需要一定的灵活性，以方便功能的添加，所以序列化之后的数据是司空见惯的，事实上除了用户的付费数据，其它的各种数据都涉及到反序列化；产品不一样，所要的数据自然也不可能完全一样，但是如果上线一个新产品，就要去调动数据、BI、运营三个部门的工作人员去根据产品的现状参与制定整个产品的数据采集标准，显然是比较低效的，低效就导致了产品上线初期一些关键的数据拿不到，也许就会错过一些有价值的数据。对此的改进，我觉得应该是这样：抽象出一个行业标准的数据规格（比如记录什么数据，其记录规格是怎样的），每个产品都必须按照这个规格记录并提供数据，这是在产品研发、实现过程中必须考虑的一部分。这样，如果有新产品上线，就可以直接按照规格去提取数据，而省去了沟通的麻烦；另外对于产品个性化的数据，可以通过后来额外的沟通共同确定、实现。统一规格的数据对于报表系统的数据生成也是很重要的，有了统一的数据模型，也许我只要更改一下产品的标识，我就能完成整个产品的报表的配置生成工作。当然统一的规格也有短板，就是如果要更改这个规格，就会要求每个产品都做相应的变更，但是从总体上看，有一个统一规格的数据规格是能提高效率的。

（4）非结构化、多个产品，如果再加上大数据量的话，我么又需要考虑更多了。在如的今互联网时代，一个成功的社交游戏产品拥有几千万的用户也是很常见的事情。正所谓量变引起质变，如果数据量巨大，E的过程必然会成为瓶颈，这在我的工作中也得到了印证。解决方案无非就是优化E过程，采用多进程的模式来提高E的效率，事实证明效果还是不错的。

（5）ETL的确认机制。整个ETL的成功是需要确认的，ETL过来的数据是后来数据工作的基础，如果ETL过程由于某些原因只取过来一半的数据或者数据还没有采集完成就去拉去数据了，再考虑到数据快照的时效性，势必会对今后更深层次的数据工作产生不利影响。因此要保证整个ETL过程的可用性还必须建立一套通知、确认机制。这样不但能够从一定程度上保证ETL过程的可靠性，并且基于这些通知数据可以做数据驱动的计算（比如说报表数据的生成、数据的预处理计算）。

2。存储模块（Hadoop HDFS+ Mysql）

（0）数据仓库存储模块要能满足存储大量数据的要求。我们所选取的存储方案是Apache Hadoop的HDFS集群，它的可扩展性能很好地满足对于大量数据的存储需求，并且从Facebook、Yahoo！、中国移动等这些大公司的使用反馈来看，其可用性也是可以满足需求的。

（1）Mysql主要是用来存储报表数据，作为世界上使用量最大的开源DBMS，我想大家也应更改不会陌生吧！

 3。计算模块（Hadoop Mapreduce）

（0）Hadoop应该说是一套完整的存储计算套件了，并且基于它，也有很多工具已经被大量应用，像是Facebook的Hive，Yahoo！的Pig都是非常好的数据处理、分析工具。

（1）Hive是我们主要的分析工具，公司的BI部门也主要使用Hive进行一些常规的数据分析（或者预处理之后用其他工具，比如R，Excel，weka等分析）。之所以选择Hive而不是Pig主要还是因为学习曲线问题，Hive的查询接口是类SQL语句，而BI部门的分析人员大多也都熟悉SQL;Pig的分析接口是一种数据流语言，更加灵活，虽然学习曲线也不是很陡，但是毕竟也是一个全新的语言，多数人都不想在能用更熟悉的工具的时候，去选择另一个不熟悉的工具，特别是它们能实现的功能差不多的时候。

（2）报表数据的生成也是基于Hive来做的，为了充分利用Hadoop集群的计算能力，我们对于报表数据的计算是数十个进程同时进行的，这一点非常重要。

（3） BI部门的分析人员现在主要通过Cloudera的HUE工具来使用Hive。从终端界面转移到一个web页面，开始的时候，很多人（几乎是每个）都有抱怨的声音发出，这可能是习惯的问题。HUE确实是一个不错的工具，还是用Django做的。

4。数据预处理模块（Hadoop MapReduce + Hive）

（0）数据的预处理在数据仓库中是非常重要的一环，说的再飘忽一些，应该就是一种最初的建模工作。既然是创建模型的工作，那么它的重要性也就不言而喻了。创建模型必须谨慎，因为一个模型一旦成型并且投入使用，再要更改这个模型，那可能要付出很大的代价。

（1）整个数据预处理过程还设计到一些数据清洗的工作，将非法数据过滤掉。

（2）至于采用的技术方案，目前还是主要基于Hive来做，对于一些用Hive难以表达的预处理工作，则直接使用Hadoop的MapReduce API来编写MapReduce程序来完成。我也探索过用脚本语言来写MapReduce程序的方案，比如last.fm开源的DUMBO，用Dumbo写程序确实很快，但是其执行的效率与用原生的Java API相比确实差距较大，最终还是选择了用Java来写。

5。报表模块（tornado web server + 一系列开源框架）

对于一个看重数据的公司来说，一个报表系统是不可少的，下面是从报表系统的开发过程中总结出的一些经验：

（0）技术选型：本人Python出身，自然将范围锁定在Python那大量的web框架上。最后由于种种原因还是选择了tornado作为开发框架；数据库用的Mysql；Jquery、jqueryui是不可少的；数据可视化选用了highchart；还使用了YAML CSS框架；ORM用的是SQLAlchemy。

（1）前端设计：由于公司运营产品众多，所以按产品做了一个树菜单，来保存各个产品的报表分类、项目，每个报表基本包含两个元素：表和图形。

（2）数据处理流：鉴于对于数据的处理可能有很多环节，我在数据处理流中对数据结构的做了严格的一致性限制。任何模块处理后的数据必须保持一致的数据结构，这样每个处理模块就像一个过滤器，每个处理模块尽量与其它处理模块无依赖（当然还是有些依赖的）。事实证明，这样的设计在后来的功能演进过程中给我们带来了极大的便利。

6。监控模块（Python）

这个模块是非常重要的一个模块，任何一个完善的数据系统都应该有一个强大的监控系统，在这方面，我做的并不多，还请大家多指教。但是总体上来说需要监控的内容主要由以下几大项：

（0）ETL整个过程的监控

（1）对于数据预处理的监控

（2）对于数据计算结果的监控，目前我们已经实现，是在计算模块中添加了一些监控子模块实现的

（3）对于数据计算时间的监控

7。深度的分析挖掘模块

这主要涉及到相关专业人员的工作了。主要是利用Hadoop处理数据，然后利用各种分析这些数据。对于这种工作，我坚定地认为工具只是手段，思想才是灵魂。但是善假于物也是非常重要的一种素质和提高效率的一种途径。俗话说“工欲善其事，必先利其器”。在我们的分析部门中，使用的工具主要有Excel，Weka，我都不是很熟悉，前段时间我研究了一下R，感觉不错，不过没有深入使用过，还是没什么底，打算今后多加研究吧。

对于大数据量的一些数据挖掘工作，只能以强大的计算能力为依托了，为此，我实验过Apache的Mahout工具，这是一个可以基于Hadoop集群做分析的工具，不过一直都没有在正式的工作中使用过。

8。分析报告展现模块

分析的结果作为知识展现出来、管理，wiki应该是不二的选择。开源wiki众多，还是出于Python的原因，最后选择了MoinMoin，并通过External Cookie实现了与报表系统的认证、权限集成。从使用的效果来看，很不错。

9。基于分析挖掘模块的数据服务系统

这个模块在我离职时还是只是一个设想，其主要功能还是将数据挖掘的结果直接应用到产品中，为用户提供差异化的服务，这其中主要涉及到一个用户分类的问题。这项工作需要许多前期的准备工作，包括更加丰富的挖掘报告，后端部门的接口准备工作，我们数据团队的接口准备工作。

10。数据服务系统反馈模块

主要是用来衡量数据服务模块效果的，并根据这个效果调整利用数据服务的策略。

X。数据清洗模块

数据清洗的功能，主要是清除脏数据，分布在数据仓库系统许多数据处理的过程中。ETL级别的清洗是第一，而后分析级别的清洗。清洗这一步可能出现在系统的多个部分，所以我就给了它一个X编号。

在公司做了一年半的数据工作，回顾这一段历程，从一开始的用脚本跑业务数据库满足运营基本的数据需求，到着手组建基于Hadoop集群的数据仓库，到优化集群的性能、优化数据仓库的存储结构、建立初级的数据仓库模型，到最后设计、开发报表系统，协助分析人员做深层分析挖掘工作。我对于这些没有任何经验，但是在书本和谷歌的帮助下还是做了下来，也许做了的也就那样了，也不一定是最好的，但是令我欣慰的是，我所做的工作确实满足了公司的大部分需求；更令我欣慰的是从这个过程中，我实践了自我学习的方法，建立了自己的知识管理体系。最后，非常感谢我身边与我一起工作的每个人，从他们身上我学到了很多，我离职之后希望他们能将数据团队建设得更好。

休息一段时间，再启程！