Two months ago, we launched a preview release of Apache Spark 2.0 on Databricks. As you can see in the chart below, 10% of our clusters are already using this release, as customers experiment with the new features and give us feedback. Thanks to this experience, we are excited to be the first commercial vendor to support Spark 2.0.
Apache Spark Usage over Time by Version
Now, let’s dive into what’s new in Apache Spark 2.0.
Easier: ANSI SQL and Streamlined APIs
One thing we are proud of in Spark is APIs that are simple, intuitive, and expressive. Spark 2.0 continues this tradition, focusing on two areas: (1) standard SQL support and (2) unifying DataFrame/Dataset API.
On the SQL side, we have significantly expanded Spark’s SQL support, with the introduction of a new ANSI SQL parser and subqueries. Spark 2.0 can run all the 99 TPC-DS queries, which require many of the SQL:2003 features. Because SQL has been one of the primary interfaces to Spark, these extended capabilities drastically reduce the effort of porting legacy applications.
On the programmatic API side, we have streamlined Spark’s APIs:
- Unifying DataFrames and Datasets in Scala/Java: Starting in Spark 2.0, DataFrame is just a type alias for Dataset of Row. Both the typed methods (e.g.
map,filter,groupByKey) and the untyped methods (e.g.select,groupBy) are available on the Dataset class. Also, this new combined Dataset interface is the abstraction used for Structured Streaming. Since compile-time type-safety is not a feature in Python and R, the concept of Dataset does not apply to these language APIs. Instead, DataFrame remains the primary interface there, and is analogous to the single-node data frame notion in these languages. Get a peek fromthis notebook and this blog for the stories behind these APIs. - SparkSession: a new entry point that supersedes SQLContext and HiveContext. For users of the DataFrame API, a common source of confusion for Spark is which “context” to use. Now you can use SparkSession, which subsumes both, as a single entry point, asdemonstrated in this notebook. Note that the old SQLContext and HiveContext classes are still kept for backward compatibility.
- Simpler, more performant Accumulator API: We have designed a new Accumulator APIthat has a simpler type hierarchy and support specialization for primitive types. The old Accumulator API has been deprecated but retained for backward compatibility
- DataFrame-based Machine Learning API emerges as the primary ML API: With Spark 2.0, the spark.ml package, with its “pipeline” APIs, will emerge as the primary machine learning API. While the original spark.mllib package is preserved, future development will focus on the DataFrame-based API.
- Machine learning pipeline persistence: Users can now save and load machine learning pipelines and models across all programming languages supported by Spark. See this blog post for more details and this notebook for examples.
- Distributed algorithms in R: Added support for Generalized Linear Models (GLM), Naive Bayes, Survival Regression, and K-Means in R.
- User-defined functions (UDFs) in R: Added support for running partition level UDFs (dapply and gapply) and hyper-parameter tuning (lapply).
Faster: Apache Spark as a Compiler
According to our 2015 Spark Survey, 91% of users consider performance as the most important aspect of Apache Spark. As a result, performance optimizations have always been a focus in our Spark development. Before we started planning our contributions to Spark 2.0, we asked ourselves a question: Spark is already pretty fast, but can we push the boundary and make Spark 10X faster?
This question led us to fundamentally rethink the way we build Spark’s physical execution layer. When you look into a modern data engine (e.g. Spark or other MPP databases), majority of the CPU cycles are spent in useless work, such as making virtual function calls or reading/writing intermediate data to CPU cache or memory. Optimizing performance by reducing the amount of CPU cycles wasted in these useless work has been a long time focus of modern compilers.
Spark 2.0 ships with the second generation Tungsten engine. This engine builds upon ideas from modern compilers and MPP databases and applies them to Spark workloads. The main idea is to emit optimized code at runtime that collapses the entire query into a single function, eliminating virtual function calls and leveraging CPU registers for intermediate data. We call this technique “whole-stage code generation.”
To give you a teaser, we have measured the time (in nanoseconds) it takes to process a row on one core for some of the operators in Spark 1.6 vs. Spark 2.0. The table below shows the improvements in Spark 2.0. Spark 1.6 also included an expression code generation technique that is used in some state-of-the-art commercial databases, but as you can see, many operators became an order of magnitude faster with whole-stage code generation.
You can see the power of whole-stage code generation in action in this notebook, in which we perform aggregations and joins on 1 billion records on a single machine.
| primitive | Spark 1.6 | Spark 2.0 |
|---|---|---|
| filter | 15ns | 1.1ns |
| sum w/o group | 14ns | 0.9ns |
| sum w/ group | 79ns | 10.7ns |
| hash join | 115ns | 4.0ns |
| sort (8-bit entropy) | 620ns | 5.3ns |
| sort (64-bit entropy) | 620ns | 40ns |
| sort-merge join | 750ns | 700ns |
How does this new engine work on end-to-end queries? We did some preliminary analysis using TPC-DS queries to compare Spark 1.6 and Spark 2.0:
Beyond whole-stage code generation to improve performance, a lot of work has also gone into improving the Catalyst optimizer for general query optimizations such as nullability propagation, as well as a new vectorized Parquet decoder that improved Parquet scan throughput by 3X. Read this blog post for more detail on the optimizations in Spark 2.0.
Smarter: Structured Streaming
Spark Streaming has long led the big data space as one of the first systems unifying batch and streaming computation. When its streaming API, called DStreams, was introduced in Spark 0.7, it offered developers with several powerful properties: exactly-once semantics, fault-tolerance at scale, strong consistency guarantees and high throughput.
However, after working with hundreds of real-world deployments of Spark Streaming, we found that applications that need to make decisions in real-time often require more than just a streaming engine. They require deep integration of the batch stack and the streaming stack, interaction with external storage systems, as well as the ability to cope with changes in business logic. As a result, enterprises want more than just a streaming engine; instead they need a full stack that enables them to develop end-to-end “continuous applications.”
Spark 2.0 tackles these use cases through a new API called Structured Streaming. Compared to existing streaming systems, Structured Streaming makes three key improvements:
- Integrated API with batch jobs. To run a streaming computation, developers simply write a batch computation against the DataFrame / Dataset API, and Spark automaticallyincrementalizes the computation to run it in a streaming fashion (i.e. update the result as data comes in). This powerful design means that developers don’t have to manually manage state, failures, or keeping the application in sync with batch jobs. Instead, the streaming job always gives the same answer as a batch job on the same data.
- Transactional interaction with storage systems. Structured Streaming handles fault tolerance and consistency holistically across the engine and storage systems, making it easy to write applications that update a live database used for serving, join in static data, or move data reliably between storage systems.
- Rich integration with the rest of Spark. Structured Streaming supports interactive queries on streaming data through Spark SQL, joins against static data, and many libraries that already use DataFrames, letting developers build complete applications instead of just streaming pipelines. In the future, expect more integrations with MLlib and other libraries.
Spark 2.0 ships with an initial, alpha version of Structured Streaming, as a (surprisingly small!) extension to the DataFrame/Dataset API. This makes it easy to adopt for existing Spark users that want to answer new questions in real-time. Other key features include support for event-time based processing, out-of-order/delayed data, interactive queries, and interaction with non-streaming data sources and sinks.
We also updated the Databricks workspace to support Structured Streaming. For example, when launching a streaming query, the notebook UI will automatically display its status.
Streaming is clearly a broad topic, so stay tuned for a series of blog posts with more details on Structured Streaming in Apache Spark 2.0.
Conclusion
Spark users initially came to Apache Spark for its ease-of-use and performance. Spark 2.0 doubles down on these while extending it to support an even wider range of workloads. Enjoy the new release on Databricks.
Read More
You can also import the following notebooks and try them on Databricks Community Editionwith Spark 2.0.
- SparkSession: A new entry point
- Datasets: A more streamlined API
- Performance of whole-stage code generation
- Machine learning pipeline persistence
]]>
]]>
Druid功能介于PowerDrill?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">Dremel之间Q它几乎实现?jin)Dremel的所有功能，q且从PowerDrill吸收一些有的数据格式。Druid允许以类似Dremel和PowerDrill的方式进行单表查询，同时q增加了(jin)一些新Ҏ(gu)，如ؓ(f)局部嵌套数据结构提供列式存储格式、ؓ(f)快速过滤做索引、实时摄取和查询、高定w的分布式体系架构{。从官方得知QDruid的具有以下主要特征：(x)
- 为分析而设?/span>——Druid是ؓ(f)OLAP工作的探烦(ch)性分析而构建，它支持各U过滤、聚合和查询{类Q?/li>
- 快速的交互式查?/span>——Druid的低延迟数据摄取架构允许事g在它们创建后毫秒内可被查询到Q?/li>
- 高可用?/span>——Druid的数据在pȝ更新时依然可用，规模的扩大和~小都不?x)造成数据丢失Q?/li>
- 可扩?/span>——Druid已实现每天能够处理数十亿事g和TBU数据?/li>
- 快速的交互式查?/span>——Druid的低延迟数据摄取架构允许事g在它们创建后毫秒内可被查询到Q?/li>
Druid应用最多的是类gq告分析创业公司Metamarkets中的应用场景Q如q告分析、互联网q告pȝ监控以及(qing)|络监控{。当业务中出C下情冉|QDruid是一个很好的技术方案选择Q?/p>
- 需要交互式聚合和快速探I大量数据时Q?/li>
- 需要实时查询分析时Q?/li>
- h大量数据Ӟ如每天数亿事件的新增、每天数10T数据的增加；
- Ҏ(gu)据尤其是大数据进行实时分析时Q?/li>
- 需要一个高可用、高定w、高性能数据库时?/li>
一个Druid集群有各U类型的节点QNodeQ组成，每个节点都可以很好的处理一些的事情Q这些节点包括对非实时数据进行处理存储和查询?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">Historical节点、实时摄取数据、监听输入数据流?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">Realtime?/a>、监控Historical节点?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">Coordinator节点、接收来自外部客L(fng)的查询和查询{发到Realtime和Historical节点?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">Broker节点、负责烦(ch)引服务的Indexer节点?/p>
查询操作中数据流和各个节点的关系如下图所C：(x)
如下图是Druid集群的管理层架构Q该囑ֱCZ(jin)相关节点和集管理所依赖的其他组Ӟ如负责服务发现的ZooKeeper集群Q的关系Q?/p>
Druid已基?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">Apache License 2.0协议开源，代码托管?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">GitHubQ其当前最新稳定版本是0.7.1.1。当前，Druid已有63个代码A(ch)献者和近2000个关注。Druid的主要A(ch)献者包括广告分析创业公司Metamarkets、电(sh)影流媒体|站Netflix、Yahoo{公司。Druid官方q对Druid?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">Shark?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">Vertica?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">Cassandra?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">Hadoop?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">Spark?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">Elasticsearch{在定w能力、灵zL、查询性能{方便进行了(jin)Ҏ(gu)说明。更多关于Druid的信息，大家q可以参考官Ҏ(gu)供的入门教程?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">白皮?/a>?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">设计文档{?/p>
作者：(x)威?/p>
- 工程数据Q譬如工单数量，SLA可用性，基础资源Q故障率Q报警统?/strong>
- 业务数据Q譬如业务DashBoard,Trace调用链，业务拓扑切换Q业务指标，业务基准数据Q业务日志挖?/strong>
- 数据可视?/strong>
当然Q这文章谈的是q维都有哪些数据Q哪些指标，以及(qing)数据呈现。ƈ没有谈及(qing)如何和大数据相关的架构做整合Q从而能让这些数据真的变得活h?/p>
比较凑y的是Q原先百度的桑文峰的分n也讲到日志的多维度分析，吃完饭的时候，一位优L(fng)朋友也和我探讨了(jin)关于业务监控的的问题。而我之前发表在肉饼铺子里的一文章?大数据给公司带来?jin)什?》也特地提到?jin)大数据对于整个q维的帮助，当时因ؓ(f)q篇内容的主旨是|列大数据的用处Q自然没法细讲运l和大数据的整合q一块?/p>
上面的文字算引子Q在步入正式的探讨前Q有一Ҏ(gu)觉得值得Q?/p>
虽然q里讲的是如何将大数据思维/架构应用于运l_(d)q_化运l工作，但是和大数据本质上没有关p，我们只是大数据处理的方式和思想应用在运l工作上。所以，即你现在所在的公司没有数据团队支撑Q也是完全可以通过现有团队完成qg事情的?/p>
1 q维监控现状
很多公司的运l的监控h如下特质Q?/p>
只能监控基础q维层次Q通过zabbix{工h供服务器,CPU,内存{相关的监控。这部分重要Q但实不是q维的核?j)?/p>
对业务的监控是最复杂的，而现在很多公司的要么q处于Shell脚本的刀耕火U阶D，要么开发能力较强，但是q是东一榔头西一子Q不同的业务需要不同的监控pȝQh人都可以Ҏ(gu)的自qx(chng)开发一个监控的工具也好Q系l也好，q_也好。M是比较凌q?/p>
使用W三方的监控q_。这个似乎在Rails/NodeJS/Pythone相关语系开发的产品中比较常见。我不做q多评h(hun)Q用后h自知?/p>
当然也有抽象得很好的Q比如点评网的运l监控据说就做得相当好，q维很闲Q天天没事就Ҏ(gu)自己的监控找开发的茬，让开发持l改q。不q他们的指导思想主要有两个：(x)
q维自动化。怎么能够实现q个目标怎么搞，q严重依赖于搞的人的规划能力和经验?/p>
抽象化，Ҏ(gu)实际面(f)的问题做出抽象，得到对应的系l，比如需要发布，于是又发布系l，需要管理配|文Ӟ所以有配管pȝQ需要日志分析所以有?jin)有日志分析pȝ。然而这h比较零散的?/p>
有点扯远Q我们还是focus在监控上?/p>
如果以大数据的思维L考，我们应该如何做好监控qg事情?
2 |列Z的数据源
《大数据对于q维的意义》这文章也讲了(jin)Q主要有工程数据Q业务数据。所有的数据源都有一个共性，是 日志 。无论文本的也好Q二q制的也好。所以日志是整个信息的源头。日志包含的信息以让我们追查到下面几g事情Q?/p>
- pȝ健康状况监控
- 查找故障Ҏ(gu)
- pȝ瓉诊断和调?/strong>
- q踪安全相关问题
- 从日志我们可以挖掘出什?
我觉得抽象v来就一个：(x) 指标 ?/p>
指标可以再进行分c：(x)
业务层面Q如团购业务每秒讉K敎ͼ团购券每U验券数Q每分钟支付、创单等
应用层面Q每个应用的错误敎ͼ调用q程Q访问的q_耗时Q最大耗时Q?5U等
pȝ资源层面Q如cpu、内存、swap、磁盘、load、主q程存活{?/p>
|络层面Q?如丢包、ping存活、流量、tcpq接数等
每个分类里的每个点其实都是一个指标?/p>
3 如何l一实现
千万不要针对具体问题q行解决Q大数据架构上的一个思维是Q我能够提供一个^台让大家方便解决q些问题?sh)? 而不是，q个问题我能解决?
先来看看架构图：(x)
- 推荐
- 搜烦(ch)
- l一查询引擎
所以监控的架构设计略简单些。如果你希望q行日志存储以及(qing)事后扚w分析Q则可以采用淘宝的这套架构方式：(x)
日志过滤，格式化，或存储v?/p>
q行实时计算Q将指标数据存储到HBase里去
到目前ؓ(f)止，我们没有做Q何的开发，全部使用大数据里通用的一些组件。至于这些组仉要多服务器Q就看对应的日志量规模了(jin)Q三五台到几癑֏都是可以的?/p>
需要开发的地方只有两个点，有一个是一ơ性的Q有一个则是长期?/p>
先说说一ơ性的Q其实就是大盘展C系l。这个就是从HBase里取出数据做展示。这个貌g有开源的一套，ELK。不q底层不是用的HBase存储Q而是ES。这里就不详l讨论?/p>
长期的则是SparkStreaming(淘宝是用StormQ我用SparkStreaming,因ؓ(f)SparkStreaming可以按时间窗口，也可以按量统一做计?Q这里你需要定义日志的处理逻辑Q生成我上面提到的各Ҏ(gu)标?/p>
q里有一个什么好处呢Q就是^台化?jin)，?gu)的监控需求响应更快了(jin)Q开发到上线可能只要几个时的功夫。如果某个系l某天需要一个新的监控指标，我们只要开发个SparkStreamingE序Q丢到^台里去，q事q完了(jin)?/p>
W一q图的^台我是已l实C(jin)的。我目前在SparkStreaming上只做了(jin)三个斚w比较基础的监控，不过应该够用?jin)?/p>
状态码大盘?HTTP响应码的URL(Lquery参数)排行榜。比如你打开面可以看到发?00错误的top100的URLQ以?qing)该URL所归属的系l?/p>
响应耗时大盘?URLh耗时排行榜。比如你打开面可以看?分钟内^均响应耗时top100的URL(Lquery参数)?/p>
q有是Tracepȝ?cMGoogle的Dapper,淘宝的EagleEye。给Z个唯一的UUID,可以q踪到特定一个Request的请求链路。每个依赖服务的响应情况Q比如响应时间。对于一个由几个甚至几百个服务组成的大系l，意义非常大，可以方便的定位出到底是那个系l的哪个API的问题。这个最大的隄是需要统一底层的RPC/HTTP调用框架Q进行埋炏V因为我使用的是自研的ServiceFramework框架Q通讯埋点比较简单。如果是在一个业务线复杂Q各个系l用不同技术开发，惌做这块就要做好心(j)理准备了(jin)?/p>
现在Q如果你惌监控一个系l是不是存活Q你不在需要取写脚本去找他的pid看进E是不是存在Q系l发现在一定的周期内没有日志，可以认为它M(jin)。而系l如果有异常Q比如有大量的慢查询Q大盘(sh)定能展示出来?/p>
描述到这Q我们可以看刎ͼq套架构的优势在哪：(x)
基本上没有需要自己开发的pȝ。从日志攉Q到日志存储Q到l果存储{，l统都是现成的组件?/p>
可扩展性好。每个组仉是集模式的Q没有单Ҏ(gu)障。每个组仉是可水^扩展的，日志量大?jin)，加机器就好?/p>
开发更集中?jin)。你只要x(chng)日志实际的分析处理，提炼指标卛_?/p>
4 大数据思维
对于q维的监控，利用大数据思维Q需要分三步赎ͼ(x)
- 扑ֈ数据
- 分析定义从数据里中我能得C?/strong>
- 从大数据q_中挑(xi)选你要的lg完成搭积木式开?/strong>
所有系l最可靠的就是日志输出，pȝ是不是正常，发生?jin)什么情况，我们以前是出?jin)问题去查日志，或者自己写个脚本定时去分析。现在这些事情都可以整合C个已有的q_上，我们唯一要做的就?定义处理日志的的逻辑 ?/p>
q里有几Ҏ(gu)意的Q?/p>
如果你拥有复杂的产品U，那么日志格式?x)是一个很痛苦的事情。以中间Storm(或者SparkStreaming)的处理环节你需要做大量的兼定w配。我个h的意见是Q第一Q没有其他更好的办理Q去兼容适配吧，W二Q推动大家统一日志格式。两件事情一起做。我一个月做不完，那我用两q时间行?L一天大安?x)有l一的日志格式的?/p>
如果你的研发能力有富?或者有大数据团队支撑，那么可以进入到SparkStreaming中的数据存储hQ然后通过SparkSQL{做卛_查询。这P有的时候原先没有考虑的指标，你可以直接基于日志做多维度分析。分析完?jin)，你觉得好了(jin)，需要固化下来，那再LC的SparkStreamingE序?/p>
后话
我做上面W一q图架构实现Ӟ从搭建到完成SparkStreamingE序开发，到数据最后进入HBase存储Q大概只׃(jin)一天多的时间。当然ؓ(f)?jin)完成那个Trace的指标分析，我修改ServiceFramework框架大约改了(jin)两三天。因为Trace分析实比较复杂。当然还有一个比较消耗工作量的，是页面可视化Q我q块自己q没有能力做Q等招个Web开发工E师再说?jin)?/p>
End.
]]>
InfoQQ?/strong>请问CarbonData是什么时候开始进行的目Qؓ(f)什么现在向Apache孵化器开源呢Q开源发展历E和目目前状态是怎么L(fng)Q?/p>
CarbonDataQ?/span>CarbonData目是华为公总?wbr style="margin: 0px; padding: 0px; max-width: 100%; box-sizing: border-box !important; word-wrap: break-word !important;">q数据处理经验和行业理解中逐步U篏h的，2015q我们对p?wbr style="margin: 0px; padding: 0px; max-width: 100%; box-sizing: border-box !important; word-wrap: break-word !important;">l进行了(jin)一ơ架构重构，使其演化为HDFS上的一套通用的列式存
储，支持和Spark引擎Ҏ(gu)后Ş成一套分布式OLAP分析的解 x(chng)案?/p> 华ؓ(f)一直是面向?sh)信、金融、IT企业{用h供大数据q_解决Ҏ(gu)的供应商Q从众多客户场景中我们不断提炼数据特征，ȝZ(jin)一些典型的对大数据分析的诉求，逐步形成?jin)CarbonDataq个架构?/p>
因ؓ(f)在IT领域Q只有开源开放，才能最l让更多的客户和合作伙伴的数据连接在一P产生更大商业价倹{?strong style="margin: 0px; padding: 0px; max-width: 100%; box-sizing: border-box !important; word-wrap: break-word !important;">开源是Z(jin)构徏E2E生态，CarbonData是数据存储层技术，要发挥h(hun)|需要与计算层、查询层有效集成在一P形成完成真正的生态发挥h(hun)倹{?/strong>
又因为Apache是目前大数据领域最权威的开源组l，其中的HadoopQSpark已成为大数据开源的事实标准Q我们也非常认可Apache以Community驱动技术进步的理念Q所以我们选择q入ApacheQ与C一同构力，使CarbonData融入大数据生态?/p>
目前CarbonData开源项目已l在6?日通过ApacheC投票Q成功进入Apache孵化器。github地址Qhttps://github.com/apache/incubator-carbondata。欢q大家参与到Apache CarbonDataCQ?https://github.com/apache/incubator-carbondata/blob/master/docs/How-to-contribute-to-Apache-CarbonData.md?/p>
InfoQQ?/span>请问是什么原因或机遇?j)?zhn)们产生做CarbonDataq个目的想法的Q之前的目中遇C么样的困难？
CarbonDataQ?/span>我们一直面临着很多高性能数据分析诉求Q在传统的做法里Q一般是使用数据库加BI工具实现报表、DashBoard和交互式查询{业务，但随着企业数据日益增大Q业务驱动的分析灉|性要求逐渐增大Q也有部分客户希望有除SQL外更强大的分析功能，所以传l的方式渐渐满不了(jin)客户需求，让我们生了(jin)做CarbonDataq个目的想法?/p>
需求一般来源于几方面?/p>
W一Q在部v?/strong>Q区别于以往的单机系l，企业客户希望有一套分布式Ҏ(gu)来应Ҏ(gu)益增多的数据Q随时可以通过增加通用服务器的方式scale out横向扩展?/p>
W二Q在业务功能?/strong>Q很多企业的业务都处在从传统数据库逐渐转移到大数据q_的迁U过E中Q这p求大数据q_要有较高兼容老业务的能力Q这里面主要包含的是对完整的标准SQL支持Q以?qing)多U分析场景的支持。同时ؓ(f)?jin)节U成本，企业希望“一份数据支持多U用场?#8221;Q例如大规模扫描和计的批处理场景，OLAP多维交互式分析场景，明细数据卛_查询Q主键低时gҎ(gu)Q以?qing)对实时数据的实时查询等场景Q都希望q_能给予支持，且达到秒U查询响应?/p>
W三Q在易用性上Q企业客户以往使用BI工具Q业务分析的OLAP模型是需要在BI工具中徏立的Q这׃(x)D有的场景下数据模型的灉|性和分析手段受到限制Q而在大数据时代，大数据开源领域已lŞ成了(jin)一个生态系l，C随时都在q步Q经怼(x)冒出一些新型的分析工具Q所以企业客户都希望能跟随社Z断改q自qpȝQ在自己的数据里快速用上新型的分析工具Q得到更大的商业价倹{?/p>
要同时达C诉要求，无疑对大数据q_是一个很大的?xi)战。ؓ(f)?jin)满些要求，我们开始不断在实际目中积累经验，也尝试了(jin)很多不同的解x(chng)案，但都没有发现能用一套方案解x(chng)有问题?/p>
大家首先?x)想到的是，在涉及(qing)到低时延查询的分布式存储中Q?strong style="margin: 0px; padding: 0px; max-width: 100%; box-sizing: border-box !important; word-wrap: break-word !important;">一般常用的是KV型NoSQL数据库（如HBaseQCassandraQ?/strong>Q可以解决主键低时g查询的问题，但如果业务的查询模式E作改变Q例如对多维度灵zȝ合的查询Q就?x)?gu)变(sh)ؓ(f)全表扫描Q性能急剧下降。有的场景下Q这时可以通过加入二索引来缓解该问题Q但q又带来?jin)二U烦(ch)引的l护和同步等理问题Q所以KV型存储ƈ不是解决企业问题的通用Ҏ(gu)?/p>
那么Q如果要解决通用的多l查询问题，?strong style="margin: 0px; padding: 0px; max-width: 100%; box-sizing: border-box !important; word-wrap: break-word !important;">时我们会(x)惛_用多l时序数据库的方案（如Linkedin PinotQ?/strong>Q他们的特点是数据都以时间序列的方式q入pȝq经q数据预聚合和徏立烦(ch)引，因ؓ(f)是预计算Q所以应对多l查询时非常快，数据也非常及(qing)Ӟ同时具备多维分析和实时处理的优点Q在性能监控、实时指标分析的场景里应用较多。但它在支持的查询类型上也有一定限Ӟ因ؓ(f)做了(jin)数据预计，所以这U架构一般无法应Ҏ(gu)l数据查询，以及(qing)不支持Join多表兌分析Q这无疑l企业用场景带来了(jin)一定的限制?/p>
另外一cL搜烦(ch)pȝQ如Apache SolrQElasticSearchQ?/strong>Q搜索系l可以做多维汇M可以查询明细数据Q它也具备基于倒排索引的快速布?yu)(dng)查询，q发也较高，g正是我们希望L的方案。但在实际应用中我们发现两个问题Q?strong style="margin: 0px; padding: 0px; max-width: 100%; line-height: 1.75em; box-sizing: border-box !important; word-wrap: break-word !important;">一?/strong>׃搜烦(ch)pȝ一般是针对非结构化数据而设计的Q系l的数据膨胀率一般都比较高，在企业关pd数据模型下数据存储不够紧凑，造成数据量较大，二是搜烦(ch)pȝ的数据组l方式和计算引擎密切相关Q这导致了(jin)数据入库后只能用相应的搜索引擎处理，q又一定程度打破了(jin)企业客户希望应用多种C分析工具的初P所以搜索系l也有他自己的适用场景?/span>
最后一cȝl，是目前C里大量涌现的SQL on HadoopҎ(gu)Q以Hive, SparkSQL, FlinkZ?/strong>Q这cȝl的特点是计和存储相分，针对存储在HDFS上的文g提供标准SQL功能Q他们在部v性和易用性上可以满企业客户需求，业务场景上也能覆盖扫描，汇聚Q详单等各类场景Q可见可以将他们视ؓ(f)一c通用的解x(chng)案。ؓ(f)?jin)提高性能QSparkQFlink{开源项目通过不断优化自n架构提升计算性能Q但提升重点都放在计引擎和SQL优化器的增强上，在存储和数据l织上改qƈ不是重点?/p>
所以，可以看出当前的很多大数据pȝ虽然都能支持各类查询场景Q但他们都是偏向某一cd景设计的Q在不是其目标场景的情况下要么不支持要么退化ؓ(f)全表扫描Q所以导致企业ؓ(f)?jin)应?gu)处理Q多l分析，明细数据查询{场景，客户常常需要通过复制多䆾数据Q每U场景要l护一套数据?/p>
CarbonData的设计初h是ؓ(f)?jin)打破这U限Ӟ做到只保存(sh)份数据，最优化地支撑多U用场?/strong>?/strong>
InfoQ:能否具体谈谈CarbonData的技术架构？有何特征和优势呢Q?/p>
CarbonDataQ?/strong>整个大数据时代的开启，可以说是源自于Google的MapReduce论文Q他引发?jin)Hadoop开源项目以?qing)后l一pd的生态发展。他?#8220;伟大”之处在于计算和存储解耦的架构Q企业的部分业务（主要是批处理Q从传统的垂直方案中解放出来Q计和存储可以按需扩展极大提升?jin)业务发展的敏捷性，让众多企业普?qing)?jin)q一计算模式Q从中受益?/p>
虽然MapReduce开启了(jin)大数据时代，但它是通过Ua(b)的暴力扫?分布式计来提升批处理性能Q所以ƈ不能解决客户Ҏ(gu)有查询场景的低时延查?/strong>要求?/p>
在目前的生态中Q最接近于客戯求的其实是搜索引擎类Ҏ(gu)。通过良好的数据组l和索引Q搜索引擎能提供多种快速的查询功能Q但偏偏搜烦(ch)引擎的存储层又和计算引擎?strong style="margin: 0px; padding: 0px; max-width: 100%; box-sizing: border-box !important; word-wrap: break-word !important;">紧耦合
的，q不W合企业?#8221;一份数据，多种场景”的期望?/span>q给?jin)我们启发，我们何不为通用计算引擎打造更一个高效的数据l织来满_户需求呢Q做到既利用计算和存储解耦架构又能提供高性能查询。抱着q个x(chng)Q我们启动了(jin)CarbonData目。针Ҏ(gu)多的业务Q计算和存储相分离Q这也成?jin)CarbonData?strong style="margin: 0px; padding: 0px; max-width: 100%; box-sizing: border-box !important; word-wrap: break-word !important;">架构设计理念?/span>
立?jin)这个理念后Q我们很自然地选择?strong style="margin: 0px; padding: 0px; max-width: 100%; box-sizing: border-box !important; word-wrap: break-word !important;">ZHDFS+通用计算引擎的架?/strong>Q因个架构可以很好地提供Scale out能力。下一步我们问自己q个架构里还~Z么？q个架构中，HDFS提供文g的复制和d能力Q计引擎负责读取文件和分布式计，分工很明，可以说他们分别定位于解决存储理和计的问题?span style="margin: 0px; padding: 0px; max-width: 100%; line-height: 1.75em; box-sizing: border-box !important; word-wrap: break-word !important;">但不隄出，Z(jin)适应更多场景QHDFS做了(jin)很大?#8220;牺牲”Q它牺牲?jin)对文g内容的理解，正是׃攑ּ?jin)对文g内容的理解，D计算只能通过全扫描的方式来进行，可以说最l导致的是存储和计算都无法很好的利用数据特征来做优化?/span>
所以针对这个问题，我们把CarbonData?strong style="margin: 0px; padding: 0px; max-width: 100%; box-sizing: border-box !important; word-wrap: break-word !important;">发力重点攑֜Ҏ(gu)据组l的优化上，通过数据l织最l是要提升IO性能和计性能。ؓ(f)此，CarbonData做了(jin)如下工作?/p>
CarbonData基础Ҏ(gu)?/strong>
1. 多维数据聚集Q?/strong>在入库时Ҏ(gu)据按多个l度q行重新l织Q数据?#8220;多维I间上更内聚”Q在存储上获得更好的压羃率，在计上获得更好的数据过滤效率?/p>
2. 带烦(ch)引的列存文gl构Q?/strong>首先QCarbonData为多cd景设计了(jin)多个U别的烦(ch)引，q融入了(jin)一些搜索的Ҏ(gu)，有跨文g的多l烦(ch)引，文g内的多维索引Q每列的minmax索引Q以?qing)列内的倒排索引{。其ơ，Z(jin)适应HDFS的存储特点，CarbonData的烦(ch)引和数据文g存放在一P一部分索引本n是数据Q另一部分索引存放在文件的元数据结构中Q他们都能随HDFS提供本地化的讉K能力?/p>
3. 列组Q?/strong>整体上，CarbonData是一U列存结构，但相对于行存来说Q列存结构在应对明细数据查询时会(x)有数据还原代价高的问题，所以ؓ(f)?jin)提升明显数据查询性能QCarbonData支持列组的存储方式，用户可以把某些不怽滤条件但又需要作为结果集q回的字D作为列l来存储Q经qCarbonData~码后会(x)这些字D用行存的方式来存储以提升查询性能?/p>
4. 数据cdQ?/strong>目前CarbonData支持所有数据库的常用基本类型，以及(qing)ArrayQStruct复杂嵌套cd。同时社Z有h提出支持Map数据cdQ我们计划未来添加Map数据cd?/p>
5. 压羃Q?/strong>目前CarbonData支持Snappy压羃Q压~是针对每列分别q行的，因ؓ(f)列存的特点得压~非帔R效。数据压~率Z应用场景不同一般在2?之间?/p>
6. Hadoop集成Q?/strong>通过支持InputFormat/OutputFormat接口QCarbonData可以利用Hadoop的分布式优点Q也能在所有以Hadoop为基的生态系l中使用?/p>
CarbonData高Ҏ(gu)?/strong>
1. 可计的~码方式Q?/strong>除了(jin)常见的DeltaQRLEQDictionaryQBitPacking{编码方式外QCarbonDataq支持将多列q行联合~码Q以?qing)应用?jin)全局字典~码来实现免解码的计，计算框架可以直接使用l过~码的数据来做聚合，排序{计，q对需要大量shuffle的查询来说性能提升非常明显?/p>
2. 与计引擎联合优化：(x)Z(jin)高效利用CarbonDatal过优化后的数据l织QCarbonData提供?jin)有针对性的优化{略Q目前CarbonDataC首先做了(jin)和Spark的深度集成，其中ZSparkSQL框架增强?jin)过滤下压，延迟物化Q增量入库等Ҏ(gu)，同时支持所有DataFrame API。相信未来通过C的努力，?x)有更多的计框架与CarbonData集成Q发挥数据组l的价倹{?/p>
目前q些Ҏ(gu)都已经合入Apache CarbonDatadQ欢q大家用?/p>
InfoQQ?/strong>在哪些场景推荐用呢Q性能试l果如何Q有没有应用案例Q目前在国内的用情况和用户规模Q?/p>
CarbonDataQ?/span>推荐场景Q?wbr style="margin: 0px; padding: 0px; max-width: 100%; color: #3e3e3e; font-family: 微Y雅黑, sans-serif; font-size: 12px; line-height: 28px; white-space: normal; box-sizing: border-box !important; word-wrap: break-word !important;">希望一份存储同时满_速扫描，多维分析Q明l数据查询的场景?wbr style="margin: 0px; padding: 0px; max-width: 100%; box-sizing: border-box !important; word-wrap: break-word !important;">在华为的客户使用案例中，Ҏ(gu)业界已有的列存方案，Carbon
Data可以带来5~30倍性能提升?/p> 性能试数据?qing)应用案例等更多信息Q请x(chng)微信公众号ApacheCarbonDataQ及(qing)Chttps://github.com/apache/incubator-carbondata?/p>
InfoQQ?/strong>CarbonData能和当前正火的Spark完美l合吗？q能兼容哪些L框架呢？
CarbonDataQ?/strong>目前CarbonData已与Spark做了(jin)深度集成Q具体见上述高Ҏ(gu)?/p>
InfoQQ?/strong>(zhn)们的项目在未来有什么样的发展规划？q(sh)(x)增加什么功能吗Q如何保证开源之后的目的持l维护工作呢Q?/p>
CarbonDataQ?/span>接下来社区重点工作是Q提升系l易用性、完善生态集成（如：(x)与Flink,Kafka{集成，实现数据实时导入CarbonDataQ?/p>
CarbonData开源的W一个月Q就有几百个commits提交Q和20多个贡献者参与，所以后l这个项目会(x)持箋(hu)的活跃?0多个核心(j)贡献者也会(x)持箋(hu)参与C?/p>
InfoQQ?/span>在CarbonData设计研发q进入Apache孵化器的q程中，l历?jin)哪些阶D，l历q的最大困难是什么？有什么样的感受或l验可以和大家分享的吗？
CarbonDataQ?/span>CarbonData团队大多Ch都有参与Apache Hadoop、Spark{社区开发的l验Q我们对C程和工作方式都很熟(zhn)。最大的困难是进入孵化器阶段Q去说服ApacheC接纳大数据生态新的高性能数据格式CarbonData。我们通过5月䆾在美国奥斯丁的开源盛?x)OSCON上，做CarbonData技术主题演讲和现场DEMO演示Q展CZ(jin)CarbonData优秀的架构和良好的性能效果?/p>
InfoQQ?/span>(zhn)们是一个团队吗Q如何保证?zhn)们团队的优秀成长Q?/p>
CarbonDataQ?/span>CarbonData团队是一个全球化的（工程师来自中国、美国、印度）(j)团队Q这U全球化工作模式的经验积累，让我们能快速的适应Apache开源社区工作模式?/p>
采访嘉宾Q?/strong>Apache CarbonData的PMC、Committers李昆、陈亮?/p>
]]>
]]>
Elasticsearch?a target="_blank" style="margin: 0px; padding: 0px; color: #258fb8; text-decoration: none; outline-width: 0px;">*
Elasticsearch是一?span style="margin: 0px; padding: 0px;">实时?span style="margin: 0px; padding: 0px;">分布式搜索和分析引擎。它可以帮助你用前所未有的速度d理大规模数据?/span>
它可以用?span style="margin: 0px; padding: 0px;">全文搜烦(ch)Q?span style="margin: 0px; padding: 0px;">l构化搜索以?span style="margin: 0px; padding: 0px;">分析Q当然你也可以将q三者进行组合?/span>
Elasticsearch是一?span style="margin: 0px; padding: 0px;">建立在全文搜索引?Apache Lucene™ 基础上的搜烦(ch)引擎Q可以说Lucene是当今最先进Q最高效的全功能开源搜索引擎框架?/span>
但是Lucene只是一个框Ӟ要充分利用它的功能，需要用JAVAQƈ且在E序中集成Lucene。需要很多的学习(fn)?jin)解Q才能明白它是如何运行的QLucene实非常复杂?/p>
Elasticsearch使用Lucene作ؓ(f)内部引擎Q但是在使用它做全文搜烦(ch)Ӟ只需要用统一开发好的API卛_Q而不需要了(jin)解其背后复杂的Lucene的运行原理?/p>
当然Elasticsearchq不仅仅是Luceneq么单，它不但包括了(jin)全文搜烦(ch)功能Q还可以q行以下工作:
分布式实时文件存储，q将每一个字D都~入索引Q其可以被搜烦(ch)?/p>
实时分析的分布式搜烦(ch)引擎?/p>
可以扩展C癑֏服务器，处理PBU别的结构化或非l构化数据?/p>
q么多的功能被集成到一台服务器上，你可以轻村֜通过客户端或者Q何你喜欢的程序语a与ES的RESTful APIq行交流?/p>
Elasticsearch?span style="margin: 0px; padding: 0px;">上手是非常简单的。它附带?jin)很?span style="margin: 0px; padding: 0px;">非常合理的默认|q让初学者很好地避免一上手p面对复杂的理论，
它安装好?jin)就可以使用了(jin)，?span style="margin: 0px; padding: 0px;">很小的学?fn)成本就可以变得很有生力?/span>
随着学深入，q可以利用Elasticsearch更多高的功能，整个引擎可以很灵zdq行配置。可以根据自w需求来定制属于自己的Elasticsearch?/p>
使用案例Q?/p>
l基癄使用Elasticsearch来进行全文搜做ƈ高(sh)昄关键词，以及(qing)提供search-as-you-type、did-you-mean{搜索徏议功能?/p>
英国卫报使用Elasticsearch来处理访客日志，以便能将公众对不同文章的反应实时地反馈给各位~辑?/p>
StackOverflow全文搜索与地理位置和相关信息进行结合，以提供more-like-this相关问题的展现?/p>
GitHub使用Elasticsearch来检索超q?300亿行代码?/p>
每天QGoldman Sachs使用它来处理5TB数据的烦(ch)引，q有很多投行使用它来分析股票?jng)场的变动?/p>
但是Elasticsearchq不只是面向大型企业的，它还帮助?jin)很多类似DataDog以及(qing)Klout的创业公司进行了(jin)功能的扩展?/p>
Elasticsearch的优~点**:
优点
- Elasticsearch是分布式的。不需要其他组Ӟ分发是实时的Q被叫做”Push replication”?/li>
- Elasticsearch 完全支持 Apache Lucene 的接q实时的搜烦(ch)?/li>
- 处理多租PmultitenancyQ不需要特D配|，而Solr则需要更多的高讄?/span>
- Elasticsearch 采用 Gateway 的概念，使得完备份更加简单?/li>
- 各节点组成对{的|络l构Q某些节点出现故障时?x)自动分配其他节点代替其q行工作?/li>
~点
- 只有一名开发者（当前Elasticsearch GitHubl织已经不只如此Q已l有?jin)相当活跃的l护者）(j)
- q(sh)够自动（不适合当前新的Index Warmup APIQ?/li>
Solr?a target="_blank" style="margin: 0px; padding: 0px; color: #258fb8; text-decoration: none; outline-width: 0px;">*
SolrQ读?#8220;solar”Q是Apache Lucene目的开源企业搜索^台。其主要功能包括全文(g)索?span style="margin: 0px; padding: 0px;">命中标示?span style="margin: 0px; padding: 0px;">分面搜烦(ch)?span style="margin: 0px; padding: 0px;">动态聚cR?span style="margin: 0px; padding: 0px;">数据库集成，以及(qing)富文本（如Word、PDFQ的处理。Solr?span style="margin: 0px; padding: 0px;">高度可扩展的Qƈ提供?span style="margin: 0px; padding: 0px;">分布式搜索和索引复制。Solr?span style="margin: 0px; padding: 0px;">最行的企业搜烦(ch)引擎QSolr4 q增加了(jin)NoSQL支持?/span>
Solr是用Java~写、运行在Servlet容器Q如 Apache Tomcat 或JettyQ的一个独立的全文搜烦(ch)服务器?Solr采用?Lucene Java 搜烦(ch)库ؓ(f)核心(j)的全文烦(ch)引和搜烦(ch)QƈhcMREST的HTTP/XML和JSON的API。Solr强大的外部配|功能得无需q行Java~码Q便可对 其进行调整以适应多种cd的应用程序。Solr有一个插件架构，以支持更多的高定制?/p>
因ؓ(f)2010q?Apache Lucene ?Apache Solr 目合ƈQ两个项目是由同一个Apache软g基金?x)开发团队制作实现的。提到技术或产品ӞLucene/Solr或Solr/Lucene是一L(fng)?/p>
Solr的优~点
优点
- Solr有一个更大、更成熟的用戗开发和贡献者社区?/li>
- 支持d多种格式的烦(ch)引，如：(x)HTML、PDF、微?Office pd软g格式以及(qing) JSON、XML、CSV {纯文本格式?/li>
- Solr比较成熟、稳定?/li>
- 不考虑建烦(ch)引的同时q行搜烦(ch)Q速度更快?/li>
~点
- 建立索引Ӟ搜烦(ch)效率下降Q实时烦(ch)引搜索效率不高?/li>
Elasticsearch与Solr的比?a target="_blank" style="margin: 0px; padding: 0px; color: #258fb8; text-decoration: none; outline-width: 0px;">*
当单U的对已有数据进行搜索时QSolr更快?/p>
当实时徏立烦(ch)引时, Solr?x)生iodQ查询性能较差, Elasticsearchh明显的优ѝ?/p>
随着数据量的增加QSolr的搜索效率会(x)变得更低Q而Elasticsearch却没有明昄变化?/p>
lg所qͼSolr的架构不适合实时搜烦(ch)的应用?/p>
实际生环境试*
下图为将搜烦(ch)引擎从Solr转到Elasticsearch以后的^均查询速度有了(jin)50倍的提升?/p>
Elasticsearch ?Solr 的比较ȝ
- 二者安装都很简单；
- Solr 利用 Zookeeper q行分布式管理，?Elasticsearch 自n带有分布式协调管理功?
- Solr 支持更多格式的数据，?Elasticsearch 仅支持json文g格式Q?/li>
- Solr 官方提供的功能更多，?Elasticsearch 本n更注重于核心(j)功能Q高U功能多有第三方插g提供Q?/li>
- Solr 在传l的搜烦(ch)应用中表现好?ElasticsearchQ但在处理实时搜索应用时效率明显低于 Elasticsearch?/li>
Solr 是传l搜索应用的有力解决Ҏ(gu)Q但 Elasticsearch 更适用于新兴的实时搜烦(ch)应用?/p>
其他ZLucene的开源搜索引擎解x(chng)?a target="_blank" style="margin: 0px; padding: 0px; color: #258fb8; text-decoration: none; outline-width: 0px;">*
- 直接使用 Lucene
说明QLucene 是一?JAVA 搜烦(ch)cdQ它本nq不是一个完整的解决Ҏ(gu)Q需要额外的开发工作?/p>
优点Q成熟的解决Ҏ(gu)Q有很多的成功案例。apache 目Q正在持l快速的q步。庞大而活跃的开发社区，大量的开发h员。它只是一个类库，有够的定制和优化空_(d)(x)l过单定Ӟ可以满绝大部分常见的需求；l过优化Q可以支?10? 量的搜索?/p>
~点Q需要额外的开发工作。所有的扩展Q分布式Q可靠性等都需要自己实玎ͼ非实Ӟ从徏索引到可以搜索中间有一个时间gq，而当前的“q实?#8221;(Lucene Near Real Time search)搜烦(ch)Ҏ(gu)的可扩展性有待进一步完?/p>
说明Q基?Lucene 的，支持分布式，可扩展，h定w功能Q准实时的搜索方案?/p>
优点Q开即用，可以?Hadoop 配合实现分布式。具备扩展和定w机制?/p>
~点Q只是搜索方案，建烦(ch)引部分还是需要自己实现。在搜烦(ch)功能上，只实C(jin)最基本的需求。成功案例较?yu)，目的成熟度E微差一些。因为需要支持分布式Q对于一些复杂的查询需求，定制的难度会(x)比较大?/p>
说明QMap/Reduce 模式的，分布式徏索引Ҏ(gu)Q可以跟 Katta 配合使用?/p>
优点Q分布式建烦(ch)引，具备可扩展性?/p>
~点Q只是徏索引Ҏ(gu)Q不包括搜烦(ch)实现。工作在批处理模式，对实时搜索的支持不佳?/p>
说明Q基?Lucene 的一pd解决Ҏ(gu)Q包?准实时搜?zoie Qfacet 搜烦(ch)实现 bobo Q机器学?fn)算?decomposer Q摘要存储库 krati Q数据库模式包装 sensei {等
优点Q经q验证的解决Ҏ(gu)Q支持分布式Q可扩展Q丰富的功能实现
~点Q与 linkedin 公司的联pd紧密Q可定制性比较差
说明Q基?LuceneQ烦(ch)引存?cassandra 数据库中
优点Q参?cassandra 的优?/p>
~点Q参?cassandra 的缺炏V另外，q只是一?demoQ没有经q大量验?/p>
说明Q基?LuceneQ烦(ch)引存?HBase 数据库中
优点Q参?HBase 的优?/p>
~点Q参?HBase 的缺炏V另外，在实CQlucene terms 是存成行Q但每个 term 对应?posting lists 是以列的方式存储的。随着单个 term ?posting lists 的增大，查询时的速度受到的媄(jing)响会(x)非常?/p>
转蝲Qhttp://blog.csdn.net/jameshadoop/article/details/44905643
]]>
2015q_(d)整个IT技术领域发生了(jin)许多深刻而又复杂的变化，InfoQ{划?#8220;解读2015”q终技术盘点系列文章，希望能够l读者清晰地梳理出技术领域在q一q的发展变化Q回过去，l箋(hu)前行?/p>
本文是大数据解读，在这文章里我们回?015展望2016Q看看过ȝ一q里q受x(chng)的技术有哪些q展Q了(jin)解下数据U学家这个职业的火热?nbsp;在关键技术进展部分我们在大数据生态圈众多技术中选取?jin)Hadoop、Spark、Elasticsearch和Apache Kylin四个点，分别请了(jin)四位专家QHulu的董西成、明略数据的梁堰波?span style="margin: 0px; border: 0px; padding: 0px; line-height: 20.8px;">_U技的卢争K、eBay的韩卿，来ؓ(f)大家解读2015里的q展?/p>
回顾2015q的关键技术进展：(x)
HadoopQ?/span>
Hadoop作ؓ(f)大数据^C最基础与重要的pȝQ在2015q提高稳定性的同时Q发布了(jin)多个重要功能与特性，q得Hadoop朝着多类型存储介质和异构集群的方向迈q了(jin)一大步?/p>
- HDFS
HDFS 之前是一个以盘单存储介质ؓ(f)ȝ分布式文件系l。但随着q几q新存储介质的兴P支持多存储介质早提上了(jin)日程。如今，HDFS 已经对多存储介质有了(jin)良好的支持，包括 Disk、Memory ?nbsp;SSD {，对异构存储介质的支持Q?nbsp;HDFS 朝着异构混合存储方向发展。目前HDFS支持的存储介质如下：(x)
ARCHIVEQ高存储密度但耗电(sh)较少的存储介质，通常用来存储h据?/p>
DISKQ磁盘(sh)质，q是HDFS最早支持的存储介质?/p>
SSDQ固态硬盘，是一U新型存储介质，目前被不互联网公司使用?/p>
RAM_DISK Q数据被写入内存?sh)，同时会(x)往该存储介质中再（异步Q写一份?/p>
- YARN
YARN作ؓ(f)一个分布式数据操作pȝQ主要作用是资源理和资源调度。在q去一q_(d)YARN新增?jin)包括基于标{调度、对长服务的支持、对 Docker 的支持等多项重大功能?/p>
Z标签的调度，使得 YARN 能够更好地支持异构集调度。它的基本思想是，通过打标{方式Z同的节点赋予不同的属性，q样Q一个大的Hadoop集群按照节点cd被分成了(jin)若干个逻辑上相互独立（可能交叉Q的集群。这U集跟物理上独立的集群很不一P用户可以很容易地通过动态调?nbsp;labelQ实C同类型节Ҏ(gu)目的增减Q这h很好的灵zL?/p>
寚w服务的支持，使得YARN逐渐变(sh)ؓ(f)一个通用资源理和调度系l。目前，YARN既支持像cM MapReduceQSpark 的短作业Q也支持cM Web ServiceQMySQL q样的长服务?nbsp;支持长服务是非常隄一件事情，YARN 需要解决以下问题：(x)服务注册、日志滚动、ResourceManager HA、NodeManager HAQNM 重启q程中，不媄(jing)?nbsp;ContainerQ和 ApplicationMaster 怸停止Q重启后接管之前?nbsp;Container。截?.7.0版本Q以上问题都已经得到?jin)比较完整的解决?/p>
对Docker的支持，使得YARN能够Z层应用提供更好的打包、隔dq行方式。YARN通过引入一U新的ContainerExecutorQ即DockerContainerExecutorQ实C(jin)对Docker的支持，但目前仍然是alpha版本Q不在生产环境中使用?/p>
- HBase
?nbsp;2015 q_(d)HBase q来?jin)一个里E碑——HBase 1.0 releaseQ这也代表着 HBase 走向?jin)稳定?nbsp;HBase新增Ҏ(gu)包括：(x)更加清晰的接口定义，?nbsp;Region 副本以支持高可用读，Family _度?nbsp;Flush以及(qing)RPC d队列分离{?/p>
SparkQ?/span>
2015q的Spark发展很快QJIRA数目和PR数目都突破了(jin)10000Qcontributors数目过?000Q可以说是目前最火的开源大数据目。这一qSpark发布?jin)多个版本，每个版本都有一些亮点：(x)
- 2014q?2月，Spark 1.2发布引入ML pipeline作ؓ(f)机器学习(fn)的接口?/li>
- 2015q?月，Spark 1.3发布引入?jin)DataFrame作ؓ(f)Spark的一个核?j)组件?/li>
- 2015q?月，Spark 1.4发布引入R语言作ؓ(f)Spark的接口。R语言接口在问世一个多月之后的调查中就?8%的用户用?/li>
- 2015q?月，Spark 1.5发布。Tungsten目W一阶段的出合q入DataFrame的执行后端，DataFrame的执行效率得到大q提升?/li>
- 2016q?月，Spark 1.6发布引入Dataset接口?/li>
Spark目前支持四种语言的接口，除了(jin)上面提到的R语言的用率以外QPython的用率也有很大提升Q从2014q的38%提升?015q的58%Q而Scala接口的用率有所下降Q从84%下降?1%。同时Spark的部|环境也有所变化Q?1%的部|在公有云上Q?8% 使用standalone方式部vQ而在YARN上的只有40%?jin)。可见Spark已经越HadoopQŞ成了(jin)自己的生态系l。而在形成Spark生态系l中起到关键作用的一个feature是外部数据源支持，Spark可以接入各种数据源的数据Q然后把数据导入Spark中进行计、分析、挖掘和机器学习(fn)Q然后可以把l果在写出到各种各样的数据源。到目前为止Spark已经支持非常多的外部数据源，像Parquet/JSON/CSV/JDBC/ORC/HBase/Cassandra/Mongodb{等?/p>
上面q些调查数据来自国Q中国的情况有所区别Q但是还是有一定的借鉴意义的。国内的Spark应用也越来越多：(x)腾讯的Spark规模C(jin)8000+节点Q日处理数据1PB+。阿里巴巴运行着目前最长时间的Spark JobQ?PB+数据规模的Spark Job长达1周的旉。百度的谷研究院也在探索Spark+Tachyon的应用场景?/p>
Spark MLlib的ALS法已经在很多互联网公司用于其推荐系l中。基本上L的互联网公司都已l部|了(jin)Sparkq_q运行了(jin)自己的业务。上面说的更多的互联|的应用Q实际上Spark的应用场景有很多。在Databricks公司的调查中昄主要应用依次是：(x)商务、数据仓库、推荐系l、日志处理、欺诈检等?/p>
除了(jin)互联|公总外，传统IT企业也把Spark作ؓ(f)其品的一个重要组成。IBM在今q?月的Spark summit期间宣布重点支持Sparkq个开源项目，同时q开源了(jin)自己的机器学?fn)系lSystemMLq推q其与Spark的更好合作。美国大数据巨头ClouderaQHortonworks和MapR都表CSpark是其大数据整体解x(chng)案的核心(j)产品。可以预见Spark是未来若q年最火的大数据项目?/p>
在深度学?fn)方?015q可谓非常热闹，如Google开源其W二代机器学?fn)系lTensorFlowQFacebook开源Torch和h工智能硬件服务器Big Sur{等。SparkC也不甘落后，?.5版本中发布了(jin)一个神l网l分cdMultiplayerPerceptronClassifier作ؓ(f)其深度学?fn)的雏Ş。虽然这个模型还有很多地斚w要优化，大家不妨试下，毕竟它是唯一一个基于通用计算引擎的分布式深度学习(fn)pȝ?/p>
除了(jin)现在非常火的深度学习(fn)Q在传统l计和机器学?fn)领域，Sparkq一q也有非常大的变化，包括GLM的全面支持，SparkR GLM的支持，A/B testQ以?qing)像WeightesLeastSquaresq样的底层优化算法等?/p>
具体内容可以看梁堰L在InfoQ上的q终回顾Q?a target="_blank" style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">解读2015之Spark：(x)新生态系l的形成》?/p>
ElasticsearchQ?/span>
Elasticsearch 是一个可伸羃的开源全文搜索和分析引擎。它可以快速地存储、搜索和分析量数据。Elasticsearch Z成熟?nbsp;Apache Lucene 构徏Q在设计时就是ؓ(f)大数据而生Q能够轻杄q行大规模的横向扩展Q以支撑PBU的l构化和非结构化量数据的处理。Elasticsearch生态圈发展状态良好，整合?jin)众多外围辅助系l，如监控MarvelQ分析LogstashQ安全Shield{。近q来不断发展受到q泛应用Q如Github、StackOverflow、维基百U等Q是数据库技术中倍受x(chng)的一匚w马?/p>
Elasticsearch在今q下半年发布?.0版本Q性能提升不少Q主要改变(sh)ؓ(f)Q?/p>
- Pipeline Aggregation
式聚合Q像道一P对聚合的l果q行再次聚合。原来client端需要做的计工作，下推到ESQ简?nbsp;client代码Q更Ҏ(gu)构徏强大的查询?/p>
- Query/Filter 合ƈ
取消filtersQ所有的filter语句自动转换为query语句。在上下文语义是queryӞq行相关性计；上下文语 义是filterӞ单排除b不匹配的docQ像现在的filter所做的一栗这个重构以为着所有的query执行?x)以最 有效的顺序自动优化。例如，子查询和地理查询?x)首先执行一个快速的模糊步骤Q然后用一个稍慢的_ 步骤截断l果。在filter上下文中Qcache有意义时Q经怋用的语句?x)被自动~存?/p>
- 可配|的store compression
存储的fieldQ例如_source字段Q可以用默认的LZ4法快速压~，或者用DEFLATE法减少index size。对于日志类的应用尤其有用，旧的索引库在优化前可以切换到best_compression?/p>
- Hardening
Elasticsearchq行?nbsp;Java Security Manager之下Q在安全性上标志着一个巨大的飞跃。Elasticsearch难于探测Q黑客在pȝ?nbsp;的媄(jing)响也被严格限制。在索引斚w也有加强Q?nbsp;indexinghack前，doc?x)被fsyncQ默认写持久?nbsp;所有的文g都计checksumQ提前检文件损?nbsp;所有的文grename操作都是原子的（atomicQ，避免部分写文?nbsp;对于pȝ理员来Ԍ一个需求较多的变化是，可以避免一个未配置的node意外加入Elasticsearch集群|络Q默认绑 定localhost onlyQ?nbsp;multicast也被U除Q鼓׃用unicast?/p>
- Performance and Resilience
除上所qͼElasticsearch和Luceneq有很多的变化Q其更加稳定可靠，易于配置Q例如：(x)
默认doc valueQ带来更的heap usageQfilter caching 更多使用 bitsets type mappings 大清理，更安全可靠，无二义?nbsp;cluster stat 使用diffq行快速变化传播，带来更稳定的大规模集?/p>
- Core plugins
官方支持的core plugins同时发布Q和Elasticsearch核心(j)使用相同的版本号?/p>
- Marvel 2.0.0 free to use in production
Marvel免费?/p>
Apache KylinQ?/span>
Apache Kylin是一个开源的分布式分析引擎，提供Hadoop之上的SQL查询接口?qing)多l分析（OLAPQ能力以支持大规模数据Q最初由eBay Inc. 开发ƈ贡献臛_源社区。最初于2014q?0?日开源，q于同年11月加入Aapche孵化器项目，q在一q后?015q?1月顺利毕业成为Apache目Q是eBay全球贡献至Apache软g基金?x)（ASFQ的W一个项目，也是全部由在中国的华人团队整体A(ch)献至Apache的第一个项目?/p>
在eBayQ已l上U两个生产环境^収ͼ有着诸多的应用，包括用户行ؓ(f)分析、点d析、商户分析、交易分析等应用Q最新的Streaming分析目也已l上Uѝ目前在eBayq_上最大的单个cube包含?jin)超q?000亿的数据Q?0%查询响应旉于1.5U，95%的查询响应时间小?U。同时Apache Kylin在eBay外部也有很多的用P包括京东、美团、百度地图、网易、唯品会(x)、Expedia、Expotional{很多国内外公司也已l在实际环境中用v来，把Apache Kylin作ؓ(f)他们大数据分析的基础之一?/p>
q去的一q多是Apache Kylin发展的重要的一q_(d)(x)
- 2014q?0?日，Kylin 代码在github.com上正式开?/li>
- 2014q?1?5日，正式加入Apache孵化器ƈ正式启用Apache Kylin作ؓ(f)目名称
- 2015q??0日，Apache Kylin v0.7.1-incubating发布Q这是加入Apache后的W一个版本，依据Apache的规范作?jin)很多修改，特别是依赖包Qlicense{方面，同时化了(jin)安装Q设|等Qƈ同时提供二进制安装包
- 2015q??日，Apache Kylin v1.0-incubating正式发布Q增Z(jin)SQL处理Q提升了(jin)HBase coprocessor 的性能Q同时提供了(jin)Zeppelin Interpreter{?/li>
- 2015q??6日，Apache Kylin与SparkQKafkaQStormQH2OQFlinkQElasticsearchQMesos{一赯获InfoWorld Bossie Awards 2015Q最?jng)_源大数据工具奖，q是业界对Kylin的认?/li>
- 2015q?1?8日，Apache Kylin正式毕业成ؓ(f)Apache目
- 2015q?2?5日，Apache Kylin v1.2正式发布Q这是升Uؓ(f)目后的W一个版本，提供?jin)对ExcelQPowerBIQTableau 9{的支持Q对高基l度增强?jin)支持，修复了(jin)多个关键Bug{?/li>
- 2016q_(d)Apache Kylin迎来重要的2.x版本Q该版本对底层架构和设计作了(jin)重大重构Q提供可插拔的设计及(qing)Lambda架构Q同时提供对历史数据查询QStreaming?qing)Realtime查询{，同时在性能QQ务管理，UI{各个方面提供增强?/li>
同时Q过Mq也是社区发展的重要一q_(d)在过Mq内发展?jin)来自eBayQ美团，京东Q明略数据，|易{众多committerQ社区每天的讨论也是非常热闹。社区提交了(jin)很多新特性和Bug修复Q包括来自美团的不同HBase写入Q来自京东的明细数据查询Q来自网易的多Hive源等多个重大Ҏ(gu)ؓ(f)Apache Kylin带来?jin)巨大的增强?/p>
C合作
在开源后的一q时间内QApache Kylin也和其他C建立?jin)良好的合作关系QApache Calcite作ؓ(f)Kylin 的SQL引擎被深入的整合q来Q我们也向Calcite提交?jin)很多改q和修复QCalcite的作者，Julian Hyde也是Kylin的mentor。HBase是Kylin的存储层Q在实际q维中，我们到q无数问题，从可靠性到性能到其他各个方面，KylinC和HBaseCU极合作解决?jin)绝大部分关键问题。另外，现在来多的用戯(g)虑使用Apache Zeppelin作ؓ(f)前端查询和展现的工具Qؓ(f)此我们开发了(jin)Kylin InterperterqA(ch)献给?jin)ZeppelinQ目前可以直接从最新版的Zeppelin代码库中看到q块。同P我们也和其他各个CU极合作Q包括SparkQKafka{，为构建和谐的C氛围和Ş成良好合作打下了(jin)坚实的基?/p>
技术发?/span>
技术上Q这一q来Apache Kylin主要在以下几个方?/p>
- Fast Cubing
在现在的版本中，Cube的计依赖MapReduceQƈ且需要多个步骤的MR Job来完成计，且MR Job的多和l度相关Q越多的l度?x)带来更多的MR job。而每一ơMR job的启停都需要等待集调度，q且MR job之间的数据需要多ơ在HDFS落地和传输，从而导致消耗了(jin)大量的集资源。ؓ(f)此我们引入了(jin)一U新的算法：(x)Fast Cubing。一个MapReduce卛_完成Cub的计，试l果表明整个Cubing的时间可以降?0?0%左右Q网l传输可以下?倍，q在大规模数据集的计算上带来了(jin)客观的性能改进?/p>
- Streaming OLAP
Kylin作ؓ(f)一个预计算pȝQ不可避免的有着数据h延迟的限Ӟq在大部分用h例中q不是问题，但随着业务和技术的发展QStreaming甚至Realtime的需求越来越高?015qKylin的主要发展都在Streaming OLAP上，Z(jin)支持低gq的数据hQ从整体的架构和设计上都做了(jin)相当大的重新设计Q目前已l可以支持从Kafkad数据q进行聚合计的能力Q同时提供SQL接口为前端客L(fng)提供标准的访问接口，数据延迟已经可以做到分钟U别?/p>
- Spark Cubing
Spark作ؓ(f)MapReduce的一U替代方案一直在C中被问及(qing)Kylin是否可以支持直接使用Spark来作。ؓ(f)此我们在2015q下半年实现?jin)同L(fng)法的Spark Cubing引擎Q目前还在测试中?/p>
- 可插拔架?/span>
Z(jin)更广泛的可扩展性，q支持如上各U新Ҏ(gu)，Kylin?.x的代码中引入?jin)可插拔架构和设计，从而解决了(jin)对特定技术的依赖问题。在新的设计中，数据源可以从HiveQSparkSQL{各USQL on Hadoop技术读取，q支持KafkaQ在计算引擎斚wQ除?jin)MapReduce斚w的Fast Cubing外，实现?jin)Spark CubingQStreaming Cubing{多U计框Ӟqؓ(f)来其他计算框架留下?jin)扩展接口；在存储上QHBase目前依然是唯一的存储层Q但在上层设计中已经很好的进行了(jin)抽象Q很Ҏ(gu)可以扩展到其他KeyQValuepȝ?/p>
大数据与机器学习(fn)
机器学习(fn)是数据分析不可缺的一部分。机器学?fn)被赞誉为大数据分析和商务智能发展的未来Q成功的机器学习(fn)目依赖于很多因素，包括选择正确的主题，q行环境Q合理的机器学习(fn)模型Q最重要的是现有的数据，大数据ؓ(f)机器学习(fn)提供?jin)很好的用武之地?/p>
机器学习(fn)正很快从一个被很少人关注的技术主题{变(sh)ؓ(f)被很多h使用的管理工兗优U的算法，大数据和高性能的计资源的条g的满得机器学?fn)快速发展，机器学习(fn)在今q第一ơ进入Gartner技术成熟曲U的报告中，q且q入大数据一L(fng)应用期；而机器学?fn)也是报告中W一个出现的技术?015q是机器学习(fn)丰收q_(d)发生?jin)很多o(h)人瞩目的大事?/p>
各大巨头开源：(x)
- 2015q?月，Facebook开?/a>前沿深度学习(fn)工具“Torch”?/li>
- 2015q?月，亚马逊启动其机器学习(fn)q_Amazon Machine LearningQ这是一全面的托管服务Q让开发者能够轻松用历史数据开发ƈ部v预测模型?/li>
- 2015q?1月，h开?/a>其机器学?fn)^台TensorFlow?/li>
- 同一月，IBM开源SystemMLq成为Apache官方孵化目?/li>
- 同时Q微软亚z研I分布式机器学习(fn)工具DMTK通过Github开源。DMTK׃个服务于分布式机器学?fn)的框架和一l分布式机器学习(fn)法l成Q可机器学?fn)算法应用到大数据中?/li>
- 2015q?2月，Facebook开源针对神l网l研I的服务?#8220;Big Sur”Q配有高性能囑Ş处理单元QGPUsQ，转ؓ(f)深度学习(fn)方向设计的芯片?/li>
大公怸仅是用开源社区来增强自己的机器学?fn)工P而且也会(x)以收购来提升自n的机器学?fn)实力。如IBM于今q?月收购了(jin)AIchemyAPIQAIchemyAPI能够利用深度学习(fn)人工Q搜集企业、网站发行的囄和文字等来进行文本识别和数据分析?/p>
此外Q?015q不仅仅是关于大公司的，利用机器学习(fn)的各U创业公怹占了(jin)同等C。比如EverString完成B轮融资，该公司利用企业内部销售数据，和不断主动挖掘分析全球新L据，C交媒体{外部数据，通过机器学习(fn)自动建立量化客户模型Qؓ(f)企业预测潜在客户?/p>
数据U学家的崛v
大数据需要数据分析，数据分析需要h才。数据科学是早就存在的词汇，而数据科学家却是q年来突然出现的新词。在Google、Amazon、Quora、Facebook{大公司的背后，都有一Ҏ(gu)据科学专业h才，大量数据变?sh)可开发有价值的金矿。在大数据时代，数据U学家等分析人才的需求在Ȁ增?/p>
据相x(chng)告，国内大数据h才缺口目前已辄万，一名高U数据挖掘工E师月薪高达30K-50K。招聘网站上的每天都?x)生大量的大数据相兌位需求。据拉勾|提供的l计来看Q从2014q到2015q_(d)IT行业关于大数据的岗位需求增长了(jin)2.4倍。h才培养迫在眉睫。复旦大学于今年成立?jin)全国首个大数据学院。阿里云于年底宣布新?0所合作高校Q开设云计算大数据专?计划?q时间培?万名数据U学家。各知名大学也将数据U学设ؓ(f)士评?/p>
无论是国内还是国外，数据U学都是目前炙手可热的研I域，数据U学家、数据分析师都是非常火爆的职位，几乎所有的产业都需要数据科学家来从大量的数据中挖掘有h(hun)值的信息。大数据分析领域的专属首席别头衔也愈发多见。美国政府今qQ命了(jin)DJ Patil作ؓ(f)政府的首席数据科学家QChief Data ScientistQ，q也是美国政府内部首ơ设?#8220;数据U学?#8221;q个职位?/p>
展望2016Q?/h2>- Hadoop。对?nbsp;HDFSQ会(x)朝着异构存储介质方向发展Q尤其是Ҏ(gu)兴存储介质的支持Q对?nbsp;YARNQ会(x)朝着通用资源理和调度方向发展，而不仅仅限于大数据处理领域，在加强对 MapReduce、Spark{短cd应用支持的同Ӟ加强对类似Web Service {长服务的支持；
- 对于HBaseQ将?x)花?gu)多精力在E_性和性能斚wQ正试的技术方向包括：(x)对于 HDFS 多存储介质的使用Q减对 ZooKeeper 的用以?qing)通过使用堆外内存~解Java GC的媄(jing)响?/li>
- Spark 2.0预计明年三四月䆾发布Q将?x)确立以DataFrame和Dataset为核?j)的体系架构。同时在各方面的性能上会(x)有很大的提升?/li>
- Apache Kylin 2.0卛_发布Q随着各项改进的不断完善，该版本将?016q在OLAP on Hadoop上更q一步！
- Elasticsearch开源搜索^収ͼ机器学习(fn)QData graphicsQ数据可视化?016q会(x)更加火热?/li>
- 大数据会(x)来大QIOT、社交媒体依然是一个主要的推动因素?/li>
- 大数据的安全和隐U会(x)持箋(hu)受到x(chng)?/li>
专家介绍Q?/span>
董西?/span> p于HuluQ专注于分布式计和资源理pȝ{相x(chng)术。《Hadoop 技术内q：(x)深入解析 MapReduce 架构设计与实现原理》和《Hadoop 技术内q：(x)深入?nbsp;?nbsp;YARN 架构设计与实现原理》作者，dongxicheng.org 博主?/p> 梁堰?/span> 明略数据技术合伙hQ开源爱好者，Apache Spark目核心(j)贡献者。北京航I天大学计机士Q曾p于Yahoo!、美团网、法国电(sh)信从事机器学?fn)和推荐pȝ相关的工作，在大数据、机器学?fn)和分布式系l领域具备丰富的目l验?/p> 卢亿?/span> _U技(AdMaster)技术副总裁兼L构师Q大数据资深专家QCCFQ中国计学?x)?j)大数据专委委员，北航特聘教授。主要负责数据的采集、清z、存储、挖掘等整个数据?hu)过E，保提供高可靠、高可用、高扩展、高性能pȝ服务Q提供Hadoop/HBase/Storm/Spark/ElasticSearch{离Uѝ流式及(qing)实时分布式计服务。对分布式存储和分布式计、超大集、大数据分析{有深刻理解?qing)实늻验。有过10q云计算、云存储、大数据l验。曾在联惟뀁百度、Carbonite工作Qƈ拥有多篇大数据相关的专利和论文?/p> 韩卿(Luke Han) eBay全球分析基础架构?ADI) 大数据^C品负责hQApache Kylin 副总裁Q联合创始hQ管理和驱动着Apache Kylin的愿景，路线图，Ҏ(gu)及(qing)计划{，在全球各C同部门中发展客户Q开拓内外部合作伙伴?qing)管理开源社区等Q徏立与大数据厂商，集成商及(qing)最l用L(fng)联系已构建健壮的Apache Kylin生态系l。在大数据，数据仓库Q商务智能等斚w拥有过十年的工作经验?/p>
]]>