Double count of dstat

2021-04-09

Monitering

dstat

参考
メモ

参考

メモ

dstatのtotalが2倍？になる？という話があり簡単に確認。

結論

ディスク単位のI/Oを total に入れるべきなのだが、正規表現上の仕様により、 xvda1 などのパーティション単位のI/Oも total に足されている。

実は、パーティションの値を取り除く正規表現ではあるのだが、当時の実装（※）としては xvd で始まるディスク名に対応できていなかったようだ。なお、その後、いくつか正規表現が改変されたような経緯がコミットログやGitHub Issueから見られた。

※CentOS7等で採用されたdstat0.7.2のリリース時期は2010年ころ

事象の確認

環境情報の確認。

[centos@ip-10-0-0-217 ~]$ uname -a
Linux ip-10-0-0-217.ap-northeast-1.compute.internal 3.10.0-1127.13.1.el7.x86_64 #1 SMP Tue Jun 23 15:46:38 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[centos@ip-10-0-0-217 ~]$ dstat --version
Dstat 0.7.2
Written by Dag Wieers <dag@wieers.com>
Homepage at http://dag.wieers.com/home-made/dstat/

Platform posix/linux2
Kernel 3.10.0-1127.13.1.el7.x86_64
Python 2.7.5 (default, Apr  2 2020, 13:16:51)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)]

Terminal type: xterm-256color (color support)
Terminal size: 86 lines, 310 columns

Processors: 4
Pagesize: 4096
Clock ticks per secs: 100

internal:
        aio, cpu, cpu24, disk, disk24, disk24old, epoch, fs, int, int24, io, ipc, load, lock, mem, net, page, page24, proc, raw, socket, swap, swapold, sys, tcp, time, udp, unix, vm
/usr/share/dstat:
        battery, battery-remain, cpufreq, dbus, disk-tps, disk-util, dstat, dstat-cpu, dstat-ctxt, dstat-mem, fan, freespace, gpfs, gpfs-ops, helloworld, innodb-buffer, innodb-io, innodb-ops, lustre, memcache-hits, mysql-io, mysql-keys, mysql5-cmds, mysql5-conn, mysql5-io, mysql5-keys, net-packets, nfs3,
        nfs3-ops, nfsd3, nfsd3-ops, ntp, postfix, power, proc-count, qmail, rpc, rpcd, sendmail, snooze, squid, test, thermal, top-bio, top-bio-adv, top-childwait, top-cpu, top-cpu-adv, top-cputime, top-cputime-avg, top-int, top-io, top-io-adv, top-latency, top-latency-avg, top-mem, top-oom, utmp,
        vm-memctl, vmk-hba, vmk-int, vmk-nic, vz-cpu, vz-io, vz-ubc, wifi

[centos@ip-10-0-0-217 ~]$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  60G  0 disk
└─xvda1 202:1    0  60G  0 part /

dstat 0.7.2は2010年にリリースされたようだ。

1 2	$ git log -1 --format=%ai 0.7.2 2010-06-14 22:25:44 +0000

参考までにpcpのバージョン

1 2	[centos@ip-10-0-0-217 ~]$ pcp --version pcp version 4.3.2

ここから動作確認。

fioを実行。

1
2
3

[centos@ip-10-0-0-217 ~]$ fio -rw=randwrite -bs=16k -size=1000m -iodepth=32 -directory=/tmp -direct=1 -invalidate=1 -runtime=300 -numjobs=8 -name=iotest -ioengine=libaio -group_reporting

(snip)

裏でdstatを実行

[centos@ip-10-0-0-217 ~]$ dstat -td -D total,xvda                                                                                                                                                                                                                                                                     ----system---- -dsk/total----dsk/xvda-
     time     | read  writ: read  writ
09-04 08:40:50| 373k  315k: 187k  158k
09-04 08:40:51|   0    95M:   0    47M
09-04 08:40:52|   0    87M:   0    44M

(snip)

およそ2倍になっている。

pcp-dstatだと？

[centos@ip-10-0-0-217 ~]$ pcp dstat -td -D total,xvda
----system---- --dsk/xvda---dsk/total-
     time     | read  writ: read  writ
