从存储、实时、安全的角度谈如何建立完整可用的企业大数据平台

内容简介：从存储、实时、安全的角度谈如何建立完整可用的企业大数据平台

要建立一个大数据系统，我们需要从数据流的源头跟踪到最后有价值的输出，并在现有的 Hadoop和大数据生态圈内根据实际需求挑选并整合各部分合适的组件来构建一个能够支撑多种查询和分析功能的系统平台。这其中既包括了对数据存储的选择，也涵盖了数据线上和线下处理分离等方面的思考和权衡。此外，没有任何一个引入大数据解决方案的商业应用在生产环境上承担的起安全隐患。

1.计算框架篇

大数据的价值

只有在能指导人们做出有价值的决定时，数据才能体现其自身的价值。因此，大数据技术要服务于实际的用途，才是有意义的。一般来说，大数据可以从以下三个方面指导人们做出有价值的决定：

1. 报表生成（比如根据用户历史点击行为的跟踪和综合分析、 应用程序活跃程度和用户粘性计算等）；

2. 诊断分析（例如分析为何用户粘性下降、根据日志分析系统为何性能下降、垃圾邮件以及病毒的特征检测等）；

3. 决策（例如个性化新闻阅读或歌曲推荐、预测增加哪些功能能增加用户粘性、帮助广告主进行广告精准投放、设定垃圾邮件和病毒拦截策略等）。

图 1

进一步来看，大数据技术从以下三个方面解决了传统技术难以达成的目标（如图 1）：

1. 在历史数据上的低延迟（交互式）查询，目标是加快决策过程和时间，例如分析一个站点为何变缓慢并尝试修复它；

2. 在实时数据上的低延迟查询，目的是帮助用户和应用程序在实时数据上做出决策，例如实时检测并阻拦病毒蠕虫（一个病毒蠕虫可以在 1.3秒内攻击 1百万台主机）；

3. 更加精细高级的数据处理算法，这可以帮助用户做出“更好”的决策，例如图数据处理、异常点检测、趋势分析及其他机器学习算法。

蛋糕模式

从将数据转换成价值的角度来说，在 Hadoop生态圈十年蓬勃成长的过程中，YARN和 Spark这二者可以算得上是里程碑事件。Yarn的出现使得集群资源管理和数据处理流水线分离，大大革新并推动了大数据应用层面各种框架的发展（SQL on Hadoop框架,流数据，图数据，机器学习）。

它使得用户不再受到 MapReduce开发模式的约束，而是可以创建种类更为丰富的分布式应用程序，并让各类应用程序运行在统一的架构上，消除了为其他框架维护独有资源的开销。就好比一个多层蛋糕，下面两层是 HDFS和 Yarn,而 MapReduce就只是蛋糕上层的一根蜡烛而已，在蛋糕上还能插各式各样的蜡烛。

在这一架构体系中，总体数据处理分析作业分三块（图 2），在 HBase上做交互式查询（Apache Phoenix, Cloudera Impala等），在历史数据集上编写 MapReduce程序抑或利用 Hive等做批处理业务，另外对于实时流数据分析 Apache Storm则会是一种标准选择方案。

虽然 Yarn的出现极大地丰富了 Hadoop生态圈的应用场景，但仍存有两个显而易见的挑战：一是在一个平台上需要维护三个开发堆栈；二是在不同框架内很难共享数据，比如很难在一个框架内对流数据做交互式查询。这也意味着我们需要一个更为统一和支持更好抽象的计算框架的出现。

图 2

一统江湖

Spark的出现使得批处理任务，交互式查询，实时流数据处理被整合到一个统一的框架内（图 3），同时 Spark和现有的开源生态系统也能够很好地兼容（Hadoop, HDFS, Yarn, Hive, Flume）。通过启用内存分布数据集，优化迭代工作负载，用户能够更简单地操作数据，并在此基础上开发更为精细的算法，如机器学习和图算法等。

有三个最主要的原因促使 Spark目前成为了时下最火的大数据开源社区（拥有超过来自 200多个公司的 800多个 contributors）：

