大资料处理的挑战悄然来袭,企业须以新思维全面因应

振锋企业资讯部经理黄立品表示,利用In-Memory技术,业务人员调用产销报表速度快了30倍,而后端的产销资料,也从每小时更新一次,加速到即时更新。

商场就是战场,指挥官最重要能力,就是综合各种可用的情报,进而取得早一步决策的先机。而在网际网路普及,企业业务流程高度IT化的今日,网路上的言论、回馈、企业内的生产、销售资料,就是企业决策的主要情报来源。另一方面,虽然大资料(Big Data)的应用在台湾仍在萌芽阶段,但是,包括厂区机台的生产资料、各分店的销售情形、社群网站中的言论等,都越来越具备大资料的3V特性:大量(Volume)、速度(Velocity)、以及多样性(Variety),企业已越来越不能自外于大资料的艰难挑战。

举例来说,证交所就在今年7月,将个股交易的撮合方式,从原本的20秒,改为15秒撮合一次,更计画在未来进步到即时撮合。面对这样严峻的要求,各家证券商必须改进自己的交易处理系统,例如元富证券利用记忆体式资料库,来加速交易订单的处理速度,虽然目前只是运用在小范围的证券交易员和贵宾大户,仍然替未来对即时资料处理的要求,跨进了新的一步。

而以金属模具、吊重链条业务为主的振锋公司,也面临了必须在短时间内处理大量报表资料的挑战。从前,业务员每调用1次产销报表,就要花上1分钟的等待时间,这在面对客户或竞争对手的场合下,往往会让他们错失先机。因此振锋决定导入In-Memory技术来加速企业的资料处理,让前线业务员在调用报表的速度上,增进了30倍,从前需要1分钟的等待时间,现在只需要2秒时间,甚至,对于更大量的资料处理,速度的增加可能比30倍更高。

面对大资料浪潮,企业如果能正视自己要面对的资料特性,并从各项技术间选择未来可能的发展方向,就有机会在大资料浪潮下,乘风而起。

业务员对于企业生产、销售的掌握程度,是决定企业是否能争取到客户的关键要素之一。但是,越来越庞大的资料量,也在企业的即时资料处理上,带来了最直接的挑战。振锋企业资讯部经理黄立品就表示,从前业务员在面对客户时,要调出产销资料供查询时,往往必须等待1分钟之久,而在交叉查询,或者是多次查询的使用情境下,时间往往会拖得更长,然而在与客户洽商的场合,时间就是筹码,等待的每分每秒都必须付出成本,有时1、2分钟的效率落后,最严重的后果可能造成订单流失。

资料膨胀导致的另一个问题是,从前的后端报表资料是每个小时更新1次,业务员在洽商场合,往往不能取得最即时的产销状况,而必须等待下1次更新週期过后,才能获得最新的数据,这同样也拖缓了业务员的反应速度。

黄立品表示,将常用资料暂存于快取记忆体内的In-Memory技术,恰巧解决了这个问题。藉由快取常用的报表资料,业务人员调出订单的速度可以从1分钟缩短为2秒,而后端的报表资料,也从1个小时1次的更新,变为即时更新,这意味着前线业务员可以取得零时差的产销资料,提升谈判的筹码与竞争力。

证交所已在今年7月,将个股交易的撮合方式从原本的20秒,改为15秒撮合一次,证交所更计画在明年底,将个股交易改成即时逐笔撮合。面对这样的要求,元富证券就导入了记忆体式资料库,来加速交易订单资料处理。每日的股市交易都牵涉了庞大的历史资料、即时资料的综合处理与判断,若是以传统的资料库来做资料处理,因为其I/O瓶颈过高,往往会有所延迟,而比起一般企业应用,证券交易往往要求更高的即时性。对此,元富证券资讯部专案副总经理李俊德表示,元富证券导入了记忆体式资料库,摆脱了过去硬碟I/O的瓶颈,让系统能更快速地处理订单交易。

不过李俊德提醒,记忆体式资料库也有其缺陷,主因是资料都是储存在记忆体中,一旦面临断电,未储存进硬碟的资料将难以复原。然而若要额外建置备援机制,则会影响到资料处理的效率,这个两难问题,也是资料处理技术上的一大挑战。

虽然,许多企业没有立即处理大量资料的问题,对于资料处理即时性的要求也不高,然而,企业仍能现在就从大资料带来的技术变革,以及新的资料处理观念出发,来重新思考企业在未来可能面对的资料类型,以及未来潜在的业务需求。

举例来说,工厂的许多机台每日产生许多的系统资料、社群网站每天也产生许多类型的资料,很多人认为,大量收集、分析这些资料可以用来改善生产、或用来更精准地投放广告,却忽略了这些资料从进入资料库系统的那一刻、其传输、储存、运算、甚至删除,都需要花费系统资源。因此收集资料不是越多越好,更重要的是,必须仔细评估企业到底需要哪种类型的资料。

此外,资料量的爆炸性膨胀,与即时处理要求的增加,在许多的情况下,也让以往要在资料群中找出「最好」解的要求,变得不那么容易达成。例如Facebook的推荐朋友、Amazon的推荐商品机制,其背后都牵涉了大量资料间,彼此关联的交互运算,若要求出一个最佳解,则必须要花费为时数天的运算时间,而在推荐系统上,用「效率」换取决对的「品质」的想法,就变得更加重要了。

虽然现行的软硬体技术、演算法设计、资料处理的思维等,都因为大资料趋势的衝击,而有了程度不同的进展,然而,在大资料处理上仍存在着极大的瓶颈。

