データが主食

データエンジニアの備忘録。分析だったり、読んだ本のメモだったり。

書籍「Designing Data-Intensive Applications」まとめ(Part1)

はじめに

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

機械学習、人工知能、ビッグデータ。胡散臭いバズワードが流行しています。 それらを実践するためには、分析基盤がないと何もできません。 ということで、Designing Data-Intensive Applicationsというオライリー本を読んで勉強しましょう。 まだ日本語訳も出ておらず、情報も少ないので読んだ部分を整理していこうと思います。 かなりボリュームのある本ですので、章ごとにつまみ食いしていきます。

Part I. Foundations of Data Systems

Chapter 1. Reliable, Scalable, and Maintainable Applications

この書籍での大事な評価指標であるReliability, Scalability, Maintainabilityに関する定義です。data-intensive applicationとして必要な性能指標です。

指標1. Reliablity

The application performs the function that the user expected. It can tolerate the user making mistakes or using the software in unexpected ways. Its performance is good enough for the required use case, under the expected load and data volume. The system prevents any unauthorized access and abuse.

システムとして当たり前ですね。 Realiabilityが実現できていないとそもそもビジネスを始められません。

指標2. Scalability

Scalability is the term we use to describe a system’s ability to cope with increased load. Note, however, that it is not a one-dimensional label that we can attach to a system: it is meaningless to say “X is scalable” or “Y doesn’t scale.” Rather, discussing scalability means considering questions like “If the system grows in a particular way, what are our options for coping with the growth?” and “How can we add computing resources to handle the additional load?”

最近のクラウドを使ったシステムでは、Scalabilityというのは当たり前の存在かもしれません。しかし、単純にユーザー数やアクセス数、データ数などが多くなってもサービスを継続できるという意味でのScalabilityだけではなく、what are our options for coping with the growth? というのもScalabilityの一側面です。

指標3. Maintainability

MaintainablityOperability, Simplicity, Evolvability の3つの要素に分かれます。

Operability

Make it easy for operations teams to keep the system running smoothly.

基本ですね。運用工数がたくさん必要なシステムを作ってもなかなかビジネスとして成功できません。

Simplicity

Make it easy for new engineers to understand the system, by removing as much complexity as possible from the system. (Note this is not the same as simplicity of the user interface.)

業務委託などのエンジニアに参加してもらうことで、ビジネス/開発のフェーズに合わせて開発工数を動的に変えることができます。そのためには、システムをシンプルに保つ必要がありますね。

Evolvability

Make it easy for engineers to make changes to the system in the future, adapting it for unanticipated use cases as requirements change. Also known as extensibility, modifiability, or plasticity. As previously with reliability and scalability, there are no easy solutions for achieving

Evolvabilityというキーワードが入っているのが今っぽくて良いですね。アジャイル開発が流行っている昨今、データシステムもコロコロ変わることが求められます。

Chapter 2. Data Models and Query Languages

第2チャプター、データモデルとクエリ言語です。

Relational Model Versus Document Model

もともとはリレーショナルモデルが主流で、最近のシステム要求に合わせてドキュメントモデルが出て来ました。

However, if your application does use many-to-many relationships, the document model becomes less appealing.

最近は何かとNoSQLがもてはやされますが、joinなどのクエリが多くなってくるとやはりRDBMSを使いたくなります。

schema-on-read, schema-on-writeの違いなどを議論しています。一例ですが、SQL on Hadoopなどでは、schema-on-readなのか、schema-on-writeなのかで全然違うシステムになります。違いをちゃんと理解して、適材適所で組み上げる必要があります。

Query Languages for Data

In a declarative query language, like SQL or relational algebra, you just specify the pattern of the data you want — what conditions the results must meet, and how you want the data to be transformed (e.g., sorted, grouped, and aggregated) — but not how to achieve that goal. It is up to the database system’s query optimizer to decide which indexes and which join methods to use, and in which order to execute various parts of the query.

この言葉グッと来ました。SQLという宣言的な言語で書くことで、手続き的なことは意識しなくてもよくなるという話。最近、仕事でhive on tezを使っているのですが、tezをバージョンアップしただけで、大分高速化されました。宣言型で記述することで、こういった利便性もありますね。

Graph-Like Data Models

As is typical for a declarative query language, you don’t need to specify such execution details when writing the query: the query optimizer automatically chooses the strategy that is predicted to be the most efficient, so you can get on with writing the rest of your application.

GraphDBへのクエリについてです。Neo4jなど趣味では使ったことがあっても、実際のビジネスでは使ったことがなく、なかなか面白いです。特にソーシャルグラフなどをRDBで格納してしまうと、実際の分析場面で多段JOINを多用することになり、大変です。これも適材適所ですね。

Chapter 3. Storage and Retrieval

ストレージの話ですね。

Why should you, as an application developer, care how the database handles storage and retrieval internally? In order to tune a storage engine to perform well on your kind of workload, you need to have a rough idea of what the storage engine is doing under the hood.

DBの仕組みやストレージの仕組みを知らなくてもウェブアプリやスマホアプリを簡単に作れてしまう時代です。 しかし、ちゃんとチューニングするような段階では、各ストレージエンジンのコンセプトを知っているひつようがあります。

Data Structures That Power Your Database
#!/bin/bash 
db_set () { 
    echo "$ 1, $ 2" > > database 
} 

db_get () { 
    grep "^ $ 1," database | sed -e "s/ ^ $ 1,//" | tail -n 1 
}

これが世界でもっともシンプルなデータベースです。分かりやすいですね。これであれば、私でも作れますね。 でも、これだと検索をする度に、毎回ファイルを全て読み込む必要があり、だんだんと遅くなっていきます。 そのため、SSTableやLSM-Treesを使いましょうという話に展開していきます。 アイスブレイク的な冗談DBの話かと思いきや最先端の話につながっており、感動します。

Transaction Processing or Analytics?

OLTPとOLAPの違いが分かりやすく整理されています。 私もデータエンジニアになる前までは、PostgreSQL/MySQLでビッグデータ処理ができると思っていました。いわゆるエクセルで扱えないデータ量がビッグデータですね笑。 実際のビッグデータに触れないと、ここあたりの違いはなかなかわからないですね。 f:id:ktr89:20180618223402p:plain

所感

ストレージやデータベースの歴史的な話から始まっていきます。 しかし、学校の歴史の授業とは違って、すぐに最先端の話につながり、とても役に立つ話が多いです。 また、実務では使う機会がないようなDBの話も書いてあってとてもおすすめの本です。

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

関連

ktr89.hateblo.jp

ktr89.hateblo.jp