大数据架构的未来.docxVIP

PAGE 1 PAGE 1 大数据架构的未来  或许全部读者都明白这一点：数据正在飞速增长，若是能够有效利用的话，我们能从这些数据中找到特别有价值的见解。  大数据的问题  或许全部读者都明白这一点：数据正在飞速增长，若是能够有效利用的话，我们能从这些数据中找到特别有价值的见解；传统技术有许多都是在40年前设计的，比如RDBMSs，不足以创造“大数据”炒作所宣称的商业价值。在大数据技术的使用上，常见的案例是“客户单一视图”；将关于客户所知道的一切内容放在一起，以便最大化服务供应与自身收入，比如确定详细需要采用什么促销方式，又是在什么时候、通过什么渠道来发送。  尽管大数据的问题在于，让我们将这种潜力变为现实，高等级的关键功能至少包括下面这些能力：  合并信息孤井、外在因素与数据流；  ·掌握数据访问；  ·依据需要转化数据；  ·整合数据；  ·为数据分析供应工具；  ·发布数据报告；  ·将见解体现在运营过程中；  ·最小化工作完成的总拥有成本与响应时间。  用数据湖作为答案  许多公司正在观望一个被某些人称为数据湖的架构，这个数据平台在合并信息孤井数据流以及在单独的规律位置中执行数据长久化方面具有敏捷性，能够从企业自身以及第三方的数据中挖掘出见解。将Hadoop（包括Spark在内）用于数据湖已成大势所趋，原因许多：使用总拥有成本较低的平凡硬件就能进行扩展，允许用读时模式（schema-on-read）收取大量数据，支持开源，包括用SQL和平凡语言构建分布式处理层。此外，像雅虎和谷歌这样的webscale公司都是早期标杆，借用这种架构在解决网站索引相关的问题时获得了巨大的成功。  Hadoop中的数据长久化选项  这样一来，从这里开始评估数据湖解决方案的前景好像很合理。一旦开始从更深的层次理解Hadoop的内涵，你就会发觉里面所包含的项目真的是包罗万象，涵盖了数据处理的方方面面。用Hadoop在数据湖中探测存储的数据时，有两个主要选项：HDFS和HBase。使用HDFS时，可以自行打算如何在只添加文件中对数据进行编码，包括JSON、CSV、Avro等等，因为HDFS只是一个文件系统，编码方式全由你打算。相反，HBase是一个数据库，其特有的数据编码方式可以将记录写入的速度最优化，在通过主键查询时执行只读的速度相对也很快。  这也是用Hadoop的数据湖之魅力所在，它能实现真实状况下的需求。因此，我们就能使用Hadoop来执行上面列出的高层次需求了。在像Spark和Hive这样的Hadoop生态系统中，仍需用到分布式处理层，但不需HDFS或HBase了，因此你可以从分布式处理层中选择长久化层面。之前的博文中有相关案例，描述了使用Spark在MongoDB中读写数据。还有一篇博文也很类似，证明白MongoDB只是读取数据的另一个Hive表格。  索引照旧很重要  大多熟识RDBMSs的技术人员发觉，从表达查询能力到二级索引，再到加速查询全都价值巨大（即便模式固定、总拥有成本高以及RDBMSs的可扩展性有限，这些使得它很难被用作数据湖）。假如我们在数据库长久化中只用到HDFS和HBase，就无法实现我们期盼的数据库临时索引了，特殊是遇到下面几个限制时：  临时切片：不通过二级索引，我们如何对不止一个主键标识出的数据切片进行有效地分析呢，例如对我们的最佳客户——那些消费金额超过X的客户进行分析？由于数据太过巨大，想要通过扫描找出最佳客户都会令工作卡住。  低延迟报告：假如没有敏捷的索引方式，我们如何在次秒级时间内响应客户的需求，为他们供应有价值的数据报告呢？再次，我们只能使用消费者的账户号或者其他主键来进行快速报告，而不是通过消费者的姓名、电话号码、邮编、花费等等。特殊提到：MongoDB刚刚为基于SQL的报告工具发布了BIConnector。  运营化：同样地，我们如何将有价值的见解引入应用运营中，从而在最大化影响公司和消费者的同时将数据变现？想象一下客服专员（CSR）告知消费者，因为数据湖仅支持这个主键，他必需供应账号才能查询全部的信息；或者查询需要10分钟时间。  当然，其中有些问题可以通过变通方法解决，不过会导致总拥有成本更高、开发或运营工作更多、延迟也更高。例如，使用搜寻引擎或者实体化视图而不是通过主键来查询；不过稍后还需返回到数据库，在有完整记录的数据库中对主表进行再次查询，以获得所需的完整信息。除了延迟翻倍之外，还需要耗费额外的管理、开发工作，以及单独搜寻引擎需要的基础设施，还有实体化视图所需的维护，加上将数据写入到其他地