アプリケーションプライバシーポリシー
個人情報保護方針(Privacy Policy)
私は、アプリを無料アプリとして公開しました。本サービスは、私が無償で提供するものであり、そのまま利用することを目的としています。
本ページは、本サービスを利用される方に、個人情報の収集、利用、開示に関する方針をお伝えするためのものです。
あなたが私のサービスを利用することを選択した場合、あなたはこのポリシーに関連する情報の収集と使用に同意することになります。私が収集した個人情報は、本サービスの提供および改善のために使用されます。私は、このプライバシーポリシーに記載されている場合を除き、あなたの情報を使用したり、誰かと共有することはありません。
本プライバシーポリシーで使用される用語は、本プライバシーポリシーで特に定義されない限り、本アプリでアクセスできる当社の利用規約と同じ意味を持つものとします。
情報の収集と使用について
より良い体験のために、私たちのサービスを使用している間、私はあなたに特定の個人を特定できる情報を提供することを要求することがあります。私が要求する情報は、お客様のデバイスに保持され、私が何らかの方法で収集することはありません。
本アプリは、お客様を特定するために使用される情報を収集する可能性のある第三者のサービスを使用しています。
アプリが使用する第三者サービスプロバイダのプライバシーポリシーへのリンク
Google Play サービス
ログデータ
私は、お客様が私のサービスを利用するたびに、アプリにエラーが発生した場合、ログデータと呼ばれるお客様の携帯電話上のデータおよび情報(サードパーティ製品を通じて)を収集することをお知らせしたいと思います。このログデータには、お客様の端末のインターネットプロトコル(以下「IP」)アドレス、端末名、オペレーティングシステムのバージョン、私のサービスを利用する際のアプリの設定、お客様がサービスを利用した日時、その他の統計などの情報が含まれることがあります。
クッキー(Cookies)について
Cookieとは、一般的に匿名のユニークな識別子として使用される、少量のデータを含むファイルです。これらは、お客様が訪問したウェブサイトからお客様のブラウザに送信され、お客様のデバイスの内部メモリに保存されます。
本サービスでは、この「Cookie」を明示的に使用することはありません。ただし、本アプリでは、情報の収集やサービスの向上のために「Cookie」を使用するサードパーティのコードやライブラリを使用することがあります。お客様は、これらのクッキーを受け入れるか拒否するかを選択することができ、クッキーがお客様のデバイスに送信されていることを知ることができます。お客様が当社のクッキーを拒否することを選択した場合、本サービスの一部を利用できない場合があります。
サービス提供者について
私は、以下の理由により、第三者の企業や個人を雇用することがあります。
- 本サービスを円滑に進めるため。
- 当社を代表して本サービスを提供するため
- 本サービスに関連するサービスを提供するため。
- 本サービスがどのように利用されているかを分析するために、当社を支援するため。
本サービスの利用者に、これらの第三者が利用者の個人情報にアクセスできることをお知らせしたいと思います。その理由は、当社に代わって彼らに割り当てられたタスクを実行するためです。ただし、これらの第三者は、他の目的のために情報を開示または使用しないよう義務付けられています。
セキュリティについて
私は、お客様の個人情報を提供することへの信頼を大切にし、そのために商業的に許容される手段を用いて個人情報を保護するよう努力しています。しかし、インターネット上の送信方法、電子的な保存方法は、100%安全で信頼できるものではなく、その絶対的な安全性を保証するものではないことをご承知おきください。
他のサイトへのリンクについて
本サービスには、他のサイトへのリンクが含まれている場合があります。お客様が第三者のリンクをクリックすると、そのサイトへ移動します。なお、これらの外部サイトは、私によって運営されているものではありません。従って、これらのウェブサイトのプライバシーポリシーを確認することを強くお勧めします。私は、第三者のサイトやサービスのコンテンツ、プライバシーポリシー、または慣行を管理することはできませんし、責任を負いません。
子どものプライバシーについて
これらのサービスは、13歳未満の人を対象としていません。 私は、13歳未満の子供から個人を特定できる情報を意図的に収集することはありません。万が一、13歳未満の子どもが私に個人情報を提供したことを発見した場合、私は直ちにこれを当社のサーバーから削除します。保護者の方で、お子さまが当社に個人情報を提供していることに気づかれた場合は、必要な措置を講じることができますので、ご連絡ください。
本プライバシーポリシーの変更
私は、当社のプライバシーポリシーを随時更新することがあります。従って、お客様はこのページを定期的にご覧になり、変更を確認されることをお勧めします。私は、このページに新しいプライバシーポリシーを掲載することにより、変更を通知します。
このポリシーは、2023-03-11から有効です。
お問い合わせはこちら
私のプライバシーポリシーについてご質問やご意見がありましたら、遠慮なく devlop.sugie@gmail.com までご連絡ください。
スライド作りの流れ
1. 下準備
- 目的を決める
- 相手が何を新しく知るか(何が既知か)&プレゼン後どうしてほしいかを決める
- 情報収集する
2. 調査詳細(具体的な内容、別ファイル推奨、同じローカルに保存しておくのが推奨)
- [調査結果ファイル]
3. スライドの流れの型
- 現状(背景、現状の分析)⇒ 課題 ⇒ アクション(解決策、具体的な実行策)
- 背景 ⇒ 結論 ⇒ 理由1 ⇒ 理由2 ⇒ 理由3・・・
- 製品の特徴 ⇒ 製品の利点 ⇒ 顧客にとってのメリット ⇒ その証拠
4. スライド作成
- メッセージを決める(MECEの意識は不要)
- メッセージを伝えるためのストーリー構成を考える(このmdを埋める)
- ページ構成を考える(何ページか、ここでは何を言いたいのか、テキストベース)
- パワポベースでタイトルと、このスライドで伝えたいことを箇条書きで書く(テンプレがあるので、それを使用すること)
- 紙で各ページの内容の構成をおおよそ書く
- グレーでスライドを作る
- 色をつけてスライドを作る
5. 考え方
- 分析内容ではなく結果の解釈を(ポジションをとる)
- 相手が既知か、直観的に納得する内容かで4象限にわける
- 出典は大事、スライドの信用に関わる
- 目次スライドは度々登場させて現在地を分かりやすくする
- みる人の視線の流れを意識する
6. スライド作成のテクニック
6.1. 文字編
- 強調したい文字:20, 普通の文字16, 補足12
- 行間、文字間は1.2くらい
- 重要度ごとの文字の大きさは1.5倍ずつがいい
- 和文フォントにはメイリオ、英語の文章には欧文フォント(segoe UI)
- メッセージは2行以内、体言止め、言い切り
- 縦棒や縦長四角形をタイトルなどの強調に使う、下線を使った強調はあんまり強調されない
- 主語、述語を対応させる(1文1義)、ダメなら2行に分ける
- 避けたい言葉「明確化する、徹底する、極力、フォローする、速やかに、努力する、なるべく、調整する」
- 数字は大きく、単位は小さく
6.2. グラフやチャート
- 強調は線を濃くするかフェードをかける
- 円グラフは1つの値(25.50.75%)に着目したいときのみ用いる
- 矢印は始点、終点を明確にしてその直線上にあるもので勘違いさせない
- 縦軸、横軸を明確にする
- 目盛りはどれくらい必要か決める
- 流れを説明する場合横は大まかな流れ、縦は細かい内容を説明しやすい
6.3. ページ構成について
- 人間の視線は左上から右下へ(右上、左下は注意が多少薄い)のでその順番に重要情報を配置
- 写真やグラフ → 文字の順に見やすい
- 箇条書きを多用しない、特にストーリー説明に箇条書きは厳禁
- 配置を決める四つの基本条件を意識
- 位置を揃える
- グルーピング(この画像グループはこっち)
- 余白を作る、見た目がすっきり
- 関係性を明確に、縦配置は順序関係、横配置は並列・比較
- 図形や文字はとにかく揃える、ctrl + shiftで並行にずらしながら複製できる
- 見出しは原則一つ
- 枠線のエッジは太くしない、なくてもいいくらい
- 注釈には、長方形の吹き出しを使うこと
- ユーザーの声は角丸吹き出しを使うこと
- フローチャートを使って、流れをビジュアル化、フローチャートの強調したい部分のみアクセントカラーで示すとか
- グラフを使うときには、吹き出しなどで、結局何が言いたいのかを見える化
6.4. 色使いについて
- 基本となる色を決める
- ベースカラー:背景白、文字黒
- メインカラー:見出し、ボックス、強調したい箇所で使う、青みがかったコーポレートカラー [30,152,185] 1E98B9
- アクセントカラー:特に注目を集めたいときに使う色、赤みがかった色 現在位置を示すのにも重要(フローチャート、目次、円グラフ、表、注目位置など) [252,233,159] FCE99F
- スライド資料は少しくすませるのもあり、文字をグレーにして、背景も少しグレーに(場合による)
6.5. デフォルトのスライドからの変更点
SEの基本
調査日時
20220710
調査の趣旨・目的
- SE一年目として必要な知識をつけるため
- 一般的なシステム開発手法の力を身につけるため
- 開発における用語をより理解できるようになり、会議に参加するため
参考URL
調査結果概要(要約)
- 読んでみたが、自分が求めるレベルより数段高いものだった。
- 2年目になったときに再トライしたい
調査詳細(具体的な内容)
背景
- Society5.0 について
- サイバー空間とフィジカル空間を高度に融合させたシステムにより、経済発展と社会的課題の解決を両立する人間中心の社会
社会の状況 | 意味 | --- |
---|---|---|
Society1.0 | 狩猟社会 | --- |
Society2.0 | 農耕社会 | --- |
Society3.0 | 工業社会 | --- |
Society4.0 | 情報化社会 | --- |
Society5.0 | 新たな社会 | --- |
所感
不明単語
単語 | 意味 | 備考 |
---|---|---|
Society5.0 | 新たな世界 | --- |
GHG | 温室効果ガス | Green House Gas |
CPS | 現実世界の情報をサイバー空間へ、サイバー空間で処理、現実空間へFBすること | Cyber Physical System |
IPA/SEC | 情報処理推進機構 | --- |
DevOps | 開発と運用担当者が協調して開発や運用し、システム価値を継続的に向上させる方法論 | 開発Development+運用Operation |
SAC | ||
--- | ||
--- | --- | --- |
簿記3級 2日目
1. 調査日時
20220710
2. 調査の趣旨・目的
- 簿記3級を合格するため
3. 参考URL
4. 調査結果概要(要約)
5. 調査詳細(具体的な内容)
5.1. 現金について
5.1.1. 現金ってどこまで?
- 簿記での現金は、以下を指す
- リアルの現金(硬貨、紙幣)
- 通貨代用証券
- すぐ銀行などで、換金できるもの
- 配当金領収書
- 株式会社の株を持っているときに配られる配当金
- 郵便為替証書
- 現金を誰かに郵送するときに使えるもの
- もちろん現金書留で送る方法もあるが、小切手のような形で送る方式もある
5.1.2. 現金の過不足
- 実際の残高が、足りていないかチェックを行う
もし、一致していなかった場合はどうしたらよいのか
- 実際残高 < 帳簿上の残高
- 帳簿上の残高を300円減らす
- 調整のために、現金化不足という項目を使う
例:帳簿上の現金残高が11910円であった。ただし、現金をカウントした結果、11610円であった。
- (借)現金化不足300 (貸)現金300
- 切手代300円の記帳を忘れていたことが判明した
- (借)通信費300 (貸)現金過不足300
5.1.3. 小口現金
- ちょっとしたことで、毎回仕入れをするのは大変
- 例:ガス料金の集金の方が来て、旅費のまとめての支払いとか
- インプレストシステム
- 営業事務所、各部署などに、まとまったお金(小口現金)を渡しておく
- 用度係が日々の支払い
- 1週間に一回、何に使ったかを定期的に経理部の出納係へ報告
- 経理部がまとめて仕分け
インプレストシステムの例題 1. 出納係は用度係に10万円渡した (借)小口現金10万円 (貸)現金10万円 2. 用度係は日々の支払いを行う 3. 金曜の夕方、用度係は出納係に1週間の支払いの領収書を提出、(ガス代3万円、出張費4万円) 4. 出納係は仕分けを行う (借)水道光熱費3万円 (貸)小口現金7万円 (借)旅費交通費4万円 5. 減った小口現金を補充 (借)小口現金 (貸)現金7万
簿記3級勉強 1日目
1. 調査日時
20220710
2. 調査の趣旨・目的
- 簿記に関しての基本知識をつける
3. 参考URL
4. 調査結果概要(要約)
5. 調査詳細(具体的な内容)
5.1. 簿記会計の全体像
5.1.1. 会計とは
- 企業の活動(仕入れ、販売、生産)を帳簿に付けること(簿記)
- 帳簿を世間(銀行、税務署、株主)に公開すること
- 企業内での管理のために用いられる数値データを計算すること
企業が帳簿をつけるのは義務なので、共通の公開ルールが必要 企業の帳簿の記載方法についての学問が簿記
5.1.2. 企業の帳簿と家計簿の違い
企業の帳簿
日付 | 勘定科目 | 金額 | 勘定科目 | 金額 |
---|---|---|---|---|
1/20 | 普通預金 | 200,000 | 売上高 | 200000 |
1/22 | 清掃費 | 3000 | 普通預金 | 3000 |
1/22 | 食料費 | 4500 | 普通預金 | 4500 |
1/28 | 諸口 | 30000 | 普通預金 | 30000 |
1/30 | 支払い家賃 | 60000 | 普通預金 | 60000 |
- 複式簿記
- 借方
- 入金は借方
- かり(「り」が左に外れているので、表の左)
- 貸方
- 出金は貸方
- かし(「し」が右に外れているので、表の右)
- 借方
- 勘定科目
- お金、建物、普通預金など...
簿記を勉強することは、複式簿記にどのように記帳すればよいか勉強すること
5つの概念
- 資産
- 資産=負債+純資産
- 負債
- 純資産
- 費用
- 収益
- 資産
三分法
三分法とは - 商品の売買をシンプルに書くことができる - 3つの勘定科目で書くことができる - 仕入れ(費用) - 売り上げ(収益) - 繰越商品(資産) - ただし、ぱっと見で利益がわかりにくいので、後でまとめて利益を計算する。
以下の問題の仕分けを行え 「商品1個を現金80円で購入した、そして上記商品を100円で現金販売した」
- 分記法
- (借)商品80 (貸)現金80
- (借)現金100(貸)商品80
- (貸)商品売買益 20
- 三分法
- (借)仕入れ80 (貸)現金80
- (借)現金100 (貸)売り上げ100
5.2. 決算について
決算とは - 期中(日本では4/1~3/31)の仕分け、帳簿を集計して、表を作成すること - 簿記:伝票を帳簿に記載すること - 決算:帳簿を集計し、財務諸表(賃借対照表、損益計算書)を作成
5.2.1. 貸借貸借票(バランスシート,B/S)
- 資産、負債、純資産から作成
- 資産 = 負債 + 純資産
- ある時点の財政状態がわかる、つまりSTOCKの情報
5.2.2. 損益計算書(Profit and Loss statement P/L)
- 費用、収益から作成
- 当期純利益 = 収益 - 費用 -ある期間の経営成績がわかる、つまりFLOWの情報
5.2.3. 決算についてのあれこれ
- 期中仕分け
- 期中で帳簿を作成すること
- 決算整理仕分け
- 決算日でのみ行う、整理仕分け
- 三分法の利益をまとめて出すとか
- 財務諸表の提出は上場企業なら6月
6. 例題
【練習問題】(商品についてはすべて三分法で仕訳してください) Q1: 1個100円の商品を掛けで100個買った。仕訳は?
A1: 仕入10,000 / 買掛金10,000
Q2: 上記商品のうち10個を、1個200円で掛け販売した。仕訳は?
A2: 売掛金2,000 / 売上2,000
Q3: 事務所での作業用にパソコンを1台(30万円)購入した。代金は掛けとした。仕訳は?
A3: 備品300,000 / 未払金300,000 事務所作業用PCなので、つまり商品ではないので、貸方は「未払金」です。商品として仕入れたのであれば「買掛金」です。
Q4: 500万円の建物と300万円の土地を購入し、普通預金から振り込んだ。仕訳は?
A4: 建物5,000,000 / 普通預金8,000,000 土地3,000,000
Q5: 決算で作成される財務諸表のうち、代表的なもの2つの名称は?
A5: 貸借対照表(Balance Sheet。略してB/S) 損益計算書(Profit and Loss statement。略してP/L)
Q6: 以下のカッコに入る言葉は? B/Sはある時点の(1)を表し、P/Lはある期間の(2)を表す。
A6: (1)財政状態 (2)経営成績
Q7: 次の中から正しい語句の組み合わせを選びなさい。 ア:賃借対照表、損益計算書 イ:貸借対照表、損得計算書 ウ:貸借対称表、損益計算書 エ:貸借対照表、損益計算書 オ:貸借対照表、損得計算書
A7: エ この間違い探し、ナニゲに難しくないですか?「賃借対照表」「貸借対称表」「損得計算書」という間違いは、『簿記初学者あるある』。キヲツケマショー!
Q8: 500円の商品を掛けで仕入れた。仕訳は?
A8: 仕入500 / 買掛金500 費用の発生と負債の増加(発生)です。
Q9: 上記Q8で仕入れた商品を700円で掛け販売した。仕訳は?
A9: 売掛金700 / 売上700 資産の増加と収益の増加(発生)です。
Q10: Q8の買掛金500円を現金で支払った。仕訳は?
A10: 買掛金500 / 現金500 負債の減少と資産の減少です。
Q11: Q9の売掛金700円について、顧客から普通預金口座に振り込まれた。仕訳は?
A11: 普通預金700 / 売掛金700 資産の増加と資産の減少です。
Q12: 従業員に給料30万円を普通預金口座から支払った。仕訳は?
A12: 給料300,000 / 普通預金300,000 費用の発生と資産の減少です。
Q13: 本社経理部で使用するために、パソコンショップから20万円のパソコンを掛けで購入した。仕訳は?
A13: 備品200,000 / 未払金200,000
Q14: 顧客に販売するために、パソコン卸売業者から、1台20万円のパソコンを10台掛けで購入した。仕訳は?
A14: 仕入2,000,000 / 買掛金2,000,000 費用の発生と負債の増加(発生)です。 Q13とQ14の違いに注意!です。 同じ「パソコン」でも、備品として購入したのか商品として購入したのかで仕訳が異なるわけです。
Q15: 銀行に行って、現金5,000円を普通預金口座に預け入れた。仕訳は?
A15: 普通預金5,000 / 現金5,000
Q16: 銀行と20万円の借金の契約をし、普通預金口座に振り込まれた。仕訳は?
A16: 普通預金200,000 / 借入金200,000 資産の増加と負債の増加(発生)です。
Q17: 売掛金3万円の代金として、2万円を現金で受け取り、残額は普通預金口座に振り込まれた。仕訳は?
A17: 現金 20,000 / 売掛金30,000 普通預金10,000 片側に複数の勘定科目がありますが、とくに記載順序のルールはありません。どちらを上に書いてもOKです。
Q18: Aさんへの未払金1,000円を支払うために、B銀行C支店に行って、AさんのD銀行普通預金口座へ現金で振り込んだ。仕訳は?
A18: 未払金1,000 / 現金1,000 必要な情報だけに絞り込んで考えてみてください(笑)
7. 所感
8. 不明単語
単語 | 意味 | 備考 |
---|---|---|
単語1 | --- | --- |
--- | --- | --- |
--- | --- | --- |
--- | --- | --- |
--- | --- | --- |
--- | --- | --- |
--- | --- | --- |
SQLの勉強 1日目
1. 調査日時
20220710
2. 調査の趣旨・目的
3. 参考URL
4. 調査結果概要(要約)
5. 調査詳細(具体的な内容)
5.1. SQLとは
5.1.1. SQL
- DBMSのデータ操作を行うための言語がSQL
5.1.2. DBMS
- DBを管理するためのシステム
- データの一貫性を保ちつつ、データを操作する機能
- DBMSに必要な機能5つ
- データ操作機能 データの構造や型の定義、データの更新、問い合わせなど
- 同時実行制御 複数のユーザーが同じデータベースを使用できるようにする機能 データ更新時には、更新が完了するまで参照させないようにする、排他制御を行う
- トランザクション管理 ユーザーから見た、ひとまとまりの処理をトランザクション トランザクション内の処理は「すべて成功」or 「全て失敗」 コミット:全て成功、結果をDBに反映 ロールバック:全て失敗、トランザクション開始前の状態に戻す
- 機密保護 ユーザーの認証、アクセス制御、暗号化
- 障害回復
データの回復など
データの更新記録(ログ)から回復することも
5.1.3. RDB (Relational Data-base)
- データを常に表の形(テーブル)で表す
- DBMSに対して、欲しいデータを要求することをクエリという。
- テーブルのルールとして、制約を設定することができる
- 一意性制約 あるテーブルのあるデータは重複を許さない(生徒IDなど)
- 参照制約、参照生合成制約、外部キー制約
テーブルAがテーブルBを参照する場合、テーブルAのデータはテーブルBに登録されていなければならない
FOREIGN KEY (student_id) REFERENCES students (student_id)
で設定
5.1.4. 三層スキーマ
5.2. SQLのあれこれ
- SQLの記述ルール
- 文末にはセミコロン
- テーブル名や列名には、原則半角数字と_
- 文字列や日付は「`」で囲む
- コメントは--の後ろか、/ /で
- SELECT
- データの問い合わせに使う
- SELECT, FROM, WHEREで同時に使うことが多い
SELECT student_id student_name FROM students WHERE branch='新宿';
- テーブルの作成
- CHAR(5)
- データの型を決める、今回は5桁の文字列
- 主キーは商品コード
- 商品名は255桁の、可変長の文字列
- 在庫数のデフォルトは0
- 登録日時のデフォルトは、今の時間(INSERTが実行された時間)
CREATE TABLE 商品マスター( 商品コード CHAR(5) PRIMARY KEY, 商品名 VARCHAR(255), 在庫数 INTEGER DEFAULT 0, 登録日時 TIMESTAMP DEFAULT CURRENT_TIMESTAMP );
- CHAR(5)
SQLで文字以外を格納する
型 保存したいデータ BLOB 画像 ARRAY 画像 JSON json XML xml -
- 同じ性質を持つ値の集合のこと
- 指名という列のドメインは人の名前の集合
- NULL
- 値のわからないデータであるときに保存するデータ
- ただし、NULLがある時点で計算も比較もできなくなってしまう
- NULLを許さない場合はテーブルの作成時に、
NOT NULL
で指定できる
- 主キー
- データを識別するのにメインで使用する列のこと
- 候補キーのうちの一つ
- IDや顧客番号などがあれば、大体それが主キー
- 主キーの特性(デフォルト)
- NULLが禁止
- 重複不可
- 複合キー
- 複数の列を組み合わせてキーにすること
- 例:校舎ごとに生徒番号が1~Nまでついている
- 複合キー:「校舎コード+生徒番号」
- ちなみに、もちろん全校舎で共通の番号にすれば、複合キーにする必要がないよね
- 参照制約 (外部キー)
- coursesテーブルのstudent_idは、studentsテーブルのstudent_idにないとダメ
CREATE TABLE courses ( student_id CHAR(5) NOT NULL, course VARCHAR(255) NOT NULL, PRIMARY KEY (student_id, course), FOREIGN KEY (student_id) REFERENCES students (student_id), FOREIGN KEY (course) REFERENCES course_master(course) );
- SQLのキーワード
キーワード | 操作内容 | 備考 |
---|---|---|
CREATE TABLE | テーブルを作成 | --- |
DROP TABLE | テーブルを削除 | --- |
PRIMARY KEY | 主キーの設定 | --- |
FOREIGN KEY | 外部キーの設定 | --- |
INSERT INTO | データの追加 | --- |
REFERENCES | 参照制約 | --- |
UPDATE | データの更新 | --- |
WHERE | 対象の指定 WHEREしないと全部指定 |
--- |
DELETE | データの削除 | --- |
ON DELETE RESTRICT | テーブルの参照先に、データがあると削除できない | --- |
ON DELETE CASCADE | テーブルの参照先に、データがあると、両方のテーブルで削除 | --- |
SELECT | データの問い合わせ | --- |
FROM | テーブルの指定 | --- |
ORDER BY | データの並べ替え ASCで昇順、DESCで降順 | --- |
COUNT() | データの件数の調査 | --- |
GROUP BY | グループの単位を決める場合、例えば出身が同じ人ごとにとか | --- |
AS | 違う列名を付けて保存する | --- |
JOIN | テーブルを結合 | --- |
CREATE VIEW | 実際のテーブルとは別の、一時的に使うためのテーブル | --- |
DROP VIEW | データは一時的な変数のようなもののため、削除しても影響なし | --- |
CHECK | 保存できる値を限定できる 例:テストなら0点以上100点以下 | --- |
6. 不明単語
単語 | 意味 | 備考 |
---|---|---|
キーワード | SELECTとかFROMとか、SQL文を構成するための単語 | --- |
予約語 | DBMSではキーワードを予約語とも | --- |
主キー、プライマリキー | テーブル内でデータを特定するのに用いるデータ(IDなど) | --- |
宣言 | student_idは主キーである、と定義すること | --- |
外部キー | テーブルAとテーブルBを関連づけるデータ | --- |
アトミック | これ以上分割できないデータ | --- |
キー、識別子 | データを識別するのに使える項目 | --- |
候補キー | キーにできる列、候補キーの中でメインで使うものは主キー | --- |
ラムダアーキテクチャ
1. 調査の趣旨・目的
ビッグデータ処理に用いられている、ラムダアーキテクチャについて理解する
- バッチレイヤ
- スピードレイヤ
- サービスレイヤ
2. 調査方法
参考ページ
- 拡張性と保守性を備える設計 ラムダアーキテクチャーを理解
- 5分ちょいでわかった気になるラムダアーキテクチャ
3. 調査結果概要(要約)
- ラムダアーキテクチャとは、三層構造を用いることで、ビッグデータを処理する設計概念
- リアルタイム&低精度のスピードレイヤと、バッチ処理&高精度のバッチレイヤから、クエリに応じて適切なデータパスで処理を行う
4. 調査詳細(具体的な内容)
4.1. ラムダアーキテクチャとは
Apacheの作者が提唱した、三層構造でデータ基盤の拡張性や、保守性を実現する設計概念 ストリーミングデータとバッチ処理の定期実行で得られる集計結果を組み合わせて分析できる ビッグデータの処理システムの設計指針
4.2. 三層構造とは
- バッチレイヤ(Cold path)
- スピードレイヤ(Hot path)
- リアルタイムで送られてくるストリーミングデータを一時的に保持、リアルタイム処理
- 精度と引き換えに、待機時間が短くなるように設計
- ストリーミングデータからリアルタイムビューを生成
- サービスレイヤ
4.3. 登場の背景
- 従来の状況
- 個別の課題を対処療法的に解決する
- コストもかかるし、プロジェクトごとに同じ仕事を繰り返し行う
- ラムダアーキテクチャ
- 課題を整理、一般化し、それらを包括的に解決
- 枠組みに昇華
4.4. 原理
- 全ての処理はデータの集合に対するクエリ
- クエリはデータに対する関数
4.5. ラムダアーキテクチャのメリット
- 計算フローを2層に分けることで、下記のトレードオフ回避
- 正確性 と レイテンシー
- クエリの自由度 と 計算量
- 永続性をマスタデータに飲み求めることで、堅牢性とスケーラビリティを両立
- 冗長化が容易
- DBサーバー管理が不要
5. 所感
やっと言いたいことがわかってスッキリした リアルタイム&精度落ちる、バッチ処理&高精度は、レイヤ型ディスプレイの考えとかに似ている(NTFとCNN) 最初は何を言っているかわからなかったが、複数サイトで包括的に見ることって大事
6. 不明単語
単語 | 意味 | 備考 |
---|---|---|
生データ | バッチレイヤに格納されているデータ、前のデータが上書きされることはないため、データはどんどん追加、精度は向上する | --- |
バッチ処理 | 大量の生データをまとめて一括で処理すること | --- |
BIツール | 企業の持つデータを分析、可視化を行うツール | Business Intelligence tool |
ストリーミングデータ | 無制限に発生する、大量のリアルタイムデータ | --- |
アドホック | その場の端末だけでグループを形成するモードをアドホックモード | その場だけ |
マスタデータ | 永続性を必要とする唯一のデータストア | --- |
バッチビュー | バッチレイヤから生成されたデータ | --- |