1. Spark可以扩展部署到超过 8000节点并处理 PB级别的数据，同时也提供了很多不错的 工具 供应用开发者进行管理和部署；

2. Spark提供了一个交互式 shell 供开发者可以用 Scala或者 Python 即时性试验不同的功能；

3. Spark提供了很多内置函数使得开发者能够比较容易地写出低耦合的并且能够并发执行的代码，这样开发人员就更能集中精力地为用户提供更多的业务功能而不是花费时间在优化并行化代码之上。

当然 Spark也和当年的 MapReduce一样不是万灵药，比如对实时性要求很高的流数据处理上 Apache Storm还是被作为主流选择，因为 Spark Streaming实际上是 microbatch（将一个流数据按时间片切成 batch,每个 batch提交一个 job）而不是事件触发实时系统，所以虽然支持者们认为 microbatch在系统延时性上贡献并不多，但在生产环境中和 Apache Storm相比还不是特别能满足对低延时要求很高的应用场景。

比如在实践过程中，如果统计每条消息的平均处理时间，很容易达到毫秒级别，但一旦统计类似 service assurance（确保某条消息在毫秒基本能被处理完成）的指标，系统的瓶颈有时还是不能避免。

但同时我们不能不注意到，在许多用例当中，与流数据的交互以及和静态数据集的结合是很有必要的,例如我们需要在静态数据集上进行分类器的模型计算，并在已有分类器模型的基础上，对实时进入系统的流数据进行交互计算来判定类别。

由于 Spark的系统设计对各类工作（批处理、流处理以及交互式工作）进行了一个共有抽象，并且生态圈内延伸出了许多丰富的库（MLlib机器学习库、 SQL 语言 API、GraphX）,使得用户可以在每一批流数据上进行灵活的 Spark相关操作，在开发上提供了许多便利。

Spark的成熟使得 Hadoop生态圈在短短一年之间发生了翻天覆地的变化， Cloudera和 Hortonworks纷纷加入了 Spark阵营，而 Hadoop项目群中除了 Yarn之外已经没有项目是必须的了（虽然 Mesos已在一些场合替代了 Yarn）,因为就连 HDFS，Spark都可以不依赖。但很多时候我们仍然需要像 Impala这样的依赖分布式文件系统的 MPP解决方案并利用 Hive管理文件到表的映射，因此 Hadoop传统生态圈依然有很强的生命力。

另外在这里简要对比一下交互式分析任务中各类 SQL on Hadoop框架，因为这也是我们在实际项目实施中经常遇到的问题。我们主要将注意力集中在 Spark SQL, Impala和 Hive on Tez上,其中 Spark SQL是三者之中历史最短的，论文发表在 15年的 SIGMOD会议上，原文对比了数据仓库上不同类型的查询在 Shark（Spark最早对 SQL接口提供的支持）、Spark SQL和 Impala上的性能比较。

也就是说，虽然 Spark SQL在 Shark的基础上利用 Catalyst optimizer在代码生成上做了很多优化，但 总体性能还是比不上 Impala, 尤其是当做 join操作的时候， Impala可以利用“predicate pushdown”更早对表进行选择操作从而提高性能。

不过 Spark SQL的 Catalyst optimizer一直在持续优化中，相信未来会有更多更好的进展。Cloudera的 Benchmark评测中 Impala一直比其他 SQL on Hadoop框架性能更加优越，但同时 Hortonworks评测则指出虽然单个数据仓库查询 Impala可以在很短的时间内完成，但是一旦并发多个查询 Hive on Tez的优势就展示出来。另外 Hive on Tez在 SQL表达能力也要比 Impala更强（主要是因为 Impala的嵌套存储模型导致的），因此根据不同的场景选取不同的解决方案是很有必要的。

图 3

各领风骚抑或代有才人出？

