HBaseのは、アプリケーション・シナリオとベストプラクティスで旅行をドロップ
背景
事業の種類をドッキング
HBaseのは、Hadoopの生態データベース、プライマルオフラインタスクのサポートと友好の上に構築されていますが、LSMツリーは優れた高スループットデータベース構造だけでなく、オンラインビジネスの多くをドッキングですので。遅延の影響を受けやすい事業へのオンラインアクセス、および、そのような注文、トラック顧客からの問い合わせなどのランダムアクセス、する傾向があります。オフラインサービスは、通常の処理時間をかけてデータ上のタスクを処理するタイミングバルクビン数で、その結果を出力し、時間は、日・レベルのレポート、セキュリティとユーザーの行動として、タスクは非常に敏感に複雑で、処理ロジックはなく、完了するために必要な解析、モデルのトレーニング。
多言語サポート
HBaseの多言語ソリューションを提供し、なぜなら言語及びRDが自分の好みを使用する各ビジネスラインのピース、内部ビットの開発にHBaseのためのように、多言語サポートの開発の重要な部分です。、JAVA JDBC（フェニックスJDBC）、フェニックスQueryServer（多言語フェニックスは、外部のソリューションを提供）、（主にC ++、PHP、Pythonで使用）HBaseのJavaのネイティブAPI、スリフトサーバー：私たちは、アクセス、複数の言語へのユーザーのための方法を提供しますMapReduceのジョブ（htable / HFILE入力）、スパーク仕事、ストリーミングなど。
データの種類
HBaseのデータは、以下の4種類の主記憶装置にドロップします。
- 通常、フェニックスSQLクエリで、大手事業者等の能力、収入の結果：統計は、データは、クラスを報告します。データの量は、お問い合わせの小型、高柔軟性の要件、一般的には遅延要件です。
- オリジナル事実に基づくデータ：などの受注、GPSのトラック運転手の乗客、ログなど、主にオンラインとオフラインのデータを供給するために使用されます。一貫性と高可用性要件、遅延に敏感な、リアルタイム書かれた、単一またはバッチのクエリのための大量のデータ。
- 中級は、データを結果：データモデルトレーニングの必要性を指します。大量のクエリの要求スループットデータ可用性および一般的な要件の一貫性の大量。
- オンラインデータバックアップシステム：元のユーザーデータは、Disaster Recoveryソリューションとして、リレーショナルデータベースや他のファイルサービス、HBaseの中に存在しています。
はじめの使用シナリオ
シーンワン：オーダーイベント
それはアプリケーションのための歴史である、との接触を持っている必要があり、このデータは、ビット製品のユーザーによって使用されます。最近の注文は、お問い合わせは、特定の時間枠の上に、Redisのを落ちる、またはのRedisが使用できない場合、クエリは、HBaseの上で分類されます。次のようにビジネス需要側は次のようになります。
- ステータス、EVENT_TYPE、order_detailやその他の情報を含むためのライフサイクルのオンライン世論調査各種ステータス、。顧客サービスシステムからメイン・クエリ。
- オンライン注文履歴は、クエリの詳細。Redisの近い将来を格納するのRedis Redisの使用またはクエリの範囲を超えていない場合、HBaseのにクエリ直順序の先頭が存在するであろう。
- 注文のステータスのオフライン分析。
- 第2の書き込みイベントあたり10Kは読み取りイベント満たす毎秒1Kを満たすために、利用可能なデータは、5秒を要します。
図1注文フローのデータフロー
これらの要件によると、私たちは次のようなデザインのrowKeyを作った、非常に典型的なシーンをスキャンしています。
注文状況表
rowKey：リバース（ORDER_ID）+（MAX_LONG - TS）
列：行のさまざまな状態
注文履歴テーブル
rowKey：リバース（passenger_id | driver_id）+（MAX_LONG - TS）
列：タイムフレームやその他の情報内の顧客の注文
シーン2：ドライバの乗客の軌跡
これにより、ユーザデータ、オンラインユーザーへのビット近く、様々なビジネスのラインやアナリストの部分が使用されます。ルートが地図上に表示されてユーザーが注文履歴を表示、;乗客の紛争が発生し、コール顧客サービスの注文軌跡シーンシーン、道路渋滞のマップのユーザ部門の分析：いくつかのシナリオの使用例。
図2の乗員軌跡データフロー
要件を提案したユーザー：
- ミートリアルタイムまたはリアルタイムに近い軌道Appユーザーまたはバックエンドのアナリストは問い合わせをコーディネート。
- 大規模陸上競技会オフライン分析。
- 満たす所与の地理的領域は、トラックユーザーの範囲または範囲を引き継い現れ内のすべてのユーザーを指定しました。
其中，关于第三个需求，地理位置查询，我们知道MongoDB对于这种地理索引有源生的支持，但是在滴滴这种量级的情况下可能会发生存储瓶颈，HBase存储和扩展性上没有压力但是没有内置类似MongoDB地理位置索引的功能，没有就需要我们自己实现。通过调研，了解到关于地理索引有一套比较通用的GeohHash算法 。
GeoHash是将二维的经纬度转换成字符串，每一个字符串代表了某一矩形区域。也就是说，这个矩形区域内所有的点（经纬度坐标）都共享相同的GeoHash字符串，比如说我在悠唐酒店，我的一个朋友在旁边的悠唐购物广场，我们的经纬度点会得到相同的GeoHash串。这样既可以保护隐私（只表示大概区域位置而不是具体的点），又比较容易做缓存。
图3 GeoHash示意图
但是我们要查询的范围和GeohHash块可能不会完全重合。以圆形为例，查询时会出现如图4所示的一半在GeoHash块内，一半在外面的情况（如A、B、C、D、E、F、G等点）。这种情况就需要对GeoHash块内每个真实的GPS点进行第二次的过滤，通过原始的GPS点和圆心之间的距离，过滤掉不符合查询条件的数据。
图4 范围查询时，边界GeoHash块示意图
最后依据这个原理，把GeoHash和其他一些需要被索引的维度拼装成Rowkey，真实的GPS点为Value，在这个基础上封装成客户端，并且在客户端内部对查询逻辑和查询策略做出速度上的大幅优化，这样就把HBase变成了一个MongoDB一样支持地理位置索引的数据库。如果查询范围非常大（比如进行省级别的分析），还额外提供了MR的获取数据的入口。
两种查询场景的Rowkey设计如下：
- 单个用户按订单或时间段查询： reverse(user_id) + (Integer.MAX_LONG-TS/1000)
- 给定范围内的轨迹查询：reverse(geohash) + ts/1000 + user_id
场景三：ETA
ETA是指每次选好起始和目的地后，提示出的预估时间和价格。提示的预估到达时间和价格，最初版本是离线方式运行，后来改版通过HBase实现实时效果，把HBase当成一个KeyValue缓存，带来了减少训练时间、可多城市并行、减少人工干预的好处。
整个ETA的过程如下：
- 模型训练通过Spark Job，每30分钟对各个城市训练一次；
- 模型训练第一阶段，在5分钟内，按照设定条件从HBase读取所有城市数据；
- 模型训练第二阶段在25分钟内完成ETA的计算；
- HBase中的数据每隔一段时间会持久化至HDFS中，供新模型测试和新的特征提取。
Rowkey：salting+cited+type0+type1+type2+TS
Column：order, feature
图5 ETA数据流程
场景四：监控工具DCM
用于监控Hadoop集群的资源使用（Namenode，Yarn container使用等），关系数据库在时间维度过程以后会产生各种性能问题，同时我们又希望可以通过SQL做一些分析查询，所以使用Phoenix，使用采集程序定时录入数据，生产成报表，存入HBase，可以在秒级别返回查询结果，最后在前端做展示。
图6 DCM数据流程
图7、图8、图9是几张监控工具的用户UI，数字相关的部分做了模糊处理。
图7 DCM HDFS按时间统计使用全量和增量
图8 DCM HDFS按用户统计文件数
图9 DCM，MR Job运行结果统计
滴滴在HBase对多租户的管理
我们认为单集群多租户是最高效和节省精力的方案，但是由于HBase对多租户基本没有管理，使用上会遇到很多问题：在用户方面比如对资源使用情况不做分析、存储总量发生变化后不做调整和通知、项目上线下线没有计划、想要最多的资源和权限等；我们平台管理者也会遇到比如线上沟通难以理解用户的业务、对每个接入HBase的项目状态不清楚、不能判断出用户的需求是否合理、多租户在集群上发生资源竞争、问题定位和排查时间长等。
针对这些问题，我们开发了DHS系统（Didi HBase Service）进行项目管理，并且在HBase上通过Namespace、RS Group等技术来分割用户的资源、数据和权限。通过计算开销并计费的方法来管控资源分配。
图10 DHS项目表监控
DHS主要有下面几个模块和功能：
- 项目生命周期管理：包括立项、资源预估和申请、项目需求调整、需求讨论；
- 用户管理：权限管理，项目审批；
- 集群资源管理；
- 表级别的使用情况监控：主要是读写监控、memstore、blockcache、locality。
当用户有使用HBase存储的需求，我们会让用户在DHS上注册项目。介绍业务的场景和产品相关的细节，以及是否有高SLA要求。
之后是新建表以及对表性能需求预估，我们要求用户对自己要使用的资源有一个准确的预估。如果用户难以估计，我们会以线上或者线下讨论的方式与用户讨论帮助确定这些信息。
然后会生成项目概览页面，方便管理员和用户进行项目进展的跟踪。
HBase自带的jxm信息会汇总到Region和RegionServer级别的数据，管理员会经常用到，但是用户却很少关注这个级别。根据这种情况我们开发了HBase表级别的监控，并且会有权限控制，让业务RD只能看到和自己相关的表，清楚自己项目表的吞吐及存储占用情况。
通过DHS让用户明确自己使用资源情况的基础之上，我们使用了RS Group技术，把一个集群分成多个逻辑子集群，可以让用户选择独占或者共享资源。共享和独占各有自己的优缺点，如表1。
表1 多租户共享和独占资源的优缺点
根据以上的情况，我们在资源分配上会根据业务的特性来选择不同方案：
- 对于访问延迟要求低、访问量小、可用性要求低、备份或者测试阶段的数据：使用共享资源池；
- 对于延迟敏感、吞吐要求高、高峰时段访问量大、可用性要求高、在线业务：让其独占一定机器数量构成的RegionServer Group资源，并且按用户预估的资源量，额外给出20%~30%的余量。
最后我们会根据用户对资源的使用，定期计算开销并向用户发出账单。
RS Group
RegionServer Group，实现细节可以参照HBase HBASE-6721这个Patch。滴滴在这个基础上作了一些分配策略上的优化，以便适合滴滴业务场景的修改。RS Group简单概括是指通过分配一批指定的RegionServer列表，成为一个RS Group，每个Group可以按需挂载不同的表，并且当Group内的表发生异常后，Region不会迁移到其他的Group。这样，每个Group就相当于一个逻辑上的子集群，通过这种方式达到资源隔离的效果，降低管理成本，不必为每个高SLA的业务线单独搭集群。
图11 RS Group示意图
总结
在滴滴推广和实践HBase的工作中，我们认为至关重要的两点是帮助用户做出良好的表结构设计和资源的控制。有了这两个前提之后，后续出现问题的概率会大大降低。良好的表结构设计需要用户对HBase的实现有一个清晰的认识，大多数业务用户把更多精力放在了业务逻辑上，对架构实现知之甚少，这就需要平台管理者去不断帮助和引导，有了好的开端和成功案例后，通过这些用户再去向其他的业务方推广。资源隔离控制则帮助我们有效减少集群的数量，降低运维成本，让平台管理者从多集群无止尽的管理工作中解放出来，将更多精力投入到组件社区跟进和平台管理系统的研发工作中，使业务和平台都进入一个良性循环，提升用户的使用体验，更好地支持公司业务的发展。