こんにちは佐々木です。
それでも続くデータ分析基盤の設計シリーズの第四弾です。と思っていたのですが、その前に1個書いていたので、第五弾でした。今回は、データの民主化の概念と、ELTです。ELTと書くと、ETL（Extract/Transform/Load）の誤字でしょと言われることが多いのですが、ELT（Extract/Load/Transform）です。
データ分析基盤におけるETL処理と、AthenaにおけるUpsertの実現方法について データ分析基盤構築の肝は、データレイクとDWHの分離 データレイクはRAWデータレイク・中間データレイク・構造化データレイクの３層構造にすると良い データ分析基盤における個人情報の扱いについて
データの民主化とは？
まずはじめに、データの民主化の概念の説明です。「データの民主化」あるいは「アナリティクス（分析）の民主化」とも言われます。これは、データ分析を一部の専門家ではなく、誰でもデータ分析をできるようにするということです。同様に、経営者や一部の人間にだけデータにアクセスできるということではなく、組織の中で必要とするものは誰でも利用できるという理念です。物事を判断する上で、事前のインプットの情報格差を作らせず、誰でも検討できるようにするということですね。
このあたり、『ワークマンは 商品を変えずに売り方を変えただけで なぜ2倍売れたのか』で実践している話が面白いです。誰でもデータ分析をできるようにトレーニングを導入し、特別なツールじゃなくてExcelで分析できるようにしているそうです。分析元となるデータを内製のシステムで作り出して、Excelに連携しているという形のようです。組織でどのようにデータの活用すればよいのか悩んでいる人は、一読することをお勧めします。
データの民主化を実現する上で必要な事
それではデータの民主化を実現するために、何が必要なのでしょうか？それは、組織の中のメンバー自身で、データ分析できるようにすることです。データ分析については、主に分析データを作るところと、それをレポートやダッシュボードにプレゼンテーションする部分の２つにわける事ができます。優先順位としては、まずは後者のプレゼンテーション部分を扱える人を増やすといことが大事です。ただ、ここでは主に前者の分析データを作るところにフォーカスします。
分析データを作る部分というのは、次の図のようにデータソースのデータを何らかの加工処理をしてDWHに加工する部分の事を指すことが多いです。いわゆるETL（Extract/Transform/Load ）ですね
この後ひたすら、ETLとELTが出てきて字面的にもややこしいです。本文中のETLは変換処理の概念としてのETLと実装としてのETLの2種類の意味で使っています。ELTについては、概念としての変換処理（ETL）の実装の手段の一つを指すものとします。
ETL（Extract/Transform/Load）とELT（Extract/Load/Transform）
ETL（Extract/Transform/Load）の肝は、データの変換部分（Transform）です。データ変換の実装方法はいろいろあり、オーソドックスに自前でプログラムを書く以外にも、ETL専用のサービスやフレームワークを使うという方法もあります。また、最近ではGUIだけで完結し、データの変換ができるサービスも多数あります。データ分析基盤を作る上では、このETLのエンジンの選定が非常に重要になります。
通常のシステムの場合、核はロジックです。ロジックなので、一度システムを構築してしまえば、日常的にロジックを改修し続ける必要があるケースは少ないです。しかし、データ分析基盤が扱う対象は、データであり分析です。データであるがため、扱うデータ種別や組み合わせが増える可能性が高いです。また分析したい事項も、課題に応じて変わってきます。そのため、一度ETL処理を組んでお終いじゃなく、常に新しいETL処理を作る必要があります。そんな時に、都度外注して構築を依頼していると、コストは高くつき、スピードもビジネス側の要望には応えられないかもしれません。そういった意味で、ETL含め内製化できるのがベストです。
内製化を考えた場合、専任のITエンジニアを確保できれば良いですが、それが難しい場合の方が多いのではないでしょうか。その場合に、非IT人材にETLのプログラムを組めと言われても、厳しいものがあります。そんな背景を元に注目を浴びているのが、ELTです。ETLと処理の順番を変えて、Extract⇒Load⇒Transformという順番で処理を行います。具体的にいうと、まずDWHに入れてしまって、DWH内のSQLで変換処理を行うという手法です。
プログラムは難しいけど、SQLだと何とかなるという人や組織は結構あります。もうちょっとストレートに言うと、とりあえずBigQueryに入れる仕組みを作って貰えれば、あとは自分たちで何とかなるという状況です。データの民主化の重要な要素の一つに、一部の専門ではなくみんながデータ分析を行えるようにするというのがあります。その考えを分析だけに限定するのではなく、データの生成の部分に広げた場合に、ETLをどうするかは重要です。そして、ELTという実装の仕方が、わりと広がっているという現状です。
※もちろんSQLすら使わずに、グラフィカルなインターフェイスでETLを行うという選択も良い選択だと思います
AWSにおけるELTの実現方法
ETLとELTという考え方が出てきた上で、AWSであればどのように実装すればよいのでしょうか？まず一般的な概念であるETL（Extract/Transform/Load）から考えてみましょう。小規模な場合はLambdaで実装する場合もありますが、基本的には専用サービスであるGlueを使うのが良いでしょう。Glueは簡単な処理であれば、GUIのみで実現できます。また複雑な処理であれば、Python ShellもしくはSparkのプログラミングで何でも実装できます。
では本題であるELT（Extract/Load/Transform）として作りたい場合は、どうでしょうか？Load先であるDWHに相当するものの第一候補は、Redshiftになります。ただこのELTという部分に限って言えば、AthenaでS3のデータに直接クエリを投げるというのも良い選択肢です。またAthenaは、Glueと連携できるようになっています。ETL処理のジョブ管理部分をGlueに任せて、処理はAthenaでSQLで実装するというのも良いですね。このあたりの詳細については、過去のエントリーをご参照ください。
まとめ
データの民主化とは、分析を一部の専門家に任せるものではないです。またデータ分析基盤は、一度作ったらお終いではなく、日常的に手を加えていく必要があります。そのために、分析を見る/見せるプレゼンテーション層だけではなく、そのデータの生成をするETL部分についても、自分の手で修正できるようにしておいた方がよいです。その手段の一つとして、SQLで実現できるELTは良い選択肢になるのではないでしょうか？組織にとって、どのようなアーキテクチャが最適かは異なります。ただし、どうやれば自前で運用できるかを事前に考えておくことが重要です。データ分析基盤を作る際の一助になれば幸いです。
