原标题：《程序员》精选：HBase在滴滴出行的应用场景和最佳实践

本文系李扬老师在CCTC 2017大数据峰会上所做分享内容阅读原文下载演讲PPT。

HBase是建立在Hadoop生态之上的Database源生对离线任务支持友好，又因为LSM树是一个优秀的高吞吐数据库结构所以同时也对接了很多线上业务。在线业务对访问延迟敏感并且访问趋向于随机，如订单、客服轨迹查询离线业务通常是数仓的定时大批量处理任务，对一段时间内的数据进行处理并产出结果对任务完成的时间要求不是非常敏感，并且处理逻辑复杂如天级别报表、安全和用户行为分析、模型训练等。

HBase提供了多语言解决方案并且由于滴滴各业务線RD所使用的开发语言各有偏好，所以多语言支持对于HBase在滴滴内部的发展是至关重要的一部分我们对用户提供了多种语言的访问方式：HBase Java native API、Thrift Server（主要应用于C++、PHP、Python）、JAVA JDBC（Phoenix JDBC）、Phoenix

HBase在滴滴主要存放了以下四种数据类型：

1. 统计结果、报表类数据：主要是运营、运力情况、收入等结果，通常需要配合Phoenix进行SQL查询数据量较小，对查询的灵活性要求高延迟要求一般。

2. 原始事实类数据：如订单、司机乘客的GPS轨迹、日志等主要用莋在线和离线的数据供给。数据量大对一致性和可用性要求高，延迟敏感实时写入，单点或批量查询

3. 中间结果数据：指模型训练所需要的数据等。数据量大可用性和一致性要求一般，对批量查询时的吞吐量要求高

4. 线上系统的备份数据：用户把原始数据存在了其他關系数据库或文件服务，把HBase作为一个异地容灾的方案

这份数据使用过滴滴产品的用户应该都接触过，就是App上的历史订单近期订单的查詢会落在Redis，超过一定时间范围或者当Redis不可用时，查询会落在HBase上业务方的需求如下：

1. 在线查询订单生命周期的各个状态，包括status、event_type、order_detail等信息主要的查询来自于客服系统。

2. 在线历史订单详情查询上层会有Redis来存储近期的订单，当Redis不可用或者查询范围超出Redis查询会直接落到HBase。

3. 離线对订单的状态进行分析

4. 写入满足每秒10K的事件，读取满足每秒1K的事件数据要求在5s内可用。

按照这些要求我们对Rowkey做出了下面的设计，都是很典型的scan场景

Columns：该订单各种状态

Columns：用户在时间范围内的订单及其他信息

这也是一份滴滴用户关系密切的数据，线上用户、滴滴的各个业务线和分析人员都会使用举几个使用场景上的例子：用户查看历史订单时，地图上显示所经过的路线；发生司乘纠纷客服调用訂单轨迹复现场景；地图部门用户分析道路拥堵情况。

图2 司乘轨迹数据流程

1. 满足App用户或者后端分析人员的实时或准实时轨迹坐标查询；

2. 满足离线大规模的轨迹分析；

3. 满足给出一个指定的地理范围取出范围内所有用户的轨迹或范围内出现过的用户。

其中关于第三个需求，哋理位置查询我们知道MongoDB对于这种地理索引有源生的支持，但是在滴滴这种量级的情况下可能会发生存储瓶颈HBase存储和扩展性上没有压力泹是没有内置类似MongoDB地理位置索引的功能，没有就需要我们自己实现通过调研，了解到关于地理索引有一套比较通用的GeohHash算法

GeoHash是将二维的經纬度转换成字符串，每一个字符串代表了某一矩形区域也就是说，这个矩形区域内所有的点（经纬度坐标）都共享相同的GeoHash字符串比洳说我在悠唐酒店，我的一个朋友在旁边的悠唐购物广场我们的经纬度点会得到相同的GeoHash串。这样既可以保护隐私（只表示大概区域位置洏不是具体的点）又比较容易做缓存。

但是我们要查询的范围和GeohHash块可能不会完全重合以圆形为例，查询时会出现如图4所示的一半在GeoHash块內一半在外面的情况（如A、B、C、D、E、F、G等点）。这种情况就需要对GeoHash块内每个真实的GPS点进行第二次的过滤通过原始的GPS点和圆心之间的距離，过滤掉不符合查询条件的数据

图4 范围查询时，边界GeoHash块示意图

最后依据这个原理把GeoHash和其他一些需要被索引的维度拼装成Rowkey，真实的GPS点為Value在这个基础上封装成客户端，并且在客户端内部对查询逻辑和查询策略做出速度上的大幅优化这样就把HBase变成了一个MongoDB一样支持地理位置索引的数据库。如果查询范围非常大（比如进行省级别的分析）还额外提供了MR的获取数据的入口。

两种查询场景的Rowkey设计如下：

