MapReduce和数据科学家（续）

nPath这类函数生成的结果类似一个SQL子查询的结果，比如是一个关系表。因此它们可以用在SQL中的FROM子句中，用来跟其他表进行连接，并利用WHERE子句进行你个过滤，用GROUP BY子句进行分组等等。SQL-MapReduce查询可以通过第三方工具进行输入并展示结果，比如Tableau，它支持自定义SQL的建立。

SQL-MapReduce函数是自描述的，也支持延迟绑定，这意味着可在不知道数据结构的情况进行改写。输入和输出数据的格式在查询运行的时候才由该函数自行确定【有点抽象哇？难道是面向对象的概念？】。这种方法非常适合分析未知的、非结构化的数据。函数管理和控制他们自己的内存和文件结构，由一个独立的处理器进行运行，减少对DBMS系统的影响。

在SQL-MapReduce中等同于Map程序的是“表函数”，等同于Reduce程序的是“分区函数”。这些函数可以链接在一起提供一套MapReduce任务哦能力，但是没有任务调度的负荷。一个函数的多个实例并行的运行在多个节点上，以及一个节点的多个线程上。输入数据按行分布到多个线程中，输出数据也按行从所有线程中收集。通过行函数【应该就是前面指的表函数，完成Map任务】，输入表的每一行可以被这个函数的一个实例进行处理。通过分区函数，由PARTITION BY子句定义的每一组行的集合将被这个函数的某一实例进行处理（见上述语句）。执行引擎因此既可以在行的级别也可以在分区的级别上实现并行，取决于那类函数被使用。

SQL-MapReduce函数可以从外部数据源读取数据，也可以写入数据到外部数据源【可以用来做ETL的E和L，在加上自己可以实现T，全了也！听起来不错】。可以利用一个函数或者一组函数来读取、转换和装载外部数据到一个DBMS的表中，并进行处理和分析，然后将结果写入到另外一个外部输出文件中。

六、什么时候用什么技术呢？

争论什么时候用Hadoop和什么时候用RDBMS让我回忆起上世纪八十年代的一些关系化争论，原因都是相似的。程序员倾向于用过程性编程语言的方法来访问和维护数据，例如Hadoop的MapReduce。而非程序员的用户则倾向于用定义性的语言，例如RDBMS的SQL。然而Hadoop Hive的SQL风格的语言和RDBMS提供的MapReduce函数让这种争论变得更加复杂了。因为Hadoop有了说明性语言HiveQl，同时RDBMS有了MapReduce的特性。

下图指明了RDBMS和Hadoop Hive的角色。如图所示，RDBMS适合在TB级结构化数据之上的非实时和实时的SQL查询；Hadoop Hive适合处理在PB级别非结构化数据上的非实时查询。

利用Hive来处理传统的SQL风格的查询扩展了其在结构化数据和准实时方面的能力。然而，在这种模式下，Hive在功能性、可用性、性能和成熟度方面比不过RDBMS【我举双手赞成这个结论】。

在RDBMS中增加MapReduce使得它可以用来处理非结构化数据上。海量非结构化数据通过SQL中的MapReduce函数来处理可能会在性价比方面有一些依赖条件。因为数据可能是PB级别，所以一般来说最好用一个POC测试来验证一下。

下表的比较没有考虑使用探索分析平台的开发者和用户。本文开始的讨论聚焦在大数据对企业的用处以及数据科学家如何处理这些数据。讨论的主要需求是企业应该如何高效低成本地处理海量非结构化数据，对于数据科学家来说，那种技术更加实用。因此，当选择一种分析解决方案的时候，其功能性和可用性需要和性能一起被考虑。下表比较了Aster Database和Hadoop Hive的这些因素。

比较总会带上一些主观的因素，但是在选择新的分析解决方案的时候，我们不得不评估一些重要的因素。

RDBMS中增加了MapReduce特性给那些熟悉SQL超过Hadoop的数据科学家在自己熟悉的环境中进行这种数据处理和分析的机会。因为RDBMS更成熟，它的可管理性和负载管理的能力会更好。

由于Hadoop的好处和市场对其的关注，许多企业不可避免的使用了Hadoop和RDBMS组合的解决方案。对于这些企业来说，采用一个组合的解决方案能使得产品选择和应用部署的决策更加容易。

