设计中避开这些坑，一个实用的机器学习框架就会诞生

No Free Lunch是监督学习领域著名的定理，指的是没有可以解决所有问题的完美机器学习模型。不同目标场景要采用不同的机器学习算法。所以机器学习框架还需具备算法开发的友好性。

人工智能需要对算法和业务问题都很精通的数据科学家，但好的数据科学家是稀缺的，因此机器学习解决方案要尽可能的“智能化”，降低对数据科学家对依赖。

1.      计算

对比于ETL相对“简单”的运算，机器学习算法对数据的运算更复杂，比如一些非线性模型需要密集的计算。所以实际中，不仅要考虑到不同计算资源的特性，同时还要调整计算模式，降低因分布式计算给通讯、同步、灾备等带来的overhead。

2.     通讯

很多机器学习算法在计算过程中会频繁使用到全局或者其他节点的信息，对网络吞吐和通讯延迟的要求要远高于ETL任务。同时，很多机器学习任务对于一致性的要求要低于ETL任务，所以在系统的设计上可以使用放松的一致性要求。

3.     存储

ETL处理的是各种来源不同的数据，其中反复迭代运算较少。而机器学习算法反复迭代运算很多，有大量不断擦写的中间数据产生，对存储的使用效率、访问效率有着更高的需求。

4.     灾备和效率的权衡

与ETL计算任务不同，机器学习计算任务流程相对复杂，中间状态较多，在较细的粒度上进行容灾，会增加执行过程中的额外开销。因此在容灾策略和容灾粒度上，机器学习计算任务和ETL 计算任务之间的权衡点不一样。

相同的机器学习算法可能会在不同的资源、不同的环境下被使用，因此机器学习算法系统本身要能够做更好的抽象和设计，屏蔽底层资源的差异性，使开发部署更为方便。

机器学习系统要能够便于集成部署在实际业务系统中。同时，因为多种多样的ETL平台会产生机器学习所需要的数据，所以机器学习系统要能够开放地对接已有的业务ETL、决策系统。

大规模分布式机器学习系统涉及的环节很多，计算逻辑复杂，因此整个系统架构设计的清晰度、执行过程的可理解性、执行的可追踪性、实际系统的可运维性都是非常重要的。同时，要在不同的数据规模下，权衡分布式overhead和收益。 

当今巨头科技公司纷纷推出开源机器学习框架，很大程度上降低了人工智能的研究门槛。但目前这些备受追捧的开源框架，真能满足企业完成实际复杂业务的挑战吗？答案可能并不乐观。因为，从根本上来说，目前最为流行的计算框架如Hadoop、Spark，其重点任务大多是ETL类计算。前文提到过，机器学习的计算任务相比于ETL计算有很多不同之处。此外，一些算法框架比如tensorflow等，比较注重研究上的易用性，算法上偏重于深度神经网络一类算法，从而在效率上有所舍弃。而另外一些注重生产应用的算法框架，特别是分布式框架，在算法二次开发上又捉襟见拙。

1.1   计算

根据计算硬件的不同特性，GDBT采用不同版本的本地计算，尽可能利用好加速指令。同时考虑到不适所有任务都需要分布式执行，所以同时对分布式、单机运行都尽可能做到最优。

1.2   存储 

不同的存储设备的价格、速度和容量不一样，GDBT要能适应不同的存储配置、最优化存储访问速度、和存储使用效率。

1.3   网络

通过合理设计计算模式，调配网络通讯，GDBT最优化网络通讯延迟、网络使用效率。

1.4   高效灾备

因为机器学习算法中间状态很多，为避免overhead问题，GDBT的灾备更加偏重于机器学习算法的核心参数。同时基于不同计算规模，制定不同灾备策略。

1.1   算法智能

机器学习中特征工程和模型调参需要数据科学家对机器学习算法和实际业务有较深理解。因此，先进的机器学习系统需要提供自动或半自动特征工程，例如GDBT就提供包括自动特征生成、自动特征选择、特征自动组合在内的自动特征工程，以及自动模型调参。

1.2   运行智能

根据不同应用场景，GDBT可以自动适配运行方式，获得更高的运行效率。

GDBT提供工业级的开发者易用性，尽量对算法开发者屏蔽底层细节，提供对机器学习组件的良好包装，能够方便实现机器学习所需的各种分布式模式。在GDBT上，只需要数百行代码，就可以实现逻辑回归、矩阵分解等算法的分布式版本。

GDBT支持多种平台，例如Yarn，Hadoop MR、MPI等，并方便跨平台迁移。它能够实时监控运行状态和进度、方便调试与错误跟踪。

通过重新设计、深度整合现有模型和算法，合理设计计算模式和流程，GDBT能够提供更加高效的符合实际应用场景的算法，比如GDBT上的算法能够兼顾离散特征和连续特征，最优化I/O和计算资源的使用效率。通过重新设计、深度整合现有模型和算法，合理设计计算模式和流程，GDBT能够提供更加高效的符合实际应用场景的算法，比如GDBT上的算法能够兼顾离散特征和连续特征，最优化I/O和计算资源的使用效率。