大数据方面核心技术有哪些

大数据技术的体系庞大且复杂，基础的技术包含数据的采集、数据预处理、分布式存储、数据库、数据仓库、机器学习、并行计算、可视化等。

1、数据采集与预处理：FlumeNG实时日志收集系统，支持在日志系统中定制各类数据发送方，用于收集数据；Zookeeper是一个分布式的，开放源码的分布式应用程序协调服务，提供数据同步服务。

2、数据存储：Hadoop作为一个开源的框架，专为离线和大规模数据分析而设计，HDFS作为其核心的存储引擎，已被广泛用于数据存储。HBase，是一个分布式的、面向列的开源数据库，可以认为是hdfs的封装，本质是数据存储、NoSQL数据库。

3、数据清洗：MapReduce作为Hadoop的查询引擎，用于大规模数据集的并行计算。

4、数据查询分析：Hive的核心工作就是把SQL语句翻译成MR程序，可以将结构化的数据映射为一张数据库表，并提供HQL(HiveSQL)查询功能。Spark启用了内存分布数据集，除了能够提供交互式查询外，它还可以优化迭代工作负载。

5、数据可视化：对接一些BI平台，将分析得到的数据进行可视化，用于指导决策服务。

大数据培训课程内容一般都是从基础知识讲起，并且课程内容与企业实际需求相匹配、理论与实战相结合这样学员在培训机构学完后找工作才比较容易，一般主要学习Java语言基础、HTML、CSS、Java、JavaWeb和数据库、Lnux基础、Hadoop：生态体系、Spark：生态体系等课程内容。如需大数据培训推荐选择达内教育。

大数据技术庞大复杂，基础的技术包含数据的采集、数据预处理、分布式存储、数据库、数据仓库、机器学习、并行计算、可视化等名种技术范畴和不同的技术层面。一般工作包括数据清洗，执行分析和数据可视化。学习Python、数据库、网络爬虫、数据分析与处理等。感兴趣的话点击此处，免费学习一下

想了解更多有关大数据的相关信息，推荐咨询达内教育。达内与阿里、Adobe、红帽、ORACLE、微软、美国计算机行业协会（CompTIA）、百度等国际知名厂商建立了项目合作关系。共同制定行业培训标准，为达内学员提供高端技术、所学课程受国际厂商认可，让达内学员更具国际化就业竞争力。达内IT培训机构,试听名额限时抢购。

“

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

1

计算框架篇

大数据的价值

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

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

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

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

图 1

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

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

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

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

蛋糕模式

从将数据转换成价值的角度来说，在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）：

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

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

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一直到15版本都还是试用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全面实施的验证技术。

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

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

我市再ITjob管网上面找的

Flink 是由Apache软件基金会开发的开源流处理框架，其核心是用Java和Scala编写的分布式流数据流引擎。

Flink以数据并行和流水线方式执行任意流数据程序，Flink的流水线运行时系统可以执行批处理和流处理程序。此外，Flink的运行时本身也支持迭代算法的执行。

Flink程序在执行后被映射到流数据流，每个Flink数据流以一个或多个源（数据输入，例如消息队列或文件系统）开始，并以一个或多个接收器（数据输出，如消息队列、文件系统或数据库等）结束。Flink可以对流执行任意数量的变换，这些流可以被编排为有向无环数据流图，允许应用程序分支和合并数据流。

一个热爱生活又放荡不羁的程序猿

本文主要讲解如下内容：

一、数据湖的优点

二、目前有哪些开源数据湖组件

三、三大数据湖组件对比

数据湖相比传统数仓而言，最明显的便是优秀的T+0能力，这个解决了Hadoop时代数据分析的顽疾。传统的数据处理流程从数据入库到数据处理通常需要一个较长的环节、涉及许多复杂的逻辑来保证数据的一致性，由于架构的复杂性使得整个流水线具有明显的延迟。

目前开源的数据湖有江湖人称“数据湖三剑客”的 Hudi、Delta Lake和Iceberg

Iceberg官网定义：Iceberg是一个通用的表格式（数据组织格式），提供高性能的读写和元数据管理功能。

