オライリー"What is big data? An introduction to the big data landscape."を勝手に翻訳

オライリー・ジャパンのウェブサイトで翻訳が出るかと思っていたものの半年経っても出る気配がないので訳してみた。と言ってもこちとら素人なので翻訳品質は期待しないでほしい。

翻訳の前に「ビッグデータ」をめぐる混乱（あるいはマーケター無双状態）

「ビッグデータ」というと最近話題になったSSL閲覧履歴もまとめて取得しちゃうぞーという色々と問題のあるツールバーとか
Tポイントツールバーを導入するとSSL通信の履歴までもが盗聴可能になる | 徳丸浩の日記

地球外からやってきた営業生命体とか

よくわからないのでググってみた。「僕はビッグデータになってくれってきちんとお願いしたはずだよ。実際の姿がどういうものか、説明を省略したけれど」「なんで教えてくれなかったのよ！」「聞かれなかったからさ。知らなければ知らないままで何の不都合もないからね。」そのまんまやん。

2012-03-04 14:02:35 via Twitter for Mac

とりあえずサッカーコラムのタイトルに付けてみたけど、内容的には大規模データ解析もヘッタクレもない何かとか。
「ビッグデータ」で読み解く現代サッカーの神髄：日経ビジネスオンライン

あるいは~~ODBCでRDBにアクセスするソフトで実行速度が向上した新バージョンを「ビッグデータ対応」とか謳っちゃうとかもう~~（実生活に差し障りが出るので以下省略）。

とにかく「ビッグデータ」って言っておけば何でも許されるらしい今日この頃、改めてビッグデータとは何かを考える材料になればと思い翻訳。いやそれ以外にも帰省中に余りに暇だったので自主的な夏休みの宿題というのも半分ぐらいの理由。あと、全体の8割ぐらいはEee Pad Transformer TF101 + Android版Atokで作業。それなりに長文を打てる環境だということも確認しました。

以下翻訳

Big data is data that exceeds the processing capacity of conventional database systems. The data is too big, moves too fast, or doesn’t fit the strictures of your database architectures. To gain value from this data, you must choose an alternative way to process it.

ビッグデータとは、従来のデータベースシステムの処理能力を超えるデータです。そのデータは大きすぎたり、早く動きすぎたり、またはあなたのデータベースアーキテクチャに上手く適合しません。そのデータから価値を得るには、処理のための新しい方法を選ばなければなりません。

The hot IT buzzword of 2012, big data has become viable as cost-effective approaches have emerged to tame the volume, velocity and variability of massive data. Within this data lie valuable patterns and information, previously hidden because of the amount of work required to extract them. To leading corporations, such as Walmart or Google, this power has been in reach for some time, but at fantastic cost. Today’s commodity hardware, cloud architectures and open source software bring big data processing into the reach of the less well-resourced. Big data processing is eminently feasible for even the small garage startups, who can cheaply rent server time in the cloud.

2012年のホットなITバズワードである「ビッグデータ」は大容量で高速で多様な大量のデータを扱うための費用対効果の高いアプローチとして確立されたものとなりました。このデータの中には、これまで抽出するには多大な労力が必要であるために隠されていた価値あるパターンや情報が埋まっていました。ウォルマートやGoogleのような企業を導くために何度か使われていましたが、馬鹿げたコストがかかっていました。今日のコモデティ化したハードウェアや、クラウドアーキテクチャ、そしてオープンソースソフトウェアにより、手持ちリソースの少ない人々にとっても、ビッグデータ処理が手の届くものとなりました。ビッグデータ処理は、クラウド上の安価なレンタルサーバを使うような小さなガレージ起業家にとってすら大いに使えるものとなっています。

The value of big data to an organization falls into two categories: analytical use, and enabling new products. Big data analytics can reveal insights hidden previously by data too costly to process, such as peer influence among customers, revealed by analyzing shoppers' transactions, social and geographical data. Being able to process every item of data in reasonable time removes the troublesome need for sampling and an investigative approach to data, in contrast to the somewhat static nature of running predetermined reports.