近一年比较吸引人眼球的 Apache Flink（与 Spark一样已有 5年历史，前身已经是柏林理工大学一个研究性项目，被其拥趸推崇为继 MapReduce, Yarn，Spark之后第四代大数据分析处理框架）。与 Spark相反， Flink是一个真正的实时流数据处理系统 ，它将批处理看作是流数据的特例，同 Spark一样它也在尝试建立一个统一的平台运行批量，流数据，交互式作业以及机器学习，图算法等应用。

Flink有一些设计思路是明显区别于 Spark的，一个典型的例子是内存管理，Flink从一开始就坚持自己精确的控制内存使用并且直接操作二进制数据，而 Spark一直到 1.5版本都还是试用 java 的内存管理来做数据缓存，这也导致了 Spark很容易遭受 OOM以及 JVM GC带来的性能损失。

但是从另外一个角度来说, Spark中的 RDD在运行时被存成 java objects的 设计模式 也大大降低了用户编程设计门槛，同时随着 Tungsten项目的引入，Spark现在也逐渐转向自身的内存管理，具体表现为 Spark生态圈内从传统的围绕 RDD（分布式 java对象集合）为核心的开发逐渐转向以 DataFrame(分布式行对象集合)为核心。

总的来说， 这两个生态圈目前都在互相学习，Flink的设计基因更为超前一些 ，但 Spark社区活跃度大很多，发展到目前毫无疑问是更为成熟的选择，比如对数据源的支持（HBase, Cassandra, Parquet, JSON, ORC）更为丰富以及更为统一简洁的计算表示。另一方面，Apache Flink作为一个由欧洲大陆发起的项目，目前已经拥有来自北美、欧洲以及亚洲的许多贡献者，这是否能够一改欧洲在开源世界中一贯的被动角色，我们将在未来拭目以待。

2. NoSQL数据库篇

NoSQL数据库在主流选择上依旧集中在 MongoDB, HBase和 Cassandra这三者之间。在所有的 NoSQL选择中，用 C++编写的 MongoDB 几乎应该是开发者最快也最易部署的选择。MongoDB是一个面向文档的数据库，每个文档／记录／数据（包括爬取的网页数据及其他大型对象如视频等）是以一种 BSON（Binary JSON）的二进制数据格式存储,这使得 MongoDB并不需要事先定义任何模式,也就是模式自由（可以把完全不同结构的记录放在同一个数据库里）。

MongoDB对于完全索引的支持在应用上是很方便的，同时也具备一般 NoSQL分布式数据库中可扩展，支持复制和故障恢复等功能。 MongoDB一般应用于高度伸缩性的缓存及大尺寸的 JSON 数据存储业务中，但不能执行“JOIN”操作，而且数据占用空间也比较大，最被用户诟病的就是由于 MongoDB提供的是数据库级锁粒度导致在一些情况下建索引操作会引发整个数据库阻塞。一般来说，MongoDB完全可以满足一些快速迭代的中小型项目的需求。

下面来主要谈谈 Cassandra和 HBase之间的比较选择。Cassandra和 HBase有着截然不同的基因血统。HBase和其底层依赖的系统架构源自于著名的 Google FileSystem（发表于 2003年）和 Google BigTable设计（发表于 2006年），其克服了 HDFS注重吞吐量却牺牲 I/O的缺点，提供了一个存储中间层使得用户或者应用程序可以随机读写数据。

具体来说，HBase的更新和删除操作实际上是先发生在内存 MemStore中，当 MemStore满了以后会 Flush到 StoreFile,之后当 StoreFile文件数量增长到一定阈值后会触发 Compact合并操作，因此 HBase的更新操作其实是不断追加的操作，而最终所有更新和删除数据的持久化操作都是在之后 Compact过程中进行的。

这使得应用程序在向内存 MemStore写入数据后，所做的修改马上就能得到反映，用户读到的数据绝不会是陈旧的数据，保证了 I/O高性能和数据完全一致性；另一方面来说， HBase基于 Hadoop生态系统的基因就已经决定了他自身的高度可扩展性、容错性。