Iceberg 的 ACID 能力可以简化整个流水线的设计，传统 Hive/Spark 在修正数据时需要将数据读取出来，修改后再写入，有极大的修正成本。

[玫瑰]ACID能力，无缝贴合流批一体数据存储

随着flink等技术的不断发展，流批一体生态不断完善，但在流批一体数据存储方面一直是个空白，直到Iceberg等数据湖技术的出现，这片空白被慢慢填补。

Iceberg 提供 ACID 事务能力，上游数据写入即可见，不影响当前数据处理任务，这大大简化了 ETL；

Iceberg 提供了 upsert、merge into 能力，可以极大地缩小数据入库延迟；

[玫瑰]统一数据存储，无缝衔接计算引擎和数据存储

Iceberg提供了基于流式的增量计算模型和基于批处理的全量表计算模型。批处理和流任务可以使用相同的存储模型，数据不再孤立；

Iceberg 支持隐藏分区和分区进化，方便业务进行数据分区策略更新。

Iceberg屏蔽了底层数据存储格式的差异，提供对于Parquet，ORC和Avro格式的支持。将上层引擎的能力传导到下层的存储格式。

[玫瑰]开放架构设计，开发维护成本相对可控

Iceberg 的架构和实现并未绑定于某一特定引擎，它实现了通用的数据组织格式，利用此格式可以方便地与不同引擎对接，目前 Iceberg 支持的计算引擎有 Spark、Flink、Presto 以及 Hive。

相比于 Hudi、Delta Lake，Iceberg 的架构实现更为优雅，同时对于数据格式、类型系统有完备的定义和可进化的设计；

面向对象存储的优化。Iceberg 在数据组织方式上充分考虑了对象存储的特性，避免耗时的 listing 和 rename *** 作，使其在基于对象存储的数据湖架构适配上更有优势。

[玫瑰]增量数据读取，实时计算的一把利剑

Iceberg 支持通过流式方式读取增量数据，支持 Structed Streaming 以及 Flink table Source。

Apache Hudi是一种数据湖的存储格式，在Hadoop文件系统之上提供了更新数据和删除数据的能力以及消费变化数据的能力。

Hudi支持如下两种表类型：

使用Parquet格式存储数据。Copy On Write表的更新 *** 作需要通过重写实现。

使用列式文件格式（Parquet）和行式文件格式（Avro）混合的方式来存储数据。Merge On Read使用列式格式存放Base数据，同时使用行式格式存放增量数据。最新写入的增量数据存放至行式文件中，根据可配置的策略执行COMPACTION *** 作合并增量数据至列式文件中。

应用场景

Hudi支持插入、更新和删除数据。可以实时消费消息队列（Kafka）和日志服务SLS等日志数据至Hudi中，同时也支持实时同步数据库Binlog产生的变更数据。

Hudi优化了数据写入过程中产生的小文件。因此，相比其他传统的文件格式，Hudi对HDFS文件系统更加的友好。

Hudi支持多种数据分析引擎，包括Hive、Spark、Presto和Impala。Hudi作为一种文件格式，不需要依赖额外的服务进程，在使用上也更加的轻量化。

Hudi支持Incremental Query查询类型，可以通过Spark Streaming查询给定COMMIT后发生变更的数据。Hudi提供了一种消费HDFS变化数据的能力，可以用来优化现有的系统架构。

Delta Lake是Spark计算框架和存储系统之间带有Schema信息数据的存储中间层。它给Spark带来了三个最主要的功能：

第一，Delta Lake使得Spark能支持数据更新和删除功能；

第二，Delta Lake使得Spark能支持事务；

第三，支持数据版本管理，运行用户查询 历史 数据快照。

核心特性

Delta lake

由于Apache Spark在商业化上取得巨 成功，所以由其背后商业公司Databricks推出的Delta lake也显得格外亮眼。在没有delta数据湖之前，Databricks的客户 般会采 经典的lambda架构来构建他们的流批处理场景。

Hudi

Apache Hudi是由Uber的 程师为满 其内部数据分析的需求 设计的数据湖项 ，它提供的fast upsert/delete以及compaction等功能可以说是精准命中 民群众的痛点，加上项 各成员积极地社区建设，包括技术细节分享、国内社区推 等等，也在逐步地吸引潜在 户的 光。