例如,硬碟与网路的I/O速度的不足,就是资料处理的严峻挑战之一。国家高速网路与计算中心副主任周立德,就藉由一个例子,说明了网路传输在资料处理的环节中造成的瓶颈。他说国网中心在跟外部机构合作时,常需要传输高达TB级的大量资料,通过网路传输得花上好几天,对于网速过慢的因应办法,周立德说,他们往往得依赖「UPS」解决,乍听之下,以为是某种新的资料传输技术,后来听他解释,才知道是「UPS联合包裹服务」:直接将硬碟里的资料快递到目的地。周立德指出,网路传输速度与CPU的运算速度间的鸿沟不断扩大,是未来资料处理的一大隐忧。

另外,新型资料处理技术人才的不足,也间接导致了这些技术无法普及。华硕云端公司总经理吴汉章认为,像是In-Memory技术、GPU运算技术等,其程式语言的撰写逻辑,有别于传统的程式语言,因此,即使对传统程式语言嫻熟者,也必须重新花时间学习,另一方面,学校也缺乏系统化的教学策略,导致真正掌握新技术的人才供不应求。

而对企业而言,人才的不足也会造成技术普及的障碍,企业即使有了新的软硬体系统建置,但在缺乏相对应的开发、维护人才的情形下,仍然无法发挥技术的最大效能。

一家网路公司单挑全球计程车业

iThome

来自旧金山的Uber,瞄准商务人士的乘车需求,只要使用行动装置上的App,就可以呼叫代步车的服务,挟资讯科技之威能,造成全球乘车服务大地震,颠覆传统计程车商业模式。

尽管Uber在欧洲,甚至是台湾都因挑战计程车产业,而引起了不少反弹声浪以及违法争议,不过即便这些风波,仍然无法掩盖Uber所带来的风潮,Uber亚太地区总经理Frank Allen 24日来台,揭露了打造出Uber全球服务背后的关键。

Uber在各市场成长快速,无论是在旧金山、纽约或是巴黎,使用人数皆持续上升。Frank Allen说,在人口密集的中国一线城市,使用人数更呈现爆炸性成长,以上海的Uber搭乘人数来说,随着进入市场的周数增加,人数以及成长速度已经远超过旧金山同时期的状况,而在Uber进入北京第13周,人数也已超过旧金山的第40周。

Frank Allen表示,Uber是一家资讯科技公司,因此许多做法有别于传统,不少决策与服务来自大资料技术运算的结果。例如计程车常遇到的派车问题。

最佳演算法所追求得理想状态是,达到最少的车辆闲置,并用最快的速度服务最多的乘客,不过目前多数这类型的演算法都是区域性(Local)的最佳化,但是Uber透过大资料技术,藉由追踪车辆行驶路线的GPS,统计出城市中各区域乘客移动的频率分布,作为Uber全域调度车辆演算法最佳化的依据。

不只如此,当把所有车辆行驶的GPS连成轨迹,还能得到详细的街道地图,城市中的小路与捷径一目了然,而这些资讯能用于改善数位地图,并且帮助最佳化行车路线。

更特别的是Uber开启新市场的方式,创新的决策更加印证Uber是家彻底的资讯公司,过去跨国公司开启海外市场前,都必须委託顾问公司作标的详尽的市场调查,但是这道程序不仅成本高昂且耗费时日,容易错失进入市场的最佳时机。

Uber统计当地Uber App被开启的次数,每次Uber App被开启时,根据用户的GPS,在世界地图对应的位置上画上红点,红点密集的地方,表示Uber在该地区的知名度越高,市场也越期待Uber的服务,当某地区红点累积次数超过一定门槛值,便是进入该市场最佳时机。大资料技术提供即时丰富的线索,充足的基础数值证据,能够支持循政决策的可靠性。

另外,Frank Allen表示,Uber在各区域提供差异化的服务,虽然客群锁定商务人士,但是不同国情所需要的服务也不一样,例如:日本原来就是服务业发达的国家,因此Uber在日本提供更高等级的服务品质,而在印度市场,Uber的要求将是当地水准之上的舒适。

在6月初,Uber甫获12亿美元融资,公司市值高达182亿美元,直逼全台市值第7名的企业南亚塑胶,而融资金额正显示着投资者对投资标的的获利期待,以及肯定其野心的执行力。Uber提供的不仅是代步车服务,而是通路。

Uber精准锁定商务人士客群,不少商务人士经常需要到各国出差,当只要透过一个App便能在全世界有Uber服务的国家,享受到安全且有品质的乘车服务,对于这群用户是既省时又方便。

而Uber的野心也不仅止于载送乘客而已,而是进一步挑战服务与物流平台。在2014年的过年,Uber首度在上海、广州、深圳和新加坡4地提供到府舞龙舞狮的服务,用户同样只要于App上选择舞龙舞狮,再指定时间地点,舞龙舞狮就会走进公司办公室,提供喜气的表演。这是在过去新创科技公司前所未见的,同时也显示,Uber原本使用来呼叫座车的平台,已能提供其他服务。

另外,Uber将7月18日订为全球冰淇淋日,使用者同样只要点一点App,选择冰淇淋服务,就有车队将冰淇淋派送到家,而且与搭车服务的付费方式一样,直接用Uber帐户连结的信用卡交易,使用者不需要额外准备现金。Frank Allen透漏,配送冰淇淋是他们用来小规模测试物流的方法。

Uber动作频频,用科技公司的创新角度挑战传统产业,不禁让人对于往后的发展有无限想像。

锁定大资料处理需求 红帽新储存伺服器容量达19PB

