大数据架构的未来

大数据架构的未来名的由来。大数据的问题有效利用的话，我们能从这些数据中找到非常有价值的见40年前设计的，比如不足以创造“大数据”炒作所宣称的商业价值。在大数据技级的关键功能至少包括下面这些能力：合并信息孤井外在因素与数据流； 控制数据访问根据需要转化数据； 整合数据； 为数据分析提供工具； 发布数据报告； 将见解体现在运营过程中；最小化工作完成的总拥有成本与响应时间。 用数据湖作为答案据平台在合并信息孤井数据流以及在单独的逻辑位置中执行数据持久化方面具有灵活性，能够从企业自身以及第三方的数据中挖掘出见解。将Spark在内）据湖已成大势所趋，原因很多：使用总拥有成本较低的普通收取SQL和普通语言构建分布式处理层。此外，像雅虎和谷歌这样的webscale公司都是早期标杆，借用这种架构在解决网站索引相关的问题时获得了巨大的成功。Hadoop中的数据持久化选项Hadoop的内涵，你就会发Hadoop在数据湖中探测存储的数据时，有两个主要选项：HDFS和HBaseHDFS时，可以自行决定JSON、CSV、AvroHDFS决定。相反，HBase是一个数据库，其特有的数据编码方式的速度相对也很快。Hadoop的数据湖之魅力所在，它能实现真实情况Hadoop来执行上面列出的Spark和HiveHadoop中，仍需用到分布式处理层，但不需HDFS或HBase此你可以从分布式处理层中选择持久化层面。之前的博文中Spark在MongoDB中读写数据。MongoDB只是读取数据的Hive表格。索引仍旧很重要RDBMSs索引，再到加速查询全都价值巨大（RDBMSs作数据湖HDFS和HBase，就无法实现我们期待的数据库临时索引了，特别是遇到下面几个限制时：X巨大，想要通过扫描找出最佳客户都会令工作卡住。级时间内响应客户的需求，为他们提供有价值的数据报告花费等等。特别提到：MongoDBSQL的报告工BIConnector。象一下客服专员（CSR）告知消费者，因为数据湖仅支持这10分钟时间。我们用惯的普通灵活索引不是很好么？MongoDB是一个有效数据湖的重要部分Hadoop3个问题。我们能否在架构中另加一层持久化层面来解决这些问题，同时保持设计原则——使用低总拥有Hadoop分布式数据层——与之前一致呢？Hadoop-only数据库，就会发现其中几乎不含二级索引（导致无法同步数据，也没有分组和聚合功能。你可以使用其果RDBMS，我们已经说过，它们固的原则。因此，推荐使用下面的架构来构建数据湖。MongoDB对数据湖非常重要这个架构将MongoDB作为持久化层面加入任何需要表达查询的数据集中，正与你需要索引（上面列举了HDFS和/或MongoDBfunctionHDFS或者MongoDBHive和Spark。不过如果数据在MongoDB上，因为筛选标准下放到数据库中，不像在HDFS中那样扫描文件，你就能在数据临时切片上运行有效分析了。与此相似，MongoDB中的数据也可用于实时、低延迟报告，并为构建的应用所用到的所有系统提供运营数据平台服务。Hadoop中进行转换，然后MongoDB可以将价值多次翻倍。结论HadoopMongoDB这样的生态环境实现，据湖时，只花费一年时间清洗所有数据，然后将其写入HDFS，希望在未来能用这些数据获取价值。结果却失望地另一种batchlayer层面。Hadoop与MongoDB是一个保持较低的总拥有成本，最快响应所有用户（数据科学家、分析师、商业用户、消费者自身）的灵活数据平台。有了数据湖，公司和员工就能用它来获取独特的见解，与客（责编/钱曙光，关注架构和算法领域，寻求报道或者投稿请发邮件HYPERLINK"mailto:qi