七、共存策略

使用Hadoop和RDBMS共存解决方案可能有以下场景；

1、利用Hadoop来存储和归档非结构化数据。可以使用连接器来从Hadoop中抽取分析所需要的数据到RDBMS中。如果RDBMS支持MapReduce函数的话，这些函数就可以被用来做抽取工作。例如Aster-Hadoop适配器使用SQL-MapReduce函数来提供在HDFS和Aster Database间的双向高速数据传输。装入Aster Database的数据即可以用SQL也可以用MapReduce来处理。【云仅存储】

2、使用Hadoop来过滤、转换或整合非结构化数据。用连接器来将Hadoop处理完成的数据抽取到RDBMS中来进行分析。【云ETL】

3、利用Hadoop来分析大规模非结构化数据，并将分析结果发布关系数据仓库环境，共享存储或者使用通用的用户接口。【还加上了云分析、DM】

4、使用提供MapReduce的关系数据库作为探索性分析平台。数据科学家可以使用RDBMS的SQL和MapReduce能力来分析结构化和非结构化的组合数据（后者从Hadoop中装载）。【仅关系数据库，没有云了】

5、使用一个前端查询工具来对存储在Hadoop和RDBMS中的数据进行访问和分析【分离的方案，无交互，像五哥提的】

上述场景提供了一个环境，在这个环境中，Hadoop和RDBMS彼此分离，然后利用一个连接软件来交互数据。未来数年的工业发展方向将使得两者配合得更加紧密。既通过类似API和元数据集成的工具，也通过将它们整合在一个软硬一体机中并允许应用在一个系统中使用两种技术的益处【前面的方向很好理解，也是我们探索的方向。后面这个有点超出预期，似乎EMC已经在做这方面的工作。但是如何隔离负荷避免相互影响呢？】。类似的集成提供了许多好处，比如消除安装和维护多套系统的麻烦，减少数据移动，提供单一的元数据存储，提供单一的接口给业务人员和分析工具。【有点像我们的混装的研究中的一些研究点】

八、总结

大数据和相关技术将给业务分析带来重大的益处，但是随着这些技术使用的不断增多，企业紧密控制所有形式的数据并将其进行分析和研究变得很困难。对于企业来说，当然不可能将所有数据都整合到EDW中，区分哪些数据能，那些数据不能集成到EDW中非常重要。【在我们架构软课题中，给出了从使用需求方面的方法，作者似乎是希望从技术方面给出一个方法】。

对于那些EDW之外的数据（例如因为性能或成本方面的原因而放在外面的），BI开发者和数据科学家需要评估最适合的方式来将其进行处理和分析。既可以利用带MapReduce能力的RDBMS，也可以使用Hadoop Hive这种非关系系统，或者利用流处理的技术进行分析。【流处理，终于看到了，这说明我们研究流技术也是很重要的，不过流，也可以在云上嘛，但不是Hadoop的批】

对于EDW中的数据，决定哪些数据需要抽取到数据集市或数据立方体【指MOLAP，我讨厌这个】以便业务人员可以分析是否非常必要的。也可以考虑抽取到一个探索性数据沙盒【Inmon也这样建议过，另外还有沙盒哦！】由数据科学家进行探索分析。后者可能就会包括非结构化数据，这些数据可能来自一个Hadoop系统。

上述这些不同的方法和组件，企业必须扩展现有的EDW基础设施来予以支持。新的基础设施可以被作为一个外部的数据仓库【数据仓库是什么呢？这个定义其实可以扩大，比如Gartner提出的逻辑数据仓库嘛，不一定只有RDBMS组成的才是数据仓库。】。这样的一个基础设施对于那些真正希望挖掘大数据中的价值的企业来说非常重要，它是的数据科学家可以研究如何改善现有业务模式，并识别新的商业机会。

【本文是Teradata赞助的，所以看官们必须要明白这一点。】

权限：公开   来自：labs

声明： 本文仅代表作者个人观点。其原创性及文中表达的意见、判断、数据、观点和陈述文字等内容均与中国移动研究院无关。移动Labs博客致力于为ICT领域的研究者及从业者提供技术和业务交流的网络平台，对本文中全部或部分内容的真实性、完整性不作任何保证或承诺，仅供读者参考交流。