半个世纪前的大数据时代

马云在最近的一次公开演讲中谈到市场经济与计划经济的比较:“我们过去的一百多年来一直觉得市场经济非常之好,我个人看法未来三十年会发生很大的变化,计划经济将会越来越大。为什么?因为数据的获取,我们对一个国家市场这只无形的手有可能被我们发现。”

(图片来自:http://data.ucop.edu/)

这听起来是一个相当大胆、甚至有科幻感的设想:如果能用深入基层的信息终端采集生产和消费数据,用全国连通的网络汇总经济数据,用数据分析软件识别和预测经济异常波动,在国家经济尺度上实时统筹和调整计划,那么近百年来计划经济面临的最大挑战“经济计算问题”有可能得到彻底解决,从而使计划经济有可能成为一种可行的、甚至更优于市场经济的方案。然而更显科幻的是,早在近半个世纪前的1970年代初期,在南美的智利,这样一个意在掌控全国经济的“大数据”系统已经被设计并实现出来了。

故事从1970年开始。在这一年的智利大选中,萨尔瓦多·阿连德被选为总统,并立即开始推行被称为“智利社会主义之路”的规划。在一系列的改革政策中,最为重要的是对大型企业(包括智利经济支柱的铜矿业)的国有化。这一改革进程很快遭遇了困难,原因不是企业主抗拒国有化,而是国有化进行得太顺利,政府很快发现自己没有足够的人才来对新生的国有企业进行整体调控。面对挑战,阿连德产生了一个大胆的构想:如果仅靠人不足以有效管理国家尺度的经济,再加上技术的支持如何?

(图片来自:http://t.cn/RadFix9)

阿连德看中的技术是控制论。1948年,控制论这门学科的创始人诺伯特·维纳将其定义为“关于动物和机器中控制和通信的科学”。在二战中,控制论的理论与技术被用于研发防空火控系统——人手操作的高射炮很难准确命中敌方战机,而维纳设计的计算机系统则可以采集敌机飞行的数据、并实时预测敌机的飞行路线、进而自动操作高射炮击中敌机。维纳事后总结,这项研究的核心在于“预测未来”:“预测一个消息的未来,就是用某种算符去运算这个消息的过去……最优预测问题的解决仅仅取决于要加以预测的时间序列的统计性质”。这门新兴学科让阿连德看到了希望:如果控制论可以用于实现防空火控系统这样实时的、复杂的、涉及大量人为因素(驾驶战机的都是由经验丰富且绝对不想被击落的飞行员)的自动化系统,它是否能被用于其他实时的、复杂的、涉及大量人为因素的领域——比如说,经济计划?

在寻找合适的技术领导者的过程中,阿连德的政治乌托邦愿景也吸引了英国控制论学者斯塔福·比尔的兴趣。尽管美国政府对“社会主义”这个字眼极度紧张,不惜以各种政治、经济手段扼杀阿连德的改革政策,阿连德所构想的其实是介于美苏两个超级大国、两种意识形态之间的“第三条路线”,一种既能全面提升智利经济和人民生活水平、又不损害智利保持四十年的民主自由氛围的两全方案。1971年,比尔和阿连德政府开始了合作,在这个政治乌托邦愿景之上又加上了一个科技乌托邦的愿景:构建一个计算机系统来实施调控国家经济——在互联网普及之前二十年。

以维纳为代表的控制论学者经常用人体作为类比。例如维纳这样谈论一个基本的控制论系统:“为了能对外界产生有效的动作,重要的不仅是我们必须具有良好的效应器,而且必须把效应器的动作情况恰当地回报给中枢神经系统,而这些报告的内容必须适当地和其他来自感官的信息组合起来,以便对效应器产生一个适当的调节输出。”比尔则对这一结构进一步深化,提出了“可生存系统模型”的概念。在这一模型中,组成一个系统的各个部件被分为5级子系统:系统1到系统3分别负责感知、信息传导、以及监控和协作的功能,系统4和系统5则负责常规运作层面之上的、有目的的管理和治理职能。比尔用生理学的类比来解释这个模型(如下图),并认为同样的模型也适用于企业和国家经济。

比尔的另一个理论基础是他在1970年的一次主题演讲中提出的“自由机器”理论。所谓自由机器,是这样一种社会-科技系统:它以网络的形式运行,而非层级结构;其中作为行动基础的是信息,而非权力;各个领域的专家知识和实时的信息反馈驱动决策,从而消除官僚体制存在的必要性。比尔甚至构想了在政府机构中这样的自由机器如何实现:它应该是一系列的指挥室,每个指挥室中实时接收和呈现来自各个子系统的信息,指挥室中的各领域专家则基于这些信息提出猜想、并运行模拟程序来验证这些猜想,由猜想汇集而成的决策再从指挥室实时传递到国民经济第一线。

基于可生存系统模型和自由机器理论,比尔的团队向阿连德政府提出了一个系统设计的方案。在他们建议的系统中,国有企业和政府之间会新建起数字化通信的渠道,用于传输实时的生产数据;这些数据随后被送进统计软件程序,用于预测工厂的生产效能,从而使政府能够提前识别和应对异常情况;系统中还包含一个计算机实现的经济模拟器,让政策制订者能够在真正实施他们的经济措施前先在模型中测试;最后,他们还提议建设一个充满未来感的指挥室,让政策制订者们能够聚集在其中,快速掌握国民经济运行的状态,并在数据的支持下快速做出决策。

只有当我们从资料图片中看到这个指挥室,我们才能直观地感受到比尔所说的“未来感”是什么意思。这个建成于1972年的指挥室看上去就像《星际迷航》里“企业号”的舰桥,其中大量塑料与玻璃纤维材质的使用、环绕四周的显示屏、座椅扶手上简洁的操作按钮,都与这个项目的愿景一样,充满了不真实感,就像一部科幻电影。

只是,这不是科幻电影,而是历史上真实存在过的一个IT系统。新生的社会主义智利政府和来自英国的科学家冀望基于这个系统平衡个体自由与自上而下的控制:既保持个人的主观能动性,又使个体为组织(企业或国家)的整体利益共同奋斗、乃至作出必要的牺牲。在智利之外,很多进步人士相信智利能通过经济上的改革探索出一条政治上和意识形态上的“第三条路”,甚至成为冷战的一条出路。阿连德和比尔的IT系统会走向何方,历史在静静注视。

站在近半个世纪之后回望这段尘封的历史,我会感到一阵莫名的激动。今天IT技术飞速发展,然而我们看见的却是技术日益被掌握在极少数人手里、并被用于为这部分人牟利。技术发展越是日新月异,这道鸿沟就越是触目惊心。难道IT技术的发展就注定伴随着不平等的加剧?难道程序员统治的黑暗世界是无可避免的唯一未来?这一前景让作为技术工作者的我感到灰心。而阿连德与比尔、一个智利人与一个英国人、一个政治家与一个科学家、一个政治乌托邦梦想与一个科技乌托邦梦想的交汇处,这段几乎已被遗忘的历史让我们重新看到希望:为技术赋予政治和社会的正面意义、用技术创造更公正的世界,思考这个问题的不是只有我们。

如果今天的一位IT架构师来设计这个名为“Cybersyn”的系统,也许他会参考IBM的商业技术趋势研究提出一个方案,其中个人移动设备和物联网设备被用于在工厂采集实时的生产数据,数据通过互联网汇集到位于云端的数据库,用大数据和机器学习技术对数据进行加工、分析和预测,并借助社交网络创造政府、企业与工人和谐共处的社会与经济环境。

尽管互联网和手机的时代还有几十年才会到来,比尔提出的方案却与现代的架构方案如出一辙。于是我们不禁要好奇:他所领导的这支团队会如何构建连接厂矿与中央政府的网络,又会用什么技术来实现数据分析与预测功能?当比尔宣称Cybersyn会同时兼顾国家经济运行效率与个人的民主和自由,什么技术能让他掌握全国民众的情绪涨落?


更多精彩洞见,请关注微信公众号:思特沃克

Share

信息爆炸?云上的机器人连接一切

前段时间,一条科技新闻惊爆整个互联网:微软举债262亿美元现金收购LinkedIn,创下科技史上收购价第三高的纪录。

为何要收购?微软CEO Satya Nadella在公开信中指出,“This deal brings together the world’s leading professional cloud with the world’s leading professional network.”依托世界上最大的专业化服务云与最大的专业化关系网,微软与LinkedIn走到一起,应用、数据与人连接在一起,将有可能构筑一个前所未有的智能、专业化生态。

无独有偶,在同一天的苹果WWDC大会上,苹果一口气发布了MacOS、iOS、WatchOS、tvOS四大操作系统。其中,最受关注的却是Siri、iMessage等软件的开放API。

1-api

从iPhone 4S时代走来的Siri第一个扛起“AI个人智能助理”的大旗,却接连被Microsoft Cortana、Amazon Echo、Google Allo等甩在身后。于是,苹果正式发布了Siri API,不久之后便可用它叫车、外卖、搜图、支付等。这一次,苹果希望以Siri为中心,将应用、数据连接在一起,重新构建真正的智能生活。

人类的历史就是一部信息传递与处理的历史。长城上的烽火把帝国的边疆阡陌连在一起,丝绸之路上的商人旅客让欧亚大陆连在一起,电话让登月的人类第一次从太空与地面进行沟通,互联网更是让人足不出户了然天下事……信息的载体从光、人、物、电磁波进化成了现代0和1的bit数字。与此同时,信息的范畴外延无比放大,从军情公文、家书鱼雁、各种软件数据到量化物体(物联网)、量化人类自己(可穿戴设备)……信息外延到了宏观的宇宙世界,又触及了微观的纳米世界。两波浪潮碰撞在一起,人类面对的是一个海量、碎片、实时、数字化的信息爆炸时代。

“弱水三千,取一瓢饮”,信息爆炸时代,人类要如何完成信息的高效处理?曾经的人类通过层级化的组织结构来小心地控制信息的输入与输出,现在的人类通过资源池化的信息引擎来完成信息的屏蔽过滤。然而,当万物连接的信息洪潮遮天蔽日地过来,曾经的组织和个体仿佛风雨中飘摇的枯叶一般弱不禁风,人类需要如何应对?在电影《环太平洋》中,面对宇宙中的洪荒巨兽,人类的机甲猎人被摧枯拉朽。这是否是人类的最终命运?

%e5%b1%8f%e5%b9%95%e5%bf%ab%e7%85%a7-2016-09-13-%e4%b8%8a%e5%8d%8811-47-45

问题太宏大,人类仍然需要回顾过去的经验,从历史的幽光中挖掘可能的解决办法。刘慈欣在科幻作品《三体》中讲述了一个科幻的故事:秦始皇的千万大军,通过黑白小旗和士兵矩阵,组建了与、或、非门,设计了一款人体计算机对微积分方程进行求解。这让我们不由沉思——低效的人类组织和协作,只要通过一些简单的规则,就可以对复杂的问题进行计算;同样,基于这些简单的规则,简单的元组件组合在一起,就能代替低效的人类组织和协作。

我们再来看看传统信息传递和处理的典型案例“长城烽火”。当敌人侵犯,守卫发现敌情,点燃烽火;附近的烽火台守卫看到烽火,点燃第二级烽火……以此类推,直到军队支援,消灭入侵敌人,消灭险情,烽火熄灭。整个过程主要涉及了如下的要素:

对象 职责 角色
烽火 烽火即警报,点燃烽火即为告警 信息协议,包括接口和格式
守卫 向烽火台网络里面输入敌情的告警信息 信息输入者
军队 处理烽火台网络输出的敌情告警信息 信息处理者
烽火台网络 确保敌情告警信息的正确传递和处理 信息传递、升级和协作体系

因此,我们可以抽象出信息处理的四个基本要素:协议、监控器、处理器,以及基于协议、由监听器和处理器组成的网络。无论是烽火狼烟,抑或是模电数电,都是基于下面的范式进行信息的采集、传递和处理,区别只在于效率和规模。面对“海量、碎片、实时、数字化”的信息洪潮,人类的终极信仰跃然纸上:云、机器人、API。

1-cloud

KK在《失控》中指出,“人造物越来越接近生命体,生命体越来越程序化。”连接和智能成为时代的主旋律,微软、苹果、腾讯、谷歌、阿里、百度……这些科技界巨头们无不提前进行结构性布局。多边平台的参与者越多,边际成本越低,网络效益最高。这也是为什么我们看到,微软不惜举债收购LinkedIn和Skype、苹果将Siri作为下一代个人智能助理的核心、腾讯将微信定位为“连接一切”……

外面的Interface很简单,但背后不显山不露水的恰恰是里子——微软的Azure和Office365云、苹果的iCloud、腾讯的腾讯云……微软、苹果、腾讯背靠各自的云和服务,坐拥无数的用户,或许正如唐太宗看见新晋进士鱼贯而出,得意洋洋地说道,“天下英雄,入吾彀中矣”。

尾声

在行文结束之前,我们再回顾一下本文的主要观点:

  • 人类需要处理的信息源将来自于自然万物:机器、软件应用、人体自己等等;
  • 海量、碎片、实时、数字化信息处理的核心在于云、程序性机器人和API接口;
  • 领先的科技公司都在这一战略逻辑之下进行结构性布局:建设云平台、将各种服务固化为程序性机器人、扩展与人类的信息输入和输出接口。

如果说微软通过Azure、Office365与LinkedIn连接是帮助职场专业人士更高效地完成办公信息的传递和处理,苹果的Siri API连接是帮助普罗消费者更高效地完成个人生活信息的传递和处理,软件研发运维的信息传递和处理如何实现呢?我们能否让每一位ThoughtWorker,从TechOps、到PS、再到TOC人员,都生出三头六臂?

 

Share

云与大数据,商业创新的加速杠杆

引言

「互联网+」的浪潮正在冲击传统的商业模式和商业组织。支付宝与天弘基金开发的余额宝在短短一年之内,吸引用户数超过1个亿,资金量超过5742亿,一跃成为全国最大的货币基金 。2013年成立的菜鸟网络将传统的「四通一达」快递公司整合进其统一信息云平台,迄今已经实现了全中国超70%快递包裹的跟踪管理微信在短短三四年之内,月活用户量达到6亿,2014年春节顶峰时间每分钟微信数量超过1000万条,与此同时,传统电信运营商的短信量剧减41.57% 。这些新兴公司,背后依托着云与大数据,更快地响应市场,建立起巨大的竞争优势,从而颠覆了传统的商业公司。

商业史是一场关于「优胜劣汰,适者生存」的进化史,「唯有偏执狂才能生存」 。进入21世纪,商业公司的更迭变得愈加频繁,「企业的平均寿命从1920年的65年降到了2015年的15年」 。初创公司更是如此。哈佛商学院教授Shikhar Ghosh的研究表明,在美国风险投资进入的初创企业中,四分之三以破产告终 。无论经验丰富的成熟公司,抑或充满活力的初创公司,在面对商业市场的不确定性时,无法建立有效的竞争优势,难以延续或扩张。在这个高度不确定的时代,第一时间拥抱云与大数据,建立商业创新的先发优势和加速杠杆,是所有企业CIO乃至CEO的必修课。

商业创新的挑战和企业策略

大量的案例表明,创新是商业公司建立竞争优势、持续扩张的关键方法。然而,创新者如过江之鲫,成功者寥寥。美国市场研究公司CB Insights通过分析101家科技创业公司的失败案例,总结出了创业失败的20大主要原因,其中「没有市场需求」以42%的比例排名榜首,「耗尽资金」以29%的比例位居第二 。面对「创新者的窘境」,商业公司最迫切的目标就是在人力资金等资源投入的有限时间之内,尽快找到创新产品与市场的契合点,建立竞争优势。emagazine pics-09

图1. 创业失败的20大主要原因(图片来源:https://www.cbinsights.com/blog/startup-failure-reasons-top/)

然而,传统商业公司的产品研发和运营往往以年或者季度为周期单位,公司业务、技术等部门的管理者们根据前一周期研发经营的情况,整理后一周期的目标和计划。一是研发周期漫长,运营的反馈很难及时到达研发部门进行调整,二是产品的概念来自于业务部门的专家意见,没有进行用户问题的真实验证,需求存在偏差。商业创新闭环的缺失,导致创新容易落后于时势,抓不住市场需求,徒然耗尽公司的资源和时机。

无论针对新兴市场的探索模式,抑或针对已有业务的拓展模式,商业产品的创新需要打通从概念到开发、运营的端到端闭环,形成快速的反馈。如何能够有效地支撑精益的商业产品创新?作为组织的CIO,需要尽早解决两个关键挑战:

  • 如何快速构建可工作的产品?
  • 如何快速验证并推广产品的概念?

幸运的是,随着技术的爆发式发展以及技术标准的演进,组织的CIO们有了更丰富的选择和更高效的工具。

云加速商业创新的构建交付

在IT技术领域,集约化与专业化成为技术服务市场的发展趋势。越来越多的专业软件服务团队颠覆起传统的基础设施或者软件服务,开发并公开运营标准的服务组件或者云服务,建立起庞大的生态系统。据ProgrammableWeb统计,截止2014年公共API(Application Programming Interface,应用编程接口 )的数量超过了10000项 。据分析公司Bessemer的统计,市场上存在着数百家成熟的云服务厂商在提供各类云服务,涵盖了从开发者服务到最终用户服务的各类场景。

以云计算的引领者Amazon WebService为例,我们来看看云服务提供了哪些产品服务 :

emagazine pics-10图2. 亚马逊云产品服务(信息来源:https://aws.amazon.com/products/)

  • 快速的研发测试环境:AWS EC2弹性云主机将一台新服务器的创建缩短到1分钟,基于Docker(容器虚拟化)的EC2 Container Service则能在几秒钟内启动数千个容器。
  • 高可用的弹性生产环境运维:AWS EC2满足99.997%的SLA服务标准成本降低到每小时只有数美分
  • 智能的业务流程引擎:AWS Lambda提供了标准的业务流程引擎,基于其API只需要几行程序即可创建一套比较完整的业务处理流程。
  • 丰富的基础性服务:AWS上也提供了移动应用后台平台(简称MBaaS)、物联网IoT SDK、智能分析API等。

借助于标准的云服务与公共API服务,产品创新依赖的诸多功能模块、基础环境、开发活动等都成为「标准件」,产品的构建过程成为了「搭积木」的过程。商业产品创新的构建交付,从某种意义上变成了业务问题,而非单纯的技术问题。

斯情斯景,组织的CIO需要有大智慧,跳出思维定式,将云服务和公共API视为工具箱的一部分,从生态系统的角度来思考产品的构建策略,满足商业创新产品快速构建和投放市场的目标,获得真实用户的反馈和验证。

大数据加速商业创新的分析验证

在传统的商业组织内部,数据的采集、存储、分析和展现往往会由专门的数据分析部门和IT部门来负责。业务部门提出分析的需求和目标。数据分析部门设计相关的数据分析模型。IT部门进行数据的埋点、采集、清洗和结构化。数据分析部门再测试和调整数据模型,争取在一定的拟合度之下,收敛到业务部门的目标。整个周期往往从数周到数月之久,牵扯大量的人员和资源投入,如服务器计算资源、协作成本等,只有很少的组织才能承担

随着大数据技术的成熟,通用的数据挖掘分析算法被数据科学家们封装成了单独的程序模块,数据挖掘分析的门槛大大降低。业界成熟的Google Analytics、Hadoop、Mahout、Spark内置了大量的数据分析算法,能够满足大部分的分析场景和需求。如下图所示,Hadoop生态系统几乎满足了大数据处理的全部场景。

emagazine pics-11

图3.  Hadoop生态系统 (信息来源:http://hadoop.apache.org/)

大数据具体提供了哪些典型功能?

  • 用户行为分析:分析真实用户的真实行为,了解用户「在何时哪个页面离开网站」、「从哪些渠道进入网站」、「购买最多的产品是什么」等;
  • 系统异常分析:分析系统的异常,及时预警,提高系统的可用性和业务连续性;
  • 系统安全审计:分析潜在的安全风险,避免恶意入侵、代码注入等行为。

因此,千人一面的网站服务向个性化转变,单一网站渠道向全渠道转变。粗放的运营管理更加精细化,从Google、Facebook等互联网公司传出的「增长黑客」(Growth Hackcking) 职位成为互联网时代的运营标配。增长黑客们建立产品业务的运营转化模型,专注于通过快速的数据与试错提高业务的用户量、活跃度、粘性等指标的增长。

商业组织拥抱云与大数据的模式

云与大数据对于商业创新的成功发挥着关键性的作用。《荀子•劝学篇》说,「君子生非异也,善假于物也。」善于利用杠杆效用的商业公司,能够避免「重复制造轮子」的成本和风险,从而加速了产品的创新和市场竞争优势的建立。

那么,CIO要如何在组织里面引入成熟的云和大数据技术呢?根据我们的实践经验,商业公司对云与大数据的采纳策略,大体上可以遵循如下的模式:

图4.  企业云与大数据应用模式

  1. 开发测试云模式:以开发测试的环境和流程为应用目的,采用云进行开发测试,大幅节约研发成本,并缩短产品上市时间。
  2. 新业务运维云模式:把所有新的应用和服务都放到云平台,而不再使用遗留基础设施或采购新硬件;利用云的快速弹性提升创新业务的响应性。
  3. 大数据分析云模式:根据计算的需要,快速灵活增减大量分析计算资源,使用大数据平台提供标准的分析算法和API,降低大数据分析对资源的依赖和时间成本。
  4. 移动应用支撑云模式:通过MBaaS等的支持,完成应用的部署、管理,并实时获取管理的参数和指标,能够快速地打造和部署移动应用。
  5. 核心企业级应用云模式:使用云上其它服务商提供的企业级ERP、CRM、数据库等服务,或者将这些企业级应用搬迁上云。
  6. 数据中心云升级模式:借助云服务商实现数据中心的整合、迁移和变更,提升现有数据中心的效率、可用性、可靠性。
  7. 企业整体云化模式:在云平台进行应用的开发,进行混合云的部署等,将通用的IT能力抽象为统一的云平台,应用的生命周期只需要使用云提供的服务和API。

云与大数据绝对不是一蹴而就。由于组织文化、能力模型的差异性,所以企业CIO们需要针对自己企业的特点对症下药,选择合适的模式切入。一方面,CIO可以在内部寻找合适的变更种子;另一方面,可以借助于外部业务的压力对云与大数据进行初步的尝试。必要时,企业可以寻找外部专业服务公司的帮助,减少新技术与方法的引入风险,提高云与大数据的落地效率。

商业组织拥抱云与大数据的案例

背景

在互联网金融的浪潮之下,某民营银行希望针对个人客户和企业客户的完整生命周期,为个人和企业客户提供定制化、全方位的惠民服务。围绕着这一目标,该银行采取了诸多创新项目。其中之一便是结合「银行级安保」的概念,采用国密算法向个人与企业客户提供安全可靠的网络保险箱移动互联网产品。

云服务加速了创新产品的构建

该网络保险箱的交付面临着如下的挑战:

  • 如何让产品在3个月之内完成所有模块(手机App、网站、存储等)的上线?
  • 如何让产品满足互联网的用户体验,比如图像、语音识别、社交分享等功能?
  • 如何让产品能够随着用户的增加,无缝扩展存储的容量(目标容量为50T)?

面对上述的挑战,ThoughtWorks推荐该银行其尽可能采用成熟的云产品服务,缩短新产品的上线周期。因此,该银行一方面选择了敏捷开发方法,通过迭代和持续交付减少需求变更以及等待的浪费;另一方面,该银行使用了ScaleWorks云解决方案:

  • 开发测试云,提高了开发测试的效率,减少等待资源的浪费;
  • 混合云,开发、生产分别使用不同服务标准的云平台,提供一致的管理;
  • 分布式云存储节省了昂贵集中式存储的采购,无缝支撑未来的扩展。 此外,该银行还选择了大量的第三方云服务,如card.io提供的银行卡图像识别SaaS云服务,减少了自研的成本和风险。
大数据分析支撑了创新产品的运营

网络保险箱产品上线之后,两个运营的新挑战又浮现出来:

  • 产品App的性能如何优化,提升用户的体验?
  • 用户的行为数据如何挖掘,提升产品的用户数和规模?

该银行将应用的日志和其他运行的数据一起采集、汇总,使用ScaleWorks Analytics大数据方案进行分析。ThoughtWorks的数据专家与该银行的业务人员、运营人员以及开发人员沟通,对采集的数据进行清洗、结构化、分析和可视化,设计了「产品是否存在性能瓶颈」、「用户量是否保持增长」、「用户活跃度是否保持活跃」、「用户来自哪些渠道」等一系列指标。

结果

三个月之后,互联网保险箱产品顺利完成了上线。仅在上线第一周,超过100个真实用户,上传了接近10G的文件量——完成了产品从0到1的跨越。该银行的CIO表示,「没有云和大数据,我们不可能在短短三个月之内完成产品的上线和推广。」

结语

由于来自新兴商业公司的「门外的野蛮人」 ,商业公司面临着比以往任何时候更大的压力和挑战。「生存,还是死亡?」在这个竞争异常激烈的时代生存,CIO乃至CEO都需要更加深刻地意识到创新的紧迫性。如何提高商业创新的效率和效果,在云与大数据的时代,CIO需要更加深刻地认识到技术的价值。引入合适的技术和工具,借助外部专业服务公司的能力,在商业公司内部打通端到端的创新从概念到落地、到运营的闭环,是CIO乃至CEO的最高优先级之一。

《荀子•儒效》中提出,「不闻不若闻之,闻之不若见之,见之不若知之,知之不若行之」。商业公司的管理者们,「一万年太久,只争朝夕」,是时候拿起云与大数据的加速杠杆,让自己立于市场竞争的不败之地了!

Share

小数据:理论和架构

大数据是当下最热门的IT主题之一。据麦肯锡的分析,大数据能使信息更透明、能让决策者获得更精确翔实的绩效信息、能针对客户群体提供更准确的定制、能提升组织决策能力、能帮助开发下一代产品和服务。新时代里与互联网联结的组织不论大小,都需要这些能力。

然而与此同时,大数据的“大”并非适用于所有组织。Gartner认为,大数据具有“3V”的特征:多样性(Variety),数据来自多种不同来源、具有多种不同形态;速度(Velocity),数据形态和呈现形式的变化快且频繁;量级(Volume),数据量非常巨大。然而对于众多的中小型企业及非营利组织而言,这三个特征有两个未必适用。很多中小型组织只有为数不多的几个IT系统,数据都保存在为数不多的几个关系型数据库中,数据量不超过数百万条记录。只有变化速度快这一特征,对于中小型组织仍然适用。从这个意义上,这些中小型组织需要的是一个“小数据”解决方案:

小数据:聚焦中小型组织和新兴业务,在数据量较小、数据来源较简单的情况下,提供非常灵活、非常简便易用、使用过程中对IT技能要求非常低的数据分析和商业智能,为应对多变且未知的外部环境提供决策支持。

传统上,很多小数据场景的分析和商业智能需求以“报表”的形式呈现在IT项目中:在开发OLTP系统的项目中列出一组报表需求,由交付OLTP系统的团队以直接SQL查询的形式实现报表。这种做法贴合了数据量小、数据来源简单的特征,但损失了灵活性,报表的定制和修改需要技术人员介入,因此又无法满足对速度的要求。为了赢得灵活性,小数据分析也同样需要首先建模OLAP Cube,然后通过不同维度的切片和钻取进行分析。

什么是Cube?按照维度建模方法,数据可以分为“事实”和“维度”两类。事实数据代表“发生了什么事”,维度数据则从各个角度描述这件事。如果以电商为例,事实数据是“销售记录”(卖了一个东西),常见的维度数据可能包括“产品”(卖的是什么)、“门店”(在哪里卖的)、“时间”(什么时候卖的)、“售货员”(谁卖的)、“顾客”(卖给了谁)等等。不难想象,事实数据表将只有一个主键、一个值、以及一大堆外键指向各个维度表;维度表也可能有外键再指向更多的描述性的子维度表(例如“产品”有外键指向“类别”)。于是我们就会得到一个星型表结构(或叫雪花型表结构)。

Star-schema-example

 

星型表结构的优势在于,分析操作会变得非常简单:你关心哪些信息,就直接用JOIN子句把这些维度表关联进来;只要在JOIN子句里指定WHERE条件,就可以快速缩减结果集。在星型表结构里,一个事实会被若干个维度修饰,因此可以把整个数据集想象成一个立方体(或超立方体,当维度多于三个时)。例如当只考虑“产品”、“城市”、“时间”这三个维度时,“销售记录”的数据集就可以被建模为一个立方体。

QQ20160126-0@2x

随后就可以在这个立方体上对数据进行各种分析。例如你可以锁定“城市”这一维度,从而得到“某城市各种产品历史销售报表”——“锁定某一维度取值”这一操作也叫“切片”(slice),因为它在这个例子中产生的效果就是从三维的立方体中切出一个二维的数据平面。同样的,我们也可以从“产品”维度切片,从而得到“某产品各市历史销售报表”。当维度具有“分级汇聚”的特性时,我们还可以进行“钻取”(drill)操作,例如当“地区”维度分为“市”和“省”两级时,我们就可以在“地区”维度上进行钻取:首先从产品维度切片得到“某产品各省历史销售报表”,然后选择一个省下钻得到“某产品在某省内各市历史销售报表”。

小数据系统设计原则1:建模一个Cube,就可以快速实现一系列分析操作(及对应的报表)。小数据系统应该支持简便且易于修改的Cube建模。

基于这个设计原则,我们可以大概推知小数据系统的架构:首先,根据指定的Cube描述信息,把业务数据建模成Cube;然后,通过RESTful API对Cube进行切片、钻取和聚合等操作,并取回二维平面表或透视表形式的结果集;最后,根据指定的报表定义信息,把结果集渲染成报表。

architecture

从上图不难看出,在这个架构中,必须由用户(不论是开发者或最终用户)提供的信息只有三项:(1)Cube的描述;(2)数据分析操作对应的URL;(3)呈现分析结果的报表定义。并且第三项信息(即报表定义)与具体业务是完全解耦的,因此理应可以用分别的开源软件组合形成轻量级的小数据解决方案。在下一篇文章中,我将具体介绍一个基于开源软件的小数据解决方案实现。

Share