之前一直头疼游戏数据格式经常变化，但前几天看到《hadoop编程指南》的某些话。突然意识到，一直以来自己犯了很严重错误。这些话如下。通常情况下，数据格式会随时间演变，必须使当前的mapper能够适应和处理遗留的数据格式。hadoop提供MultipleInputs/MultipleOutpus类解决这些问题。
初次使用hadoop的MultipleInputs/MultipleOutpus类，是因为某项数据需求，需要在map端同时归并处理两个不同格式文件。当时只是从google搜索到可以使用这个API，也没有细想（其实这就是搜索式学习的坏处，没有认真思考，只知道what，不知道how和why），现在想想，这也是数据格式演变的特例。
刚开始工作什么都不懂，一直是拿来主义，希望数据仓库、纬度建模、ETL等业界成熟的数据处理方法能够为我所用。但现在想想，这些方法有些隐含假设：1）为了快速和方便满足数据需求，对复杂的底层数据格式进行转变成关系格式（通俗来说就是标准的行列记录）；2）数据需求比较稳定，没有太多变换。
但数据建模-->逻辑建模-->物理建模是否适合游戏呢？游戏就是一个世界，世界变化太快，数据需求和数据格式一直在演变。使用数据仓库等是否会让我们丧失数据处理方面的灵活性呢？面对未知和变化的需求，我们迎接好挑战了么？我们的思维是否被限死了，只希望得到别人的指引，而不能自己去实际思考、实际动手？
hadoop也是可以处理非结构化数据的，但现在我们的工作趋势似乎是，为了避免麻烦，非得花很大力气将非结构化数据转换成行列格式。其实hive支持复杂的structs、map、arrays等类型，某种程度上也是考虑到处理非结构化数据的需求，游戏内很多数据都是非结构化的。
改变历史数据是很困难的事情， 进行数据格式转换也是很耗资源的事情。数据格式终归是要演变的，数据需求也是会演变的。越来越偏向于不转变数据（更准确来说是转变数据的影响很少，不会牵一发而动全身），而是在实际数据需求时进行数据解析。