可視化や統計でデータに『恣意的なストーリーを語らせる』16の闇の魔術【bad charts】 - Qiita
闇の魔術に対する防衛術 Advent Calendar 2020の三日目 はじめに データの可視化は非常に難しい。 まずデータの抽出が難しい ・データソースごとの整合性が取れているか ・取得したデータとソースデータに欠損が生じていないか ・SQL文を実行したサマリの結果が部分的に抜け落ちていないか。 その確認は時間的にも精神的にも苦痛。 しかし、苦労して抽出したデータも使い方で全くの無駄になる その例として「可視化や統計」部分に着目してお話をしようと考えた。 データの背景を知らない人には、データ可視化が歩み寄る手段になるし、伝えたい事をインパクトを伴って伝えられるなど非常にメリットである。 ※ただし 「可視化」の使い方によっては誤った理解をさせることも可能。 伝えたい事だけを正しいように見せる方法もあり、 可視化に詳しくない人に誤解を与えて自分の主張を通すこともできるかもしれない。 これは
AWS GlueでApache Sparkジョブをスケーリングし、データをパーティション分割するためのベストプラクティス | Amazon Web Services
Amazon Web Services ブログ AWS GlueでApache Sparkジョブをスケーリングし、データをパーティション分割するためのベストプラクティス AWS GlueはApache Spark ETLジョブでのデータ分析・データ処理を行うために、様々なデータソースから大量のデータセットを準備(抽出および変換)し、ロードするサーバーレスな環境を提供します。この投稿のシリーズでは、Apache SparkアプリケーションとGlueのETLジョブの開発者、ビッグデータアーキテクト、データエンジニア、およびビジネスアナリストが、AWS Glue上で実行するデータ処理のジョブを自動的にスケールするのに役に立つベストプラクティスについて説明します。 まず最初の投稿では、データ処理を行うジョブのスケーリングを管理する上で重要な2つのAWS Glueの機能について説明します。1つ目は、
ドメイン駆動設計の集約のわかりにくさの原因と集約を理解するためのヒント - ソフトウェア設計を考える
『ドメイン駆動設計』のモデル要素のひとつとして「集約」があります。 アプリケーションの対象となる事業活動の仕組みや決め事をソフトウェアで表現する技法のひとつとして集約の考え方はとても役に立ちます。 集約パターンはデータベースのデータ整合性の視点での説明されることが多いようです。しかしデータ整合性の文脈で集約を理解しても、ドメイン駆動設計の中核の関心事である「ドメインの複雑さ」を理解しドメインの知識をクラスで表現するためにはあまり役に立ちません。 この記事では、集約パターンをドメインロジックを表現するモデルの構成要素として効果的に利用するためのヒントを提供したいと思います。 集約はデータ操作の道具ではありません。集約はビジネスルールにもとづくドメインロジックのモデリングと実装の手段です。ここがわかるとドメイン駆動設計の理解が一気に進むと思います。 どうして集約がデータ整合性の話になってしまう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
