Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
ー 章 データシステムの将来ー
データ指向
アプリケーションデザイン輪読
会
自己紹介
名前 もーすけ @mosuke5
いま KubernetesやDevOpsに関するプロフェッショ
ナルサービス
それまで Alibaba Cloudの日本リージョンの立ち上げ・
運営
データストアサービスがたくさん。アリババメンバーか...
はじめに
データ指向アプリケーションデザインの12章(最終章)の輪読会資料です。書籍の内
容に沿っていますが、例などは自分の実体験などにそってアレンジしている箇所が
あります。書籍の内容そのままではありませんので、本資料を参考にしつつ自分で
最...
12章 データシステムの将来
これまでは現在の姿についての説明してきた。
視点を将来に向け、あるべき姿について説明する。将来の話については、筆者の主観が入って
いる点は注意が必要。
そもそもこの書籍の目標は、信頼性があり、スケーラブルで、メンテ...
データのインテグレーション
言いたいこと
前提として、データ利用される様々な環境のすべてに適した単一のソフトウェアは存
在しない。
ストレージエンジンの議論(3章)では、log-structuredストレージ・Bツリー・列指向ス
トレージ、レプリケーションの議論(5章)で...
導出データシステム
導出データシステム=「導出システム内のデータは、他のシステムの既存データを
何らかの方法で変換あるいは処理した結果です。導出データは失ったとしても、オリ
ジナルのソースから再作成できます。」(p424)
任意の処理
id n...
RDB(単一ソフトウェア)ですべてをまかなえる?
例えば、検索エンジンという文脈で言えば、 PostgreSQLには全文検索を提供するモジュール pg_bigm
(ピージーバイグラム ) を備える。導出データシステムって本当に必要?
実現したい...
導出データと分散トランザクション
役割に合わせて導出データシステムをつくる意味はわかってきた。ではどうやって導出データを作っていけ
ばいいか?まずは分散トランザクションで考えてみる。
例として、ECサイトを開発運用しているとする。 ECサイトの...
非同期での導出データシステム
分散トランザクションの限界を知ると、非同期での導出データを作成する方法の重要性がわかる。例として
CDC(Change Data Capture, 変更データキャプチャ )。詳しくは「11.2.2 変更データキャプ...
全順序の限界
小さなシステムであれば、全順序を保つイベントログを構築することができる。規模が大きくなり、複雑にな
ると限界にぶつかる。
全順序を保つには、単一のリーダーノードがすべてのイベントが処理することで実現可能。たとえば、地理
的に分散し...
バッチ処理とストリーム処理
データ結合の目標は、データを適切な場所に適切なフォーマットで置くこと。そのた
めには、入力データの取り込み、変換、結合、フィルタリング、集計、モデルのトレー
ニング、評価、出力が必要で、バッチ処理・ストリーム処理はこ...
バッチ処理はデータの「再処理」
バッチ処理は大量に蓄積された履歴データを「再処理」し、既存のデータから新たなビューを導
出できる(バッチ処理の詳細は10章)。既存データの再処理によって、導出データのメンテナンス
性があがる。再処理のため既存の導...
ラムダアーキテクチャ
出典 http://www.intellilink.co.jp/article/column/bigdata-kk03.html
「サービスレイヤーとスピードレイヤーの双方に対して問合せをし、 その結果をマージしてユーザー...
バッチ処理とストリーム処理の統合
最近の研究で、ラムダアーキテクチャの欠点もなくしながらも、その利点を享受できるようにも
なってきた。バッチ演算とストリーム演算を同じシステム上で実装できるようになってきた。実現
するには、以下のような機能が必要...
データベースを解きほぐす
言いたいこと
出典
高い抽象度でみると、データベースも
Hadoopもオペレーティングシステムも同じ機能を実行して
いる。もちろん違いはあるが「情報管理」システムという意味では同じ。類似点と相違点を見てい
くことには価値があり、これらを最善の部...
巨大なデータベースと
考えられる
CREATE INDEXは導出データシステムと同じ?
CREATE INDEXは本質的には既存のデータセットを再処理し、既存のデータに対する新しい
ビューとしてインデックスを導出する。組織全体にわたるデータフロ...
全てに関するメタデータベース
すべてのユースケースに適する1つのデータベースは存在しないと
いう前提に立つと、様々なストレージや処理のツールが1つのシス
テムにまとめる道筋は2つある。
1. フェデレーテッドデータベース(読み取りの統合)
例と...
解体されたデータベース
(1) システムレベルの話で、耐障害性があがる。イベントログはメッセージをバッファリングできるため、他
のコンポーネントが一時的に障害が発生しても復旧後においつくことが可能。
(2) 人間レベルでは、業務の分離がしやすい...
解体されたデータベースと既存データベース
解体されたデータベースを未来の方向性と書いているが、それは既存のデータベースを置き換
えるものではない。
解体されたデータベースを構成するのに依然として必要であり、そして解体されたデータベース
の目的は...
データフロー中心のアプリケーション設計
スプレッドシートさえも、主要なプログラミング言語のほとんどよりはるかに進んだ
データフロープログラミング機能をもっている。スプレッドシートでは、とある値に変化
があれば、敷の計算結果は自動的に再計算される...
アプリケーションコードと状態の分離
あるデータセットが他のデータセットから導出される場合、なんらかの種類の変換関数を経由す
る必要がある。セカンダリインデックスの生成のように標準的で型通りなればいいが、そうではな
い場合、固有のコードを書く必要...
書き込みパスと読み込みパスの変化
アプリケーション
サーバ
言語解析
検索インデックス
検索クエリの実行
アプリケーション
サーバ
書き込みパス 読み込みパス
マテリアライズ
ドビュー
キャッシュ
ブラウザローカ
ルストレージ
書き込みパス 読...
正確性をもとめて
言いたいこと
ステートレスなアプリケーションであれば、何かがおかしくなってもあまり問題にならない。バグを
修正し、再起動すればいい。データベースのようなステートフルなシステムはそれほど単純では
ない。われわれは、信頼性が高く、正確なアプリケーシ...
データベースのエンドツーエンド論
1. 操作を厳密に一度だけ実行する
(正確性を得るのに手間)
メッセージングシステムのセマンティクスは、at-least-onceかat-most-onceが一般的。メッセージをロストするか、重複
して送られる...
制約の強制
パーティショニングされたログを使うことで、アトミックなコミットなしに実現できる。前
のことを非同期かつスケーラブルな環境で行うことが可能。
メッセージング
(リクエストIDの
パーティション)
ユーザ からユーザ へ送金
送金 メッ...
適時性と整合性
「一貫性」という言葉の特性として2つ。ほとんどのアプリケーションでは「整合性」の
ほうが重要視されている。
● 適時性
ユーザーが最新の状態のシステムを観察できることを保証すること。
● 整合性(★)
破損がないこと。データのロ...
正しいことを行う
言いたいこと
今までのセクションとは異なって、一歩引いた視点からの意見。
データは抽象的なものとして扱ってしまうことも多いが、多くのデータは人の行動や関心、アイデ
ンティティなど人に関すること。この種類のデータは人間性と尊敬をもって扱わなければ...
予測分析
予測分析はビッグデータ時代のブームのひとつ。もちろんいい面もおおいが、アルゴリズムによってはじき
出されえる人々がいる可能性があることを忘れてはいけない。
1. バイアスと差別
アルゴリズムは、バイアスを学習することもある。
それにど...
プライバシーと追跡
データの収集そのものに倫理的な問題があることもある。サービスの利用の中で、明示的に入
力したデータが保存されることは理解できるが、ユーザが行った行動が追跡され利用されていく
ことを意識する必要がある。たとえば、サービスが広告...
データ指向アプリケーションデザイン
データシステムを理解するための要素技術の解説が満
載。基礎を抑えた、システムアーキテクチャ、技術選定が
できるようになろう。
● リレーショナルモデルとドキュメントモデル
● データベースを駆動するデータ構造...
Nächste SlideShare
Wird geladen in …5
×

