技术创新战略企业案例分析

奇瑞發展历程：对外开放成就了奇瑞的崛起

新华网合肥１月２５日电

题：对外开放成就了奇瑞的崛起

历经波折的奇瑞轿车终于获准上市

场按照加入世贸组织的承诺，

这意味着刚出襁褓的奇瑞

一开始就要在家门口参加“国际竞争”。

当回答关于奇瑞何以能够创造罕见的发展速喥这个问题时

瑞公司董事长兼总经理尹同耀对记者说，

对外开放是最重要的发展环境

奇瑞在发展之初就必须跨越“国际化”的高门槛，

在经济全球化的背景下寻求和

大数据技术对处理大批量数据和茬分布式计算上较传统技术优势明显。那么借大数据技术在处理航空数据上是否有用武之地？本文接下来讨论使用大数据组件来处理航空数据

航空数据有的数据以csv文件格式存储，统计分析航空数据有很多潜在价值尽管有可观的分析价值，但这里仍跟大数据技术扯不仩关系所以，笔者准备从案例的角度来尝试讨论下自己的观点。

假设一个航空公司的某业务一天生成100个csv一个月生成3000个csv，在使用csv文件數据时遇到一个问题: 

这些csv怎么存？怎么用

这个问题比较宽泛，我们可以拆解为怎么存，可以解析为怎么存和好不好存？怎么用可以解析为能不能用？和好不好用其实还可以继续拆解：

从图中看，如果“一般文件系统”不能胜任可以使用hadoop hdfs文件系统，或鍺其它分布式文件系统这类分布式文件系统首先能解决容量的问题。既是文件系统文件系统该有的功能也都具备，所以使用hadoop hdfs是个不错嘚选择

如果不使用文件系统存储，数据库no sql数据库也是一个选择。mysqloracle存csv并不常见，no sql 存csv也不常见不确定后果，不是一个好的选择如此┅来，可能也会排除hivehbase等no sql数据库。但另一方面不常见的原因是，数据库存储的数据单元更小而已如能把csv拆分，也能存csv那么，这里的問题是如此一来，处理csv的方式出现了分水岭：

选择哪一边是很困难的。基于改动越小越好的原则选择“文件系统”更好。基于拓展性越多越好的原则第二种更好。

那么在使用文件读取工具上，怎么选择大数据组件如果“一般工具”能胜任，就使用一般工具好了这里的“一般工具”可以是csv读写工具，也可以是csv计算工具实际上，不光读写功能这里显然是做了过度简化。据笔者个人的了解目湔市面上这一类工具很多，也很优秀如果我们强制区分“一般性工具”和“大数据组件”，大数据组件可选的有：

相比较大数据组件茬处理csv上，也不是很差优点也很多，只是用起来需要环境等前提。

那么性能，效率怎么样它们都是开源产品，在不断完善在往恏的方向上。那么选哪一种大数据组件呢

首先是比较了。市面上也有比较分析结果总之，比较结果的共识是：

这里谈点个人理解需偠注意的是，“需求点”的成本和收益比如“百度搜索”，它其实是查询功能这个需求点，是查询这个点价值巨大，所以值得整个公司为它投入巨大各种高科技都往上堆。

既然前面说到使用“大数据组件”有前提这就牵扯到好不好用上面了。实际上这个问题是這样的：

问题这么多，这并不好决定

（2）大数据组件优缺点分析

在一个数据处理流程中，本来做技术的很难掌控铨局更何况做小弟的。在组件选型上首先，是推荐spark平台原因是，spark是后来着后来者会吃掉前者。这是玩笑话但实际上，确实如此spark的特点:

技术也并不是越先进越好，况且笔者也没有掌握全这么多技术那么，支持spark平台的组件如何选型首先看下常用的大数据组件的優缺点：

实际上，以上列出的只是其中几个常用的组件其实，笔者还漏掉了一些组件而这些，根本不是需要犹豫的而是必须选择的。比如：

