数据服务系统的定位

数据服务系统的定位

作者：张颋 版本：V1.0 最后更新日期：2013/2/17

数据服务领域的工作是计算密集型的，相对于其他IT系统，数据服务系统的计算往往更具复杂性。例如，数据服务系统内的作业较少在1分钟以内结束，有时候甚至要花费超过一周的时间完成。

在提供数据或分析时，我们常说数据质量是第一重要的：结果不可信，无论表达方式有多么花哨都是徒劳，获得高质量的数据往往是要付出大量计算代价的。举一个相对简单但实际上并不简单的例子，不妨考虑一下如何验证身份证号码是否合理？不难发现，多一些计算，少一些问题。

一个值得思考的问题是机器究竟能在多大程度上代替人类。2011年情人节那天，第三次人机大战上演，Watson在智力问答节目中与两位人类选手相遇，并最终获胜。Watson作为一台耗资300万美元的机器，能耗是85KW；而人类选手能耗是20W。Watson是否代替人类的问题可以简化为用85,000W战胜20W是否值得的问题。

在考虑数据服务系统的定位时，不能忽视人脑相对于计算机而言，也是有重大优势的，例如－－低能耗。低能耗（省电）正是ARM在手机芯片领域战胜Intel的关键因素之一。因此，我们在构建系统时不必以机器完全代替人类为目标。

在进一步明确数据服务系统的定位之前，我们需要抽象出描述系统特征的关键字－－“计算”。这可能与现有的理论有所不同。回忆一下“数据仓库之父”Inmon对数据仓库的定义：“一个面向主题的、集成的、随时间变化的、非易变的用于支持管理的决策过程的数据集合”。在实际构建企业数据仓库时会发现另外一个人Kimball，他与Inmon相比，走的是另外一条道路。与其关注Kimball和Inmon之间的分歧，不如关注数据仓库项目的成功率。应当承认，完成一个数据仓库的建设，理论和技术都是成熟的。以某公司为例，YYYY年投资$.$$亿，实现了基于A系统的数据仓库部署。A系统在Gartner-DW魔力象限中长期居于领导者地位，的确是帮助某公司“完成”了数据仓库的“部署”，但是之后长达N年的时间里，这个“数据仓库”口碑不佳、收益为负。这正是通常数据仓库项目所面临窘境的真实写照。用“计算”的观点可以很好解释这一切。出于计算的观点，我们将交易系统和数据仓库系统或者别的什么系统都视为同一个平台的不同组成部分，这些系统作为“计算环境”而言并无本质不同。一般数据仓库项目面临窘境的真正原因是过于关注数据的剥离，而忽视了计算环境的构建。继续以某公司为例，YYYY年购买了A系统，我们有理由相信那个时候的确是解决了许多问题，但是人与机器的一个重要的区别就是人有创新意识而机器没有，接下去不难推测原有系统很快便跟不上用户分析思路变化的形势了。

在最初构建A系统技术体系和组织结构时，并没有为方便系统重建而设计，从而开发人员只能在原有系统上不停的增加冗余，接下去某公司面对的应该就是计算资源枯竭的难题了，而扩充一个节点的成本又是惊人的。ZZZZ年某公司引入了B系统，大大降低了扩充节点的成本，也就是降低了计算的成本，这是朝着正确的方向迈进了一步，但是不便于重建的计算环境问题依然存在，m个节点扩充一倍是容易的，10*m个节点扩充一倍相对就困难了，我们有理由担心B系统也难逃被多变的需求击败的命运。

现在可以提出数据服务系统的定位了。数据服务系统应当是云计算平台的一部分，用较低的成本保存长期的历史数据，提供面向分析的可重建的计算环境、保存计算结果，提供安全、高效、稳定、可控的信息查询和数据下载服务。