红帽近日在台发表储存伺服器3.0版本,锁定PB级的资料处理需求,单一丛集最多支援128台伺服器,容量上看19PB,新版本强化的功能包括提升伺服器的扩充能力、资料保护与作业控管能力,同时也正式支援Hadoop档案系统外挂程式,目前台湾已有电信产业和金融产业在进行POC验证阶段。

新版本结合红帽企业级Linux 6和GlusterFS 3.6开源档案系统,支援横向扩充档案储存系统,红帽资深解决方案架构师游政杰表示,相较2.1版本,新版本每台伺服器最多支援的硬碟数量从24个增加至60个,而每个丛集支援的伺服器数量,则从64台增加至128台,可用容量高达19PB。

为强化资料保护,红帽储存伺服器3.0新增了快照备份功能(Volume Snapshot),每个Volume提供256份快照,游政杰表示,在先前的2.1版本时是针对各个磁碟进行快照,而新版本则可以针对完整的逻辑磁碟进行快照备份。

因应大资料的趋势,新版本正式支援Hadoop档案系统外挂程式,在Hadoop解决方案中可以取代原有的Hadoop档案系统,直接在储存伺服器上运行Apache Hadoop的工作负载,也可整合Apache Ambari开源管理套件,来监控Hadoop系统与设备的生命周期。

在作业控管能力上,红帽储存伺服器3.0整合了开源的系统监控软体Nagios,可以随时监控储存伺服器中的逻辑物件、实体物件、容量、空间等资讯。若系统服务发生异状可发送电子邮件通知管理者。游政杰表示,未来红帽储存伺服器会持续与第三方的解决方案进行认证或整合。

此外,游政杰也表示,若使用者已安装2.1版本,可安装升级程式直接升到3.0版本。

对于软体定义储存趋势,游政杰认为,台湾市场目前还在观念移转阶段,企业客户欠缺足够的驱力,不过许多企业其实都有大资料处理的潜在需求,像是图资网站、具导航服务的网站、视讯媒体等线上服务网站,或是像金融业等有资料备查需求的产业,这些企业若使用传统技术,横向扩充的弹性较低,使用传统磁带也有保管与寿命上的限制。

若採用软体定义储存的解决方案,以x86作为储存阵列基础,企业较能控制扩充成本。

目前红帽在软体定义储存上提供3种解决方案,包括收购Gluster后推出的储存解决方案、红帽OpenStack平台中为云端环境提供Object Storage的Swift解决方案,以及今年收购Intank后推出的红帽Intank Ceph企业级储存解决方案。

Gluster原本是开源丛集档案系统开发商,其GlusterFS开放原始码档案系统和Gluster储存平台软体堆叠核心技术,支援大资料的储存管理与存取,红帽在2011年并购Gluster后推出首款储存软体设备。今年5月红帽又以1.75亿美元买下Ceph分散式储存系统供应商Inktank,并在7月推出Inktank Ceph 1.2企业级解决方案,提供物件和区块储存软体。

苹果收购大资料图书分析公司BookLamp

BookLamp

苹果已经和大资料图书分析服务公司BookLamp达成收购协议。在亚马逊收购了BookLamp的竞争对手GoodRead之后,苹果证实收购大资料图书分析服务公司BookLamp,强化iBook中的推荐、搜索和分类功能,以和亚马逊相抗衡。据TechCrunch报导,此次的收购价格约在1,000至1,500万美元之间。
BookLamp主要透过扫描图书的内容,将图书内容分割成数以千计的数位档,再用量化方式寻找相似之处,也可以分析图书中某些主题出现的频率和密度,分析出此书的写作风格后,提供使用者相似的阅读名单,先前为亚马逊、苹果iBook等网路书店,提供图书推荐服务。另外,BookLamp也透过资料分析服务,为出版商评估哪一本书籍在哪一个区域比较畅销,或者预计可以分配到的预算金额。
BookLamp曾推出图书基因组合专案(Book Genome Project),此平台可以先扫描读者喜欢的写作风格,再将一本书切割成数以千计的资料点(Data Point),加以分析后,就可以告诉读者此书的风格,与是否受使用者所喜欢。
此外,BookLamp不仅能为网路书店提供图书推荐服务,还能提供广告服务,如可以就使用者搜索或点击的关键字,再加以分类,为企业提供投放广告的建议。由于目前苹果iBook,仅为苹果的使用者提供电子书服务,但未提供内容推荐服务,所以市场预计,当苹果收购BookLamp后,可做为和亚马逊竞争间的新利器。

 

Yahoo商城分析百万笔购物行为 猜出消费者购物慾望

JCCONF

在3月Yahoo推出了慾望墙,将消费者可能会想购买的商品集中在同一页面上,而其推荐的结果,是分析来自Yahoo购物中心与商城每日5百万笔的购物行为纪录,Yahoo资深工程师陈怡安在2014年JCCONF上分享,Yahoo如何使用即时串流机器学习Samoa,根据顾客频繁变化的购买行为特徵,做出商品最佳推荐。

陈怡安说,为了提升购物中心的点击率(Click Through Rate,CTR),对于各类型族群的消费者,给予不同的搜寻结果,提高命中消费者兴趣点的机率,以名牌Coach关键字为例,不同族群在购物中心搜寻时,得到的结果皆不一样,当搜寻Coach是年龄族群较高的女性,推荐引擎的结果可能要提供当季且单价较高的手提包,而搜寻的用户如果是刚入社会不久的年轻女性,经济状况可能较不宽裕,推荐引擎或许要推荐的是价位较低的皮夹为主。

