渠道建设网站,怎么当网站站长,深圳网咯鸟网站建设公司怎么样,什么是网络营销的缺点前言 数据的实时化是最近几年数据行业很重要的趋势#xff0c;我们在去年底也建立起新一代的实时数仓#xff0c;但是在数据应用上一直没有取得很大的突破#xff0c;我们希望实时数仓不仅仅是支撑大屏、核心实时报表、个别实时应用等简单的场景#xff0c;希望更大… 前言 数据的实时化是最近几年数据行业很重要的趋势我们在去年底也建立起新一代的实时数仓但是在数据应用上一直没有取得很大的突破我们希望实时数仓不仅仅是支撑大屏、核心实时报表、个别实时应用等简单的场景希望更大的发挥实时数仓的价值更方便、更快速、更大规模的对外提供数据服务是我们一直思考的问题。 基于阿里云Hoogres 所建设的统一数据服务在一定程度上帮助我们实现了这个目标。 通过这套系统整合离线和实时数据对外提供统一的数据服务目前已经支撑了实时报表、用户司机实时标签系统push系统、运力调度、营销活动实时监控、公司内部的客服后台系统等几十个数据需求实现实时用户精细化运营。在数据易用性、交付周期、数据的准确性上都比以往有了很大的提升。公司介绍 快狗打车(原58速运)是一家拉货的短途货运打车平台。解决比如搬家、买大家具家电、买各种大件、批发市场商家发货等场景对货车的需求同时为蓝领司机师傅提供一个可以接单的平台也就是货运版的“滴滴”来实现帮助1000w人解决就业问题的目标。数据服务的发展阶段原始阶段 在早期我们的数据服务常见的场景根据每一个需求加工数据。 如果是离线需求通过Hive加工数据使用Sqoop将结果数据导出到业务提供的MySQL表中供业务查询。 如果是实时需求开发一个实时项目将处理的数据落表或者发送MQ(Kafka或DMQ(自研组件))提供到业务方使用。 这种从底到顶的烟囱式开发导致的开发成本高、逻辑分散 、数据不一致、管理维护困难等问题随着业务的发展已经难以接受。1.0阶段 18年我们基于Spark Streaming 和Spark SQL所实现的实时数仓对落地表进行分层、建设大宽表将计算好的数据统一存放到HBase中使用ES给HBase做索引并仿照SQL接口设计了一个较为简单的 查询api对外提供统一的查询接口。所有需要实时数据的任务都可以从这套系统获取数据不再根据具体需求做定制化开发。 这种方式在一定程度上降低了开发成本增加了数据的复用、缓解了数据不一致问题并且应用在多个实时程序上。但是因为计算层面Spark Streaming 状态支持有限很难做较复杂计算、开发修改成本高。存储和服务层面通过接口查询在HBase中的数据只能做明细查询和简单聚合查询灵活性不足能对外提供的功能有限同时也没有能解决针对离线数据需求的问题所以大部分应用主要是在部门内为部门内提效。2.0阶段 在去年底实现的基于Blink 的实时数仓借助于Blink SQL的实时ETL能力重新设计了实时数仓的数据模型完善了层级划分和主题建设能对外提供的数据比之前多得多。 在存储层我们选择有较好实时OLAP性能的阿里云AnalyticDB MySQL(下称ADB)和开源Doris类似接口层面都是兼容MySQL对于一些不是太复杂的OLAP查询可以在秒级甚至亚秒级返回结果。但是由于ADB并不是太好的实时写入性能、存储成本昂贵以及一些内部原因我们将一部分查询场景简单、数据量大、查询QPS特别高的表输出到HBase中使用ES做索引。 底层存储的割裂只能在数据服务层做统一。为此我们设计了一套查询接口无论数据存放在ADB、HBase、MYSQL、Maxcompute中都可以通过接口的SQL 查询出来。但是接口层并没有完全屏蔽底层存储要根据数据存储位置不同写不同的查询SQL。不同存储之间也不能做跨库join在使用上还是有很多的局限性。虽然承接了一些数据需求但是这些局限还是约束了不能更大规模的推广。我们希望提供给到用户的是一个使用起来足够简单、丰富的数据服务。 3.0 阶段 底层存储的不一致导致的一系列问题一直困扰着我们 期望有一种引擎具有帮助我们统一实时数据存储的能力。 我们是在Hologres(下称Holo) 刚刚商业化的时候注意到Holo的Holo提出的HSAP概念统一 针对服务的点查询和实时OLAP查询在存储上也没有ADB翻倍厉害的情况。通过一周多的测试、对Holo的系统架构有了一定了解之后明确了预期收获、风险点、成本等因素后写了一篇Holo的测试文章之后将实时数仓的数据存储全部迁移到Holo。 同时基于Holo重新修改了数据服务接口由于统一的数据存储、更完善的数据建设、以及Holo很强的实时OLAP能力、统一的数据服务我们的需求交付能力相比以往有了很大的提升。很多以往要做几天的需求现在只需要配置一条SQL效率的提升是巨大的。系统上线两个月接到了很多外部数据需求目前每天请求百万次高峰期实时OLAP 查询QPS上百(和OLTP的QPS不可比可以想象1s向Hive提交100个查询)大部分周期查询平均耗时几十毫秒、两三百毫秒很少有超过1s的。单个周期查询最大耗时很少有超过1s。虽然从请求量上看并不是太大但是考虑到公司体量和我们上线的时间这个数据还是很可观的。目前公司新上的实时数据需求基本上都是在使用这套数据服务。Hologres简介 下面是个人在使用Hologres过程中结合官网资料对Hologres的理解 阿里云官网对Hologres 的介绍是交互式分析(Hologres)是一款兼容PostgreSQL协议的实时交互式分析产品。Hologres与大数据生态无缝打通支持对PB级数据进行高并发、低延时的分析处理。是基于阿里提出的HASP (hybrid serving and analytical processing)理念而设计的一种ROLAP系统。相对于HTAP(Hybrid transaction/analytical processing)来说HASP弱化了对事务的要求追求更强的性能和更快的响应时间。 一般来说为了应对不同的数据使用场景我们会将高QPS的点查请求的数据存放在kv存储中比如说Redis、HBase、Tair等系统中分析型的数据存放在Druid、Clickhouse、Doris等系统中有些场景还会使用ES、MySQL等。比如说下图美团到店的实时数仓存储分层图就是目前常见的实时数仓存储架构。 HASP理念的主要目标将以上的这些存储统一成一种存储引擎主要分为两种场景点查(point query)和OLAP的查询Holo的点查询实现很类似于HBase使用很小的资源就可以支撑起很高的QPS实时OLAP查询则是基于MPP的实时交互式查询针对两种场景分别使用了行存和列存两种不同的存储格式。 在存储上Hologres采取云原生设计存储计算分离数据存储在阿里云分布式文件系统pangu中(类比开源HDFS)方便按需单独扩展计算或者存储读写分离的设计以同时支持高并发读取和高吞吐的写入。Holo的数据写入也是使用LSM tree 写入即可见定期刷新但是碎片文件会分为多个级别。弱化一致性仅支持原子写和Read-your-writes以实现高吞吐和低延迟的读取和写入。 宣传的是写入可以达到数亿的TPS比起ADB数万的TPS高出了很多。我们在压测时没有遇到写入瓶颈。 在查询上Hologres使用LBS做查询负载均衡查询请求发送到Hologres FE做查询优化生成并行化的很多片段的执行计算DAG提交给Blackhole执行。 Holo设计了称为HOS的用户态线程调度系统执行上下文之间的切换成本几乎忽略不计同时可以实现更高的并行。Holo的调度策略中还考虑到大型分析查询不应阻止对低敏感的服务查询此处的服务查询也就是点查询(point query)。和Clickhouse、Doris底层一样Holo也是使用C实现使用native方法以及向量化引擎等提供更好的性能。 我们在实际的使用中还发现Holo的硬扫的能力很强几百万级别的数据不需要要索引就很快返回。 另外Holo还提供了多种索引可以手动添加比如聚簇索引、分段索引、bitmap索引、字典索引等等。要注意的是除bitmap和字典索引其他索引都需要在建表时指定不能修改。如果对Holo的实现感兴趣文末附有Holo发表在vldb上的论文链接。场景实践下面是58快狗打车基于Hologres的场景架构图主要的架构思路是实时数据由Blink做实时ETL写入Hologres。使用Hologres统一实时数据存储。基于Hologres和离线仓库之上提供统一数据服务对接业务层的各种报表、分析系统等。可以看到整个架构主要有主要分为3个部分数据服务、实时数仓和数据存储。下面将会就这3个部分仔细讲诉。1.数据服务 主要基于Holo我们做了一套对外提供的统一数据服务。从上面的架构图可以看到用户提交的查询请求到统一数据服务接口经过安全校验解析、别名映射后提交到Holo等执行。 使用Holo为我们解决了两个半问题。第一相对于ADBHolo很大程度上降低了存储的成本。第二Holo解决了数据存储不统一的问题同时提供了高性能的实时OLAP能力。第三Holo提供了无需搬移数据加速查询离线数据的功能但是由于是以资源消耗为代价性能会比直接查询Holo内部表差10倍同时有较多的限制。所以算是解决了半个问题。 然后我们在数据服务接口做了更进一步的统一数据服务接口以Holo为主同时兼容一些历史上存放在MySQL中的任务。对于特别复杂同时对响应时长不敏感的查询也可以使用数据服务接口直接查询离线数据。所以我们希望数据服务接口是作为整个数据部门统一的数据服务统一对外的所有数据接口。 Blink任务修改后可能会导致之前的状态不可用状态清空直接修改上线落表数据正确性会有影响。同时Holo大部分索引需要在建表时指定如果一开始表设计不合理 或者之前的表设计不再满足现有需求。这时候物理表如果被写入很多任务中是很难修改的。所以我们设计了别名映射的mapping系统mapping中会指定物理表库名、连接等信息用户只需要知道别名就可以使用无需关心具体位置同时别名是相对固定的。Blink修改任务时可以新建任务写到新建表待补齐数据借助推送系统一键切换立即生效所有的查询马上切换到新物理表线上业务无感知类似于一个主备切换的过程。另外如果一旦发生较大改动也可以在我们这边控制。 服务保障方面通过监控每次的查询建立查询异常报警机制监控整体服务的稳定性对于不合理查询可以及时提供修改意见保障整体服务持续稳定和高效。2.实时数仓 实时数仓原始数据源来自日志数据和MySQL binlog订阅我们开发了数据订阅平台通过平台配置将数据统一发送到Kafka中使用Blink SQL做实时ETL。 在建模上参考了离线的已有的数据模型但是又不完全一样主要体现在分层和表字段设计这是因为离线、实时数据的本身的属性不同。离线每天拉取一次一次性计算跑一次当天都可以一直使用同时离线计算能力强所以可以建设高内聚低耦合复杂的数据模型 使用逻辑下沉、复杂模型、完善分层和更完整维度抽象等方式来更好的保障数据一致性和数据易用性。对外提供的也是聚合数据为主明细为辅。 但是实时任务是24小时运行更高的层级抽象意味着使用起来不灵活、链路长稳定性差、维护代价大、时效性差等。所以相较于离线实时的层级更轻。很多公司在实时数仓会有较多的维度退化我们基于Holo较好的join 性能在一定程度上减少维度退化的设计提高了灵活性和开发效率。 更重要的是借助于Holo很好的实时OLAP性能很多任务可以实时OLAP 现算而不用针对具体任务加工具体的应用层数据使用实时Join也不用做大宽表。这对效率的提升是巨大的。以前很多实时需求需要专门写实时加工任务而且如果需求修改修改实时任务的代价也是很大的整个开发周期好几天现在可能使用统一数据服务接口基于我们体系的数据建设可能几分钟就可以交付了。目前实时OLAP是数据领域发展得比较快的一个模块很多公司依赖于开源Doris、Clickhouse等来实现但是从完成度来讲Holo算是做得比较好的不过是商业闭源软件。 当然也并不能过度的依赖于实时OLAP在我们的最终实践上为了更高的效率和一定的数据一致性。我们预处理了部分比较固化的计算在聚合层对外提供的数据优先使用固化的聚合层对于比较灵活的查询和不好固化的统计使用明细层总体来说以明细为主需求交付效率有较大提升。 3.数据存储 Lambda架构不仅会导致了计算的冗余也导致了存储的冗余。而Kappa架构在目前的技术下过于理想化。行业内还很少听到有完全的Kappa架构落地的案例目前主要是以Lambda为主个别地方会做调整优化的方式。计算的冗余其实比较难以解决虽然这几年实时计算技术发展迅速但是实时计算还远远不能完全替代掉离线程度实时任务修改的复杂度也远远高于离线任务。Flink的流批一体的方案使用一套代码同时运行离线和实时计算的方案目前也是在初期发展中虽然没有用过但是能想到应该有很多困难的地方。 相对而言存储的一致性能做的事情更多。不考虑实际理想情况下离线和实时的数据都存储在一个存储引擎中同时能跑批任务也具有对外提供数据服务的能力。 Holo在这个方向上往前走了一步除了解决了实时数仓存储统一的问题还提供了离线外表的功能可以将离线表作为Holo的外部表借助于Holo比较强大的硬扫能力来加快离线数据的查询使用一套系统就能同时查询离线和实时的数据。上面也讲过这种硬扫是以大量的磁盘IO和CPU资源为代价的所以会有较多的限制比如说为了更好的性能对于外表的分区数量和MaxCompute数据量有一定的约束。这种做法可以理解为一种冷数据的处理官方给的字眼是 ”离线加速“。 在实际使用中我们测试对2亿数据的点查大约在2s左右官方给到的数据是相比于内部表外部表性能会差10倍可以满足一些对时效要求不高、查询频率不高的数据需求在高时效性的任务这种性能表现可能不能满足需求。 具体到我们的实践上对于一部分需要离线数据、对时效性要求不是特别高同时离线查询分钟级的响应时长不能满足、查询频率不高的需求我们会以外部表的形式对外提供语法还是和Holo内表相同的语法对于需要一部分离线数据、同时时效性要求很高、查询频率很高的查询场景我们选择将一部分离线数据导入到Holo中有时会和实时对应任务放在同一个表中对外提供服务这种做法事实上造成数据冗余是一种妥协。 总的来说Holo 并没有完全解决实时和离线统一存储的问题但是往前做了一些探索性的工作。目前Holo和离线Maxcompute开发团队已经融合期待下一步看到更多的融合。Hologres存在的一些问题 Holo作为新生事物基于新型的架构设计提供了非常强大的性能。我们在测试和使用的过程中也发现了一些不足之处。目前Holo升级配置和版本需要停服停服几分钟的时间后续版本会解决这个影响很大要有预备。Holo gis 功能目前不支持索引在大量数据下效率较低我们测试2亿数据下地理距离查询大约几秒钟。目前索引功能开发中。Holo支持分区子表有点类似于Hive的分区表比较适合增量数据在数据删除和查询上有一定的优势。但是目前每个分区子表必须手动提前建表手动删除。资源隔离在我们调研测试中就发现Holo存在大查询影响小查询的响应时长问题在后来的实测中发现即使是大查询没有完全跑满资源的情况也会影响到小查询的响应时长。这个问题在测试调研时就和Holo沟通过我们的期望是有一个硬资源隔离类似于yarn的资源队列的形式也已经得到明显答复后面会解决这个问题。由于我们很早就意识到这个问题所以从一开始就做了很多措施来控制目前还好。在测试使用过程中还发现一些小bug 作为新产品我们在享受便利的同时也肯定会有一些不足的地方。未来规划 Holo帮助我们实现在实时数据数据存储方面只使用一套存储在一定程度上缓解了数据不一致的问题算是前进了一大步。但是更远期来说我们希望在未来可以彻底解决数据一致的问题真正的让一份数据只存储在一个地方。具体到眼前我们的主要精力在系统的稳定性、规范化沉淀、工具提效、并通过需求来完善我们的数据服务体系更好的易用性、更强的稳定性、更快的交付周期会更多的在内部的建设上。参考Alibaba Hologres: A Cloud-Native Service for Hybrid Serving/Analytical Processinghttp://www.vldb.org/pvldb/vol13/p3272-jiang.pdf
