试着大致整理Hadoop生态系统

总的来说，Hadoop生态系统可以被概括为以下方面（2018年）。

需要永久地，在中国以本地语言的方式将下述内容进行改写的一种选项：
CL：求助； TR：翻译；

整理一下围绕着Hadoop这一重大突破而形成的生态系统。
本文将简略地概述，不涉及复杂的内容。

Hadoop是什么？

我們開發了一個框架，讓分散系統的構建變得非常容易（並不意味著變得簡單）。

顺便说一下，分布式系统指的是

• 複数のサーバを連携させて一つのサーバとみなす

• なんからの計算処理を複数のサーバで手分けして行う

Ex. 夏休みの宿題を家族で手分けすれば早く終わりますよね、ね！

高価かつ超ハイスペックサーバじゃなくてもコモディティハードウェアを複数台束ねるだけで、構築可能(スケールアウト)
リソースが足らなくなってもサーバを足せばよい(既存サーバを有効活用できる)

雖然有很多好處，但也存在一些問題，
在本應該構建分散系統的情況下，

• サーバが壊れたときにそこで処理していたものはどうする?

• サーバが問題なく動いているかを誰が監視するの?

データが来ないんだけどこれってネットワークの問題?それともサーバの問題?

等等，腦海中有很多要思考的事情堆積如山。

※余談
在研究领域中，分散系统相关存在着各种问题。
包括协议问题、领导者选举问题、分散快照问题、节点故障检测等等……
哎呀，从这里开始就是未知的领域了
（我也打算从这些方面开始学习）

因此，如果要建立分散系統，就需要實現考慮到上述問題的演算法，但這實在是相當困難的。

因此，Hadoop是通过将复杂的问题转化为框架，并在分布式系统中实现数据存储和处理，而无需从头开始实施分布式系统算法的。

顺便提一下，Hadoop主要分为三个组件。

所以，现在进入正题。

Hadoop已经诞生了！这样就可以建立分布式系统了！太棒了！希望有这样的功能，还希望有那样的功能，自己动手去实现吧！然后出现了许多应用程序来弥补Hadoop的弱点（大概）。将这些组件总称为Hadoop生态系统。

顺便提一下，Hadoop的弱点可以大致分为以下几个类别。

• プログラミングやりたくない問題

• バッチ処理問題

データの抽出問題 → 一部のデータだけ変えるとかができない。小回りがきかない。
スピード問題　→とにかく遅い。
IoT等によるストリーミング問題　→　リアルタイムにデータをさばけない。

その他

我不想要做编程的问题

在Hadoop上进行并行分布式处理时，通常会提供Java框架，因此需要使用Java来编写Map处理、Reducer处理等，这样做有些麻烦。而处理大数据的人更倾向于是工程师而不是分析师，因此开发面向这一层次的分布式处理接口变得非常流行。其中的典型例子是SQL。

在Hive中，可以用SQL来描述MapReduce处理。

Hive是类似于由Facebook开发的SQL接口。
Hive可以像一般的关系型数据库那样创建表，
通过编写类似于SELECT 〇〇 FROM △△的SQL语句来提取数据。

真正的RDB和Hive之间的区别在于它们的处理引擎。
在Hive中，处理引擎仍然是MapReduce。具体来说，Hive会解释SQL语句，并将其作为MapReduce处理在Hadoop上执行。

因此，类似于RDB这样在短时间内返回数据是不会发生的。
虽然是SQL，但只进行批量处理。

因此，最近很少直接使用Hive本身，但在稍后提到的用于SQL处理引擎中，很多情况下仍使用Hive来存储表结构的元数据和服务器功能。

用脚本处理编写Pig的MapReduce

Pig是Yahoo开发的一个在Hadoop上可处理的脚本处理接口。它能够执行一种名为Pig Latin的专有脚本语言。由于学习成本要低于Java，因此被认为易于实施。然而，由于Hive（SQL）更有名，所以我个人没有听说过它被广泛使用的案例。

