zono

データエンジニア。ビッグデータ基盤の開発やデータマネジメントを担当。 データエンジニア…

zono

データエンジニア。ビッグデータ基盤の開発やデータマネジメントを担当。 データエンジニアリング本を読むのが趣味。

  • データ志向アプリケーションデザインを活かすために

    データ処理システムの設計に携わるエンジニアや、データ処理システムに関する知識を深めたい人にとって必読の書籍です。

  • 実践的データ基盤への処方箋を現場で活かすために

    「実践的データ基盤への処方箋」というデータ基盤に関わる人必読の本を紹介します。データエンジニア、データサイエンティスト、データアナリストにオススメの内容になっています。

  • DMBOKを現場で活かすために

    「DMBOK」というデータマネジメントのバイブル（体系本）を紹介します。データエンジニアやPMの方にオススメの内容になっています。企業のデータを管理するためのノウハウが詰め込まれています。

  • 固定された記事

2024年版：データエンジニア向け推薦本リスト

世間ではデータエンジニアリングが流行しており、エンジニアからは人気が出て、企業からはその能力が求められています。 データエンジニアは、データの収集、蓄積、分析、活用に必要なデータ基盤を構築・運用する職種です。データエンジニアとして活躍するためには、非常に幅広い知識と能力が求められます。 データベース プログラミング システム開発 クラウドサービス データ分析 etc……. 私は多少データエンジニアとして経験を積んできており、業務を行う上で読んで良かったと心から思