上面列举了一些大数据的组件它们各有优缺点。事实上随着技术迭代（比如hbase已经迭代到V1.2了），它们的缺点越来越少

如果是离线处理csv文件，那么以下搭配都是可行的：

分布式文件系统+”一般工具”+关系数据库

分布式文件系统+spark core+”一般工具”+关系数據库

说到这里可能有人觉得，这样看来组件选型也不是很困难。

其实前面讲了存取，读写计算工具，还有一样没有讲到就是：數据分析工具。对于“数据分析”而言大数据组件也很多，比如

hadoop中用于处理数据分析程序的高级查询语言。

一种框架可允许高效的查询翻译，其中包括异构性及联合性数据的查询

高性能交互式的SQL，可访问所有的Hadoop数据

由Dremel授意的交互式分析框架。

这些名字都不知道怎麼念的分析组件其实可以发现一个特征，它们都在尽力模仿SQL的查询方式另一方面，由于多数组件都是Apache基金下因此接入它们也是可行嘚，至少java语言的版本是可行的

至于选哪种组件，笔者比较推荐的有：

（4）”是否好用“的问题分析

那么回过头来，再看看“是否好用”的问题：

比如说“结果准吗”这个问题这里面其实还有很大部分是指在数据除噪上的工作好不好，这就涉及规则校验-数据质量评价

单纯从技术角度看，笔者的理解按照已知的规则进行，数据准确性是很高的

再比如“执行结果稳定吗”这个问题，这也是一个复杂的问题如果过度简化的话，就是指这个大数据组件搭配起来的处理系统是否稳定乐观的是，基于分布式和高可用的特性它当然基本是稳定的。

还有其它的问题都是复杂的问题。笔者的理解这些不会是能够完全解决的问题。通常的做法是先穷尽鈳能的问题，然后解决主要的问题其它的，笔者也说不清楚

（5）可能的搭配和总结

至此，笔者分析了在数据存取+读寫+计算+分析上常见的大数据组件的应用的可能，我们可以总结出一个可行的组件搭配：

分布式文件系统+”一般工具”+关系数据库+SQL分析

从鉯上的几个搭配来看有几点似乎比较明显：

（1）似乎关系数据库是一个存在感很强的部分。是的关系数据库本身很优秀。

（2）在没有鼡到分布式文件系统的时候no sql数据库存在感也比较强。笔者觉得在这种情况下，redisehcache，slorelastic search 将有很强的作用。

（3）似乎把它们全部加起来也昰一个很好的搭配是的，但是有多好呢这个笔者反而不清楚。

那么这样的组件搭配，效果怎么样呢从笔者的实际应用经验看，

（1）能很大提高数据处理能力至少以前是不可能的，低效的

（2）按目前的应用经验来看组件之间能互相衔接，流程能走通

（3）复杂度比較高调优空间还有很大

最后，尽管上面分析了一些组件的优缺点但仍停留在比较浅的层面，仍然不能在“是否值得使用”的问题上有所解答笔者也试着分析了几个问题的本质，不过看起来真正的情况是，还得实践然后才有更多的体会。

对一些飞行培训学校或航空公司有关飞机飞行的过程，会构建一些模型来做分析这个在教学和研究中有时会遇到，其复杂度会比类SQL查询要高

从谷歌学术中一些公开的论文或学术资料中，可以找到比如：

（1）《飞机排班数学规划模型》

（2）《基于航空公司成本最小化的飞机排班问题模型与算法》

（3）《飞机的航迹模拟仿真算法》

（4）《民用飞机航迹预测关键技研究》

（5）《基于遗传算法的下降阶段飞机油耗分析与研究》

（6）《基於深度学习的航空发动机故障融合诊断》

（7）《航空发动机温度过热故障挖掘模型仿真》

从上面的模型也好算法也好，看起来模型千差万别。

大概分析下案例二的问题：

面对千差万别的模型如果有这样的问题： 
即同样的数据源能否在不同模型下都能使鼡？ 


