2016年的Hadoop Spark日本大会

2 年 ago

宇, 华

2 minutes

Linux发行版和Hadoop发行版很相似的感觉，
真正的成熟将在未来到来。

重点笔记

Apache Hadoop目前和未来的发展

Hadoop通过大量排列以发挥高吞吐量。

MapReduce是一种用于执行并行分布式处理的中间件，非常常用。

HDFS：高可靠性分布式文件系统
MapReduce：分布式计算模型

YARN的现状与未来

为了通用化Hadoop的计算机资源管理的方法。

分布式处理中间件的普及

分散处理中间件的接口

SQL-esque descriptions are predominant.

MapReduce对于用于机器学习的矩阵计算不擅长。

目前重点放在CPU、内存和磁盘的中心处理上。

在高水平语言中，出现了利用GPGPU、FPGA等中间件的趋势。

请以中文进行简要阐述，我将提供一个选项：
↓

这些将如何影响YARN的发展方向？

YARN的未来

作为一个能够处理包括GPGPU和FPGA在内的计算资源的数据中心操作系统，它正在不断发展。

HDFS的现状和未来

在过去的1-2年里，添加了许多新功能。

よく使うデータはSSDに書き込むとかコントロールできるようになった
メモリをストレージとして使ったり

セキュリティ、運用性

データの暗号化
ローリングアップグレードで無停止運用できるようになってきた
これまで使えなかった領域で使えるようになってきた

ハードウェアの進化に合わせて進化していく

开发社区

在日本，NTT和Yahoo做出了巨大的贡献。对于社区的未来，我们希望进一步加强Hadoop的使用。

SSD
GPGPU
NVMeSSD
インターコネクト

Hadoopの開発者をもっと増やしたい

YARN的应用正逐渐普及。

雅虎日本的数据平台的整体情况和未来展望

雅虎日本的多源大数据

秒間50000アクセス

数据平台的整体框架

MySQL(percona)
Oracle

DWH

Teradata

Object Storage

S3互換の独自ストレージ(Go製)

KVS

Cassandra

接下来

Express, Redis, 开放堆栈

内存数据库类型
HBase、Phoenix → 广告平台
纠错编码存档层

Spark正在试验性地进行70台搜索数据的图形化处理。

关于Hadoop的技术挑战

数据爆增每年增长4倍

在8个月内用完3000个Hadoop集群资源…

以技术而非金钱来解决这些问题。

Tez上的Hive

性能要求：每小时10万次
初始测试结果为1万次。

通过将Metastore从远程转移到本地解决了由于其成为瓶颈导致的2万个查询的问题。

资源管理器
增加了ApplicationMaster的启动数量
增加了启动线程数，达到了4万个查询。

数据节点
在其他节点上重新利用
最近数据的访问量激增，成为了瓶颈
增加最新数据的复制，进行8万次查询。

客户端
对附加工具进行优化
并不意味着增加并行执行就会好。有时减少才会更好。
如果任务同时结束，会导致命名节点同时开始写入，因此可以通过插入随机睡眠来引发时间差，从而处理10万个查询。

クライアントサイドの最適化

最后

从使用到制造

我正在逐渐转向与HortonWorks合作并逐步构建的一方。

解题引擎→解决世界上的问题

Hadoop存储

2006-2007的基础所指的只是基本的批处理过程。

2008年至2011年的生产期间，经历了各种扩张，并出现了商业发行的分发。

2012年至2015年，企業的安全性和性能问题方面的处理

存储的演进

基础

HDFS独占地位
MapReduce太慢了
早期使用者使用的

生产

HDFS 已经进化了，
加强了安全性和其他一些方面，
优化了性能，
HBase。

企业 (qǐ yè)

实施了稳定的访问控制、灾难恢复和加密以及整合新的查询引擎。

从2016年开始

从硬盘驱动器转换至固态硬盘

3D Xpoint存储器（比NAND快1000倍，而且比RAM便宜）

Kudu很好。
与HDFS和HBase都不重叠的地方。

2016 年日本闪耀大会

贡献者数量开始增加

经常被使用的组件

GraphX: 图计算

我希望能够有更加易懂的GraphX应用案例。

火花2.0 接下来是什么

火花＝速度，易用性，结合精致的数据处理引擎。

2015年对于Spark来说是个重要的一年
它新增了R语言的支持
Meetup的数量大幅增加了

Spark就是大数据软件的泰勒·斯威夫特
哈哈，是北川景子呢

各种不同的执行环境

Mesos

这些中的一半在公共云上运行。

Spark已经完成了吗？
不！！！

シンプルだが表現豊かに
セマンティクスが十分に定義されてる
バックエンド

运行DataFrame的平台

Tungsten

Streaming DataFrames
DataFrameとDatasetの成熟とマージ
ANSI SQL（自然結合、サブクエリ、ビューのサポート）

