数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。
数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。
数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。
单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。
显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。
数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。
“面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。
“与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。
“不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此，数据仓库中的数据是极少或根本不修改的;当然，向数据仓库添加数据是允许的。
数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。
补充一下，数据仓库的方案建设的目的，是为前端查询和分析作为基础，由于有较大的冗余，所以需要的存储也较大。为了更好地为前端应用服务，数据仓库必须有如下几点优点，否则是失败的数据仓库方案。
1.效率足够高。客户要求的分析数据一般分为日、周、月、季、年等，可以看出，日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。由于有的企业每日的数据量很大，设计不好的数据仓库经常会出问题，延迟1-3日才能给出数据，显然不行的。
2.数据质量。客户要看各种信息，肯定要准确的数据，但由于数据仓库流程至少分为3步，2次ETL，复杂的架构会更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据失真，客户看到错误的信息就可能导致分析出错误的决策，造成损失，而不是效益。
3.扩展性。之所以有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，这样的话，客户不用太快花钱去重建数据仓库系统，就能很稳定运行。主要体现在数据建模的合理性，数据仓库方案中多出一些中间层，使海量数据流有足够的缓冲，不至于数据量大很多，就运行不起来了。
参考资料：http://searchdatabase.techtarget.com.cn/tips/229/2313729.shtml
其中A工为国内某知名分销软件的总经理，银行系统出身，是IT方面的技术专家，虽然我自己也是软件开发出来的，但对于他在对行业业务的了解，对于软件开发、系统架构方面的本领可也是佩服的紧的；B顾问也是为国内知名的咨询公司的顾问，博士，认识时间不长，但也是受教不浅。
现在也听听他们是如何说数据仓库与BI的吧：
我与B顾问的讨论如下：
2006-4-12
20:35:42
Drate
B顾问
*老师，晚上好。
2006-4-12
20:36:09
Drate
B顾问
今天参加了IT规划成果的展示会，对于集团的整体信息规划算是了解了一个大概
2006-4-12
20:37:07
B顾问
Drate
H经理讲得如何？
2006-4-12
20:38:07
Drate
B顾问
嗯，说实话，我感觉针对有准备的内容讲的还算可以，但对于讨论的环节似乎回答问题还不能到点上
2006-4-12
20:38:49
Drate
B顾问
当然，对于有准备的内容，似乎讲的过程缺乏一些互动吧。:$，从听众的角度说的
2006-4-12
20:39:09
B顾问
Drate
喔，前面的内容是我和他一起准备的，后面的问题没有准备，不知他怎么回答的。
2006-4-12
20:39:33
B顾问
Drate
好像业务部门的反馈还可以。
2006-4-12
20:40:00
Drate
B顾问
嗯，整体来说是不错的了，而且说了这么多，一些需要说明的内容也说清楚了
2006-4-12
20:41:29
Drate
B顾问
只不过是我们可能会更挑剔一些吧
2006-4-12
20:41:54
B顾问
Drate
是的，每个人的水平不一样，理解也不一样。
2006-4-12
20:42:11
B顾问
Drate
其实那个金字塔和季节主线以及BI是可以将得非常精彩的。
2006-4-12
20:42:55
Drate
B顾问
是的，这一部分的内容与业务结合起来讲的话，将是出彩的一个部分
2006-4-12
20:43:26
B顾问
Drate
H经理现在基本理解了我们当初所说的意思，但是还是不深刻的。
2006-4-12
20:43:52
Drate
B顾问
但其实我自己心里还是有疑问的，也正好可以请教你，一般来说，BI是在有一定的数据积累才开始做的，而在目前的情形上就先上BI的系统，这合适吗？
2006-4-12
20:44:13
B顾问
Drate
这是很多人的误区
2006-4-12
20:44:31
B顾问
Drate
也是ERP厂商给客户带来的误区。
2006-4-12
20:44:44
B顾问
Drate
害了很多人。
2006-4-12
20:44:56
Drate
B顾问
看来我也是受害者之一。
2006-4-12
20:45:47
B顾问
Drate
其实象J公司现有系统的数据已经足够多了，但是没有充分利用起来，而且高层看不到效果，这是很致命的问题。
2006-4-12
20:45:54
Drate
B顾问
但“巧妇难为无米之炊”，没有数据积累，如何进行BI的相关工作，这也说的通呀。
2006-4-12
20:46:30
Drate
B顾问
嗯，也就是说，现有的系统积累的数据虽然是片段的、但目的还是需要考虑到应用是吧。
2006-4-12
20:46:47
B顾问
Drate
怎么“无米”呢
2006-4-12
20:47:03
Drate
B顾问
嗯，这就涉及到前期的数据仓库的问题了
2006-4-12
20:47:08
B顾问
Drate
现有的系统和金蝶大量的数据就是米啊
2006-4-12
20:47:18
B顾问
Drate
否则我们怎么做报表
2006-4-12
20:47:27
B顾问
Drate
刚开始做BI，不要寄很高的期望
2006-4-12
20:48:22
B顾问
Drate
把现在手头的报表实现，然领导任意角度观察和钻探，这是很大的进步呢，然后在此基础上有些提升就非常好了。
2006-4-12
20:48:36
Drate
B顾问
这里的米就涉及到“米”中含有的“沙”的含量有多少的问题了。数据仓库，其实更多的是由咨询顾问对企业进行建模然后，需要对原有数据进行一个“数据清洗”的过程的，而原来他们这些数据是否应该会有这一个槛要过的？
2006-4-12
20:49:15
B顾问
Drate
完全没有必要担心，这是一个正反馈机制，先有后好
2006-4-12
20:49:45
B顾问
Drate
如果领导用了发现数据标准，自然会促使系统的数据更准确
2006-4-12
20:49:55
B顾问
Drate
而不是期望数据好了以后再上。
2006-4-12
20:50:40
B顾问
Drate
如果说因为数据不好，不上BI，那报表怎么办？
2006-4-12
20:50:50
B顾问
Drate
还不是从系统中来的？
2006-4-12
20:51:00
Drate
B顾问
嗯，我们原来一直的方向是，报表是直接从系统中来
2006-4-12
20:52:03
Drate
B顾问
只是我们可能把BI这一块的功能更多的上升到了一个高度，认为它是带有一些“神秘”色彩的高级玩艺。
2006-4-12
20:54:06
B顾问
Drate
一点不神秘，从技术角度比报表容易多了，从管理角度比报表灵活多了。
2006-4-12
20:56:01
Drate
B顾问
呵呵，是这样的，今天看了一下H经理的演示，感觉是非常灵活，而且管理层会比较容易接受
2006-4-12
21:32:11
B顾问
Drate
不好意思，刚才有人来了。
2006-4-12
21:32:32
B顾问
Drate
我觉得你也可以考虑用这个东西，比较便宜的。
我与A工的讨论如下：
2006-04-12 15:05:42 小虫(Drate)
呵呵，正好，今天参加集团公司的IT规划成果会议，下午他们还在继续呢
2006-04-12 15:05:56 A工
整个集团的？：）
那是大手笔了：）
2006-04-12 15:07:22 小虫(Drate)
是呀，比较夸张的
2006-04-12 15:08:16 A工
好啊
这么宏伟
我们切一小块就知足了：）
2006-04-12 15:09:32 A工
DRP VIP POS 第一阶段
ERP 第二阶段
后面的我就没什么意见了
太高了：）
2006-04-12 15:10:13 小虫(Drate)
当然，目前他们在做的是BI和数据仓库，这个你想不到吧
2006-04-12 15:10:05 A工
这个反而先做？！
2006-04-12 15:10:13 A工
不可思议
哪来数据？
2006-04-12 15:10:50 小虫(Drate)
今年他们要启动BI、数据仓库、协同办公、DRP这几个项目呢
2006-04-12 15:11:12 小虫(Drate)
用他们原来老的系统的数据吧，而且现在已经在找供应商了吧
2006-04-12 15:19:35 小虫(Drate)
他们这个蓝图说实现起来的话，要投资****万，听了有些害怕
2006-04-12 15:21:56 A工
这是他们的长处吧
我是农民
只知道稻子怎么从田里种出来
至于商人们怎么包装去忽悠顾客
说包治阳萎肾虚
那就不关我们事情了：）
2006-04-12 15:22:22 A工
drp *** 万
那就找国外的了
2006-04-12 15:22:56 A工
不知道A公司和国外哪一家合作
国内的现在他们主要是和B公司
2006-04-12 15:24:08 小虫(Drate)
呵呵，他们的话有和B公司接触，但B公司据我所知的话，做的都是小企业的了
2006-04-12 15:24:03 A工
可是B公司很会吹
2006-04-12 15:24:31 A工
他们的系统
我随意可以删掉数据库
不想公布而已
呵呵
2006-04-12 15:25:15 A工
没有必要太狠
不过他们很多时候行径太恶劣了
呵呵
2006-04-12 15:26:02 小虫(Drate)
呵呵，但这个很现实的，这么大一个系统，不是靠吹出来的，上次吃饭的时候，我和老肖觉的，如果要做分销的话，你们的和BJ的可以考虑，如果用国外的系统的话，估计难度更高，而H经理还有想法是上SAP，但自己心里没有底，估计也不知道如何做选择呢
2006-04-12 15:28:11 小虫(Drate)
关键还是没有一个主心骨吧，现在在上BI的，说实话，这个太玄了，感觉这个东西麻烦大大的
2006-04-12 15:27:55 A工
BJ也是流氓：）
我们在苏州快签下来的单子
他们一去就许诺给客户20万
还好没得逞
其它项目就不说了
他们的系统是终端仿真的
只是门店用了.net
2006-04-12 15:29:46 A工
BI主要的问题不是软件
2006-04-12 15:30:00 A工
是企业自己建模
2006-04-12 15:30:26 小虫(Drate)
呵呵，其实打单的时候，估计都会用手段。
2006-04-12 15:30:07 A工
软件都很成熟的
2006-04-12 15:30:21 A工
是的，很正常
就是造谣太厉害了
2006-04-12 15:30:44 小虫(Drate)
嗯，他们现在没有这个概念吧，他们把BI和数据仓库还是定位为软件系统
2006-04-12 15:30:34 A工
BI和数据仓库绝对不是软件
2006-04-12 15:30:46 A工
软件的成分远远低于DRP
2006-04-12 15:31:32 小虫(Drate)
但他们现在连软件都选好了，正一股脑的向上面上去呢
2006-04-12 15:31:33 A工
我都有些想退出江湖了：）
不是全退
是商业的事情不干
2006-04-12 15:32:22 小虫(Drate)
嗯？怎么个说法？找个CEO来做商务的事情？
2006-04-12 15:32:11 A工
国外帮人家上BI
主要是咨询专家
而不是软件工程师
2006-04-12 15:32:45 A工
呵呵，有合适的人就交出去了
这方面我不擅长
如果哪一天
发现技术也不擅长
那就幸福咯
2006-04-12 15:33:29 小虫(Drate)
呵呵，不过这个BI的东西主要是H集团的高层想要用吧，但也没有人提出反对
2006-04-12 15:34:34 A工
领导兴头上
下面不反对是正常的：）
2006-04-12 15:35:27 小虫(Drate)
呵呵，但至少也进行一个说明吧，有些是基本的过程总是要遵守的
2006-04-12 15:36:37 A工
到时候就说IT不好，其它部门的人是不用承担责任的
2006-04-12 15:37:49 小虫(Drate)
我今天听了一天的会下来，总之就是觉的玄!!!所以的话，这个玄的话就是高风险了
2006-04-12 15:39:32 A工
是的
后果不是钱的问题
因为实际上投入一些钱后
看不对劲
就会停下来的
麻烦的是
以后对上这类项目大家都怕了
2006-04-12 15:40:13 A工
我们现在一个客户
哈森
很大的
就有这个问题
跑到哪里
大家都说
那就看看吧
以前都失败几次了
没信心了
2006-04-12 15:41:07 小虫(Drate)
嗯，是呀，所以的话，折腾不成的话，基本上信息化到H集团的话是很难会有什么起色的了
========================
跟两位聊完，其实倒还真的是把我给聊糊涂了，呵呵，看来还是需要自力更生，需要自己再去找答案。
注：以上内容主要是为了抛出来供大家讨论用，请不要胡乱猜测，对号入坐，当然，如果当事人看到，请包含一二，以上内容以讨论为主，同时我也隐掉了关键性的名词，望海涵。
http://www.learn-it.cn/Info_9134.htm
首先我们来了解数据仓库和数据库分别是什么：
1、数据库:是一种逻辑概念，用来存放数据的仓库，通过数据库软件来实现。数据库由很多表组成，表是二维的，一张表里面有很多字段。字段一字排开，对数据就一行一行的写入表中。数据库的表，在于能够用二维表现多维的关系。如：oracle、DB2、MySQL、Sybase、MSSQL Server等。
2、数据仓库：是数据库概念的升级。从逻辑上理解，数据库和数据仓库没有区别，都是通过数据库软件实现存放数据的地方，只不过从数据量来说，数据仓库要比数据库更庞大德多。数据仓库主要用于数据挖掘和数据分析，辅助领导做决策；
区别主要总结为以下几点：
1.数据库只存放在当前值，数据仓库存放历史值；
2.数据库内数据是动态变化的，只要有业务发生，数据就会被更新，而数据仓库则是静态的历史数据，只能定期添加、刷新；
3.数据库中的数据结构比较复杂，有各种结构以适合业务处理系统的需要，而数据仓库中的数据结构则相对简单；
4.数据库中数据访问频率较高，但访问量较少，而数据仓库的访问频率低但访问量却很高；
5.数据库中数据的目标是面向业务处理人员的，为业务处理人员提供信息处理的支持，而数据仓库则是面向高层管理人员的，为其提供决策支持；
6.数据库在访问数据时要求响应速度快，其响应时间一般在几秒内，而数据仓库的响应时间则可长达数几小时
一直想整理一下这块内容，既然是漫谈，就想起什么说什么吧。我一直是在互联网行业，就以互联网行业来说。先大概列一下互联网行业数据仓库、数据平台的用途：
整合公司所有业务数据，建立统一的数据中心；
提供各种报表，有给高层的，有给各个业务的；
为网站运营提供运营上的数据支持，就是通过数据，让运营及时了解网站和产品的运营效果；
为各个业务提供线上或线下的数据支持，成为公司统一的数据交换与提供平台；
分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果；比如广告定向精准投放、用户个性化推荐等；
开发数据产品，直接或间接为公司盈利；
建设开放数据平台，开放公司数据；
。。。。。。
上面列出的内容看上去和传统行业数据仓库用途差不多，并且都要求数据仓库/数据平台有很好的稳定性、可靠性；但在互联网行业，除了数据量大之外，越来越多的业务要求时效性，甚至很多是要求实时的 ，另外，互联网行业的业务变化非常快，不可能像传统行业一样，可以使用自顶向下的方法建立数据仓库，一劳永逸，它要求新的业务很快能融入数据仓库中来，老的下线的业务，能很方便的从现有的数据仓库中下线；
其实，互联网行业的数据仓库就是所谓的敏捷数据仓库，不但要求能快速的响应数据，也要求能快速的响应业务；
建设敏捷数据仓库，除了对架构技术上的要求之外，还有一个很重要的方面，就是数据建模，如果一上来就想着建立一套能兼容所有数据和业务的数据模型，那就又回到传统数据仓库的建设上了，很难满足对业务变化的快速响应。应对这种情况，一般是先将核心的持久化的业务进行深度建模（比如：基于网站日志建立的网站统计分析模型和用户浏览轨迹模型；基于公司核心用户数据建立的用户模型），其它的业务一般都采用维度+宽表的方式来建立数据模型。这块是后话。
整体架构下面的图是我们目前使用的数据平台架构图，其实大多公司应该都差不多：
请点击输入图片描述
逻辑上，一般都有数据采集层、数据存储与分析层、数据共享层、数据应用层。可能叫法有所不同，本质上的角色都大同小异。
我们从下往上看：
数据采集数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些简单的清洗。
数据源的种类比较多：
网站日志：
作为互联网行业，网站日志占的份额最大，网站日志存储在多台网站日志服务器上，
一般是在每台网站日志服务器上部署flume agent，实时的收集网站日志并存储到HDFS上；
业务数据库：
业务数据库的种类也是多种多样，有Mysql、Oracle、SqlServer等，这时候，我们迫切的需要一种能从各种数据库中将数据同步到HDFS上的工具，Sqoop是一种，但是Sqoop太过繁重，而且不管数据量大小，都需要启动MapReduce来执行，而且需要Hadoop集群的每台机器都能访问业务数据库；应对此场景，淘宝开源的DataX，是一个很好的解决方案（可参考文章 《异构数据源海量数据交换工具-Taobao DataX 下载和使用》），有资源的话，可以基于DataX之上做二次开发，就能非常好的解决，我们目前使用的DataHub也是。
当然，Flume通过配置与开发，也可以实时的从数据库中同步数据到HDFS。
来自于Ftp/Http的数据源：
有可能一些合作伙伴提供的数据，需要通过Ftp/Http等定时获取，DataX也可以满足该需求；
其他数据源：
比如一些手工录入的数据，只需要提供一个接口或小程序，即可完成；
数据存储与分析毋庸置疑，HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。
离线数据分析与计算，也就是对实时性要求不高的部分，在我看来，Hive还是首当其冲的选择，丰富的数据类型、内置函数；压缩比非常高的ORC文件存储格式；非常方便的SQL支持，使得Hive在基于结构化数据上的统计分析远远比MapReduce要高效的多，一句SQL可以完成的需求，开发MR可能需要上百行代码；
当然，使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使用MapReduce来做分析与计算；Spark是这两年非常火的，经过实践，它的性能的确比MapReduce要好很多，而且和Hive、Yarn结合的越来越好，因此，必须支持使用Spark和SparkSQL来做分析和计算。因为已经有Hadoop Yarn，使用Spark其实是非常容易的，不用单独部署Spark集群，关于Spark On Yarn的相关文章，可参考：《Spark On Yarn系列文章》
实时计算部分，后面单独说。
数据共享这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库；
前面使用Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但大多业务和应用不可能直接从HDFS上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据； 和数据采集层到HDFS刚好相反，这里需要一个从HDFS将数据同步至其他目标数据源的工具，同样，DataX也可以满足。
另外，一些实时计算的结果数据可能由实时计算模块直接写入数据共享。
数据应用
业务产品
业务产品所使用的数据，已经存在于数据共享层，他们直接从数据共享层访问即可；
报表
同业务产品，报表所使用的数据，一般也是已经统计汇总好的，存放于数据共享层；
即席查询
即席查询的用户有很多，有可能是数据开发人员、网站和产品运营人员、数据分析人员、甚至是部门老大，他们都有即席查询数据的需求；
这种即席查询通常是现有的报表和数据共享层的数据并不能满足他们的需求，需要从数据存储层直接查询。
即席查询一般是通过SQL完成，最大的难度在于响应速度上，使用Hive有点慢，目前我的解决方案是SparkSQL，它的响应速度较Hive快很多，而且能很好的与Hive兼容。
当然，你也可以使用Impala，如果不在乎平台中再多一个框架的话。
OLAP
目前，很多的OLAP工具不能很好的支持从HDFS上直接获取数据，都是通过将需要的数据同步到关系型数据库中做OLAP，但如果数据量巨大的话，关系型数据库显然不行；
这时候，需要做相应的开发，从HDFS或者HBase中获取数据，完成OLAP的功能；
比如：根据用户在界面上选择的不定的维度和指标，通过开发接口，从HBase中获取数据来展示。
其它数据接口
这种接口有通用的，有定制的。比如：一个从Redis中获取用户属性的接口是通用的，所有的业务都可以调用这个接口来获取用户属性。
实时计算现在业务对数据仓库实时性的需求越来越多，比如：实时的了解网站的整体流量；实时的获取一个广告的曝光和点击；在海量数据下，依靠传统数据库和传统实现方法基本完成不了，需要的是一种分布式的、高吞吐量的、延时低的、高可靠的实时计算框架；Storm在这块是比较成熟了，但我选择Spark Streaming，原因很简单，不想多引入一个框架到平台中，另外，Spark Streaming比Storm延时性高那么一点点，那对于我们的需要可以忽略。
我们目前使用Spark Streaming实现了实时的网站流量统计、实时的广告效果统计两块功能。
做法也很简单，由Flume在前端日志服务器上收集网站日志和广告日志，实时的发送给Spark Streaming，由Spark Streaming完成统计，将数据存储至Redis，业务通过访问Redis实时获取。
任务调度与监控在数据仓库/数据平台中，有各种各样非常多的程序和任务，比如：数据采集任务、数据同步任务、数据分析任务等；
这些任务除了定时调度，还存在非常复杂的任务依赖关系，比如：数据分析任务必须等相应的数据采集任务完成后才能开始；数据同步任务需要等数据分析任务完成后才能开始； 这就需要一个非常完善的任务调度与监控系统，它作为数据仓库/数据平台的中枢，负责调度和监控所有任务的分配与运行。
前面有写过文章，《大数据平台中的任务调度与监控》,这里不再累赘。
总结在我看来架构并不是技术越多越新越好，而是在可以满足需求的情况下，越简单越稳定越好。目前在我们的数据平台中，开发更多的是关注业务，而不是技术，他们把业务和需求搞清楚了，基本上只需要做简单的SQL开发，然后配置到调度系统就可以了，如果任务异常，会收到告警。这样，可以使更多的资源专注于业务之上。
请点击输入图片描述
请点击输入图片描述