未解决
此帖子已超过 5 年
2 Intern
•
4K 消息
0
725
【分享】大数据架构的未来
原文出处：CSDN孙薇，http://geek.csdn.net/news/detail/58167
英文链接：https://dzone.com/articles/the-future-of-big-data-architecture
本文讲述了大数据的相关问题，以及“大数据架构”得名的由来。
大数据的问题
或许所有读者都明白这一点：数据正在飞速增长。若是能够有效利用的话，我们能从这些数据中找到非常有价值的见解；传统技术有很多都是在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的报告工具发布了BI Connector。
- 运营化：同样地，我们如何将有价值的见解引入应用运营中，从而在最大化影响公司和消费者的同时将数据变现？想象一下客服专员（CSR）告知消费者，因为数据湖仅支持这个主键，他必须提供账号才能查询所有的信息；或者查询需要10分钟时间。
当然，其中有些问题可以通过变通方法解决，不过会导致总拥有成本更高、开发或运营工作更多、延迟也更高。例如，使用搜索引擎或者实体化视图而不是通过主键来查询；不过稍后还需返回到数据库，在有完整记录的数据库中对主表进行再次查询，以获得所需的完整信息。除了延迟翻倍之外，还需要耗费额外的管理、开发工作，以及单独搜索引擎需要的基础设施，还有实体化视图所需的维护，加上将数据写入到其他地方造成的一致性问题。保持我们的设计原则，只用我们用惯的普通灵活索引不是很好么？
MongoDB是一个有效数据湖的重要部分
我们开始讨论，探索单用Hadoop是否能满足数据湖的需求，并发现了至少3个问题。我们能否在架构中另加一层持久化层面来解决这些问题，同时保持设计原则——使用低总拥有成本的普通硬件、开源模式、读时模式还有Hadoop分布式数据层——与之前一致呢？
我选择本文的主题是因为，MongoDB就是在Hadoop-only数据湖中，补位最优秀的数据库。如果使用另一个开源NoSQL数据库，就会发现其中几乎不含二级索引（使用二级索引会导致无法同步数据），也没有分组和聚合功能。你可以使用其中一些数据库将数据写入数据湖，不过如果出于商业需求想要以灵活的方式使用二级索引读取的话，是做不到的。如果想要在数据湖中使用开源RDBMS，我们已经说过，它们固定的模式、昂贵的垂直扩展模型都违背了我们设计数据湖的原则。
因此，推荐使用下面的架构来构建数据湖。
MongoDB对数据湖非常重要
这个架构将MongoDB作为持久化层面加入任何需要表达查询的数据集中，正与你需要索引的三个原因（上面列举了）相关。由于需求数据来自消费者，无论是否将数据发布到HDFS和/或MongoDB中，我推荐用governance function来确定。无论存储到HDFS或者MongoDB上，就可以运行分布式处理任务，比如Hive和Spark。不过如果数据在MongoDB上，因为筛选标准下放到数据库中，不像在HDFS中那样扫描文件，你就能在数据临时切片上运行有效分析了。与此相似，MongoDB中的数据也可用于实时、低延迟报告，并为构建的应用所用到的所有系统提供运营数据平台服务。
如今一些公司只是将数据复制到Hadoop中进行转换，然后再复制到其他地方，用于完成有价值的工作。为什么不直接利用数据湖，发挥最大价值呢？使用MongoDB可以将价值多次翻倍。
结论
观察长期与短期需求，确保这些需求可以通过核心Hadoop分布中的最佳工具，以及MongoDB这样的生态环境实现，数据湖对你而言就是有价值且而可行的。一些企业在使用数据湖时，只花费一年时间清洗所有数据，然后将其写入HDFS，希望在未来能用这些数据获取价值。结果却失望地发现这些数据毫无价值，事实上在数据与消费者之间还存在另一种batch layer层面。
通过将Hadoop与MongoDB合并，数据库可以确保成功，并是一个保持较低的总拥有成本，最快响应所有用户（数据科学家、分析师、商业用户、消费者自身）的灵活数据平台。有了数据湖，公司和员工就能用它来获取独特的见解，与客户进行有效沟通，将数据变现并战胜竞争对手。