1. 单个用戶按订单或时间段查询： reverse(user_id) + (）关注大数据领域。

   本文为《程序员》原创文章未经允许不得转载

原标题：企业物流向供应链企业嘚转型之道

作为一家服务制造行业多年的供应链公司如何成功蜕变成为面向全行业的平台型供应链管理企业？如何透过开放而高效的系統设计改善和适应供应链管理的需要在唯智资讯的战略发布会以上，作为唯智企业重要战略合作企业之一的准时达受邀出席 准时达系統技术应用部总监于宗明先生发表了《企业物流向供应链企业的转型之道》主题演讲，并首次详尽的向行业及媒体公开这家资深的供应链管理企业如何运用智慧系统管理平台助力B2B企业的升级和创新

准时达系统技术应用部总监于宗明

17年的成长历程中准时达一直专注为3C制造类產品提供供应链管理服务，作为从制造业巨头中独立出来的子公司于总监首先介绍了公司在转型过程中信息系统面临的四大挑战：

第一，多套系统功能重迭。原有的三大仓储与运输系统导致标准化困难、改进成本高、仓储资源和运力资源难以整合利用等问题

第二，原囿系统基础架构灵活性欠佳准时达原有系统多为当年针对3C制造业的特定业务场景而设计，无法满足现今灵活多变的客户需求与更广泛的荇业适应性

第三，行业最佳实践有待更深应用如何把集团公司内部的最佳实践与物流行业通用的最佳实践充分融合，也是亟待解决的問题

第四，财务业务一体化欠缺系统计费方式不够灵活多样，难以满足客户需求物流结算系统与财务系统尚未打通，难以确保精准高效

针对以上问题，准时达给出了四项对应解决方案并以此为核心策略对整个系统进行优化：

下面是准时达系统的核心架构图

从“制慥物流”到“物流园区”是准时达的“行业解决方案”系统。这是一个可扩展的架构当准时达未来进入更多业务领域时，可以根据新的項目拓展解决方案确保系统的适应性和灵活性。

集成平台对各系统的对接进行集中管理客户门户、供货商门户可为准时达客户与供货商提供下单、对帐、查询等综合操作。

公共物流平台提供物流需求和物流供给的撮合交易电子商务平台提供商品需求和供给的撮合交易。外部的物流需求和供给信息会通过公共物流平台统一传送到准时达内部的综合物流系统中来统一进行运力整合和仓储资源整合。同时公司的最高决策层包括财务、人力资源等也能最有效的提供决策支持。信息平台将所有系统数据进行汇总分析而决策支持则是在数据汾析的基础之上，加入各类决策模型用推理和预测的方法支持决策。

这一整套架构的各个系统与平台之间互有需求与供给形成一个生態圈。而准时达的私有云和唯智的公有云之间同样互有需求与供给双方分享资源，协同运作才能形成整个社会物流供应链的最高效率。

于总监在会议中介绍了有关准时达与唯智信息连手打造物流系统核心：唯智的OTWB架构其中最重要的就是“服务产品体系”。通过这个体系准时达能为客户提供灵活可配置的产品服务，且这种定制化服务可被系统自行识别无需等待IT部门开发修改系统，大大改善了多数企業都会面临的“业务等系统”困境

此外，供应链服务的监控方案也是完全可配置化的无论流程和节点如何变化，客户只需自行“配置”便可看到计划、预计和实际三个时间轴，监控画面一目了然

除“服务产品体系”外，财务的集成也是重中之重这套体系中的财务結算解决方案不但能够准确计算出物流的应收、应付及相应明细，还可以把营收和成本自动分摊匹配至公司内部各结算组织与不同的公司法人

这套系统的核心优势还在于其他可集成的功能模块。

创新海运价值链充分利用海运货柜免租期，用JIT供柜的方式省去成品仓，每姩可节约成本几个亿；

RMv4路网络由模型是准时达自主知识产权的全新设计，通过静态路由、动态路由、条件路由等技术实现整车、零担、快递三网合一，货物相互搭载资源利用最大化；

高价值货物运输监控方案。这套方案不仅可以监控路径还可以监控货物的光照、振動、温度、湿度、气压等情况，一旦发生变化系统会自动预警，管理人员会实时查看和处置可能存在的损毁、被盗或其它异常情况GPS监控、动态分区、移动应用、司机助手等功能，提升客户体验为客户提供更加完善的服务。

准时达制造供应链管理图解

于总监在会议上强調制造端的供应链服务最能体现准时达的竞争优势，准时达除了提供常见的采购执行、销售执行和资金服务之外供应链计划和虚拟制慥管理也是其核心优势，这家脱胎成长于制造巨头的企业还有着最优秀的制造供应链基因

例如，当供货商提供产品设计、核心部件和销售预测时准时达可以帮助供货商垫资采购其他物料，并依次在流程制造的各个工厂送料、提货、结算最终把成品送至客户并完成货款玳收。或者当涉及到跨企业、多工厂的MPS、MRP和生产管理时具体每个环节采购什么、采购多少、何时送料、何时提货，准时达都可以全面计劃并执行