組織にとってのビッグデータの価値は2つのカテゴリに分類されます。分析への利用と、新しい製品を可能とすることです。ビッグデータ分析は、例えば買い物客の商取引やソーシャルデータ、地理的データを分析することで顧客の間での仲間内の影響のような、これまで処理にコストがかかりすぎることから隠されていた洞察を明らかにすることを可能としました。データ中の全ての項目を手頃な時間で処理できるようになったことで、事前に決定されているレポートを実行するような静的な特徴とは対照的に、サンプリングやデータの調査手法に対する面倒な要求が取り除かれます。

The past decade's successful web startups are prime examples of big data used as an enabler of new products and services. For example, by combining a large number of signals from a user's actions and those of their friends, Facebook has been able to craft a highly personalized user experience and create a new kind of advertising business. It's no coincidence that the lion's share of ideas and tools underpinning big data have emerged from Google, Yahoo, Amazon and Facebook.

過去10年に成功したWebスタートアップは、ビッグデータが新しい製品やサービスを可能とするために使用された素晴らしい例です。例えば、ユーザや彼らの友人たちの活動による多数のシグナルを統合することにより、Facebookは高度にパーソナライズされたユーザー経験を作成し、さらに新しい形の広告業を作ることを可能としました。ビッグデータを下支えするアイデアやツールといった「ライオンの分前」がGoogle、Yahoo、AmazonそしてFacebookから現れたことは偶然ではありません。

The emergence of big data into the enterprise brings with it a necessary counterpart: agility. Successfully exploiting the value in big data requires experimentation and exploration. Whether creating new products or looking for ways to gain competitive advantage, the job calls for curiosity and an entrepreneurial outlook.

ビッグデータが企業で導入されるようになるととともに、必要なカウンターパートである迅速性も導入されるようになりました。ビッグデータの価値を上手く使うには、実験と調査が必要となります。新しい製品を作るにせよ競争的利益を得るにせよ、その仕事には好奇心と起業家的な視点が求められます。

What does big data look like?
As a catch-all term, "big data" can be pretty nebulous, in the same way that the term "cloud" covers diverse technologies. Input data to big data systems could be chatter from social networks, web server logs, traffic flow sensors, satellite imagery, broadcast audio streams, banking transactions, MP3s of rock music, the content of web pages, scans of government documents, GPS trails, telemetry from automobiles, financial market data, the list goes on. Are these all really the same thing?
To clarify matters, the three Vs of volume, velocity and variety are commonly used to characterize different aspects of big data. They're a helpful lens through which to view and understand the nature of the data and the software platforms available to exploit them. Most probably you will contend with each of the Vs to one degree or another.

ビッグデータとはどのようなモノなのか？
キャッチーな言葉である"ビッグデータ"は、"クラウド"という言葉が様々な技術をカバーしているのと同じように、非常に曖昧なものになり得ます。ビッグデータシステムへ入力できるデータはソーシャルメディアでのおしゃべりや、ウェブサーバのログや、交通量センサや、衛星画像や、放送音響システムや、銀行取引や、ロックミュージックのMP3や、ウェブページのコンテンツや、政府公文書のスキャンや、GPSログや、自動車のテレメトリデータや、金融市場データ、とリストは続きます。これらは本当に同じものなのでしょうか？

問題をはっきりさせるため、容量（volume）、速度（velocity）、多様性（variety ）という3つのVがビッグデータの異なる側面を特徴づけるため一般的に使われています。このような見方を通して、データの特性や、これらのデータを開拓するために有用なソフトウェアプラットフォームを見通し、理解する助けとなります。おそらくあなたは、それぞれのVと多かれ少なかれ戦うことになります。

Volume
The benefit gained from the ability to process large amounts of information is the main attraction of big data analytics. Having more data beats out having better models: simple bits of math can be unreasonably effective given large amounts of data. If you could run that forecast taking into account 300 factors rather than 6, could you predict demand better?
This volume presents the most immediate challenge to conventional IT structures. It calls for scalable storage, and a distributed approach to querying. Many companies already have large amounts of archived data, perhaps in the form of logs, but not the capacity to process it.

容量
大量の情報を処理する能力から得られる利点は、ビッグデータ解析の主要な魅力です。より多くのデータを持つことは、より良いモデルを持つことに勝ります。大量のデータから得られた単純で僅かな数値は、途方もなく有用になり得ます。もし6つの要素より300の要素を考慮に入れた予想が出来れば、より良く要求を予想できるでしょう？