09-04 09:16:47|           :
09-04 09:16:48|   0    41M:   0    41M
09-04 09:16:49|   0    45M:   0    45M
09-04 09:16:50|   0    50M:   0    50M
09-04 09:16:51|   0    35M:   0    35M^

(snip)

ということで、2倍になっていない。

ちなみに、そもそもpcp-dstatは、上記のdstatとは全く異なる実装に見える。

doolだと？（2021/4/8時点のmasterブランチ）

[centos@ip-10-0-0-217 Sources]$ ./dool/dool -td -D total,xvda
-----system---- -dsk/total----dsk/xvda-
      time     | read  writ: read  writ
Apr-09 11:24:54| 577k 3307k: 289k 1653k
Apr-09 11:24:55|   0    66M:   0    33M
Apr-09 11:24:56|   0    25M:   0    13M
Apr-09 11:24:57|   0    44M:   0    22M^

(snip)

ということで、dstatと同様。

doolの登場

dstatの源流は今はメンテされておらず、 dool が開発されている。

Dool is a Python3 compatible clone of Dstat.

また dstatが開発終了した話に記載されているが、他にもpcp系列のdstatが残っている。

ただし、doolにおいても、正規表現は同じようなものだった。

When DeltaLog ID is created

2021-04-04

Storage LayerDelta Lake

Delta Lake

参考
メモ
- 前提
- createRelationから確認する

参考

メモ

Delta LakeのDelta LogのIDがいつ確定するのか、というのが気になり確認した。

前提

Delta Lakeバージョン：0.8.0

createRelationから確認する

org.apache.spark.sql.delta.sources.DeltaDataSource#createRelation をエントリポイントとする。

ポイントは、DeltaLog がインスタンス化されるときである。

まず最初にインスタンス化されるのは以下。

org/apache/spark/sql/delta/sources/DeltaDataSource.scala:141

1	val deltaLog = DeltaLog.forTable(sqlContext.sparkSession, path)

org.apache.spark.sql.delta.DeltaLog は、 org.apache.spark.sql.delta.SnapshotManagement トレイトをミックスインしている。当該トレイトには、 currentSnapshot というメンバ変数があり、これは org.apache.spark.sql.delta.SnapshotManagement#getSnapshotAtInit メソッドを利用し得られる。

org/apache/spark/sql/delta/SnapshotManagement.scala:47

1	@volatile protected var currentSnapshot: Snapshot = getSnapshotAtInit

このメソッドは以下のように定義されている。

org/apache/spark/sql/delta/SnapshotManagement.scala:184

protected def getSnapshotAtInit: Snapshot = {
  try {
    val segment = getLogSegmentFrom(lastCheckpoint)
    val startCheckpoint = segment.checkpointVersion
      .map(v => s" starting from checkpoint $v.").getOrElse(".")
    logInfo(s"Loading version ${segment.version}$startCheckpoint")
    val snapshot = createSnapshot(
      segment,
      minFileRetentionTimestamp,
      segment.lastCommitTimestamp)

    lastUpdateTimestamp = clock.getTimeMillis()
    logInfo(s"Returning initial snapshot $snapshot")
    snapshot
  } catch {
    case e: FileNotFoundException =>
      logInfo(s"Creating initial snapshot without metadata, because the directory is empty")
      // The log directory may not exist
      new InitialSnapshot(logPath, this)
  }
}

ポイントは、スナップショットを作る際に用いられるセグメントである。セグメントにバージョン情報が持たれている。

ここでは3行目の

1	val segment = getLogSegmentFrom(lastCheckpoint)

にて org.apache.spark.sql.delta.SnapshotManagement#getLogSegmentFrom メソッドを用いて、前回チェックポイントからセグメントの情報が生成される。

なお、参考までにLogSegmentクラスの定義は以下の通り。

org/apache/spark/sql/delta/SnapshotManagement.scala:392