有关流处理的问题

困難的原因
– 長時間的輸出
– 延遲的數據
– 障礙
– 分散

Spark的速度已经相当快
即使是2.0版本，它会变得更快。

Spark2.0将于4-5月正式发布。

樱互联网通过构建的Apache Spark原价计算系统。

不是大数据。
也不是大规模分散系统。

不要失望啊。基本上都是由Asakusa框架来完成的。

项目的背景

追求规模 = 拥有经营
资产大幅增长

这项投资的资本是否按计划进行了改进？

只要知道成本，就应该能够了解改修情况！

把海量数据输入到最强工具中，结果卡住了哈哈。

由于浅草框架将Hadoop或Spark用于后端处理进行了隐藏，所以使用者几乎无需关心使用哪个选项。

基本上是本地部署
– 有30台物理服务器
– 具有200个核心
– 内存容量为1.6TB
– 可以根据需要灵活增加。

意识不高的类型

午餐会议

我试图对流处理产品进行基准测试。

Storm

我几乎没有进行调整就试了一下。

在Kafka的四个台上进行数据注入。

CPU的使用效率（割合）
在相同的数据量下，Spark的速度是最快的。

Samza只是没有进行基准测试。

我心目中最強的大資深工程師

冰柱型工程师是最强的，而不是T字型。

KPI
機械学習
統計…

語学力
先見性
作らない能力

アリものを組み合わせて使う能力

分布式 TensorFlow

木星网络
1百万个千兆位每秒

张量=多维数组

我在使用GPU进行机器学习，一般只用一台进行训练，不需要分布式计算。

TensorFlow比Chainer等慢。

TensorFlow会自动管理GPU等，您无需担心程序的问题。

下午的会议

从状态流体架构转变为流体流程。

为了弥补分断，需要一种架构。

企业服务总线

控制的集中还没有解决。 (The concentration of control has not been resolved.)

创业者的武士

当摆钟摇摆回来时，
ESB仍然有效且被广泛使用。

反动正在进行中

考虑替换MSA→N层架构
考虑进行分区

给予工作和沟通的方式

采用MSA的公司往往有很多成功的案例。

为什么能够实现？

→ 是由于工程师的能力所致

重要的是如何处理延迟。
服务要考虑到这种延迟来构建服务。
消息队列。

細分化的消息處理量很大

现有的企业想要引入这项技术非常困难。

我需要一個具有耐障礙性且高性能的消息隊列，傳統的隊列無法滿足需求。

陈旧不堪的比喻

从云层高处的视角下俯瞰。

承诺水平

Recruit Lifestyle 对于流数据的利用方式

AWS + Kafka + Spark Streaming:
亚马逊云服务+Kafka+Spark流处理

大数据的普遍主题

容量 (Volume) – 容积
集約 (Variety) – 多样性
鲜度 (Velocity) – 速度

由于持续增长的数据量，行为日志已经达到1000亿条记录。由于数据散落在关系数据库和文件中，使用起来很困难。收集数据需要花费很长时间，数据的新鲜度因此下降。

利用于整个社会的共通分析基础设施

引入数据仓库 (DWH)

過去〜直近データも一様に見れる

我们需要数据中心基础设施！

水项目

Sparkを使用したストリーム基盤

考虑过的东西 de

クラウド vs オンプレ

採用AWS可以立即設立驗證、開發和運營環境。

数据中心平台

Kafka vs Kinesis

想要使用OSS，所以选择了Kafka。

流媒体平台

Spark Streaming vs Storm

由于有MLlib等框架的存在，所以选择在Spark中进行处理。

商务需求

考虑利用高度新鲜的数据来创造服务方案。

技术细节和提示

优化Fluentd和Kafka之间的协调
由于Fluentd有时会出现拥堵现象，因此进行了优化调整
由于Kafka已实现SSL支持，所以考虑放弃中间的Fluentd

日志输出需要定期调整。

开发Spark Streaming 应用程序

手元で簡単に実装/デバッグできる
テスト環境で本番同様に実行できる

現実

スペック不足による停止なのか環境なのか判断が難しい
コストメリットの問題だけど、本番と同じ環境をAWSで用意してやってみる

持续推动流处理的关键点

処理が止まらず稼働し続ける

現実

エラーハンドリングする
51日以上連続して動いてる

不停地移動的流程處理定義

止まらない

現実

停止は起きる
ストリーム処理停止とシステム全体の停止は異なる

将数据存储在DynamoDB中

指标的聚合是使用InfluxDB实现的。

回顾

メトリクスを取得することで改善に取り組んだ

接下来

データソースを増やす
新しいサービスを作りたい
さらにサービスのスピードを上げたい

エンジニアがビジネスを創出する環境ができてきた

重温对Hive的思考

Hive已经八年了，
庞大的Hive用户数量。

