Yahoo Japan 数据基础设施研讨会

2 年 ago

科, 雅

1 minute

→ データを取得およびパッケージ化する部門、および提供する場所
→ ユーザーフレンドリーにする部門、およびレコメンデーションなどを提供する場所
→ データインフラストラクチャ

6.5百亿页面浏览量

雅虎的广告系统和Hadoop上的SQL。

通过技术加速不断发展的广告业务和行业。

YDN广告…推荐在Yahoo首页上的那个。

广告报告的使命是什么？

需要的东西 de

吞吐量和可扩展性

每天发生60亿行。

随着服务的增加和集计项目的添加，数据量迅速增加。
需要具备灵活的可扩展性来应对这种情况。

追求的目标

使い勝手

雅虎在运营和研究方面与谷歌相比成本相差了3到4倍。

过去的努力

传统系统

每天发生10亿行数据，
在RDB中处理它很困难。

当时的对策
按账户组进行文件输出
水平分割
虽然吞吐量有所增加，但是…

功能受限发生
文件分割速度变慢→无法及时提供第二天的数据

将SQL引入Hadoop系统

瞪羚

最初尝试Impala

不過，增加集群可以對功能限制和服務水平的降低起到貢獻，但卻存在可擴展性問題。

2015年7月开始提供服务。

Hive在Tez上运行

虽然延迟并不是很严重，但还是不错的，采取了解决传统的MapReduce问题的方法。

可以实现可扩展性保证

预计于2016年开始提供服务。

挑战与贡献

目标是实现亚秒级查询。

人们期待低延迟化的每一天。

Hive on Tez + LLAP 与 Phoenix 的比较

由于问题的存在，我们一直在日益改进。同时我们也在关注两个方面。

以前我们使用了Yahoo.inc的封闭源代码，但现在我们与HortonWorks合作，开始努力工作。
我们开始提供开源软件的补丁，并为行业做出贡献。
我们希望展现我们的实力。

大规模的HDFS和纠删码技术

分散计算黑带.

大規模HDFSが直面する課題

数据使用量和CPU使用量指数级增加
集群数量增加到6000台

普通的HDFS… de HDFS…)

有3000个DataNode，共有1.3亿个文件和1.6亿个块，导致块报告变慢…

在NameNode上发生垃圾回收导致变慢

有效数据量为60PB，实际可用的是20PB，从成本角度来看非常惊人。

区块报告延迟问题

如果NameNode的启动很慢（几个小时），那么无法提供服务。

为什么区块报告这么慢？
因为要进行差异比较和其他各种操作，所以所以的过程变慢了。

我明白原因了。

暫定対策

運用手順で対応 10分くらいで終わる

全DataNode Stop
NameNode起動・再起動

根本対策

コミュニティと連携して根本敵にソースコードを修正する
Hadoop2.6.1から入る

存储成本问题

为了保持耐障害性，需要三个副本。

耐久度为2，额外开销为200%。

通过ErasureCoding进行改善
通过ReedSolomon（6,3）进行改善

精细地进行条纹处理
6个区块的条纹，3个奇偶性

Durability=3, Overhead=50% → 耐久性=3、开销=50%

最大的优点是需要较少的磁盘容量。
缺点是会产生较多的网络流量和CPU使用率。

ErasureCoding的写入性能很好，因为同时运行了9个从节点，所以很快。

ストレージコストのメリットが大きい

存储政策

根据数据访问频率来决定

COLD ほとんど使わない

关于Yahoo的下一代管道

数据管道是什么？

高效地将分散的数据收集到分析基础设施中

管道建立了数据解决方案的良性循环。

数据高速公路

雅虎公司制造

封闭系统的局限性

成長速度について行けない

I/Fがオープンではないため、ガラパゴス化する

汎用的よりも特化的
導入コストがかかる
プロダクトごとに管理が必要になって困る

随着数据量的急剧增加，销售额没有增长，而是通过技术实力加以弥补。

不仅要增加服务器，还要增加每一层来进行适应。

使用开放技术

下一代管道

Fabric Network

卡夫卡指的是

消息经纪人。
其他公司也有处理大规模数据的成功案例。

镜像制造机

将Kafka集群数据进行镜像备份的工具。

总结

为全球数据管道的发展做出贡献。

卡夫卡与日本见面计划！1月16日

LT（Long Term）

Yahoo的关系数据库（RDB）和最新的MySQL验证结果。

小黑在DB管理方面和三谷先生一样出色。

Yahoo使用什么样的关系数据库（RDB）？

200DB
広告、ヤフオク、ショッピング、トラベル、ニュースetc…

MySQL 5.1 Percone 5.5

MySQL的新版本。

5.7版本发布了。

查询重写插件

在Oracle和PostgreSQL中不可用的缓冲池。

Ambari和大型集群以及我

完全开源的100%管理Hadoop的搭建、管理和运维

我們正在使用四個Ambari集群來完成本次工作。

1000个部署问题

同時に1000台追加することはできません。
少しずつ増やそうとすると、通信ができません。

原因
資料庫的死結
連線數目達到限制

对应
每次增加100台（不可能）
Arp队列设置

網頁使用者界面出現嚴重問題

2.1.0 升级后变得非常卡顿
一些功能变得很慢
应用补丁

关于InfluxDB

时间序列数据库

通过连续观测某一现象的时间变化而得到的数值序列

可以在股票等方面使用

时间结构化合并树
减少磁盘容量

很快就会遇到错误

如果使用rpm进行安装后遇到了错误。

雅虎日本ID的背后

在使用服务时需要的Yahoo Japan ID
适用于Yahoo Japan专用的标识符

独自KVS

存储数据
超过2亿
超过800种类
每个账户6kb

连接客户端数量超过10000台
请求数量为110k RPS

服务器的数量是多少？
有16台。
为了实现4重化，需要80台。

情报资产的访问控制列表

分散系统面临的挑战

处理模型的推移太过混乱。

为什么这里有这么多？

现有模型过于简化了。
现实是复杂的…

分散クラウドデータベースの分野でも単純化の反動

问题很多，让人感到困惑。

是似曾相识的感觉…？

在超级计算（并行）的领域中，我们要做的是作业管理。
而在并行数据库的领域中，我们要做的是查询并行化。

只要我们从历史中学习，就应该知道！