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



の続きです。 Part 3は Derived Data です。 日本語訳的には派生データといったところでしょうか。Part1/Part2では各種データベースの特性などについての記述がメインでしたが、 Part3ではそれらのデータベース的なシステムを組み合わせアプリケーションを構築する話です。

何でもかんでも一つのデータベースで処理するのではなく、それぞれの長所短所を知った上で、アプリケーション全体を設計する必要があります。 複数のデータベースに格納するため、情報が重複し冗長だと言われそうなところですが、パフォーマンスを考えるとデータベースを組み合わせる事で より良いものが実現できます。

Chapter 10 Batch Processing


  • Services (online systems)
  • Batch processing system (offline systems)
  • Stream processing system (near-real-time systems)

このChapterではBatch processing systemを扱います。特にHadoop/Map Reduceが題材です、

MapReduce is a fairly low-level programming model compared to the parallel processing systems that were developed for data warehouses many years previously , but it was a major step forward in terms of the scale of processing that could be achieved on commodity hardware. Although the importance of MapReduce is now declining, it is still worth understanding, because it provides a clear picture of why and how batch processing is useful.

SQL on Hadoopを安易な気持ちで利用していると、もっとMapReduceの気持ちを考えろとお叱りを食らう事がよくあるのですが、ここでもそう書かれています。

この章では、UNIX Toolsの哲学が説明され、それと同様にMapReduceが動作するということが説明されます。

The philosophy was described in 1978 as follows:

Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”. Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input. Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.

そして、Reduce-Side Join や Map-Side join などの高速化手法が説明されています。

hiveなどのSQL on Hadoopの構成について、結構細かく書いてあるのですがここでは省略します。 Hadoopをアプリケーションの1構成要素として利用したい開発者にとってはちょうどいい情報量だと思います。 一方で、Hadoopの実装の細かいところまで知りたいという方には少し物足りないかもしれません。

Chapter 11 Stream Processing

The problem with daily batch processes is that changes in the input are only reflected in the output a day later, which is too slow for many impatient users. To reduce the delay, we can run the processing more frequently — say, processing a second’s worth of data at the end of every second — or even continuously, abandoning the fixed time slices entirely and simply processing every event as it happens. That is the idea behind stream processing.

As we have seen throughout this book, there is no single system that can satisfy all data storage, querying, and processing needs. In practice, most nontrivial applications need to combine several different technologies in order to satisfy their requirements: for example, using an OLTP database to serve user requests, a cache to speed up common requests, a full-text index to handle search queries, and a data warehouse for analytics. Each of these has its own copy of the data, stored in its own representation that is optimized for its own purposes.



KafkaなどのStream 処理用ツールの説明が細かく書いてあります。こちらもBatch processingと同じで、利用者側としては十分な情報量ですが、 実装まで知りたい人には不満かもしれません。


すごく雑にまとめてしまいましたが、とても良書です。みなさまが手にとるきっかけになればと思います。 とくに、膨大なデータを活用したビジネスが増えてきて、この本で扱っているような知見を必要とするような方が増えてくると思います。 その方の入門書としては最適だと思います。 また、RDBMSから進化がまとめて書いてあるので、玄人がまとめとして読んでも面白いかもしれません。

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