容量(Volume)は、従来のITストラクチャに対し、待ったなしのの挑戦を引き起こします。大容量により、スケーラブルなストレージや、分散クエリ実行が必要となります。多くの会社は既に、おそらくログなどの形で大量のアーカイブ化されたデータを持っていますが、それを処理する能力は持っていません。

Assuming that the volumes of data are larger than those conventional relational database infrastructures can cope with, processing options break down broadly into a choice between massively parallel processing architectures ― data warehouses or databases such as Greenplum ― and Apache Hadoop-based solutions. This choice is often informed by the degree to which the one of the other “Vs” - variety ― comes into play. Typically, data warehousing approaches involve predetermined schemas, suiting a regular and slowly evolving dataset. Apache Hadoop, on the other hand, places no conditions on the structure of the data it can process.

仮に、データの容量が従来のリレーショナルデータベースインフラが処理できる量を超えたと仮定すると、例えばGreenplumやApache Hadoopベースのソリューションのような強力な並行処理アーキテクチャが処理のための選択肢となります。この選択はしばしば他のV - 多様性（variety）の登場です - が関わります。一般的に、事前に決定されたスキーマを必要とするデータをウェアハウス化するアプローチは、規則正しくゆっくりと発展するデータセットに適合しています。一方、Apache Hadoopでは、データの構造には依存しません。

At its core, Hadoop is a platform for distributing computing problems across a number of servers. First developed and released as open source by Yahoo, it implements the MapReduce approach pioneered by Google in compiling its search indexes. Hadoop’s MapReduce involves distributing a dataset among multiple servers and operating on the data: the “map” stage. The partial results are then recombined: the “reduce” stage.
To store data, Hadoop utilizes its own distributed filesystem, HDFS, which makes data available to multiple computing nodes. A typical Hadoop usage pattern involves three stages:

loading data into HDFS,

MapReduce operations, and

retrieving results from HDFS.

This process is by nature a batch operation, suited for analytical or non-interactive computing tasks. Because of this, Hadoop is not itself a database or data warehouse solution, but can act as an analytical adjunct to one.

本質的には、Hadoopはたくさんのサーバをまたぐ分散コンピューティングのプラットフォームです。もともとYahooにより開発されオープンソースとしてリリースされました。HadoopはGoogleにより検索インデックスコンパイルのために切り開かれたアプローチであるMapReduceを実装しています。HadoopのMapReduceは複数のサーバ間に分散したデータセットを含み”map"ステージで処理されます。これら部分的な結果は、次に"reduce"ステージで再結合されます。

データを保存するため、Hadoopは複数の計算ノードからデータを利用するため、固有の分散ファイルシステムであるHDFSを利用します。典型的なHadoopの使用パターンは以下の三つのステージを含みます。

データをHDFSへロード
MapReduce処理
HDFSから結果を取得

この処理は本質的に、インタラクティブでは無い計算処理タスクを扱うための一括処理です。そのため、Hadoop単体ではデータベースまたはデータウェアハウスソリューションに向いておらず、分析のための付加的なものとして使うことが可能です。

One of the most well-known Hadoop users is Facebook, whose model follows this pattern. A MySQL database stores the core data. This is then reflected into Hadoop, where computations occur, such as creating recommendations for you based on your friends’ interests. Facebook then transfers the results back into MySQL, for use in pages served to users.

FacebookはHadoopのもっともよく知られたユーザのひとつであり、かれらのモデルはこのパターンを踏まえています。mySQLデータベースはコアデータを保存ししています。このデータは、あなたのフレンドの関心に基づくレコメンデーションを作成するときなどの計算が行われたときにHadoopへ反映されます。

Velocity
The importance of data’s velocity ― the increasing rate at which data flows into an organization ― has followed a similar pattern to that of volume. Problems previously restricted to segments of industry are now presenting themselves in a much broader setting. Specialized companies such as financial traders have long turned systems that cope with fast moving data to their advantage. Now it’s our turn.