case class LogSegment(
    logPath: Path,
    version: Long,
    deltas: Seq[FileStatus],
    checkpoint: Seq[FileStatus],
    checkpointVersion: Option[Long],
    lastCommitTimestamp: Long) {

  override def hashCode(): Int = logPath.hashCode() * 31 + (lastCommitTimestamp % 10000).toInt

  (snip)

上記の通り、コンストラクタ引数にバージョン情報が含まれていることがわかる。

インスタンス化の例は以下の通り。

org/apache/spark/sql/delta/SnapshotManagement.scala:140

LogSegment(
  logPath,
  newVersion,
  deltasAfterCheckpoint,
  newCheckpointFiles,
  newCheckpoint.map(_.version),
  lastCommitTimestamp)

Power Grid Data

2021-02-12

Power Grid Data

参考
メモ

参考

以下の資料参照。

メモ

電力データ活用に関連する、割と新しい情報をまとめた。

Mesh wifi for Home Network

2021-01-31

Home Network

IPv6, WiFi, WiFi6

参考
メモ

参考

メッシュWiFiルータ

JPNE v6plus

So-net

au光

動作確認

ipv6 test

メモ

メッシュWiFi

メッシュWiFiとは、Elecomの Vol.83 メッシュ（Mesh）Wi-Fiって何？メリットと活用方法を紹介記事の通り。戸建ての家などでは、広く安定してカバーできるはず、ということで。

日本国内においてどの機器を使うか？については、メッシュルーターの選び方について整理したがわかりやすい。

個人的にはIPv6対応している点で、「Synology MR2200ac」が候補に上がった。仕様は MR2200ac を参照されたし。

JPNE v6プラス

v6プラス(IPv6/IPv4インターネットサービス) によると、

「v6プラス」は、NTT東西の次世代ネットワーク（NGN）を利用しインターネット接続を提供するISP事業者が、 IPv6及びIPv4の設備を持たずに、インターネット接続をお客さま(エンドユーザ)にご提供いただくためのサービスです。

とのこと。

Synology製Wi-FiルーターMR2200acでv6プラス接続設定によると、MR2200acでv6plusを利用する方法が記載されている。

auひかりのHGW（ホームゲートウェイ）

auひかりのホームゲートウェイはいらない? 知っておきたい不都合な真実にも記載の通り、

先ほどから触れてるとおり、auひかりはホームゲートウェイが無ければインターネットに接続することができません。その理由は、ホームゲートウェイ内に、KDDIの認証を取る機能があるからです。

とのこと。

そこで、自前のルータを利用したい場合は、 DMZ機能を利用して、ルータ機能をHGWと自前ルータの療法で動かす設定をすることもある。

au光で市販のルーターを使うが参考になる。ブリッジモードにせずDMZの下でルーターモードで利用するにはも参考になる。こちらはtp-linkのブログ。

so-net

So-net 光 with フレッツ S 東日本は、フレッツ光の契約と思われる。

So-net 光プラスの次世代通信 v6プラスは v6プラスを利用したサービスと思われる。 So-net 光プラスの次世代通信 v6プラスの対象サービスによると、 So-net 光プラスなどが対応している。その他フレッツ系のサービスが対応しているようだ。

IPv6の動作確認

ipv6 test にアクセスると良い。

Memo of How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh

2021-01-19

Data Mesh

Data Lake, Data Mesh

参考
メモ

参考

メモ

Zhamak DehghaniによるHow to Move Beyond a Monolithic Data Laketo a Distributed Data Mesh を読んで簡単にまとめた。

この文章では、ドメインが所有し、提供するデータプロダクトの相互利用に基づく「データメッシュ」の考え方を提唱するものである。固有技術そのものではなく、アーキテクチャ検討の前の「データを基礎としたサービス開発、ソフトウェア開発のためのデータの取り回し方」に関する示唆を与えようとしたもの、という理解。

Memo of Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics

2021-01-16

Storage LayerDelta Lake

Delta Lake, Paper

参考
メモ

参考

Lakehouse A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics

メモ

Lakehouse A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics の論文を確認し、簡単なメモを作成した。

考え方を節異名しつつ、Delta Lake、Delta Engineを使用した際のTPC−DSの実行結果、クエリ実行コストの情報が記載されていた。また関連研究、参考文献も過去から現在のトレンドの背景を知る上で参考になるものが多い。

Getting started of Ansible Vault

2021-01-07

Configuration ManagementAnsible

Ansible, Vault

参考
- 公式サイト
- ブログ
メモ

参考

公式サイト

Encrypting content with Ansible Vault

ブログ

Ansible-Vaultを用いた機密情報の暗号化のTips

メモ

Ansible内で使用する変数を平文でファイルに記載し、プレイブック集に入れ込むのに不安を感じるときがある。そのようなとき、Ansible Vaultを利用すると暗号化された状態で変数を管理できる。 Ansible Vaultで管理された変数をプレイブック内で通常の変数と同様に扱えるため見通しが良くなる。

公式サイトの Encrypting content with Ansible Vault が網羅的でわかりやすいのだが、具体例が足りない気がしたので以下に一例を示しておく。ここに挙げた以外の使い方は、公式サイトを参照されたし。

Ansible-Vaultを用いた機密情報の暗号化のTips も参考になった。

暗号化されたファイルの作成

secret.yml 内に変数を記述し、暗号化する。後ほど暗号化されたファイルを変数定義ファイルとして読み込む。

ここでは以下のような内容とする。

secret.yml

1 2	hoge: fuga: foo

ファイルを暗号化する。

1	$ ansible-vault create secret.yml

上記ファイルを作成する際、Vault用パスワードを聞かれるので適切なパスワードを入力すること。あとでパスワードは利用する。

（参考）復号して平文化

1	$ ansible-vault decrypt secret.yml

（参考）暗号化されたファイルの編集

1	$ ansible-vault edit secret.yml

（参考）Vaultパスワードをファイルとして渡す

プロンプトで入力する代わりに、どこかプレイブック集の外などにVaultパスワードを保存し利用することもできる。ここでは、 ~/.vault_password にパスワードを記載したファイルを準備したものとする。編集する例を示す。

1	$ ansible-vault edit secret.yml --vault-password-file ~/.vault_password

プレイブック内で変数として利用

変数定義ファイルとして渡し、プレイブック内で変数として利用する。以下のようなプレイブックを作る。

test.yml

- hosts: localhost
  vars_files:
    - secret.yml
  tasks:
    - name: debug
      debug:
        msg: "{{ hoge.fuga }}"

以下、簡単な説明。

変数定義ファイルとして secret.yml を指定（ vars_files の箇所）
今回はdebugモジュールを利用し、変数内の値を表示することとする。
暗号化された変数定義ファイル secret.yml に記載されたとおり、構造化された変数 hoge.fuga の値を利用する。
結果として、foo という内容がSTDOUTに表示されるはず。

プレイブックを実行する。

1	$ ansible-playbook test.yml --ask-vault-pass

Use static image on Hexo blog

2020-12-31

Hexo

参考
メモ

参考

メモ

Hexo 記事に画像を貼り付けるを参考に、もともとCacooのリンクを使っていた箇所をすべてスタティックな画像を利用するようにした。

post_asset_folderを利用して、記事ごとの画像ディレクトリを利用することも考えたが、画像はひとところに集まっていてほしいので、 Global-Asset-Folder を利用することにした。

なお、上記ブログでは

1	プロジェクトトップ/images/site

以下に画像を置き、

1	![猫](/images/site/cat.png)

のようにリンクを指定していた。

自身の環境では、rootを指定しているので

1	プロジェクトトップ/image

以下にディレクトリを置き、

1	![猫](memo-blog/images/cat.png)

と指定することにした。

Delta Lake with Alluxio

2020-12-31

Storage LayerDelta Lake

Alluxio, Delta Lake

参考
メモ
- 疑似分散で動作確認

参考

論文

Hadoop環境

ansible-bigdata

Alluxioドキュメント

メモ

Delta Lake High-Performance ACID Table Storage over Cloud Object Stores や Lakehouse A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics の論文の通り、 Delta Lakeはキャッシュとの組み合わせが可能である。

今回は、ストレージにHDFS、キャッシュにAlluxioを使って動作確認する。

疑似分散で動作確認

実行環境の準備

ansible-bigdata あたりを参考に、Hadoopの疑似分散環境を構築する。 Bigtopベースの2.8.5とした。

併せて、同Ansibleプレイブック集などを用いて、Spark3.1.1のコミュニティ版を配備した。

併せて、Alluxioは2.5.0-2を利用。

Alluxioに関しては、以下のようにコンパイルしてパッケージ化して用いることできる。

$ sudo -u alluxio mkdir /usr/local/src/alluxio
$ sudo -u alluxio chown alluxio:alluxio /usr/local/src/alluxio
$ cd /usr/local/src/alluxio
$ sudo -u alluxio git clone git://github.com/alluxio/alluxio.git
$ sudu -u alluxio git checkout -b v2.5.0-2 refs/tags/v2.5.0-2
$ sudo -u alluxio mvn install -Phadoop-2 -Dhadoop.version=2.8.5 -DskipTests

コンフィグとしては以下を利用。

$ cat conf/alluxio-site.properties

(snip)

# Common properties
# alluxio.master.hostname=localhost
alluxio.master.hostname=localhost
# alluxio.master.mount.table.root.ufs=${alluxio.work.dir}/underFSStorage
# alluxio.master.mount.table.root.ufs=/tmp
alluxio.master.mount.table.root.ufs=hdfs://localhost:8020/alluxio

# Security properties
# alluxio.security.authorization.permission.enabled=true
# alluxio.security.authentication.type=SIMPLE
alluxio.master.security.impersonation.yarn.users=*
alluxio.master.security.impersonation.yarn.groups=*

# Worker properties
# alluxio.worker.ramdisk.size=1GB
alluxio.worker.ramdisk.size=1GB
# alluxio.worker.tieredstore.levels=1
# alluxio.worker.tieredstore.level0.alias=MEM
# alluxio.worker.tieredstore.level0.dirs.path=/mnt/ramdisk

# User properties
# alluxio.user.file.readtype.default=CACHE
# alluxio.user.file.writetype.default=MUST_CACHE

ポイントは以下の通り。

疑似分散環境のHDFS利用
Alluxioの使用するディレクトリとして、/alluxioを利用
マスタはローカルホストで起動

フォーマット、起動

1 2	$ sudo -u alluxio ./bin/alluxio format $ sudo -u alluxio ./bin/alluxio-start.sh local SudoMount

テストを実行

1	$ sudo -u alluxio ./bin/alluxio runTests

もしエラーが生じた場合は、例えばHDFSの/alluxioディレクトリに、適切な権限設定、所有者設定がされているかどうかを確認すること。

Alluxioが起動すると以下のようなUIを確認できる（ポート19999）

先程テストで書き込まれたファイル群が見られるはず。

ここでは、上記の通り、環境を整えた前提で以下説明する。

Sparkの起動確認

Examples: Use Alluxio as Input and Output を参考に、Alluxio経由での読み書きを試す。

予め、今回の動作確認で使用するテキストデータ（AlluxioのREADME）をアップロードしておく。

1	$ sudo -u alluxio /opt/alluxio/default//bin/alluxio fs copyFromLocal /opt/alluxio/default/LICENSE /LICENSE

予め、以下のような設定をspark-defaults.confに入れておく。 Alluxioのクライアントライブラリを用いられるように。

1 2	spark.driver.extraClassPath /opt/alluxio/default/client/alluxio-2.5.0-2-client.jar spark.executor.extraClassPath /opt/alluxio/default/client/alluxio-2.5.0-2-client.jar

Sparkが起動することを確認する。ここではDelta Lakeも含めて起動する。

$ /usr/local/spark/default/bin/spark-shell \
  --packages io.delta:delta-core_2.12:0.8.0 \
  --conf "spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension" \
  --conf "spark.sql.catalog.spark_catalog=org.apache.spark.sql.delta.catalog.DeltaCatalog"

起動したシェルでAlluxio上のREADMEファイルを読み取り、行数を確認する。

scala> val pathOnAlluxio = "alluxio://localhost:19998/LICENSE"

scala> val testDF = spark.read.text(pathOnAlluxio)

scala> testDF.count
res0: Long = 482

Delta Lakeを通じて書き込む動作確認

準備として、Alluxio上に、dobachiユーザ用のディレクトリを作成してみる。

1
2
3

$ sudo -u alluxio /opt/alluxio/default/bin/alluxio fs mkdir /users
$ sudo -u alluxio /opt/alluxio/default/bin/alluxio fs mkdir /users/dobachi
$ sudo -u alluxio /opt/alluxio/default/bin/alluxio fs chown dobachi:dobachi /users/dobachi

先程起動しておいたシェルで、Delta Lake形式のデータを書き込んで見る。

scala> val data = spark.range(0, 5)
data: org.apache.spark.sql.Dataset[Long] = [id: bigint]

scala> val outputUrl = "alluxio://localhost:19998/users/dobachi/numbers"

scala> data.write.format("delta").save(outputUrl)

すると以下のようなエラーが生じた。

scala> data.write.format("delta").save(outputUrl)
21/01/05 22:47:50 ERROR HDFSLogStore: The error typically occurs when the default LogStore implementation, that
 is, HDFSLogStore, is used to write into a Delta table on a non-HDFS storage system.
 In order to get the transactional ACID guarantees on table updates, you have to use the
 correct implementation of LogStore that is appropriate for your storage system.
 See https://docs.delta.io/latest/delta-storage.html " for details.

org.apache.hadoop.fs.UnsupportedFileSystemException: fs.AbstractFileSystem.alluxio.impl=null: No AbstractFileSystem configured for scheme: alluxio

(snip)

当たり前だが、Delta Lakeの下回りのストレージとして標準では、 Alluxioが対応しておらず、LogStoreからエラーが生じた、ということのようだ。

一瞬、LogStoreを新たに開発しないといけないか？と思ったものの、よく考えたら、HDFSHadoopFileSystemLogStoreから Alluxioのスキーマを認識させてアクセスできるようにすればよいだけでは？と思った。そこで、Hadoopの設定でAlluxioFileSystemをalluxioスキーマ（ファイルシステムのスキーマ）に明示的に登録してみる。

/etc/hadoop/conf/core-site.xmlに以下を追記。

<property>
  <name>fs.AbstractFileSystem.alluxio.impl</name>
  <value>alluxio.hadoop.AlluxioFileSystem</value>
  <description>The FileSystem for alluxio uris.</description>
</property>

再びSparkを立ち上げ、適当なデータを書き込み。

scala> val data = spark.range(0, 5)

scala> val outputUrl = "alluxio://localhost:19998/users/dobachi/numbers"

scala> data.write.format("delta").save(outputUrl)

以上のように書き込みに成功した。

つづいて、テーブルとして読み出す。

scala> val df = spark.read.format("delta").load(outputUrl)
scala> df.show
+---+
| id|
+---+
|  1|
|  2|
|  3|
|  4|
|  0|
+---+

テーブルへの追記。

scala> val addData = spark.range(5, 10)
scala> addData.write.format("delta").mode("append").save(outputUrl)
scala> df.show
+---+
| id|
+---+
|  3|
|  9|
|  6|
|  5|
|  1|
|  8|
|  4|
|  2|
|  7|
|  0|
+---+

また、追記書き込みをしたのでDeltaログが増えていることが分かる。（3回ぶんのログがあるのは、↑には記載していないがミスったため）

（補足）HDFS上のディレクトリ権限に関するエラー

Sparkでの処理実行時にYARNで実行していたところ、Executorにおける処理からAlluxioを呼び出すときにエラー。 yarnユーザでのアクセスとなり、HDFS上の /alluxio へのアクセス権がなかったと考えられる。

1
2

21/01/05 02:54:35 WARN TaskSetManager: Lost task 0.0 in stage 0.0 (TID 0, hadoop-pseudo, executor 2): alluxio.exception.status.UnauthenticatedException: Channel authentication failed with code:UNAUTHENTICATED. Channel: GrpcChannelKey{ClientType=FileSystemMasterClient, ClientHostname=hadoop-pseudo.mshome.net, ServerAddress=GrpcServerAddress{HostName=localhost, SocketAddress=localhost:19998}, ChannelId=81f7d97f-8e32-4289-bcab-ea6008d5ffac}, AuthType: SIMPLE, Error: alluxio.exception.status.UnauthenticatedException: Plain authentication failed: Failed to authenticate client user="yarn" connecting to Alluxio server and impersonating as impersonationUser="vagrant" to access Alluxio file system. User "yarn" is not configured to allow any impersonation. Please read the guide to configure impersonation at https://docs.alluxio.io/os/user/2.4/en/operation/Security.html
        at alluxio.exception.status.AlluxioStatusException.from(AlluxioStatusException.java:141)

Alluxio Security のドキュメント中に「Client-Side Hadoop Impersonation」を読むと、「なりすまし」を許可する設定があるようだ。

そこで、yarnユーザが様々なユーザになりすませるような簡易設定を以下のように加えることにした。実際の運用する際は、なりすましのスコープに注意したほうが良さそうだ。

conf/alluxio-site.properties

1 2	alluxio.master.security.impersonation.yarn.users=* alluxio.master.security.impersonation.yarn.groups=*

ドキュメントではクライアントで alluxio.security.login.impersonation.username も指定するよう書かれていたが、起動時にしてしなくてもアクセスできるようになった。あとで実装を調べたほうが良さそうだ。

Information about trends in 2020

2020-12-26

ResearchTrends

Trends

参考
メモ

参考

ガートナー

ガートナー、「先進テクノロジのハイプ・サイクル：2020年」を発表

データ・ファブリック

DNAコンピューティング

アダプティブラーニング

米軍の教育でもAIが活躍　「アダプティブ・ラーニング」の可能性 (1/4)

デジタル・ツイン

IOWN

メモ

オープンになっている情報を中心に既存情報を軽くまとめる。特にデータ処理、データ活用との関連を探る。

先進テクノロジのハイプ・サイクル：2020年

ガートナー、「先進テクノロジのハイプ・サイクル：2020年」を発表の記事によると、 2020/8/19にハイプ・サイクルが発表された。

記事冒頭で触れられているとおり、COVID-19の影響は否定できない。例ではヘルス・パスポート、ソーシャル・ディスタンシング・テクノロジが挙げられていた。記載されているととおり、「過度な期待」として初登場する技術は少ないのだが、それに該当するということで注目されている。

挙げられていたトレンドと所感

デジタル・ミー
- つまりは、デジタル・ツイン
- 多分にもれずデジタル・ツイン関連は取り上げられていた。
- 過去になかったデータを使うようになるという側面はあるが、それに合わせた新たなアーキテクチャが必要になるか。
  - 過去のブーム面との例
    - 大量の顧客行動情報、ログ：非構造データ処理に適した並列分散処理フレームワーク（MapReduceなど）
    - 大量の画像データ：深層学習
    - 大量のセンサーデータ：IoT、ストリーム処理
    - 大量のデジタル・ツイン・データ：？
コンポジット・アーキテクチャ
- 一言で言うとデータ・ファブリック※1を基礎としたアーキテクチャ
  - ※1）つまりオンプレ、クラウドに点在するデータを最適な場所に配置し、いつでも利用可能にする
- 重要なのは柔軟性を実現するという目論見
- 柔軟性を求める組織に必要とされるアーキテクチャと考えることもできそうだ
フォーマティブAI
- 一言で言うと状況に動的に対応するAI
- 動的に適応していく、さらに突き詰めると「自律的に…」というニュアンスが生じそう
- AIに関する倫理の議論と関連すると考えられる。
アルゴリズムによる信頼
- 一言で言うと、責任ある権限に基づく信頼モデルから、アルゴリズムによる信頼への転換
シリコンの先へ
- 一言で言うと、シリコンに変わる新素材に対する期待
- 参考
  - DNAコンピューティング（日本生物理学会）、DNAコンピューティングの原理と展開（小倉裕介）

個人的にピックアップしたキーワードと所感

アダプティブな機械学習
- 「学習」という領域におけるパーソナライズの一つの形と思えばよいか
- 近年ではAIの普及もあり、機械的な支援をもとに実現することも増えてきたか。
- 参考
  - 米軍の教育でもAIが活躍　「アダプティブ・ラーニング」の可能性 (1/4)
シチズン・ツイン
- Google検索では適切な結果は得られなかった
人のデジタル・ツイン
- シチズン・ツインと同様、モノのデジタル化に続いて、ヒトのデジタル化を目指す、ということか。
- NTTサービスイノベーション総合研究所の提唱する「デジタルツインコンピューティング」では、層の中間層を設けることが重要とされている。
- 参考
- ヒトと社会のデジタル化世界 ─ デジタルツインコンピューティング ─
- IOWNでヒトもデジタル化　“私のコピー”が仮想空間で仕事する世界
データ・ファブリック
- 「オンプレ、クラウドに点在するデータを最適な場所に配置し、いつでも利用可能にする」というコンセプトは特徴的だが、ベンダによって実際の定義が異なるように感じる。
- 「データ民主化」と同様のコンセプトに感じる。
- ポイントはストレージとしての特徴ではなく、「統合」を実現する側面か
- 参考情報
  - データファブリックを実現するクラウドデータサービス、ネットアップとNEC、国内初となるデータファブリックソリューションの提供を開始、 NetAppのデータファブリックは時代遅れなのか？、世界のデータファブリックの市場、Talend Data Fabric、 Splunk エンタープライズマシンデータファブリック

週刊ダイヤモンド 2020年12/12号

週刊ダイヤモンド 2020年12/12号の中に、「NTT帝国の逆襲」という特集記事がある。

技術というより、事業職が強いが念の為に（あえて）技術に関連するキーワードだけ述べる。なお、この書籍で重要なのは、本来はどちらかというとビジネス戦略側面である。詳細は当該書籍を参照されたし。

技術キーワード

IOWN構想
- 光ファイバー、ネットワーク転送、音声等のNTT特許数は圧倒的である。
- 電力効率100話い、伝送容量125倍、遅延を200分の1を目指す
- 光電子融合型の光トランジスタ開発によりリード。
O-RAN
- 通信規格を主導。オープン化で囲い込みを打破する。
V-RAN
- 通信の仮想化

IOWN公開情報

あくまで公開された情報ではあるがリスト化しておく。

IOWN公式ウェブサイト
- 概要や目指しているところを理解できるコンテンツが公開されている
- 構成要素は以下の通り。
  - 「オールフォトニクス・ネットワーク」
    - 「大容量光伝送システム・デバイス」、「イジングマシン」、「光格子時計ネットワーク」
  - 「デジタルツインコンピューティング」
    - 「多様な産業やモノとヒトのデジタルツインを自在に掛け合わせて演算を行う」ことが特色
  - 「コグニティブ・ファウンデーション」
    - ICTリソースを全体最適に調和させ、必要な情報をNW内に流通させる。

参考

メモ

結論

事象の確認

関連する実装は？

doolの登場

参考

メモ

前提

createRelationから確認する

参考

メモ

参考

メッシュWiFiルータ

JPNE v6plus

So-net

au光

動作確認

メモ

メッシュWiFi

JPNE v6プラス

auひかりのHGW（ホームゲートウェイ）

so-net

IPv6の動作確認

参考

メモ

参考

メモ

参考

公式サイト

ブログ

メモ

暗号化されたファイルの作成

（参考）復号して平文化

（参考）暗号化されたファイルの編集

（参考）Vaultパスワードをファイルとして渡す

プレイブック内で変数として利用

参考

メモ

参考

論文

Hadoop環境

Alluxioドキュメント

メモ

疑似分散で動作確認

実行環境の準備

フォーマット、起動

Sparkの起動確認

Delta Lakeを通じて書き込む動作確認

（補足）HDFS上のディレクトリ権限に関するエラー

参考

ガートナー

データ・ファブリック

DNAコンピューティング

アダプティブラーニング

デジタル・ツイン

IOWN

メモ

先進テクノロジのハイプ・サイクル：2020年

挙げられていたトレンドと所感

個人的にピックアップしたキーワードと所感

週刊ダイヤモンド 2020年12/12号

IOWN公開情報