Iceberg

Netflix的数据湖原先是借助Hive来构建，但发现Hive在设计上的诸多缺陷之后，开始转为 研Iceberg，并最终演化成Apache下 个 度抽象通 的开源数据湖 案。

三者均为Data Lake的数据存储中间层，其数据管理的功能均是基于 系列的meta 件。Meta 件的 类似于数据库的catalog，起到schema管理、事务管理和数据管理的功能。与数据库不同的是，这些meta 件是与数据 件 起存放在存储引擎中的， 户可以直接看到。这个做法直接继承了 数据分析中数据对 户可见的传统，但是 形中也增加了数据被不 破坏的风险。 旦删了meta 录，表就被破坏了，恢复难度很 。

Meta包含有表的schema信息。因此系统可以 掌握schema的变动，提供schema演化的 持。Meta 件也有transaction log的功能（需要 件系统有原 性和 致性的 持）。所有对表的变更都会 成 份新的meta 件，于是系统就有了ACID和多版本的 持，同时可以提供访问 历史 的功能。在这些 ，三者是相同的。

Hudi 的设计 标正如其名，Hadoop Upserts Deletes and Incrementals（原为 Hadoop Upserts anD Incrementals），强调了其主要 持Upserts、Deletes 和 Incremental 数据处理，其主要提供的写 具是 Spark HudiDataSource API 和 提供的 HoodieDeltaStreamer，均 持三种数据写 式：UPSERT，INSERT 和 BULK_INSERT。其对 Delete 的 持也是通过写 时指定 定的选项 持的，并不 持纯粹的 delete 接 。

在查询 ，Hudi 持 Hive、Spark、Presto。

在性能 ，Hudi 设计了 HoodieKey ， 个类似于主键的东西。对于查询性能， 般需求是根据查询谓词 成过滤条件下推 datasource。Hudi 这 没怎么做 作，其性能完全基于引擎 带的谓词下推和 partition prune 功能。

Hudi 的另 特 是 持 Copy On Write 和 Merge On Read。前者在写 时做数据的 merge，写 性能略差，但是读性能更 些。后者读的时候做 merge，读性能差，但是写 数据会 较及时，因 后者可以提供近实时的数据分析能 。最后，Hudi 提供了 个名为run_sync_tool 的脚本同步数据的 schema 到 Hive 表。Hudi 还提供了 个命令 具 于管理 Hudi 表。

Iceberg 没有类似的 HoodieKey 设计，其不强调主键。没有主键，做 update/delete/merge 等 *** 作就要通过 Join 来实现， Join 需要有 个类似 SQL 的执 引擎。

Iceberg 在查询性能 做了 量的 作。值得 提的是它的 hidden partition 功能。Hidden partition 意思是说，对于 户输 的数据， 户可以选取其中某些列做适当的变换（Transform）形成 个新的列作为 partition 列。这个 partition 列仅仅为了将数据进 分区，并不直接体现在表的 schema中。

Delta 的定位是流批 体的， 持 update/delete/merge，spark 的所有数据写 式，包括基于dataframe 的批式、流式，以及 SQL 的 Insert、Insert Overwrite 等都是 持的。

不强调主键，因此其 update/delete/merge 的实现均是基于 spark 的 join 功能。在数据写 ，Delta 与 Spark 是强绑定的，这 点 Hudi 是不同的：Hudi 的数据写 不绑定 Spark。

在查询 ，Delta 前 持 Spark 与 Presto，但是，Spark 是不可或缺的，因为 delta log 的处理需要 到 Spark。这意味着如果要 Presto 查询 Delta，查询时还要跑 个 Spark 作业。更为难受的是，Presto 查询是基于 SymlinkTextInputFormat 。在查询之前，要运 Spark 作业 成这么个 Symlink 件。如果表数据是实时更新的，意味着每次在查询之前先要跑 个 SparkSQL，再跑 Presto。为此，EMR 在这 做了改进可以不必事先启动 个 Spark 任务。

在查询性能 ，开源的 Delta 乎没有任何优化。