在数据模型上，Cassandra和 HBase类似实现了一个 key-value提供面向列式存储服务，其系统设计参考了 Amazon Dynamo (发表于 2007年)分布式哈希（DHT）的 P2P结构（实际上大部分 Cassandra的初始工作都是由两位从 Amazon的 Dynamo组跳槽到 Facebook的工程师完成)，同样具有很高的可扩展性和容错性等特点。

除此之外，相对 HBase的主从结构，Cassandra去中心化的 P2P结构能够更简单地部署和维护，比如增加一台机器只需告知 Cassandra系统新节点在哪，剩下的交给系统完成就行了。同时，Cassandra对多数据中心的支持也更好，如果需要在多个数据中心进行数据迁移 Cassandra会是一个更优的选择。

Eric Brewer教授提出的经典 CAP理论认为任何基于网络的数据共享系统，最多只能满足数据一致性、可用性、分区容忍性三要素中的两个要素。实际分布式系统的设计过程往往都是在一致性与可用性上进行取舍，相比于 HBase数据完全一致性的系统设计，Cassandra选择了在优先考虑数据可用性的基础上让用户自己根据应用程序需求决定系统一致性级别。

比如：用户可以配置 QUONUM参数来决定系统需要几个节点返回数据才能向客户端做出响应，ONE指只要有一个节点返回数据就可以对客户端做出响应，ALL指等于数据复制份数的所有节点都返回结果才能向客户端做出响应，对于数据一致性要求不是特别高的可以选择 ONE，它是最快的一种方式。

从基因和发展历史上来说，HBase更适合用做数据仓库和大规模数据处理与分析（比如对网页数据建立索引），而 Cassandra则更适合用作实时事务和交互式查询服务。Cassandra在国外市场占有比例和发展要远比国内红火，在不少权威测评网站上排名都已经超过了 HBase。目前 Apache Cassandra的商业化版本主要由软件公司 DataStax进行开发和销售推广。另外还有一些 NoSQL分布式数据库如 Riak, CouchDB也都在各自支持的厂商推动下取得了不错的发展。

虽然我们也考虑到了 HBase在实际应用中的不便之处比如对二级索引的支持程度不够（只支持通过单个行键访问，通过行键的范围查询，全表扫描），不过在明略的大数据基础平台上，目前整合的是依然是 HBase。

理由也很简单，HBase出身就与 Hadoop的生态系统紧密集成，其能够很容易与其他 SQL on Hadoop框架（Cloudera Impala, Apache Phoenix, or Hive on Tez）进行整合，而不需要重新部署一套分布式数据库系统，而且可以很方便地将同样的数据内容在同一个生态系统中根据不同框架需要来变换存储格式（比如存储成 Hive表或者 Parquet格式）。

我们在很多项目中都有需要用到多种 SQL on Hadoop框架，来应对不同应用场景的情况，也体会到了在同一生态系统下部署多种框架的简便性。但同时我们也遇到了一些问题，因为 HBase项目本身与 HDFS和 Zookeeper系统分别是由不同开源团队进行维护的，所以在系统整合时我们需要先对 HBase所依赖的其他模块进行设置再对 HBase进行配置，在一定程度上降低了系统维护的友好性。

目前我们也已经在考虑将 Cassandra应用到一些新的客户项目中，因为很多企业级的应用都需要将线上线下数据库进行分离，HBase更适合存储离线处理的结果和数据仓库，而更适合用作实时事务和并发交互性能更好的 Cassandra作为线上服务数据库会是一种很好的选择。

3.大数据安全篇

随着越来越多各式各样的数据被存储在大数据系统中，任何对企业级数据的破坏都是灾难性的，从侵犯隐私到监管违规，甚至会造成公司品牌的破坏并最终影响到股东收益。给大数据系统提供全面且有效的安全解决方案的需求已经十分迫切：

• 大数据系统存储着许多重要且敏感的数据，这些数据是企业长久以来的财富

• 与大数据系统互动的外部系统是动态变化的，这会给系统引入新的安全隐患

• 在一个企业的内部，不同 Business Units会用不同的方式与大数据系统进行交互，比如线上的系统会实时给集群推送数据、数据科学家团队则需要分析存储在数据仓库内的历史数据、运维团队则会需要对大数据系统拥有管理权限。

