精华内容
参与话题
问答
  • 大众点评数据平台架构变迁

    万次阅读 2013-12-18 19:04:37
    最近和其他公司的同学对数据平台的发展题做了一些沟通,发现各自遇到的问题都类似,架构的变迁也有一定的相似性。 以下从数据&架构&应用的角度对2012.07-2014.12期间大众点评数据平台的架构变迁做一个概括性的总结,...

    最近和其他公司的同学对数据平台的发展题做了一些沟通,发现各自遇到的问题都类似,架构的变迁也有一定的相似性。

    以下从数据&架构&应用的角度对2012.07-2014.12期间大众点评数据平台的架构变迁做一个概括性的总结,希望对还处在数据平台发展初期的同学有一些帮助,欢迎线下沟通。

    1.0(2012.07)



    数据:
    1. 以支持用户报表需求为主
    2. 初步沉淀出了一些底层模型
    3. 模型计算程序以python为主
    架构:
    1. 存储和计算都在GreenPlum
    2. GreenPlum采用双集群热备,一大一小,部分关键报表数据同时在两个集群存储、计算。
    3.传输:公司的DBA同学将数据从Mysql、SQLServer拉出来,落地成文件。传输程序每天凌晨解析落地的文件,然后将数据load到greenplum
    4.调度:使用Quartz框架,依赖关系存放到表中,将依赖检查做成一个脚本,下游job 调用方法check上游任务是否完成
    5.监控:用户程序自主判断异常,邮件、手机报警。
    数据应用:
    1.报表数据以邮件的形式发送给用户
    2.用户可以使用自定义sql的web查询工具主动查询数据

    2.0(2013.04)


    数据
    1. 有了明确的模型分层:
     a) ODS:存放从原系统采集来的原始数据
        b) DW:保存经过清洗,转换和重新组织的历史数据,数据将保留较长时间,满足系统最细粒度的查询需要
        c) DM: 数据集市。基于部门或某一特定分析主题需要
        d) RPT:直接面向用户的报表
    2. 形成了流量、团购、信息三大基础模型及构建于三大基础模型之上的数据集市
    3. 基于volocity开发了canaan计算框架。
    4. 开发了一些自定义的UDF
    架构:
    1. 存储和计算都基于HIVE
    2. GREENPLUM作为HIVE的“cache”存在,供用户做一些小数据的快查询,报表存储。
    3. 调度:和canaan框架进行整合,支持用户快速新增任务,并自动导入任务依赖。
    4. 主数据:保存了数据仓库元数据信息,供用户查询和系统内部各个模块交互。
    5. ACL:构建了数据仓库数据访问权限控制,包括用户权限申请、审批者审批、数据赋权等。
    6. 传输:
      a)参考阿里DataX的设计,实现了点评的异构数据离线传输工具wormhole
      b)可视化界面,用户通过界面操作,方便的将数据导入导出数据
      c)和调度、主数据等系统打通
    7. 监控:由于任务数量增长较快(2000+),运维已经是个问题此外,因此,我们花了较大精力做了可视化的工作:
        
       

    数据应用
    1. 运营工具:用户自定义SQL,存储基于HIVE
    2. 指标(KPI):用户自定义SQL,计算基于HIVE,结果放到GREENPLUM中,用户可以根据指标通过时间拼接成报表
    3. HIVE WEB:非常便捷的HIVE WEB工具,可用性可以甩hive原生的web界面HWI几条街了

    3.0(2013.12)


    数据
    1. 有了明确的上层数据集市,各层数据集市打通,例如团购数据和流量数据打通
    2. 形成了用户集市、商户集市两大主题
    3. 和算法团队合作建设推荐系统
    4. 提供框架和工具支持,引入外部数据开发者
    架构:
    1. 引入mysql、hbase,支持线上服务
    2. 数据访问接口支持:API、Query Engine、RPC Service
    3. 引入shark支持临时查询,出于稳定性考虑,牺牲性能,shark/spark集群和hadoop/hive集群物理隔离
    4. 数据质量:用户指定以条件,对计算结果做检查
    数据产品:
    支持DashBoard

    4.0(2014.12)


    数据
    1. 持续扩充/完善数据模型
    2. 数据规范化,主要包括:APP日志、渠道
    3. 完善数据开发平台,其他部门数据开发者100+

    架构:
    1. 建设Redis Cluster,支持实时推荐、用户画像等服务
    2. Hadoop升级到YARN
    3. 引入Storm支持实时计算
    4. 推出类Kafka的分布式消息系统,结合日志框架,支持日志数据的快速/低成本接入
    5. 建设元数据中心

    数据产品:
    推出专有数据产品,包括:运营效果评估、流量分析产品等

    展开全文
  • 企业每天都在制造大量的经营数据,这些数据反映了企业生成、销售状况。营销分析是在广泛收集信息资料的基础上,运用各种定性和定量的方法,帮助管理层决策分析,更好的为开展营销工作服务。着公司企业规模的扩大,对...

    企业每天都在制造大量的经营数据,这些数据反映了企业生成、销售状况。营销分析是在广泛收集信息资料的基础上,运用各种定性和定量的方法,帮助管理层决策分析,更好的为开展营销工作服务。

    一般而言营销管理分析系统包含以下几个基本要求:

    灵活弹性的报表设计,适应各个地区、情况的报表需求,能迎合企业需要快速反应企业状况;

    可视化的数据呈现方式,帮助企业领导层快速解读报表内容;

    多元化的数据分析维度,帮助企业发现数据隐含的意义。

    建设企业营销管理和分析平台的背景

    某公司的信息化建设主要借助SAP系统进行,缺陷是报表展现上不灵活,随着公司企业规模的扩大,对数据量和报表展现的要求也随之提高,SAP自带的数据处理和报表展现功能已无法满足公司现有业务需求,因此需要建设一个报表系统弥补数据处理、数据展现上的弱点,即满足从数据库中取数,生成报表,供领导检查和审阅,用于分析经营状况的需求。

    营销和管理分析平台的模块规划

    1股份总公司销售指标

    2 、成材率的多维度分析

    3 、线体月产量综合分析

    4 、期货到货的综合分析

    5期货订货的比例分析

    6  期货订货量统计分析

    工具

    SAP系统

    报表开发工具:FineReport

     

    成果展示:SAP系统中用finereport建成的营销管理和分析平台

    1、股份总公司销售指标:数据图表结合的实时分析展现


    2、材率的多级表单分析

     

    3、线体月产量的综合分析表

     

    4、期货到货情况分析汇总

     

    5、期货订货比例分析

     

    6、期货订货量分析表

     

    展开全文
  • 数据平台简介

    千次阅读 2018-10-31 18:28:31
    为了给各个业务平台提供稳定可靠的数据 提供一个通用的数据处理流程解决方案 生成一些面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合 整合多个数据源的历史数据进行细粒度的、多维的分析 说白了...

    目标

    1. 为了给各个业务平台提供稳定可靠的数据
    2. 提供一个通用的数据处理流程解决方案
    3. 生成一些面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合
    4. 整合多个数据源的历史数据进行细粒度的、多维的分析
    5. 说白了就是读取数据–>生产数据–>交付数据的过程

    一些概念

    ETL

    ETL,Extraction-Transformation-Loading的缩写,中文名为数据抽取、转换和加载。ETL负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成,最后加载到数据仓库或数据集市中,成为联机分析处理、数据挖掘的基础。ETL是BI项目最重要的一个环节,通常情况下ETL会花掉整个项目的1/3的时间,ETL设计的好坏直接关接到BI项目的成败。ETL也是一个长期的过程,只有不断的发现问题并解决问题,才能使ETL运行效率更高,为项目后期开发提供准确的数据。

    数据仓库

    数据仓库,英文名称为Data Warehouse,可简写为DW或DWH。数据仓库,是为企业所有级别的决策制定过程,提供所有类型数据支持的战略集合。它是单个数据存储,出于分析性报告和决策支持目的而创建。 为需要业务智能的企业,提供指导业务流程改进、监视时间、成本、质量以及控制。

    目前要解决的问题

    1. 需要任务调度监控平台来管理数据读取、生产、交付的一系列脚本,任务的调度与监控。
    2. 需要一个API接口平台来满足一些数据的即席查询。
    3. 需要一个数据同步平台来将生产完成的数据同步到各个业务端。
    4. 需要一个数据检测平台来控制交付数据的质量。
    5. 需要一个BI数据展示的平台来清晰地展示不同角色关注的各个维度数据。

    解决方案

    1. 使用airflow来搭建ETL系统,即编排调度一系列数据的采集脚本,清洗脚本,数据汇总,聚合,预计算多维度指标的工作。提供任务监控以及webUI可视化任务依赖。
    2. 使用dataX来完成数据同步工作。
    3. 使用lumen来做API接口平台。
    4. 数据检测平台和BI展示一期暂时不考虑。

    技术栈

    airflow(python)、lumen、postgreSQL、dataX、elasticsearch
    后期基于数据量会做spark分布式集群离线计算,hdfs存储,流计算、hive等

    理想状态

    后期的日志分析可以接入ETL系统来分析用户行为,用户画像,提高系统的安全性。
    对绩效日报,周报,年报等数据展示汇总提供更短的时延,降低业务系统的负载。
    对ERP数据进行汇总分析来为领导层决策提供参考。
    对APP日志进行汇总分析来为产品设计和运营提供一些数据事实依据。
    同时面对数据极速增长情况下大数据分析也能够得心应手。

    “罗马不是一天建成的”

    展开全文
  • 数据平台作业调度系统详解-实践篇

    万次阅读 热门讨论 2017-07-25 09:34:19
    上一篇文章,讨论了作业调度系统的分类,流派,架构实现方案和各种方案的优缺点以及适用场景,最后还简单总结了理想中,一个完备的工作流作业调度系统,应该具备哪些功能特性。但是,纸上得来终觉浅,绝知此事要躬行...

    上一篇文章,讨论了作业调度系统的分类,流派,架构实现方案和各种方案的优缺点以及适用场景,最后还简单总结了理想中,一个完备的工作流作业调度系统,应该具备哪些功能特性。

    但是,纸上得来终觉浅,绝知此事要躬行。实践才是硬道理。我司刚巧在开发工作流作业调度系统这块有一些实践经验,所以这篇文章来和大家探讨一下过去两年多来,我司Jarvis调度系统的产品功能定位,架构实现以及经验教训。


    需求定位

    如前文(数据平台作业调度系统详解-理论篇)所述,我司的Jarvis调度系统,经历了两代系统的迭代发展。

    第一代Jarvis调度系统的实现,是以静态执行列表的方案为基础实现的,系统每天晚上11点半,根据周期性作业的计划和依赖关系,提前生成第二天要执行的所有任务列表和任务依赖关系。而Jarvis 2则是以动态执行列表方案为基础的。

    Jarvis一代系统的问题

    Jarvis一代系统是多年前,部门内一个同学在短时间内构建起来的系统,由于受当时的时间和人力资源所限,一代系统的功能形态和架构实现方面都缺乏整体规划设计,在系统的模块化方面也没有太多考虑。

    所以,2015年下半年开始,我们开始构思Jarvis二代系统的实现。最开始,重构的原因其实很简单,主要是为了提升系统的可维护性。

    在当时,正常情况下,Jarvis一代系统应对每日的作业调度流程,问题不大,但是在运维管理,报警监控,流量控制,权限隔离等方面都没有较好的支持,模块化程度不够,所以功能拓展也比较困难。后续添加的各种功能都是以补丁的方式到处Hack流程来实现的,开发维护代价很高,添加新功能时一不小心就可能破坏了其它同样Hack的流程逻辑,导致有一段时间内,系统故障频发。

    其次,从功能上来说,Jarvis一代调度系统,对于我司当时的应用场景,虽然能够勉强应对,但是遇到系统异常情况的处理,或者稍微特殊一点的调度需求,往往都需要大量的人肉运维干预。

    于此同时,系统所管理的作业任务快速增长,各种长周期任务(比如月任务),短周期任务(小时,甚至分钟级别任务)需求日益增多,任务之间的依赖关系日趋复杂,而使用调度系统的用户也从单一的数仓团队向更多的业务开发团队甚至运营团队拓展。

    这种情况下,拓展应用场景,降低使用成本,提升系统易用性也成为了重构开发Jarvis二代系统的重要的目标。

    Jarvis 2 设计目标

    Jarvis 2的核心设计目标,从后台调度系统自身逻辑的角度来看,大致包括以下几点:

    • 准实时调度,支持短周期任务,作业计划的变更,即时生效

    • 灵活的调度策略,触发方式需要支持:时间触发,依赖触发或者混合触发,支持多种依赖关系等

    • 系统高可用,组件模块化,核心组件无状态化

    • 丰富的作业类型,能够灵活拓展

    • 支持用户权限管理,能和各种周边系统和底层存储计算框架即有的权限体系灵活对接

    • 做好多租户隔离,内建流控,负载均衡和作业优先级等机制

    • 开放系统接口,对外提供REST API,便于对接周边系统


    从作业管控后台以及用户交互的产品形态方面来看,则包括以下目标:

    • 用户可以在管控后台中,自主的对拥有权限的作业/任务进行管理,包括添加,删除,修改,重跑等。对没有权限的作业,只能检索信息。

    • 支持当日任务计划和执行流水的检索,支持周期作业信息的检索,包括作业概况,历史运行流水,运行日志,变更记录,依赖关系树查询等。

    • 支持作业失败自动重试,可以设置自动重试次数,重试间隔等

    • 支持历史任务独立重刷或按照依赖关系重刷后续整条作业链路

    • 允许设置作业生命周期,可以临时禁止或启用一个周期作业

    • 支持任务失败报警,超时报警,到达指定时间未执行报警等异常情况的报警监控

    • 支持动态按应用/业务/优先级等维度调整作业执行的并发度

    • 调度时间和数据时间的分离


    最后,从进一步提升易用性和可维护性的角度出发,和周边一些系统相结合,还有如下目标需求:

    • 支持灰度功能,允许按特定条件筛选作业按照特定的策略灰度执行

    • 根据血缘信息,自动建立作业依赖关系

    • 任务日志分析,自动识别错误原因和类型


    具体目标的详细分析和实践

    接下来,逐一具体讨论一下上述各条设计目标的需求来源,部分设计实现细节和相关实践经验

    准实时调度,支持短周期任务,作业计划的变更,即时生效

    所谓准时实调度,首先指的是Jarvis 2的设计目标不是以强实时触发为最高原则的(亦即只要触发时间到了,一定要精确准时执行),实际上Jarvis 2的设计目标基本上是以资源使用情况为最高原则的,受并发度控制,任务资源抢占,上游任务执行时间等因素的限制,Jarvis 2只保证在资源许可的情况下,尽量按时执行作业。

    所以,如果要保证特定作业的精确定时执行,就必需保障该作业的资源可用性和计划可控性,比如提高作业优先级,划定专门的执行队列和资源,没有外部依赖,或者相关依赖作业执行时间严格可控等。但总体上来说,Jarvis 2并不保证秒级别的精确定时触发逻辑。

    而另外一方面,Jarvis2的设计目标中,作业计划的变更,只要具体的任务还没有被触发进入就绪状态,所有的变更(增删改),就应该能够立刻生效,无需等到下一个周期或人工更新当日任务执行计划。

    比如9点钟用户修改了一个原定于9点5分开始执行的作业的参数配置,改到10点执行,那么从今天开始,这个修改就应该生效,也不需要人工干预,从计划中先挪除之前的计划,再添加新计划等等。

    但如果这个作业当前周期的任务实例已经执行过了,比如9点5分的任务,已经执行完毕,在11点修改调度计划到14点执行,那么,这个修改第二天才会生效。

    我们认为上述逻辑应该符合绝大多数用户的意图,如果有特殊情况,可以通过人工重跑任务等方式来实现

    具体的策略方面其实还有很多细节要考虑,比如面对一个月一次的长周期任务,或者一个小时执行一次的短周期任务,该如何处理这种计划的变更?在很多情况下,并没有绝对正确的处理方式,重要的是让默认的处理逻辑尽可能符合多数用户的意图,同时给予必要的结果反馈。

    灵活的调度策略,多种触发方式和依赖关系支持

    支持时间触发,和作业依赖触发,这两个需求很好理解。 为什么需要支持时间和依赖混合触发?这有几方面的考量因素:

    首先,一些作业的触发时间周期和父作业的触发时间周期可能不一致,比如月任务依赖日任务,小时任务依赖日任务等。

    其次,有些作业属于低优先任务,在依赖满足的条件下,定制触发时间,可以人工调配资源,错开集群峰值负载时间

    最后,在当前作业依赖多个父亲作业的情况下,填写时间触发周期,有利于对特定周期依赖触发条件的判断,以及到点未执行等异常情况的报警判断。

    (本质上,各种按一个Flow流定义整体触发周期的系统如oozie等,其实是把所有作业都定义成混合触发模式了,只不过这些作业的时间触发周期范围都一样而已。)

    在实际Jarvis 2系统的实现中,我们只允许把仅有单个作业依赖的任务设置成纯依赖任务,存在多个父亲作业依赖关系的作业都要求配置成混合触发,也就是说需要设定触发时间周期。

    作业依赖关系方面,当依赖的父作业在当前作业的触发周期区间内有多个任务时,Jarvis 2支持如下几种依赖策略:

    • All:调度区间内,所有依赖满足。

    • Any:调度区间内,任何1个依赖满足。

    • First(n):调度区间内,前面n个依赖满足。

    • Last(n):调度区间内,后面n个依赖满足。

    • Continuous(n):连续n个依赖满足。


    默认策略为All,实际情况下,对多数一天执行一次的离线作业来说,这几种策略都是等价的,但对于不等周期的作业之间的依赖关系,就有区别了。通常All或者Last(1)的策略会常用一些,比如日任务依赖小时任务,可能只需要最新的一次小时任务执行成功,日任务就可以执行了。

    系统高可用,组件模块化,核心组件无状态化

    系统高可用当然是任何工程系统的通用追求,但是怎么实现高可用,实现的程度如何,那就因系统而异了。

    从系统架构的角度出发,模块化的设计有利于功能隔离,降低组件耦合度和单个组件的复杂度,提升系统的可拓展性,一定程度上有利于提升系统稳定性,但带来的问题是开发调试会更加困难,从这个角度来说又不利于稳定性的改进。所以各个功能模块拆不拆,怎么拆往往是需要权衡考虑的。

    Jarvis 2 采用常见的主从式架构,有中心的作业管理体系方案:Master节点负责作业计划的管理和任务的调度分配,worker节点负责具体任务的执行。



    此外,Jarvis 2使用专门的Log服务器管理任务日志的读写,用户通过Web控制后台管理作业,而Web控制后台与Master服务器之间的交互透过Rest服务来执行,Rest服务也可以给Web控制后台以外的其它系统提供服务(用于支持外部系统和调度系统的对接)。

    实际上,图上没有画出来,Jarvis 2还支持通过Tesla接口(我司自研的RPC服务接口)对外提供作业调度服务。

    调度系统的核心逻辑,抽象的来说,就是一个状态机,所以,显然,严格的按学术定义来说,核心组件是不可能做到无状态的。

    所以,这里所说的无状态化,更多的强调的是各个调度组件运行时状态的持久化,在组件崩溃重启后,所有的运行时状态都应该能够通过外部持久化的数据中快速的恢复重建。

    为了保证状态的一致统一,Jarvis 2所有作业和任务的信息变更,无论是用户发起的作业配置修改,还是执行器反馈的作业状态变更,都会提交给Master节点同步写入到外部数据库。

    在HA方面,按照准实时的设计目标,Jarvis 2并没有打算做到秒级别的崩溃恢复速度,系统崩溃时,只要能在分钟级别范围内,重建系统状态,就基本能满足系统的设计目标需求。

    所以其实高可用性设计的重点,关键在于重建的过程中,系统的状态能否准确的恢复。比如,主节点崩溃或维护期间,发生状态变更的任务在主节点恢复以后,能否正确更新状态等等。

    而双机热备份无缝切换,目前来看实现难度较大(太多流程需要考虑原子操作,数据同步和避免竞争冲突),实际需求也不强烈,通过监控,自动重启和双机冷备的方式来加快系统重建速度,基本也就足够了。

    另外,为了提高系统局部维护/升级期间的系统可用性,Jarvis 2 支持Worker节点的动态上下线,可以对worker节点进行滚动维护,当Master节点下线时,Worker节点也会缓存任务的状态变更信息,等到Master节点重新上线后再次汇报结果。所以一定程度上也能减少和规避系统不可用的时间。

    丰富的作业类型,能够灵活拓展

    做为通用调度系统,当然需要支持各种类型的作业的调度。理论上,只要支持Shell作业,那任何类型的作业都可以交给用户,通过调用Shell脚本封装的形式调用起来。

    但实际上,出于更好的控制作业的生命周期,定制执行流程,定制执行环境,适配作业参数,简化用户部署难度等需要考虑,往往还是需要根据实际的作业类型,定制专门的执行器(Executor)来执行特定类型的作业

    Jarvis 2通过标准化任务执行接口(Executor)的方式来实作业类型的灵活拓展,具体的调度Worker负责将任务相关信息和环境变量传递给特定类型的Executor进程去执行,每个Executor除了实现run,kill,status等任务运行管理接口,还可以实现包括pre/post等流程Hook接口,用于执行一些特殊作业运行前的准备或运行后的清理工作。

    Jarvis 2目前内建支持包括Hive/Presto/MR/Spark/Java/Shell以及一些我司内部专属的作业类型,其它少数没有强烈定制需求的作业类型,还是交给具体业务实现方,通过Shell作业来封装实现。扩展作业类型并不困难,困难的其实是各种类型的作业之间,流程,功能,环境,部署等方面在通用和定制两个维度间的平衡取舍,亦即,到底要定制到什么程度才是合理的。

    支持用户权限管理,能和各种周边系统和底层存储计算框架即有的权限体系灵活对接

    用户权限管理,其实一直是大数据生态环境最棘手的问题之一。

    大数据系统组件众多,且不说,从底层组件的角度来看,并没有一个统一完整的权限管控解决方案:比如Kerberos,Sentry,Ranger都有自己的局限性和适用范围,比如很多组件可能压根没有权限体系,还有些组件不同的版本可能也有不同的权限体系方案。

    从业务流程的角度来看,各家公司根据自己的应用场景也会有各种权限和用户管控需求。比如公司用户账号体系有统一的管理系统,不同业务流程要求不同的认证方式,各种大数据体系以外的系统(比如DB)有自己的权限和用户体系方案等等

    而调度系统是对接这些组件的核心枢纽之一,所以势必需要一个通用的解决方案能够灵活适配各个周边系统和底层组件。

    但要在一个中间系统中实现完全管控,这其实很难。所以,Jarvis 2的设计中,调度系统的核心逻辑实际上尽可能的只是起到用户和权限管理的二传手的作用,重点在于Hook好上下游系统,确保整体链路的权限管理流程体系的通畅无障碍。

    对上,Jarvis自身维护作业信息,但是不维护用户数据信息,通过模块化组件,借助外部系统获取和管理用户。比如,通过我司的统一登陆服务,实现用户认证。通过我司的RBAC统一权限管理服务,对用户进行功能性验权。通过元数据管理系统等,进行业务组信息管理和任务/脚本/对象的授权管理。

    对下,Jarvis将权限控制所需的相关信息尽可能完整的向后传递,比如任务的作业类型,owner归属信息,业务组信息,当前执行者信息等等。

    这样,具体的计算和存储框架的用户和权限匹配工作,可以在上层,通过外部系统进行Gateway式的管理,也可以在下层,交由对应具体类型的Executor去实现。具体各种组件采用哪种方式来实现用户管理和验权,各有什么优缺点和适用场景,这又是一个很复杂的话题,后续文章专门另行讨论吧。

    做好多租户隔离,内建流控,负载均衡和作业优先级等机制

    大多数的公有云工作流调度系统,多租户的隔离是简单粗暴彻底的,那就是业务上租户之间完全独立,租户之间的业务很难相互关联。同一租户的工作流方面也往往如此。所以,它们更多的考虑是物理资源层面的隔离,这个,多半通过独立集群或者虚拟化的方案来解决,同一租户内部,做得好的可能再考虑一下业务队列管理。

    我司的业务环境则不适合采取类似的方案,首先从业务的角度来说,不同的业务组(亦即租户),虽然管理的作业会有不同,但是往往不同租户之间的作业,相互依赖关系复杂,犬牙交错,变化也频繁,基本不可能在物理集群或机器的层面进行隔离,业务组之间的人员流动,业务变更也比较频繁。

    其次在同一租户业务内部,不同优先级的任务,不同类型的任务,不同应用来源的任务,包括周期任务,一次性任务,失败重试任务,历史重刷任务等各种情况,也有不同的资源和流控管控需求。

    Jarvis 2在上述需求方面,主要实现并支持如下功能:

    • 作业优先级定义,主要管理满足触发条件,在就绪任务队列中的任务的执行顺序。

    • 多维度的并发度控制:包括作业类型(Hive/MR/Spark等),应用类型(即作业的提交来源,比如从开发平台提交的还是从其它外部系统提交的),调度类型(周期任务,一次性任务,重跑任务等)和优先级类型(关键任务/非关键任务)等多种维度的并发度控制

    • Worker节点的被动负载反馈(负载高的情况拒绝接收任务)和主节点的主动负载均衡(轮询和Worker节点并发数控制等策略)


    其中,并发度控制相关,后面专门的小节再详细讨论

    开放系统接口,对外提供REST API,便于对接周边系统

    一方面支撑调度系统自身逻辑运行,需要对接的周边系统众多,所以各组件和系统之间,需要通过低耦合的接口进行对接。

    另一方面,往往还有很多业务流程无法完全接入开发平台的调度系统体系统一进行管理。比如,外部业务方业务流程复杂,多数业务相关程序必须在自己的系统中运行,只有部分数据处理作业可以提交到数据平台上来,或者出于安全角度的考虑,只有部分任务需要(可以)提交到开发平台上执行和管理。再比如,一些外部业务,可能需要根据调度系统中作业运行的相关状态信息来执行对应的流程方案。

    Jarvis 2自身调度组件之间采用RPC通讯提高交互效率和可靠性,与后台管控组件和周边系统之间采用REST服务或我司通用RPC服务封装进行通讯和作业管理。同时对外部系统提供诸如作业状态变更消息通知等机制来辅助业务决策或串流外部业务流程。

    用户可以在管控后台中,自主的对拥有权限的作业/任务进行管理,包括添加,删除,修改,重跑等。对没有权限的作业,只能检索信息。

    这个很直白了,根本的目的是让用户能够尽可能的自助服务,同时降低操作代价,减少犯错的可能性。

    支持当日任务计划和执行流水的检索,支持周期作业信息的检索,包括作业概况,历史运行流水,运行日志,变更记录,依赖关系树查询等。

    这部分功能的目的,是为了让系统更加透明,让业务更加可控,让排查和分析问题更加容易。当然,也是为了降低平台开发和维护者背黑锅的可能性。尽可能的让一切作业任务信息和变更记录都有源可查,做到冤有头债有主 ;)

    支持作业失败自动重试,可以设置自动重试次数,重试间隔等

    这部分功能也很直白,作业失败的原因很多,有些情况下可能是临时性的,比如网络原因,比如集群或者外部DB负载原因,可能重试了就好了,你当然不希望半夜起来处理问题,然后发现问题已经不存在了,你只是点一下重跑button。。。所以,为了降低运维代价,我们需要可以支持相关重试策略的配置。当然,更加理想的情况是系统可以智能的根据失败的原因自动采取不同的策略。

    支持历史任务独立重刷或按照依赖关系重刷后续整条作业链路

    用户永远是对的,所以,用户三天两头没事批量重刷历史任务也是理直气壮的! 既然如此,我们就需要提供一个方便的手段让用户高效的去做正确的事情。。。

    与当天失败任务的处理不同,失败的任务,下游后续的任务默认都是阻塞的,所以,修改脚本也好,修复其它错误原因也好,只要重新开始执行失败任务,恢复计划中的作业流程就好了,基本上,就是一个暂停,修复,重启动的过程。

    而当执行历史任务重刷时,通常情况下,对应的历史任务是已经执行成功过的,所以用户的意图是单独重跑这个任务,还是要重跑所有下游依赖任务,甚至只是重跑部分下游任务,都是有可能的,系统自身无从判断,此外,重跑的日期范围是哪些,所有这些信息,都需要用户明确的定义。如何能给用户提供一个便捷的手段完成相关操作,上述所有的内容都需要考虑。

    我司Jarvis 2的做法是提供图形化的界面,让用户搜索和选择相关作业,可以树形展开单独勾选这些作业的部分下游作业,也可以选择重跑所有下游作业,并提供日期范围选择



    用户交互容易处理,更难处理的问题是重刷逻辑的构建以及它和正常调度逻辑的共存。

    首先,需要根据所选的作业构建正确的依赖关系(只依赖于链路选择范围内部的作业,需要排除其它预定义依赖),生成执行列表。

    其次,要考虑作业的串行/并行执行机制,以及重刷任务和正常周期任务之间的依赖关系,是否会干扰周期任务,同时运行是否会冲突,如果冲突如何处理等,如果相同数据日期的作业重刷成功,对应失败的周期任务如何解决等等。这里面,可能包含很多的业务流程逻辑,你可以完全不处理,也可以帮用户按照你认为合理的方式包办一切。Again,选择怎样的业务流程逻辑,没有唯一的答案,取决于你所提供的功能的形态定义和场景的需求与多数用户的认知是否能达成一致。

    允许设置作业生命周期,可以临时禁止或启用一个周期作业

    维护一个服务平台,头大的问题之一,就是用户用完即忘,留下一堆垃圾作业浪费系统资源。。。而你要让用户定期清理吧,用户也有苦衷,这个作业现在是不用了,但是说不定哪天我又要再用一下呢。。。

    为了降低维护代价和机会成本,设置作业生命周期是一种可以采取的手段。虽然作用有限,多数同学实际上不会去设置,不过,总是聊胜于无吧。 而且,万一,哪天,你要是强势起来,可以强制设置有限的生命周期要求用户定期刷新呢 ;)

    至于提供临时禁止和启用的功能,也是降低用户心理负担的一种方式,留下一条后路,心里总是不慌一些。除此之外,这些功能,平时也可以用作一些特殊操作的变通手段。

    不过,凡事总有代价。要支持这些功能,系统的调度逻辑复杂度就会增加,在生成调度计划,触发作业执行,包括系统暂停,恢复,判定调度周期等场景下,需要权衡考虑的问题就多了很多。。。

    另外,还需要考虑依赖关系链问题,禁止了一个作业,下游别的作业怎么办?挪除依赖?自动禁止? 当前我们的实现是不允许禁止还有下游依赖的作业。

    总之,在易用性,可维护性和实现复杂性之间要取得一个合理的平衡,还是蛮伤脑筋的。

    支持任务失败报警,超时报警,到达指定时间未执行报警等异常情况的报警监控

    这个需求同样很明确,很直白。但困难的地方在于,如何做到智能化?

    条件太宽,过多的无用报警,只会让大家精神紧张,降低报警的收益。条件太严,该报的没有及时报,那肯定更不行了。

    举个例子,比如任务失败报警,配置了失败重试逻辑,那么第一次任务失败了报不报警,还是失败三次后再报警?你说,可以让用户来选择嘛,但用户往往是不会主动做这个选择的。理想中,不应该按固定的次数来判断,而应该按照重试代价来评估,如果重跑一次任务只需要5秒钟,那重试完几次都失败了再报警又如何?如果跑一次就需要两小时,那最好还是出了问题立即报警不是。。。

    其次,报警的逻辑,其实和调度系统自身逻辑,不应该是强耦合的,因为这里面可能掺杂了大量的可能会随时调整的业务逻辑。比如:

    • 可能需要支持按业务组(用户组)排班的方式报警:比如很多业务可能是一个团队共同负责的,每天安排人值班

    • 可能在不同的时间段需要设置不同的报警策略:比如非关键业务,不着急处理,如果是半夜出错了,也不着急报警,白天上班时间再报警。

    • 可能需要设置不同的报警方式:比如短信,电话,邮件,IM工具等等

    • 可能需要临时调整报警的行为方式:比如大促高峰流量期间,系统维护期间等等。


    所以,智能化的根据业务和历史信息进行报警;和核心调度逻辑松耦合,能够灵活调整策略,满足不同场景的需求,这两点才是实现报警功能的难点所在。

    在我们的Jarvis 2 系统中,主要的思路是,尽可能把与调度逻辑无关的策略部分剥离出去。报警行为的触发判定功能模块化,而具体报警策略的制定,通过独立的报警服务平台来承接,解耦核心调度逻辑和报警策略之间的关联关系。

    支持动态按应用/业务/优先级等维度调整作业执行的并发度

    这里所谓的并发度,指的不是一个作业分成几片执行,而是说系统中允许多少个特定类型的作业的并行执行

    如果集群资源无限丰富,那么当然不用考虑流控问题。但实际情况往往是僧多粥少,狼多肉少,你的集群优化工作做得越好,集群利用率越高,这个问题就越突出,因为缓冲的余地就越小。

    虚拟化动态弹性集群资源固然是一种解决方式,但实际情况是弹性的响应周期,弹性的范围,和业务的需求往往并不能完全匹配。所以,或多或少,自主控制资源的使用量总是一个逃不过去的问题。

    但是决定是否能够给一个具体的任务分配资源并运行起来,往往需要考虑这个任务多方面的属性。比如

    • 任务类型:因为不同的任务类型,需要的资源和对应的执行环境往往不同,对资源的消耗也不同。

    • 调度来源:比如正常的调度作业,重刷历史作业,临时性一次跑的业务,可能共享相同的资源,但是互相之间又不能过于互相影响,比如多数情况下要留给正常的调度作业足够的资源

    • 业务重要程度:比如核心业务的作业,需要优先保证执行,很可能需要更多的资源和并发度支持。


    这几个维度的参数通常还是混杂在一起的,比如一个重刷历史的,属于核心业务范围的Spark任务,能不能跑起来?

    我司Jarvis 2系统的实现中,多种维度的并发度是独立设置,然后共同约束的,任何一个维度的条件不满足,对应的作业任务就跑不起来。

    这种实现方案的优点是实现简单,但是缺点是,正确的划分维度,并不容易,有些时候,你很难做到既能精确的控制某一特定属性集合的作业,又不对其它作业的并发度控制逻辑造成影响。因为这些维度压根就是纠缠在一起的。

    举个例子,比如某一天,系统出了些问题,作业跑得慢了,我如果想要确保核心业务的产出时间,那么,我可以临时降低非核心业务的并发度,腾出资源给核心业务使用。但如果于此同时,我又希望非核心业务中,一些实时计算相关任务不要延迟太严重,要有足够的资源可用,那就很尴尬了,因为上述条件“与”的逻辑并不支持这种设定方式。(一定要实现的话,需要一个“或”的逻辑。但这样,各种并发度条件设置的综合效果,对用户来说就更难理顺和理解了)

    总体而言,按不同维度进行并发度控制,有着广泛的应用场景和价值,但是具体的实现和维度分类方式值得深入思考和研究。

    调度时间和数据时间的分离

    先解释一下这两个时间的概念。

    调度时间,指的是一个作业的任务实例,按计划是什么时候跑起来的。如果一定要细分,由于任务调度受各种因素干扰,不一定能够按时执行,所以还可以分为计划调度时间和实际执行时间

    数据时间,这个概念对很多强实时性要求的分片作业系统来说,通常并没有意义,也不是一个必需的环境参数。但对于用在大数据平台业务领域的工作流调度系统来说,却往往是一个重要的参数,重要到可以成为必备参数。

    举例来说,比如,在离线数据业务处理流程中,常见的逻辑是从一天的凌晨开始,批量计算和处理头一天的数据。 这时候,调度日期是T,而数据日期则是T-1。你要说,那不能固定的认为数据日期就是T-1么?脚本根据调度时间,自己位移并计算数据时间就好了呗。

    可惜的是,即使抛开用户使用成本不说,这种假设在很多情况下也是不成立的。比如,你在今天重刷3天前的作业,需要处理的数据是T-4呢?比如,如果你的任务是短周期小时任务,时间位移是以小时为单位呢?

    所以,我们的做法是调度时间和数据时间是分离的,用户主动调度任务时后者可以独立设置。而对于系统定时生成的周期性作业的数据时间,则是通过作业调度计划和作业周期类型自动判断并生成的,然后以环境变量参数的形式传递给具体任务。

    爱思考的同学可能还会问,那只有数据时间可不可以?调度时间好像没啥用。应该说对于作业自身运行逻辑来说,这可能比只有调度时间好很多,但是还是有些场合需要调度时间参数,此外,更重要的是,调度时间是调度系统用来管理作业调度生命周期的重要依据,反正是系统运转不可或缺的部分,那多传给作业一些信息也没啥坏处。

    支持灰度功能,允许按特定条件筛选作业按照特定的策略灰度执行

    没有不下线的系统,没有不犯错的人。降低系统变更风险的最好办法就是不变更。。。其次,是局部变更,验证,再整体变更,也就是所谓的灰度发布

    我司Jarvis 2系统的灰度服务功能,其设计目标包含了两个层面的内容,一个是和自身系统升级等相关的灰度,另一个是业务层面的灰度。

    举个例子,比如调度系统对接的Hive执行后端想要升级,那么能不能先灰度一部分Hive作业跑在新版本的Hive执行引擎上,先验证一下脚本/语法的兼容性和性能呢?这个动作能不能不需要修改任何脚本,对用户也是透明的呢?

    再比如,一部分业务逻辑我想换一种执行方式,比如出于快速验证性能或流程的目的,一批作业想要dummy执行。

    我们当前的实现方式,是让用户根据各种作业属性信息,创建规则,筛选出一批作业,然后按照一定的灰度比例定向发布到特定的机器(worker)上去执行。



    这种方式,可以处理大部分通过执行器(部署在worker上)的变更就能够完成的灰度任务(比如前面提到的灰度升级Hive版本),理论上多数的任务也一定可以通过这种灰度手段来完成,只是代价大小的问题。。

    对于无法低成本的通过执行器变更完成的任务,比如,修改作业自身的业务参数或者运行变量之类,理论上我们只需要增加更多的灰度手段就好,灰度的筛选规则和整体流程,用户交互形式都可以保持不变。不过,难点是可能有些灰度手段会涉及到调度组件自身功能逻辑的一些变更,目前看来这方面的需求不太明显,但是一个可以改进的方向。

    根据血缘信息,自动建立作业依赖关系

    从作业脚本中自动分析血缘关系,然后自动建立作业的依赖关系,当然是为了进一步降低用户构建工作流拓扑逻辑的代价。

    试想,很多情况下,用户可能只知道自己的任务读取的是哪张表的数据,但根本不知道或者不关心这个表是由哪个作业任务生成的,是什么时候生成的。那他如何能够定义出作业的依赖关系呢?去找上游业务负责同学打听么?更糟糕的情况是,如果将来生成这个表的作业发生了变更,换成另外一个作业了怎么办?

    所以,如果能够降低这部分工作的难度,对于维护准确的作业拓扑逻辑关系,保障业务的正确稳定运行还是有很大价值的。而对用户来说,如果他只需要开发脚本,然后提交,作业依赖关系依托系统自动搞定,对于提高工作效率来说,也应该是极好的。

    但是自动分析作业血缘关系这件事并不容易,目前,我们只实现了针对Hive脚本和部分我们自身系统生成的Shell脚本的血缘关系分析。

    由于涉及语法分析,所以如果不是文本/SQL形式的作业,而是比如MR作业或者Java作业,那么,自动分析依赖关系基本上是不太现实的,所以我们也提供给用户人工编辑依赖关系的选择。毕竟,本质上,作业的依赖关系最终还是要由用户说了算。

    任务日志分析,自动识别错误原因和类型

    维护开发平台的同学应该多少都有些体会,但凡作业跑出问题了,不管Log日志记录有多么详细,哪怕错误原因日志里都明确写出来了,总还会有一些业务开发同学会第一时间来找你。你要问他为什么就不能先翻一下日志,或者先谷歌一下呢?他可能会告诉你,哦,日志太长了,没看见呀,或者是,看不懂呀~~~

    说实话,这也不能完全怪他(她)们,有人靠着多容易啊,再说,有时候人家压根也就没想好好研究脚本该怎么写,正确的业务流程应该是怎样的,还有GMV指标要背呢,没空自己排错,你帮我排错多好。所以要想改变用户,基本是不现实的,想要不被琐事累死,还是要靠自己啊。

    比如,自动分析运行日志,识别常见的错误模式,明确的告诉用户错误类型,如果可能,告知解决方案。




    不过,你可能会说,这很好,但是这和调度系统好像并没有太直接的关系啊。应该是做为开发平台整体功能的一部分。

    是的,虽然从服务用户的角度来说,任务日志分析好像更多的是脚本业务逻辑开发方面的辅助功能。但其实,从作业运行管理的角度来说,还是有一定关系的。

    比如,你可以通过任务错误的类型,来决定该任务是否需要重试。如果是语法错误,显然没必要重试了。如果是集群错误或者DB超时之类,没准重跑一下是可行的。

    再比如,你还可以通过错误的类型,来决定要向谁发送错误报警。如果是业务逻辑,语法之类的问题,那么报警给业务Owner,如果是集群,执行引擎,网络之类的问题,那么发给业务方可能也没用,还是发给平台维护同学来处理更好一些

    以上功能,我司的Jarvis 2系统当前只实现了一部分,毕竟错误的类型多种多样,情况复杂,要做到智能识别,并不容易。

    Jarvis 2 现状和将来

    最后再总结一下我司Jarvis 2 系统的现状,以及将来想要改进的方向

    现状和问题

    整体来说,本文前面所描述的一众设计目标,Jarvis 2系统基本上都已经实现了。经过快两年的开发和持续改进过程,当前,Jarvis 2调度系统日常大概日均承载约2万个周期调度作业,以及大致数量级的一次性任务作业和重刷任务作业。由于系统自身原因造成的大规模系统故障已经非常罕见。

    但是,当前整体系统的流程逻辑,有些部分的实现过于定制化,为了降低开发难度,还有一些偏外围的业务逻辑被耦合到了核心调度流程中,不利于系统功能的后续拓展和调整。

    此外,如果负载相对平均的话,稳定承载到10万个/日以上的作业,估计问题不大,但是在突发峰值或者极端高负载情况下的系统稳定性和节点失效恢复能力,尤其是在高负载大流量情况下,遇到系统硬件,内存,DB或网络异常问题时,能否较好的进行容错处理,还是需要经历更多的复杂场景来加以磨练的。

    产品改进目标

    系统自身的稳定性,部分既有逻辑的梳理重构,这些太过细节,你也未必关心,所以我就不说了,下面主要谈谈产品形态方面的改进目标

    系统整体业务健康度检测和评估手段改进

    为了保障系统的健康运行,监控当然是必不可少的,从系统监控的维度来说,大致会有几种做法:

    首先是硬件指标层面的监控,比如监控一下CPU/内存/IO / 网络的使用情况,只要想去做,实施起来都不难。

    其次是系统和进程层面的监控,比如服务是否存活,进程有没有假死,GC情况等等,稍微麻烦一点,但也不是什么困难的事

    再进一步的,是组件和链路层面的监控,比如各功能调用的链路跟踪记录,比如各组件和功能模块自身Metrics的统计,这些相对来说,实现起来就复杂很多了。

    以上这些监控手段,对于分析具体的故障和问题来说,是有帮助的,但是对于工作流调度系统这样一个关联系统众多,承载了大量用户自行定义的业务逻辑的复杂系统来说,往往还是不够的,这点我们深有体会。

    举个例子,比如,某天凌晨,你突然被大批的作业延时报警吵醒,怎么办?什么原因? 最幸运的情况是你发现前面有作业失败(有报警,没吵醒你),阻塞了后面的作业运行,那么,赶紧针对性的分析一下好了。但是如果没有作业失败呢?系统进程看起来也都活着,后端Hadoop集群负载? 和平时也没有太大区别,甚至有可能,多半比平时还要低很多(不正常,但是,为什么?)

    你想看一下具体某个超时未运行的作业是什么情况,可是依赖链路复杂,上游有十几层依赖上千个作业,有些作业完成了,有些还没有。检查了一下部分上游执行完毕的作业,也没有发现明显的异常,就是触发执行的时间比以前晚了,实际运行时间,有些长了,有些还更短了,具体变长变短是否属于正常,不好说。。。

    上面的例子毕竟还有迹可查,更难搞一点的例子,比如有一天你发现最近主要的离线批处理作业流程,整体产出时间,平均同比上个月推迟了两个小时,但是这个变化是渐进的,找不到某一天开始有明显变化的点。事实上,受各种因素影响,这些作业流程的产出时间,日常的波动范围也在一个小时到两个小时之间,所以每天的环比根本看不出问题来,只是放大时间范围来看,总体趋势在变坏中。。。

    所以是整体数据量变化导致的么?是某些组件负载或者容量趋近瓶颈,性能缓慢变差的原因么?是最近业务方太闲,写了很多脚本,模型越来越复杂导致的么?还是局部某个作业,脚本写法不科学,数据不断累积,数据倾斜日益严重拖累了下游业务?千头万绪,你能够如何入手展开分析?

    上述问题之所以难解决,本质的原因还是在于可能导致问题的相关因素太多,信息过于繁杂,难以快速甄别有用信息。可能的解决方法,比如:广泛的收集各种维度的业务历史信息和系统环境信息,将日常实践中总结出来的各种分析的手段和问题排查模式固化下来,实时自动化的进行统计和汇总。即使不能自动发现问题,也可以抽象出更精简的数据,或者通过图形化的方式将各种数据汇总比对,提高分析问题的效率。

    具体的手段我们还需要在将来更多实践和思考,可能的做法,随便举个例子,比如:

    将作业执行的各种相关信息和流水记录,实时格式化的导入数据库,接入自定义报表可视化分析系统,便于随时进行各种多维度的统计分析和问题挖掘

    • 比如分析所有作业的执行时间的历史变化趋势,及时监测异常变化的作业

    • 比如按特定链路,特定类型,特定业务组,特定时间段,汇总统计作业的变化趋势

    • 按照各种组合条件灵活进行挖掘分析。


    统计分析是一方面,更重要的是,在此基础上,可以更好的结合历史数据,判断当前业务的健康情况,或者预测将来系统的行为,比如一批任务还需要多长时间,多少资源才能完成。

    个人业务视图的改进

    多租户场景下,用户需要看到自己维护的作业,而如果是一个团队共同负责一部分业务,那么还会需要看到自己的用户组相关的作业,再然后,做为系统或具体业务组的管理员,则往往需要更大范围内的全局视图。

    所以在业务众多的情况下,如何规划好个人业务视图,让各种条件的检索更佳快捷方便,也会对平台的效率和易用性产生影响,目前Jarvis更多的是提供按需过滤的方式,在全局视图中筛选出个人所关注的业务。这么做功能可以实现,但是操作想对繁杂,尤其是用户在多种角色中切换的时候,这方面的应用形态还需要进一步改进

    此外,业务维度的资源汇总情况,比如每天跑的任务统计,资源消耗,健康程度,变化情况等等,也应该更好的按不同维度(个人/业务组/全局等)汇总展示给用户,方面用户随时掌控和调整自身业务

    归根到底,只有用户清晰的掌握了自身业务的状态,才有可能减少犯错,提高工作效率,从而减少需要平台开发者介入帮助处理的情况

    业务诊断专家系统的改进

    目前我们提供了部分作业的错误原因分析,但是对于没有出错的业务的健康度的诊断,或者一批业务失败原因的快速综合诊断能力还不够。

    比如某个任务跑得慢,是因为GC,还是数据量变化,是因为集群资源不够,还是自身业务在某个环节被限流?各种情况下,用户该如何应对解决,能否自动给出建议?

    此外,是否能够定期自动诊断,及时提醒用户,敦促用户自主优化?避免问题积压到影响业务正常运行的时候才被关注。

    自动测试体系的完善开源

    固定的单元测试对当前Jarvis系统在大流量负载,复杂并发场景下潜在的Bug的发现,还是不够的,需要构建更加自动的,随机生成测试用例以及模拟和再现组件失效模式的测试体系。

    这方面,理想很好,要真正实践起来,还是有很大难度的。

    开源

    开源严格的说不是一个目标,是一个手段,是用来提高产品质量的一个有效手段。

    但开源也绝对不能像国内多数公司那样,只是开放代码,而没有开放思想。

    开放代码很简单,只要你不偷不抢,使用别人的代码还不遵守版权协议。但是,光秃秃的代码放在那里,再加一个几百年不更新的README,你以为就叫开源了么?那不是开源,那是晒代码。

    开放思想就难得多了,开源的目的是让大家一起参与,共同提高项目质量,共同受益,既不是单向输出,也不要奢望别人无偿奉献。要做到这一点,首先,维护者得花费大量的精力去维护社区的氛围,包括:

    • 解耦项目的公司内部逻辑功能模块,提供替换机制,做到外部真正可用。
    • 提供目标需求,场景说明文档,项目计划,Road Map等
    • 提供当前项目架构解析,关键技术说明,常见问题指南, 安装使用维护说明等。
    • 提供问题反馈途径,及时解答社区问题
    • 代码单元/集成测试手段和代码评审机制

    只有做到这些,才能构建起健康的开源项目环境,才能真正对外输出价值,同时从社区汲取有益的帮助,而要做到这些,花费的精力绝对是巨大的,所以不要指望通过开源来节省自己的精力 ;)

    小结

    工作流调度系统是开发平台的核心组件,要做得完善并不容易,而且根据你自己的业务环境需求不同,选择怎样的路径并没有固定的套路,我们所走的路,所选择的产品形态,未必适合你的场景。

    使用开源产品,二次开发,还是完全自研,没有绝对对错,理解用户需求,了解现有产品局限性,评估自研代价和收益价值,才是最重要的。当然,现实是,没有实践可能也无从评估,所以,如果没有把握,找一个目标场景最接近的系统先用着,在实际使用中去发现问题,总结需求。


    常按扫描下面的二维码,关注“大数据务虚杂谈”,务虚,我是认真的 ;)


    展开全文
  • 2010年左右,还是在上学的时候,学过一门课程叫《数据仓库与数据挖掘》,那还是属于传统数据的时代,我们会讨论什么是数据仓库?什么是数据集市?数据仓库和数据库有什么区别?等等,当我还在苦苦学习这些之时,...
  • 作者 |June来源 | 智领云科技(ID:LinkTimeCloud)造概念,在 IT 行业可不是一件陌生的事儿,中文博大精深,新名词、新概念往往简单准确,既可以被大众接受,又可以被...
  • 数据平台投标方案模板

    千次阅读 2017-04-07 19:20:31
    随着信息化程度的加深,以及移动互联网、物联网的崛起,人们产生的数据急剧膨胀,传统的数据处理技术难以支撑数据大量的增长和处理能力。经过近几年的发展,大数据技术逐步成熟,可以帮助企业整合更多的数据,从海量...
  • 是如何保证数据的不重复?也就是说每次取数据都要按照时间字段做限制?还是说不需要关心这个,他给什么就收什么?是多线程的吗,实时保持通信?望好心人做做解答。多谢
  • 同志们辛苦了,为人民服务~
  • 数据平台初试(技术篇)——抖音数据采集(高级版) ​ 上一篇文章讲了如何对采集的数据进行抓包和解析,本次主要讲解如何使用自动化工具,实现自动化数据采集。如果想了解抓包和解析部分的内容,可以查阅我的上一篇...
  • 数据库自动化运维平台--元数据平台

    千次阅读 2017-04-12 15:00:08
    数据库元数据平台 很多DBA可能都用过Excel来维护数据库集群列表,在公司数据库集群规模比较小,用这种方式维护也是很简单方便的。但随着数据实例越来越多达到了上百上千的时候,再用这种方式维护就要崩溃了。所以...
  • 工业互联网:4 数据平台

    千次阅读 2018-11-25 15:53:33
    4 数据平台 为什么会有物联网的数据平台呢?从某种程度上说,数据平台才是最具物联网特色的东西。虽然提到物联网,很多人脑海中第一个闪现的是传感网络,但实际上,如果你读过前几章就会发现,实际上所谓物联网,...
  • 美团点评数据平台融合实践

    千次阅读 2017-08-25 19:00:00
    原来完全独立甚至相互竞争的两家公司,有着独立的技术体系、平台和团队,如何整合,技术和管理上的难度都很大。2015年10月,美团与大众点评合并为今天的“美团点评”,成为全球规模最大的生活服务平台。主要分布在...
  • 目录数据平台数据中台数据平台与数据中台的区别与联系区别联系整体架构硬件层&虚拟化数据平台存储能力计算能力管理平台数据中台数据仓库数据集市数据开发数据运维赋能对象赋能管理者赋能业务运营赋能业务中台...
  • 数据平台调度系统的设计

    千次阅读 2015-01-02 15:05:50
     1 能定时发起各类型的任务 1.1 任务类型比如 shell脚本,或者jar 程序,或者调用存储过程 ...1.3 数据平台一般的任务类型有:  1.3.1 101任务: 检查数据源文件是否到齐(包括文件个数,或者
  • 汽车之家数据平台架构

    千次阅读 2015-04-27 09:22:10
    汽车之家数据平台架构 互联网企业数据仓库构建是采用自下而上的方式,还是自上而下的方式?如果你是一个数据部门的架构师,你怎样去规划数据仓库呢?2015年中国数据库技术大会上,来自汽车之家用户智能组的高...
  • 一、需求分析 ...字段:排序 平台名称 成交额 综合利率 投资人 借款周期 借款人 满标速度 累计贷款余额 资金净流入二、rvest爬虫实现源代码rm(list=ls()) gc() options(scipen = 200) library('rvest') timest
  • 阿里巴巴数据平台火热招聘中

    千次阅读 2013-12-08 22:15:24
    阿里大脑-智能数据平台项目招聘 分布式系统研发工程师 1、拥有C++大型系统开发经验 2、在以下领域之一有大型生产系统研发经验  -大型分布式系统开发  -大流量和高性能在线服务设计和性能调优领域有实践...
  • GemFire分布式内存数据平台的原理

    千次阅读 2013-12-31 22:17:21
    GemFire分布式内存数据平台的原理为: 通过云计算平台虚拟化技术,将若干X86服务器的内存集中起来,组成最高可达数十TB的内存资源池,将全部数据加载到内存中,进行内存计算。计算过程本身不需要读写磁盘,只是定期...
  • 先大概列一下互联网行业数据仓库、数据平台的用途: 整合公司所有业务数据,建立统一的数据中心;提供各种报表,有给高层的,有给各个业务的;为网站运营提供运营上的数据支持,就是通过数据,让运

空空如也

1 2 3 4 5 ... 20
收藏数 131,131
精华内容 52,452
热门标签
关键字:

数据平台