データが主食

データ系エンジニアのぽえむ。分析だったり、読んだ本のメモだったり。

書籍「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

機械学習人工知能ビッグデータ。胡散臭いバズワードが流行しています。機会学習理論を理解するためには、線形代数が必要だみたいな言説をよく耳にしますが、処理基盤がないと何もできません。ということで、ビッグデータ処理基盤に関するオライリー本です。まだ日本語訳も出ておらず、情報も少ないので読んだ部分を整理していこうと思います。かなりボリュームのある本ですので、章ごとにまとめていきます。

Part I. Foundations of Data Systems

Chapter 1. Reliable, Scalable, and Maintainable Applications

この書籍での大事な評価指標であるReliability, Scalability, Maintainabilityに関する定義です。

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.

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?”

Maintainability

Maintainablityは3つの要素に分かれます。Evolvabilityというキーワードが入っているのが良いですね。アジャイル開発が流行っている昨今、データシステムもコロコロ変わることが求められます。アジャイル開発の本質は不確実なビジネス環境で、、みたいに語りたくなりますが、今回は関係ないですね。

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

Chapter 2. Data Models and Query Languages

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

Relational Model Versus Document Model

もともとはリレーショナルデータベースが主流で、最近の要請に合わせてNoSQLが出て来ました。

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

その他、schema-on-read, schema-on-writeの違いなどを議論しています。ここあたり知らないと、サービスイン後にデータスキーマ変更できるの?できないの?みたいな議論ができなくなってしまいますね。

Query Languages for Data

身の回りのデータサイエンティストからSQLはクソという言葉を浴びせかけられることが多いですが、この言葉グッと来ました。SQLという宣言的な言語で書くことで、手続き的なことは意識しなくてもよくなるという話、感覚的にはわかっていましたが、納得感がありました。

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.

Graph-Like Data Models

GraphDBへのクエリについてです。Neo4jなど趣味では使ったことがあっても、実際のビジネスでは使ったことがなく、なかなか面白いです。業務での実例を知りたいですね。

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.

Chapter 3. Storage and Retrieval

ストレージの話ですね。データベースの議論の前に足回りです。いきなり、KuduとかHiveとかそういうアプリケーションから入るのではなくて、足回りから入るところが好感持てます。

Data Structures That Power Your Database

これが世界でもっともシンプルなデータベースだそうです。分かりやすいですね。これであれば、僕でも作れますね。世界で一番シンプルなKVSという名称でgithubに公開しようかな。それ以外にもSSTable やLSM-Treesなどの話も面白いですね。もちろんB木も紹介されています。

#!/ bin/ bash 
db_set () { 
    echo "$ 1, $ 2" > > database 
} 

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

OLTPとOLAPの違いが分かりやすく整理されています。データエンジニアになる前までは、MySQLビッグデータ処理ができると思っていました。実際のビッグデータに触れないとここあたりの違いはなかなかわからないですね。カラム志向などもとても分かりやすく説明されています。

f:id:ktr89:20180618223402p:plain

Column-Oriented

ビッグデータといえばカラム志向ですね。列方向の集計が多いから、それに合わせたデータフォーマットにするという話、当たり前といえば当たり前ですが、面白い。 最近のカンファレンスではParquetr採用のおかげでストレージがだいぶ減ったみたいな話もありましたね。