速度
データが持つ速度　ー　組織へ流れ込むデータの増加量　ー　の重要性は、データの容量と同じパターンを持っています。以前は産業のセグメントにより制約されていた問題が、より幅広い背景の中に現れてきています。金融取引業のような特殊化された会社は、高速で移動するデータに対応し、アドバンテージとするためにシステムを変更し続けています。ここで私たちの出番です。

Why is that so? The Internet and mobile era means that the way we deliver and consume products and services is increasingly instrumented, generating a data flow back to the provider. Online retailers are able to compile large histories of customers’ every click and interaction: not just the final sales. Those who are able to quickly utilize that information, by recommending additional purchases, for instance, gain competitive advantage. The smartphone era increases again the rate of data inflow, as consumers carry with them a streaming source of geolocated imagery and audio data.

なぜそうなるのでしょうか？インターネットとモバイルの時代は、製品やサービスを配送し消費する方法が益々計測され、提供者へ戻すためのデータが収集されることを意味します。オンライン小売業者は、単なる最終的な売り上げだけではなく、消費者のすべてのクリックやインタラクションの大きな履歴をかき集めることが可能です。この情報を迅速に利用可能な人々は、たとえば追加購入をおすすめすることにより、競争上の優位を得ます。スマートフォン時代においては消費者が地理情報や音声データを提供するため、データ流入率が再度上昇しています。

It’s not just the velocity of the incoming data that's the issue: it's possible to stream fast-moving data into bulk storage for later batch processing, for example. The importance lies in the speed of the feedback loop, taking data from input through to decision. A commercial from IBM makes the point that you wouldn't cross the road if all you had was a five-minute old snapshot of traffic location. There are times when you simply won't be able to wait for a report to run or a Hadoop job to complete.

やってくるデータの速さだけが問題ではなく、たとえば後でバッチ処理を行うために高速データをバルクストレージへと流し込むことが可能であるかどうかが問題です。重要なのは、入力されたデータを元に決定を行うためのフィードバックループのスピードです。五分前の古い交通量スナップショットを元に道路を渡ることが出来ないというIBMのコマーシャルはポイントを射ています。レポートを実行したり、Hadoopのジョブが完了するまで待つことが出来ない場合もあります。

Industry terminology for such fast-moving data tends to be either “streaming data,” or “complex event processing.” This latter term was more established in product categories before streaming processing data gained more widespread relevance, and seems likely to diminish in favor of streaming.

専門用語として、このように高速で動くデータを「ストリーミングデータ」または「複雑なイベント処理」と呼びます。後者はストリーミングデータ処理が広範に受け入れられる以前にプロダクトのカテゴリに確立されました、ストリーミングという言葉のにおいを嫌っているような感じもします。

There are two main reasons to consider streaming processing. The first is when the input data are too fast to store in their entirety: in order to keep storage requirements practical some level of analysis must occur as the data streams in. At the extreme end of the scale, the Large Hadron Collider at CERN generates so much data that scientists must discard the overwhelming majority of it ― hoping hard they’ve not thrown away anything useful. The second reason to consider streaming is where the application mandates immediate response to the data. Thanks to the rise of mobile applications and online gaming this is an increasingly common situation.

ストリーミング処理を考慮すべき二つの理由があります。最初の理由は、永続化して保存するには入力データが早すぎる場合です。スケールの究極的な例ですが、CERNのラージハドロンコライダーは大量のデータを生成するため、科学者たちは有用な何かを放り投げていないことを強く願いつつ、その大部分を破棄する必要があります。ストリーミングを考慮すべき二つ目の理由としては、データに対して迅速な応答が必須となるアプリケーションがあります。これはモバイルアプリケーションやオンラインゲームの増加により、ますます一般的な状況となっています。

Product categories for handling streaming data divide into established proprietary products such as IBM's InfoSphere Streams, and the less-polished and still emergent open source frameworks originating in the web industry: Twitter’s Storm, and Yahoo S4.
As mentioned above, it's not just about input data. The velocity of a system's outputs can matter too. The tighter the feedback loop, the greater the competitive advantage. The results might go directly into a product, such as Facebook's recommendations, or into dashboards used to drive decision-making.

