业务为王，这两年我们采用的那些数据产品和技术引擎

近两年我们在大数据业务上有了一些进步，而伴随业务发展的则是技术上的进步，笔者在这里盘点了近2年我们在数据技术上的一些创新做法，希望于你有所启示。

当然技术只是手段，所以要引入一些新技术大多是应用的需要，因此笔者会在谈某个技术的时候连带说下业务的驱动。

1、有所选择的进行计算引擎的提升

为了提升hadoop的Hive处理性能，完成集群hive3.0测试，当然Hive3.0有大量的新特性，但我们其实最关注速度，结果如下：

（1）hive3.0可兼容目前2.0的代码。

（2）hive3.0在计算份数约为2.0 1/9的情况下，执行效率却有较可观的提高，运行时长缩减50%-70%。

（3）相同数据量下，hive3.0的文件数缩减67%，存储量增加10%。

以前特别强调单集群的处理能力要非常强，比如集群节点规模要特别大，阿里发布了飞天大数据计算平台的最新消息，提到单一引擎可将10万台服务器合为一体，也是全球集群规模最大的计算平台。

但对于大多数企业来讲，现有的hadoop集群规模并不是瓶颈，即使到了瓶颈，从应用层面也可以找到很多解决方案，而且太大了不一定是好事，比如一次升级的风险，牵一发而动全身，对于技术和管理要求太高，因此在很多企业里实际是有多套hadoop集群的。

我们也在推进Spark的生产应用，目的当然不是为了颠覆HIVE，因为大多数应用场景HIVE其实够用，而在某些特定的场景（比如复杂计算）采用spark效率会高很多，大多数时候性价比是主要考虑的因素。

2、混合事务/分析处理（HTAP）的应用

运营商有两个核心数据：位置和上网。位置数据很大的基础应用其实是基于地图圈选特定范围的用户群，从而衍生出各种服务和应用，而快速的进行用户位置数据的在线更新和快速统计是一个基本技术要求，比如实时的用户位置热力统计。

但大家都知道实时用户位置状态数据更新涉及到海量数据的OLTP操作，在线分析则是海量数据的OLAP操作，如果要达到这两个目的，就会涉及到OLTP、OLAP数据库的选择、数据交换等系列问题。

混合事务/分析处理（HTAP）是 Gartner 提出的一个架构，它的设计理念是为了打破事务和分析之间的那堵“墙”，实现在单一的数据源上不加区分的处理事务和分析任务。这种融合的架构具有明显的优势，可以避免频繁的数据搬运操作给系统带来的额外负担，减少数据重复存储带来的成本，从而及时高效地对最新业务操作产生的数据进行分析。

最终我们采用了易鲸捷数据库（EsgynDB）来解决这个问题，可以做到前端海量的流数据直接更新易鲸捷的数据表，同时针对这个数据表做快速的统计分析。

前期也用了其他的方法，比如在流处理或内存数据库中直接进行处理，但都面临灵活性、数据量的挑战，现在流批一体的Flink应是一种选择。

3、基于ES解决简单条件下的快速探索问题

标签库中用户可以通过大量标签的自由组合来获得目标客户群，但由于成本、规模等因素的考量，用户希望一个个删选标签的时候，能实时显示客户群的大小变化，以便灵活调整，但原来的基于关系型数据库的时延平均需要100秒，意味着用户每调整一次就得等100秒，这个严重影响生产力。

而用ES就可以解决这个问题，现在的时延是0.1秒，比原来快了1000倍，以下显示了我们的一个投放产品中的应用情况，用户的体验大为改善。

ES用得最多的地方还是针对上网内容的解析，比如笔者曾经设想的天眼用户偏好检索系统，当然这个对于NLP能力的挑战巨大，我们也在努力，希望有实现的一天。

4、 基于Kylin解决复杂条件下的快速分析问题

ES能够实现维度指标的自由组合查询，而且是开源的，方便易用，但采用 ES 实时聚合的方式，大多数时候对单个字段的聚合查询是非常快的，一旦遇到较为复杂的多维度组合查询并且聚合的数据量比较大（如数十亿），就可能会产生大量的分组，对 ES 的性能压力很大，查询时间很长（几十秒到数分钟）导致难以等待。