而这之中的消费行为差异,必须要藉由机器学习(Machine Learning)帮忙,用大量的资料训练数学模型,以预测未知的资料。假设一个篮子里有蓝色鸭蛋与红色鸡蛋,透过已经存在的样本告诉电脑,鸭蛋就涂蓝色,是鸡蛋就涂红色,当下次有一颗蛋需要上色时,电脑便可藉由过去的经验判断该颗蛋的颜色。而Yahoo的推荐引擎也在做分鸡蛋的事情,将使用者的点击资料当作推荐引擎的训练资料,分析使用者的搜寻、浏览商品等行为资料,了解浏览商城以及购买的习惯,以得到商品与使用者族群之间的关係。

陈怡安以购物中心的关键字为例,有不少消费者想要购买「女神」风格的衣服,但是一开始并没有人了解「女神」的衣服是什么样子,而推荐引擎藉由使用者的搜寻以及点击行为学习后发现,搜寻关键字「女神」的用户,有高比例会点击具有飘逸、网纱、雪纺以及典雅等形容词的商品,因此推荐引擎便可藉由使用者行为资料的训练,得知当用户搜寻「女神」时,应该推荐什么样的商品。

机器学习在不同的环境有不同的工具可利用,当在单一的机器可以使用R语言的套件或是开源的Java软体Weka,而在大资料的分散式批次架构中可以使用Pig、Mahout或是MLib。

陈怡安表示,Yahoo商城使用者行为的变数非常多,而且随时都在变动,因此推荐引擎需要具有即时的分析能力,于是他们採用了分散式串流机器学习架构Samoa,他表示,Samoa能不断的串流资料,即时修正数学模型,是串流机器学习领域发展较为成熟的套件。

Samoa可依需求选择Apache S4或是Storm分散式串流运算平台,而且其本身也支援多种演算法,例如Classifier Methods、Clustering Methods或是Frequent Pattern Mining。陈怡安说,Yahoo商城因为功能上的需要,目前尝试导入Storm,因为Storm不只具有弹性规模,能依运算量扩展机器,并且还有容错的能力,当一个运算节点发生错误时,另一台机器可以马上接手工作,而且重要的是,所有任务要保证一定会被至少执行一次。

另外,他们认为运算速度是一件很重要的事,而且整个资料流的过程,不能有瓶颈,因为整体的速度,会被最慢的环节拖慢,因此分析工作很仰赖记忆体式运算架构,将大量运算放在记忆体中处理,而不存取硬碟。

不过,有些演算法在传统水平平行化运算上无法得到效能的提升,例如决策树,陈怡安说,Samoa是为Web Mining而设计的,一个任务可能包含十几万个特徵,当节点都处理十几万个特徵,水平平行化会使记忆体负担太大,Samoa团队在设计上,便採用了较不直觉,但是计算量能被接受的垂直平行化。

陈怡安也提到,许多技术的选择无法选出一个最好的,只有依照需求选出最适合的。

资料是新石油,但你要找得到油井

还记得10年前爆发的SARS(严重急性呼吸系统综合症)疫情吗?台湾及邻近国家都陷入社会恐慌、人人自危的不安局面,为了控制病毒蔓延,疾管局全面展开通报机制,不仅医疗单位要在第一时间向上通报可疑的发烧及呼吸道感染等疑似案例,机关、学校及民间企业也都全面加入量测体温的行列,以便及早发现SARS的徵状。

落实通报机制,证实发挥了很大的效果。从台湾在3月出现首宗SARS案例,到7月世界卫生组织确认SARS在台湾已终止人际链的传播,疫情在4个月内就获得了有效的控制。

然而,透过基层通报的疫情监控机制,在2009年美国H1N1流感大爆发时,显得捉襟见肘。因为美国幅员辽阔,层层通报机制下的讯息传播速度较慢,等到疾管局收集到资料,通常已经与事发有1至2个礼拜的时间差了。当流感传播的速度快于疫情通报时,疾管局无法掌握实际的疫情状况,也就难以做出正确的判断与资源调度。

正当美国疾管局大伤脑筋之际,Google的工程师发表了一项以资料分析技术预测流感传播趋势的研究成果,说明他们不必依赖基层医师回报流感案例,只要分析人们使用搜寻引擎的行为,透过分析庞大的搜寻资料,找到流感与搜寻字词之间的相关性,预测流感未来的传播趋势。

Google的方法不仅是预测的结果与疾管局的疫情资料相符,而且更重要的是,这种利用电脑来分析的做法,可以马上呈现即时的流感趋势预测结果,不必等上1、2个礼拜才能知道结果;而这个方法所需要的成本,也远低于疾管局现行的通报系统。

Google这项研究的成果,也就是目前仍在提供的Flu Trends服务,让人看到了人类有机会成功对付病毒的一线生机。疫情监控人员将能摆脱追着病毒跑的宿命,可以及早依据预测的资讯,将疫苗、药剂等医疗资源送到可能会需要的地方。

自2009年之后,这个流感预测服务陆续推广至29个国家,后续也增加对于登革热的疫情监控,Flu Trends逐渐成为传染病监控的得力助手,也成为人们津津乐道的大资料(Big Data)应用案例。

不过,在2012年底冬季流感爆发季节,Flu Trends的预测结果却突然大暴走,高估了疫情,出现与疾管局的资料有大幅度偏差的现象,引起了一些对预测准确性的质疑。事后Google并未说明问题原因,只交代会修正分析模型,而其他人则认为是搜寻行为的改变影响了分析结果,有可能是媒体大幅报导流感讯息及政府大力宣导,人们因而提高了对流感的意识,进而导致搜寻数量增多,使得Flu Trends的分析模型受到了干扰。