ストリーミングデータを扱うためのプロダクトカテゴリは、IBMのInfoSphere Streamsのような確立されたプロプライエタリプロダクトと、比較的洗練されておらず未だに新興の、Twitter StormやYahoo S4のようWeb産業由来のオープンソースフレームワークとに二分されています。

上で述べたように、これはインプットデータに関するものだけではありません。システムの出力速度も同様の問題となり得ます。フィードバックループがタイトになるほど、競争上の利点があります。フィードバック結果は、たとえばFacebookのリコメンデーションや意志決定のためのダッシュボードへ直に反映します。

It’s this need for speed, particularly on the web, that has driven the development of key-value stores and columnar databases, optimized for the fast retrieval of precomputed information. These databases form part of an umbrella category known as NoSQL, used when relational models aren't the right fit.

特にwebにおいて、計算済みの情報を迅速に取り出すことに特化したキーバリューストアやカラム指向データベースの開発が促進されているのは、スピードへの要求のためです。このようなデータベースは、NoSQLとして知られる包括的なカテゴリを形成し、リレーショナルモデルが適合しない場合に使用されます。

Variety
Rarely does data present itself in a form perfectly ordered and ready for processing. A common theme in big data systems is that the source data is diverse, and doesn't fall into neat relational structures. It could be text from social networks, image data, a raw feed directly from a sensor source. None of these things come ready for integration into an application.

多様性
データ自身が完全に並べられ、処理の準備が整っているということは滅多にありません。ビッグデータシステムの共通テーマの一つは、元となるデータが多様であり、秩序正しいリレーション構造へ落とし込むことができないということです。ソーシャルネットワークから得られたテキストデータや、画像データや、センサーソースから直に得られた生フィードなどのことです。これらのモノは、あるアプリケーションへと統合するための準備がなされていません。

Even on the web, where computer-to-computer communication ought to bring some guarantees, the reality of data is messy. Different browsers send different data, users withhold information, they may be using differing software versions or vendors to communicate with you. And you can bet that if part of the process involves a human, there will be error and inconsistency.

コンピュータ同士がコミニュケーションすることである程度の保証があるはずのWebにおいてすら、実際のデータは乱雑なものです。異なるブラウザは異なるデータを送信し、ユーザは情報を差し控え、あなたとの通信にバージョンやベンダーが異なるソフトウェアを使用するかもしれません。また、もし処理に人の手を入れてしまえば、間違いなくエラーや不整合が発生します。

A common use of big data processing is to take unstructured data and extract ordered meaning, for consumption either by humans or as a structured input to an application. One such example is entity resolution, the process of determining exactly what a name refers to. Is this city London, England, or London, Texas? By the time your business logic gets to it, you don’t want to be guessing.

ビッグデータ処理の一般的な使用としては、人の手による、あるいはアプリケーションへ入力された構造化データを消費するため、非構造化データを取得し秩序だった意味を抽出することです。そのような例の一つがエンティティ解析、つまりある名前がなにを指し示しているのかということを正確に決定する処理です。"ロンドン"とは英国のロンドンのことでしょうか？あるいはテキサス州のロンドンのことでしょうか？あなたのビジネスロジック上でこんなことを推測したくありませんよね。

The process of moving from source data to processed application data involves the loss of information. When you tidy up, you end up throwing stuff away. This underlines a principle of big data: when you can, keep everything. There may well be useful signals in the bits you throw away. If you lose the source data, there’s no going back.

ソースデータをアプリケーションデータへ移動する処理は、情報のロスを伴います。整理整頓をするときには、最終的にはがらくたを放り捨てます。ビッグデータにも同じ原理が存在しており、可能な場合には全てを取っておくべきです。あなたが放り投げる断片は有用なシグナルであるかもしれません。ソースデータを失えば、もう戻らないのです。

Despite the popularity and well understood nature of relational databases, it is not the case that they should always be the destination for data, even when tidied up. Certain data types suit certain classes of database better. For instance, documents encoded as XML are most versatile when stored in a dedicated XML store such as MarkLogic. Social network relations are graphs by nature, and graph databases such as Neo4J make operations on them simpler and more efficient.

