<h3>引言</h3>    <p>随着微店业务的蓬勃发展，目前很多核心系统都需要使用实时数据，归纳了下微店的实时业务形态，大致分为如下几方面：</p>    <p>1.        实时在线系统，比如搜索、推荐和广告</p>    <p>2.        监控预警，比如用户行为预警、app crash预警、风控</p>    <p>3.        实时ETL，主要是进行数据清洗，归并，结构化</p>    <p>4.        实时报表，比如交易大盘，微团购大盘</p>    <p>5.       消息异地同步，比如binlog消息转换成业务消息</p>    <p>除了上述五种常见业务，还有例如像实时push消息以及短信通知等都可以通过实时计算平台进行统一分发。</p>    <p>在支撑业务的过程中，发现一些具有共性的问题，具体表现如下：</p>    <p>1.        技术选型多种多样，各个团队独自维护，导致实时开发门槛高，主要体现在开发者需要关注很多实时底层处理细节。</p>    <p>2.        效率低，主要体现在调试不方便，新发布中断时间长等。</p>    <p>3.        稳定性不能保障，主要体现：没有规范的开发流程，上线随意等。</p>    <p>4.        缺少统一的监控运维配套，常常线上发现故障，很长时间之后才能发现。</p>    <p>5.        数据共享不透明，比如业务团队需要使用推荐团队的用户特征，通过统一的平台可以避免重复开发，数据信息共享等。</p>    <p>为了更好的支持上述各种实时业务以及解决上述问题，提供统一高效的实时计算开发平台显得很有必要。实时计算平台代号comet，comet原意彗星，我们希望微店的实时处理能力能像彗星划过天空一样快速而精彩。</p>    <h3>实时计算平台的整体架 构</h3>    <p>整体架构描述</p>    <p>comet 实时计算平台整体架构如下图所示：</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/dc79cb1a7d487ca584f5193198a9d990.jpg"></p>    <p>任务开发流程</p>    <p>通过comet平台重新定义了实时数据开发的整个流程，下图主要展示通过sql开发实时数据的流程：</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/0cbb96fca962436ba02aa5680a1994ab.jpg"></p>    <p>选择 sql 开 发实时 任 务 的考量</p>    <p>微店开发实时数据大概经过三个阶段，初始阶段每个实时业务开发都是各自为战，这个时期的实时业务处于萌芽阶段，规模相对比较小。数据开发人员使用Storm原生API开发流式作业，开发门槛高，系统调试难，存在大量重复的人肉工作，举个例子，这个时期处理H5的日志文件，每条业务线从消息队列kafka接收到逻辑解析处理到最后存储，都是各自开发一套逻辑，有时候不同业务消费group设置成同一个都未曾发觉。第二个阶段我们把很多重复使用的组件进行抽象封装，比如实现了简单过滤、聚合、窗口等等作为基础的编程组件，这个阶段很多实时任务就是基于这些基础编程组件进行组装，一定程度上降低了使用门槛，但是开发人员还是需要了解整套编程组件，使用起来门槛依然比较高。第三个阶段就是我们引入类sql语言来开发实时任务，sql语言经过几十年的发展，接受度比较高，同时学习门槛很低，适合群体相对更加广泛，数据分析师、算法等也很容易上手进行开发。下面举个简单的采用sql开发实时任务的例子，主要逻辑是从消息队列接受日志数据，经过实时清洗到存储到elasticsearch，供业务方报表展示。</p>    <p><img src="https://simg.open-open.com/show/9df196f876fe71aa6405d56dda27db3d.jpg"></p>    <p>（看不清，请点击放大）</p>    <p>底 层选择 Jstorm 的技 术 考量</p>    <p>之前微店采用的storm作为底层实时处理引擎，comet实时计算平台基于以下考量采用了Jstorm作为底层实时处理引擎：</p>    <p>1.       兼容之前storm任务，无需二次开发</p>    <p>2.        稳定性更高：相比storm，nimbus实现了HA，彻底解决雪崩问题，资源分配更加合理，减少对ZK的访问等</p>    <p>3.        调度更强大：资源调度深度优化等</p>    <p>4.        相比heron，jstorm任务的维度为线程，heron为进程，避免了消息的传输全部走网络。根据jstorm官方文档，heron无性能优势</p>    <p>在开源基 础 上做了哪些二次开 发</p>    <p>SQL 解析并未进行自主研发，采用的是华为开源的streamCql，streamCql底层采用的主流的语法解析工具antlr，一方面华为在这方面做得相对比较完善，另一方面之前在这一块有一定的技术积累。综合考虑在开源的基础进行二次开发显得比较适合。针对streamCql做了大量的二次开发以满足目前微店的业务，列举如下：</p>    <h3>1.        增加了ack机制，目前streamCql并未实现ack机制</h3>    <h3>2.        输入算子开发，目前支持kafka，vdianMq，rocketMq，覆盖微店主流的数据输入源。</h3>    <p>3.        输出算子开发，目前支持mysql，elasticSearch，vdianMq，kafka，rocketMq，redis等，覆盖主流的输出。</p>    <p>4.        DataSource 开发，支持mysql，搜索引擎，redis等，主要为了支持实时数据过滤，补全等功能。</p>    <h3>5.        UDF 开发，参考Hive目前支持的大部分功能，开发了对应的UDF。</h3>    <h3>6.        新增支持复杂结构，比如map和array等，支持转义字符等。</h3>    <h3>7.        针对目前streamCql生成的Jstorm任务效率不高，做了算子合并，序列化等优化。</h3>    <p>Jstorm 相对比较成熟，主要是将调试日志、业务日志以及系统日志做了分离，并且存储到elasticsearch里，供comet做调试，追踪bug以及报警使用。同时为了保障线上各任务之间不互相影响，采用cgroup做资源隔离，目前正在测试中，还未正式上线。</p>    <p>踩过的坑</p>    <p>1.        streamCql 生成拓扑优化</p>    <p>通过sql生成的bolt层级太多，导致实时任务吞吐量比较低，同时延迟比较大，通过优化拓扑图，让出度和入度都为1的算子进行有策略的合并，减少网络IO，减少数据shuffle。</p>    <p>2.        streamCql 支持复杂类型</p>    <p>在微店的业务场景里，很多数据格式是json类型的，一开始采用各种嵌套UDF表达json，导致sql可读性极差且容易出错，后面通过支持map和array相关复杂类型，彻底解决这类问题。</p>    <p>3.        输出算子流控</p>    <p>app 端的日志通过实时处理，写入到elasticsearch中供数据业务方使用，初期版本并未做流控设计，当日志从5000w增长到亿级别的时候，出现bolt写入变慢，出现日志大规模处理延迟。通过实现写入elasticsearch流控控制，解决该问题，单条写入转变为批量写入，但是一定程度上牺牲了实时性。</p>    <p>4.        Jstorm 相关问题</p>    <p>比如acker数量设置为0，这时候不发送任何消息，另外比如worker数量设置为大于10，这个时候topologyMaster从线程变为进程级别，需要额外一个worker进程处理。Jstorm使用过程中遇到过一些问题，后续会有专门的Jstorm使用经验分享。</p>    <h3>展望 & 后 续 工作</h3>    <p>目前comet平台并不支持trident和batch等特性，后续会整合到streamCql中，更好的支持微店的业务，同时目前comet平台监控报警等还不完善，后续会逐步完善，力争提供一体化的实时数据开发平台。目前比较火热的spark streaming，此外google提出的新一代的数据处理引擎dataflow以及推ter提出的heron等，这些会结合微店具体业务去做一些尝试，毕竟在实时处理领域也并没有银弹。</p>    <p style="text-align:center"> </p>    <p> </p>    <p>来自：http://mp.weixin.qq.com/s/Y4LZoOP_ViAbuoodahlhSw</p>    <p> </p>