提供通用的噪点小的数据源。

那么面对这种需求，大数据组件应该怎样选型呢看上去，该问题像是无解的但仍可以做一些定性分析。

来看下大数据组件需要面对的问题：

（2）需要重点解决的问题

从上面来看我们可以重点关注这几点：

（2）臨时存储空间大？

（3）是否提供管理工具

目前，原始数据源是csv文件csv格式，这种类型也不差格式简洁，容易解析直接使用，最省事嘚但存在问题：

1.颗粒度比较的，意味着无效数据较多增加性能消耗。
2.此外数据不够集中，无效的数据导致分析异常且难排查。

那麼转成：mysql表结构或hbase结构？

因为这2中结构是关系表结构和K-V结构的代表同类产品还有：

将csv转成另一种结构的数据，这样新数据就不是原始数据了。自然对分析结果有影响这会带来很大的问题：分析后的结果数据面临信任危机！

那么，只有减小这种影响方式比如有：

（1）转换过程中只简单处理或不处理。

（2）把csv格式转成csv近亲格式比如csv是逗号分隔，转成分号分隔

当然，这样的方式也会遇到困难比如，数据本身的类型int，floatstring，double等

在java 中，类似“泛型”的方式可以处理不确定数据类型的数据。借助于泛型可是生成包容不同数据类型嘚List数据，这是一个中间数据格式

或是json数据格式，它近年被大量采用于各个领域互联网也好，大数据也好关系型数据库oracle和mysql也都支持这種数据格式。足以说明它的优势

回到上面的问题：数据格式统一？

这个问题本身意味着格式转换不可避免笔者的见解是：

（1）就千差萬别的模型而言，没有通用的数据格式

（2）要转，就转成一个能很方便转成其它格式的数据格式

再来看第二个问题：临时存储空间大？

这又为什么呢据笔者了解，模型训练也好分析也好，通常是基于大样本这意味着数据源很大，中间计算产物也大

比如说，有这樣的计算需求：

查询一年中某几个参数的所有数据

（1）模型每次要完整执行一次，才会出结果

（2）模型执行一次下次可以只执行一部汾就可出结果

这第二种可能，显然是重复利用了中间计算产物第二种可能看起来，耗时更小可复用性也比第一种要高，那么是不是更優秀呢

笔者觉得，不知道但笔者更倾向于第一种。因为中间计算产物的可复用性到底高不高一个模型可以调节的参数通常很多，中間计算产物也很多如果能重复利用越多越好，但一来需要甑别的环节；而来，可复用的次数高不高很难做评估。

实际上依笔者的看法，这个实际上是一个计算能力的问题

原因就是，如果计算够快并不期望能节省多少资源。

目前spark计算能力足够强除了本身的计算能力，spark应用的思想之一是：如果一个计算过程有5种中间计算产物那么每个计算步骤后，都只会有一种中间计算产物原来的中间计算产粅被覆盖，而且分布式保存在各节点上直到最后一步，才真正计算并把结果数据汇集到主节点。

这种 思想使得计算很高效，但同样占用内存

对此，笔者觉得如果想不出更好的点子，就往目前的点子上面靠所以，针对“临时存储空间大”的需求使用spark core组件，并使鼡效果较好的调优手段是比较好的选择。

第三（3）是否提供管理工具？

模型分析需要的样本很大一个好的管理工具能大大方便大批量数据的管理。据笔者了解apache 基金下有一些好的组件提供管理工具，比如：

提供较好的元数据管理和数据安全管理

提供很好的列式存储，提供数据压缩同步等特性。

综上为了解决需求：提供通用的，噪点小的数据源

笔者分析了一些数据处理方式，以筆者的见解推荐的大数据组件搭配有：

总之，第一关系数据库是必要的，一些元数据还是要放在关系数据库；第二hbase这里的作用，除叻本身作为列式数据库其实，笔者觉得还有需要研究的地方但仍是一个推荐的组件。