通过这两项可以判断一个数据处理人员的技术功底。
不同级别的数据量决定了处理方法的不同。如果只有100M的数据，无论代码写得多么懒，都可以使用机器暴力，在短时间内解决。而如果是100T的数据，则需要精致的算法，同时考虑到机器资源（内存空间、CPU、磁盘空间），才能巧妙解决这些问题。100M的数据，可以不怎么考虑异常，代码可以重跑；而 100T的数据则不同了，重跑任何job是严重的伤不起啊。
数据的时效性也可以判断技术功底，更深层次来说，数据业务特点也决定了技术要求。从接触到的数据看，存在两种不同的数据层，一是离线数据层，二是在线数据层。静态数据变换小，实时性要求低，可以进行离线分析，普通的脚本与程序都可以应付；动态数据实时要求较高，如果需要考虑多维度和高并发特点，则不是一个简单的脚本就能解决的了。
其实，要做好数据处理，需要充分结合业务特性和数据特点考虑，采用适合的方法，才能解决实际问题。期望一招通杀，往往事与愿违。
很多日志LOG需要正则表达式提取对应的记录与字段，不深入说，需要用到的时候才查找资料
在组内，很多人都痛苦甚至痛恨过数据以及代码的编码问题。现在想想，我们之所以痛恨，是因为我们的能力还不够。如果我们的技术功底好，其实编码问题是很容易解决，甚至这根本不是一个问题。
工作中接触到的数据编码主要有两种，utf-8和gbk。程序给到我们的一般是GBK编码，而hadoop和hive默认的编码是utf-8编码。有的童鞋很头疼这些编码转换。为了以后方便，将所有数据都统一转成utf-8，这是一种解决编码问题的方法。但是最近信奉少转换数据，对这种方法持保留态度。一是因为数据量很庞大，转换编码也是需要消耗资源。另外，我们转换编码并不是因为我们解决了问题，恰恰想法我们在逃避问题。因为我们没有能力解决他，所以都是一招通杀，将所有的数据都专程utf-8格式，以图省事。
文件格式主要有两种。在数据库中，主要是二进制文件存储大量的字段；而普通的日志LOG主要是文本格式存储相应的信息。
无论是gbk编码或utf-8编码；无论是二进制或十六进制文件或文本文件，只要熟悉掌握不同编码格式的数据处理，那么得心应手也就为期不远了。
压缩是为了节省存储空间，同时也利于网络传输，可是说来惭愧，因为工作中接触到的数据量比较少，也没有技术规范可以参与，很多时候都是暴力解决问题，数据的存储也不例外，需要自我检讨一下。文本数据的压缩比例一般在1：9，采用这种方式存储数据，可以节省一大笔机器开销。
归档，主要是对旧数据和不常用数据进行处理。例如数据量与时效性中说到，对于不同的数据，要根据其特点采取适当的方法处理。对旧数据归档，可以减少数据库中的数据量，提高一些即时数据的性能。
可以参考wiki上的介绍，游戏数据中经常用到序列化，因此需要了解这些概念。
数据处理中经常需要对数据进行关联。因此熟练使用inner join、left join、right join、outer join等可以方便关联数据的处理。
通常我们遇到的都是标准的行列数据，也就是指定记录与字段的分隔符，复杂点加上正则表达式，就可以处理大部分数据了。而针对非结构化数据，则不是通用的字段分割符和记录分隔符就可以了。前面说的编码、压缩、序列化、数据关联，都是处理不同数据内容的方法。说到底，针对输入流，我们都需要做到能自定义输入数据的格式，并且自定义的编码处理。