s******a
发帖数: 184 | 1 公司准备考虑一个hadoop 的应用， 但现在已有基于SAP 的系统， 和基于 Microsoft
SQL 的系统， 一些 顾问公司提出的建议是把所有SAP和 microsoft SQL 里的data全
load 到 HAHDOOP去。 但管理SAP和Microsoft SQL的 组都不愿意这么做。我也觉得这
不是一个正确的做法。 现在有什么成熟的架构能够只在需要的时候读取 SAP和
microsoft SQL里的data， 而不是在Hadoop上再做一套数据的备份。或者说有什么data
federation layer 的设计能够让hadoop 的 application layer 自由调度存在那些里
的data |
w***g
发帖数: 5958 | 2 SQL的数据为准，然后周期性自动导出到Hadoop上是最可靠的做法。
on-demand从SQL捞数据是个美好的想法，真去做，不但费力，还容易把事情搞砸。
你们的顾问公司太狗屁了。后台很硬吧？
Microsoft
data
【在 s******a 的大作中提到】
: 公司准备考虑一个hadoop 的应用， 但现在已有基于SAP 的系统， 和基于 Microsoft
: SQL 的系统， 一些 顾问公司提出的建议是把所有SAP和 microsoft SQL 里的data全
: load 到 HAHDOOP去。 但管理SAP和Microsoft SQL的 组都不愿意这么做。我也觉得这
: 不是一个正确的做法。 现在有什么成熟的架构能够只在需要的时候读取 SAP和
: microsoft SQL里的data， 而不是在Hadoop上再做一套数据的备份。或者说有什么data
: federation layer 的设计能够让hadoop 的 application layer 自由调度存在那些里
: 的data
|
d******e
发帖数: 2265 | 3 为什么用hadoop这个烂货呢？出发真的是海量数据。否则毫无好处。
Microsoft
data
【在 s******a 的大作中提到】
: 公司准备考虑一个hadoop 的应用， 但现在已有基于SAP 的系统， 和基于 Microsoft
: SQL 的系统， 一些 顾问公司提出的建议是把所有SAP和 microsoft SQL 里的data全
: load 到 HAHDOOP去。 但管理SAP和Microsoft SQL的 组都不愿意这么做。我也觉得这
: 不是一个正确的做法。 现在有什么成熟的架构能够只在需要的时候读取 SAP和
: microsoft SQL里的data， 而不是在Hadoop上再做一套数据的备份。或者说有什么data
: federation layer 的设计能够让hadoop 的 application layer 自由调度存在那些里
: 的data
|
T*******x
发帖数: 8565 | 4 这不是和顾问公司的做法是一样的吗？
【在 w***g 的大作中提到】
: SQL的数据为准，然后周期性自动导出到Hadoop上是最可靠的做法。
: on-demand从SQL捞数据是个美好的想法，真去做，不但费力，还容易把事情搞砸。
: 你们的顾问公司太狗屁了。后台很硬吧？
:
: Microsoft
: data
|
w***g
发帖数: 5958 | 5 我开始理解错了你的帖子了。确实是和顾问公司建议的做法一样。
那顾问公司就是对的。
【在 T*******x 的大作中提到】
: 这不是和顾问公司的做法是一样的吗？
|
s******a
发帖数: 184 | 6 项目 背景是这样的，公司有数据存在各种现有的系统上， 现在希望有一个大数据分析
系统能够对所有这些数据进行综合分析。就是说还是需要把现有数据都在HDFS上做一个
备份。谢谢。
【在 w***g 的大作中提到】
: 我开始理解错了你的帖子了。确实是和顾问公司建议的做法一样。
: 那顾问公司就是对的。
|
T*******x
发帖数: 8565 | 7 这确实是个问题。哪个大牛能给讲讲hadoop的use case到底是什么？
比如把SQL server数据库搬到hadoop上，SQL server上的query改写成hive sql。那肯
定是要比sql server慢的了。那它的意义何在呢？
用spark sql改写sql server query是不是能达到相对较快的速度？但我觉得应该还是
要比sql server慢，可能只是慢的不多而已。
所以use case到底在哪？
【在 d******e 的大作中提到】
: 为什么用hadoop这个烂货呢？出发真的是海量数据。否则毫无好处。
:
: Microsoft
: data
|
T*******x
发帖数: 8565 | 8 谢谢。我在另一个回帖中提问hadoop use case到底在哪？请大牛给解答一下。
【在 w***g 的大作中提到】
: 我开始理解错了你的帖子了。确实是和顾问公司建议的做法一样。
: 那顾问公司就是对的。
|
d******e
发帖数: 2265 | 9 我估计你们的数据其实不大？几十个G?否则sql早搞不定了。
第二,综合分析，也就是etl或者简单统计。
最多上spark.足够了。每种数据写成一个stream source或者用kafka replicate一下。
足够了。
【在 s******a 的大作中提到】
: 项目 背景是这样的，公司有数据存在各种现有的系统上， 现在希望有一个大数据分析
: 系统能够对所有这些数据进行综合分析。就是说还是需要把现有数据都在HDFS上做一个
: 备份。谢谢。
|
s******a
发帖数: 184 | 10 请问这里"用kafka replicate 一下"， 是不是说原有系统里的数据只在需要的时候才
会传到Hadoop上， 并不需要把原有系统， 比如sql 里的全部数据全事先导到Hadoop上。
【在 d******e 的大作中提到】
: 我估计你们的数据其实不大？几十个G?否则sql早搞不定了。
: 第二,综合分析，也就是etl或者简单统计。
: 最多上spark.足够了。每种数据写成一个stream source或者用kafka replicate一下。
: 足够了。
|
|
|
w***g
发帖数: 5958 | 11 对。这么做是最稳妥的。比如每天增量导出，周末全量导出。（如果数据量小，
可以每小时增量导出，每天全量导出，或者把增量部分都去掉。）
这样出活快。
【在 s******a 的大作中提到】
: 项目 背景是这样的，公司有数据存在各种现有的系统上， 现在希望有一个大数据分析
: 系统能够对所有这些数据进行综合分析。就是说还是需要把现有数据都在HDFS上做一个
: 备份。谢谢。
|
w***g
发帖数: 5958 | 12 google的GFS和mapreduce是05年左右发的paper。发paper的时候他们内部应该用了几年
了。
然后06年的样子hadoop出来，到现在有快１０年了。１０年以前机器的内存没现在这么
大，
CPU也没现在这么快，大数据系统的软件开发也才起步。当时hadoop确实能解决不少问
题。
后来机器内存多了，很多人又发现其实数据没那么大，所以就把hadoop的out-of-core
processing抛弃了，改用spark的in-memory processing。现在hadoop有用的就是
一个HDFS文件系统。直接写mapreduce的应该少了，都是用HDFS上面的ecosystem。
另外需要注意的是这１０年硬件也在发展，传统数据库的处理能力也在增强。
是不是真要用hadoop，得针对具体case分析。
【在 T*******x 的大作中提到】
: 这确实是个问题。哪个大牛能给讲讲hadoop的use case到底是什么？
: 比如把SQL server数据库搬到hadoop上，SQL server上的query改写成hive sql。那肯
: 定是要比sql server慢的了。那它的意义何在呢？
: 用spark sql改写sql server query是不是能达到相对较快的速度？但我觉得应该还是
: 要比sql server慢，可能只是慢的不多而已。
: 所以use case到底在哪？
|
S*******e
发帖数: 525 | 13 同意应对具体的case分析。 我以前曾提过一个我们的例子，用Oracle要花上6-7个小时
，才能对我们20几个市场的一个市场进行一个方面的分析。现在我们用Spark over
Hadoop Yarn, 只要几分钟就能完成同样的分析。当然代价是现在的Hadoop Cluster 有
近 400 个 nodes。 Oracle 是 单机 （魏老师也许用C做到几分钟 :) |
T*******x
发帖数: 8565 | 14 那太厉害了。这是铁的use case啊。
不过Oracle那么慢原因是什么啊？是数据量太大？还是很多join？spark如何解决的呢？
【在 S*******e 的大作中提到】
: 同意应对具体的case分析。 我以前曾提过一个我们的例子，用Oracle要花上6-7个小时
: ，才能对我们20几个市场的一个市场进行一个方面的分析。现在我们用Spark over
: Hadoop Yarn, 只要几分钟就能完成同样的分析。当然代价是现在的Hadoop Cluster 有
: 近 400 个 nodes。 Oracle 是 单机 （魏老师也许用C做到几分钟 :)
|
T*******x
发帖数: 8565 | 15 所以现在就是HDFS加spark。那是不是hive也没啥用了？
core
【在 w***g 的大作中提到】
: google的GFS和mapreduce是05年左右发的paper。发paper的时候他们内部应该用了几年
: 了。
: 然后06年的样子hadoop出来，到现在有快１０年了。１０年以前机器的内存没现在这么
: 大，
: CPU也没现在这么快，大数据系统的软件开发也才起步。当时hadoop确实能解决不少问
: 题。
: 后来机器内存多了，很多人又发现其实数据没那么大，所以就把hadoop的out-of-core
: processing抛弃了，改用spark的in-memory processing。现在hadoop有用的就是
: 一个HDFS文件系统。直接写mapreduce的应该少了，都是用HDFS上面的ecosystem。
: 另外需要注意的是这１０年硬件也在发展，传统数据库的处理能力也在增强。
|
w**z
发帖数: 8232 | 16 数据量大，当然是 mr job 快。大数据就是 use case.
【在 T*******x 的大作中提到】
: 这确实是个问题。哪个大牛能给讲讲hadoop的use case到底是什么？
: 比如把SQL server数据库搬到hadoop上，SQL server上的query改写成hive sql。那肯
: 定是要比sql server慢的了。那它的意义何在呢？
: 用spark sql改写sql server query是不是能达到相对较快的速度？但我觉得应该还是
: 要比sql server慢，可能只是慢的不多而已。
: 所以use case到底在哪？
|
c*********e
发帖数: 16335 | 17 你知道hadoop是用来干什么的吗?先把它的基础知识搞清楚。
Microsoft
data
【在 s******a 的大作中提到】
: 公司准备考虑一个hadoop 的应用， 但现在已有基于SAP 的系统， 和基于 Microsoft
: SQL 的系统， 一些 顾问公司提出的建议是把所有SAP和 microsoft SQL 里的data全
: load 到 HAHDOOP去。 但管理SAP和Microsoft SQL的 组都不愿意这么做。我也觉得这
: 不是一个正确的做法。 现在有什么成熟的架构能够只在需要的时候读取 SAP和
: microsoft SQL里的data， 而不是在Hadoop上再做一套数据的备份。或者说有什么data
: federation layer 的设计能够让hadoop 的 application layer 自由调度存在那些里
: 的data
|
T*******x
发帖数: 8565 | 18 那如果数据量不大呢？
比如有100个传统数据库，都不大。
把它们导入hadoop，接下来怎么玩啊？
这个问题不太具体，你随便说说吧。
【在 w**z 的大作中提到】
: 数据量大，当然是 mr job 快。大数据就是 use case.
|
w***g
发帖数: 5958 | 19 不是oracle慢，是400台机器快。
呢？
【在 T*******x 的大作中提到】
: 那太厉害了。这是铁的use case啊。
: 不过Oracle那么慢原因是什么啊？是数据量太大？还是很多join？spark如何解决的呢？
|
w**z
发帖数: 8232 | 20 具体情况具体分析，量不大,就没必要用hadoop, 楼上说了，你先了解一下 map reduce
究竟是干嘛的。
【在 T*******x 的大作中提到】
: 那如果数据量不大呢？
: 比如有100个传统数据库，都不大。
: 把它们导入hadoop，接下来怎么玩啊？
: 这个问题不太具体，你随便说说吧。
|
|
|
N********n
发帖数: 8363 | 21 HADOOP最大的用处是当个海量收集站，如果你的数据有固定SCHEMA、有很强的
耦合度且还没有大到RMDB装不下就没必要用HADOOP。海量无SCHEMA数据是有代
价的，代价就是事后DATA ANALYSIS很慢，因为收集时无SCHEMA、无INDEX，所
以所有的数据检索基本上就是线性查找。
Microsoft
data
【在 s******a 的大作中提到】
: 公司准备考虑一个hadoop 的应用， 但现在已有基于SAP 的系统， 和基于 Microsoft
: SQL 的系统， 一些 顾问公司提出的建议是把所有SAP和 microsoft SQL 里的data全
: load 到 HAHDOOP去。 但管理SAP和Microsoft SQL的 组都不愿意这么做。我也觉得这
: 不是一个正确的做法。 现在有什么成熟的架构能够只在需要的时候读取 SAP和
: microsoft SQL里的data， 而不是在Hadoop上再做一套数据的备份。或者说有什么data
: federation layer 的设计能够让hadoop 的 application layer 自由调度存在那些里
: 的data
|
w***g
发帖数: 5958 | 22 慢是一回事。数据库ETL是有好处的，就是数据库的schema迫使L那一步的数据是干净的
。Hadoop和mongo这类没schema的，导入的时候容易了，事后处理就得handle各种corne
r case。我们的Hadoop表里经常有上游的垃圾混进来。有时候读着读着会来一条wget或
者别的什么程序的运行出错信息。
【在 N********n 的大作中提到】
: HADOOP最大的用处是当个海量收集站，如果你的数据有固定SCHEMA、有很强的
: 耦合度且还没有大到RMDB装不下就没必要用HADOOP。海量无SCHEMA数据是有代
: 价的，代价就是事后DATA ANALYSIS很慢，因为收集时无SCHEMA、无INDEX，所
: 以所有的数据检索基本上就是线性查找。
:
: Microsoft
: data
|
s******a
发帖数: 184 | 23 我们的例子和你的有相通之处。 请问你们是不是把ORACLE上所有的数据都倒到HADOOP
上了。 将来你们会不会全面取消ORACLE呢。
【在 S*******e 的大作中提到】
: 同意应对具体的case分析。 我以前曾提过一个我们的例子，用Oracle要花上6-7个小时
: ，才能对我们20几个市场的一个市场进行一个方面的分析。现在我们用Spark over
: Hadoop Yarn, 只要几分钟就能完成同样的分析。当然代价是现在的Hadoop Cluster 有
: 近 400 个 nodes。 Oracle 是 单机 （魏老师也许用C做到几分钟 :)
|
S*******e
发帖数: 525 | 24 我们部门的另一个team是用Oracle储存那个数据的，也是那个team用Oracle做的分析（
没多大用--因为只能分析一个市场，还需要这么长时间）。 但是我们公司成立了一个
大数据部门，这个部门用Hive存储类似上面提到的那个数据，但更全面。这个hive就是
我提到的400 nodes cluster的一部分。我所在的team用Spark做出了这样的好结果，当
然另外一组不很高兴（我们经理跟大数据部门有“熟人关系“，能够用那个cluster。
）所以， 不是我们把ORACLE上所有的数据都倒到HADOOP上， 而是公司另外部门没有经
过Oracle这个环节做了这工作（数据源是一样的）。 |
