facebook realtime hadoop

  Realtime Apache Hadoop at Facebook PPT读后感和摘录.

标签: HBase Facebook

Facebook Realtime Hadoop:

英文原版PPT微盘:     SIGMODRealtimeHadoopPresentation.pdf​

为什么选择Hadoop/HBase:

Problem:

    MySQL:

        1. 本质上是集中型数据库

        2. Table大小限制

        3. Schema不灵活

    Hadoop

        1. MapReduce速度慢而且编写复杂

        2. 不支持随机写

        3. 随机读性能差

Facebook采用的一些专门解决方案:

    1. 高吞吐量, 持久化的KV系统

        TC

    2. 大规模的数据仓库

        Hive/Hadoop

    3. 图片存储

        HayStack

    4. 其他的一些定制的C++服务

FB需要一个什么样的实时数据存储系统:

    需求:

        1. 海量数据, 包括大量冷数据

        2. 可伸缩和高可用

        3. 单个数据中心的强一致性

        4. 错误隔离

    可忽略的需求:

        1. 单个数据中心的网络割裂.

        2. 跨数据中心的active-active服务能力.

        3. 单个数据中心故障的发生时的零不可用时间.

为什么HBase符合需求:

    数据库比较选型:

        Apache Cassandra, Apache HBase, Sharded MySQL

    比较性能,伸缩性和功能:

        1. HBase有极好的随机写和顺序写性能, 有非常好的顺序读性能, 有比较好的随机读性能

        2. HBase有很多现成的好功能:

            * 原子性的读写操作

            * 单个服务器上的数据分片

            * 批量导入(Bulk Importing)

            * 支持MapReduce

HBase通过使用HDFS做为底层文件系统获得了很多好处:

    1. 容错性, 扩展性, 数据校验, MapReduce.

    2. 磁盘错误隔离, 数据冲突解决, 支持海量数据.

    3. 大量的运营经验.

        

HBase相对Hadoop的特性:

    相比Hadoop的新特性

        HDFS上的随机读写功能

    需要对Hadoop做一些修改

        1. 文件Append

        2. HA NameNode

        3. 读优化

    使用ZooKeeper做为协调器

HBase特点概括:

    有序的,基于列的数据库

    高吞吐量

    水平扩展能力

    自动故障恢复

    动态的Region分片

    自动负载均衡

    

UseCase1(TITAN: Facebook Messages):

    特点:

        1. 高写吞吐量: 用户消息, 即时信息, 短信, 邮件索引.

        2. 特别定制的Schema

    数据规模:

        1. 每秒6K用户消息.

        2. 每秒50K即时信息

        3. 每个月增长300TB压缩后数据

    单元部署:

        1. 消息系统含有多个单元

        2. 一个机架20台服务器, 一个集群有5个以上机架

        3. Master,NameNode,JobTracker和ZooKeeper分布于多个机架

    高写吞吐量:

        1. 写数据写WAL和memstore,WAL为顺序写,memstore flush也为顺序写.

    水平扩展:

        1. 表格水平分片到多个region

        2. region支持动态自动分裂

        3. region散布于多个region server

        4. 自动的region负载均衡

    自动故障转移: 

        1. Master通过ZooKeeper获取regionserver死亡消息.

        2. Master通过Meta表获得其他的server列表,用来接收死亡server的regions.

        3. 无需数据物理拷贝, 因为数据都是存储在HDFS上.

    Schema设计:

        连续IO型应用, row设计采用timestamp或者序列号

        随机型应用, row设计采用md5或者hash

        混合型应用(先随机在连续)可以采用md5_timestamp这样的混合型row.

UseCase2(Puma: Facebook Insights):

    特点:

        1. 实时数据传输管道:

            * Scribe-HDFS: 将已经存在的log信息进行聚集的管道

            * Sync+PTail: 提供HDFS实时导入HBase的能力

            * HBase: 高写吞吐量

        2. 数据的实时计算

            * 利用HBase属性值原子递增的能力来提供计数器功能

            * HBase为了单独用户的计算功能而设计的Schema

            * 将检查点信息直接存储在HBase中

    实时MapReduce:

        1. PTail实现Map(?):

            * 将log输入流分离到多个数据分片(Region)中.

            * 第一个版本只支持随机分片.

            * 现在支持应用及分片.

        2. HBase实现Reduce:

            * 每个 row+column 做为一个输出Key.

            * 通过原子计数器来统计key数量.

            * 也可以保存每个Key的数据列表或者其他数据结构.

    Puma for Facebook Insights功能:

        1. 实时 URL/Domain 统计

            * 域用户可以查看域下所有URL的详细分析数据

            * Clicks, Likes, Shares, Comments, Impressions统计

            * 详细的访问用户分类统计(年龄,性别,地区,国籍等),包括匿名用户

            * 全局和每个域下最热门URL统计

        2. 吞吐量

            * 数十亿URL

            * 每秒增加100万以上的计数器

UseCase3(ODS: Facebook Internal Metrics):

    特点:

        1. 收集数据仓库运行信息

            * 系统信息: CPU, Memory, IO, Network

            * 应用信息: Web, DB, Caches

            * Facebook信息: Usage, Revenue

                > 简单的统计信息时序图

                > 支持复杂的数据统计和转换

        2. MySql的扩展性不好

            * 数百万的时间序列, 以及每个时间序列上数十亿的点

            * 不规则的数据增长形式

        3. HBase支持Regions的动态分片和负载均衡

HBase在FB的未来:

    1. 存储用户数据和图形化数据

    2. HBase对MySql的补充(?):

        * 单行的ACID

        * 总是通过in-memory缓存对外提供服务

        * HBase非常适合存储字典和列表

    3. IOPS决定了数据库的分层大小(?)

        * HBase只做连续写

        * 低IOPS代表着低消耗

        * 大量的表存储在廉价的节点上

        

结论:

    1. Facebook持续投资Hadoop/HBase上的实时计算

        * 大量的开发人员工作在实时平台上

        * 与开源社区的紧密合作

    2. 更多的实时Hadoop文章分享

        * 对Hadoop和HBase的修改细节.

        * 在生产线上的运营经验.

一些地方还是有一点疑问, 还需要仔细考虑一下.