因此为了保护公司业务、客户、财务和名誉免于被侵害，大数据系统运维团队必须将系统安全高度提高到和其他遗留系统一样的级别。同时大数据系统并不意味着引入大的安全隐患，通过精细完整的设计，仍然能够把一些传统的系统安全解决方案对接到最新的大数据集群系统中。

一般来说，一个完整的企业级安全框架包括五个部分：

• Administration:大数据集群系统的集中式管理，设定全局一致的安全策略

• Authentication:对用户和系统的认证

• Authorization：授权个人用户和组对数据的访问权限

• Audit：维护数据访问的日志记录

• Data Protection：数据脱敏和加密以达到保护数据的目的

系统管理员要能够提供覆盖以上五个部分的企业级安全基础设施，否则任何一环的缺失都可能给整个系统引入安全性风险。

在大数据系统安全集中式管理平台这块，由 Hortonworks推出的开源项目 Apache Ranger就可以十分全面地为用户提供 Hadoop生态圈的集中安全策略的管理，并解决授权 (Authorization)和审计 (Audit)。例如，运维管理员可以轻松地为个人用户和组对文件、数据等的访问策略，然后审计对数据源的访问。

与 Ranger提供相似功能的还有 Cloudera推出的 Apache Sentry项目，相比较而言 Ranger的功能会更全面一些。

而在认证（Authentication）方面,一种普遍采用的解决方案是将基于 Kerberos的认证方案对接到企业内部的 LDAP环境中， Kerberos也是唯一为 Hadoop全面实施的验证技术。

另外值得一提的是 ApacheKnox Gateway项目，与 Ranger提高集群内部组件以及用户互相访问的安全不同，Knox提供的是 Hadoop集群与外界的唯一交互接口，也就是说所有与集群交互的 REST API都通过 Knox处理。这样，Knox就给大数据系统提供了一个很好的基于边缘的安全（perimeter-based security）。

基于以上提到的五个安全指标和 Hadoop生态圈安全相关的开源项目，已经足已证明基于 Hadoop的大数据平台我们是能够构建一个集中、一致、全面且有效的安全解决方案。

4.总结

本文主要介绍了如何将 Hadoop和大数据生态圈的各部分重要组件有机地联系在一起去创建一个能够支撑批处理、交互式和实时分析工作的大数据平台系统。其中，我们重点尝试从计算框架、 NoSQL数据库以及大数据平台安全这三方面分析了在不同的应用场景中相应的技术选型以及需要考虑到的权衡点，希望让大家对如何建立一个完整可用的安全大数据平台能有一个直观的认识。

作者介绍

江金陵 ，明略数据数据科学家，中山大学本科，硕士毕业于沙特阿拉伯阿卜杜拉国王科技大学，博士就读于丹麦奥尔堡大学，攻读博士期间赴斯德歌尔摩参与创立一款个性化新闻阅读工具并提名瑞典最佳新媒体类移动应用，后加入欧洲前三大博彩公司 Unibet负责实时个性化赛事推荐系统的大数据平台开发工作。他曾在 ICDE、ICDM等数据库和数据挖掘顶级会议中发表过学术文章，对大数据环境下的搜索、推荐、自然语言处理等方面均有十分丰富的经验。目前供职于明略数据数据科学家团队，负责公安和金融领域的大数据建模与开发工作。

以上所述就是小编给大家介绍的《从存储、实时、安全的角度谈如何建立完整可用的企业大数据平台》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！

查看所有标签

猜你喜欢:

• 开车出门没处停？未来可用AI实时预判空车位
• 只需一台电脑，人人都可用 Python 实现新冠病毒分布实时追踪
• 构建生产环境可用的高可用kubernetes集群
• 维基百科 – Sparql查询获取dbpedia可用的所有可用电影
• 可用性高达5个9！支付系统高可用架构设计实战
• LearningAVFoundation之拍摄+实时滤镜+实时写入

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。