大数据弹性应用开发的八项基本原则_最新动态_新闻资讯_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 新闻资讯 > 最新动态 > 大数据弹性应用开发的八项基本原则

大数据弹性应用开发的八项基本原则

 2014/8/25 16:37:41    程序员俱乐部  我要评论(0)
  • 摘要:英文原文:Theeightmust-haveelementsforresilientbigdataapps大数据应用正在从概念走向现实,而企业在大数据应用开发时,软件的弹性(Resilient)正在成为决定大数据应用成败的关键因素。弹性差的应用无法应对大规模的数据集,在测试和运营中也缺乏透明度,而且也不安全。避免大数据应用在生产环境中掉链子的最佳办法就是在开发阶段就开发弹性应用,例如:鲁棒、经过测试、可改变、可审计、高安全、可监控。可以说,开发出弹性大数据应用既是一个技术工作,也是一个哲学问题
  • 标签:应用 数据 开发 应用开发

  machinelearning" src="/Upload/Images/2014082516/948DE3738C420FC1.jpg" alt="machinelearning" width="523" height="258" border="0" />

  英文原文:The eight must-have elements for resilient big data apps

大数据应用正在从概念走向现实,而企业在大数据应用开发时,软件的弹性(Resilient)正在成为决定大数据应用成败的关键因素。弹性差的应用无法应对大规模的数据集,在测试和运营中也缺乏透明度,而且也不安全。

  避免大数据应用在生产环境中掉链子的最佳办法就是在开发阶段就开发弹性应用,例如:鲁棒、经过测试、可改变、可审计、高安全、可监控。

  可以说,开发出弹性大数据应用既是一个技术工作,也是一个哲学问题。Concurrent 的 Supreet Oberoi 近日撰文提出大数据应用开发八大基本原则,IT 经理网编译如下:

  一、为弹性大数据应用描绘一个蓝图

  第一步是为企业大数据应用创建一个系统的架构和方法,要处理什么数据?那些类型的分析最重要?软件架构需要承载那些指标、审计、安全和运营功能?

  另外一些需要考虑的问题:那些技术最关键?哪些技术只是图一时之便?你的蓝图需要准确评估当前架构的问题所在。

  二、数据规模不再是问题

  如果应用无法处理更大规模的数据集,那么它就缺乏弹性,弹性应用应当能够处理任意规模的数据集(包括数据深度、广度、频度等),数据弹性还只对新技术的兼容,缺乏弹性的应用需要不断配置修改应用来适应不断更新的大数据技术,对于企业来说是时间、资源和金钱上的无底洞。

  三、透明度

  对于复杂应用来说,查找扩展性等弹性相关问题还很难实现自动化。关键是锁定问题的根源所在:是代码、数据还是架构抑或网络问题?并非每个应用都要具备这种透明度,但大一些的平台应当具备足够的透明度,让所有开发者和运营人员都能在问题发生时立刻找到根源并采取措施。

  一旦发现问题,最为关键的是将找到应用行为对应的代码——最好是通过发现问题的监控应用。大多数情况下,访问代码会涉及到多个开发人员,执行起来流程将非常曲折。

  四、抽象,事关高效和简洁

  弹性应用总是面向未来的,通常采用抽象层来简化开发、提升效率,允许采用不同的技术实现。作为架构的一部分,弹性开发的抽象层能够避免开发者陷入技术实现的细节泥潭中。简洁性则能方便数据科学家使用应用访问所有类型的数据源。如果没有抽象技术,产品的生产力会大打折扣,修改成本增高,而用户则为复杂性所困扰。

  五、安全:审计与合规

  弹性应用能自我审计,能够显示谁使用了应用,谁有权限使用,访问了哪些数据以及政策如何实施。在应用开发阶段就将这些功能考虑进去是应对日益增长的大数据隐私、安全、治理和控制挑战的关键所在。

  六、完整度与测试驱动的开发

  弹性应用的一个基本要求就是不能遗失任何数据,数据完整性的丧失往往会导致严重的后果,例如金融企业会因为程序代码弄丢了一两行交易数据而在反洗钱或金融欺诈调查中遭受处罚。

  七、数据便携性

  不断发展的业务需求驱动技术不断做出改变,因此,大数据应用也应当能够在多个平台和产品上运行。最终的目标是让最终用户能够通过 SQL 和标准 API 访问数据(无论是否实时)。例如,一个先进的大数据平台应当允许原本由 Hadoop 存储 MapReduce 处理的数据,转移到 Spark 或 Tez 中进进行处理,而且这个过程不需要或尽可能少地改动代码。

  八、不要搞个人“巫术”

  大数据应用的开发不应当依赖某个高手的个人才华,代码应当在多个开发者之间分享、评估和保有。这个策略让整个团队,而不是个人,对应用质量负责。

  • 相关文章
发表评论
用户名: 匿名