批处理问题

MapReduce 是一种以批处理为前提的编程模型。顺便提一句，根据处理方法的大致分类，

为了处理大量数据并避免在分布式节点上出现数据丢失的情况，Hadoop采用了具有容错性的架构。因此，它采用了批处理架构，但这也导致了以下方面的牺牲。

HBase是一种具有随机访问能力的数据库，但存在灵活性不足的问题。

HBase是Hadoop生态系统的一个组成部分。
HBase具有类似关系型数据库的表处理功能，具有可以随机访问数据的能力，可以对数据进行部分获取、插入和更新等操作。
另外，与关系型数据库不同的是，HBase不需要事先定义模式（DDL），因此可以扮演数据湖的角色。
作为数据结构，HBase采用了宽列类型的结构。

从“什么是宽列式布局”的讨论来看，它是键值对类型与几乎无限的横向列相结合的形式。

实际存储数据的方式可能会变成类似的形式（实际的数据保存方式可能会稍有不同）
此外，可以创建列族作为列的分组。

因此，数据的存储要使用

• テーブル名

• カラムファミリー名

• カラム名

キーの値

在同一数据表中的不同列族名称上，可以指定相同的列名来输入数据。

建议您阅读与NoSQL相关的文章或书籍，以了解这些数据结构的详细信息。

这些数据存储在HDFS的后端，因此具有容错性。
此外，表不是以节点为单位处理，而是以类似于区域块的单位处理。

• Regionが膨らんできたらRegionそのものを分割する

ノードごとにRegionの大きさが偏ってきたらロードバランシング（Regionの大きさを均一にするように調整する）

该系统还具有这样的功能。
它通常被用作消息数据库。

HDFS和HBase的结合？Kudu。

Kudu被誉为结合了HDFS和HBase优点的分布式存储服务。具体而言，

• 主にデータ抽出(SELECT処理)に特化したDWH型のストレージ

• RDBのようにスキーマを決めておく必要あり

SQLインターフェースがあるためクエリでデータを取得可能

※我打算再多学一点，再加一些内容。。。

能够与Hive进行协同处理的引擎。

出现了Hive，使得可以在SQL中进行分布式处理！！！然而，随之而来的是问题的发生。

虽然可以用SQL编写，但是结果返回很慢！

一般的的关系数据库（RDB）查询执行，即使慢点，也应该在几分钟内返回结果，但是在Hive中，甚至经过数小时仍然没有返回结果… 这也不足为奇，因为Hive的处理引擎是MapReduce = 批处理，所以无法像关系数据库那样进行交互式处理。

但我不会放弃。

要是能制造一台跑得快的引擎就好了吧？ yī dé de jiù ba?)

因此，涌现出了可以替代MapReduce的并行分布式处理引擎。

我对这些区别的细微之处不是很明白…

最近常常听到的是Presto或者是SparkSQL吧。

被称为MapReduce2.0的通用分布式处理引擎Spark。

最近很流行诸如”金钱2.0″、”动力3.0″之类的概念，就像〇〇2.0一样。
从这个意义上说，可以说Apache Spark就是MapReduce 2.0。
Spark是在美国著名的UC Berkeley大学的AMPlab开发的分布式处理框架。

在于MapReduce

• インメモリ処理

基本的にデータをインメモリに入れたまま処理するためMapReduceよりディスクI/Oが少ないので早い。

遅延実行(DAG(非循環有向グラフ))
キャッシュ機能による反復処理の効率化

効率的な処理が可能になる

バッチ処理だけでなく、リアルタイム処理、機械学習、SQLライクな処理のライブラリがある

大概就是这个意思了。

目前，有关DataFrame和DataSet等高效数据处理的开发正在进行中，
在分布式数据处理方面已经成为几乎事实标准。

实时发送数据的Flume，Kafka。