Delta 在数据 merge 性能不如 Hudi，在查询 性能不如 Iceberg，是不是意味着 Delta 是处了呢？其实不然。Delta 的 优点就是与 Spark 的整合能 ，尤其是其流批 体的设计，配合 multi-hop 的 data pipeline，可以 持分析、Machine learning、CDC 等多种场景。使 灵活、场景 持完善是它相 Hudi 和 Iceberg 的最 优点。另外，Delta 号称是 Lambda 架构、Kappa 架构的改进版， 需关 流批， 需关 架构。这 点上 Hudi 和 Iceberg 是 所不及的。

三个引擎的初衷场景并不完全相同，Hudi 为了 incremental 的 upserts，Iceberg 定位于 性能的分析与可靠的数据管理，Delta 定位于流批 体的数据处理。这种场景的不同也造成了三者在设计上的差别。尤其是 Hudi，其设计与另外两个相 差别更为明显。

Delta、Hudi、Iceberg三个开源项 中，Delta和Hudi跟Spark的代码深度绑定，尤其是写 路径。这两个项 设计之初，都基本上把Spark作为他们的默认计算引擎了。 Apache Iceberg的 向 常坚定，宗旨就是要做 个通 化设计的Table Format。

Iceberg完美的解耦了计算引擎和底下的存储系统，便于多样化计算引擎和 件格式，很好的完成了数据湖架构中的Table Format这 层的实现，因此也更容易成为Table Format层的开源事实标准。另 ，Apache Iceberg也在朝着流批 体的数据存储层发展，manifest和snapshot的设计，有效地隔离不同transaction的变更， 常 便批处理和增量计算。并且，Apache Flink已经是 个流批 体的计算引擎， 者都可以完美匹配，合 打造流批 体的数据湖架构。

Apache Iceberg这个项 背后的社区资源 常丰富。在国外，Netflix、Apple、Linkedin、Adobe等公司都有PB级别的 产数据运 在Apache Iceberg上；在国内，腾讯这样的巨头也有 常庞 的数据跑在Apache Iceberg之上，最 的业务每天有 T的增量数据写 。

Java基础语法

· 分支结构if/switch

· 循环结构for/while/do while

· 方法声明和调用

· 方法重载

· 数组的使用

· 命令行参数、可变参数

IDEA

· IDEA常用设置、常用快捷键

· 自定义模板

· 关联Tomcat

· Web项目案例实 ***

面向对象编程

· 封装、继承、多态、构造器、包

· 异常处理机制

· 抽象类、接口、内部类

· 常有基础API、集合List/Set/Map

· 泛型、线程的创建和启动

· 深入集合源码分析、常见数据结构解析

· 线程的安全、同步和通信、IO流体系

· 反射、类的加载机制、网络编程

Java8/9/10/11新特性

· Lambda表达式、方法引用

· 构造器引用、StreamAPI

· jShell(JShell)命令

· 接口的私有方法、Optional加强

· 局部变量的类型推断

· 更简化的编译运行程序等

MySQL

· DML语言、DDL语言、DCL语言

· 分组查询、Join查询、子查询、Union查询、函数

· 流程控制语句、事务的特点、事务的隔离级别等

JDBC

· 使用JDBC完成数据库增删改查 *** 作

· 批处理的 *** 作

· 数据库连接池的原理及应用

· 常见数据库连接池C3P0、DBCP、Druid等

Maven

· Maven环境搭建

· 本地仓库&中央仓库

· 创建Web工程

· 自动部署

· 持续继承

· 持续部署

Linux

· VI/VIM编辑器

· 系统管理 *** 作&远程登录

· 常用命令

· 软件包管理&企业真题

Shell编程

· 自定义变量与特殊变量

· 运算符

· 条件判断

· 流程控制

· 系统函数&自定义函数

· 常用工具命令

· 面试真题

Hadoop

· Hadoop生态介绍

· Hadoop运行模式

· 源码编译

· HDFS文件系统底层详解

· DN&NN工作机制

· HDFS的API *** 作

· MapReduce框架原理

· 数据压缩

· Yarn工作机制

· MapReduce案例详解

· Hadoop参数调优

· HDFS存储多目录

· 多磁盘数据均衡

· LZO压缩

· Hadoop基准测试

Zookeeper

· Zookeeper数据结果

· 内部原理

· 选举机制

· Stat结构体