为了规模化变现业务，当前神灯慧洞察产品正在推出的自助分析平台正好有这个特点，其数据量特别巨大，比如需要基于分钟级的位置数据进行交叉统计分析，而且维度特别多，而 Apache Kylin 在大数据 OLAP 分析方面非常还是有优势的，使用下来基本能达到预期。

5、基于图数据库的对象应用的初步落地

跟微信、QQ等社交数据一样，运营商其实有更为强悍的的社交网络数据，虽然现在还没有成熟的商业应用场景，但基于社交网络的商业分析必定是未来的一个数据金矿。图数据库则是社交网络分析当仁不让的选择，千万用户的六度交往圈可以方便的跑出来。

图数据在元数据管理中也已经得到了初步应用，我在《图数据库：一种解决元数据管理“两张皮”的方法！》文中有所介绍。

6、离线数据中台向实时中台升级

大数据的一个核心特点就是实时性，但当前企业内对于实时数据的应用并不普及，因为存在着较高的使用门槛，毕竟大多数人只会SQL，而实时数据中台就是为了解决这个问题，本质上做的是实时数据仓库+前端可编排，见下图所示。当前企业基于实时中台的应用场景已经超过100个，实时应用的开发效率获得了大幅的提高。

采用基于Kappa的实时中台技术平台架构，见下图所示：

如要了解细节，可参考笔者的文章《 为什么企业要从离线数据中台走向实时数据中台？》。

7、多数据源融合解决轨迹数据完整性问题

运营商的轨迹数据的来源是非常复杂的，起码包括信令（还区分从哪个口采集）、话单（上网和通话）、MR（测量报告，可以构建指纹地图）、http日志（部分带经纬度信息）等等，但每一类数据源都有各自的缺陷。

比如信令数据采集的完整性往往无法保障且精度不高，话单数据中的位置信息只有用户业务活跃才产生、MR的数据采集困难、实时性不够且对算法要求很高、http日志经纬度精度高但信息量不够多等等，现实中，没有数据是理想化的。

如何综合这些位置数据的各自优势还原一个用户的真实的轨迹路径是个挑战，这就是我们干的事情，集合各种类型位置数据的优势打造出一套融合轨迹模型，这样位置数据的完整性和准确性得到很大提升，其应用场景得到拓展。

比如以下这些应用运营商以前是做不动的，包括 分交通方式的城际交通交换模型、 出行目的识别模型、 地铁和公交的预测接驳模型、 城市快速路匝道控制模型、 营业厅高精度进店客流分析和预测模型等等。

8、一站式数据开发管理平台

当前独立的大数据工具和技术栈已经相对成熟，但一个公司大数据支撑能力强不强不是由某个技术引擎的强弱决定的。

比如苹果手机的技术指标其实要远比同价格的华为手机低很多，但是很多人还是喜欢苹果手机，因为在性能基本够的情况下，技术上的差别已经无关紧要，而综合性能变得至关重要，苹果的手机设计、操作系统、制作工艺等等集成在一起，形成了它独特的优势。

我们引入任何一个数据技术组件，首先要考虑的是它能否集成到原有的技术体系中来，无论是易鲸捷、麒麟或者其他，由于它们天然就跟现有的hadoop生态吻合，因此能产生1+1>2的效果。BAT自研了很多的技术引擎，性能也许更强大，但如果无法有效集成，对很多企业就没什么价值。

我们的DM平台就是一个数据集成的平台，其是由多种工具和能力组合而成的数据应用引擎、数据价值化的加工厂，它屏蔽了原有企业内的复杂数据结构，有效连接了下层的数据和上层的数据应用，大幅提升了数据获取、共享、开放和管理效率。

近两年我们在DM上不断叠加能力，集成了越来越多的技术组件，从代码开发框架、可视化引擎、指标管理引擎、敏捷挖掘引擎、流处理引擎、分布式调度引擎到数据交换引擎等等，最终形成了数据交付中心、数据智能中心、实时计算中心、数据运维中心及数据运营中心五大中心。基于DM这种平台实现大数据+云计算+人工智能三者能力的融合是一种趋势。

这里提到的任何一种技术，在纳入企业技术栈的时候，都经历了大量的磨合和改造，比如麒麟维度限制的问题等等，虽然结果是好的，但付出的代价不可谓不大，因此每个企业要根据自己实际的应用需要和技术能力去做出理性的选择。

完

作者：傅一平 （微信号： frank61822702）

来源：与数据同行