zono

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

zono

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

  • データモデリング・アーキテクチャまとめ

    データモデリングやデータアーキテクチャに関する記事のまとめです。

  • データ処理技術まとめ

    分析基盤に関わるデータ処理技術をまとめるマガジン。

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

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

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

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

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

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

  • 固定された記事

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

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

zono

    • データ修正の注意点

      はじめに データエンジニアにとって、データの修正は避けて通れない課題です。特に、顧客に直接影響を与えるデータにおいては、データの整合性と正確性が極めて重要です。データベース、データウェアハウス（DWH）、データマートに保存される情報が最新かつ正確であることが求められます。 本記事では、データの修正を行う過程や修正プロセスにおけるデータ管理の重要性、その手法について紹介します。 1. 修正前後のデータの比較画像に示されたローン契約データの修正前後の比較を基に、データソース

      zono

      • ストリーム処理とバッチ処理の比較と運用における注意点

        1. ストリーム処理とバッチ処理の基本概念1.1 バッチ処理とは バッチ処理は、一定期間に蓄積されたデータを一括で処理する方式です。典型的には、1日、1時間、またはそれ以上のスパンでデータを集め、その後一度に処理を行います。 バッチ処理のメリットは、データを一気に処理するためスケーラビリティが高く、リソースの使用効率も比較的高いことです。 また、システムの停止やエラーが起きた際にリカバリーが比較的容易です。しかし、リアルタイム性がないため、即時反応が求められるケースには不

        zono

        • データ関係者が行うべき匿名化の基本

          はじめに個人情報保護が求められる現代において、データの匿名化は非常に重要なプロセスです。特に、個人情報が大量に含まれるデータセットを扱う場合、そのデータをどのようにして匿名化し、適切に利用するかが課題となります。本記事では、2つの匿名化手法やリスクベースの非特定化方法論に基づく具体的な実装手法について、SQLを用いて解説します。 個人情報とは 「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日、その他の記述等により特定の個人を識別すること

          zono
        • 固定された記事

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

        zono

        マガジン

        • データモデリング・アーキテクチャまとめ
          3本
        • データ処理技術まとめ
          6本
        • データ志向アプリケーションデザインを活かすために
          12本
        • 実践的データ基盤への処方箋を現場で活かすために
          3本
        • DMBOKを現場で活かすために
          17本

        記事

          金融データのスタースキーマ実装方法

          はじめに 本記事では、金融データの管理・分析に有効なスタースキーマの概要と実装方法を紹介します。 データレイクに格納されたテーブルからスタースキーマを作成する具体的な方法について説明します。ただし、理解しやすさを優先したので非常にシンプルかつ簡易的な設計になっています。 スタースキーマ スタースキーマは、データウェアハウスやデータマートでよく使用されるデータモデルの一種です。その特徴はシンプルで直感的な構造でありながら、高いパフォーマンスと柔軟性を提供します。 スター

          zono

          金融データのスタースキーマ実装方法

          zono

          多段ビューのテーブル化によるクエリの効率化とコスト削減

          はじめにデータ分析基盤の設計は非常に重要な役割を果たしており、データエンジニアは、初期設計時にしばしば多段ビュー（nested views）を利用します。 しかし、これらの多段ビューは、パフォーマンスやコストの観点から問題を引き起こすことがあります。 本記事では、多段ビューの課題を解決するためにテーブル化を検討する方法について詳細に説明します。 多段ビューの利点と課題多段ビューの利点 柔軟性と再利用性: 多段ビューは、複数のビジネスロジックを再利用可能な形で定義することが

          zono

          多段ビューのテーブル化によるクエリの効率化とコスト削減

          zono

          分析基盤の誤ったデータの対処法

          誤ったデータが混入する主な原因データ入力プロセスで発生する問題 皆さんもご存知の通り、入力時点で誤ったデータが混入することは多々あります。リストエントリーやフィールドの影響や業務プロセスの変更、一貫していない業務プロセス等があります。 データ処理機能の稼働中に発生する問題 入力以外にもデータソースの仕様の誤認識だったり、送られてくるデータ構造の変更等もよくあるケースになります。ベンダーツールや他の部署が扱っているサーバー等、自分が把握できていないところから発生します。

          zono

          分析基盤の誤ったデータの対処法

          zono

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

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

          zono

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

          zono

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

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

          zono

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

          zono

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

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

          zono

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

          zono

          第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