· 监听器

· 分布式安装部署

· API *** 作

· 实战案例

· 面试真题

· 启动停止脚本

HA+新特性

· HDFS-HA集群配置

Hive

· Hive架构原理

· 安装部署

· 远程连接

· 常见命令及基本数据类型

· DML数据 *** 作

· 查询语句

· Join&排序

· 分桶&函数

· 压缩&存储

· 企业级调优

· 实战案例

· 面试真题

Flume

· Flume架构

· Agent内部原理

· 事务

· 安装部署

· 实战案例

· 自定义Source

· 自定义Sink

· Ganglia监控

Kafka

· 消息队列

· Kafka架构

· 集群部署

· 命令行 *** 作

· 工作流程分析

· 分区分配策略

· 数据写入流程

· 存储策略

· 高阶API

· 低级API

· 拦截器

· 监控

· 高可靠性存储

· 数据可靠性和持久性保证

· ISR机制

· Kafka压测

· 机器数量计算

· 分区数计算

· 启动停止脚本

DataX

· 安装

· 原理

· 数据一致性

· 空值处理

· LZO压缩处理

Scala

· Scala基础入门

· 函数式编程

· 数据结构

· 面向对象编程

· 模式匹配

· 高阶函数

· 特质

· 注解&类型参数

· 隐式转换

· 高级类型

· 案例实 ***

Spark Core

· 安装部署

· RDD概述

· 编程模型

· 持久化&检查点机制

· DAG

· 算子详解

· RDD编程进阶

· 累加器&广播变量

Spark SQL

· SparkSQL

· DataFrame

· DataSet

· 自定义UDF&UDAF函数

Spark Streaming

· SparkStreaming

· 背压机制原理

· Receiver和Direct模式原理

· Window原理及案例实 ***

· 7x24 不间断运行&性能考量

Spark内核&优化

· 内核源码详解

· 优化详解

Hbase

· Hbase原理及架构

· 数据读写流程

· API使用

· 与Hive和Sqoop集成

· 企业级调优

Presto

· Presto的安装部署

· 使用Presto执行数仓项目的即席查询模块

Ranger20

· 权限管理工具Ranger的安装和使用

Azkaban30

· 任务调度工具Azkaban30的安装部署

· 使用Azkaban进行项目任务调度，实现电话邮件报警

Kylin30

· Kylin的安装部署

· Kylin核心思想

· 使用Kylin对接数据源构建模型

Atlas20

· 元数据管理工具Atlas的安装部署

Zabbix

· 集群监控工具Zabbix的安装部署

DolphinScheduler

· 任务调度工具DolphinScheduler的安装部署

· 实现数仓项目任务的自动化调度、配置邮件报警

Superset

· 使用SuperSet对数仓项目的计算结果进行可视化展示

Echarts

· 使用Echarts对数仓项目的计算结果进行可视化展示

Redis

· Redis安装部署

· 五大数据类型

· 总体配置

· 持久化

· 事务

· 发布订阅

· 主从复制

Canal

· 使用Canal实时监控MySQL数据变化采集至实时项目

Flink

· 运行时架构

· 数据源Source

· Window API

· Water Mark

· 状态编程

· CEP复杂事件处理

Flink SQL

· Flink SQL和Table API详细解读

Flink 内核

· Flink内核源码讲解

· 经典面试题讲解

Git&GitHub

· 安装配置

· 本地库搭建

· 基本 *** 作

· 工作流

· 集中式

ClickHouse

· ClickHouse的安装部署

· 读写机制

· 数据类型

· 执行引擎

DataV

· 使用DataV对实时项目需求计算结果进行可视化展示

sugar

· 结合Springboot对接百度sugar实现数据可视化大屏展示

Maxwell

· 使用Maxwell实时监控MySQL数据变化采集至实时项目

ElasticSearch

· ElasticSearch索引基本 *** 作、案例实 ***

Kibana

· 通过Kibana配置可视化分析

Springboot

· 利用Springboot开发可视化接口程序

以上就是关于大数据方面核心技术有哪些全部的内容，包括:大数据方面核心技术有哪些、大数据培训课程都包含哪些内容、如何建立一个完整可用的安全大数据平台等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！