以下是关于实时数据传输组件的介绍。
特别是在物联网领域中，我们需要实时检查设备状态和监测突发压力（值的突然大幅变化）等需求增加，这也导致了最近实时数据处理技术的增加，各种开源软件也应运而生。

虽然实时数据处理架构一开始看起来似乎很复杂，但是如果我们整理一下相关人物，

基本上

• やってきたデータを一時的に保管する場所(簡易的にストアと呼ぶようにします)

• ストアにデータを送る

ストアからデータを取得する

只能这样了。

除了这种组合之外，还有以下方式：
原始数据→临时存储数据→最终存储数据

• 随時データ元がデータを送るのか（Push型）

一定間隔でデータを取ってくるのか（Pull型）という違いがあります。

如果是Kafka和Flume的情况，

通过将原始数据（如日志等）随时发送到临时存储中进行数据保留（推送方式），
最终的数据存储位置（如HDFS等）定期地从临时存储中取回数据（拉取方式）。

这是一个组织形式。

另外，在Kafka的情况下，可以对存储消息的地方（代理服务器）进行集群化和复制，从而保证消息的容错性。
此外还有一个名为Mirror Maker的功能可以复制集群。

除此之外

使用Sqoop将数据从RDB发送到HDFS

可以使用Flume或者Sqoop等工具来实现数据的导入。

• RDBからデータを取り出してCSV等テキストファイル化する

テキストファイルをHDFSに配置する

需要进行以下的步骤，但Sqoop可以通过命令轻松处理。
此外，Sqoop还支持批量加载，可以快速传输大量数据。
而且，Sqoop不仅可以将关系数据库中的数据导入到HDFS，还可以将HDFS中的数据导入到关系数据库中，这也是它的优势之一。

以Avro和Perquet的方式高效地处理文件。

HDFS是一个文件系统。(第二次)

在HDFS上，我们会放置文本文件，但有时文件会进行复制，所以我们希望能够尽可能地压缩数据，但又不喜欢处理执行时解压缩所带来的延迟。

因此，Avro和Parquet作为适用于数据处理的文件格式应运而生。

作为这两者的共同之处

• データをシリアライズできる

• バイナリ形式

Snappy等の圧縮アルゴリズムを使って、ブロック分割したときにスプリッタブル(ファイル分割状態のままでも処理可能)なので分散処理に適している

有。

以下是中文的本地化解释，仅提供一种选项：

两者的不同之处是，

Avro = 阿弗罗

• 行指向

スキーマ（カラム）構造の変更に強い

佩尔奎

• 列指向

一部のカラムのみ読み出すときのスピードが早い
Avroよりデータのファイルサイズが圧縮される

可以提出以下的例子

定义Oozie用于分布式处理的工作流程

Oozie是一种能够以工作流的形式管理多个处理的工具。通常，分散处理很少只在一个应用程序中完成，而是通过按顺序执行多个处理来实现满足要求的处理。

Oozie不仅可以构建工作流程（Job），还可以…

• Jobの監視

HiveやMapReduce,Sparkとうことなる処理を単一のJobにまとめられる

也有诸如此类的优点。

Zookeeper负责协调管理分布式节点。

在构建分布式系统时，需要协调各个集群节点之间的工作。具体而言，这种协调的方式是…

• 自分以外にどのノードが分散システムに組み込まれているのか

• 今動いていないノードがあるか（どのノードが動いていないか）

• 複数のノードが動いているとまずいときに、他のノードの動きをロックさせる

設定ファイルを全ノードで共通化させる

等等等等。

在节点之间（甚至超过100个节点）进行此类操作非常困难。
因此，Zookeeper是一个能够协调管理分布式系统的管理器。

在实际使用HBase或Kafka时，强烈建议或要求使用Zookeeper。

结束

我尝试简要整理了Hadoop生态系统。看到这些，我深深地感受到技术进步并非从无到有，而是从既有的问题解决中衍生而来。（确实是站在巨人的肩膀上）我打算进一步学习分布式系统领域。