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 |
z****e
发帖数: 54598 | 2 db比较难scale，如果db比较容易scale，就没有hadoop这些什么事了
hadoop可以replica data在不同的node上
这样就可以保证大throughput的需要
不愿意这么做是肯定的，现有的猴子适应了现有的系统
如果没有来自领导层的压力，他们多半不会换
反正公司又不是他们的，他们不愿意学习新东西很正常 |
s******a
发帖数: 184 | 3 最关键的是公司已经投资了很多人力物力在SAP，SQL server 这些系统上,如果再要
求做一套备份在 HDFS 上,这个项目估计很难获得批准。 现在想法是新的数据全放到
Hadoop上， 但海量的旧数据不动， 只在需要的情况上调用。 但不知有没有可靠的架
构。 我觉得这对于很多传统的大公司都有这个问题。请教了。
【在 z****e 的大作中提到】
: db比较难scale，如果db比较容易scale，就没有hadoop这些什么事了
: hadoop可以replica data在不同的node上
: 这样就可以保证大throughput的需要
: 不愿意这么做是肯定的，现有的猴子适应了现有的系统
: 如果没有来自领导层的压力，他们多半不会换
: 反正公司又不是他们的，他们不愿意学习新东西很正常
|
z****e
发帖数: 54598 | 4
那你先批准了再讨论构架，都没有批准，这个都是空的
【在 s******a 的大作中提到】
: 最关键的是公司已经投资了很多人力物力在SAP，SQL server 这些系统上,如果再要
: 求做一套备份在 HDFS 上,这个项目估计很难获得批准。 现在想法是新的数据全放到
: Hadoop上， 但海量的旧数据不动， 只在需要的情况上调用。 但不知有没有可靠的架
: 构。 我觉得这对于很多传统的大公司都有这个问题。请教了。
|
s***f
发帖数: 457 | 5 为什么用hadoop ？
怎样通过自学转行成为一个软件工程师
http://www.mitbbs.com/article/JobHunting/32988555_0.html
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
|
f********x
发帖数: 99 | 6 可以考虑用Kafka Connect连通新旧系统：
http://www.confluent.io/blog/how-to-build-a-scalable-etl-pipeli
http://hortonworks.com/hadoop-tutorial/import-microsoft-sql-ser
http://docs.confluent.io/2.0.0/connect/connect-jdbc/docs/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
|
j*******g
发帖数: 331 | 7 我就在一个Hadoop公司工作 你们可以考虑跟我们谈一下 怎样load data取决于你们要
做什么application
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
|
s******a
发帖数: 184 | |
s******a
发帖数: 184 | 9 是这样得， 我们作分析的这块和做开发的想上Hadoop／Spark, 但做SAP, SQL Server
这块的都比较反对, 特别是SAP 自己也有大数据方案. 其实这种争论都可以理解, 大家
都想保饭碗吗. 所以就想寻求一种解决方案能够不强制要求把所有旧系统上的数据都再
做一个备份. 只有方案大家都能接受了, 才能批准.现在是在proposal 阶段.
【在 z****e 的大作中提到】
:
: 那你先批准了再讨论构架，都没有批准，这个都是空的
|
s******a
发帖数: 184 | 10 给你发站内信了, 谢谢.
【在 j*******g 的大作中提到】
: 我就在一个Hadoop公司工作 你们可以考虑跟我们谈一下 怎样load data取决于你们要
: 做什么application
:
: Microsoft
: data
|
|
|
m*****y
发帖数: 229 | |
z****e
发帖数: 54598 | 12
Server
系统当然是备份越多越好，如果条件允许的话
如果不把旧的数据做一个备份，那就意味着开发要做两套接口
一套给旧的系统，一套给新的系统
也就是开发会很痛苦，就看开发同意不同意了
其实这种东西不应该民主评议，民主的效率低下从这种事可以看出来
旧的顽固势力肯定会拖着你们，这种要看领导的魄力
【在 s******a 的大作中提到】
: 是这样得， 我们作分析的这块和做开发的想上Hadoop／Spark, 但做SAP, SQL Server
: 这块的都比较反对, 特别是SAP 自己也有大数据方案. 其实这种争论都可以理解, 大家
: 都想保饭碗吗. 所以就想寻求一种解决方案能够不强制要求把所有旧系统上的数据都再
: 做一个备份. 只有方案大家都能接受了, 才能批准.现在是在proposal 阶段.
|
d****n
发帖数: 12461 | 13 这是造好房子娶老婆的节奏吗？我觉得还是先找到老婆比较重要，找到一个sap和sql都
搞不定的应用就够了。
hadoop在一些大公司可能只是作为etl的步骤，最后还是要进data warehouse的。
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
|
b****u
发帖数: 1130 | 14 我最近也做了一个类似系统。其实取决于你们最后要用这些数据干什么，性能的要求（
是否要实时）。
很多情况下，需要一个datawarehouse，同时你需要建议个pipeline把数据拷备，同步
等。我用Scala和spark，因为spark有dataframe，处理转化数据非常方便。我们用
redshift做数据仓库，性能不错。
同时还需要一些visualization的软件， 如tableau，looker， etc。有了数据仓库，
做一些更高级的分析也会很方便，python，R，Scala，都不错。
特别说明一下，现在已有很多商业化的datapipeline，但同步数据一半都要数据源的
log文件来做CDC （capture data change）.我们最后自己做pipeline，其实更放心。 |
T*******x
发帖数: 8565 | 15 你们最后自己做data pipeline，也就是说你们自己处理数据源的log来做CDC的？比如
说你们数据源有SQL server，数据库的变化有t-log，你们是自己处理t-log来做CDC的？
【在 b****u 的大作中提到】
: 我最近也做了一个类似系统。其实取决于你们最后要用这些数据干什么，性能的要求（
: 是否要实时）。
: 很多情况下，需要一个datawarehouse，同时你需要建议个pipeline把数据拷备，同步
: 等。我用Scala和spark，因为spark有dataframe，处理转化数据非常方便。我们用
: redshift做数据仓库，性能不错。
: 同时还需要一些visualization的软件， 如tableau，looker， etc。有了数据仓库，
: 做一些更高级的分析也会很方便，python，R，Scala，都不错。
: 特别说明一下，现在已有很多商业化的datapipeline，但同步数据一半都要数据源的
: log文件来做CDC （capture data change）.我们最后自己做pipeline，其实更放心。
|
b****u
发帖数: 1130 | 16 这就是为什么我问具体的需求和应用是什么。获取数据库的log并不是一个好的选择，
这个方案被否决。
最理想的方法是加一个mesage 中间层 （kafka，等）。 然后SQLserver，
Datawarehouse， etc 再获取数据。但这要改变你们的整个系统架构。而我们对实时没
有太多要求，所以我们可以每天full load 大多数的数据表格。有一些很大的时间序列
数据，你可以用timestamp来做到CDC， 大概一个小时同步一遍。
的？
【在 T*******x 的大作中提到】
: 你们最后自己做data pipeline，也就是说你们自己处理数据源的log来做CDC的？比如
: 说你们数据源有SQL server，数据库的变化有t-log，你们是自己处理t-log来做CDC的？
|
z*********0
发帖数: 103 | 17 我是SAP公司的，首先，当然反对Load数据到HADOOP，开什么玩笑，你知道这个Load对
系统稳定性影响有多大吗？
你用hadoop最多就是做做BI分析吧，就算SAP自家公司的BW，或者你直接用HANA做底层
，各种ETL抽数据都是非常谨慎的，
另外问下贵公司底层用的什么数据库， HANA还是Oracle，或者就是SQL Server？
如果是后者的话。。算了。。别瞎折腾，为了一个BI把系统给折腾跨了不值得。。
那些所谓的咨询公司在瞎出主意呢，，
SAP自家游大数据平台，不过要求首先贵公司SAP系统迁移到HANA上去，然后通过HANA
集成HADOOP/SPARK，作为分析平台。。
不过一般公司折腾不起，HANA多贵知道吧，HANA工程师也很贵。。 |
T*******x
发帖数: 8565 | 18 你这个架构我没太看懂。
kafka我不熟悉，但我大概知道它是干什么的。
假如想把sql server数据库搬到Hadoop上去。
那么你们的做法是：sql server -> kafka -> hadoop？
你们对于小的table每天做full load，大的有时间序列的用timestamp做CDC.
那么你们完全不需要数据库那边dba做一点改动，对不对？
完全是从用户的层面来处理。
【在 b****u 的大作中提到】
: 这就是为什么我问具体的需求和应用是什么。获取数据库的log并不是一个好的选择，
: 这个方案被否决。
: 最理想的方法是加一个mesage 中间层 （kafka，等）。 然后SQLserver，
: Datawarehouse， etc 再获取数据。但这要改变你们的整个系统架构。而我们对实时没
: 有太多要求，所以我们可以每天full load 大多数的数据表格。有一些很大的时间序列
: 数据，你可以用timestamp来做到CDC， 大概一个小时同步一遍。
:
: 的？
|
T*******x
发帖数: 8565 | 19 这个load怎么对系统稳定性有影响？能不能展开说明？
【在 z*********0 的大作中提到】
: 我是SAP公司的，首先，当然反对Load数据到HADOOP，开什么玩笑，你知道这个Load对
: 系统稳定性影响有多大吗？
: 你用hadoop最多就是做做BI分析吧，就算SAP自家公司的BW，或者你直接用HANA做底层
: ，各种ETL抽数据都是非常谨慎的，
: 另外问下贵公司底层用的什么数据库， HANA还是Oracle，或者就是SQL Server？
: 如果是后者的话。。算了。。别瞎折腾，为了一个BI把系统给折腾跨了不值得。。
: 那些所谓的咨询公司在瞎出主意呢，，
: SAP自家游大数据平台，不过要求首先贵公司SAP系统迁移到HANA上去，然后通过HANA
: 集成HADOOP/SPARK，作为分析平台。。
: 不过一般公司折腾不起，HANA多贵知道吧，HANA工程师也很贵。。
|
z****e
发帖数: 54598 | 20 这就是一个很好的理由为什么我们/他们要用hadoopo
因为连load个数据这么简单的功能，都能造成“对系统稳定性有影响”
开什么玩笑，这种设计是对分布式的一种侮辱
【在 z*********0 的大作中提到】
: 我是SAP公司的，首先，当然反对Load数据到HADOOP，开什么玩笑，你知道这个Load对
: 系统稳定性影响有多大吗？
: 你用hadoop最多就是做做BI分析吧，就算SAP自家公司的BW，或者你直接用HANA做底层
: ，各种ETL抽数据都是非常谨慎的，
: 另外问下贵公司底层用的什么数据库， HANA还是Oracle，或者就是SQL Server？
: 如果是后者的话。。算了。。别瞎折腾，为了一个BI把系统给折腾跨了不值得。。
: 那些所谓的咨询公司在瞎出主意呢，，
: SAP自家游大数据平台，不过要求首先贵公司SAP系统迁移到HANA上去，然后通过HANA
: 集成HADOOP/SPARK，作为分析平台。。
: 不过一般公司折腾不起，HANA多贵知道吧，HANA工程师也很贵。。
|
|
|
z****e
发帖数: 54598 | 21
hadoop有价值的部分主要是hdfs
用vert.x之后，连这个都可以省掉其实
我直接用vert.x的file system，自己写replica这些，也没多难
要不是大学那边一定要用hadoop，因为他们买了cloudera的服务
不用浪费，所以说给我们用不收钱，我未必会主张用什么hadoop呢
data warehouse的hype居多
其实hadoop本身也是一个hype，大多数人只是觉得这个hot
就无脑上了，etl用一个scheduler就好了，如果非要streaming的话
用rxjava做一个稳定的连接，但是一般没有必要
vert.x的setPeriodic方法足以替代一般的scheduler
【在 d****n 的大作中提到】
: 这是造好房子娶老婆的节奏吗？我觉得还是先找到老婆比较重要，找到一个sap和sql都
: 搞不定的应用就够了。
: hadoop在一些大公司可能只是作为etl的步骤，最后还是要进data warehouse的。
:
: Microsoft
: data
|
j**********3
发帖数: 3211 | |
b****u
发帖数: 1130 | 23 我们暂时还不用kafka，因为不要求做实时同步。其实就是一个简单的数据拷贝，没必
要那么麻烦。Spark 有一个很有用的东西dataframe，它可以从数据源读取表格然后直
接存到目标数据库中，数据源可以是一个文件，非常方便。
我的原则是越简单越好，能用已有的轮子最好。
不要对原始数据库的东西做任何改变，当然为了方便，也可以加几个view table。这个
好处是，以后原始数据库有一些大的变化，你只要调整重写viewtable 就可以了，
pipeline是不用变化的，有点像interface。
现在的关键是你要把数据放到什么地方。我们用redshift，它是column based，性能好
。 同时还是一个rational db， 和以前的系统兼容性好。
【在 T*******x 的大作中提到】
: 你这个架构我没太看懂。
: kafka我不熟悉，但我大概知道它是干什么的。
: 假如想把sql server数据库搬到Hadoop上去。
: 那么你们的做法是：sql server -> kafka -> hadoop？
: 你们对于小的table每天做full load，大的有时间序列的用timestamp做CDC.
: 那么你们完全不需要数据库那边dba做一点改动，对不对？
: 完全是从用户的层面来处理。
|
f******y
发帖数: 54 | 24 你要的那个同步工具，可能sqoop符合你的要求.哈哈 |
u*****1
发帖数: 28 | |
s******a
发帖数: 184 | 26 谢谢你的回复。 项目大概的背景是这样， 有不同的数据源， 传统的会计数据， 一般
都在SAP里。 一些管理数据和市场销售数据分布在SQL 和SAP上。 现在很多生产过程中
产生的实时数据也会存下来， 这部分因为是新的所以肯定要放在 HADOOP ／SPARK系统
上。从供应链的角度，肯定希望有一个分析平台能够把所有这些数据都放在一起， 支
撑可能会需要的全局分析。 （确实有点象前面回帖中提到的先盖房子再去老婆）。现
在一个主要的问题就是是否需要把SAP和 SQL里的所有数据都物理性的存到HDFS上。 这
种物理性的彻底备份会使得SAP team 和 SQL team 觉得他们的工作受到威胁。 这个
转向 HADOOP／SPARK的proposal就很难通过。所以我们想找到一个message layer的设
计只把分析需要的data 实时传过来。 不知道这样的想法是不是合理。
【在 b****u 的大作中提到】
: 我最近也做了一个类似系统。其实取决于你们最后要用这些数据干什么，性能的要求（
: 是否要实时）。
: 很多情况下，需要一个datawarehouse，同时你需要建议个pipeline把数据拷备，同步
: 等。我用Scala和spark，因为spark有dataframe，处理转化数据非常方便。我们用
: redshift做数据仓库，性能不错。
: 同时还需要一些visualization的软件， 如tableau，looker， etc。有了数据仓库，
: 做一些更高级的分析也会很方便，python，R，Scala，都不错。
: 特别说明一下，现在已有很多商业化的datapipeline，但同步数据一半都要数据源的
: log文件来做CDC （capture data change）.我们最后自己做pipeline，其实更放心。
|
h**e
发帖数: 410 | |
B*****g
发帖数: 34098 | 28 sql server, check CDC
do not know sap
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
|
B*****g
发帖数: 34098 | 29 赵老师混db版了？
【在 z****e 的大作中提到】
: db比较难scale，如果db比较容易scale，就没有hadoop这些什么事了
: hadoop可以replica data在不同的node上
: 这样就可以保证大throughput的需要
: 不愿意这么做是肯定的，现有的猴子适应了现有的系统
: 如果没有来自领导层的压力，他们多半不会换
: 反正公司又不是他们的，他们不愿意学习新东西很正常
|
c*****d
发帖数: 6045 | 30 好虫和赵老师已经放弃宝典版了，觉得他们水平太差
现在好像老魏也不去了
【在 B*****g 的大作中提到】
: 赵老师混db版了？
|
|
|
B*****g
发帖数: 34098 | 31 放弃DB版吧
【在 c*****d 的大作中提到】
: 好虫和赵老师已经放弃宝典版了，觉得他们水平太差
: 现在好像老魏也不去了
|
s**********o
发帖数: 14359 | 32 这还是一个DATA INTEGRATION的问题吧，数据多久更新一次啊
是FULL LOAD还是INCREMENTAL啊，数据质量怎么样，LOAD要多久啊，
搞大数据很容易把以前的烂数据模型给暴露出来，几个烂水果，拼凑起来
搞个好吃的果盘，不容易。大数据LOAD好了，RUN一下就出结果了，很容易；
但是数据从哪里来的，怎么来的，变了没有，怎么变的，这就是大问题 |
J*******o
发帖数: 741 | |
f********x
发帖数: 99 | 34 你的这个需求就是Kafka Connect要解决的问题：
http://www.confluent.io/blog/how-to-build-a-scalable-etl-pipeli
【在 s******a 的大作中提到】
: 谢谢你的回复。 项目大概的背景是这样， 有不同的数据源， 传统的会计数据， 一般
: 都在SAP里。 一些管理数据和市场销售数据分布在SQL 和SAP上。 现在很多生产过程中
: 产生的实时数据也会存下来， 这部分因为是新的所以肯定要放在 HADOOP ／SPARK系统
: 上。从供应链的角度，肯定希望有一个分析平台能够把所有这些数据都放在一起， 支
: 撑可能会需要的全局分析。 （确实有点象前面回帖中提到的先盖房子再去老婆）。现
: 在一个主要的问题就是是否需要把SAP和 SQL里的所有数据都物理性的存到HDFS上。 这
: 种物理性的彻底备份会使得SAP team 和 SQL team 觉得他们的工作受到威胁。 这个
: 转向 HADOOP／SPARK的proposal就很难通过。所以我们想找到一个message layer的设
: 计只把分析需要的data 实时传过来。 不知道这样的想法是不是合理。
|
a*s
发帖数: 131 | |
s******a
发帖数: 184 | 36 谢谢， 请问Pentaho也是实现类似的功能的吗？
【在 f********x 的大作中提到】
: 你的这个需求就是Kafka Connect要解决的问题：
: http://www.confluent.io/blog/how-to-build-a-scalable-etl-pipeli
|