リレーショナルデータベースに人気があり、その性質がよく理解されているにも関わらず、整頓されている場合ですら、常にデータの終着点となる訳ではありません。ある種のデータタイプは、データベースよりも適合します。たとえば、XML エンコードされたドキュメントはMarkLogicのような特化したXMLストアへ保存した場合にもっとも使い勝手がよくなります。ソーシャルネットワークの関連性は原理的にグラフであり、Neo4jのようなグラフデータベースにより、よりシンプルで有効に処理できます。

Even where there’s not a radical data type mismatch, a disadvantage of the relational database is the static nature of its schemas. In an agile, exploratory environment, the results of computations will evolve with the detection and extraction of more signals. Semi-structured NoSQL databases meet this need for flexibility: they provide enough structure to organize data, but do not require the exact schema of the data before storing it.

劇的なデータタイプのミスマッチがない場合でも、リレーショナルデータベースはそのスキーマが本質的に静的であるという欠点を持っています。アジャイルで試験的な環境では、計算結果はより多くのシグナルが検出され抽出されることで進化します。準構造化されたNoSQLデータベースは、組織的なデータに十分な構造を提供しますがデータを保存する前に厳密なスキーマを要求しないため、柔軟性という要求に見合います。

実用面（In practice）

We have explored the nature of big data, and surveyed the landscape of big data from a high level. As usual, when it comes to deployment there are dimensions to consider over and above tool selection.

我々はビッグデータの性質を説明し、高いレベルからビッグデータの俯瞰図を調査しました。通常は、配置を行うときにはツールの選択に加えて他の側面についても考慮が必要です。

Cloud or in-house?
The majority of big data solutions are now provided in three forms: software-only, as an appliance or cloud-based. Decisions between which route to take will depend, among other things, on issues of data locality, privacy and regulation, human resources and project requirements. Many organizations opt for a hybrid solution: using on-demand cloud resources to supplement in-house deployments.

クラウドかインハウスか

現在ビッグデータソリューションの主流は、ソフトウェアのみ、アプライアンス、クラウドベースという三つの形で提供されています。これらの内どのルートを取るべきかという決定は、データの置き場所やプライバシーと規則、ヒューマンリソースやプロジェクトの要求によります。多くの組織は、インハウスでの配置を補助するためのオンデマンドクラウドリソースの利用というハイブリッドな解決法を選択します。

Big data is big
It is a fundamental fact that data that is too big to process conventionally is also too big to transport anywhere. IT is undergoing an inversion of priorities: it’s the program that needs to move, not the data. If you want to analyze data from the U.S. Census, it's a lot easier to run your code on Amazon’s web services platform, which hosts such data locally, and won’t cost you time or money to transfer it.
Even if the data isn’t too big to move, locality can still be an issue, especially with rapidly updating data. Financial trading systems crowd into data centers to get the fastest connection to source data, because that millisecond difference in processing time equates to competitive advantage.

ビッグデータは大きい

ビッグデータの、従来通りの処理には大きすぎるというビッグデータの根本的な性質は、何処が他の場所へ運ぶには大きすぎるということも意味しています。ITは動かすべきはプログラムであり、データではないという優先順位の逆転を経ている最中です。もしも米国国勢調査で得られたデータを解析したい場合、そのようなデータをローカル上にホストしており、データの転送にコストや時間をかける必要の無いAmazonのWebサービスプラットフォーム上でプログラムを実行する方が大変容易です。

もしも移動するには大きすぎるようなデータでない場合ですら、特にデータが頻繁に更新される場合には、データの場所が問題となります。金融取引システムはソースデータへ最高速での接続を行うためにデータセンターへ群がっていますが、これは処理にかかるミリ秒の差が競争上の優位と等しいからです。

Big data is messy
It's not all about infrastructure. Big data practitioners consistently report that 80% of the effort involved in dealing with data is cleaning it up in the first place, as Pete Warden observes in his Big Data Glossary: “I probably spend more time turning messy source data into something usable than I do on the rest of the data analysis process combined.”
Because of the high cost of data acquisition and cleaning, it's worth considering what you actually need to source yourself. Data marketplaces are a means of obtaining common data, and you are often able to contribute improvements back. Quality can of course be variable, but will increasingly be a benchmark on which data marketplaces compete.