尽管我在Spark方面输了，但是在其他方面我还领先了两倍！

在过去的两到三年间，Hive也经历了重大的变化。

蜂巢LLAP

Hadoop Hacks

无论如何，熟悉Hive是必不可少的，但关于最新功能却没有提到。
在网上也没有太多丰富的信息。

从在Hive的各个场景中积累的经验中获得的技巧和调优的讲述

国内对Hadoop的引进进展顺利。

近年来越来越常见的用法

すでに実績のあるところに相乗り

HiveQL 是一种本地的中文方言。

有时候会不自觉地用HiveQL来写代码，就像RDBMS一样。

分散処理が分散しない
BIツールで普通に出てくるので困る

マルチインサート使ってない

大規模処理が効率よくできる
Hadoop HacksにRDBとの違いとか書いてるのでオススメ

我們現在能夠使用一些類似於RDB的功能！

通称WITH句

WINDOW関数

UDFでがんばってたのがビルトインの構文でできる

LATERAL View + Explode

只需要Hive，就能变得非常简单了。

关于ORCFile

列式思考格式
高速、高压缩率

引入RDB的想法来尝试加速的努力

高的压缩率也可能成为性能问题

重新思考Hive

可以适应各种工作负载
如果使用纵向容量，需要有承受林立风险的准备
对于RDB来说，可能会有过时的感觉
这需要根据性能需求来确定。

加快Hive的LLAP性能

Hive执行引擎

今でもこれを想定する人は多い
YARN時代に置いてはHadoop1系の名残
今はほとんどメリットがない

Tez

Sparkのライバル的存在
MapReduceに代わるやつ

Spark

蜂巢的极限

SQLライクに使うための物

LLAP的意思是什么？

虽然Tez的速度已经大大提升，但在DWH中的应用方式还是比较多的。

Hive2.0新增的功能

生生不息的基本思想 (LLAP)

Hadoop上でDaemonとして動かす仕組みを提供するもの
Pig並にググラビリティが低い

Hybridな環境

TezのVrtexをDaemon化するのがLLAP
LLAP自体は実行エンジンではない

现金

不是中央集权持有，而是每个节点独立拥有
由于使用了Off-Heap，降低了Java的Full GC等风险

多线程，流水线

在多个执行器上执行
节点数量乘以执行器数量等于实际可执行的并行数。

需要做的并不是增加数量。
而是要设定为合适的数量。
需要设定为能充分有效利用而不会枯竭的数量。

Hive LLAP与Spark SQL比较

HiveQL与SQL不同，
使用Hive的人在兼容性方面可能会感到困难，
如果数据无法存入内存，那么Tez应该是有优势的。

如果想要进行流式处理，
→ 由于依赖于HDFS，使用Spark Streaming可能更方便。

LLAP的运行速度

Hive on Tez的速度比较

3回同じ処理を実行しての平均速度

TCP-DS的结果

在大多数的查询中，使用LLAP会更快速。
虽然LLAP的速度变得极慢，但原因还在调查中。

LLAP的未来

キャッシュの洗練

可维护的Hadoop云架构

在云上使用Hadoop的原因。

每天都会自动提高性能和稳定性，并且价格越来越便宜。

Hadoop与其他网络服务的决定性差异在于，Hadoop本身是用于其他应用程序的基础，因此需要有这样的基础。这就是云所提供的。

维护易损性。

キューイング・エラー処理とかを適切にできる

无国籍

Stateless Hive Metastore

“状态保存的元数据是什么？”

在MySQL或类似的数据库上作嘲笑
如果使用HCatalog可能可以完成…
但会有成本
无法抛弃Metastore。

无国界的精心设计商店

创建一个嵌入式本地元数据存储

如果在使用MessagePack进行数据交换时遇到问题，只需将其删除即可。

等离子数据库

トランザクション処理

S3 or Riak

Immutable
S3とRiakの使い分けは？

使い分けてると言うよりは、サービスの違いでそれぞれ使ってるって感じ。

在这里重要的是不能使其成为无状态的。
通过组合上述两个，可以保证不会导致不一致。

机动性

为了管理多个Hadoop版本

需要使用各种版本和处理各种破解，需要维护。客户也需要逐一进行管理。

抑制这个到最低限度。

将零散的工作人员集中起来。

排队

Hadoop的REST API

工人是队列。

当有Hadoop作业服务器时，它能像Presto API一样使用，非常方便。

完美排队

グレースフルシャットダウンとライブ離スターティングができるので、ジョブのデータが消えない。気を遣わなくていい。

总结

Note: This is the simplified Chinese paraphrase of the given text.

状態を持たないアプリケーションは究極的にはできないけど、できるだけどっか一つに集める

Mobility

マイグレーションのしやすさ

Queueing

ジョブが動いてるのか、とか止めることを気にせずにできる仕組みにする必要がある

保留多个版本的好处不大。