Flu Trends这个例子的过程,正是对大资料最好的詮释。Google从大资料中找到有意义的资讯,所做出的预测与实际发生的状况相去不远,对过去监控疫情的做法无疑是个破坏性的创新;不过,大资料可也不是那么神奇,必须不断地监控、修正,才能一直确保大资料的分析价值。要挖掘大资料,可不像淘金客发现溪中金沙那样碰运气,在技术上必须下很大的功夫,可能得探勘多次才找得到真正有产值的油井,也可能油井突然枯竭了,要判断是继续挖深还是另寻他法。

资料被认为是未来世界的新石油,如同过往掌握石油的人能称霸世界,未来能够掌握资料的人,就有可能改写既有的规则,雄霸新世界。在前进大资料时代之际,许多技术、观念也都随之改变。自本期封面故事开始的一系列大资料报导中,我们就先从资料处理的变革来谈起。

吴其勋/iThome电脑报周刊总编辑

锁定HPC领域大数据应用,Seagate推出整柜式储存系统

大数据是当前火红的企业IT应用之一,许多储存设备厂商纷纷推出可支援横向扩展的产品,而硬碟厂商这几年来也默默加入战局,甚至积极并购相关的整柜式物件储存系统厂商,像是HGST推出了Active Archive System,就是得力于2015年买下Amplidata,而Seagate更早在2014年并购了Xyratex,因此开始提供ClusterStor系列设备,而在该年9月推出了ClusterStor 1500、6000、9000与ClusterStor Secure Data Appliance,这些都是Xyratex时期就有的产品,而到了2015年下半,该公司推出更多机型,像是L300、A200、G200。

以L300这款机型而言,是特别针对开放原始码的平行分散式档案系统Lustre,所推出的储存设备,当中搭配了Seagate的3.5寸HPC硬碟ClusterStor HPC Drive,这系列硬碟是专门为了高效能运算市场所设计的,主要用于Seagate自家的这类型解决方案。

就存取效能而言,L300的每台机柜若是搭配Seagate的3.5寸HPC硬碟,将可提供到112 GB/s,而相较于先前推出的ClusterStor系列设备,效能可高出77%。如果需要更高效能,L300的每台机柜还可支援所谓的「极致模式」,能提供到448 GB/s,主要是针对小型的档案应用。而此时,所用的储存组态,主要搭配的是Seagate的快闪记忆体技术。

L300也可採用固态混合硬碟(Solid State Hybrid Drive),提供较便宜的储存搭配选项,以支援小型档案的高速应用。

若要将物件储存系统作为备份目的地(Object Storage Target),L300还可支援相关的资源池管理──可横跨不同的储存媒体,像是Flash记忆体、HPC硬碟、固态混合硬碟与传统硬碟,在同一个档案系统内,建立多个彼此分隔的储存资源池。而透过这样的机制,可协助在单一储存系统内整并多种应用系统,并能为个别应用程式或工作负载,提供更好的服务品质管控(QoS)。

在网路I/O存取介面上,L300本身可支援10GbE和40GbE的乙太网路连接介面,同时也支援许多专为巨量运算而设的新规格,像是Intel所发展的Omni-Path,以及Mellanox的100 Gb/s Infiniband。

Seagate ClusterStor L300
●原厂:Seagate(02)2545-1305
●建议售价:厂商未提供
●档案系统支援:Lustre 2.5/2.7、IBM Spectrum Scale 4.2
●机柜组成:基本机柜、扩充机柜
●最大原始容量:搭配8TB SAS硬碟,每座基本机柜为3,936 TB,每座扩充机柜为4,592 TB
●效能:每座基本机柜为96 GB/s,每座扩充机柜为112GB/s
●丛集最大规模:160亿节点(需选购Distributed Namespace Server)
●机柜组成:基本机柜(置顶交换器、ClusterStor管理单元、横向扩展储存单元)、扩充机柜(置顶交换器、横向扩展储存单元)

【注:规格与价格由厂商提供,因时有异动,正确资讯请洽厂商】

中华电信组合168台伺服器建立巨量资料运算平台

iThome

虽然对很多台湾企业来说,巨量资料仍被视为未来才会逐渐发生的事情,但实际上,台湾电信业者确实已开始发展处理巨量资料的方法。

企业分析巨量资料的目的,多半是为了分析客户行为,并针对这些行为给予主动行销。以过去常运用资料仓储分析资料的金融业来说,现在有更多即时性的资料出现,若能结合历史性跟即时性的资料进行综合分析,就能让应用资料的效益更高。

现在台湾也有电信业将巨量资料的分析结果应用在预测骇客攻击的领域。由于一般骇客在正式攻击之前,会先尝试攻击不同的伺服器,这些攻击都会在系统的Log中留下轨迹。在Log会有一段叙述,用来描述错误讯息,电信业者就藉由可同时处理结构与非结构性资料的资料仓储系统来处理这些半结构性资料,利用这些错误讯息建立模式,进而预测骇客攻击提早加以预防。显见得巨量资料在应用领域上已经逐渐多元化。

为了解决这些巨量又大型的非结构性资料,各个企业作法并不同,但Gartner副总裁Donald Feinber表示,大部分的企业会特别打造一个空间或是平台来存放并分析这些非结构化资料或是巨量资料。中华电信的作法也是如此。

中华电信研究所为了配合中华电信的需求,在2010年1月建置了一个以Hadoop技术为核心的平台,称为「大资料运算平台」,用来分析一些讯务资料、MOD每日收视率分析等。