ビッグデータは汚い
ビッグデータの専門家は、80%の努力が最初にデータをクリーンにするために払われていると一貫して報告しています。Pete Wardenは彼のビッグデータ用語集で"私はおそらく汚いソースデータを利用可能なものとするためにより多くの時間を費やし、その後の残りにデータ分析処理が付いてくる"と観察しています。

データを掘り出して浄化するための処理が高コストであるため、実際に必要な物を自分自身で供給することは考慮に値します。データ市場は一般的なデータを得る手段であり、しばしばあなたの改良を戻すことで貢献することも可能です。もちろん品質は様々ですが、データ市場における競争を示す判断基準となっていくでしょう。

Culture
The phenomenon of big data is closely tied to the emergence of data science, a discipline that combines math, programming and scientific instinct. Benefiting from big data means investing in teams with this skillset, and surrounding them with an organizational willingness to understand and use data for advantage.
In his report, “Building Data Science Teams,” D.J. Patil characterizes data scientists as having the following qualities:

Technical expertise: the best data scientists typically have deep expertise in some scientific discipline.

Curiosity: a desire to go beneath the surface and discover and distill a problem down into a very clear set of hypotheses that can be tested.

Storytelling: the ability to use data to tell a story and to be able to communicate it effectively.

Cleverness: the ability to look at a problem in different, creative ways.

The far-reaching nature of big data analytics projects can have uncomfortable aspects: data must be broken out of silos in order to be mined, and the organization must learn how to communicate and interpet the results of analysis.
Those skills of storytelling and cleverness are the gateway factors that ultimately dictate whether the benefits of analytical labors are absorbed by an organization. The art and practice of visualizing data is becoming ever more important in bridging the human-computer gap to mediate analytical insight in a meaningful way.

文化
ビッグデータの展開は、数学とプログラミングと科学的直感が組み合わさった規範であるデータサイエンスの隆興と緊密に結びついています。ビッグデータから利益を得るということは、このスキルセットのチームへ投資するということを意味しており、またデータを利益のために理解し使用するという組織的な意思で包み込むことを意味します。

D.J. Patilは彼のレポート“Building Data Science Teams,"で、データ科学者を次のような資質を持つと特徴付けています。

専門技術経験: 最高のデータ科学者は一般的に科学的訓練に基づく深い経験
好奇心: 表面を掘り下げ、問題点を検証可能で明確な仮説へと生成する欲求
ストーリーテリング: データを使って物語を語り、効果的なコミュニケーションを取る能力
賢さ：問題を普通とは違った創造的な方法で見ることが出来る能力

ビッグデータ解析プロジェクトの遠大な性質には、不愉快な面もあります。データを採掘するにはサイロを壊さねばなりませんし、組織はコミュニケートし分析結果を横取りする方法を学ばなければなりません。ストーリーテリングや賢さといったスキルは、分析作業が最終的に組織に吸収されるかどうかを決定づける不可欠な因子となります。データを可視化する技術と実践は、有用な分析的洞察を仲介するための人とコンピュータとの隙間をつなぐますます重要な要素となっています。

Know where you want to go
Finally, remember that big data is no panacea. You can find patterns and clues in your data, but then what? Christer Johnson, IBM’s leader for advanced analytics in North America, gives this advice to businesses starting out with big data: first, decide what problem you want to solve.
If you pick a real business problem, such as how you can change your advertising strategy to increase spend per customer, it will guide your implementation. While big data work benefits from an enterprising spirit, it also benefits strongly from a concrete goal.

目的をはっきり持て
最後に、ビッグデータに万能薬が無いことを忘れないでください。データにパターンや手がかりを見つけることが出来るかも知れませんが、その次に何をすべきでしょうか？IBMの北米先端分析部門のリーダーであるChrister Johnsonは、ビッグデータからはじめるビジネスについて次のようにアドバイスしています。最初に、あなたが解決したい問題を決めておけと。
もしも実際のビジネス上の問題、例えば顧客ごとの消費を増加させるために広告戦略をどのように変更するかという問題を取り上げたとすると、実施方法を左右するものとなります。ビッグデータは企業家精神から利益を得られると同時に、具体的なゴールからも強力な利益が得られます。