当前位置：
构建机器学习系统的20个经验教训
36大数据 　
核心提示：
数据科学家对优化算法和模型以进一步发掘数据价值的追求永无止境。在这个过程中他们不仅需要总结前人的经验教训，还需要有自己的理解与见地，虽然后者取决于人的灵动性，但是前者却是可以用语言来传授的。
数据科学家对优化算法和模型以进一步发掘数据价值的追求永无止境。在这个过程中他们不仅需要总结前人的经验教训，还需要有自己的理解与见地，虽然后者取决于人的灵动性，但是前者却是可以用语言来传授的。最近Devendra Desale就在KDnuggets上发表了一篇文章，总结了Quora的工程副总裁Xavier Amatriain在Netflix和Quora从事推荐系统和机器学习工作时所总结的20条经验教训。
更多的数据 & 更好的模型
并不是数据越多结果就越好，高质量的数据才能产生高质量的结果。多并不意味着好，事实上，有些情况下较少的数据反而效果更好，因此数据要适量，质量要高。
可能并不需要所有的
组织可能积累了不同种类的大数据，但是并不是每一个场景都会用到所有的数据。大部分情况下，通过一些样本数据就能获得比较好甚至是比使用全量数据更好的效果。
有时候更复杂的模型并没有带来任何提升，但这并不意味着就不需要它了
如果将一个线性模型的特征数据作为另一个更复杂模型(例如非线性模型)的输入，而复杂模型产生的结果并没有任何提升，那并不意味着这个复杂模型就毫无意义。因为通常情况下只有更复杂的特征数据才需要更复杂的模型，对于简单的特征数据复杂模型往往难以发挥出自身优势。
学会处理展现偏见
系统通常会将那些预测的比较正确的结果展示给用户，用户会选择性的查看，但是用户不看的那部分并不一定就毫无吸引力。更好的选择是通过关注模型或者MAB分析用户的点击概率，合理地呈现内容。
认真思考训练数据
构建训练和测试数据的时候需要充分考虑结果和各种不同的场景。例如，如果要训练一个预测用户是否喜欢某部电影的分类器，那么产生数据的可能场景包括：用户看完电影并给出了一星的评价，用户看了5分钟、15分钟或者一小时之后离开，用户再次查看电影等，如何选择这些数据是需要经过深思熟虑的。
UI是用户与算法通信的唯一方式
系统通过UI展现算法结果，用户通过UI提供算法反馈，它们应该是相互对应的关系，任何一个发生变化另一个也需要进行改变。 数据和模型是否已经足够好了?
要有正确的评估方法
产品决策始终应该是数据驱动的。对于不同的问题，要选择正确的评估方法，例如，通过A/B测试来衡量不同特征数据，不同算法的优劣;通过脱机测试使用 (IR) 度量测试模型的性能。
分布式算法重要，但是理解它的分布式程度更重要
分布式/并行算法分三级：第一级针对总体的每一个子集，第二级针对超参数的每一种组合，第三级针对训练数据的每一个子集，每一级都有不同的要求。
慎重地选择超参数
要选择正确的度量标准自动化超参数的优化。 有些事情能线下做，有些不能，有些介于两者之间，为此需要支持多层次的机器学习。
隐式信号几乎总是打败显式信号
许多数据科学家认为隐式反馈更有用。但真的是这样么?实际上有些情况下结合不同形式的隐式和显式信号能更好地表示长期目标。
　模型会学习你教给他的内容
机器学习算法并不是一个随意的过程，它的每一步都涉及到科学方法。模型要从训练数据、目标函数和度量中学习。
有监督的 + 无监督的学习
开发模型的时候不能简单地选择有监督的或者无监督的学习，它们各有长处，适用场景不同，用户需要根据具体情况同时迭代地使用它们，通过两种方法的融合获得更好的效果。
所有的事情都是一种集成(Ensemble)
使用机器学习的大部分应用程序都是一个集合体。你可以添加完全不同的方法(例如CF和基于内容的方式),你也可以在集成层使用许多不同的模型(例如LR、GDBT、RF和ANN)。
一个模型的输出可能是另一个模型的输入
确保模型的输出具有良好的数据依赖关系，例如可以容易地改变值的分布而不影响依赖它的其他模型。要尽量避免反馈循环，因为这样会在管道中造成依赖和瓶颈。另外，机器学习的模式设计也需要遵循最佳的软件工程实践，例如封装、抽象、高内聚和松耦合。
特征工程的失与得
良好的机器学习特征可重用、可转换、可解释并且可靠。捕获的特征越好，结果越精确。为了量化数据的属性必须将维度翻译成特征。
机器学习基础设施的两面性
任何机器学习基础设施都需要考虑两种不同的模式。模式1：机器学习实验需要扩展性、易用性和可重用性。模式2：机器学习产品不仅需要模式1的特性，还需要性能和可伸缩性。理想情况下，应该保持这两种模式尽可能地相近。
要能回答有关于模型的问题
必须能够向产品所有者解释模型的行为，知道如何使用模型，它需要哪些特征，导致失败的原因是什么;同时还需要知道产品所有者或投资者的期望，能够向他们介绍模型为产品带来了什么价值。
不需要分发机器学习算法
Hadoop/Spark这些&容易的&分布式计算平台也有一些陷阱，例如成本和网络延迟，实际上有些情况不使用它们也能很好的完成工作，通过智能数据样本、离线模式以及高效的并行代码等方法训练模型所花费的时间甚至比这些分布式平台要少的多。
数据科学 vs. 机器学习工程不为人知的故事
拥有强大的能够挖掘数据价值的数据科学家是非常值得的。但是既懂数据又有扎实工程技能的数据科学家非常稀少，通常情况下，构建数据科学家团队和机器学习工程团队并让他们通力配合才是比较好的方案。
关注官方微信：或微信号： 我们将定期推送IDC产业最新资讯
第十届中国IDC产业年度大典（IDCC2015）于-7日在北京国家会议中心盛大开幕。三天议程，8000人规模、百余位演讲嘉宾。
Copyright 2001 - 2013 Chinaitlab Group All Rights Reserved. 京公网安备14号您的位置：
大数据如何更好的驱动商业模式、用户体验和精细化运营？
36大数据专稿，转载请标明出处及作者。在上文（《）我们已经详细阐述了互联网思维UFO模型。本文将研究互联网思维和大数据的关系。互联网思维UFO模型中的U代表User experience，即极致用户体验，其对应的方向是产品设计；F代表Freemium，即免费商业模式，其对应的方向是商业模式研究和设计；O代表精细化运营，其对应的方向是产品运营，而大数据在这三个方向的应用起到不同程度的作用。其中，大数据与F（免费商业模式）及U（极致用户体验）关联度或者驱动度中等，与O（精细化运营）关联度或驱动度最高。大数据如何支撑更好的商业模式？好的免费商业模式要求：（1）通过免费或者“利润超薄”的产品或服务发展大规模的用户，形成用户大盘；（2）产品可以做到通过互联网方式每天有机会与用户发生接触或联系。即前文提到的例子，如果你把手机卖给一个人，就不跟他“联系”了，这个人并不是你的用户，但你通过某种方式每天跟他“联系”，如你在手机上提供软件服务，让这个人跟你发生“联系”，他就是你的用户；（3）产品或服务是否可以做到版本迭代升级。很多人认为传统领域的产品或者服务比较难提供“版本”升级，但其实这只是受传统思维方式所阻。以汽车为例，我们常常认为已经卖给客户的车不存在版本升级的概念，而特斯拉做到了：特斯拉在2014年12月底宣布了计划把 Tesla Roadster 升级，Roadster 将会被换上一组新的电池，对比原本那组电池来说，新电池可以在同样的体积下提供额外 31% 的能量，另外，Roadster 还会换上新的空气动力学套件，令到车身的风阻系数由 0.36 减至 0.31，还有就是会换上滚动摩擦系数更低的轮胎。我们在设计好的免费商业模式的时候，要充分考虑以上三点。但大数据目前在商业模式设计、商业模式研究、创新商业模式研究这方面的能力还比较弱，目前在中国还没看到成功的利用大数据的智慧来辅助设计商业模式的案例，也许是因为计算机目前的智慧还没达到设计商业模式的能力高度。但是我们可以通过大数据的方法进行行业监测以及进行创新监测，从而可以辅助战略规划人员来进行商业模式的设计。比如我们可以通过爬虫技术的手段采集互联网上的国内外行业发展动态、行业发展趋势、分析师文章、最新专利申请情况、相关最新产品上市情况等来辅助战略规划人员进行相关的行业分析和创新分析，以辅助设计商业模式。总的来说，大数据在免费商业模式设计方面的能力还比较弱。但如果大数据作为商业模式中的一个引擎，即大数据作为产品的一个引擎，就有可能促进商业模式的升级。打个比方，把一个传统的商业模式比作一辆汽车，这辆汽车的引擎是2.0的排量，如果你在设计商业模式的时候把大数据很好的融入商业模式中，那么这辆2.0排量的汽车就有可能升级为2.0T，即变成带涡轮增压的发动机，动力将更猛。如健康领域，如果是一个销售传统血压计的商业模式，投资人对这种商业模式并不会很关注，但在血压计加上大数据的能力，即做智能血压计，可以远程监控父母的血压情况，及时进行病情预警，这种加入的大数据的商业模式就会比较有投资价值。总的来说，如果把大数据作为一种研究能力来支撑商业模式研究，那么其作用相对较低，只能在行业监测和创新监测起一些作用；但如果把大数据作为一个引擎嵌入到商业模式中，嵌入到产品中，其价值则非常大。大数据如何更好的驱动用户体验？在互联网思维UFO模型中，我们提到做极致用户体验一个很重要的SIM原则：S指Simple（简单），少即是多的“极少主义”；I指iteration（迭代），即小步快跑，快速迭代。M指micro-innovation，微创新。以上三方面均可以通过大数据来支撑。通过大数据我们可以监测一个产品是否做到足够的简单（simple），我们可以基于大数据构建很多的用户体验监测模型。如用户行为的漏斗模型，我们可以把用户使用产品的关键触点（touchpoint）定义出来，监测每个触点之间的转化率。如电商购物，用户进入首页、查看商品产品详情、把产品放到购物车、购买以及支付等是关键用户关键触点，通过监控各环节之间转化率来以及从最开始的接触点到最终的接触点的转化率来衡量产品的体验是否做的足够好，足够简单。我们相信，如果用户完成一个产品操作任务，用的步骤越少，转化率相对就越高。通过大数据的手段，我们可以帮助更好的快速迭代，以提升效果。尤其是利用A/B测试方法以及灰度发布实时监测手段。A/B 测试简单来说，就是为同一个目标制定两个方案或版本（比如两个页面），让一部分用户使用 A 方案，另一部分用户使用 B 方案，通过及时的统计使用效果数据如点击率等，看哪个方案更符合设计目标。当然，在实际操作过程之中还有许多需要注意的细节，在此就不赘述。Google很多新的产品上线或者功能优化上线前都要进行A/B测试。对于常规的A/B测试，同一个目标一般要做两种方案，很多互联网公司为了简化，一般只做一种方案，进行灰度上线（即只抽取一小部分用户进行产品发布）以后，再通过大数据实时监测看这个效果和之前版本的效果对比，如果效果不如之前的版本，新版本就放弃正式发布。通过大数据的手段也可以帮助产品实时产品微创新的效果。360公司的周鸿祎先生说过，口碑是衡量创新的标准，因为给用户带来强烈体验的东西一定能形成口碑。通过大数据可以很好的及时监测产品口碑的情况。通过大数据爬虫的手段，我们可以抓取产品在互联网上的评价，如抓取微博、论坛、电商评论等，通过自然语言处理的手段和语义分析，对评论等非结构数据进行处理和挖掘，计算产品的推荐度，实时掌握产品口碑情况；另一方面，我们也可以通过大数据的手段，实时发现产品问题点，这样会对产品的改进非常有帮助。在很多产品导向型的大型互联网企业，都会要求若1小时内有3人同时反映一个问题，就定义为BUG，需要在24小时内必须立即解决。基于大数据的手段可以在产品问题的及时发现和定位上非常有帮助。大数据如何更好的驱动精细化运营？好产品是运营出来的，互联网产品需要不断运营、持续打磨。产品运营的目的是为了扩大用户群、提高用户活跃度、寻找合适商业模式并增加收入。成功的互联网运营要做到精细化运营，成功的精细化运营需要大数据支撑。大数据和互联网思维在此方面关联度最高。所以，企业在大数据的应用场景上，一定是要优先考虑如何通过大数据进行精细化运营，以驱动更好的运营效率和效果的提升。但值得注意的是，企业在这方面的建设一定要考虑如何让数据分析人员、算法人员与产品运营人员更好的融合在一起工作，否则大数据将在产品运营环节比较难起到理想的作用。因为很多公司的运营人员并不是非常了解大数据在哪些运营的环节可以用到大数据；同时，数据分析和算法人员不能很好的理解业务，也不知道有哪些运营策略和场景，也较难为产品运营人员提供好的支持。我们的建议是如果数据分析人员和算法人员能够定期参与产品运营的一些例会，甚至如果有可能，可以让数据分析和算法人员与产品运营人员坐在一个相邻的办公区域一起工作。基于大数据可以更好的做精细化运营监控、更准确的做用户细分、更准确的进行个性化推荐、更合理的进行营销推广效果的评估、更有效的进行用户生命周期管理以及基于用户生命周期进行相关的营销和运营策略。具体方面如下：在精细化运营监控方面，我们需要进行关键数据体系梳理和构建，在此基础上通过智能化模型开发出来的数据产品，监控关键数据的异动，并可以快速定位数据异动的原因，辅助运营决策；通过基于大数据的方法进行用户细分，基于大数据可以找出更好的细分维度，并对用户做更好区隔，以辅助产品运营人员做更加准确的用户细分，并洞察每个细分人群的兴趣爱好和消费倾向，对每类用户分别进行有针对性的策划和运营活动。通过数据挖掘的手段进行用户生命周期管理，我们可以可做到实时对不同生命周期的用户进行实时标记和预警，并把有效的活动当成商品一样及时的推送给不同生命周期阶段的客户。通过大数据的方法，我们可以实现对不同通过渠道的效果评估。如果只看一些表面的数据，如广告的点击率，是非常难衡量不同推广渠道的真正效果。如果把用户的渠道行为和后续产品行为（即通过渠道获取的用户在产品上的各种使用行为）进行打通跟踪，在此数据基础上构建渠道质量评估模型，将能够更好的发现渠道的真正质量，或者更直接的，可以发现推广渠道的究竟有多少是虚假的流量。通过利用基于大数据进行有针对性的用户画像，并通过用户画像数据、用户行为和偏好数据，结合个性化推荐算法实现根据用户不同的兴趣和需求推荐不同的商品或者产品，通过算法真正的实现“投其所好”，以实现推广资源效率和效果最大化。总之，互联网思维和大数据有着紧密的关系。互联网思维背后代表的是商业模式、产品设计、产品运营，而大数据在不同程度的支撑或者驱动这三方面。如果大数据能够作为商业模式的一部分或者更准确的说是作为企业产品的一个引擎，那么企业的能量和想象空间将会更大。而大数据在产品设计和运营环节都能起到不同程度的左右，作用最为明显的是在驱动产品的精细化运营。我们希望企业相关决策层在运用大数据的时候更好的了解大数据应用的优先级和应用场景，更好的发挥大数据的价值。文：傅志华关于作者：傅志华先生曾为腾讯社交网络事业群数据中心总监以及腾讯公司数据协会会长。在腾讯前，曾任DCCI互联网数据中心副总裁。傅志华先生现就职于某美国上市互联网公司大中心，同时任中国信息协会大数据分会理事和中国互联网协会数据分析研究组专家。如果对大数据在电信、金融和互联网的应用感兴趣，欢迎关注与作者同名的微信公众号“傅志华”。End.
作者的其他文章
关注作者的人当前Hadoop技术蓬勃发展，用于解决大数据的分析难题的技术平台开始涌现。Spark凭借性能强劲、高度容错、调度灵活等技术优势已渐渐成为主流技术，业界大部分厂商都提供了基于Spark的技术方案和产品。根据Databricks的统计，目前有11个商业的Spark版本。
在使用Spark作出计算平台的解决方案中，有两种主流编程模型，一类是基于Spark API或者衍生出来的语言，另一种是基于SQL语言。SQL作为数据库领域的事实标准语言，相比较用API(如MapReduce API，Spark API等)来构建大数据分析的解决方案有着先天的优势：一是产业链完善，各种报表工具、ETL工具等可以很好的对接;二是用SQL开发有更低的技术门槛;三是能够降低原有系统的迁移成本等。因此，SQL语言也渐渐成为大数据分析的主流技术标准。本文将深入解析Inceptor的架构、编程模型和编译优化技术，并提供基准测试在多平台上的性能对比数据。
1. Inceptor架构
Transwarp Inceptor是基于Spark的分析引擎，如图1所示，从下往上有三层架构：最下面是存储层，包含分布式内存列式存储(Transwarp Holodesk)，可建在内存或者SSD上;中间层是Spark计算引擎层，星环做了大量的改进保证引擎有超强的性能和高度的健壮性;最上层包括一个完整的SQL 99和PL/SQL编译器、统计算法库和机器学习算法库，提供完整的R语言访问接口。
图1：Transwarp Inceptor架构图
Transwarp Inceptor可以分析存储在HDFS、HBase或者Transwarp Holodesk分布式缓存中的数据，可以处理的数据量从GB到数十TB，即使数据源或者中间结果的大小远大于内存容量也可高效处理。另外Transwarp Inceptor通过改进Spark和YARN的组合，提高了Spark的可管理性。同时星环不仅仅是将Spark作为一个缺省计算引擎，也重写了SQL编译器，提供更加完整的SQL支持。
同时，Transwarp Inceptor还通过改进Spark使之更好地与HBase融合，可以为HBase提供完整的SQL支持，包括批量SQL统计、OLAP分析以及高并发低延时的SQL查询能力，使得HBase的应用可以从简单的在线查询应用扩展到复杂分析和在线应用结合的混合应用中，大大拓展了HBase的应用范围。
2. 编程模型
Transwarp Inceptor提供两种编程模型：一是基于SQL的编程模型，用于常规的数据分析、数据仓库类应用市场;二是基于数据挖掘编程模型，可以利用R语言或者Spark MLlib来做一些深度学习、数据挖掘等业务模型。
2.1 SQL模型
Transwarp Inceptor实现了自己的SQL解析执行引擎，可以兼容SQL 99和HiveQL，自动识别语法，因此可以兼容现有的基于Hive开发的应用。由于Transwarp Inceptor完整支持标准的SQL 99标准，传统数据库上运行的业务可以非常方便的迁移到Transwarp Inceptor系统上。此外Transwarp Inceptor支持PL/SQL扩展，传统数据仓库的基于PL/SQL存储过程的应用(如ETL工具)可以非常方便的在Inceptor上并发执行。另外Transwarp Inceptor支持部分SQL 2003标准，如窗口统计功能、安全审计功能等，并对多个行业开发了专门的函数库，因此可以满足多个行业的特性需求。
2.2 数据挖掘计算模型
Transwarp Inceptor实现了机器学习算法库与统计算法库，支持常用机器学习算法并行化与统计算法并行化，并利用Spark在迭代计算和内存计算上的优势，将并行的机器学习算法与统计算法运行在Spark上。例如：机器学习算法库有包括逻辑回归、朴素贝叶斯、支持向量机、聚类、线性回归、关联挖掘、推荐算法等，统计算法库包括均值、方差、中位数、直方图、箱线图等。Transwarp Inceptor可以支持用R语言或者Spark API在平台上搭建多种分析型应用，例如用户行为分析、精准营销、对用户贴标签、进行分类。
3. SQL编译与优化
Transwarp Inceptor研发了一套完整的SQL编译器，包括HiveQL解析器、SQL标准解析器和PL/SQL解析器，将不同的SQL语言解析成中间级表示语言，然后经过优化器转换成物理执行计划。SQL语言解析后经过逻辑优化器生成中间级表示语言，而中间表示语言再经过物理优化器生成最终的物理执行计划。从架构上分，逻辑优化器和物理优化器都包含基于规则的优化模块和基于成本的优化模块。
为了和Hadoop生态更好的兼容，Inceptor为一个SQL查询生成Map Reduce上的执行计划和Spark上的执行计划，并且可以通过一个SET命令在两种执行引擎之间切换。
图2：SQL编译框架
3.1 SQL编译与解析
Transwarp Inceptor的SQL编译器会根据输入的SQL查询的类型来自动选择不同的解析器，如PL/SQL存储过程会自动进入PL/SQL解析器并生成一个Spark RDD的DAG从而在Spark平台上并行计算，标准SQL查询会进入SQL标准解析器生成Spark或Map Reduce执行计划。由于HiveQL和标准的SQL有所出入，为了兼容HiveQL，Transwarp Inceptor保留了HiveQL解析器，并可以对非标准SQL的Hive查询生成Spark或者Map Reduce执行计划。
3.1.1 SQL 标准解析器
Transwarp Inceptor构建了自主研发的SQL标准解析器，用于解析SQL 99 & SQL 2003查询并生成Spark和Map Reduce的执行计划。词法和语法分析层基于Antlr语法来构建词法范式，通过Antlr来生成抽象语义树，并会通过一些上下文的语义来消除冲突并生成正确的抽象语义树。语义分析层解析上层生成的抽象语义树，根据上下文来生成逻辑执行计划并传递给优化器。首先Transwarp Inceptor会将SQL解析成TABLE SCAN、SELECT、FILTER、JOIN、UNION、ORDER BY、GROUP BY等主要的逻辑块，接着会根据一些Meta信息进一步细化各个逻辑块的执行计划。如TABLE SCAN会分成块读取、块过滤、行级别过滤、序列化等多个执行计划。
3.1.2 PL/SQL 解析器
PL/SQL是Oracle对SQL语言的模块化扩展，已经在很多行业中有大规模的应用，是数据仓库领域的重要编程语言。
为了让存储过程在Spark上有较好的性能，PL/SQL解析器会根据存储过程中的上下文关系来生成SQL DAG，然后对各SQL的执行计划生成的RDD进行二次编译，通过物理优化器将一些没有依赖关系的RDD进行合并从而生成一个最终的RDD DAG。因此，一个存储过程被解析成一个大的DAG，从而stage之间可以大量并发执行，避免了多次执行SQL的启动开销并保证了系统的并发性能。
解析并生成SQL级别的执行计划
解析SQL的依赖关系并生成DAG, 再根据各个SQL的执行计划来生成最终存储过程的Spark RDD DAG
3.2 SQL优化器
Transwarp Inceptor使用Spark作为默认计算引擎，并且开发了完善的SQL优化器，因此在大量的客户案例性能测试中，Transwarp Inceptor的性能领先Map Reduce 10-100倍，并超越部分开源MPP数据库。SQL优化器对平台性能的提升居功至伟。
3.2.1 基于规则的优化器(Rule Based Optimizer)
目前为止，Transwarp Inceptor共实现了一百多个优化规则，并且在持续的添加新的规则。按照功能划分，这些规则主要分布在如下几个模块：
文件读取时过滤
在文件读取时过滤数据能够最大化的减少参与计算的数据量从而最为有效的提高性能，因此Transwarp Inceptor提供了多个规则用于生成表的过滤条件。对于一些SQL中的显示条件，Transwarp Inceptor会尽量将过滤前推到读取表中;而对于一些隐式的过滤条件，如可以根据join key生成的过滤规则，Inceptor会根据语义保证正确性的前提下进行规则生成。
过滤条件前置
Transwarp Inceptor能够从复杂的组合过滤条件中筛选出针对特定表的过滤规则，然后通过SQL语义来确定是否能将过滤条件前推到尽量早的时候执行。如果有子查询，过滤条件可以递归前推入最低层的子查询中，从而保证所有的冗余数据被删除。
超宽表的读取过滤
对一些列超多的表进行处理的时候，Transwarp Inceptor首先会根据SQL语义来确定要读取的列，并在读取表的时候进行跨列读取减少IO和内存消耗。而如果表有过滤条件，Inceptor会做进一步优化，首先只读取过滤条件相关的列来确定该行记录是否需要被选择，如果不是就跳过当前行的所有列，因此能够最大程度上的减少数据读取。在一些商业实施中，这些优化规则能够带来5x - 10x的性能提升。
Shuffle Stage的优化与消除
Spark的shuffle实现的效率非常低，需要把结果写磁盘，然后通过HTTP传输。Transwarp Inceptor添加了一些shuffle消除的优化规则，对SQL的DAG中不必要或者是可以合并的shuffle stage进行消除或者合并。对于必须要做Shuffle的计算任务，Inceptor通过DAGScheduler来提高shuffle的效率：Map Task会直接将结果返回给DAGScheduler，然后DAGScheduler将结果直接交给Reduce Task而不是等待所有Map Task结束，这样能够非常明显的提升shuffle阶段的性能。
Partition消除
Transwarp Inceptor提供单一值Partition和Range Partition，并且支持对Partition建Bucket来做多次分区。当Partition过多的时候，系统的性能会因为内存消耗和调度开销而损失。因此，Inceptor提供了多个规则用于消除不必要的Partition，如果上下文中有隐式的对Partition的过滤条件，Inceptor也会生成对partition的过滤规则。
3.2.2 基于成本的优化器(Cost Based Optimizer)
基于规则的优化器都是根据一些静态的信息来产生的，因此很多和动态数据相关的特性是不能通过基于规则的优化来解决，因此Transwarp Inceptor提供了基于成本的优化器来做二次优化。相关的原始数据主要来自Meta-store中的表统计信息、RDD的信息、SQL上下文中的统计信息等。依赖于这些动态的数据，CBO会计算执行计划的物理成本并选择最有效的执行计划。一些非常有效的优化规则包括如下几点：
JOIN顺序调优
在实际的案例中，join是消耗计算量最多的业务，因此对join的优化至关重要。在多表JOIN模型中，Transwarp Inceptor会根据统计信息来预估join的中间结果大小，并选择产生中间数据量最小的join顺序作为执行计划。
JOIN类型的选择
Transwarp Inceptor支持Left-most Join Tree 和 Bush Join Tree，并且会根据统计信息来选择生成哪种Join模型有最佳性能。此外，Transwarp Inceptor会根据原始表或者中间数据的大小来选择是否开启针对数据倾斜模型下的特殊优化等。此外，针对HBase表是否有索引的情况，Transwarp Inceptor会在普通Join和Look-up Join间做个均衡的选择。
并发度的控制
Spark通过线程级并发来提高性能，但是大量的并发可能会带来不必要的调度开销，因此不同的案例在不同并发度下会有最佳性能。Transwarp Inceptor通过对RDD的一些属性进行推算来选择最佳并发控制，对很多的案例有着2x-3x的性能提升。
4.Transwarp Holodesk内存计算引擎
为了有效的降低SQL分析的延时，减少磁盘IO对系统性能的影响，星环科技研发了基于内存或者SSD的存储计算引擎Transwarp Holodesk，通过将表数据直接建在内存或者SSD上以实现SQL查询全内存计算。另外Transwarp Holodesk增加了数据索引功能，支持对多个数据列建索引，从而更大程度的降低了SQL查询延时。
4.1 存储格式
Transwarp Holodesk基于列式存储做了大量的原创性改进带来更高的性能和更低的数据膨胀率。首先数据被序列化后存储到内存或SSD上以节省者资源占用。如图3所示，每个表的数据被存储成若干个Segment，每个Segment被划分成若干个Block，每个Block按照列方式存储于SSD或内存中。另外每个Block的头部都加上Min-Max Filter和Bloom Filter用于过滤无用的数据块，减少不必要的数据进入计算阶段。
Transwarp Holodesk根据查询条件的谓词属性对每个数据块的对应列构建数据索引，索引列采用自己研发的Trie结构进行组织存储，非索引列采用字典编码的方式进行组织存储。Trie不仅能对具有公共前缀的字符串进行压缩，而且可以对输入的字符串排序，从而可以利用二分查找快速查询所需数据的位置，从而快速响应查询需求。
图3：Holodesk存储格式
HDFS 2.6支持Storage Tier让应用程序可以选择存储层为磁盘或者SSD，但是没有专用的存储格式设计是无法有效利用SSD的读写吞吐量和低延，因此现有的Text以及行列混合(ORC/Parquet)都不能有效的利用SSD的高性能。为此验证存储结构对性能的影响，我们将HDFS构建在SSD上并选用某基准测试来做了进一步的性能对比，结果如图4所示：采用文本格式，PCI-E SSD带来的性能提升仅1.5倍;采用专为内存和SSD设计的Holodesk列式存储，其性能相比较SSD上的HDFS提升高达6倍。
图4：SSD上Holodesk对HDFS的性能加速比
4.2 性能优势
某运营商客户在12台x86服务器上搭建了Transwarp Inceptor，将Transwarp Holodesk 配置在PCIE-SSD上，并与普通磁盘表以及DB2来做性能对比测试。最终测试数据如图5所示：
图5：某运营商Holodesk性能测试结果
在纯粹的count测试一项，Holodesk性能相对于磁盘表最高领先32倍;对于join测试一项，Transwarp Holodesk最高领先磁盘表多达12倍;在单表聚合测试中，Holodesk提升倍数达10~30倍。另外Transwarp Holodesk在和DB2的对比中也表现优秀，两个复杂SQL查询在DB2数据库中需要运行1小时以上，但是在使用Transwarp Holodesk均是分钟级和秒级就返回结果。
内存的价格大约是同样容量SSD的十倍左右，为了给企业提供更高性价比的计算方案，Transwarp Holodesk针对SSD进行了大量的优化，使得应用在SSD上运行具有与在内存上比较接近的性能，从而为客户提供了性价比更高的计算平台。
在对TPC-DS的IO密集型查询的测试中，无论上构建在PCI-E SSD还是内存上，Holodesk对比磁盘表有一个数量级上的性能提升;而SSD上的Holodesk性能只比内存差10%左右。
图6：数据在磁盘、SSD和内存中的性能表现
5. 稳定的Spark执行引擎
企业目前应用开源Spark的主要困难在稳定性、可管理性和功能不够丰富上。开源Spark在稳定性上还有比较多的问题，在处理大数据量时可能无法运行结束或出现Out of memory，性能时快时慢，有时比Map/Reduce更慢，无法应用到复杂数据分析业务中。
Transwarp Inceptor针对各种出错场景设计了多种解决方法，如通过基于成本的优化器选择最合适的执行计划、加强对数据结构内存使用效率的有效管理、对常见的内存出错问题通过磁盘进行数据备份等方式，极大提高了Spark功能和性能的稳定性，上述问题都已经解决并经过商业案例的考验。Transwarp Inceptor能稳定的运行7*24小时，并能在TB级规模数据上高效进行各种稳定的统计分析。
6. SQL引擎效能验证
TPC-DS是TPC组织为Decision Support System设计的一个测试集，包含对大数据集的统计/报表生成/联机查询/数据挖掘等复杂应用，测试用的数据有各种不同的分布与倾斜，与真实场景非常接近。随着国内外各代表性的Hadoop发行版厂商以TPC-DS为标准测评产品，TPC-DS也就逐渐成为了业界公认的Hadoop系统测试准则。
6.1 验证对比的平台和配置
我们搭建了两个集群分别用于Transwarp Inceptor与Cloudera Data Hub/Impala的测试。每个集群采用4台普通两路x86服务器搭建，每台服务器硬件配置如下：
考虑到磁盘的容量和HDFS的存储复制模式，我们选择的是500GB的数据总量。SQL测试案例的选择上，在Cloudera Impala中使用的是由Cloudera改动过的TPC-DS测试子集，在Transwarp Inceptor我们选用的是TPC-DS为Oracle生成的测试集合，保留了原有的各种复杂SQL，因此能够客观反映出Inceptor在SQL支持上的情况。
6.2 Transwarp Inceptor VS Cloudera Impala
Transwarp Inceptor由于有完善的SQL支持，能够运行全部所有的99个SQL查询。而由于Cloudera官方发布的TPC-DS测试集只包含19个SQL案例，因此我们只能运行这19个SQL，实验证明这部分查询在Impala上全部正常运行完成。
图7是所有的测试集合的性能对比图。图中纵坐标小于1表述测试案例中Cloudera Impala性能超过Transwarp Inceptor，而大于1则表示Transwarp Inceptor有更好的性能表现。对于Cloudera Impala不能支持的SQL，我们就标记这个性能比为100。从图中可见，在Cloudera Impala支持的19个SQL中，有8个SQL的表现超过Transwarp Inceptor，2个表现相当，另外9个Transwarp Inceptor比Cloudera Impala表现的更好。
图7：Transwarp Inceptor与Cloudera Impala的性能比较
6.3 Transwarp Inceptor VS Map Reduce
我们使用了同样的硬件和软件配置完成和开源的Hive执行效率相比，Transwarp Inceptor能够带来10x-100x的性能提升。图8是TPC-DS的部分SQL查询在Inceptor和CDH 5.1 Hive的性能提升倍数，其中最大的提升倍数竟可达到123倍。
图8：Transwarp Inceptor与开源Hive的性能比较
7. 结语
随着在大数据领域国内外开始处于同一起跑线，我们相信像星环科技这样国内具有代表性的Hadoop发行版厂商将在中国的广阔市场空间中获得长足发展，并且由于中国市场激烈的竞争与磨练，逐步打磨出超越国外先进厂商的技术与实力。
刘汪根。2013年加入星环，作为早期员工参与了星环大数据平台的构建，现担任数据平台部研发经理，主要负责与管理星环大数据平台数据平台的研发工作，如SQL编译器，Spark执行引擎等工作，产品涵括Transwarp Inceptor/Transwarp Stream等软件。
【编者按】星环科技从2013年6月开始研发基于Spark的SQL执行引擎，在2013年底推出Transwarp Inceptor 1.0，并落地了国内首个7x24小时的商用项目。经过1年多的持续创新与改进，星环已经在国内落地了数十个Inceptor的商用项目。这是一篇星环Spark解决方案的技术解析，也是Spark用户可以效仿的优化之道。