中华电信研究所宽网室研究员萧毅表示,目前这个平台仍在研发阶段,会针对中华电信内部的需求来开发平台功能,接下来,将进一步对内实际提供加值应用,未来也打算将技术包装后,对外提供巨量资料平台运算的服务。

这个「大资料运算平台」目前是由168台伺服器所组成,资料容量是600TB,以Hadoop云端运算技术为核心架构。在底层核心架构上,中华电信研究所再利用开放原始码各种技术开发了其他模组,像是分散式资料库系统、工作排程、流程管理、资料库介接工具等来提高平台的可使用度。同时,为了提升平台的维运效率,中华电信研究所开发了管理模组、效能监测、告警通报、组态管理等一般网管所具有的机制。

另外,中华电信研究所也开发了一个「大资料元件库」。萧毅表示,元件库就如同中介软体,藉由这些元件库的API,开发人员不一定要学会用Hadoop技术来写程式,就能使用平台上的资料分析功能。目前这个元件库底下约有6种元件库,包括MOD元件库、影音搜寻元件库、影像辨识元件库等。

萧毅表示,当巨量资料平台所群组起来的伺服器越多时,就表示要处理资料量越大,相对来说,管理能力就一定要增强,而目前中华电信研究所开发的「大资料运算平台」程式功能已具有管理200台伺服器的能力,未来若要商用化,这些能力都会持续扩增,让可运算的资料量达到PB等级。

中华电信研究所会想要开发这个巨量资料运算平台,有一个原因就是想要利用Hadoop来处理过去关联性资料库不容易处理的大量非结构化资料。非结构化资料通常都呈现非常大型的状态,就好像是一整篇文章,而不是经过筛选的资料栏位,萧毅称为「一尾式」的资料。

萧毅表示,这种「一尾式」的资料,如果要变成结构性资料,第一个问题是由于资料太过庞大,让资料库的费用大幅增加。第二个问题是,在资料量太大的时候,传统资料库难以连接不同的资料表。因此,「一尾型的资料因为传统资料库无法运算,就改放入Hadoop平台运算,若原本是简化过的结构性资料,才放进原来的资料库分析。」他说。

像之前中华电信研究所曾经利用传统资料库来计算MOD每日收视率分析,结果由于资料量过大而无法分析,建构了「大资料运算平台」以后,运用Hadoop 技术只需1个小时就能计算出结果。萧毅认为,如果硬体的数量再增加,分析所需要的时间甚至可以在几分钟内完成。

虽然巨量资料运算平台可以解决关联性资料库无法分析非结构性资料的难题,但萧毅认为,只要是200TB以内的资料量都还是可以靠传统资料库分析,但超过PB等级资料量的话,传统的资料库恐怕就无法负荷。

因此,中华电信研究所也在这个平台上开发了介面程式来转换结构与非结构性资料,可以将非结构性资料转成结构性资料分析,也可以把原先结构性资料打散变成非结构性资料,再让Hadoop技术做倒立式的搜寻。

虽然开发这个平台为中华电信研究所带来许多崭新的测试经验,但在开发过程中,他们遇到最大的困难就是严重的技术瓶颈。

萧毅表示,最大的挑战在于NoSQL与Hadoop等巨量资料技术与传统资料的设计观念完全不一样,必须训练资讯人员接受新方法,而难题就在于说服资深的技术人员学习新技术。「一旦採用Hadoop技术,原始程式和应用系统功能都要修改,要让技术人员重新学习,这就是我们的困难。」他说。

中华电信要自己开发元件库也是为了解决这个难题。不过,在这个元件库下还是得开发不同专业领域元件库,这时候需要该领域的专家以及能用Hadoop技术开发程式的技术人员共同合作才能完成。

就算可以使用元件库来简化开发,对于技术人员来说,要从本来传统资料库的元件库转换,也会出现转换障碍。

而且,萧毅表示,即使可以利用元件库,技术人员还是直接用Java写MapReduce的分析程式,在运作效能与速度都会比较好,技术人员还是得熟悉Hadoop技术。

因此,中华电信研究所建立了巨量资料技术的专长培训机制,来协助技术人员的转换技能,也为了训练各应用领域的系统设计人员,建立新的巨量资料架构观念拥有自行评估设计、规画、开发的技术能力。

 

中华电信研究所从2010年1月建置好「大资料运算平台」后,陆陆续续在这个平台上测试了不少工作,包含讯务的分析以及MOD收视率分析等。

综合这1年半来运用Hadoop技术的经验,中华电信研究所认为,Hadoop技术各有几项优缺点。

第一个优点是,运用Hadoop技术可以节省成本。中华电信研究所宽网室研究员萧毅表示,开发巨量资料运算平台的硬体很便宜,软体也是免费的,如果要计算一样的资料量来说,只需要支付用传统资料库计算时价格的10分之1。

第二个优点是,减轻程式维护人力。萧毅表示,过去企业要维护一个传统资料库,需要大量的专业人力,尤其是要计算PB等级的资料量时,资料库会变得更加复杂,加上备份的机制,对于程式维护来说是很大的负担。但利用Hadoop技术,由于每一笔资料体积庞大,只要利用类似使用搜寻引擎的功能就可以找到资料,而且Hadoop也会自动备份3次,大大减低程式维护的人力。

另外,中华电信研究所也看好Hadoop技术将成为Java程式语言主流架构,可以同时支援开发单机版,或是多机版。

同时,他们也提出几项目前採用Hadoop技术的缺点,其中有一些也是正在解决的问题。

