Beginner must-see! A future that can be opened by learning HadoopDataWorks Summit
What is "Hadoop" now? It is difficult to hear ... But those who are interested, those who are thinking about the future as active as a data engineer, those who are new to the first time, through introductions of Hadoop and the surrounding ecosystem, introducing merits and examples, "What now Should I learn? "And I will introduce the future spreading through learning Hadoop and the surrounding ecosystem.
【DLゼミ】XFeat: Accelerated Features for Lightweight Image Matchingharmonylab
公開URL:https://arxiv.org/pdf/2404.19174
出典:Guilherme Potje, Felipe Cadar, Andre Araujo, Renato Martins, Erickson R. ascimento: XFeat: Accelerated Features for Lightweight Image Matching, Proceedings of the 2024 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR) (2023)
概要:リソース効率に優れた特徴点マッチングのための軽量なアーキテクチャ「XFeat(Accelerated Features)」を提案します。手法は、局所的な特徴点の検出、抽出、マッチングのための畳み込みニューラルネットワークの基本的な設計を再検討します。特に、リソースが限られたデバイス向けに迅速かつ堅牢なアルゴリズムが必要とされるため、解像度を可能な限り高く保ちながら、ネットワークのチャネル数を制限します。さらに、スパース下でのマッチングを選択できる設計となっており、ナビゲーションやARなどのアプリケーションに適しています。XFeatは、高速かつ同等以上の精度を実現し、一般的なラップトップのCPU上でリアルタイムで動作します。
セル生産方式におけるロボットの活用には様々な問題があるが,その一つとして 3 体以上の物体の組み立てが挙げられる.一般に,複数物体を同時に組み立てる際は,対象の部品をそれぞれロボットアームまたは治具でそれぞれ独立に保持することで組み立てを遂行すると考えられる.ただし,この方法ではロボットアームや治具を部品数と同じ数だけ必要とし,部品数が多いほどコスト面や設置スペースの関係で無駄が多くなる.この課題に対して音𣷓らは組み立て対象物に働く接触力等の解析により,治具等で固定されていない対象物が組み立て作業中に運動しにくい状態となる条件を求めた.すなわち,環境中の非把持対象物のロバスト性を考慮して,組み立て作業条件を検討している.本研究ではこの方策に基づいて,複数物体の組み立て作業を単腕マニピュレータで実行することを目的とする.このとき,対象物のロバスト性を考慮することで,仮組状態の複数物体を同時に扱う手法を提案する.作業対象としてパイプジョイントの組み立てを挙げ,簡易な道具を用いることで単腕マニピュレータで複数物体を同時に把持できることを示す.さらに,作業成功率の向上のために RGB-D カメラを用いた物体の位置検出に基づくロボット制御及び動作計画を実装する.
This paper discusses assembly operations using a single manipulator and a parallel gripper to simultaneously
grasp multiple objects and hold the group of temporarily assembled objects. Multiple robots and jigs generally operate
assembly tasks by constraining the target objects mechanically or geometrically to prevent them from moving. It is
necessary to analyze the physical interaction between the objects for such constraints to achieve the tasks with a single
gripper. In this paper, we focus on assembling pipe joints as an example and discuss constraining the motion of the
objects. Our demonstration shows that a simple tool can facilitate holding multiple objects with a single gripper.
9. Agenda
NameNode HA 化の必要性
NameNode HA 化前後の比較
NameNode HA 全体構成図
NameNode HA 構成の動き
Hadoopクラスタ全体構成図
NameNode HA に関する設定項目
NameNode HA 化前提条件
NameNode HA化手順
11. Agenda
NameNode HA 化の必要性
NameNode HA 化前後の比較
NameNode HA 全体構成図
NameNode HA 構成の動き
Hadoopクラスタ全体構成図
NameNode HA に関する設定項目
NameNode HA 化前提条件
NameNode HA化手順
12. NameNode HA 化前提条件
今回は、以下を前提条件として NameNode HA化を実施
- HDPバージョン:2.4.2
- Ambariバージョン:2.5.2
- Ambariにて、以下の構成でHadoopクラスタ構築済み
Active NN ResourceManager
JobHistoryServer
Master
・DataNode
・NodeManager
Slave
Ambari
Server
MySQL
管理系
Secondary NN
13. Agenda
NameNode HA 化の必要性
NameNode HA 化前後の比較
NameNode HA 全体構成図
NameNode HA 構成の動き
Hadoopクラスタ全体構成図
NameNode HA に関する設定項目
NameNode HA 化前提条件
NameNode HA化手順
23. Agenda
NameNode HA 化の必要性
NameNode HA 化前後の比較
NameNode HA 全体構成図
NameNode HA 構成の動き
Hadoopクラスタ全体構成図
NameNode HA に関する設定項目
NameNode HA 化前提条件
NameNode HA化手順
25. Agenda
NameNode HA 化の必要性
NameNode HA 化前後の比較
NameNode HA 全体構成図
NameNode HA 構成の動き
Hadoopクラスタ全体構成図
NameNode HA に関する設定項目
NameNode HA 化前提条件
NameNode HA化手順
26. NameNode HA に関する設定項目
hdfs-site.xml にある HA に関するプロパティ
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
⇒ 自動フェールオーバー有効
<name>dfs.ha.fencing.methods</name>
<value>shell(/bin/true)</value>
⇒ フェンシング方法「shell」()内は実行コマンド
※/bin/true は正常終了する(戻り値0を返す)だけのコマンド
何もしないが内部的にはフェンシングが成功したように見なされる
<name>dfs.ha.namenodes.[nameservice ID]</name>
<value>nn1,nn2</value>
⇒ 個々のNameNode ID
27. Agenda
NameNode HA 化の必要性
NameNode HA 化前後の比較
NameNode HA 全体構成図
NameNode HA 構成の動き
Hadoopクラスタ全体構成図
NameNode HA に関する設定項目
NameNode HA 化前提条件
NameNode HA化手順
29. Agenda
NameNode HA 化の必要性
NameNode HA 化前後の比較
NameNode HA 全体構成図
NameNode HA 構成の動き
Hadoopクラスタ全体構成図
NameNode HA に関する設定項目
NameNode HA 化前提条件
NameNode HA化手順
36. NameNode HA構成の動き(F/O時)
ZK1 ZK2 ZK3
NameNode
(Active)
ZKFC
NameNode
(Standby
⇒ Active)
NameNode#1(192.168.1.1) NameNode#2(192.168.1.2)
ヘルスチェックヘルスチェック
⇒ SERVICE_HEALTHY
セッション管理
Active 選出
セッション管理
Active 選出
ActiveStandbyElector
HealthMonitor
ZKFC
ActiveStandbyElector
HealthMonitor
/Hadoop-ha
②一時znode ③一時znode
永続znode
①
万が一、Active NameNodeの状態が正常なのに、ZKとのセッションが切れてしまったら?
①何らかの理由でZKとのセッションが切れた
②NameNode#1が作成した一時znodeが消滅
③StandbyであるNameNode#2は一時znodeの作成を試み、成功するとActiveになる権利を得る
⇒ Active が 2つ = Split Brain の発生?
これを防ぐために NameNode#2 は Active になる前に永続znode の情報を読み込み、誰が今まで Active
だったかをチェックし、今まで Active だった ノード(NameNode#1) に対してフェンスを行う
37. NameNode HA構成の動き(F/O時)
一時znode 一時znode
永続znode ← 情報書換
ZK1 ZK2 ZK3
NameNode
(Active)
ZKFC
NameNode
(Active)
ZKFC
Master-201 Master-202
⑤ヘルスチェック
状態切り替え
⑤ヘルスチェック
⇒ SERVICE_HEALTHY
⑥セッション管理
⑦Active NN 選出
⑥セッション管理
⑦Active NN 選出hadoop-hdfs-zkfc-[NameNode#2].logより抜粋
フェンスが必要な古いActiveをチェック
ha.ActiveStandbyElector - Checking for any old active which needs to be fenced...
ha.ActiveStandbyElector - Old node exists:
0a0a4e616d654e6f6465484112036e6e321a0e4d61737465722d3230322e636f6d20d43e28d33e
ha.ZKFailoverController - Should fence: NameNode at [NameNode#1]/192.168.1.1:802
フェンス処理実施
ha.NodeFencer - ====== Beginning Service Fencing Process... ======
ha.NodeFencer - Trying method 1/1: org.apache.hadoop.ha.ShellCommandFencer(/bin/true)
ha.NodeFencer - ====== Fencing successful by method
org.apache.hadoop.ha.ShellCommandFencer(/bin/true) ======
フェンス成功後、永続znodeを書き換えActiveへ
ha.ActiveStandbyElector - Writing znode /hadoop-ha/[nameserviec ID]/ActiveBreadCrumb to indicate
that the local node is the most recent active...
ha.ZKFailoverController - Trying to make NameNode at [NameNode#2]/192.168.1.2:8020 active...
ha.ZKFailoverController - Successfully transitioned NameNode at [NameNode#2]/192.168.1.2:8020 to
active state
⇒ 上記の動きによりActiveは必ず1つとなる
41. NameNode HA構成の動き
Master-202
NameNode
(Active) Quorum
JournalManager
Journal
Node1
NameNode
(Active)Quorum
JournalManager
②edits 書き込み
Master-201 ①NW的に完全に分離
Journal
Node2
Journal
Node3
②edits 書き込み
edits
最新エポック番号③
エポック番号②エポック番号③
hadoop-hdfs-journalnode-[NameNode#1].log より抜粋 (意図的にF/O、F/Bを繰り替えした際)
INFO server.Journal - Updating lastWriterEpoch from 0 to 1 for client /192.168.1.1
INFO server.Journal - Updating lastWriterEpoch from 1 to 2 for client /192.168.1.2
INFO server.Journal - Updating lastWriterEpoch from 2 to 3 for client /192.168.1.1
INFO server.Journal - Updating lastWriterEpoch from 3 to 4 for client /192.168.1.2
INFO server.Journal - Updating lastWriterEpoch from 4 to 5 for client /192.168.1.1
INFO server.Journal - Updating lastWriterEpoch from 5 to 6 for client /192.168.1.2
INFO server.Journal - Updating lastWriterEpoch from 6 to 7 for client /192.168.1.1
/hadoop/hdfs/journal/[nameservice ID]/current/last-promised-epoch にて確認
# cat last-promised-epoch
7
⇒ JournalNodeは最新のエポック番号情報を保持している