zono

    • 分析基盤のテーブルと連携方式

      分析基盤においては様々な連携手法があります。 これは、データ量が多いか少ないか、データソースが最新か履歴か、によって変わってきます。 今回は、連携手法を紹介しながら、その連携に必要なテーブルの特徴について話したいと思います。 連携元と連携先のテーブル連携元のテーブルは、最新テーブルになっている場合も履歴テーブル（インサートオンリー）の場合もあります。これはアプリ側の仕様によって異なります。多くの場合は、UPDATEができて、データ量が少なくなる最新テーブルになります。 基

      zono

      • 分析基盤のためのテーブルとカラム

        データ分析基盤を構築する上で、テーブルとカラムの設計は非常に重要です。分析に必要なデータを効率的に取得・加工するために、適切なテーブル構成とカラム設計を行う必要があります。 マスタとトランザクションマスタテーブルとトランザクションテーブルは、データベース設計で重要かつ基本的な構成です。 下記で紹介するテーブルは全て履歴テーブルです。 マスタテーブル 基本的に静的なマスターデータを格納するテーブルのことです。 様々なトランザクションシステムから参照されるため、履歴管理が不

        zono

        • データマートのモデリングとパフォーマンスチューニング

          はじめにデータエンジニアリングが興隆してから数年が経ち、各企業がデータ基盤に注力し始めたり、知見が溜まり始めています。 そんな流れがある中、データマートの乱立やパフォーマンスで悩んでいる方が多いのではないでしょうか？ そこで、本記事では重要な分析基盤の1つであるデータマートに焦点を当てつつ、データ基盤のデータモデリングから構築、運用に至るまでの手法と考え方を解説していきます。 データマートの目的と要件の明確化データマートには様々な用途がありますが、いずれの場合も最初に重要

          zono
        • 固定された記事

        2024年版：データエンジニア向け推薦本リスト

        zono

        マガジン

        • データ志向アプリケーションデザインを活かすために
          12本
        • 実践的データ基盤への処方箋を現場で活かすために
          3本
        • DMBOKを現場で活かすために
          17本

        記事

          第12章 データシステムの将来

          前の章 前の章である第11章 ストリーム処理はこちらです。 データインテグレーションこの本の目標は、信頼性、拡張性、保守性の高いアプリケーションとシステムを作成することでした。（1章からのテーマ） 唯一の正しい解決策はありませんが、状況に応じて適切なさまざまなアプローチが存在します。ソフトウェア実装では通常、特定のアプローチを 1 つ選択する必要があります。 したがって、最適なソフトウェア ツールの選択も状況によって異なります。すべてのソフトウェアは、いわゆる「汎用」

          zono

          第12章 データシステムの将来

          zono

          第11章 ストリーム処理

          前の章 前の章である第10章 バッチ処理はこちらです。 ストリームとはストリームとは、時間の経過とともに段階的に利用可能になるデータを指します。したがって、データセットは決して終わることがなく、これまでに受信したデータを処理する必要があります。一方、バッチ処理では、データベースがいつ終了するかがわかり、その後に計算を開始できます。 ストリーミングでは、入力は、ある時点で起こった何かの詳細を含む不変オブジェクトであるイベントです。これは、テキスト文字列、JSON、またはバ

          zono

          第11章 ストリーム処理

          zono

          第10章 バッチ処理

          前の章 前の章である第9章 一貫性と合意の問題はこちらです。 3 つの異なるシステム結果整合性は、複数のノード間でデータをレプリケートする際に遅延が発生する可能性があっても、データは最終的にはすべてのノードに到達します。 ただし、これは弱い保証になります。レプリカがいつ収束されるかについては言及されておらず、単に収束します。 オンラインシステム サービスは、クライアントからのリクエストまたは指示が到着するのを待ちます。メッセージを受信すると、サービスはできるだけ早く

          zono

          第10章 バッチ処理

          zono

          第9章 一貫性と合意

          前の章 前の章である第8章 分散システムの問題はこちらです。 一貫性の保証結果整合性は、複数のノード間でデータをレプリケートする際に遅延が発生する可能性があっても、データは最終的にはすべてのノードに到達します。 ただし、これは弱い保証になります。レプリカがいつ収束されるかについては言及されておらず、単に収束します。 線形化可能性 線形化可能性とは Register (key/行) の読み書きにおける最新性を保証することです。 これは最新性の保証でもあり、読み取られ

          zono

          第9章 一貫性と合意

          zono

          第8章 分散システムの問題

          前の章 前の章である第7章 トランザクションはこちらです。 フォールトと部分障害分散システムは、システムが完全に動作しているか完全に壊れている単一ノード コンピューターとは異なり、分散システムでは部分的な障害が発生する可能性があるという点で単一ノード コンピューターとは異なります。 ハードウェアが正しく動作していれば、同じ処理は常に同じ結果をもたらします。これを決定的と呼びます。 部分的な障害への対処がより困難になるのは、部分的な障害が非決定的であるためです。うまくい

          zono

          第8章 分散システムの問題

          zono

          第7章 トランザクション

          要約 ACIDは、トランザクションの安全性を確保するための原則を指す頭字語で、原子性、一貫性、分離性、耐久性から構成されます。 原子性は、障害時にトランザクションを中止し、一貫性はデータベースが「良好な状態」を維持することを指します。分離性は、トランザクションの相互干渉を防ぎ、耐久性はデータの不滅性を保障します。 BASEはACIDを満たさないシステムを指し、基本的に利用可能、厳密ではない状態遷移、結果整合性を特徴とします。 3つのリード現象（ダーティリード、ノンリピータ

          zono

          第7章 トランザクション

          zono

          第6章 パーティショニング

          要約 この章では、大きなデータセットをより小さなサブセットに分割するパーティショニングを扱います。データが大量にあり、それを1台のマシンに保存して処理することがもはや不可能な場合に必要です。 パーティショニングの目的は、データとクエリの負荷を複数のマシンに均等に分散し、ホットスポット（負荷が不均衡に高いノード）を避けることです。そのためには、データに適したパーティショニング・スキームを選択し、クラスタにノードを追加または削除したときにパーティションのバランスを調整する必要

          zono

          第6章 パーティショニング

          zono

          第5章 レプリケーション

          要約 レプリケーションは、ネットワークで接続された複数のマシンに同じデータを保持する方法で、障害への耐性や処理能力向上に活用されます。 シングルリーダー、マルチリーダー、リーダーレスの3つのアプローチがあります。 また、同期と非同期のレプリケーションも存在し、同期は一貫性を保障しますが、非同期は処理速度向上をもたらします。問題としては、レプリケーションラグや書き込みの衝突が挙げられ、ケースバイケースで最適な構成を選択する必要があります。 シングルリーダーは広く使われ、マル

          zono

          第5章 レプリケーション

          zono

          第4章 エンコーディングと進化

          要約 大規模システムのデプロイにおいて進化性を高める手法として、スムーズな動作を確認しながら全体をアップグレードするローリングアップグレードが挙げられます。ダウンタイムがなく、リリースが容易になり進化性が向上します。 データ変更に伴う互換性管理には前方互換性と後方互換性が存在し、Apache Thrift、Protocol Buffers、Apache Avroなどもあり、それぞれフィールドのタグが存在したり、初期値を設定する必要があります。 前の章 前の章である第3章

          zono

          第4章 エンコーディングと進化

          zono

          第3章 ストレージと抽出

          要約 OLTPはトランザクション処理に、OLAPは分析処理に特化しています。 インデックスにはハッシュ、SSTable・LSMツリー、Bツリーなどがあり、読み取り速度と書き込み速度のトレードオフがあります。 データウェアハウスではインデックスはあまり機能しません。ストレージでは行ではなく、列指向が使われており効率化を図っています。 前の章 前の章である第2章 データモデルとクエリ言語はこちらです。 OLTPとOLAP私たちが普段使っているデータベースは2つのやらなけれ

          zono

          第3章 ストレージと抽出

          zono

          第2章 データモデルとクエリ言語

          要約 データモデルには様々な種類があり、それぞれが異なる利用方法を提供します。 リレーショナルモデルはSQLデータモデルで知られ、30年以上の歴史があります。ドキュメントモデルはJSON形式で階層構造を持ち、人間には理解しやすいが多対多の関係表現が難しいとされます。グラフモデルは多対多の関係が複雑な場合に有効で、ソーシャルネットワークや不正検出などに利用されます。NoSQLはリレーショナルデータベースの限界に挑戦し、大規模データセットや高いスループットが求められる状況での利

          zono

          第2章 データモデルとクエリ言語

          zono

          第1章 信頼性、スケーラビリティ、メンテナンス性に優れたアプリケーション

          要約 信頼性、スケーラビリティ、メンテナンス性はソフトウェアシステムの重要な課題です。 信頼性はフォールトに対処し、障害に強いシステムを構築すること。スケーラビリティはシステムが負荷に対応できる能力であり、オートスケーリングだけでなく、設計変更も含む。メンテナンス性は初期開発だけでなく、運用中のメンテナンスコストも考慮し、単純性、進化性に注力する。 以上、この3つが重要になります。 データシステムに関する考察 最近はデータベースとメッセージキュー等のツールがしばらくの間

          zono

          第1章 信頼性、スケーラビリティ、メンテナンス性に優れたアプリケーション

          zono