第一个缺点是,安全性不足的问题。萧毅解释,中华电信研究所未来想要让这个「大资料运算平台」上拥有多租户的功能,但是如果要将这些用户隔开,就必须自行开发程式或使用不同的硬体来区分不同的用户,不过,他认为,这对于单一企业应用此技术开发单一平台来说,就不会有这个问题。

第二个缺点是程式开发人员必须要学习MapReduce架构才能在Hadoop平台开发程式,而且没有针对各行各业需求打造的元件库。

第三个缺点则是各版本功能的差异较大,容易造成应用程式相容性的问题。萧毅表示,为了解决这个问题,在开发的过程中就必须加进许多管控机制才能让程式运作更顺畅。

第四个缺点则是管理机制大多为指令介面,缺乏友善的图像管理介面。事实上,萧毅认为,对专业的开发人员来说,指令介面并没有什么问题,不过对于一般的人来说,容易产生距离感。

 

空污监测的瓶颈 大资料预测突破了

微软亚洲研究院的所在地北京,是全球空气污染恶名昭彰的城市,整座都市时常处于一片灰濛濛的雾霾中。其他城市不受欢迎的颳风下雨,在北京市民的眼中,却是迎接明日蓝天白云、清新空气的好预兆。

在台湾很多人都没听过PM 2.5(细悬浮微粒),但许多北京市民却非常注意这项代表空气品质的指标。PM 2.5是指空气中粒径小于2.5微米的细悬浮微粒,大小约是髮丝的三十分之一而已,因而能直接进入肺部的深处。在空气污染严重的地区,PM 2.5微粒通常会附着一些有害的物质,像是重金属或是多环芳香烃等经证实会致癌的有害物质,而直接进入人体肺部深处。今年10月,世界卫生组织(WHO)亦首度将户外空气污染,列为最高等级的第一类致癌物。

近年来中国许多城市的PM 2.5数值不时风高,美国大使馆在北京监测的数据,甚至一度超过仪器的上限。一起生活在北京市的微软亚洲研究院的电脑科学家,自然也就将其擅长的技术运用在城市空气品质的预测。

微软亚洲研究院现场示范的U-Air空气品质预测系统,已经能提供即时空气品质预测,不论你选择北京、上海等城市的任何一个角落,该系统都能提供即时的PM 2.5推估值。

微软研究员郑宇指出,传统分析城市空气品质的作法,是依赖空气监测站的分析数据,例如北京官方就设立了22个空气品质监测站。但即使有22个监测站,对一座城市来说覆盖率依然很低,再者城市的空气品质其实并不一致,受到交通流量、房屋密度、建筑物造形、绿地等影响,城市裏紧邻区域的空气品质有可能落差很大,而传统仰赖空气监测站的做法,除非是广泛设立监测站,否则是难以针对更小的区域提供空气品质的监测资讯。但是空气品质监测站价格不菲,事实上是难以大量部署。

微软亚洲研究院开发的U-Air空气品质预测系统,利用大资料与机器学习技术,从空气监测站的历史与即时数据,结合交通、地型、地物等相关资料一起分析,可针对城市内任一定点方圆1公里的空气品质提出预测。

微软的做法则是利用大资料(Big Data)分析技术,提供城市各角落的空气品质预测。郑宇表示,U-Air的作法是除了空气监测站的即时数据外,再结合5种异质资料集一起分析,包括气象资讯、交通流量、人群移动、城市据点(如车站、大楼、饭店、停车场、公园等等)及道路结构等资料。利用机器学习的技术,微软研究员从这些大量的资料中,找出空气品质的分析模型。再以这个模型为基础,就能依据即时的空气监测数据、交通流量等数据,以及各地区的地形、地物等资讯,提出城市任一地点的空气品质预测。

在我们採访的当天,U-Air系统推测微软亚洲研究院所在地的PM 2.5数值是131(微克/每立方公尺),属轻度污染程度,抬头朝玻璃窗望去,户外看起来有些矇矓,确实不太好。郑宇接着拿起手机,开启U-Air的Windows Phone App,其中已经预设其住家的位置,显示PM 2.5数值为153,比微软亚洲研究院还要高。

 

在採访当天,U-Air系统的即时预测数据显示,北京的空气品质状况不太好,有许多地区的PM 2.5值都已经达到中度污染的程度。

至于预测的准确率如何,郑宇开启另一项资料,显示当下北京市的PM 2.5预测准确率达到84%,而上海市的预测准确率则超过9成。他指出,U-Air系统每个小时会比对预测结果与监测站的数据,以验证分析预测的准确度。若只由监测站的历史资料来分析未来趋势,传统作法的准确率只有60%,而把监测站的历史资料结合上述的5种资料集,准确率就能超过80%。倘若不计算这5种资料集中的流量类型资料,那么准确率就会降到76%,「每多加一项资料集,都有它的价值。」他说。

 

U-Air系统每隔1小时会比对空气监测站的即时资料,以了解系统的预测准确率。由图中上海市的空气品质预测结果来看,多项空气品质预测都有9成以上的准确率。

U-Air像是神奇的空气品质算命师,但其背后的作法其实很复杂,郑宇表示,最主要的关键是大资料分析与异质资料融合。以前预测空气品质的方法是分析监测站的历史数据,只着重单一资料在时序上的变化,微软U-Air则是融合时间与空间数据等异质资料,透过半监督的机器学习模型来分析、预测。例如其中一个机器学习的模型,是分析交通流量对空气品质的影响,分析模型除了建立资料的时序关係,还要分析空间关係。