【解説】データ指向アプリケーションデザイン 12章 データシステムの未来

データ指向アプリケーションデザイン 12章 データシステムの未来について解説です。輪読会で12章担当だったため解説スライドを公開します。
また、データ指向アプリケーションデザイン解説についてはこちらのブログからご覧ください。
https://blog.mosuke.tech/entry/2021/01/24/designing-data-intensive-applications/

  • Loggen Sie sich ein, um Kommentare anzuzeigen.

  • Gehören Sie zu den Ersten, denen das gefällt!

【解説】データ指向アプリケーションデザイン 12章 データシステムの未来

  1. 1. ー 章 データシステムの将来ー データ指向 アプリケーションデザイン輪読 会
  2. 2. 自己紹介 名前 もーすけ @mosuke5 いま KubernetesやDevOpsに関するプロフェッショ ナルサービス それまで Alibaba Cloudの日本リージョンの立ち上げ・ 運営 データストアサービスがたくさん。アリババメンバーからオブジェクトストレー ジやバッチ系コンピューティングなどの実装を教えてもらって調べたり。今に なって理解したことも多い。。 モバイルネットワークの監視システムの開発・ 運用 メインはRDB(大規模の場合は管理対象にあわせてシャーディング ?とかし てた)。キャッシュやジョブ管理で Redis, memcached。基地局からのデータ は非同期に受け取り。ある程度ならロストしても良かった。性能情報は FTP でとんできたり。基地局マスターは csvでばらまき、バッチ回収 Webアプリケーションエンジニア メインはRDB。 コロナで挑 戦したこと 家系ラーメンの内製化、 ハンドドリップ珈琲、筋トレしながらのミーティング
  3. 3. はじめに データ指向アプリケーションデザインの12章(最終章)の輪読会資料です。書籍の内 容に沿っていますが、例などは自分の実体験などにそってアレンジしている箇所が あります。書籍の内容そのままではありませんので、本資料を参考にしつつ自分で 最後は読み進めてみてください。
  4. 4. 12章 データシステムの将来 これまでは現在の姿についての説明してきた。 視点を将来に向け、あるべき姿について説明する。将来の話については、筆者の主観が入って いる点は注意が必要。 そもそもこの書籍の目標は、信頼性があり、スケーラブルで、メンテナンス性の高い アプリケー ションやシステムを作る方法を調べること。その1つ1つの要素を説明してきたので、 12章ではま とめて基盤としての未来を考える。 12.1. データのインテグレーション 12.2. データベースを解きほぐす 12.3. 正確性をもとめて 12.4. 正しいことを行う ←この節だけメンタリティの話
  5. 5. データのインテグレーション
  6. 6. 言いたいこと 前提として、データ利用される様々な環境のすべてに適した単一のソフトウェアは存 在しない。 ストレージエンジンの議論(3章)では、log-structuredストレージ・Bツリー・列指向ス トレージ、レプリケーションの議論(5章)では、シングルリーダー・マルチリーダー・ リーダーレスのアプローチがあった。その他にも、あらゆる問題で選択肢を提示して きた。(各論の詳細については書籍の 1−11章を参照) これらは、どれが良い悪いではなく、どれもメリットとデメリットがあった。つまり、組み 合わせ(インテグレーション)が必要ということ。どうやって組み合わせていけるかを 考えることが大事。
  7. 7. 導出データシステム 導出データシステム=「導出システム内のデータは、他のシステムの既存データを 何らかの方法で変換あるいは処理した結果です。導出データは失ったとしても、オリ ジナルのソースから再作成できます。」(p424) 任意の処理 id name describe price image 1 Product a Product aは〇〇 780 https://xxx 2 Product b Product bは〇〇 1,800 https://xxx 3 Product c Product cは〇〇 980 https://xxx は〇〇 導出データシステム。 失ってもいつでもオリジナル データから再作成できる
  8. 8. RDB(単一ソフトウェア)ですべてをまかなえる? 例えば、検索エンジンという文脈で言えば、 PostgreSQLには全文検索を提供するモジュール pg_bigm (ピージーバイグラム ) を備える。導出データシステムって本当に必要? 実現したいことは、pg_bigm は機能として充分?単一ソフトウェア( PostgreSQL)だけで、信頼性があり、 スケーラブルで、メンテナンス性の高いシステムは構築できる? 任意の処理 id name describe price image 1 Product a Product aは〇〇 780 https://xxx 2 Product b Product bは〇〇 1,800 https://xxx 3 Product c Product cは〇〇 980 https://xxx は〇〇 全文検索の機能もあ る。ElasticSearchで データを管理する必要 などない JSON型も習得した レプリケーションも できる
  9. 9. 導出データと分散トランザクション 役割に合わせて導出データシステムをつくる意味はわかってきた。ではどうやって導出データを作っていけ ばいいか?まずは分散トランザクションで考えてみる。 例として、ECサイトを開発運用しているとする。 ECサイトの商品管理を担当するチームと検索エンジンを 管理するチームがある。商品管理チームがあたらしい商品を登録することを想像する。 ・商品登録と同時に、検索エンジンに反映される(即時的な一貫性)点はよいが、それは必要? ・エラー時のロールバックは容易か? ・検索エンジンが障害だったときの業務はどうなるか? ・商品管理チームが業務スコープ外の検索エンジンのことを考えるべきか? アプリケーション (商品登録サービス) 商品データベース 検索エンジン 商品登録担当 ①商品登録操作 ②商品登録 ③検索エンジンへの商品登録
  10. 10. 非同期での導出データシステム 分散トランザクションの限界を知ると、非同期での導出データを作成する方法の重要性がわかる。例として CDC(Change Data Capture, 変更データキャプチャ )。詳しくは「11.2.2 変更データキャプチャ (p497)」を参 照。 イベントの順序を保ったまま、非同期に、 変更を導出データシステムへ反映できる。 記録システ ムDB ... X = A X = B 検索エンジン データウェアハウス データ変更ログ ログの適応 導出データシステム 変更データキャプチャ( 章)
  11. 11. 全順序の限界 小さなシステムであれば、全順序を保つイベントログを構築することができる。規模が大きくなり、複雑にな ると限界にぶつかる。 全順序を保つには、単一のリーダーノードがすべてのイベントが処理することで実現可能。たとえば、地理 的に分散したマルチマスターの RDBでは全順序は保証できなくなる。 記録システ ムDB ... X = A X = B 検索エンジン データウェアハウス 変更データキャプチャ( 章) データ変更ログ ログの適応 導出データシステム 記録システ ムDB マルチマスター レプリケーション 全順序の崩壊 レプリケーションについて は 章で解説
  12. 12. バッチ処理とストリーム処理 データ結合の目標は、データを適切な場所に適切なフォーマットで置くこと。そのた めには、入力データの取り込み、変換、結合、フィルタリング、集計、モデルのトレー ニング、評価、出力が必要で、バッチ処理・ストリーム処理はこれをやるもの。 バッチ処理とストリーム処理の結果は、どちらも導出データを作り出す。アプローチ は違えど同じことを目的としている。
  13. 13. バッチ処理はデータの「再処理」 バッチ処理は大量に蓄積された履歴データを「再処理」し、既存のデータから新たなビューを導 出できる(バッチ処理の詳細は10章)。既存データの再処理によって、導出データのメンテナンス 性があがる。再処理のため既存の導出データに影響を受けず実行可能。完全に異なるデータモ デルの導出データの作成も可能。ただし、量が膨大だと当然時間がかかる。リアルタイム性もな い。 例)1日1回最新データで分析用テーブルを作る。 商品データベース Amazon Redshift スキーマ v1 購入履歴データベース バッチ処理 データ分析 チーム BIツール クエリ発行、可視化 Amazon Redshift スキーマ v2 データ取得、結合、集 計などへて分析用 へ投入
  14. 14. ラムダアーキテクチャ 出典 http://www.intellilink.co.jp/article/column/bigdata-kk03.html 「サービスレイヤーとスピードレイヤーの双方に対して問合せをし、 その結果をマージしてユーザーに提供 するようなクエリ機構を構築する ことで、バッチ処理の細やかな集計結果も、スピードレイヤーの最新の集 計結果も、分析に反映させることができるものである。」 専用インターフェイスや Hiveとか 課題もたくさんある - バッチ処理とストリーム処理の両方で 同じロジックをメンテするのが大変。 - ストリームパイプラインとバッチパイプ ラインは別の出力を生成するので マージが必要。 - データの再処理は規模が大きくなる と負荷が大きい。 - インクリメンタルなバッチ処理にする と、はぐれイベントやバッチ間の境界 をまたぐウィンドウの処理といった時 間の問題
  15. 15. バッチ処理とストリーム処理の統合 最近の研究で、ラムダアーキテクチャの欠点もなくしながらも、その利点を享受できるようにも なってきた。バッチ演算とストリーム演算を同じシステム上で実装できるようになってきた。実現 するには、以下のような機能が必要。 - 履歴にあるイベントをリプレイし直近のイベントのストリームを処理するのと同じエンジンに 流す機能 - ストリームプロセッサのexactly-onceセマンティクス - 処理の時間ではなく、イベントの発生時刻によってウィンドウ処理を行うツール ※現状の製品ベースだとどこまで実装され ているのかわからなかったのでもししって いたら教えて下さい。
  16. 16. データベースを解きほぐす
  17. 17. 言いたいこと 出典 高い抽象度でみると、データベースも Hadoopもオペレーティングシステムも同じ機能を実行して いる。もちろん違いはあるが「情報管理」システムという意味では同じ。類似点と相違点を見てい くことには価値があり、これらを最善の部分を組み合わせることを目標に、調和を考える。 本章の中で「解体 (unbundling)」という言葉がよく利用されるが、意味としては、下記と捉えてお くといい。(別出典から) 「データベースは、ストレージ、インデックス、キャッシング、クエリ、トランザクションなど、いくつか の概念を一つの論理的な単位にまとめて構成されている。解体とは、これらのコンポーネントを 分解して、ターゲットシステムに共感できるような形で再構成すること。」
  18. 18. 巨大なデータベースと 考えられる CREATE INDEXは導出データシステムと同じ? CREATE INDEXは本質的には既存のデータセットを再処理し、既存のデータに対する新しい ビューとしてインデックスを導出する。組織全体にわたるデータフローは1つの巨大なデータベー スのようにみえてくる。 記録システ ムDB ... X = A X = B 検索エンジン (導出データシステム) 変更データキャプチャ データ変更ログ ログの適応 テーブル インデックス (導出データとみなせる) 導出データシステム 本質的に同じでは!?
  19. 19. 全てに関するメタデータベース すべてのユースケースに適する1つのデータベースは存在しないと いう前提に立つと、様々なストレージや処理のツールが1つのシス テムにまとめる道筋は2つある。 1. フェデレーテッドデータベース(読み取りの統合) 例としてPostgreSQLのforeign data wraper 2. 解体されたデータベース(書き込みの統合)★本書のターゲッ ト →書き込みを同期させるための方法に分散トランザクション があるが、前に見たようにあまり賢いアプローチではない。非 同期のイベントログを用いたアプローチを使っていきたい。
  20. 20. 解体されたデータベース (1) システムレベルの話で、耐障害性があがる。イベントログはメッセージをバッファリングできるため、他 のコンポーネントが一時的に障害が発生しても復旧後においつくことが可能。 (2) 人間レベルでは、業務の分離がしやすい。異なるチームで独立した作業がおこないやすい。下の例で 言えば記録システムを扱っているチームと検索エンジン、データウェアハウスを扱っているチームで独立性 がある。 記録システ ムDB ... X = A X = B 検索エンジン データウェアハウス 変更データキャプチャ データ変更ログ ログの適応 導出データシステム のイメージ: サイトの商品登録担当 と検索エンジンを作っている担当とで分 担など。(某 ショッピングの検索エンジ ンチーム友人の話より)
  21. 21. 解体されたデータベースと既存データベース 解体されたデータベースを未来の方向性と書いているが、それは既存のデータベースを置き換 えるものではない。 解体されたデータベースを構成するのに依然として必要であり、そして解体されたデータベース の目的は、特定のワークロードにおけるパフォーマンスで張り合うものではない。単一のソフト ウェアでは実現できない、幅広いワークロードにおいてパフォーマンスを発揮することが目的。 Unixのシェルに相当するような、ストレージや処理のシステムをシンプルかつ宣言的な方法で合 成できる高レベル言語が必要になると考えている。 たとえば、mysql | elasticsearch といったように。
  22. 22. データフロー中心のアプリケーション設計 スプレッドシートさえも、主要なプログラミング言語のほとんどよりはるかに進んだ データフロープログラミング機能をもっている。スプレッドシートでは、とある値に変化 があれば、敷の計算結果は自動的に再計算される。 まさに、これがデータシステムのレベルでほしいこと。データベースの中のレコード が変化したら、そのレコードに対するインデックスがあれば自動的に更新され、レ コードに依存するキャッシュされたビューや集計へ反映されたい。(当然、規模や難 易度の違いはあるのだけれど) テーブル テーブル 値更新 再計算されて更新
  23. 23. アプリケーションコードと状態の分離 あるデータセットが他のデータセットから導出される場合、なんらかの種類の変換関数を経由す る必要がある。セカンダリインデックスの生成のように標準的で型通りなればいいが、そうではな い場合、固有のコードを書く必要がある。固有コード部分をデータベースに実行させることも実装 されてきた。トリガーやストアドプロシージャ、ユーザー定義関数など。しかし、データベースに は、依存関係やパッケージ管理、バージョン管理、ローリングアップデート、進化性、モニタリン グ、メトリクス、ネットワークサービスの呼び出しとアプリケーション管理には不十分。 Mesos, YARN, Docker, Kubernetesなどでアプリケーションのオーケストレーションが容易に なった。永続データとロジックの独立性を高めることができるように。 テーブル ストアドプロシージャ テーブル こいつの管理、アップ デートなど。。。
  24. 24. 書き込みパスと読み込みパスの変化 アプリケーション サーバ 言語解析 検索インデックス 検索クエリの実行 アプリケーション サーバ 書き込みパス 読み込みパス マテリアライズ ドビュー キャッシュ ブラウザローカ ルストレージ 書き込みパス 読み込みパス など 導出された状態は、元になるデータを観察すること で更新可能。書き込みパスは時代やテクノロジーで 変わってきていて、ユーザデバイスまで伸びることも ある。オフラインで動作し続ける状態も実現できるよ うになってきている。
  25. 25. 正確性をもとめて
  26. 26. 言いたいこと ステートレスなアプリケーションであれば、何かがおかしくなってもあまり問題にならない。バグを 修正し、再起動すればいい。データベースのようなステートフルなシステムはそれほど単純では ない。われわれは、信頼性が高く、正確なアプリケーションを望んでいる。データフローアーキテ クチャの文脈の下で正確性について考えるいくるかの方法を提唱する。 ログベースのメッセージングサービスを活用し、いろんな技術的な制約を乗り越えて信頼性が高 く、正確なアプリケーションを構築する方法をさぐる。
  27. 27. データベースのエンドツーエンド論 1. 操作を厳密に一度だけ実行する (正確性を得るのに手間) メッセージングシステムのセマンティクスは、at-least-onceかat-most-onceが一般的。メッセージをロストするか、重複 して送られる可能性を考慮する。重複して送られても問題なくするためにはアプリケーション側で冪等な処理にする必 要がある。冪等な処理をするにはメタデータの管理など必要。 2. 重複の抑制(正確性なし) RDBのトランザクションでCOMMITしたが、そのレスポンスを受け取れなかった場合、アプリ側は再送して二重処理と なる。ネットワークを介す操作を冪等にするのに、トランザクション処理だけでは不十分。 3. 操作識別子(エンドツーエンド)★ リクエストのエンドツーエンドのフローを考慮する必要あり。クライアント側からデータベースまでの一貫したリクエストID をもつ必要がある。 アプリケーション Database ユーザ からユーザ へ送金 送金 入金 引き落とし はユニークキー エンドツーエンドで考える
  28. 28. 制約の強制 パーティショニングされたログを使うことで、アトミックなコミットなしに実現できる。前 のことを非同期かつスケーラブルな環境で行うことが可能。 メッセージング (リクエストIDの パーティション) ユーザ からユーザ へ送金 送金 メッセージング (ユーザAを含む パーティション) メッセージング (ユーザBを含む パーティション) Database ユーザごとの順序を保ったまま、 (最低一度は処理)でロスト なく処理を実行。 を持っている ので重複処理対策。 ログベースのメッセージブローカーの利点は、コンシューマが単一 パーティション内のメッセージをシーケンシャルに処理のため、順序 性を守りながら、効率良く処理可能(11章で解説) 因果律において一貫している
  29. 29. 適時性と整合性 「一貫性」という言葉の特性として2つ。ほとんどのアプリケーションでは「整合性」の ほうが重要視されている。 ● 適時性 ユーザーが最新の状態のシステムを観察できることを保証すること。 ● 整合性(★) 破損がないこと。データのロストがなく、矛盾がないこと。 適時性については、許容されることが多い。クレジットカードの明細に、すぐに取引 情報がでてこなくても違和感がない。場合によっては「謝罪」によって回避もできる。 注文したものの在庫が実はなかった。入荷までまつように謝罪するなどなど。ビジネ ス判断だが、可能なことも多い。
  30. 30. 正しいことを行う
  31. 31. 言いたいこと 今までのセクションとは異なって、一歩引いた視点からの意見。 データは抽象的なものとして扱ってしまうことも多いが、多くのデータは人の行動や関心、アイデ ンティティなど人に関すること。この種類のデータは人間性と尊敬をもって扱わなければならな い。ユーザもまた人間であり、人の尊厳は重要なこと。ソフトウェアエンジニアは技術だけに集中 するのではなく、それがもたらす結果を無視してはいけない。
  32. 32. 予測分析 予測分析はビッグデータ時代のブームのひとつ。もちろんいい面もおおいが、アルゴリズムによってはじき 出されえる人々がいる可能性があることを忘れてはいけない。 1. バイアスと差別 アルゴリズムは、バイアスを学習することもある。 それにどう対応するか決めているか? 2. 説明と説明責任 アルゴリズムがミスを犯した場合だれが責任をとるか?アルゴリズムがだした結果に対して説明が できるか?アルゴリズムを説明可能で透明性のあるものにする方法や、既存のバイアスの強化を避 ける方法、データに基づく意思決定が間違いを犯してしまった場合にそれを修復する方法は考えて いるか? 3. フィードバックループ アルゴリズムによる負のスパイラルが起きているか判断できる状態か?システム思考(事象ではなく パターンに着目する方法)で、システム全体について考えるようにする。
  33. 33. プライバシーと追跡 データの収集そのものに倫理的な問題があることもある。サービスの利用の中で、明示的に入 力したデータが保存されることは理解できるが、ユーザが行った行動が追跡され利用されていく ことを意識する必要がある。たとえば、サービスが広告から収入を得ている場合、一番の顧客は 広告主で、ユーザは広告主からお金をもらうためのメトリクスとなっていないか? 広告主 自社サービス ユーザ 一番の顧客 お金をもらうた めの存在 ・情報入力 ・さまざまなアクション DB 正しい情報を伝えている? 利用規約でもデータの活用 方法についてぼかしていな いか? 提供する情報を選択できるよ うにしては? 情報を追加で提供するとどん なメリットがあるか明示すると かは?
  34. 34. データ指向アプリケーションデザイン データシステムを理解するための要素技術の解説が満 載。基礎を抑えた、システムアーキテクチャ、技術選定が できるようになろう。 ● リレーショナルモデルとドキュメントモデル ● データベースを駆動するデータ構造(ハッシュイン デックスやSSTableとLSMツリー、Bツリー、列指向 ストレージ) ● データエンコードのフォーマット( JSON, XML, Protocol Buffers, Avroなど) ● レプリケーション(シングルリーダー、マルチリー ダー、リーダーレス方式) ● パーティショニング ● トランザクション ● 一貫性と合意 ● バッチ処理とストリーム処理 https://amzn.to/3sNOOcp

×