大数据项目架构思考（一）
大数据概念到今天，炒作的最高风口已经过去了，根据Gartent发布的HypeCycle曲线，大数据已经处于炒作顶点之后的衰退期。
HypeCycle曲线
而从HypeCycle曲线定义的阶段来看，越过炒作顶点的技术，通常被认为已经满足了技术可行性，进入了可实用的阶段。
所以，对于大数据项目来说，技术上已经没有什么太大的问题了，无论从软件还是从人员来说，该填的空也都填得差不多了，剩下就是看整体项目建设中该考虑如何落地的问题。
项目如何实施，第一步应该怎样走？为什么这样走？怎么样才算成功？
大数据不缺情怀，汗牛充栋的大数据情怀之作，让大家打足鸡血，甚至产生宗教崇拜情节——不用大数据的都是邪教，应该绑起来烧死：
技术上也不缺：各种Hadoox权威指南，Sparx权威指南……啥的书，也能够垒成书山了，但是恰恰漏掉了大数据整个项目应该如何实施的？
安装软件工程的模式，最重要的就是三个字“里程碑”。（说起这三个字，想到虾神才毕业时候做项目的经历，动辄就是里程碑发版本，加班加得头发一把把的掉……差点就聪明绝顶了）。
在一个单位内部，如何实施一个大数据项目？如何确定这个项目是成功还是失败了，业界有个主流的观点，认为大数据项目的里程碑，应该在下面三个关键点上面：
第一个节点称之为：系统轻载，通俗说起来，就是轻装上阵：
众所周知，当一个系统运行到一定时候，系统中会存储大量的历史数据，而数据库在访问由1万条记录组成的表的效率，和访问由1亿条记录组成的表的效率，那是完全不在一个数量级上的。
历史数据的存放一直是个很大的问题，特别是电商、银行这种，需要进行永久性存储业务数据的企业来说，代价一直是很高昂的。
所以这个节点，是很多企业的“刚需”，而对于我们空间信息技术相关的企业来说，暂时还没有那么大的“痛楚”，那么这个阶段的刚需，就是“数据化石”的激活了。
地理信息相关的企业（或者应用单位）通常会收集很多很多的数据，而且还会做很多数据的处理——这样导致了一个问题，在收集过程中，或者处理过程中，会生成非常多的过程数据（比如我见过的一个单位，在对矢量数据进行处理的时候，一天甚至能发出100多个版本）。
这些数据，要么因为存储空间不够或者认为意义不大，而直接丢弃了，要么就存储在了磁带机或者冷备硬盘上仅用于历史存档。而这些历史存档数据又因为技术上的“不可（不方便、不能快速）”访问，变成了所谓的数据化石。
这些数据化石里面，保留了无数的有价值的数据，举个简单的例子：
某领导突然过来问：我记得当年（五年前），xx在做xx区域的时候，曾经出过一个专题图，谁那还有?然后大家一阵鸡飞狗跳，（几小时 or 几天后）好容易在哪个灰尘20cm厚的仓库废品堆里面把那个专题挂图给找出来了。领导看过之后，嗯，不错，这几个地方重新改一下，再做一版拿给我……
这种情况，大家的表情肯定是：
五年前昙花一现的专题图成果（已经打印成了挂图），我去哪找原始数据啊？
大数据平台的构建，在第一阶段，就应该是解决这样的一些问题。
那么第二个阶段是什么呢？
第二个关键点，就是形成应用的闭环。
软件企业开发软件（或者项目），业务单位使用这些软件（或者应用），那么在使用的过程中，自然会生成大量的数据，这些数据有的是工作过程中产生的（业务数据、工作记录……），也有可能是软件运行产生的（操作日志、系统日志、维护日志……），这些数据，一旦收集起来，对软件厂商下一步软件开发提供建议。
如果能够对整个软件运行进行监控，那么很容易的获取所有功能模块的用户操作信息，包络使用习惯、操作步骤，使用频率等等，后期就能够针对这些内容进行更精准的优化。
那么对于政府或者所谓公共服务性质的单位呢？比如国土部门可以通过对某些查询的频率（比如那些表格的哪些字段，何种查询方式，需要何种结果），来决定数据库的优化策略；或者针对兄弟部门服务需求或者上级领导提出的要求（汇总数据、制作专题图等其他业务需求），来优化整个系统的功能设计。
说到这里，其实很多的实际应用场景与产品经理的设计是有冲突的。下面可以给大家举个小例子：
程序员在做汇总查询功能的时候，通常会按照数据计算引擎的模式，给出极高精确度的结果，比如要统计某个区域内的地块类别汇总，程序员设计的方式是鼠标在地图上一拉框，系统就会自动去计算这个区域内所有地块信息的累加和，最后给出的来的结果精确到小数点后面6位数……
但是随着数据体的变大，这种操作可能会非常非常慢……比如要统计整个长江流域的非农业用地面积，可能就需要几个小时设置几天的时间。
如果有一天，领导过来问你：从xx路到xx河，一共有多少亩农用土地？如果你花1小时后告诉领导，一共有44万3652.173亩……和你花三分钟就直接告诉领导，有44万3千多亩，甚至1分钟之后，就告诉领导，一共有40多万亩。那么你觉得领导会对哪个结果更满意？
因为领导并不是要你给出一个精确到小数点后N位的答案，他问你的时候，可能只需要一个大概的数字，与他现在正在进行考虑的某件事，形成一个决策数据链，所以，40多万这个答案，和小数点后3位这个精度，完全没有区别，而对响应时间要求非常高……一个小时以后，你的答案说不定已经没有任何意义了。
那么这种牺牲精度提高响应速度的场景，在实际的应用中多不多？这就仁者见仁，智者见智了。
最后一个关键点，就是所谓的数据变现，也就是大家经常说的“这东西能卖钱么？”
数据变现做为一个远景目标，也是很多决策者和架构师们在考虑的问题。 目前数据变现不一定指的是盈利，因为空间大数据有大量的用户是政府部门，所以变现就分为经济价值和社会价值两个部分。 经济价值就不说了，目前因为国内特殊情况，有些还处于探索阶段，比如数据的交换（买卖）。 根据国外的一些发展，未来数据变现在经济上可能有如下的发展： 1、资源买卖。通过原始数据的买卖产生经济价值。目前国内处于有钱没地方买，但是如果未来能够放开，那么数据交易的市场将非常庞大。从科研到教学，从社会生产生活，到宏观趋势研究，如果能够通过合理的价格来获取数据，那么对提供方和需求方都是一个重大的利好。 2、数据产品。通过数据来生产各种产品，比如医务工作者，对大医院病例与治疗方案的需求，相应的组织就可以针对医疗数据进行产品化（去除掉各种隐私、敏感等相关的信息）之后，可以对相应的机构提供。 3、专业分析服务。通过数据建模，可以提供各种专业的服务，比如投资、旅游、购物等。 4、软件和人才，这个就不用说了。 而政府相关的部门，可能更在乎变现的社会价值。 比如交通管理部门，通过对LBS数据的分析，能够对城市的交通管理决策更加优化。 在单位内部，大数据部门（极其使用者）可以变成行业（单位）的顶级智囊：能够对行业内（外）若干年发生的任何事情、资料、数据了如指掌，能够对任意决策提供数据支持和建议，能够快速的针对业务制作各种专业的报表和专题图，能够成为所有“标准答案”的出口……像这样的数据专家，哪个单位不想要？ 那么，做为大数据的从业者，或者想从业者，你准备好了吗？
HypeCycle曲线
而从HypeCycle曲线定义的阶段来看，越过炒作顶点的技术，通常被认为已经满足了技术可行性，进入了可实用的阶段。
所以，对于大数据项目来说，技术上已经没有什么太大的问题了，无论从软件还是从人员来说，该填的空也都填得差不多了，剩下就是看整体项目建设中该考虑如何落地的问题。
项目如何实施，第一步应该怎样走？为什么这样走？怎么样才算成功？
大数据不缺情怀，汗牛充栋的大数据情怀之作，让大家打足鸡血，甚至产生宗教崇拜情节——不用大数据的都是邪教，应该绑起来烧死：
技术上也不缺：各种Hadoox权威指南，Sparx权威指南……啥的书，也能够垒成书山了，但是恰恰漏掉了大数据整个项目应该如何实施的？
安装软件工程的模式，最重要的就是三个字“里程碑”。（说起这三个字，想到虾神才毕业时候做项目的经历，动辄就是里程碑发版本，加班加得头发一把把的掉……差点就聪明绝顶了）。
在一个单位内部，如何实施一个大数据项目？如何确定这个项目是成功还是失败了，业界有个主流的观点，认为大数据项目的里程碑，应该在下面三个关键点上面：
第一个节点称之为：系统轻载，通俗说起来，就是轻装上阵：
众所周知，当一个系统运行到一定时候，系统中会存储大量的历史数据，而数据库在访问由1万条记录组成的表的效率，和访问由1亿条记录组成的表的效率，那是完全不在一个数量级上的。
历史数据的存放一直是个很大的问题，特别是电商、银行这种，需要进行永久性存储业务数据的企业来说，代价一直是很高昂的。
所以这个节点，是很多企业的“刚需”，而对于我们空间信息技术相关的企业来说，暂时还没有那么大的“痛楚”，那么这个阶段的刚需，就是“数据化石”的激活了。
地理信息相关的企业（或者应用单位）通常会收集很多很多的数据，而且还会做很多数据的处理——这样导致了一个问题，在收集过程中，或者处理过程中，会生成非常多的过程数据（比如我见过的一个单位，在对矢量数据进行处理的时候，一天甚至能发出100多个版本）。
这些数据，要么因为存储空间不够或者认为意义不大，而直接丢弃了，要么就存储在了磁带机或者冷备硬盘上仅用于历史存档。而这些历史存档数据又因为技术上的“不可（不方便、不能快速）”访问，变成了所谓的数据化石。
这些数据化石里面，保留了无数的有价值的数据，举个简单的例子：
某领导突然过来问：我记得当年（五年前），xx在做xx区域的时候，曾经出过一个专题图，谁那还有?然后大家一阵鸡飞狗跳，（几小时 or 几天后）好容易在哪个灰尘20cm厚的仓库废品堆里面把那个专题挂图给找出来了。领导看过之后，嗯，不错，这几个地方重新改一下，再做一版拿给我……
这种情况，大家的表情肯定是：
五年前昙花一现的专题图成果（已经打印成了挂图），我去哪找原始数据啊？
大数据平台的构建，在第一阶段，就应该是解决这样的一些问题。
那么第二个阶段是什么呢？
第二个关键点，就是形成应用的闭环。
软件企业开发软件（或者项目），业务单位使用这些软件（或者应用），那么在使用的过程中，自然会生成大量的数据，这些数据有的是工作过程中产生的（业务数据、工作记录……），也有可能是软件运行产生的（操作日志、系统日志、维护日志……），这些数据，一旦收集起来，对软件厂商下一步软件开发提供建议。
如果能够对整个软件运行进行监控，那么很容易的获取所有功能模块的用户操作信息，包络使用习惯、操作步骤，使用频率等等，后期就能够针对这些内容进行更精准的优化。
那么对于政府或者所谓公共服务性质的单位呢？比如国土部门可以通过对某些查询的频率（比如那些表格的哪些字段，何种查询方式，需要何种结果），来决定数据库的优化策略；或者针对兄弟部门服务需求或者上级领导提出的要求（汇总数据、制作专题图等其他业务需求），来优化整个系统的功能设计。
说到这里，其实很多的实际应用场景与产品经理的设计是有冲突的。下面可以给大家举个小例子：
程序员在做汇总查询功能的时候，通常会按照数据计算引擎的模式，给出极高精确度的结果，比如要统计某个区域内的地块类别汇总，程序员设计的方式是鼠标在地图上一拉框，系统就会自动去计算这个区域内所有地块信息的累加和，最后给出的来的结果精确到小数点后面6位数……
但是随着数据体的变大，这种操作可能会非常非常慢……比如要统计整个长江流域的非农业用地面积，可能就需要几个小时设置几天的时间。
如果有一天，领导过来问你：从xx路到xx河，一共有多少亩农用土地？如果你花1小时后告诉领导，一共有44万3652.173亩……和你花三分钟就直接告诉领导，有44万3千多亩，甚至1分钟之后，就告诉领导，一共有40多万亩。那么你觉得领导会对哪个结果更满意？
因为领导并不是要你给出一个精确到小数点后N位的答案，他问你的时候，可能只需要一个大概的数字，与他现在正在进行考虑的某件事，形成一个决策数据链，所以，40多万这个答案，和小数点后3位这个精度，完全没有区别，而对响应时间要求非常高……一个小时以后，你的答案说不定已经没有任何意义了。
那么这种牺牲精度提高响应速度的场景，在实际的应用中多不多？这就仁者见仁，智者见智了。
最后一个关键点，就是所谓的数据变现，也就是大家经常说的“这东西能卖钱么？”
数据变现做为一个远景目标，也是很多决策者和架构师们在考虑的问题。 目前数据变现不一定指的是盈利，因为空间大数据有大量的用户是政府部门，所以变现就分为经济价值和社会价值两个部分。 经济价值就不说了，目前因为国内特殊情况，有些还处于探索阶段，比如数据的交换（买卖）。 根据国外的一些发展，未来数据变现在经济上可能有如下的发展： 1、资源买卖。通过原始数据的买卖产生经济价值。目前国内处于有钱没地方买，但是如果未来能够放开，那么数据交易的市场将非常庞大。从科研到教学，从社会生产生活，到宏观趋势研究，如果能够通过合理的价格来获取数据，那么对提供方和需求方都是一个重大的利好。 2、数据产品。通过数据来生产各种产品，比如医务工作者，对大医院病例与治疗方案的需求，相应的组织就可以针对医疗数据进行产品化（去除掉各种隐私、敏感等相关的信息）之后，可以对相应的机构提供。 3、专业分析服务。通过数据建模，可以提供各种专业的服务，比如投资、旅游、购物等。 4、软件和人才，这个就不用说了。 而政府相关的部门，可能更在乎变现的社会价值。 比如交通管理部门，通过对LBS数据的分析，能够对城市的交通管理决策更加优化。 在单位内部，大数据部门（极其使用者）可以变成行业（单位）的顶级智囊：能够对行业内（外）若干年发生的任何事情、资料、数据了如指掌，能够对任意决策提供数据支持和建议，能够快速的针对业务制作各种专业的报表和专题图，能够成为所有“标准答案”的出口……像这样的数据专家，哪个单位不想要？ 那么，做为大数据的从业者，或者想从业者，你准备好了吗？