郑宇指出,大资料处理方法与处理能力非常重要。大资料的处理分法并非在一开始找出精确资料,而是用更模糊的方法,把许多资料汇整起来,以机器学习的方法,从许多资料中找出特徵,学习资料之间的相关性。也因为这些巨量、异质资料要放到一个大模型去分析,才能找出相关性,因此需要拥有巨量资料的处理能力,因为实际上处理的资料量非常大,而且计算速度要非常快,才能提出即时的分析。

微软U-Air系统在5分钟内就能分析整个北京市的空气品质,郑宇表示,分析速度快的关键不在于硬体设备,因为这套系统其实只靠1台伺服器运行,而且不是什么大型设备。真正的关键在于机器学习、资料管理与资料协同运算等技术的突破。他说,若没有大资料技术的突破,传统作法需要2、3个小时才能完成资料分析,对于即时空气品质分析这样的应用根本派不上用场。如果没有大资料的处理能力与可行的分析方法,是不可能实现这样的预测系统。

微软亚洲研究院目前尚未对外公开U-Air,不过相关的网站与手机App都已经实际在运作。郑宇说,未来的应用甚至可以透过手机的即时资讯,建议路跑者空气品质最佳的路线。

 

微软同时也开发U-Air的Windows Phone App,使用者由手机就能随时知道城市中各个地点的空气品质状况。这套系统未来甚至可以依据预测数据,建议空气品质最佳的路跑路线

抢攻大资料与分析应用,IBM推2U尺寸Linux系统专用伺服器

为了抢攻Linux平台伺服器市场,IBM在2015年10月推出了LC系列的Power Systems硬体伺服器,强调可针对资料分析应用环境,提供更快速与更便宜的伺服器选择,他们预计将提供三种产品形式:单路架构的S812LC,以及双路架构的S822LC商业运算版与S822LC高性能运算版等。

这三款设备都採用2U尺寸的机箱,其中S812LC可配置10颗处理器核心、1TB记忆体、每秒115GB的记忆体频宽,以及14台硬碟;而S822LC商业运算版和S822LC高性能运算版均可配置20颗处理器核心、1TB记忆体与每秒230GB的记忆体频宽。不过,其中的S822LC高性能运算版,还可额外搭配2张Nvidia Telsa K80的GPU运算加速卡。

根据IBM发布的红皮书,拆开前端面板后,我们可以看到S822LC可搭配硬碟数量较少,只有2台2.5寸硬碟,这里还有1个USB 2.0埠和状态灯号,其他空间留给4个散热风扇模组。
之后,是8张记忆体横向转接卡,每张可放置4支记忆体,因此总共有32个插槽。接着是处理器,这里可搭配2颗8核心或10核心Power8。
至于最后面则是5个PCIe插槽(其中2个可供应300瓦电力,能安装Nvidia GPU运算加速卡),以及2台1300瓦电源供应器。

S822LC的记忆体採用相当高密度的横向扩充模组的配置方式,图中是更近一点的观看角度。

这是S822LC的逻辑架构图,最上面我们可看到32支记忆体如何对应到2颗Power处理器,右下角则呈现了2台2.5寸硬碟的连接。

基于Power处理器,IBM表示LC系列伺服器搭配Linux作业系统,对于资料分析、云端服务与高效能运算类型的工作负载,可提供更高效能。

近年来,IBM一直鼓吹Linux on Power的伺服器应用型态,图中这是目前Power LC系列的底层硬体与伺服器虚拟化平台、作业系统之间的运作架构。

根据该公司内部测试,同样是能够承担Apache Spark大资料分析系统的负载(Ubuntu 15.04、Spark 1.4、OpenJDK 1.8),并且都配置256GB记忆体的组态下,若以搭配Intel 12核心Xeon E5-2690 v3处理器平台的2路伺服器作为对照组(24核48执行绪),搭配10核心80执行绪2.9 GHz Power8处理器的单路伺服器S812LC,成本号称可低于一半;若以用户端的存取效能性价比相比,S812LC可得到的每一美元的效能是对照组的2.3倍;再以同样的机箱空间来看,S812LC能多支撑94%的社交媒体分析工作负载。

图中是从后侧上方,来看S812LC的硬体组成,照片最上面是位于伺服器前方面板的12台3.5寸硬碟,在机箱内部后侧还有1个硬碟扩充模组,可放置2台3.5寸硬碟。
接着是5个系统风扇模组、32个记忆体插槽,以及1颗Power8处理器的配置。
最下方是有2台电源供应器与4个PCIe 3.0介面卡扩充插槽。

上图是S812LC的逻辑架构,硬碟的配置方式和S822LC不同,是从处理器连接的PCIe 3.0介面中延伸的SATA RAID控制器,由它来连接12台3.5寸硬碟。
而这个RAID控制器还可以透过PCIe介面或扩充子卡,连接机箱内部2台3.5寸硬碟。

在这项测试中同样搭配256GB记忆体,S822LC的处理器是2颗8核心Power8(16核128绪),对照组的处理器是2颗18核心Xeon E5-2699 v3(36核76绪),根据IBM测得的结果是,S822LC可得到对照组2倍以上的每核心效能和记忆体频宽,而性价比领先4成。

 

●原厂:IBM(02)8723-8888

●建议售价:厂商未提供

●机箱尺寸:2U

●系统组态:商业运算版:8335-GCA,高性能运算版:8335-GTA

●处理器:2颗Power8(8核3.32GHz或10核2.92GHz)

●记忆体:DDR3,最大可到1TB

●硬碟:2座2.5寸硬碟坞

●PCIe插槽:3.0规格5个(3个是x16,2个x8)

●作业系统:Linux on Power